gdh

PHP 버전 5.3.12와 5.4.2 이전 버전에는 소스코드가 노출되거나 공격자가 임의의 코드를 실행할 수 있는 취약점(CVE-2012-1823)이 존재한다. 이 취약점은 요청 URI의 쿼리스트링 부분을 잘못 처리함으로써 발생한다.

bWAPP의 PHP 버전은 phpinfo.php 페이지에 접속해보면 5.2.4임을 확인할 수 있다.

bWAPP의 /admin/ 경로에서 PHP-CGI 취약점 공격을 실습해보자.

※ CGI(Common Gateway Interface) : 스크립팅 언어(쉘 스크립트, 파이썬 스크립트, perl 스크립트 등)로 만들어진 외부 프로그램을 웹 서버에서 실행할때 사용하는 기술. 90년대~00년대 초중반에 주로 쓰인 기술.

소스코드 노출

쿼리스트링 부분에 -s를 입력하니 admin 페이지의 PHP 소스코드가 출력된다.

이 취약점을 이용하면 임의의 코드 실행도 가능하다.

메타스플로잇을 이용한 공격

칼리 리눅스 메뉴에서 메타스플로잇을 검색해서 실행한다.

search 명령어로 공격 모듈을 검색한다.

use 명령어로 모듈을 설정한다.

공격에 성공하게 되면 실행할 페이로드를 설정한다. show payloads 명령어로 페이로드 목록을 확인할 수 있다. 리버스 쉘을 생성하는 페이로드를 설정하였다.

show options 명령어로 옵션을 확인하고 set 명령어로 필요한 옵션을 설정한다.

설정을 모두 마쳤으면 run 명령어를 입력하여 익스플로잇을 실행한다. 공격에 성공하면 쉘이 생성된다.

www-data 사용자 권한을 획득했다. 실제로는 루트 권한 획득을 위해 권한 상승 공격으로 이어진다.

쉘쇼크는 시스템 환경변수에 다음과 같이 특정 패턴의 문자열과 함께 임의의 명령어가 저장되어 있으면 쉘이 실행될 때 해당 명령어가 실행되는 취약점이다.

() { :;}; <command>

쉘쇼크 취약점이 공개될 때 쉘쇼크 취약 여부를 테스트하기 위해 알려진 명령문은 다음과 같다.

env x='() { :;}; echo vulnerable' bash -c 'echo this is test'

x 환경 변수에 쉘쇼크 공격 패턴과 명령어(echo vulnerable)을 지정한 뒤 지정한 명령어가 실행되는지 확인하는 것이다. 쉘쇼크 취약점에 취약하다면 vulnerable 문자열이 출력된다.

A9 그룹의 Shellshock Vulnerability 메뉴를 선택한다.

CGI가 보이고 레퍼러 헤더를 공격하라는 힌트가 있다.

CGI로 구현된 웹 애플리케이션의 경우 요청 헤더가 환경 변수로 저장됨으로써, 웹을 통해 쉘쇼크 공격이 가능하다.

페이지의 소스코드를 보면 <iframe>태그를 통해 요청한 shellshock.sh 쉘 스크립트가 실행되고 있다. shellshock.sh가 요청되면 bash에 의해 쉘 스크립트가 실행된다. 이때 쉘쇼크 취약점이 존재하므로, SHELLSHOCK.SH를 요청하는 요청 헤더에쉘쇼크 공격 코드를 삽입하여 전송하면 원하는 명령을 실행할 수 있다.

쉘쇼크 공격은 명령어 실행이 가능한 공격이다. 이처럼 원격 명령어나 원격 코드 실행이 가능한 경우 명령어를 실행하여 쉘을 획득 후 호스트 침투 및 추가 공격을 진행한다. 쉘을 획득하는 기법은 주로 리버스 쉘을 이용한다. 기업 네트워크 환경에서 내부에서 외부로의 접속은 허용되어도 외부에서 내부로의 접속은 방화벽에 차단되기 때문이다.

