Lucene search
K

hackingcitrix.txt

🗓️ 03 Oct 2002 00:00:00Reported by wirepairType 
packetstorm
 packetstorm
🔗 packetstormsecurity.com👁 40 Views

Explores Citrix security, access handling, and risks related to Remote Desktop protocols.

Code
`Hacking Citrix:  
  
Last Updated: Oct 2nd 9:00PM (Found 'Respond to Broad Cast Packets' to NOT break Ian Viteks scanner,  
so much for that!)  
  
- Oct 1st, 2002 10:36AM (Minor Corrections in Introduction)  
  
- Introduction  
- How Citrix Works  
- Peeling Citrix Back  
- Securing Citrix... Sort of.  
  
.Introduction  
  
Citrix is a Remote Desktop application that is becoming widely popular. It is similar to Microsoft's  
Terminal Services,   
RDP (Remote Desktop Protocol). Unlike Terminal Services, Citrixs' lines of products allow the admini  
strator to specify   
certain applications to be run on the server. This allows them to control which programs they want t  
o allow the end user   
to execute. There exists an interesting gray line for the security of citrix applications due to the  
mixing of both   
citrix technology, and microsoft technology. With an application that allows users remote access to   
not only published   
programs, but remote desktops, a serious threat arises. Microsoft Terminal Services uses RDP, wherea  
s Citrix uses ICA   
(Independent Computing Architecture).   
  
In this paper I will be outlining how citrix works, and how to take advantage of the way citrix hand  
les user access to programs.  
  
Corrections have been provided to me by Brian Madden (Author of Citrix MetaFrame XP: Advanced Techni  
cal Design Guide.)  
Note: I'm not a Citrix Administrator some of the descriptions of the product maybe faulty but this i  
s not the main focus  
of this paper. For corrections please email me at [email protected]  
  
.How Citrix Works  
  
There are multiple solutions that citrix has available and I will list them here.   
  
- Citrix MetaFrame  
Citrix MetaFrame has three different suits in its family; XPs, XPa, and XPe. Each come with a diff  
erent set of tools and  
applications to help the administrator. XPe is fully featured with many different management options  
. XPa and XPe have  
slightly less. For this paper I will be discussing just XPe, but most of these tactics also apply to  
the other versions.  
Citrix uses XML over whatever port you want usually port 80 to begin communication. Citrix listens b  
y default on port   
1494 and must be connected to using the Citrix ICA client which can be downloaded for free from thei  
r web site.   
  
- Citrix NFuse/Citrix Secure Gateway  
Citrix NFuse allows the administrator to lock down applications even further by only allowing conn  
ections in through  
a web browser. NFuse itself sits on IIS 5.0 by default but I have seen papers detailing how to set i  
t up on apache.  
You probably understand the concerns regarding NFuse sitting on IIS by default and we will touch on   
that subject later.  
All communication is done over SSL at 128-bit encryption, IF specified.   
  
A common setup with NFuse for remote access allows the administrator to also implement Citrix Secure  
Gateway. If they  
properly configure NFuse, the remote user should not be able to directly access the Citrix Server it  
self. Instead,   
all connections are filtered through the NFuse server through the Secure Gateway connection. Here's   
a diagram to make this   
a bit easier to understand.  
  
[user]--->[router]--->[firewall]  
| | |  
| | +-[DMZ]-->[Citrix NFuse Server]  
| | | | [Citrix Secure Gateway]  
| +----+ | |  
| +--------------+   
|   
[Citrix Server]   
  
I hope that makes more sense... and you can follow my horrible diagram I probably confused you more.  
  
Now the user does not have a direct connection to the Citrix Server but instead follows through the   
DMZ -> internal network.  
In a configuration with the default NFuse setup (without Secure Gateway) the user first hits the NFu  
se web server, then  
once the published application is established, the user makes a direct connection to the Citrix Serv  
er. You can see the problem  
with this, the user can still *directly* access the Citrix Server and after using the published appl  
ication scanner,  
gather their own list of published applications and then create their own .ica file containing the i  
nformation they  
specify. This also means, if this configuration is for an external network, two holes are punched th  
rough the firewall,  
one for the IIS server *shudder* and one for Citrix. You can scan port 1494 to see if this holds tru  
e.  
  
Citrix MetaFrame usually has a very helpful management console which enables the administrator to se  
t users and publish  
applications with relative ease. A citrix network without NFuse uses Independent Computing Architect  
ure (.ICA) files  
which is a text based document that contains all of the configuration options and settings. These fi  
les are given to   
the end user who, after having the citrix client installed, clicks on the file and automatically con  
nects to the server  
specified in the .ica file.   
  
If NFuse is in use, then these .ICA files are usually not required. A user opens a web browser, goes  
to the NFuse web  
server and logs in using his Domain/NT account. After this is successful the user is given a list of  
applications which  
they may use to access the servers or Citrix Farm.  
  
.Peeling Citrix Back  
There are so many ways to get a remote desktop on a citrix host its impossible for me to know where   
to begin. I imagine   
the first thing people want is remote access so let us begin there. Recently Ian Vitek of ixsecurity  
has released  
some very helpful perl tools. I use these a lot now and I must give him props on them. The tool I us  
e most is  
Citrix published application scanner [you can find these tools at: http://www.cqure.net/itools01.htm  
l].  
This tool enumerates the published applications that are allowed on the remote server. This comes in  
handy when you're   
'knocked out' of the regular login process, such as a script to automatically log a user out. After   
getting a list of   
the published applications, you can then modify your ICA file with the published application informa  
tion. At this point   
you can attempt to brute force login attempts, I personally find backup accounts to be very helpful.  
If you find a 'test'   
account or backup account has a guess able password you're in luck. I find variants of test and citr  
ixtest almost always   
existent.   
  
Note: If the scanner does not work, you can try my tool which attempts to brute force the published   
applications.  
http://sh0dan.org/files/pubappbrute.tar.gz  
  
So lets assume at this point you have access to the citrix server. And lets suppose you are denied l  
ogin, maybe guest  
doesn't have enough privileges to follow through the login process. Now, if you used the citrix appl  
ication scanner  
and gathered a list of applications try this trick. I haven't seen this published and maybe this is   
a citrix flaw  
or maybe its expected. But citrix appears to only look at the [Application Name] in the .ICA file wh  
en verifying which  
application to run. So here is a regular published application file:  
  
[WFClient]  
Version=2  
TcpBrowserAddress=ip.ip.ip.ip  
  
[ApplicationServers]  
word=  
  
[word]  
Address=word  
InitialProgram=#word  
ClientAudio=Off  
Compress=On  
TWIMode=On  
DesiredHRES=800  
DesiredVRES=600  
DesiredColor=4  
TransportDriver=TCP/IP  
WinStationDriver=ICA 3.0  
  
  
So what happens if we modify the InitialProgram from #word to cmd.exe? or explorer.exe? Well, it hap  
pily runs what  
ever application we specify in that field. I've used this tactic numerous times to bypass faulty log  
in processes. Just  
make sure that the application in the brackets and the Address is legitimate otherwise you'll get so  
me interesting  
errors. So now we have a remote command prompt on the citrix server. Or if you like a gui and you de  
cide you  
want this after you run cmd.exe, no problem just type in explorer.exe you'll get a little prompt sta  
ting that  
you are now starting a seamless remote desktop session :). So now you have a desktop. I'd hope at th  
is point you would  
know enough to elevate your privileges so I will not cover that aspect. An interesting note, even wh  
en I logged in as guest  
to a citrix server, I was able to access the Administrative tools. Obviously this is rather alarming  
and to be honest  
I myself was rather surprised. I'd suggest looking at the user accounts to see if you can find more   
accounts that would   
most likely have default/easily guessed passwords. Never underestimate the power of shitty password   
choosing. Just so   
you know you are not *really* administrator, just try changing a password.  
  
So what if they are using NFuse with Citrix Secure Gateway and filtering all traffic through a firew  
all?   
Then you can not modify your .ica file in this aspect. Once again there are multiple ways of getting  
a remote   
desktop. A lot of times citrix administrators have published applications such as office. What a won  
derful piece of   
software. If you have access to excel, look into vbscript macros for starting explorer.exe. Or if y  
our lazy like me,   
just View as Web page. This will open Internet Explorer and allow you to execute C:\winnt\explorer.e  
xe. This trick also   
works for Microsoft Word and I assume other office products. In fact, most programs have a help -> V  
iew online help option.  
So this will also execute Internet Explorer if it is set to the default browser. Another issue is 'w  
inhelp32', most   
programs have this built in, and guess what? You can "Jump to URL." Now you can put cmd.exe on a rem  
ote web server, jump  
to the url and download it. If you have write access your set. Modify your .ica file to execute this  
upon logon and  
you now have your shell.   
  
Here are some other ways of getting a remote desktop, most of these have been submitted to me by Ian  
Vitek so props to him.  
By pressing Ctrl + F1 you are given the Windows Security window. From here you start Task Manager st  
art -> new task ->   
explorer.exe or cmd.exe. Or you can be lazy and just press Ctrl + F3 and you will automatically get   
Task Manager.  
This can be disabled under the Group Policy (Disable Task Manager) so it may not always work. Most   
programs need to access   
files or have a 'Open' option for accessing their filetypes. Under Windows 2000 go to open a file, m  
ove to My Computer,   
here you will get a list of your drives and the servers (if you have access.) Next right click on th  
e drive, and select explore,   
once again we have a seemless desktop. Like I said there is a multitude of ways one can get a remote  
desktop and more importantly   
access to a command prompt.  
  
  
If you compromise a machine that has citrix installed, and you have sufficient privileges, Citrix st  
ores all of its connections  
for the Citrix Program Neighborhood in a well known directory.   
- In NT4 browse to %systemroot%\profiles\username\Application Data\   
- In Win2k browse to C:\Documents and Settings\username\Application Data\  
steal the ICAClient directory and copy it to your %systemroot%\profiles\youruser\Application Data\ o  
r  
C:\Documents and Settings\profiles\youruser\Application Data\ and then open Citrix Program Neighborh  
ood. You'll notice   
all of that users connections. If they are using Citrix chances are they are lazy as well and most l  
ikely cache their   
passwords. Use Revelation or another 'password reveler' and viola you have their password for that   
connection.  
  
Sniffing is yet another concern, dsniff has citrix sniffing capabilities and this may become a real   
problem when  
used in conjunction with arp cache poisoning.   
  
.Securing Citrix  
  
First off I'd like to say good luck. Here are some tips that may help an administrator locking down   
a Citrix Server.  
I spent the last few days attempting to come up with a magical Group Policy for windows that will lo  
ck programs down.  
The goal is to make it so a user may not use any programs which may be used to upload or transfer fi  
les to the citrix host.  
- Securing Externally  
1. Use the NFuse / Citrix Secure Gateway configuration such as the one I displayed earlier in this t  
ext.  
2. Make sure the IIS/Apache server is completely locked down and resides in the DMZ. Require .htacce  
ss  
or NTLM authentication to even access the webroot of the NFuse server.  
3. If possible, require remote users to use SecureID for authentication. This gets pricy so is most   
likely  
not going to be an option for most people.  
4. Use a different browser than Internet Explorer per default. Most applications use the "default br  
owser" for online  
help pages. If you install Netscape and set this as the default browser they will not be able to exe  
cute applications  
such as cmd.exe/explorer.exe.  
5. Make a group and put all remote citrix users in this group. Deny access (using ntfs) to cmd.exe,   
ftp.exe, tftp.exe, rcp.exe, net.exe,  
command.com, iexplorer.exe (if not a published app or required) and any other programs that they may  
execute to transfer files to the   
citrix server. I did not test whether or not disallowing cmd.exe may break login scripts so be sure   
to test this before it is put in to production.  
6. Keep up to date on all patches for your citrix server, If you keep up to date on your patching yo  
u'll not need to worry about  
privilege escalation exploitation.   
7. Since there are ways to bypass the 'default browser' such as winhelp32. You can attempt to set se  
curity settings under  
internet options to restrict to only allow certain web pages. This will hopefully disallow someone f  
rom downloading their  
own cmd.exe.   
8. Although I've not attempted this and it may only work in certain situations. Disallow write acces  
s to the citrix  
server itself. This way they can not upload their own files. This may only be possible to achieve if  
you also disallow  
users mapping their drives to the server. Remember, users can map their drives and run their tools f  
rom their local machine.  
I'm quite sure this runs under the citrix localsystem context, I may be incorrect on this point.  
9. If possible, disallow users from mapping their drives. You can do this via the Citrix Connection   
Configuration  
double click on ica-tcp, select 'client settings.' And select the necessary boxes.  
10. Under Group Policy disable access to TaskMgr.exe.  
  
  
ADDITIONS:  
The following fixes have been provided to me by Brian Madden. One of these fixes will disallow the c  
hanging of the  
InitialProgram. I thank Brian again for bringing these to my attention.   
  
FIX #1 DOES NOT PREVENT THE SCANNER FROM WORKING! Sorry, I should have tested this before I posted..  
. (XPs FR2 was tested)  
1. Disable MetaFrame XP server broadcast response. CMC | Right-click on farm | MetaFrame Settings ta  
b | Uncheck the   
two boxes in the "Broadcast Response" section. This will prevent that perl scanner from working.  
  
2. Configure your MetaFrame XP servers so that users can only run published applications.   
(Citrix Connection Configuration | double-click "ica-tcp" | Advanced button | Check "Only run publis  
hed applications"  
in the "Initial Program" section). I'd suggest first adding a published application for 'remote des  
ktop' and only  
allow administrators to use this feature.   
  
3. Ian Vitek suggested a product called SecurEXE, This looks very promising and if I have time to te  
st this out  
I will post my results. After looking at their live demo (they let you terminal services in and play  
around),  
I am simply amazed, I could barely get anywhere, all I could do is right click on an exe and try to   
'run as' a user  
and them attempt to brute force the Administrator password. Other than that I was completely locked   
out. I have  
yet to test this in a lab, but from that demo I must admit I'm very impressed.  
Here is the URL for SecurEXE: http://www.securewave.com/products/secureexe/secure_exe.html   
  
- Securing Internally  
Try using the same steps as listed for external, if you can segment your network access via a firewa  
ll + citrix   
secure gateway you are much better off then leaving it on the same segment. Other than that I know o  
f no real  
good procedures for securing internally.  
  
  
  
.Questions Comments?  
This is my first paper regarding Citrix and most likely as I play with it more I'll add more additio  
ns. Feel free  
to email me at [email protected]. Disregard the lame banner underneath my emails, its free, and  
its email...  
  
Hope this helps some people realize the serious flaws with using citrix. It's a good idea, just not   
when used in  
conjunction with Microsoft Windows :(.  
  
.Editorial Note:  
After attempting to contact Citrix regarding the cmd.exe insert flaw, they told me this rather amusi  
ng story.  
Since I do not have a tech support agreement with citrix, it would cost me 400$ per incident to repo  
rt this.  
I was rather astounded and made quite sure this was true. Here is the dialogue:  
  
citrix: We are sorry sir, you do not currently have a tech support agreement with us. Without one, c  
ontacting  
tech support to report this issue will cost you 400$, would you like to charge this to a credit card  
?  
  
me: Wait, so let me get this straight, I pay you 400$ to do you a favor by telling you, you have a p  
ossible security  
flaw with your program?  
  
citrix: Yes *nervous giggle* we are sorry but it is the only way to contact tech support, they won't  
even let me transfer  
you over.  
  
me: Ok so I have to release this to everyone and have your engineers find and possibly scramble to f  
ix this issue?  
  
citrix: Yes *nervous giggle again* *mentions something about going through my reseller*  
  
me: Ok looks like I'll release it, Thank you.  
  
  
  
`

Data

Build on a solid foundation with Vulners data

We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data

Api

Power your application with Vulners API

The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access

App

Assess and manage vulnerabilities with Vulners tools

Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation