microserf v1
@cgocable.net
| reply to SUMware
Re: .NET Framework Rootkits
The 'exploit' starts with the modification of a framework dll (assembly) from outside the runtime using administrative privileges. I'd hardly call that a viable rootkit but ok, let's run with it.
Changes to an assembly can be detected with a signature check but the CLR used by the author is blindly loading Strong Name assemblies. This is not how I understood the runtime to function in a default configuration. Without an exception made by sn.exe or inserted directly into HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\StrongName\Verification\, any SN assembly will have its current file hash checked against the signed one as it is loaded. The author claims this verification is not occurring within the GAC. If so, call Microsoft for a bug fix.
Without this initial compromise the rest of the paper is useless. I'll wait for someone to explain why the CLR is not working as (I thought) it should. |
|
SUMware
Premium
join:2002-05-21
1 edit | said by microserf v1 :
The author claims this verification is not occurring within the GAC. If so, call Microsoft for a bug fix. said by whitepaper :
Microsoft response team assigned the GAC protection bypass case the track number of "MSRC 8566gs", but even if the GAC bypass will be fixed it'll surely be possible to mount the attacks described in this paper in some other way, since an attacker who has administrator level privileges on a machine can do everything anyway.
Conclusions
Modification of the framework behavior can lead to some very interesting results as seen in this paper. An attacker who has managed to compromise your machine can backdoor your framework, leaving rootkits behind without any traces. Those rootkits can turn the framework upside down, letting the attacker do everything he wants while his malicious code is hidden deep inside the framework DLL’s. As the owner of the machine, there’s not much you can do about that. You can use external file tampering detectors, such as tripwire, in a scenario where you have another machine that monitors your machine. Microsoft, as the developer of the Framework, should give the .NET Framework a kernel level modification protection.
|
|
NetFixer
Freedom is NOT Free
Premium
join:2004-06-24
Murfreesboro, TN
 ·Vonage
 ·Cingular Wireless
·AT&T CallVantage
 ·AT&T Southeast
| said by Erez Metula :
As the owner of the machine, there's not much you can do about that.
Actually, that is not an entirely accurate statement. One can do as I have done for quite some time and simply refuse to install and use any application that uses the .NET Framework, and let the vendor know the reason why their application is unacceptable to you. The software vendors who utilize the .NET Framework probably don't care if you like it or not, but it never hurts to voice your opinion.
--
A well-regulated militia, being necessary to the security of a free State, the right of the people to keep and bear arms shall not be infringed.
»portscan.dcs-net.net
»nature-pics.com |
|
OZO
Premium
join:2003-01-17
| That is exactly my point as well. I refuse to participate in testing new and new incompatible frameworks on my computers. I understand that development with NET may be easier, but as a consumer - I'll better wait until it settles down to finally workable solution...
--
Keep it simple, it'll become complex by itself... |
|
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 |
|