먼저 칼리 리눅스 터미널에서 nc 명령어를 이용해 서버모드로 실행한다.

shellshock.sh 요청을 리피터 기능을 이용해 레퍼러 헤더의 값을 다음과 같이 변경한다.

() { :;}; 쉘쇼크 공격 패턴 뒤에 nc를 이용하여 칼리 리눅스에서 리스닝하고 있는 4000번 포트로 접속한다. 

192.168.56.102는 칼리 리눅스의 IP다.

요청 전송 후 리버스 쉘이 연결되고 명령어를 실행할 수 있다.

아래의 명령어를 실행하면 프롬프트가 나타난다.

python -c 'import pty; pty.spawn("/bin/bash");'

쉘을 획득했지만 id 명령어의 결과에서 보이듯이 www-data라는 사용자 권한을 획득한 것이다. root 권한이 아니기에 추가 공격을 진행하는데 제한이 있다. 이런 경우 실제로는 루트 권한 획득을 위한 권한 상승 공격으로 이어진다.

많은 개발 프로젝트들이 오픈소스 라이브러리를 사용하고 있다. 오픈소스 라이브러리엔 취약점이 존재하고 있고 알려진 대부분의 취약점은 CVE 데이터베이스를 통해 공개된다.

하트블리드 취약점은 SSL/TLS 프로토콜을 구현한 OpenSSL 라이브러리 중 1.0.1 - 1.0.1f 버전에 존재하는 취약점이다. 취약점이 하트비트라는 확장 기능에서 발견되었기에 하트블리드라는 이름이 명명되었다.

하트비트라는 확장 모듈에서 클라이언트 요청 메시지를 처리할 때 데이터 길이 검증을 수행하지 않아 시스템 메모리에 저장된 64KB 크기의 데이터를 외부에서 탈취할 수 있는 취약점이다.

하트블리드 취약점을 이용하면 공격자는 웹 서버 호스트의 메모리를 읽을 수 있게 되어 사용자의 로그인 정보 및 그 밖의 민감한 정보들을 탈취할 수 있다.

A9 그룹의 Heartbleed Vulnerability 메뉴를 선택한다.

톰캣에서는 HTTP 통신시 8080포트를 사용한다. 보안을 위해 SSL/TLS 인증서 기반의 HTTPS 통신을 하는 경우 8443포트를 사용한다.

attack script 를 눌러서 heartbleed.py 파일을 다운로드한다.

bee box의 8443포트로 접속한다. HTTPS를 이용해서 접속해야한다.

https://192.168.56.104:8443

에러가 뜰텐데 Advanced를 클릭하고 리스크를 감수하겠다고 하면 된다. 에러가 뜨는 이유는 HTTPS 통신을 할때 SSL 인증서가 사용되는데 bwapp에서 제공하는 인증서를 신뢰하지 못하기 때문이다.

접속 후 로그인하고 나서 heartbleed.py를 실행한다.

python2 heartbleed.py 192.168.56.104 -p 8443

python2를 사용해야 에러없이 실행된다. python3을 사용하면 수정할게 너무 많다.

192.168.56.104는 bwapp이 실행되는 서버 IP이니 자기의 환경에 맞는 IP로 변경해야한다.

스크롤을 내리다 보면 웹 서버 호스트의 메모리에 남아있는 로그인 정보가 나타난다.

 따라서 HTTPS 통신시 통신 내용이 암호화되기 때문에 데이터가 노출되지 않는게 정상이지만 하트블리드 취약점이 존재한다면 데이터가 노출된다.

사용자가 웹 애플리케이션으로 전달되는 XML 데이터를 직접 업로드하거나 변조할 수 있는 경우, 공격자는 외부 엔티티를 참조하는 XML 데이터를 전송하여 파일과 같은 서버 내부의 정보를 탈취하거나 서비스 거부 공격, SSRF 등의 공격을 수행할 수 있다.

XML 외부 엔티티는 다음과 같은 형태로 선언된다. 

