접속하면 소스코드 준다. 근데 github 링크도 줘서 들가보면 문제 아카이빙 되어있는데 아마 정황상 실제 ctf에 출제됐을 당시엔 app.py의 소스코드만 공개되어있던것 같다. (이유는 뒤에 가면 나옴)

 

 

코드오디팅이야 각자 문제 코드 보시고, 중요한 부분만 살펴보면.

 

Exec 함수가 실제 사용자의 input action에 따라 동작을 수행하는 곳이다.

 

특이하게 살펴볼 곳은, if 'scan' in self.action과 if 'read' in self.action이 elif로 묶인게아니라 별도로 if로 되어있는것, 그리고 action을 ==이나 ===으로 일치를 보는게 아니라 'in' 키워드로 문자열에 속하는지를 통해 검증하는것이다.

 

위 코드는 sign값을 만들어내어 유저에게 전달해주는 함수이다. 코드 상 self.action은 scan으로 고정되어있기때문에 read action에 대한 sign값은 os.urandom(16)으로 정해진 secret_key로 해싱하기 때문에 예측할 수 없다. (현재로서는)

 

실제 sign을 만들어내는 함수로써, user input인 action과 param을 받아 secret_key와 더하여 md5 해싱한다.

여기서 주목할 점은 본래 argument가 action, param순으로 되어있는데 구욷이 key+param+action 순으로 더하여 해싱한다는 것이다. (나름의 힌트가 아니었을까)

 

뭐 앞단의 검증들이 끝나면 urllib.urlopen으로 param값을 넘기는 전형적인 ssrf형태의 코드가 나온다.

 

또 뭐 앞에 waf라고 해서 file이랑 gopher 스키마를 막는 구문이 있긴한데 이건 그냥 urllib.urlopen('/etc/passwd')로 하면 바로 파일 접근이 가능하기에 쉽게 우회될 수 있따.

 


 

그럼 이제부터 어떻게 풀어나갈지 한번 살펴보자

 

특이점

1. if elif가 아닌 if if로 되어있음 (앞의 if문이 충족해도 뒤의 if문까지 실행됨)

2. ==, ===가 아닌 in 키워드로 action 값 검증

3. key+param+action 순서의 md5 해싱

4. 굳이 md5로 해싱?

 

이를 살펴보면, 우리가 만약

 

1. 'scanread' 형식으로 action을 준다면?

 - if if로 되어있기 때문에 in 키워드를 if 'scan' in action과 if 'read' in action 조건을 둘다 만족시켜 read 구문까지 실행될 수 있다.

2. key+param+scan + read 형식의 md5를 예측할수있다면?

 - sign값을 알기 때문에 정상 요청이 가능하다!

 

이 문제를 풀기 전에 codegate 2020 csp 문제를 풀어봤기 때문에 length extension attack에 대하여 알고 있는 상태였따.

 

md5에 대한 length extensio attack을 할 수 있는 툴로는 'HashPump'가 있다.

 

이를 통해 length extension attack을 한다면 우리는 scan과 read를 동시에 하며 ssrf를 통한 lfi(local file include)가 가능해질것이다.

 


 

 

action : scan

param : /etc/passwd

일때 sign 값

 

 

known hash와 data1에 data2를 더했을 때의 예측 md5값과 modified data

 

 

실제 요청 쿼리

 - /etc/passwd가 잘 가져와짐!

 

 

 

이제 여기서부터가 실제 ctf랑 달랐던 부분인데,

 

실제 ctf에선 'flag is in ./flag.txt'가 hint로 나왔나보다.

 

근데 난 flag.sh에서 flag경로가 나와서 ('/app/flag.txt') 그냥 바로 /app/flag.txt를 lfi로 가져왔는데, ctf에선 현재경로의 flag.txt를 구하라고 했다.

 

구하는 방법은, /proc/self/cwd/ 는 현재 실행된 프로세스를 실행한 디렉터리와 링킹되어있다.

 

따라서 /proc/self/cwd/flag.txt 가져오면 ./flag.txt와 동일하게 된다.

 

 

flag get!

냉무

 

앞에서부터 뿌시기로 했으니 쓴다만 이 문제는 쓸 가치도 없다

1 - Hello, glzjin wants a girlfriend

2 - Do you want to be my girlfriend?

 

 

전형적인 blindsqli

 

이외엔 error 뿜는다

 

여러가지 필터링인데 () select from 안막아놨으니 걍 blind sqli 돌리면 됨

 

공백 필터링 되어있는데 %09로 이용가능

 

걍 뚝딱 하면 됨

 

 

갑자기 난이도가 떡락했넹

첨부터 깃헙링크를 준다.

 

코드 오디팅을 해보자.

 

 

대충 코드해석 해보면

