  jdong Eat A Beaver, Save A Tree. Premium join:2002-07-09 Rochester, MI clubs:  
| reply to SUMware Re: .NET Framework Rootkits
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 |
|
  Link Logger Premium,MVM join:2001-03-29 Calgary, AB
·Shaw
| reply to microserf v1 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 |
|
  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. |
|
 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.
|
|
 Kiwi Premium join:2003-05-26 USA | reply to Link Logger Apparently I should have spent the time, but you already did it twice Good job. |
|
  Link Logger Premium,MVM join:2001-03-29 Calgary, AB
·Shaw
| reply to SUMware 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
·Comcast
·Aristotle Internet
| reply to Woody79_00 said by Woody79_00 :This article is Snake Oil IMO the attacker would have to have admin access to your machine, in other words, gotten past your firewall and cracked your password. At this juncture, I don't care eif you have .Net installed or not, your owned regardless. Besides, why would they even both with a .Net rootkit anyways, when there are much easier methods of rootkitting a system? this article is snakeoil for that reason. If someone gets admin access to your system, your owned no matter what you have installed. .Net is no more a security risk than any other runtime or compiler. Mirroed my own thoughts. I work with .NET, but not by choice. Regardless, I do believe Woody nailed this down, certainly not a drive by thing for sure. There are a couple of other remarks that had been made, I noted my head nodding up and down  |
|
  Woody79_00
join:2004-07-08 united state
| reply to SUMware This article is Snake Oil IMO
the attacker would have to have admin access to your machine, in other words, gotten past your firewall and cracked your password.
At this juncture, I don't care eif you have .Net installed or not, your owned regardless. Besides, why would they even both with a .Net rootkit anyways, when there are much easier methods of rootkitting a system?
this article is snakeoil for that reason. If someone gets admin access to your system, your owned no matter what you have installed. .Net is no more a security risk than any other runtime or compiler. |
|
  AB Premium join:2006-04-04 Leesburg, VA
| reply to jdong said by jdong :said by AB :You're saying then, that if I gave remote Administrative write permissions to some pimply-faced Russian teenager, he could do more than alter my .NET Framework .DLLs? Is that what you're trying to claim? Not only that -- I am also claiming that this CAN'T POSSIBLY HAPPEN if you don't use .NET. For the 20 year history of Microsoft operating systems there are ZERO incidents of some type of malware modifying native binary executables such that when they run, they do their task and then something subtly malicious. Can't think of anything like that until .NET strong name signature checking compromises came around! Thank you. Just so we're straight on that.
But I believe in giving young people scriptkiddies a fair chance, and so will be keeping .NET Framework v. 2.0 on this machine.
No remote write permissions, though-- I said I was fair, not easy.  |
|
  jdong Eat A Beaver, Save A Tree. Premium join:2002-07-09 Rochester, MI clubs:  
| reply to AB said by AB :You're saying then, that if I gave remote Administrative write permissions to some pimply-faced Russian teenager, he could do more than alter my .NET Framework .DLLs? Is that what you're trying to claim? Not only that -- I am also claiming that this CAN'T POSSIBLY HAPPEN if you don't use .NET. For the 20 year history of Microsoft operating systems there are ZERO incidents of some type of malware modifying native binary executables such that when they run, they do their task and then something subtly malicious. Can't think of anything like that until .NET strong name signature checking compromises came around! -- Ubuntu MOTU Developer and Forums Council |
|
  AB Premium join:2006-04-04 Leesburg, VA
| reply to jdong said by jdong :. . it's a shame people are suddenly using this to fear-monger the .NET framework as if somehow non-.NET native based runtimes are not affected by tampering in this manner? You're saying then, that if I gave remote Administrative write permissions to some pimply-faced Russian teenager, he could do more than alter my .NET Framework .DLLs?
Is that what you're trying to claim?  |
|
  jdong Eat A Beaver, Save A Tree. Premium join:2002-07-09 Rochester, MI clubs:  
| reply to SUMware Right, exactly. And it's a shame people are suddenly using this to fear-monger the .NET framework as if somehow non-.NET native based runtimes are not affected by tampering in this manner? -- Ubuntu MOTU Developer and Forums Council |
|
 SUMware Premium join:2002-05-21
| reply to SUMware As stated before: said by whitepaper : It is important to mention that the technique described in this paper is considered as a post exploitation type attack! Such attacks are usually deployed after an attacker has managed to penetrate a system (using some other attack) and want to leave backdoors and rootkits behind, for further exploitation. In other words, changing the Framework requires administrator level privileges.
And, although it goes without saying - you must have administrator level permissions to overwrite the DLL, since this is a post exploitation attack
|
|
  AB Premium join:2006-04-04 Leesburg, VA
| reply to redwolfe_98 said by redwolfe_98 :. . i am not that familiar with working with "hewlett-packard" drivers, so i don't know if you can work around not having "NETFramework", with them, or not.. in my experience with installing the regular HP driver-packages, which is the only ones that i have used, NETFramework is installed as part of the installation-process, when the drivers are being installed.. The HP AIO printer I use (1200 series, which is an older one) has no reliance upon .NET Framework. |
|
  jdong Eat A Beaver, Save A Tree. Premium join:2002-07-09 Rochester, MI clubs:  
| reply to SUMware Well I'm not sure if I consider this much of a security problem -- I mean, replacing a .NET library with a malicious one with similar API calls but malicious payloads causing bad effects should NOT be a surprise.
That's like saying replacing Notepad with a reformatter causes you to lose data when clicking on a Notepad shortcut later on. You need to be priviledged in order to be able to tinker with the actual framework .dlls to begin with, at which point you can reign so much hell on the system that this is a moot point. -- Ubuntu MOTU Developer and Forums Council |
|
  salzan Experienced Optimist Premium join:2004-01-08 WA State
| reply to redwolfe_98 said by redwolfe_98 :the ati driver, alone, does not require NETFramework, but the "catalyst control center" does require it.. You can use ATI Tray Tools instead of the Catalyst Control Center. No need of .NET for ATI cards.
I have avoided .NET completely. |
|
 OZO Premium join:2003-01-17
| reply to redwolfe_98 If in the printer package you have a folder with *.INI file along with set of other files (usually with *.dl_ extensions) you may install the driver directly. In this case you do not have to run any "setup" program from the package (and it will not install any .NET). That's the way I install my drivers. |
|
  NetFixer Freedom is NOT Free Premium join:2004-06-24 Murfreesboro, TN
·Vonage
·AT&T Southeast
·Cingular Wireless
·AT&T CallVantage
1 edit | reply to redwolfe_98 said by redwolfe_98 :i agree with you, netfixer.. i hate having "NETFramework" installed, but my ati (video card) driver-package requires it.. as far as i know, hewlett-packard "printer" driver-packages also require "NETFramework".. That sux for you. 
Fortunately for me, the ATI video cards and HP printers in use on my Windows 2k & XP systems work just fine using the builtin O/S drivers (the same applies for my Linux systems), so no .NET crap was required on my Windows systems. I did try the ATI supplied RADEON package on one PC, but the overhead and security risks of the .NET crap made me remove it after a brief test. I saw no benefit to me for using the bloated ATI package. -- 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 |
|
 redwolfe_98
join:2001-06-11
·RoadRunner Cable
1 edit | reply to OZO said by OZO :What if you will install driver only - does it require .NET too? the ati driver, alone, does not require NETFramework, but the "catalyst control center" does require it..
i am not that familiar with working with "hewlett-packard" drivers, so i don't know if you can work around not having "NETFramework", with them, or not.. in my experience with installing the regular HP driver-packages, which is the only ones that i have used, NETFramework is installed as part of the installation-process, when the drivers are being installed.. |
|
 OZO Premium join:2003-01-17 1 edit | reply to redwolfe_98 What if you will install driver only - does it require .NET too? |
|