<!DOCTYPE foo [

<!ENTITY XXE SYSTEM "file:///etc/passwd">

]>

DOCTYPE 선언을 한 후 ENTITY 태그를 이용하여 xxe라는 외부 엔티티를 선언한다. 선언된 외부 엔티티는 XML 내부에서 참조할 수 있다. 즉, XXE 엔티티를 참조하면, XXE의 값인 SYSTEM 키워드로 지정된 /etc/passwd 파일을 참조하게 된다. 위 예시는 file://을 사용하여 호스트 내부의 파일을 참조하지만 http://를 사용하여 외부 리소스를 참조할 수 있다.

A7 그룹의 XXE 메뉴를 선택한다.

Any bugs? 버튼을 누르고 요청 메시지를 버프스위트로 본다.

요청 메시지를 보면 Content-type이 text/xml이다. 즉, xml 데이터를 보낸다. 또한 post 메시지의 바디부분의 bee 문자열이 응답 메시지에서도 사용되고 있다. 전송한 xml 데이터가 사용되고 있는 것이다.

버프스위트의 리피터 기능을 이용하여 xml 데이터를 아래와 같이 변경하여 전송한다.

/etc/passwd 파일을 지정하는 외부 엔티티 XXE 를 선언하고 <login> 태그의 값으로 XXE 외부 엔티티를 참조함으로써, /etc/passwd 파일이 노출된다.

XXE 공격 대응

외부 엔티티 참조 기능이 필요하지 않은 경우 관련 설정을 비활성화하는 것이다. 설정을 비활성화하는 방법은 프로그래밍 언어나 XML 파서의 종류에 따라 다르다. 

인증 : 신원을 확인하는 과정

인가 : 인증된 사용자의 권한을 확인하는 것

접근 통제 : 인증과 인가를 거친 후 리소스에 대한 접근을 허용하거나 차단하는 과정

IDOR 공격(안전하지 않은 직접 객체 참조)

Insecure Direct Object Reference의 약자로 공격자가 요청 메시지의 URL이나 파라미터를 변경하여 정상적으로는 허용되지 않은 기능을 실행하거나 다른 사용자의 리소스에 접근할 수 있는 공격

A4 그룹의 Insecure DOR (Order Tickets) 메뉴에 접속해보자

Confirm 클릭시 전송되는 요청의 형태를 버프스위트로 보면 quantity, price가 보인다. 

quantity는 100, price는 0으로 수정하여 요청을 전송한다.

결과적으로 100개의 티켓을 0원으로 주문할 수 있다.

관리자 페이지 인증 우회

종종 관리자 페이지는 admin, admin.php, admin.jsp 등과 같은 URL로 되어 있어 쉽게 추측할 수 있는 경우가 많다. 

manager, system 등의 URL로 되어 있을 수도 있다. 이는 DirBuster 같은 자동화 툴을 이용하여 숨겨진 URL을 쉽게 찾을 수 있다.

bWAPP의 관리자 페이지는 로그인 없이 접속가능하다. bee/bug로 로그인 가능함을 알 수 있다.

디렉터리 트래버설 취약점 공격

경로를 입력받는 파라미터가 존재하는 경우 파일의 경로를 조작하여 개발자가 의도하지 않은 경로에 있는 파일에 접근하는 공격이다. 주로 ../ 형태로 많이 사용한다.

A7 그룹의 Directory Traversal - Files 메뉴에 접속하자.

page 인자에 message.txt가 전달된다. 이 값을 ../를 이용하여 /etc/passwd 파일에 접근한다.

접근 통제 취약점 공격 대응 방안

1. IDOR 공격 대응

웹 애플리케이션은 사용자로부터 전달되는 모든 입력값을 검증해야한다.

2. 관리자 페이지 우회 공격 대응

admin과 같이 쉽게 추측할 수 있는 디렉터리를 사용하는 것을 지양한다.

관리자 인터페이스를 별도의 포트 번호에서 제공한다.

관리자 메뉴는 HTTPS 프로토콜을 이용하도록 구현한다.

