'웹해킹/Bee-box'에 해당되는 글 22건

1. 하트블리드 취약점 개요

하트 블리드 취약점은 2014년 4월에 발견된 OpenSSL 소프트웨어 버그다. CVE-2014-0160이며 이 취약점은 사용자나 관리자의 아이디, 패스워드, SSL 비밀키 등을 노출하게 하는 매우 위험한 취약점으로 판명됐다. OpenSSL 1.0.1 이후 '하트비트'라는 세션 연결을 확인하는 방법을 제공하지만 전달되는 값의 길이가 검증되지 않아 버퍼 오버플로우가 발생한다. 이 결함은 최대 64KB의 응용 프로그램 메모리 내용을 요청할 수 있다. 서버의 메모리 정보를 평문으로 볼 수 있어 지속적으로 공격해 정보들을 합치면 아이디, 패스워드, 기타 개인 정보 노출이 가능해진다.

                                                                                                          <사진 출저 : blog.alyac.co.kr>

[그림 1-1] 하트블리드 시나리오

하트블리드 시나리오를 보면 클라이언트는 의도적으로 거짓 정보를 서버에게 전달해 오류를 발생시킨다. 서버측은 클라이언트에서 받은 거짓 정보를 검증 하지 않고 클라이언트가 요청한 거짓 정보 값을 그대로 다시 응답한다. 예를 들면 "이것은 잘못된 정보입니다. 사용자의 ID 값은 Hello며 PW는 1234$ 입니다."로 잘못된 정보를 포함해 또 다른 정보들을 클라이언트에게 전달하게 된다. 이러한 정보들이 합쳐져 아이디, 패스워드, 개인 정보 등과 같은 중요 정보들이 노출되게 된다.

2. 취약점 실습 환경 구성

3. 하트 블리드 취약점 스크립트 코드 시연

[그림 3-1] 하트 블리드 취약점

Nginx 웹 서버가 취약한 버전의 OpenSSL을 사용하고 있다. 8443 포트로 공격 스크립트를 작동하라는 메시지가 출력되었다.

[그림 3-2] 명령어 입력

위의 스크립트를 다운 받아 저장 후 실행한다. Python heartbleed.py [웹 서버 IP] | more 명령어를 입력하고 실행하면 공격 스크립트가 실행된다.

[그림 3-3] 8443 포트 접근

희생자 PC에서 웹 서버의 8443 포트로 접근한 후 계정 정보로 로그인을 시도한다.

[그림 3-4] 계정 정보 노출

로그인 시도 후 실행했던 공격 스크립트를 확인하면 메모리 단에 로그인했던 계정 정보가 평문으로 노출되어 있음을 확인할 수 있다.

[그림 3-5] 와이어 샤크 패킷 전송

와이어샤크에서 ip.addr == [웹 서버 IP]로 필터링하고 패킷을 확인하면 하트블리드 공격에 의해 전송된 값을 볼 수 있고 입력 했던 계정 정보가 평문으로 노출되고 있음을 확인할 수 있다.

[그림 3-6] TCP Steam

정상 SSL 통신에서 암호화되는 요청 패킷의 내용이 하트블리드 취약점에 의해 요청 패킷 내용이 평문으로 전송되고 있다.

4. 하트블리드 취약점 메타스플로잇 시연

[그림 4-1] 모듈 검색

msfconsole 실행 후 search heartbleed 명령어로 하트블리드 관련 모듈을 확인한다. 하트블리드 취약점 시연을 위해 auxiiary/scanner/ssl/openssl_heartbleed 모듈을 사용한다.

[그림 4-2] 옵션 지정

하트블리드 모듈을 실행하고 옵션을 지정한다. 지정 옵션들은 다음과 같다.

[그림 4-3] 공격 수행

옵션 지정 후 공격을 수행하면 스캔이 시작된다. 스캔이 되고 메모리 값이 노출되는데 웹 서버에서 로그인 했던 계정 정보가 평문으로 노출되고 있음을 확인할 수 있다.

5. 대응 방안

Open SSL 버전 업데이트, 비밀번호 이중 인증, 인증서 재발급, IPS 탐지룰 설정 등으로 방어한다. 사용하는 운영체제의 정식 페이지에서 Open SSL 업데이트 버전을 설치한 후 테스트 해보는 방법도 필요하다.

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

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방식으로 사용하는 것도 예방책이 될 수 있을 것 같다.

