Cross Site Scripting (XSS) to Meterpreter
Hello Guys, Today we are going to learn about how we can exploit Cross Site Scripting (XSS) vulnerability and gain access over client’s system via meterpreter. Sounds weird?? Let’s have a look of it. Before proceeding, we need to learn following topics and tools.
What is Cross Site Scripting (XSS)?
Types of XSS
Stored XSS: The most damaging type of XSS is Stored (Persistent) XSS. Stored XSS attacks involves an attacker injecting a script (referred to as the payload) that is permanently stored (persisted) on the target application (for instance within a database). The classic example of stored XSS is a malicious script inserted by an attacker in a comment field on a blog or in a forum post.
When a victim navigates to the affected web page in a browser, the XSS payload will be served as part of the web page (just like a legitimate comment would). This means that victims will inadvertently end-up executing the malicious script once the page is viewed in a browser.
We will be exploiting Stored or persistent XSS for this demo but other two types can be exploited as well.
Reflected XSS: In Reflected XSS, the attacker’s payload script has to be part of the request which is sent to the web server and reflected back in such a way that the HTTP response includes the payload from the HTTP request. Using Phishing emails and other social engineering techniques, the attacker lures the victim to inadvertently make a request to the server which contains the XSS payload and ends-up executing the script that gets reflected and executed inside the browser. Since Reflected XSS isn’t a persistent attack, the attacker needs to deliver the payload to each victim – social networks are often conveniently used for the dissemination of Reflected XSS attacks.
DOM-based XSS: DOM-based XSS is an advanced type of XSS attack which is made possible when the web application’s client side scripts write user provided data to the Document Object Model (DOM). The data is subsequently read from the DOM by the web application and outputted to the browser. If the data is incorrectly handled, an attacker can inject a payload, which will be stored as part of the DOM and executed when the data is read back from the DOM.
- Victim IP: 192.168.0.103
- Victim OS: Windows XP
- Victim Browser: Internet Explorer 6.0
- Vulnerable Web App: Damn Vulnerable Web Application (DVWA)
- Attacker IP: 192.168.0.104
- Attacker OS: BackBox 4.7 [BeEf and Metasploit installed]
BeEF: Beef is the short form of Browser Exploitation Framework. This is the core of our exploit. BeEF can be used to “safely” exploit Web and browser-based vulnerabilities like cross-site scripting (XSS) using client-side attack vectors. If a user clicks on a link that BeEf put there, it will hook the user’s browser into the BeEF server. Then by using different module within BeEF we can perform various malicious activities like phising, stealing password, detecting browser components, make victim’s browser to download any malicious file etc.
Metasploit: Don’t know really how to describe metasploit, many security researchers, pen testers, many blogs, sites are there to make you understand what is metasploit and what are the functionality of metasploit. So I don’t want to describe metasploit within this small paragraph. In one words, without metasploit its very tough job as penetration tester. It is basically a exploitation framework but we can use metasploit for exploit development, Anti Virus evasion, Malicious file generator and many more. You should know metasploit very well if you want to be in cyber security field.
Damn Vulnerable Web Application (DVWA): This Damn Vulnerable Web App (DVWA) is a PHP/MySQL web application that is damn vulnerable. Its main goals are to be an aid for security professionals to test their skills and tools in a legal environment, help web developers better understand the processes of securing web applications and aid teachers/students to teach/learn web application security in a class room environment. In our demo we use “Stored XSS” segment.
- Attacker found a site that is having stored cross site scripting vulnerability.
- Attacker configures BeEF in his system and generate a link that will hook victims browser whenever the link will be clicked.
- When victim opens the vulnerable page, the injected link will be triggered and victim’s browser will be hooked by BeEF.
- Attacker chooses any browser dependent vulnerability within metasploit where a link will be generated and should be clicked by the user for successful exploitation.
- Via BeEF module, Attacker will create an invisible iFrame with metasploit generated link and execute that within victim’s hooked browser wintout victim’s interaction.
- if all things go right, we will have access of victim’s system.
NOTE: if you found it complicated then don’t worry. Follow the following steps.
- DVWA has been installed within 192.168.0.103 machine. From attacker machine it can be accessed via browser. If you installed DVWA for the first time, Default user and password is admin:password.
- BeEF has been already installed within BackBox . It resides within the following menu list.
- While clicking BeEF, it has been started with command line.
- The above picture shows that hookable URL is : http://192.168.0.104:3000/hook.js It means attacker has to use this link as a payload of XSS
- Now its Time to login into BeEF by using : http://127.0.0.1:3000/ui/panel
- Default login credential for BeEF is beef:beef
- There is two options in BeEF. One is Online browser and other one is Offline Browser. Online Browser indicates those hooked browsers which are online and Offline indicates those hooked one which are not active. As our XSS payload has not been built yet so there is no browser listed over here.
- Now we are done as an attacker. While victim open that page in internet explorer of his/her machine, victim’s hooked browser will be seen in BeEF “Online Browser”. Note that DVWA security should be “Low” at victim’s end.
- Whenever attacker found his target in “Online Browser”, his/her next move will be trigger any exploit which is browser dependent. Browser dependent exploits are those exploits where metasploit gives an URL and attackers have to convince the victim to open the URL in victim’s browser. Instead of convincing victim to open the Malicious URL, BeEF gives option to attacker to execute the URL as iframe. There are lots of exploits available within metasploit regarding browser. Among them Attacker chooses : exploit/windows/browser/ms10_002_aurora
- There are lots of modules and submodules in BeEF. Among them “Create Invisible iframe” is the one. But my recommendation is to try different modules as well for testing. Each module has different functionalities. Try to explore them.
- After successful execution of iframe with our metasploit generated payload, our metasploit terminal shows that attacker has penetrated into the victim’s system.