특정 IP 범위를 지정하여, 범위에 속하는 IP만 관리자 메뉴에 접근할 수 있도록 한다.

3. 디렉터리 트래버설 공격 대응

화이트 리스트 방식의 입력값 검증을 수행한다.

블랙리스트 방식을 사용할 경우, ../와 http:// 같은 문자열을 차단해야한다.

평문 패스워드 노출

A6 Text Files(Accounts)에서 사용자를 등록한다.

Download를 클릭하면 사용자들의 정보가 나온다.

Base64 인코딩

Base64 인코딩은 각각 8비트로 구성된 3개의 바이트를 6비트씩 4개로 나누어 변환하는 방식이다. 6비트 단위로 나누어 각 6비트를 10진수로 변환하고 Base64 테이블을 이용하여 변환한다. 디코딩은 반대로 하면된다.

온라인과 버프스위트에 Base64 인코딩, 디코딩 기능이 있다.

A6 Base64 Encoding (Secret)에 접속하자.

참고로 %2F는 URL 인코딩한 값이며 원래는 '/' 문자이다.

이를 버프스위트나 온라인상에서 디코더를 이용하여 값을 구하면 시크릿의 값이 나온다.

민감한 데이터 노출 대응 방안

1. HTTPS 프로토콜

HTTPS 프로토콜은 암호화 통신을 수행하기에 데이터들이 암호화되어 전달된다.

2. 웹 스토리지 보호

로컬 스토리지에 민감한 데이터를 저장하지 않는다. 민감한 데이터를 클라이언트로부터 전달받아야 하는 경우, 쿠키를 통해 전달하도록 하고 해당 쿠키에 HttpOnly 플래그를 추가한다. 이로써 자바스크립트로 쿠키에 접근하지 못하게 할 수 있다. XSS 취약점이 발견되어도 데이터를 보호할 수 있다.

3. 검증된 암호화 사용

민감한 데이터는 암호화하여 저장한다. 안전한 암호화 알고리즘을 적용하여 저장하면 데이터가 노출되어도 복호화할 수 없기 때문이다. 

웹 스토리지를 통한 데이터 노출

웹 스토리지는 HTML5부터 등장한 기술이다. 쿠키를 대체할 수 있다.

웹 스토리지는 세션 스토리지와 로컬 스토리지로 구분할 수 있다.

세션 스토리지는 세션이 종료되면 데이터도 삭제되지만 로컬 스토리지는 삭제 요청을 하기 전까지 데이터가 계속 남아있다. 

로컬 스토리지에 저장된 데이터를 크로스 사이트 스크립팅을 이용해 알아내보자.

A6 그룹에 있는 HTML5 Web Storage (Secret) 메뉴에 접속한다.

개발자도구의 Storage 탭에 접속하면 바로 볼 수 있다. 이제 XSS를 이용하여 접근해보자.

해당 페이지는 XSS 취약점이 있다. First name 칸에 아래의 스크립트를 입력하면 secret에 해당하는 값이 나온다.

<script>alert('secret: ' + localStorage.getItem('secret'))</script>

 HTTP 프로토콜에 의한 노출

HTTP 통신은 80번 포트를 사용하며 평문으로 데이터가 전송된다. 따라서 네트워크 스니핑에 취약하다. 

네트워크 스니핑 프로그램은 대표적으로 tcpdump와 wireshark가 있다.

-n : IP주소나 포트 숫자를 호스트 네임이나 서비스이름으로 변경하지 않고 숫자 그대로 표시

-i : 인터페이스 지정

-A : 아스키 문자열로 출력

-s <숫자> : 출력할 내용의 길이 지정. 0은 제한없음 의미

tcp 통신과 80번 포트에 대해서 출력

로그인을 시도하면 입력한 값이 나타난다. 참고로 bWAPP이 실행되는 호스트의 IP는 192.168.56.104이다.

login과 password 파라미터에 입력한 값인 bee와 bug가 각각 전달되고 있음을 알 수 있다.