이번 포스팅은 Base 64 인코딩 복호화, Html 5 웹 저장소, 파일텍스트 중요정보 저장에 대해 해보려고 한다. 조금 말이 복잡해 보이는데 크게 어렵진 않은 내용들이다. 

1. 클라이언트에 암호화하지 않고 서버에 암호화 하는 이유는?

- 클라이언트에서 암호화를 해서 서버로 전송을 하게 되면 클라이언트가 해커인지 사용자인지 분간할 수 없다. 서버에서 암호화를 하기는 하지만 보안상 완벽하다고 말하기는 힘들다.

- 클라이언트에서 암호화하게 되면 중간에 해커가 가로채는 하이재킹공격을 시도할 수 있기 때문에도 되도록이면 서버에서 암호화 할 수 있도록 하는게 좋다.

* 공격 실습

1) Base 64 Encoding(Secret)

일단 Base 64 Encoding(Secret)를 선택하고 보안레벨을 Low로 맞추고 프록시를 잡아주면 secret값이 나온다. 이걸 그대로 복사해준다.

이걸 그대로 Base64 Docoder기에 넣어주면 바로 해독된다는 것을 볼 수 있다.

잠깐 비박스에서 Base64에 대한 코드를 보면 보안레벨이 1,2일땐 sha1으로 비밀번호를 정의한다고 했는데 sha1은 얼마든지 해킹이 가능하기 때문에 사실 이것도 보안이라고 보긴 힘들다. base64 인코드 역시 바로 번역기로 해킹이 가능하기 때문에 안전한 보안이라고 할 수 없다.

medium에 세팅해놓고 프록시를 잡아봤을때도 아까와 별다를게 없어보인다. 이걸 Hash에 넣고 확인해본다.

리눅스에 hash를 실행시켜서 secret문자를 붙여넣어보면 비밀번호가 sha1으로 되어 있음을 알 수 있다.

이 값을 그대로 sha1 디코더에 넣어서 실행시켜 보면 바로 비밀번호가 해킹됐음을 알 수 있다. 여기서 제일 중요한건 웹환경을 구축할 때 민감한 평문데이터들을 local에 저장하면 절대 안된다는 것이다. local에 저장했을시 이렇게 쉽게 해킹되기 때문에 구축할때 주의가 필요하다.

Xss공격으로도 쉽게 security값을 알아낼 수 있다.

물론 보안레벨이 높아짐에 따라 조금씩 좋아지긴 하지만 어쨌든 local에는 평문으로 민감한 데이터를 저장하지 않는게 핵심이다.

2) Html5 web Storage(Secret) 공격

일단 보안레벨을 Low로 맞춰준다.

그리고 text에 이렇게 코드를 삽입해준다.

Xss-Reflected(Get)으로 와서 방금 입력한 코드를 Firstname에  넣어서 실행해보면 이런식으로 나오는데 이 또한 아까와 똑같은 sha1값이 그대로 출력된다는 걸 알 수 있다. Xss공격에 대한 방어가 안되고 있음을 보여주고 있으며 medium, High로 올려봤을땐 전혀 sha1값이 나오진 않았지만 local환경은 항상 유의해야 함을 볼 수 있었다.

3) Text Files(Account) 공격

아이디와 비밀번호를 입력하고 보안레벨은 low로 맞춰준다.

다운로드를 클릭해서보면 사진처럼 bee bug만 나온다.

이번에는 medium으로 맞추고 다운로드를 클릭해본다.

이번에는 알수없는 문자가 나왔지만 hash에 넣어보면 이 역시 sha1이다. 바로 해독기에 넣고 돌리면 비밀번호가 추출된다.

이런식으로 추출이 완료된다. sha1으로 된 비밀번호는 역시 위험하다.

이번에는 보안레벨을 High로 맞춰놓고 다운로드를 해본다.

이번에는 salt까지 추가되었음을 볼 수 있다. Hash 비밀번호를 Hash에서 어떤식으로 되어 있는지 확인해 보도록 하겠다.

아까와는 다른 SHA-256으로 되어 있는데 이렇게 SHA-256으로 되어 있는 비밀번호들은 비교적 많이 안정하다고 평가 받고 있다. 아까 나온 salt 비밀번호와 같이 합쳐줘서 계산해줘야 되기 때문에 해독이 쉽지 않아 이런식으로 되어 있으면 보안등급이 높다고 평가 할 수 있다.

