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 < or <
closing angle bracket (>) as > or >
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
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.
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.
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.
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
- https://www.notsosecure.com/exploiting-ssrf-in-aws-elastic-beanstalk/
- https://medium.com/bugbountywriteup/from-ssrf-to-aws-credentials-disclosure-64c51e1bf5dc
Reports Gathered from HackerOne
- https://hackerone.com/reports/508459
- https://hackerone.com/reports/53088
Leave a comment