Link Logger
Premium,MVM
join:2001-03-29
Calgary, AB
 ·Shaw
| reply to SUMware
Re: .NET Framework Rootkits
I will summarize what I was going to post before the server decided to choke and subsequently lose my usually detailed and eloquent posting on this topic.
First I've seen a number of people say they won't load .Net runtimes onto their machines, my question to them is do they load Java runtimes as perhaps they should read this paper as Erez Metula states on page 5:
And, as a side note – the methods described in this paper are not restricted only for the
.NET Framework, but can also be applied to other VM based platforms, such as Java.
Next this interesting as the basis of the exploit is:
Surprisingly, it was found during this research that the modified DLL can be directly
copied to the correct location at the file system, because the SN mechanism does not
check the actual signature of a loaded DLL but blindly loads the DLL based on
the directory name with the corresponding signature name!
It is important to mention that this technique does not requires "full trust"
permissions, which further proves the fact that the GAC / CAS protection
mechanisms are broken
Now the name is checked on initial loading so the deal here is that the .Net framework already has to be up and running, which greatly limits the attack potential. If the DLL was infected and saved, when the .Net runtimes loaded the naming problem would cause the attack to gack, so to make this a virus you would need to leave the original DLL in place such that it was loaded during the initial load and then have an application run which would do the dirty deed of injecting the infected DLL in after.
Now certainly this exploit implies that the applications using the .Net environment don't have use any security checking code (ex Declarative or Imperative coding which checks the environment etc) which cause a stack walk and would likely raise and exception with the naming problem of the infected DLL. CAS (.NEt's Code Access Security) would also likely detect and report this problem (CAS is actually kind of cool as you can white list what your app can do such that any exceptions are flagged, handy if your using a third party dll that you don't trust, so white list what it can do and anything else it does and CAS raises an exception and stops the app cold).
So in terms of am I fearing any mass attack from this nope, and I will use this in my upcoming .NET Secure Presentation to help drive home why something should be done in certain ways.
Blake
--
Vendor: Author of Link Logger which is a traffic analysis and firewall logging tool |
|
Kiwi
Premium
join:2003-05-26
USA | Apparently I should have spent the time, but you already did it twice  Good job. |
|
mysec
Premium
join:2005-11-29
4 edits | reply to Link Logger
said by Link Logger  :(CAS is actually kind of cool as you can white list what your app can do such that any exceptions are flagged, handy if your using a third party dll that you don't trust, so white list what it can do and anything else it does and CAS raises an exception and stops the app cold).
Nice to know!
Other White List solutions will also stop this exploit cold.
From the White Paper:
Framework modification can be achieved by tampering with a Framework DLL and
"pushing" it back into the Framework.
The process is composed of the following steps:
• Locate the DLL in the GAC, and copy it outside
• Analyze the DLL
• Decompile the DLL using ildasm
• Modify the MSIL code
• Recompile to a new DLL using ilasm
• Bypass the GAC strong name protection
• Reverting back from NGEN Native DLL
• Deploy the new DLL while overwriting the original
My test:
• select a White Listed .dll (ver.dll)
• modify a copy of ver.dll and place on a USB drive
• attempt to copy/overwrite ver.dll
__________________________________________
I don't see any way a non White Listed executable can be installed without user permission
on a properly protected system.
|
|
microserf v1
@cgocable.net
| reply to SUMware
Thank you (sorry for the delay in responding).
Your quote clearly shows a difference I have with the author in terms of perspective. Farting around with .NET when you have admin privileges on a machine is counter-productive. IMO, any modifications made to the framework from an external (to the framework) point highlights commercial/secure distribution issues in a hostile administrative environment. |
|
Link Logger
Premium,MVM
join:2001-03-29
Calgary, AB
·Shaw
| said by microserf v1 :
IMO, any modifications made to the framework from an external (to the framework) point highlights commercial/secure distribution issues in a hostile administrative environment. Reminds me of a time when a company asked me how they could secure a database from their DBA whom they didn't trust (but apparently didn't want to fire), which for me was another reminder that a lot of security problems are not technical, but are in fact HR problems (if someone could tell me what HR does anymore I'd certainly appreciate it). For another example isn't it funny that the lowest paid, least respected employee is usually the one with all the keys and the least supervision (ie your cleaning staff)?
At some point in time trust in employees isn't optional so selecting who those employees are shouldn't be a glossed over or outsourced issue.
Blake
--
Vendor: Author of Link Logger which is a traffic analysis and firewall logging tool |
|
jdong
Eat A Beaver, Save A Tree.
Premium
join:2002-07-09
Rochester, MI
clubs:  
| reply to SUMware
Well I don't want to completely downplay this security vulnerability either -- Microsoft advertised signing of their .NET assemblies as a way to tamper-proof them (or at least make them tamper evident) and in this specific example, this claim is not true. This doesn't mean the sky is falling, as already discussed, but it also isn't entirely harmless or pointless to regard as a security vulnerability.
--
Ubuntu MOTU Developer and Forums Council |
|