1. 내 공인ip md5해서 내 고유 디렉터리 생성

2. 거기에 빈 파일인 index.php 생성 ( /upoad/{md5(myip)}/index.php )

3. 확장자에 ph 나 htacess 가 들어가면 ban

4. 파일 내용에 <? 가 들어가면 ban

5. exif_imagetype이 false이면 ban

6. 유효성 검증이 끝나면 내가 올린 파일명으로 파일 생성

 

 

굳이 index.php를 만드는게 힌트라면 힌트인것 같다.

 

어떻게 업로드하지 고민고민하던중 preg_match에 'htacess'가 들어가면 ban이라는걸 보았다.

 

어라.. .htaccess 인데 htacess... c가 하나 빠졌다

 

아! 필터링 실수를 의도하고 낸 문제구나 하고 .htaccess로 익스하기위해 열과 성을 쏟아부었지만.. 왜인지 안되었다.

 

내 서버에도 똑같이 세팅하고 올려봤는데 내서버에선 웹쉘이 잘 동작하는데 문제서버에선 안되었다,,,

 

 

일단 다른 문제에서도 .htaccess를 업로드하여 문제를 풀어야 할 경우를 대비해 팁을 적어보자면 

 

위 상황에서 필터링을 우회하기 위해선

 

3. 확장자에 ph 나 htacess 가 들어가면 ban

 - .php가 아닌 다른 확장자의 파일을 실행파일로 인식하도록 함

  -> AddType application/x-httpd-php .png

 - htacess라고 잘못 필터링 되어있으므로 .htaccess를 업로드하는데에 아무 문제가 되지 않음

  

4. 파일 내용에 <? 가 들어가면 ban

 - .htaccess 설정을 제어하여 멀티바이트 캐릭터로 인식하도록 할 수 있다.

  -> php_value zend.multibyte 1

  -> php_value zend.detect_unicode 1

  -> 실제 업로드 파일을 <\x00?\x00p\x00h\x00p\x00 ... 중략 ... 이런식으로 멀티바이트 캐릭터로 구성

 

5. exif_imagetype이 false이면 ban

 - exif_imagetype에서 바라보는 image extension들이다.

https://www.php.net/manual/en/function.exif-imagetype.php

 

 - 해당 이미지 타입에 대하여 헤더를 검사하는 방식으로 이미지인지 아닌지를 판단한다.

 - 각 이미지 타입별로 어디까지 이미지 헤더를 검사하는지 (몇 바이트를 검사하는지)는 이미지 타입마다 다르다. 관심있는 분은 직접 해당 소스코드를 찾아봐도 괜찮을 것이다.

 - 찾아보니 쓸만한 이미지헤더론 'GIF89a'와 '\x00\x00\x89'가 있었다

 - 나는 후자인 '\x00\x00\x89' 를 이용하여

 

\x00\x00\x89\x0d\x0a<\x00?\x00p\x00h\x00p\x00 ... 중략 ...

 

이와같은 식으로 멀티바이트 웹쉘을 만들 수 있었다.

 

이를 실제로 내 서버에 htaccess를 적용하였을 때 위와같은 웹쉘 파일을 .png로 실행시키는것이 가능하였다.

 

그래서 다 풀었다고 생각하고 문제서버에 적용했는데 왠걸? 안되는것이다.

 

내가 놓친것이 있을까 하였는데 모르겠어서 라업을 찾아봤따.

 

 

아.. 문제 서버가 nginx로 운영중인것이 힌트였던 것 같다.

 

nginx 서버가 fastcgi 설정이 켜져있을 경우 .htaccess를 통해 서버 설정을 바꾸어 웹쉘을 업로드하는것과 비슷하게 .user.ini 파일을 업로드하여 내 마음대로 동작하게 할 수 있다고 한다.

 

이때 이용하는 설정으론 auto_prepend_file={file} 으로, 해당 옵션이 있으면 include('./header.php')와 비슷한 효과를 낸다.

 

모든 페이지에서 auto_prepend_file로 설정된 파일을 include 하게 되는데, 여기에 웹쉘을 작성하면 되고, 웹쉘은 <script language='php'>system('ls -al /;');</script> 와 같이 실행시킬 수 있다고 한다(신기..)

 

.user.ini

GIF89a=1

auto_prepend_file=a.png

 

a.png

GIF89a=1

<script language="php">system('ls -al');</script>

 

  1. ar9ang3 ar9ang3 2020.02.15 18:02 신고

    중요한 내용을 빼먹었는데, .htaccess를 통한 익스가 안되는 이유는 nginx에서 fasgcgi를 이용하여 요청을 처리하기 때문에 handler(.htaccess)를 거치지 않는것 (?)이라 한다.
    @posix

+ Recent posts