A cute byproduct of the .Net framework rootkit development that has been going on is a new little child called 'frameSafe'. The first ever (to my knowledge) framework rootkit detection kit. Currently, no research for identification is being done (but the .Net sploit packages will be detected). The base idea is to secure the set of libraries needed for the tool to run by resigning them and including them in the release (this prevents the framework based tool from being injected). Next, the tool hashes a known good set of framework dlls (prior to distribution to the world (this is the inhouse step)).
Once those .Net Framework dll's are hashed and signed, the hashes are then placed in a descriptive manifest along with dll version number, and whether or not a native DLL should exist in the non JIT native images location. The ILASM output of the dll is also hashed and signed into this manifest. Now we have a hashed/signed snapshot of the framework assemblies and layout. The tool can then be used to scan for changes in the framework, and if detected - do a comparison of the current IL and the stored(good) IL. This will get us a snippet of ASM that can help us in determining the version of a specific infection (within reason).
So that's it, expect a release of the first version to sourceforge in a week or so.
Monday, September 28, 2009
Sunday, September 6, 2009
WCF Raping, teh fun and teh Glory
WCF getting pushed like crack in a schoolyard? Yes... How secure is it? Well, don't you know? Of course not... nobody fucking does... lets take a look, shall we....
So .net-sploit 1.0 has shown us the beauty of RootKits for the managed .net framework. It is possible to modify the .Net Framework in such a way that a managed code rookit can be hiddenly indefinately from detection (until the framework is completely ripped/reinstalled). Knowing this, we can begin to attack the WCF stack from a code- injection standpoint for affected systems with the assurance (within reason) of permanent residence. To assure our unilateral attendance period goes unnoticed, calling back home...etc from and infected PC may not be the smartest choice. Sometimes, you just want the infect PC's to give up some goodies without you having to ask too much from system. Therein lies the principle of the MITM (Man In The Middle Attack) attack. You are not part of the affected stack, but you are part of the communication stream. A WCF 'from the wire alone' sniffing is what I am working at... Kerberos is what I am fighting against for the secure streams. Maybe... just maybe... I can infect a PC with something that forcefully downgrades a Kerberos session to say something like... o, I dunno... NTLM. That would suck, especially if you noted things like 'Only use kerberos' in the configuration of all endpoints to ensure this 3rd party MITM attack doesn't occurr...
Only if....well, that WAS true.
The first attack I am using is a design flaw in how WCF secures its communications. To prevent MITM attacks on the WCF transport stacks, the transport sessions rely upon Kerberos encryption to ensure a 3rd party isn't checking in. I am not He-Man, nor do I aspire to wield an unstoppable sword, but I can infect any PC in the communication stream (client or server) via an exploit (if no auth exists) - better if I pick up creds and attack, but a bootstrapping bot bit of shellcode and some IL tricks, and then my resident rootkit can perform a bit of magic to the SPN fields of any Kerberos call. These calls verify the hosts you are speaking to are not spoofed, however, we can 'in an encapsulated layer' automagically downgrade from Kerberos to NTLM auth and hashing without notice to any parent layers on either client or server. This works, I have a POC in hand.
Now the MITM is possible to occurr, and do so in a MITM friendly environment outside the realm of current RootKit detection technology. So this a a brief synopsis of where I am at (I can spoof a WCF server even when kerberos auth is turned on, without changing the endpoints).
There are a few things I am working out for all of this to be a success, but they simply only take time. If you are interested in getting some more information, or to get your SVN action going email me for more info. (like the code repository and such).
So .net-sploit 1.0 has shown us the beauty of RootKits for the managed .net framework. It is possible to modify the .Net Framework in such a way that a managed code rookit can be hiddenly indefinately from detection (until the framework is completely ripped/reinstalled). Knowing this, we can begin to attack the WCF stack from a code- injection standpoint for affected systems with the assurance (within reason) of permanent residence. To assure our unilateral attendance period goes unnoticed, calling back home...etc from and infected PC may not be the smartest choice. Sometimes, you just want the infect PC's to give up some goodies without you having to ask too much from system. Therein lies the principle of the MITM (Man In The Middle Attack) attack. You are not part of the affected stack, but you are part of the communication stream. A WCF 'from the wire alone' sniffing is what I am working at... Kerberos is what I am fighting against for the secure streams. Maybe... just maybe... I can infect a PC with something that forcefully downgrades a Kerberos session to say something like... o, I dunno... NTLM. That would suck, especially if you noted things like 'Only use kerberos' in the configuration of all endpoints to ensure this 3rd party MITM attack doesn't occurr...
Only if....well, that WAS true.
The first attack I am using is a design flaw in how WCF secures its communications. To prevent MITM attacks on the WCF transport stacks, the transport sessions rely upon Kerberos encryption to ensure a 3rd party isn't checking in. I am not He-Man, nor do I aspire to wield an unstoppable sword, but I can infect any PC in the communication stream (client or server) via an exploit (if no auth exists) - better if I pick up creds and attack, but a bootstrapping bot bit of shellcode and some IL tricks, and then my resident rootkit can perform a bit of magic to the SPN fields of any Kerberos call. These calls verify the hosts you are speaking to are not spoofed, however, we can 'in an encapsulated layer' automagically downgrade from Kerberos to NTLM auth and hashing without notice to any parent layers on either client or server. This works, I have a POC in hand.
Now the MITM is possible to occurr, and do so in a MITM friendly environment outside the realm of current RootKit detection technology. So this a a brief synopsis of where I am at (I can spoof a WCF server even when kerberos auth is turned on, without changing the endpoints).
There are a few things I am working out for all of this to be a success, but they simply only take time. If you are interested in getting some more information, or to get your SVN action going email me for more info. (like the code repository and such).
Subscribe to:
Posts (Atom)
Posts
