⌘

Upgrade self XSS to Exploitable XSS an 3 Ways Technic

hahwul

오늘은 Self-XSS를 유효한 XSS로 업그레이드 하는 방법 3가지에 대해 이야기 할까 합니다.

Self XSS

공격자가 피해자인 XSS입니다. 즉 본인만 볼 수 있는 페이지의 XSS이며, 보통 버그바운티에선 영향없는건으로 리워드 대상이 아닙니다. 기업보안 입장에선 당연히 같이 체크해야하는 부분이구요.

XSS Vulnerable to Only Me. Generally speaking, both attackers and victims are the same, i.e. XSS, which does not affect other users.

POST /me/save_profile

name=<svg/onload=alert(45)>

Fire on /me/profile

Technic1 :: Self XSS + CSRF(Stored) (aka, XSRF?)

self XSS를 영향있게 만드는 방법중 하나가 stored 되는 부분에 대한 CSRF 입니다. 결국 CSRF로 피해자의 로그인 세션에서 XSS 코드를 저장하고, 저장된 페이지를 강제로 호출시켜 XSS 코드를 동작시킵니다.

One of the ways to influence self XSS is the CSRF of the stored function from XSS Vulnerable page. The CSRF stores the XSS code from use victim’s login session and forces the saved page to execute the XSS code.

<form action="~/me/save_profile" method="post" target="_blank" id="ff">
  <input type="hidden" name="name" value="<svg/onload=alert(45)>">
</form>

<script>document.getElementsById('ff').submit;document.location.href='~/me/profile'</script>

Technic2 :: Self XSS + Login CSRF

두번째는 login csrf를 이용한 방법입니다. 이부분은 사실 잘 몰랐던 부분인데, 최근 m0z(@LooseSecurity)와 Jenish(@_jensec)와의 대화로 새로 알아간 부분이네요.

*Second, Login csrf. I didn’t really know this part, but I just recently got to know this part of my conversation with m0z(@LooseSecurity) and Jenish(@_jensec)

Login CSRF는 공격자의 ID/PW로 로그인하는 CSRF입니다.

여기서, 궁금한점이 생기는데 공격자의 세션인데 뭐가 문제인지? 라는 물음이 생깁니다. 저 또한 이 부분때문에 Login CSRF라는 개념 자체를 부정하고 있었구요. (왜냐면 영향 없다고 생각해서..)

재미있는점은, 로그인된 사용자에게 공격자의 계정으로 로그인했을 때 일부 서브 도메인은 피해자의 세션을 들고있다는 점입니다. 이를 이용하면 공격자의 피해자의 정보를 탈취할 수 있습니다. (보통 신뢰받는 서브 도메인간은 SOP나 CSP등의 정책이 약한 상태죠.)

The question here is what kind of threats an attacker’s session poses. I didn’t even think about this because I thought there was no risk because it was an attacker’s session. What’s interesting is that some subdomains are victims’ sessions when logged in as an attacker’s account. This can be used to steal information from an attacker’s victim.

Attacker test accounts

  • id: test
  • pw: test111

Login csrf(preset)

<form action="~/me/save_profile" method="post" target="_blank" id="ff">
  <input type="hidden" name="name" value="<svg/onload=alert(45)>">
</form>

<script>document.getElementsById('ff').submit;document.location.href='~/me/profile'</script>

Send login csrf to the victim

<form action="/login" method="post">
  <input type="hidden" name="id" value="test">
  <input type="hidden" name="id" value="test111>">
</form>

Flow 1) Save self-XSS(Attacker) 2) Login CSRF(Victim) 3) Fire Self-XSS on Attacker Sessions(Victim) 4) Leak Subdomain Credential(Victim)

Technic3 :: XSS Jacking (with Click jacking)

사용자가 공격코드를 붙여넣게 만드는 방법입니다. 사실 잘 안할법하긴한데, 화면 구성을 잘하면 가능할수도 있습니다. 그리고 보통 사회공학기법을 생각하는데, 뛰어난 페이지 디자인과 몇가지 트릭이면 충분히 낚을 수 있습니다.

Finally, XSS Jacking(Click Jacking). With a few tricks and a well-crafted page design, you can catch a victim. You can use event handlers such as oncopy to intercept and replace a user’s action. Please look at the code below.

oncopy 등의 이벤트 핸들러를 이용해서 사용자가 한 액션을 가로채어 바꿀 수 있습니다. 아래 시나리오는 피해자에게 Captcha로 보이는 페이지를 주고 공격자가 의도한 문자열을 복사하고 전송하게 합니다. 피해자는 임의의 수로 보이는 데이터를 카피하지만, 실제론 해당 데이터와 함께 XSS코드가 삽입되며 취약 페이지의 UI 구성으로 인해 공격 코드는 보이지 않습니다.

This scenario is gives the victim a page that appears to be Captcha and allows the attacker to copy and transmit the intended string. Victims copy what appears to be random numbers of data, but the XSS code is inserted with the data and the attack code is not visible due to UI configuration on the vulnerable page. (but my design wasn’t great. just… just take it in.)

attacker.html

<script>
    document.addEventListener('copy', function(e){
        console.log("gg")
        e.clipboardData.setData('text/plain', '\x3cscript\x3ealert(45)\x3c/script\x3e                                           9e107d9d654654654qsdfa65s4da65s4f372bb6826bd81d3542a419d6');
        e.preventDefault();
    });
    console.log("inited")
</script>

<img src="http://clipart-library.com/images/6cyog8Azi.png" width="100px">
<h2>If you not robot?</h2>
&nbsp;&nbsp;<input type="text" width="100%" value="9e107d9d654654654qsdfa65s4da65s4f372bb6826bd81d3542a419d6"><br>
<iframe src="./vuln.html" style="border:none">

vuln.html

<input id="up"  type="text" value=""><input type="button" value="confirm" onclick="alert(document.getElementById('up').value)">

스크립트 실행전에 취약 페이지의 input에선 스크립트 코드가 보이지 않습니다.

다만 이 방법을 트리거하기 위해선 Click Jacking과 마찬가지로 iframe에 대한 보호 정책이 없거나 우회되야 합니다.

For trigger this method, the protection policy for the iframe must be missing or bypassed, as with Click Jacking. Thank you :)

#security