Day 5/100 Hack and Improvement

Day 4 from #100daysofhackandimprove comes with an explanation about the common vulnerability, but a with certain level of complexity called Cross Site Scripting (XSS). Besides Cross Site Scripting, and more types of SSRF escalation attacks.

Cross Site Scripting (XSS)

From Sam (CoffeeJunkie), to describe the impact of Cross Site Scripting (XSS), the Sammy Worm is a good example where Kamkar stored a JavaScript payload on his profile. This payload had a lot of effects such as whenever a logged-in user would visit his Myspace profile, the payload code would execute, making the viewer Kamkar’s friend on Myspace and updating the viewer’s profile to display the text “but most of all, samy is my hero.” Then the code would copy itself to the viewer’s profile and continue infecting other Myspace user pages. This kind of attack happens when websites render certain characters unsanitized, causing browsers to execute malicious JavaScript. Some of the most common characters that allow XSS are ", ', <, >. If some of these characters doesn’t change the output that the website provides, might be because they’re being rendered as HTML encode characters. In this case it will display as the following:

double quote (") as " or "
single quote (') as ' or '
opening angle bracket (<) as &lt; or &#60;
closing angle bracket (>) as &gt; or &#62;

If the website doesn’t sanitize angle brackets, it is possible to change the HTML structure of the webpage. This is an example of a basic XSS payload.

<script>alert(document.domain);</script>

What the payload from above will do, will be execute as JavaScript, there will be a pop up with the name of the current domain. Remember that if you’re submitting this vulnerabilities to a report, the idea is to show impact on how you can use the XSS attack, or even escalate the attack. Also remember that the impact of the XSS will depend of the place where you find the vulnerability. It might depend if the website is using httponly flags, or not. This httponly flags will not allow to the attacker to steal cookies, but if the flag is not set, the attacker can steal the victim’s cookies. Also, if the site is vulnerable to this attack, try to understand what kind of cookies the site is using. For example, the attack would have more impact if the attacker is able to steal sensitive cookies as well.

Security Mechanism

The JavaScript is rendered harmless because browsers implement a Same Origin Policy (SOP) as a security mechanism. The SOP restricts how the document can interact with sources loaded from another origin, because the SOP protects innocent websites from malicious sources that attempt to exploit the website from the user’s side.

Payload Explanation

Example#1

Not always might be possible to inject HTML tags as a form of payload. It’s necessary to understand the website and how it works in order to make the payloads work. Let’s get to the following example to understand how important is to understand how the website works in order to create a good payload.

<input type="text" name="username" value="hacker" width=50px>

By injecting a double quote in the value attribute, you could close the existing quote and inject a malicious XSS payload into the tag. You might do this by changing the value attribute to hacker” onfocus=alert(document.cookie) autofocus “, this would achieve the following.

<input type="text" name="username" value="hacker"
 onfocus=alert(document.cookie) autofocus "" width=50px>

From the example showed above, the payload that has been injected is “hacker" onfocus=alert(document.cookie) autofocus ”. which is intended to execute javascript in the website.

Example #2

Let’s say you find a variable within a <script>tag. You can inject a closing script tag </script> and inject your own payload.

# Before payload
<script>
    var name = 'hacker';
# After payload
<script>
    var name = 'hacker';alert(document.cookie);'';
</script>

Types of XSS

The main types of XSS are reflected and stored XSS.

Reflected XSS

Reflected XSS occurs when a single HTTP request that isn’t stored anywhere on the site delivers and executes the XSS payload. Nowadays, browsers are made to prevent this kind of attacks. Therefore, when an XSS attempt occurs, the browser shows a broken page with a message related to the protection of the users.

Developers do their best efforts to protect browsers agains this kind of attacks. But, there is always a way to bypass the protection, because JavaScript can be executed in multiple ways. File Descriptor has a great explanation about it. Also, in case if you need (which you will) Masato Kinugawa has a pretty good filter bypass cheat sheet.

Stored XSS

Occurs when a site saves a malicious payload and renders it unsanitized. The payload might not execute immediately after submission, but it could execute when another page is accessed. There are other subcategories of XSS attacks such as DOM-based and blind.

DOM-Based XSS

DOM-based XSS attacks involve manipulating a website’s existing JavaScript code to execute malicious JavaScript; it can be either stored or reflected.

Blind XSS

DOM-based XSS attacks involve manipulating a website’s existing JavaScript code to execute malicious JavaScript; it can be either stored or reflected. In order to track this kind of attacks the tool XSS hunter will be useful.

Write Ups and Explanations

SHOPIFY WHOLESALE

The attacker sent the following payload in the URL

# Decoded URL
https://wholesale.shopify.com/asd';alert('XSS');'
# Encoded URL
https://wholesale.shopify.com/asd%27%3Balert%28%27XSS%27%29%3B%27

The payload was ';alert('XSS');' . Look how the attacker didn’t have the need to insert HTML tags in order to make the attack successful. Remember to look how the website sanitized the input.

SHOPIFY CURRENCY FORMATTING

The attacker had the chance to act as an administrator where he had the chance to manipulate the HTML of the website. He introduced the following payloads.

Therefore, when the victim was trying to get access to the store, a pop up displaying the name of the domain will appear.

YAHOO! MAIL STORED XSS

The attacker achieved to bypass the HTML filters in the emails. Also, the attacker had the chance to manipulate the HTML values by injecting the following payload.

<img ismap='xxx' itemtype='yyy style=width:100%;height:100%;position:fixed;left:0px;top:0px; onmouseover=alert(/XSS/)//'>

This is the video from the attacker with a clear explanation.

GOOGLE IMAGE SEARCH

The attacker while trying to change his picture in hacker one he found the following URL in Google search.

http://www.google.com.eg/imgres?imgurl=https://lh3.googleusercontent.com/-jb45vwjUS6Q/Um0zjoyU8oI/AAAAAAAAACw/qKwGgi6q07s/w426-h425/Skipper-LIKE-A-BOSS-XD-fans-of-pom-29858033-795-634.png&imgrefurl=https://plus.google.com/103620070950422848649&h=425&w=426&tbnid=ForZveNKPzwSQM:&docid=OEafHRc2DBa9eM&itg=1&ei=9ID8VZufMYqwUfSBhKgL&tbm=isch 

Something that attracted his attention was the parameter imgurl with the href attribute <a>. Therefore he went to triage the vulnerability with the following payload: “javascript:alert(1)”.

http://www.google.com.eg/url?sa=i&source=imgres&cd=&ved=0CAYQjBwwAGoVChMIjsP-48OByAIVxNMUCh3pSQ98&url=javascript:alert(1)&psig=AFQjCNGcADmmDJe6-BWjcDAJ1pV84euDZw&ust=1442698210302078

This video explains the attack process.

SSRF to read Internal Files and AWS Metadata

Rajesh Ranjan, There may a possible where we can read the internal files using SSRF. Suppose the example.com is vulnerable by SSRF, and this look like:

https://example.com/service.php?url= 

So, you can put the payload in “url=” parameter, and the final URL will look something like:

https://example.com/index.php?url=file:///etc/passwd

Now this can be escalate this further to read the AWS EC2 metadata if the application is using the AWS services. To do that, suppose the application is running its AWS services on 169.254.169.254, then we can craft a malicious URL as:

169.254.169.254/latest/meta-data

And, now replace the url parameter with this, so the final crafted URI will be:

https://example.com/index.php?url=169.254.169.254/latest/meta-data

Now to read the Access key ID, secret key, we can use the following payload will be:

https://example.com/index.php?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanorastalk-ec2-role

Blogs Related to SSRF Escalation

1. https://www.notsosecure.com/exploiting-ssrf-in-aws-elastic-beanstalk/
2. https://medium.com/bugbountywriteup/from-ssrf-to-aws-credentials-disclosure-64c51e1bf5dc

Reports Gathered from HackerOne

1. https://hackerone.com/reports/508459
2. https://hackerone.com/reports/53088