SHA-256을 해독하기 위해 john이라는 툴을 사용해봤는데 해독하기 쉽지 않았다. passwd.txt에 Hash값을 넣고 저장해서 salt값을 같이 넣어서 실행해줬는데 시간도 너무 오래 걸리고 잘 해독되지 않았다. 이처럼 hash값이 SHA-256으로 되어 있으면 안전하다고 평가할 수 있을 것 같다.

이번에는 중요정보를 변경 및 초기화하고 상품가격을 조작하는 공격에 대해 알아보려고 한다.  먼저 이러한 해킹들의 대표적인 실제 사례가 있어 제시한다.

<실제 사례>

<사진출저:Google 나무위키 사전백과>

2014년에 있었던 KT 최악의 개인정보 유출사건이다. 이 당시에 1200만명의 엄청난 고객 정보들이 유출 되었으며 그중 일부는 다른 회사에 판매하는 방식으로 이익을 챙겨 일당들이 전부 구속된 사례이다. 이게 어떻게 해킹 되었는지는 아래에 실습과정을 쓰겠지만 사실 어떻게보면 해킹이라고 보기에도 너무 애매하다. 오늘 실습했던게 보통 로그인을 할 때 과연 그 사용자가 맞는지, 해커는 아닌지에 대해 검증하고 필터링 하는 과정이 필요한데 KT는 이 당시에 이러한 검증절차를 거치지 않고 DB의 내용만 믿고 숫자만 맞으면 로그인을 시키게끔 했던 시스템이었다. 그러다보니 파로스프로그램, 즉 본인이 사용하고 있는 버프스윗과 거의 차이가 없는 툴이었다. 이 툴을 바탕으로 고유숫자 9개를 아무거나 입력시켜서 가입고객 고유번호를 맞춰서 고객정보를 유출시킨 사건이었다.

<공격실습>

(1) InSecure DOR(Change Secret) 공격

비밀번호 바꾸기 공격이다. 사용자인줄 알고 DB인증 절차 없이 바로 비밀번호 변경이 가능한 실습이다. 보안레벨을 low로 맞춰주고 test1234라는 값을 입력하고 change버튼을 눌러준다.

전에 했었던  SQL 인젝션 로그인폼으로 와서 bee, bug를 입력해주고 로그인하면 저런식으로 Test1234라고 비밀번호가 바로 변경된 것을 볼 수 있다. 인증절차 없이 DB정보만 맞으면 그냥 바꿔준 것이다.

이번에는 'or 1=1# 공격문을 써서 로그인을 해보니 아이디는 AIM이라고 나오고 비밀번호는 아까 입력한 test1234가 나오게 된다. 비밀번호를 한 번 변조해 보겠다.

InSecure DOR로 다시 와서 바꿀 비밀번호를 입력하고 프록시를 잡아준다. 그리고 프록시를 잡아준 곳을 보면 login이라는 곳이 있는데 여기에다가 아까 변조하려고 했던 A.I.M.을 넣어주고 포워딩시킨다.

그리고 SQL 인젝션으로 다시와서 아까와 똑같이 로그인을 해보면 저런식으로 Test4321로 비밀번호가 변경된 것을 볼 수 있다. DB내용만 맞으면 로그인이 되어서 저런식으로 변조가 가능했던 것이다.

이번엔 보안레벨을 medium으로 맞추고 프록시를 잡아보았다. medium레벨에서는 아까와는 다르게 token이라는 값이 잡혔는데 이 token값을 활용해서 검증절차를 한번 더 짚어보겠다는 의미로 해석된다. low와는 다르게 한단계정도는 보안이 강화된 상황이다. 

<대응방안>

비박스에 들어가서 insecure_direct_object_ref_1.php파일을 열어보면 보안레벨이 low일때 어떤방식으로 처리하고 있는지에 대해서 알 수 있다. $sql쪽을 보면 login이 되면 별다른 검증절차 없이 어떠한 아이디라고 패스워드를 바꿀 수 있다. 이러한 방식은 매우 위험한 코드라고 보면 된다. 검증절차를 거치게 하는 코드를 짜야한다. 그래도 Xss공격에 대해서는 방어를 하고 있는 상태이다. escape함수, htmlspecialchars함수를 사용했으며 어느정도 Xss공격에 대해서는 대비가 되어 있는 상태라고 볼 수 있다. 

이번에는 Medium과 High레벨 상태의 코드이다. 아까와는 다르게 token이라는 값을 삽입해 세션을 검증하는 절차를 거치고 있다. 세션이 검증되지 않으면 로그인 정보로 넘어갈 수 없는 상태이다. medium, High레벨 상태도 Xss공격에 대한 대해서는 대비가 되어 있는 것을 볼 수 있다. 하지만 이 코드도 그렇게 안전하지는 못하다고 생각한다. sql쪽에서 문제가 발생할 수 있는데 login이라는 정보를 프록시에 삽입해주기만 하면 우회해서 또 변경이 가능하다.

test1234를 입력하고 프록시를 잡아준 화면인데 여기에 login할 아이디를 입력해준다. 그리고 포워드를 해준다.

그렇게 되면 이런식으로 또 한번 비밀번호가 변경되었음을 볼 수 있다. 그래도 검증절차를 거치는 것은 기본이라 보안레벨이 조금이라도 높다고는 할 수 있지만 이런식으로도 해킹이 얼마든지 가능하기 때문에 이러한 해킹을 막는건 조금 더 생각해 봐야 할 문제 일 것 같다.

(2)  InSecure DOR(Reset Secret) 공격

Reset Secret공격도 아까 했던 공격과 크게 다르진 않다. 프록시를 잡아주고 변조할 아이디를 넣고 Forword를 해준다. 

SQL 인젝션쪽으로 와서 로그인해서 확인해보면 저런식으로 비밀번호가 변조되었음을 알 수 있다.

이번에는 medium으로 맞춰놓고 프록시를 잡은상태인데 바꿀비밀번호를 aaa로 놓고 포워딩을 해줬다.

A.I.M.으로 로그인을 해보니 비밀번호가 전혀 바뀌지 않고 아까와 그대로 임을 볼 수 있다. 

<대응방안>

 insecure_direct_object_ref_3.php 파일을 열어보면 다음과 같은 코드들이 있다. 좀 두드러진 특징이 Content-type를 사용해서 데이터를 보내주고 있다는 것인데 Post방식을 사용할때는 xxe-2.php로 보내준다고 코드가 짜여져 있다. 

xxe-2.php 파일을 열어보면 이런 코드가 나오는데 보안레벨이 low일때를 보여주고 있다. 아까와 같이 비밀번호가 손쉽게 변경된 이유도 DB 검증절차를 전혀 거치지 않고 있다.  xml에서  login, secret으로 아무런 검증없이 로그인만 되면 바로바로 변경이 가능할 수 있다. 검증절차를 거치지 않는 코드는 보안레벨이 가장 낮은 코드라고 보면 된다.

반대로 보안레벨이 조금 높아진 경우의 코드이다. 아까와는 다르게 login값을 세션에 묶어 검증하는 절차가 있음이 눈에 띄게 보이게 된다. 이런식으로 반드시 검증하는 절차의 코드가 있어야 그래도 조금 안전한 레벨의 보안수준이라고 할 수 있을 것 같다.

(2) InSecure DOR(Order Ticket) 공격 -> 상품가격조작 공격

이 공격도 매우 간단하지만 홈페이지에 있는 가격을 변조해서 물건을 구입하려는 블랙해커들이 자주사용하는 방법이다. 실사이트에 공격해 물건값 변조해서 구입하면 이 역시 교도소행이니 알아만두고 절대 사용하면 안된다!

이렇게 프록시를 잡아주고 프록시에서 ticket값을 1로 변조하고 포워딩을 시켜준다.

이렇게 되면 아까는 15유로였는데 1유로로 변조되었음을 알 수 있다.

<대응방안>

레벨이 가장 낮은 보안수준일때는 ticket_price를 그냥 입력되는 그대로 전부 다 보내주고 있다. 아무런 검증절차를 거치지 않고 그냥 로그인정보만 믿고 보내주는 셈이다.

반면 보안레벨이 medium, High일때는 ticket_price를 입력된 값 그대로 보내주겠다는 코드이고, 그렇지 않으면 안보내겠다는 코드이다. 즉, Request라는 검증절차를 거치고 보내주겠다는 의미로 해석된다.