This post is about abusing some well-known and widely used features of Citrix and Terminal-Service , to compromise end-user clients .
The topic has been one of my under-going research cases , and I`ve been playing around it since some months ago , but as part of it will be published soon in a known commercial products, there`s no reason too keep the case in dark. I`ve to warn you that this post will cover only concepts and no tools nor ready-to-use technical details will be provided , So if you`re looking for some download links to practical ./hack-it tools , save your time and move on to another blog .
Ok , let`s review some basics . Both Terminal-Service and Citrix have some powerful features known as resource mapping . This feature is about linking/moving resources on client to the server s/he connects to , through TS or Citrix . What kind of resources ? well , all kind of resources . from printers and local drives to plug & play devices. Assuming you have no previous experience with this resource-mapping feature , I`ll explain it better , through some common usage scenarios :
(#1 ) You , as a system administrator , connect to your servers with TS ( AKA RDP ) to do your daily management jobs . During your works , you should transfer some files from/to the server. Considering you as a wise admin , you`ve already blocked SMB ( file-sharing ) traffic on network boarders so using normal network shares is not possible . So how will you transfer files from your client to TS server ? Here the 'drive-mapping' comes handy . You can locate it in your terminal-service client ( mstsc.exe ) under 'Local Resources' tab . And how it works ? You simply check the option to enable it , since it`s NOT enabled by default for terminal-service . Then , you select drive letters of your CLIENT to be mapped . finally you connect to the server . Opening My-Computer on server , you`ll see your selected drive letters there ! cool huh ? :) after that , you can simply use mapped drive(S) for any purpose , right like they are a local volume on server .
(#2) You , as a normal network user working in your corporate network , should work with some office and business applications. Applications you should work with ( An office-automation , or a financial application for example ) are shared through application servers , running on Citrix platform . Don`t get worry , Citrix is big brother of Terminal-Service , so most of base and back-end systems and functionalities are actually based on same idea and some times exactly same technical details . So you connect to citrix server by installed client , and GUI of published application finally pops up . Your application ask you to upload your document , and your document file is on your CLIENT . So again , there should be a way to transfer your doc to server and feed the application . Following same my-computer example , you`ll see your client drives AUTOMATICALLY MAPPED at server . You go to your mapped drive letter , pick the file and so on ...
So now you get the idea how this drive-mapping thing is working and being used .
There are some points in these scenarios :
The topic has been one of my under-going research cases , and I`ve been playing around it since some months ago , but as part of it will be published soon in a known commercial products, there`s no reason too keep the case in dark. I`ve to warn you that this post will cover only concepts and no tools nor ready-to-use technical details will be provided , So if you`re looking for some download links to practical ./hack-it tools , save your time and move on to another blog .
Ok , let`s review some basics . Both Terminal-Service and Citrix have some powerful features known as resource mapping . This feature is about linking/moving resources on client to the server s/he connects to , through TS or Citrix . What kind of resources ? well , all kind of resources . from printers and local drives to plug & play devices. Assuming you have no previous experience with this resource-mapping feature , I`ll explain it better , through some common usage scenarios :
(#1 ) You , as a system administrator , connect to your servers with TS ( AKA RDP ) to do your daily management jobs . During your works , you should transfer some files from/to the server. Considering you as a wise admin , you`ve already blocked SMB ( file-sharing ) traffic on network boarders so using normal network shares is not possible . So how will you transfer files from your client to TS server ? Here the 'drive-mapping' comes handy . You can locate it in your terminal-service client ( mstsc.exe ) under 'Local Resources' tab . And how it works ? You simply check the option to enable it , since it`s NOT enabled by default for terminal-service . Then , you select drive letters of your CLIENT to be mapped . finally you connect to the server . Opening My-Computer on server , you`ll see your selected drive letters there ! cool huh ? :) after that , you can simply use mapped drive(S) for any purpose , right like they are a local volume on server .
(#2) You , as a normal network user working in your corporate network , should work with some office and business applications. Applications you should work with ( An office-automation , or a financial application for example ) are shared through application servers , running on Citrix platform . Don`t get worry , Citrix is big brother of Terminal-Service , so most of base and back-end systems and functionalities are actually based on same idea and some times exactly same technical details . So you connect to citrix server by installed client , and GUI of published application finally pops up . Your application ask you to upload your document , and your document file is on your CLIENT . So again , there should be a way to transfer your doc to server and feed the application . Following same my-computer example , you`ll see your client drives AUTOMATICALLY MAPPED at server . You go to your mapped drive letter , pick the file and so on ...
So now you get the idea how this drive-mapping thing is working and being used .
There are some points in these scenarios :
- In Terminal-Service, drive-mapping is NOT enabled by default , and user should activate it from options . Few admins do it usually , but after all it`s a favorite option !
- In Citrix environments , unless denied by citrix policies , this feature is enabled by default. The only user-interaction is where citrix client software asks end-user how he wants to share local drives . Again unless users are trained or guided by automated option selections , default setting is to allow read/write access . And to make it even more interesting , by default , all local drives are mapped .
You should be aware that , drive-mapping is not the only option . You can virtually map any resource from your client to server . Some common mappings are : Sound system , USB/Parallel/Serial ports , printers and related drivers , SMART Cards , and some more ... .
After mapping , your mentioned local resources ( available only in your client workstation ) will be also available on server . And all these happen under RDP or ICA protocol , depending on server and used platform.
Hopefully Microsoft recently released technical details of RDP so you can happily begin reading them . Note that before this , you had to spend long days of reversing , reading codes , try & error and many other hard works to understand how underlying system is actually working . Of course there are some published junks in product documentations , but they are nothing more than brief notes without any real technical details.
Here are also some other notes about the mapping feature , used sub-systems and protocols . If you`re a system administrator , I highly recommend you read this part carefully as I`ve seen many admins out there having wrong sense about security of their systems.
After mapping , your mentioned local resources ( available only in your client workstation ) will be also available on server . And all these happen under RDP or ICA protocol , depending on server and used platform.
Hopefully Microsoft recently released technical details of RDP so you can happily begin reading them . Note that before this , you had to spend long days of reversing , reading codes , try & error and many other hard works to understand how underlying system is actually working . Of course there are some published junks in product documentations , but they are nothing more than brief notes without any real technical details.
Here are also some other notes about the mapping feature , used sub-systems and protocols . If you`re a system administrator , I highly recommend you read this part carefully as I`ve seen many admins out there having wrong sense about security of their systems.
- EVERYTHING is encapsulated into ICA ( if you`re using Citrix) or RDP ( if you`re running only TS ) , so a single tcp port ( 3389 or 1494 ) is used for entire work . Here you think about your firewalls and IDS/IDP systems , but read next :
- EVERYTHING is fully encrypted/&/compressed . In case of TS , x.509 certificates are used to tunnel RDP traffic over SSL , and in ICA protocol case , things are even more less-documented and proprietary . To make you relax : No chance for monitoring the traffic at all ( hey , not many admins have knowledge to actively forge RDP certificates and MITM it to capture data , and it`s not a friendly solution for inspection at all !!! )
- Drive-mapping feature specifically , is NOT DEPENDED on any file-sharing service available on your server . you may think disabling 'file & print sharing' service can mitigate , or you may watch for SMB/NetBios traffic to bust malicious activity , but again NOTHING is left for you to inspect . Since it`s not network share , watching sessions is useless. since it`s not remote connection watching for network traffic is useless . and since it`s happening all under RDP and related services , no specific log entry will appear in event-log with normal and even above-normal audit levels . ( You can still relay on enabling resource tracking auditing options through system policies in windows , but due to load of generated logs it`s not a good solution .)
- Finally based on available resources there`s really no way to distinguish between a legitimate and malicious use of sub-systems .
Here`s another point , or kind of wrong assumption , for those who think this game is too easy :
- Assuming multiple users connect to same server , and each user have his resources mapped , non of them access other users resources . So every user`s session is isolated . User Bob maps his local drives to server , and John does the same . But John will not see Bob`s mapped drives while opening my-computer on server .This is good from admin`s point of view , and bad from hacker`s point of view .
Now you`ve got better idea about how resource mapping works . Here we can switch to bad guy`s point of view and review the scenario .
As I`ve mentioned before , drive-mapping feature is enabled by default in Citrix environments , so it`s more interesting for hackers . Beside popularity of citrix , there are usually much more end-user targets available per-server for attack . Focusing on attacking ( read pen-testing !) enterprise networks , some times you can gain access to interesting resources through compromising administrative workstations , or specific users workstations. Not to mention how many of classified and confidential materials are leaked this way , by attacking client systems, not big tightly protected enterprise servers.
From now on , we consider the attacker have complete control over Terminal-Service server, or Citrix server . to be more clear , we`ll assume we have administrator / SYSTEM level access . Don`t query me how to gain such high level of access . There are many ways to do that . To give you some idea , citrix itself have at least three known ( who care`s about 0days ?! ) remotely exploitable flaws giving you instant SYSTEM access remotely. Citrix servers are usually bundled with some 3rd-party services such as MS-SQL , and these usually run with SYSTEM , or even better, Domain-Admin level credentials . As end-users should interact with Citrix servers , there are usually some common tools and drivers installed too . Here you say : "Huh , drivers ?! kernel-mode exploits ? no way ! " but try to be creative . MANY ( if not all ) of sound-system drivers for example , have an old known weak configuration problem which let you gain SYSTEM level access on servers . Just google for old c:\program.exe trick .... . There can be many other opportunities to elevate privileges , but as it`s not subject of this post , I`ll skip it .
Ok , we`re SYSTEM/Admin now . Let`s take a look at how Citrix & Terminal-Service work and gives user access to his remote space & session . Both of these two , relay on terminal-server service as their background , for managing users sessions , in kernel level . When a new user connect to server , the service create a new session , dedicate some primary (and usually limited
) resources to the session , run very few processes to manage core functionalities ( such as authentication and running new processes in user space ) , run published application in session , and finally hands over it to remote user through ICA or RDP session . Drive-mapping is also handled during this initialization .Below image will give you idea how these sessions and drive-mapping looks like :
Server have some local volumes ( drives ) that is shared between all users , means that (skipping applied NTFS limitations ) all users can browse local drives of server and create new files for example . But we have mapped drives too . Beside local drives of server, if drive-mapping is enabled/allowed , user will see his _client_ drives in server too . Since it`s NOT a server-wide map , and initialized INSIDE that specific session , mapped drives are isolated to that specific session , as shown in previous image . This isolation and management of sessions and mapped drives are handled by terminal-server service , or to be more specific in technical details , RDP-EFS ( File System Virtual Channel Extension ) . hmm , seems new publications by MS are really helping ;) . Given document is about 90 pages , but to save your time , here`s how EFS works : After negotiation between client and server through RDP , list of drives ready for mapping is handed between peers , and published on server . After that , based on request from client or server I/O operations happens , like server query client for list of contents of dir c:\ , and client responds with data , then server list responded contents in server . Everything SERVER wants from mapped-drives of client , is handled by EFS virtual channel and related service .
And the conclusion : processes on SERVER , can NOT directly interact with client-mapped drives . This simple conclusion reveals the big problem for hacker . To make it again more clear ; a process running in session#1 can`t simply do I/O operation for a mapped drive in session#2 . This almost matches to all other virtual channels ( or mapped resources ) . For example process in session#1 can`t manage or work with a mapped printer in session#2 , and so on . Same restriction applies to session#0 ( console ) , so even with full access you can not normally interact with other sessions .
So far we learned how staff works , mappings are handled , and finally how the isolation between sessions works . But how to bypass this ? and what do we mean exactly by bypassing ? Well , the goal is to gain access to all/one session(S) mapped resources and DIRECTLY work with those resources , doing I/O operation on remote mapped drives for example .
Consider every resource on SERVER as session#0 , or what we call it a 'console' session. We have to be able to interact with other sessions from session#0 , or in more advanced manner , from session#{x} with session#{y} . Doing so requires high privileges on server , and that`s why at beginning I mentioned that we assume we have full access on server . You can also find a local vulnerability ( like some of unpatched RPC weak/broken access controls ) and proof this wrong , doing this attack with privileges of a normal user . Follow "ms08-006 under rated" topic in DailyDave to get some idea about possible vulnerabilities ;)
Based on what we`ve learned so far , there could be two possible avenues for attacking other sessions :
Attack-1 : Owning the terminal-server service and Redirector service.
This is probably the harder one , cause it requires modification and hijacking of objects in kernel space , which I personally have no experience on . At least theoretically this attack looks straight-forward , assuming privileged access to server and memory space. Since we`re goint to attack devices , not GUI part of session for example , we should focus on the driver responsible for redirecting driver , printer , SMART Card ,... wich is RDPDR.SYS , the kernel-mode redirector of terminal-service . In every session , dirve I/O is handled by RdpDr , and mapped to \Device\RdpDr\tsclient\{drive-letter} . This map is later translated to \\tsclient\{drive-letter} as a UNC path , when user asks for I/O in session . Of course redirector won`t simply and blindly accept requests to maps and here`s what I`m currently trying to work on and learn . This concept is same between TS and Citrix for mapping drives . And here you saw way disabling 'File & Print Sharing' service won`t help admin to secure his server , preventing unauthorized mappings . Skipping complexity of this attack , it has a major benefit compared to second attack I`ll later explain . Attacking the system at this level will open access to ALL/ANY sessions resources . Completed output of this piece of research will be able to list all mapped resources ( drives to be more targeted and specific ) and interact with them , and prepare DIRECT access to targeted session(s) . I`ll leave this vector here , till farther researches about possibilities and technical details of attack . I hope to be able to update this case in another post .
Attack-2 : Abusing features , capabilities and APIs of Citrix/Terminal-Service.
Compared to previous vector , this method is much easier to implement ( already done ) and no deep technical work is required for attacking other sessions . Here`s how the simple idea works : As we have full access on server/services , we ask from service and application to do what we want , all by calling available functionalities . This technique how ever , can handle one session at time . for example , you`ll focus on a specific session# , join the session , do your post-exploitation tasks , and get out . Those who have experience in managing and configuring Citrix and Terminal-Service in application-server mode , may have already got the idea . Yes , there are many provided tools and commands by Citrix and TS , to manage and INTERACT with open sessions . we just hack and pack them together to reach our final goal .
As Citrix is more common , I`ll continue the topic focusing on it . Citrix have many usefull set of command and functionalities provided to admins for managing sessions . The most well-known feature is 'shadowing' , also available in TS . Shadowing a session means forcefully hijacking an open session and gaining controll over the session , to do administrative tasks , or ( in view-only shadowing ) just watch the user browsing porn sites . This feature looks enough at first glance for what we need . Here`s a possible scenario of owning end-user by shadowing :
## we interact ( shadow ) session either from Citrix/TS management console , or by command-line version of tool and gain interactive ( but not direct) access to session . Why I say not-direct ? because we`re still using citrix/ts functionalities to gain access to session . not by rae read/write to memory for example . There at opened session , we can copy our trojan.exe from server drive to client`s mapped drive , leaving it in a place user later will execute ON HIS OWN COMPUTER NOT THE SERVER , or you`ll re-infect the server . game over . But hey , user won`t just seat & watch you infecting his client ! so we`ve to look for a more stealth way . Here come`s the second possible scenario :
## we list available sessions on server , target one , RUN NEW CUSTOM PROCESS into that session , again by using Citrix capabilities , and continue our work . this custom process can be a simple hidden cmd.exe . We execute it , interact with it , from command-prompt copy our files from server to client`s mapped volumes or wise versa . Note that this way we can see mapped drives of client , because we`re actually in the same session as user ! so things work pretty straight-forward . This scenario can be extended very creatively , making any devilish attack possible . from capturing key-strokes of user in session by injecting and executing a keyLogger process , to instantly infecting end-user client by modifying/backdooring/replacing Citrix or TS client binaries at user`s workstation . This is how the attack vector has been recently implemented in one of commercial packages and provided to users . I`m not going to name the company , and not telling they have re-packed and selling already-available set of tools & commands as a commercial package . The truth is that they have provided a simple-to-use tiny package for attacking citrix , and it works pretty well ,as shown in their advertisement (demo) ! Here is the scenario followed in demo :
1-Attacker compromise server and copy tool-set files to server.
2-Using one of tools in package , available sessions are listed and attacker can list details of a targeted session . No big deal here , as all of tasks in this step are provided in MORE ADVANCED manner by citrix command-line tools already out of the box .
3-Using the same tool , attacker injects and run an instance of cmd.exe into targeted session and thus gaining access to mapped-drives of client . This step requires some advanced citrix skills among some process injection tricks while taking care of security tokens , so we create new process in correct session & security contexts .
4-Attacker copy a backdoored version of citrix client to c:\program files\citrix\blah blah ... and replace it with original binary name , keeping original binary with another name .
5-Attacker disconnect targetted session , so poor user should run his client again , to connect to server . Here the trick works , user blindly execute backdoored client , and his ass is compromised silently . Again this step can be reproduced all by citrix commands.
6- You say ... :-)
Here the second attack vector is finished . I guess I`ve gave you enough information for where to look for farther info . There are two ways to learn Citrix/TS in a way that you`ll be able to implement attack-2 . First ; read and learn documents and administration materials of Citrix/TS . If you already have the knowledge and just look for a qiuck cheat-sheet of useful and required commands , here`s a good one .
There are some other attack vectors to own end-user from a compromised server , but I leave them for further research and more practical tests .
Have fun , till next post .
As I`ve mentioned before , drive-mapping feature is enabled by default in Citrix environments , so it`s more interesting for hackers . Beside popularity of citrix , there are usually much more end-user targets available per-server for attack . Focusing on attacking ( read pen-testing !) enterprise networks , some times you can gain access to interesting resources through compromising administrative workstations , or specific users workstations. Not to mention how many of classified and confidential materials are leaked this way , by attacking client systems, not big tightly protected enterprise servers.
From now on , we consider the attacker have complete control over Terminal-Service server, or Citrix server . to be more clear , we`ll assume we have administrator / SYSTEM level access . Don`t query me how to gain such high level of access . There are many ways to do that . To give you some idea , citrix itself have at least three known ( who care`s about 0days ?! ) remotely exploitable flaws giving you instant SYSTEM access remotely. Citrix servers are usually bundled with some 3rd-party services such as MS-SQL , and these usually run with SYSTEM , or even better, Domain-Admin level credentials . As end-users should interact with Citrix servers , there are usually some common tools and drivers installed too . Here you say : "Huh , drivers ?! kernel-mode exploits ? no way ! " but try to be creative . MANY ( if not all ) of sound-system drivers for example , have an old known weak configuration problem which let you gain SYSTEM level access on servers . Just google for old c:\program.exe trick .... . There can be many other opportunities to elevate privileges , but as it`s not subject of this post , I`ll skip it .
Ok , we`re SYSTEM/Admin now . Let`s take a look at how Citrix & Terminal-Service work and gives user access to his remote space & session . Both of these two , relay on terminal-server service as their background , for managing users sessions , in kernel level . When a new user connect to server , the service create a new session , dedicate some primary (and usually limited
) resources to the session , run very few processes to manage core functionalities ( such as authentication and running new processes in user space ) , run published application in session , and finally hands over it to remote user through ICA or RDP session . Drive-mapping is also handled during this initialization .Below image will give you idea how these sessions and drive-mapping looks like :
Server have some local volumes ( drives ) that is shared between all users , means that (skipping applied NTFS limitations ) all users can browse local drives of server and create new files for example . But we have mapped drives too . Beside local drives of server, if drive-mapping is enabled/allowed , user will see his _client_ drives in server too . Since it`s NOT a server-wide map , and initialized INSIDE that specific session , mapped drives are isolated to that specific session , as shown in previous image . This isolation and management of sessions and mapped drives are handled by terminal-server service , or to be more specific in technical details , RDP-EFS ( File System Virtual Channel Extension ) . hmm , seems new publications by MS are really helping ;) . Given document is about 90 pages , but to save your time , here`s how EFS works : After negotiation between client and server through RDP , list of drives ready for mapping is handed between peers , and published on server . After that , based on request from client or server I/O operations happens , like server query client for list of contents of dir c:\ , and client responds with data , then server list responded contents in server . Everything SERVER wants from mapped-drives of client , is handled by EFS virtual channel and related service .
And the conclusion : processes on SERVER , can NOT directly interact with client-mapped drives . This simple conclusion reveals the big problem for hacker . To make it again more clear ; a process running in session#1 can`t simply do I/O operation for a mapped drive in session#2 . This almost matches to all other virtual channels ( or mapped resources ) . For example process in session#1 can`t manage or work with a mapped printer in session#2 , and so on . Same restriction applies to session#0 ( console ) , so even with full access you can not normally interact with other sessions .
So far we learned how staff works , mappings are handled , and finally how the isolation between sessions works . But how to bypass this ? and what do we mean exactly by bypassing ? Well , the goal is to gain access to all/one session(S) mapped resources and DIRECTLY work with those resources , doing I/O operation on remote mapped drives for example .
Consider every resource on SERVER as session#0 , or what we call it a 'console' session. We have to be able to interact with other sessions from session#0 , or in more advanced manner , from session#{x} with session#{y} . Doing so requires high privileges on server , and that`s why at beginning I mentioned that we assume we have full access on server . You can also find a local vulnerability ( like some of unpatched RPC weak/broken access controls ) and proof this wrong , doing this attack with privileges of a normal user . Follow "ms08-006 under rated" topic in DailyDave to get some idea about possible vulnerabilities ;)
Based on what we`ve learned so far , there could be two possible avenues for attacking other sessions :
Attack-1 : Owning the terminal-server service and Redirector service.
This is probably the harder one , cause it requires modification and hijacking of objects in kernel space , which I personally have no experience on . At least theoretically this attack looks straight-forward , assuming privileged access to server and memory space. Since we`re goint to attack devices , not GUI part of session for example , we should focus on the driver responsible for redirecting driver , printer , SMART Card ,... wich is RDPDR.SYS , the kernel-mode redirector of terminal-service . In every session , dirve I/O is handled by RdpDr , and mapped to \Device\RdpDr\tsclient\{drive-letter} . This map is later translated to \\tsclient\{drive-letter} as a UNC path , when user asks for I/O in session . Of course redirector won`t simply and blindly accept requests to maps and here`s what I`m currently trying to work on and learn . This concept is same between TS and Citrix for mapping drives . And here you saw way disabling 'File & Print Sharing' service won`t help admin to secure his server , preventing unauthorized mappings . Skipping complexity of this attack , it has a major benefit compared to second attack I`ll later explain . Attacking the system at this level will open access to ALL/ANY sessions resources . Completed output of this piece of research will be able to list all mapped resources ( drives to be more targeted and specific ) and interact with them , and prepare DIRECT access to targeted session(s) . I`ll leave this vector here , till farther researches about possibilities and technical details of attack . I hope to be able to update this case in another post .
Attack-2 : Abusing features , capabilities and APIs of Citrix/Terminal-Service.
Compared to previous vector , this method is much easier to implement ( already done ) and no deep technical work is required for attacking other sessions . Here`s how the simple idea works : As we have full access on server/services , we ask from service and application to do what we want , all by calling available functionalities . This technique how ever , can handle one session at time . for example , you`ll focus on a specific session# , join the session , do your post-exploitation tasks , and get out . Those who have experience in managing and configuring Citrix and Terminal-Service in application-server mode , may have already got the idea . Yes , there are many provided tools and commands by Citrix and TS , to manage and INTERACT with open sessions . we just hack and pack them together to reach our final goal .
As Citrix is more common , I`ll continue the topic focusing on it . Citrix have many usefull set of command and functionalities provided to admins for managing sessions . The most well-known feature is 'shadowing' , also available in TS . Shadowing a session means forcefully hijacking an open session and gaining controll over the session , to do administrative tasks , or ( in view-only shadowing ) just watch the user browsing porn sites . This feature looks enough at first glance for what we need . Here`s a possible scenario of owning end-user by shadowing :
## we interact ( shadow ) session either from Citrix/TS management console , or by command-line version of tool and gain interactive ( but not direct) access to session . Why I say not-direct ? because we`re still using citrix/ts functionalities to gain access to session . not by rae read/write to memory for example . There at opened session , we can copy our trojan.exe from server drive to client`s mapped drive , leaving it in a place user later will execute ON HIS OWN COMPUTER NOT THE SERVER , or you`ll re-infect the server . game over . But hey , user won`t just seat & watch you infecting his client ! so we`ve to look for a more stealth way . Here come`s the second possible scenario :
## we list available sessions on server , target one , RUN NEW CUSTOM PROCESS into that session , again by using Citrix capabilities , and continue our work . this custom process can be a simple hidden cmd.exe . We execute it , interact with it , from command-prompt copy our files from server to client`s mapped volumes or wise versa . Note that this way we can see mapped drives of client , because we`re actually in the same session as user ! so things work pretty straight-forward . This scenario can be extended very creatively , making any devilish attack possible . from capturing key-strokes of user in session by injecting and executing a keyLogger process , to instantly infecting end-user client by modifying/backdooring/replacing Citrix or TS client binaries at user`s workstation . This is how the attack vector has been recently implemented in one of commercial packages and provided to users . I`m not going to name the company , and not telling they have re-packed and selling already-available set of tools & commands as a commercial package . The truth is that they have provided a simple-to-use tiny package for attacking citrix , and it works pretty well ,as shown in their advertisement (demo) ! Here is the scenario followed in demo :
1-Attacker compromise server and copy tool-set files to server.
2-Using one of tools in package , available sessions are listed and attacker can list details of a targeted session . No big deal here , as all of tasks in this step are provided in MORE ADVANCED manner by citrix command-line tools already out of the box .
3-Using the same tool , attacker injects and run an instance of cmd.exe into targeted session and thus gaining access to mapped-drives of client . This step requires some advanced citrix skills among some process injection tricks while taking care of security tokens , so we create new process in correct session & security contexts .
4-Attacker copy a backdoored version of citrix client to c:\program files\citrix\blah blah ... and replace it with original binary name , keeping original binary with another name .
5-Attacker disconnect targetted session , so poor user should run his client again , to connect to server . Here the trick works , user blindly execute backdoored client , and his ass is compromised silently . Again this step can be reproduced all by citrix commands.
6- You say ... :-)
Here the second attack vector is finished . I guess I`ve gave you enough information for where to look for farther info . There are two ways to learn Citrix/TS in a way that you`ll be able to implement attack-2 . First ; read and learn documents and administration materials of Citrix/TS . If you already have the knowledge and just look for a qiuck cheat-sheet of useful and required commands , here`s a good one .
There are some other attack vectors to own end-user from a compromised server , but I leave them for further research and more practical tests .
Have fun , till next post .
A Research or a Shoam ? Stop moanning and bitchig and verbing ; please .
ReplyDelete