'Hacking/Web'에 해당되는 글 94건

본 글은 blackhat.com에서 공개한 LDAP Injection & Blind LDAP Injection을 번역&정리한 것입니다.

생략된 부분이 많기 때문에, 자세히 알기 위하신 분들은 아래 pdf 파일을 참고하시기 바랍니다.

출처 : https://www.blackhat.com/presentations/bh-europe-08/Alonso-Parada/Whitepaper/bh-eu-08-alonso-parada-WP.pdf

1. LDAP 개요

LDAP 필터들은 RFC 4515에 다음과 같이 정의되어 있다. 이러한 필터들의 구조는 다음과 같이 요약될 수 있다 : 

모든 필터는 항상 괄호 안에 있어야하며, 오직 논리와 관계와 관련된 연산자들만 그것들을 구성할 수 있다.

특수한 문자인 "*"은 필터들의 구성에서 하나 혹은 많은 문자들을 대신하여 사용될 수 있다. 

논리연산자를 제외하고, RFC 4256에서 독립적으로 사용할 수 있도록 허용된 두 특수 상수들이 있다 :

 - (&) : 절대 참

 - (|) : 절대 거짓

2. 공통적인 LDAP 환경들

거의 모든 환경에서, LDAP 서비스를 기반으로 한 어플리케이션들은 다음의 목적들 중 하나의 디렉토리를 사용한다.

 - 접근제어(user/password 기반 검증, 사용자 인증거 관리)

 - 권한 관리

 - 자원 관리

3. Web Applications 에서의 LDAP Injection

가장 널리 사용되는 LDAP인 ADAM과 OpenLDAP에서  [1. LDAP 개요] 에서 설명한 LDAP 필터 구조의 구현에 대해 알아보자.

※ (attribute=value) 

 : 만약 쿼리 구조에 논리연산자(OR 또는 AND)가 존재하지 않다면, "value)(injected_filter"와 같은 injection은 두 필터에서 다음과 같은 결과일 것이다 : (attribute=value)(injected_filter) 

 : OpenLDAP에서는 두번째 필터가 무시되어 오직 첫번째 것만 실행될 것이다. 

 : ADAM에서는 두 필터를 가진 쿼리가 허용되지 않는다. 그러므로 injection은 불가능하다.

※ (|(attribute=value)(second_filter)) or (&(attribute=value)(second_filter))

 : 만약 쿼리 구조에 논리연산자(OR 또는 AND)가 존재한다면, "value)(injected_filter)"와 같은 injection은 다음과 같은 결과일 것이다 : (&(attribute=value)(injected_filter))(second_filter))

 : 비록 필터가 심지어 구문적으로 올바르지 않더라도, OpenLDAP은 첫번째 필터가 끝난 이후의 어떠한 문자든 무시를하며 왼쪽에서부터 오른쪽으로 처리를 시작할 것이다.

 : 일부 LDAP Client web components는 두번째 필터를 무시하고 ADAM과 OpenLDAP에 오직 첫번째 완성된 것만 보내어 injection이 허용될 것이다.

몇몇의 어플리케이션 프레임워크들은 그것을 LDAP 서버로 보내기 전에 필터가 올바른지 체크할 것이다. 이러한 경우, 필터들은 구조적으로 올바르게 되어있어야 하므로 injection은 다음과 같이 만들 수 있다 : "value)(injected_filter))(&(1=0"

이것은 결과적으로 두개의 다른 필터를 만들고, 두번째는 무시될 것이다 : (&(attribute=value)(injected_filter))(&(1=0)(second_filter))

두번째 필터가 LDAP Server에서 무시되게 될 경우, 일부 구성요소들은 두 필터를 가진 LDAP query를 허용하지 않을 수 있다. 이러한 경우 단일필터 LDAP query를 얻기 위해서는 특별한 injection이 만들어져야 한다.

injection이 "value)(injected_filter"와 같으면 결과는 다음과 같을 것이다 : (&(attribute=value)(injected_filter)(second_filter)).

이후 상세한 쿼리 및 예제들은 그림과 함께 보는 것이 이해가 빠르므로 출처 PDF를 참고해주시기 바랍니다.

1. 이론

(1) expect://

 : system command 실행 가능

ex) www.test.com?page=expect://ls

(2) php://filter

 : I/O 스트림을 다루는데 사용하는 wrapper로 encode/decode를 이용하여 서버 내 파일을 읽을 수 있다. 대표적으로 base64를 이용한다.

ex) www.test.com?page=php://filter/convert.base64-encode/resource=/etc/passwd

(3) zip://

 : zip:// wrapper는 압축을 풀고 그 안에 있는 파일의 코드를 실행시켜주는 wrapper이다.

ex) www.test.com?page=zip://file.zip#shell.php

2. 실습

(1) test.php 코드

(2) expect wrapper 실습

 - 오류가 떴으며, 검색해본 결과 expect wrapper를 이용하기 위해서는 따로 설치하는 과정이 필요한 것으로 보인다.

 - 기본적으로 설치되어 있지 않는 모듈일 가능성이 커 실제로 이용하기에는 제한적이라 생각들어 여기서 stop

 - 더 진행해보고자 하는 분들은 아래 출처 페이지를 참고하여 설치 후 진행해보길 바란다.

(3) php://filter 실습

 - resource에 지정한 파일이 다음과 같이 base64로 인코딩된 상태로 출력된다.

 - 출력된 base64를 디코딩하면 해당 파일의 내용을 볼 수 있다.

(4) zip:// 실습

 - shell.php 코드

 - zip 명령어 : zip rootable.zip shell.php

 - 해당 wrapper 또한 expect 처럼 세팅이 필요해보인다.

3. 결론

 - php://filter가 짱짱맨이다

 - php://filter의 경우 base64가 유명하여 막힐 가능성이 있으므로, string.rot13으로 암호화하여 진행하는 경우도 생각해놓자

ex) www.test.com?page=php://filter/string.rot13/resource=/etc/passwd

(출처)

https://www.opentutorials.org/module/4291/26819

http://linux-problem-solver.blogspot.com/2014/02/solution-to-installation-of-expect.html

https://www.php.net/manual/en/filters.string.php

JWT에서 signature 생성을 위한 알고리즘에는 대표적으로 RS256와 HS256가 있다. 이 때, RS256은 비대칭 알고리즘이므로 공개키와 개인키가 있는 반면, HS256은 대칭키이므로 하나의 키만을 사용하게 된다. 이에 따라, RS256 JWT 토큰을 HS256으로 변환시켜 권한 상승이 가능한 취약점이 존재한다.

아래부터는 RS256 JWT 토큰을 HS256으로 변환시키는 과정을 단계별로 상세히 작성해보겠다.

그 전에 참고용으로 RS256와 HS256에 대해 알아보도록 하자.

* RS256 : RSA Signature with SHA-256의 줄임말이다. 

* HS256 : HMAC SHA-256의 줄임말이며, 여기서 HMAC이란 keyed-hash message authentication code 혹은 hash-based message authentication code라고 표현할 수 있다.

Step 1. 제공받은 public key (key.pem)을 아래의 명령어를 통해 HEX로 변환해준다.

 (1) /key를 통해 제공받은 public key를 key.pem으로 저장한다. 이 때 인증서 형식에 맞게 저장해야 한다.

(2) xxd는 주어진 파일을 16진수나 2진수 형태로 볼 수 있는 명령어로 -p 옵션을 통해 포맷이 없는 hexdump를 출력해준다.

(3) tr 명령어는 translate의 약어로, 지정한 문자를 바꾸어주거나 삭제하는 명령어다. -d 옵션을 통해 개행 문자를 제거해준다.

(4) 위의 명령어들을 통해 public key를 hexdump한 데이터가 개행문자 없이 출력된다.

Step 2. 이전에 수정한 토큰과 public key를 ASCII hex 형태로 바꾼 것을 통해 HMAC signature를 생성한다.

(1) username을 admin으로 변경한 토큰에서 signature를 제거한 것을 echo를 통해 다음 명령어의 입력으로 넣어주며 이 때 -n 옵션을 통해 개행문자는 제거해준다.

(2) openssl 명령어를 통해 제공받은 토큰을 암호화해줄 것이다. 이 때 dgst를 통해 SHA256 digest로 설정해주고, -mac 옵션을 통해 HMAC 알고리즘을 이용한 MAC(keyed Message Authentication Code)를 생성해 줄 것이며, -macopt 옵션을 이용하여 MAC key를 16진수로 된 키로 지정해준다. 여기서 지정해준 MAC key는 [Step 1]에서 나온 결과물을 입력해준다.

(3) 해당 결과물은 RSA의 공개키를 이용하여 HS256에서 사용할 비밀키를 생성해준 것이다.

Step 3. signature를 HEX에서 base64로 변환해준다.

(1) binascii.a2b_hex 함수를 이용하여 Step2의 결과인 비밀키를 binary 형태의 16진수로 만들어주고 이것을 base64로 변환해준 뒤 signature로 만들어주기 위해 =를 제거해준다.

Step 4. 수정한 payload에 signature를 붙여준다.

참고

- https://github.com/swisskyrepo/PayloadsAllTheThings/tree/74f2dfcccaec7786598a93733ecacadee35c6131/JSON%20Web%20Token

- https://www.it-swarm.asia/ko/jwt/rs256-%eb%8c%80-hs256-%ea%b7%b8-%ec%b0%a8%ec%9d%b4%ec%a0%90%ec%9d%80-%eb%ac%b4%ec%97%87%ec%9e%85%eb%8b%88%ea%b9%8c/826436771/

 - https://en.wikipedia.org/wiki/HMAC

1. open_basedir 지시어란?

 - open_basedir란 설정된 디렉토리 및 하위 디렉토리에서만 파일을 열 수 있도록 제한하는 지시어이다.

 - 상세한 설정 및 이에 따른 설명은 아래 [2. 세팅 방법]에서 다루도록 하겠다.

2. 세팅 방법

 - 필자는 CentOS 6.0 기준으로 작성하였다. 다른 버전의 경우 검색을 통해 알아보길 바란다.

여기서 php_admin_value 옵션은 ini_set() 혹은 set_include_path()와 같은 방법으로 어플리케이션에서 직접적으로 설정 정보를 변경하지 못하도록 하는 옵션이다.

open_basedir로 경로를 설정할 때 : 를 기준으로 여러 디렉토리를 설정해줄 수 있으며 어플리케이션 경로 및 세션 정보와 파일 업로드 시 필요한 tmp 디렉토리만 설정해준다.

이렇게 설정해줄 경우 Directory에 표기된 /var/www/html/test/ 하위에 정의된 파일들은 open_basedir에 설정된 /var/www/html/test 를 벗어나 상위 디렉토리에 접근할 수 없다.

설정 후 httpd service를 restart해주면 적용이 완료된다.

(참고) php.ini에서도 open_basedir 설정이 가능하다.

3. open_basedir 우회

 - 올해 3월달에 @Blaklis_ 라는 분께서 open_basedir이 설정되어있을 때 우회하는 PoC를 공개하였다.

 - 그리고 이에 대한 상세한 설명 및 방법은 shpik 님께서 블로그에 잘 정리해 놓으셨다. 

( https://blog.shpik.kr/2019/PHP_Open_basedir_Bypass/ )

 - 개인적으로 테스트를 해보며 첨언을 하자면 위에 내가 세팅한 방법인 httpd.conf 파일에 세팅하는 경우에는 위의 방법으로 우회가 되지 않는다. 왜냐하면 php_admin_value 옵션이 들어가있기 때문이다. 위의 경우는 php.ini 파일에서 open_basedir을 설정하였을 경우 우회되는 방법이다.

- 추후 관련 CTF가 출제될 수 있으므로 Final payload만 저장해둔다.

※ 참고

 - https://idchowto.com/?p=22531

 - https://ma.ttias.be/php-php_value-vs-php_admin_value-and-the-use-of-php_flag-explained/

데이터베이스에는 MySQL, MSSQL, Oracle이 대표적이지만 안드로이드와 IOS에서 주로 사용되는 SQLite 가 존재한다.

데이터베이스 관련 취약점인 SQL Injection이 해당 데이터베이스에서도 발생되는데 이에 대한 대응방안을 찾아보았다.

PERL이나 PHP같은 스크립팅 언어에서는 쿼리를 종료하는 모든 문자열에 대해 다룰 수 있다. PHP 언어의 경우 SQLite에 특별한 입력 문자열에 대해 다루는 sqlite_escape_string()이라는 함수를 제공해준다.

아래는 해당 함수를 사용하는 예시이다.

나의 경우 해당 함수를 사용하였는데 다음과 같은 에러가 발생하였다.

왜 그런지 알아보았는데 결론은 테스트 환경인 CentOS의 문제였다.

동일한 에러가 발생한다면 아래 Step대로 진행하면 해결될 것이다.

아래 php-5.X.X.tar.gz 부분은 버전정보를 입력하면 된다. ( "php -v" 명령어를 통해 확인 가능 )

* 만약 진행하다가 phpize 명령어가 안된다면 다음 명령어를 통해 php-devel를 설치 

참고 )

 - https://www.tutorialspoint.com/sqlite/sqlite_injection.htm

 - https://www.php.net/manual/en/function.sqlite-escape-string.php

 - https://www.serveradminblog.com/2013/07/centos-5-call-to-undefined-function-sqlite_escape_string/

 - https://medium.com/@a.m./solved-phpize-command-not-found-in-centos-6-4-6ee253419053

1. HTTP 인증 설정

 (1) /etc/apache2/apache2.conf 내 AllowOverride를 None에서 AuthConfig 수정

 (2) [htpasswd -cb .htpasswd (아이디) (패스워드)] 명령어를 통해 .htpasswd 파일 생성

 (3) .htaccess 파일에 아래와 같이 입력

2. HTTP 인증 우회

 - 설정을 완료할 경우 아래와 같이 해당 디렉토리 내의 파일에 접근할 경우 로그인을 진행해야 한다.

 - 하지만 아래와 같이 지정되어있는 메소드가 아닌 Method로 요청을 보내면 인증을 우회하여 접근 불가능한 페이지에 접근이 가능하다.

3. 대응방안

 - /etc/apache2/apache2.conf 내 AllowOverride를 AuthConfig에서 All로 변경 (이후 service apache2 reload)

 - .htaccess 파일 내 아래의 내용을 추가해준다. 그 결과 GET과 POST를 제외한 다른 메소드의 경우 접근이 제한되어 Forbidden이 된다.

※ 에러 체크

만약 htaccess 설정하였는데 500 Internal Server Error가 뜰 경우는 apache2.conf의 AllowOverride가 수정되지 않았기 때문이다. All로 변경한 뒤 apache2 서비스를 reload해주어야 정상적으로 작동한다.

※ 참고

- https://httpd.apache.org/docs/2.4/mod/overrides.html