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:
- Capture the victims authentication traffic when they login with the Receiver app.
- Extract the username and encoded password from the POST request to enum.aspx (shown below).
POST /Citrix/XDPNAgent/enum.aspx HTTP/1.1Content-Type: application/x-www-form-urlencodedUser-Agent: C:\PROGRA~1\Citrix\ICACLI~1\PNAMain.exeHost: xxx.xxx.xxx.xxxContent-Length: 705Connection: Keep-AliveCache-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>
- 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.
- Open the Receiver app and log in with the username and a blank password.
- Burp will then intercept the POST request that looks like above.
- 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.
- Voila! Now you are logged into the Receiver app as the victim. Now you can launch whatever virtual desktop is associated to that user.
- 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.
- Open Internet Explorer and prep the configuration to not use any proxy, but don't click OK yet.
- Click on a virtual desktop through the Receiver to launch it.
- Burp will then intercept the authentication request to launch.aspx. Paste the encoded password into the "Password" XML field again.
- 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.
- 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...