Rootkit.TmpHider

Discussion in 'malware problems & news' started by sergey ulasen, Jul 12, 2010.

Thread Status:
Not open for further replies.
  1. trismegistos

    trismegistos Registered Member

    Joined:
    Jan 29, 2009
    Posts:
    363
    Who needs endless patches, upgrades and updates, when default-deny security policy restrictions is enough. Ask noone_particular. :)
     
  2. Czerno

    Czerno Registered Member

    Joined:
    May 16, 2005
    Posts:
    37
    Software restriction policies don't exist in Windows pre-XP. I'm not sure how SRP could mitigate this flaw by the way, it's not running an executable in the usual way, rather as a by-product of the careless loading of a library by an internal function of the Windows shell : SRP wouldn't be triggered.
     
  3. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    trismegistos used the phrase, default-deny security policy restrictions and wasn't necessarily referring to Software Restriction Polices of XP/Vista, since he mentions noone_particular who uses System Safety Monitor (SSM) and has default-deny policies set up through that program.

    This exploit is really no more dangerous than any other if you understand that it's use is to install a malware executable. In this way, it's no different than a PDF or FLASH exploit: all three use remote code execution to trigger the exploit.

    This Link exploit just happens to be more sensational because it uses a feature (.lnk short cut files) to do the dirty work. The fact that just viewing the shortcut will trigger the installation of the malware is really no different than viewing any web site that has a remote code execution exploit embedded: both exploits use code to trigger the malware without any user interaction.

    With this in mind, trismegistos can make the statement that he does, speaking for those who have the type of security in place that he refers to.

    regards,

    -rich
     
  4. Rampastein

    Rampastein Registered Member

    Joined:
    Oct 16, 2009
    Posts:
    290
    I must agree with others about keeping their systems updated, if an user is running Windows 2000 or an unsupported version of XP he is putting him/herself at risk. No reason to bash MS if you're not keeping your systems up-to-date.

    Interesting information is this thread about this vulnerability though.
     
  5. CloneRanger

    CloneRanger Registered Member

    Joined:
    Jan 4, 2006
    Posts:
    4,978
    Here's a different view, not so quick, or easy :D

    *

    @ Revo59ndx

    Welcome to Wilders.

    Even the official MS patch isn't perfect

     
  6. Czerno

    Czerno Registered Member

    Joined:
    May 16, 2005
    Posts:
    37
    The perfect solution - not a workaround, corrects the error at the root by replacing the offending call (LoadLibrary) with an appropriate call to LoadLibraryEx that does not lead to code execution whenever Windows tries to locate an icon for a malicious link (lnk OR pif). It does precisely what MS programmers wanted from day one :

    Viktor's patcher, with ASM source !

    -http://nemesis.te-home.net/News/20100723_Patch_for_0day__LNK_file_handling_vulnerability_up.html-


    I've asserted the code is sound and clean, and then patched my Windows 2000 SP4 - it rocks !

    Covered : Windows 2000 SP1 and SP4, Windows XP no SP, SP1, SP2, SP3.

    Arguably Viktor's method is better than the official patch where both apply. However I am not recommending users of a supported OS install this, for reasons of ulterior compatibility.

    The caveat : the program can only patch versions of shell32.dll which Viktor has examined. Some versions from special updates or QFEs may fail the patching (the program will report accordingly and should break nothing).

    Enjoy !
     
    Last edited by a moderator: Aug 6, 2010
  7. Czerno

    Czerno Registered Member

    Joined:
    May 16, 2005
    Posts:
    37
    Typo: the name's Vektor, not Viktor ! Sorry...
     
  8. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571
    Sigh. The patch isn´t supposed to break LNK files. Read my answer to you on the previous page. If you manually open a malicious LNK file, any malware the LNK file points to will run. This is how it´s supposed to work. This does not somehow make the official patch imperfect. Stop the FUD.

    Have you tested this? Because people who have say SRP is triggered. SRP covers LoadLibrary, if you have SRP applied to libraries as well.
     
  9. CloneRanger

    CloneRanger Registered Member

    Joined:
    Jan 4, 2006
    Posts:
    4,978
    @ Czerno

    Thanks, previously posted ;) Nice to hear it's worked for you. How do you know for sure though, what did you test it with ?

    I never said it did :p Take it up with Siemens, they published what they did, i just passed the info on. They are either right or wrong !
     
  10. aigle

    aigle Registered Member

    Joined:
    Dec 14, 2005
    Posts:
    11,164
    Location:
    UK / Pakistan
    I can think of a scenario. A malicious .lnk file is on a USB stick along with a malicious dll. User inserts the disk in his PC and malicious dll is loaded into explorer.exe. It can capture data and leak it out via explorer.exe. Most HIPS like SSM will not intercept library loading.
     
  11. CloneRanger

    CloneRanger Registered Member

    Joined:
    Jan 4, 2006
    Posts:
    4,978
    And the beat goes on ......

    Sounds a "bit" dangerous too me :eek: Just goes to show what can be done with insecure systems, policies, and people.
     
  12. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    First, the ~.tmp file has to execute to load the DLL. I'm going to assume that with his default-deny rules, nothing can run from USB. I'll ask him about this.

    ----
    rich
     
  13. aigle

    aigle Registered Member

    Joined:
    Dec 14, 2005
    Posts:
    11,164
    Location:
    UK / Pakistan
    I am not talking about this particular malware. I was just thinking about a malicious dll being loaded via lnk exploit.
     
  14. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571
    I was commenting on what you said. What you said was this:
    Your quote from Siemens does not, in any way, prove that the patch isn't perfect. For some reason, Siemens seems to be talking about normal LNK file functionality (you click on it, it executes whatever the LNK points to) as if it was some kind of a problem or flaw. Sure, they're right that if you open a malicious shortcut, it executes whatever malicious file the shortcut points to. What I'm saying is that this is not surprising, and it's not an issue. It's just precisely how shortcuts are supposed to work.
     
  15. CloneRanger

    CloneRanger Registered Member

    Joined:
    Jan 4, 2006
    Posts:
    4,978
    @ Windchild

    OK sir, point taken ;)
     
  16. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    That should be easy to block:

    lnk-dll.gif
     
  17. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    Rmus called my attention to this thread. I've tried the POC on XP-SP2 and Win2K-SP4. The POC didn't work at all for me on XP. It would partially function on 2K if I manually launch it. SSM immediately intercepted it. If I insert a standard U3 USB stick, SSM intercepts the autostart.

    Regarding the ability of a default-deny policy implemented by SSM (or another good HIPS), both the free and pro versions of SSM will intercept the attempt to utilize rundll32 to execute a dll. With the pro version, the user can whitelist specific command line parameters as well. SSM can also make blocking rules for entire folders for applications, drivers and DLLs contained in them. If the user took the time to set the allowed parent-child settings and didn't give system components like rundll32.exe or explorer.exe blanket approval to do/launch everything without restriction, SSM will defeat such exploits.

    Regarding the issue of MS putting those who use unsupported operating systems at risk, this doesn't hold up. Using a supported system doesn't prevent you from being at risk. Any OS that's default-permit is at risk to some degree. It is not possible to patch your way to being secure. I might not agree with their artificially accelerated rate of planned obsolescense for the sole purpose of parting users from their money, but the choice is still mine. I can choose to pay for a newer supported system, or choose to use what I have. I choose to provide my own support. The statements regarding unsupported systems being at risk needs to be qualified. They're at risk when used with a default-permit policy, especially if they're being run in administrator mode. It's not that important how you implement a restrictive or default-deny security policy. Both built in tools and 3rd party software can do it. Each has advantages. What matters is that you take the time to do it right. Don't get lazy with the rules for the core system components.
     
    Last edited: Aug 8, 2010
  18. trismegistos

    trismegistos Registered Member

    Joined:
    Jan 29, 2009
    Posts:
    363
    Nicely put, Rmus and noone_particular.

    I am not sure, but, would that require dll injection and other possible processes which would trigger any Classical HIPS? But it is indeed a privacy concern (leaking of private data via explorer.exe), I wish experts can shed some light.

    Most Classical HIPS can intercept dll loading. In the case of a malicious dll being loaded, what does a malicious dll do which would not trigger a Classical HIPS like SSM. And as noone_particular said, both free and pro version can prevent dll loading.

    These for e.g. are blocked consequently by SSM free in cases malicious dll loading was allowed:
    * Malware and Rootkit Installation
    * Driver Loading
    * Program Execution of additional malware executable that was able to be downloaded
    * NT Services Installation and State Change
    * Program State and Memory Modification
    * Thread and Process Suspension and Termination
    * Direct Physical Memory Access
    * Global Hook Installation
    * System Registry Modification
    * Window Opening
    * IE Settings Change
    * Startup Menu Modification

    I can think of SSM free not able to block low level disk access once malicious dll was allowed but the pro version can. And so the importance of default deny policies as what Rmus and noone_particular championed.
     
    Last edited: Aug 8, 2010
  19. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    How would explorer.exe leak data? I can't speak for Vista or Win-7, but on XP and older systems, there's no reason to give explorer.exe internet access, unless that little preview it shows in the folders is important to you. Both SSM pro and any decent firewall will stop that. That's one reason I feel default-deny should be applied to internet access.
    A lot of the features of the pro version are redundant. Most of them wouldn't come into play unless the user or a poorly configured ruleset already allowed something unwanted. The free version for instance has a "keep process in memory" option which restarts a process if it's terminated. It also prevents a process from terminating another unless the user permits it. If the user or the rules don't permit it, the keep process in memory option won't be used. The same applies to low level access. It wouldn't need to be defended against at all unless a malicious process was already allowed.
     
  20. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    Same here.

    For sure.

    Unfortunately, risk is not talked about enough. One other person I've noticed over the years who mentions risk or risk assessment is BlueZannetti. And so it's no accident that the opening of his informative thread on PC Security includes this:

    Securing Your PC and Data
    https://www.wilderssecurity.com/showthread.php?t=252253
    I use that approach to maintain that one can have a secure system no matter the Operating System or Browser.

    Note that this is not to suggest that people shouldn't upgrade to the latest Operating System, or another browser, if that provides a better peace of mind.

    Nonetheless, if a person is comfortable in providing her/his own support with whatever Operating System/Browser/PDF Reader/Email program is being used, then it's not fair to pass judgment by making blanket statements from a distance as to whether or not that person has a secure system.

    regards,

    rich
     
    Last edited: Aug 9, 2010
  21. trismegistos

    trismegistos Registered Member

    Joined:
    Jan 29, 2009
    Posts:
    363
    I completely agree. Explorer.exe asking for internet access in XP is a dead-give a way of a questionable behaviour.

    I know this is already moot and academic when one's system is protected by default-deny policies including internet access. I would like to ask. What if the process in question is your default web browser which was obviously given default-permit internet access was the one in relation to what aigle raised on which a malicious dll was allowed to load, capture data and leak it out via that default web browser? Does it need dll injection or process modification or any? So essentially, the malicious activity will trip a wire and trigger even with SSM free.
     
    Last edited: Aug 9, 2010
  22. Czerno

    Czerno Registered Member

    Joined:
    May 16, 2005
    Posts:
    37
    May I ask which proof-of-concept you did your experiment with, and how you were set up ?

    Would it be that you tried IvanLeFou's "svckme" link and its associated dll.dll ?
    Then you realise, I hope, that in order to see the result, you need to hook a kernel debugger to the box under test (such as MS kd, or SoftICE), or more simply run Sysinternals DebugView.

    Otherwise the PoC is completely silent, it doesn't follow you're not pwned :=)

    Indeed the exploit works on all (unpatched) versions of Windows NT, 2000, XP and up. If you concluded otherwise, you are hmm... not so competent.

    --
    Czerno
     
  23. wat0114

    wat0114 Guest

    Although I'm not sure about Vista/Win7, it is actually normal behavior in XP. As for controlling this normal behavior, it can't be expected of anyone not running a software firewall with application outbound network control, or from those who don't want to bother with it.
     
  24. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    By "exploit" I assume you mean the "POC," because without testing the exploit on one's particular system, you can't make a blanket statement.

    Regarding your comment about noone_particular's competency with the POC: since I also could not get it to auto-execute, I'll respond with my tests on Win2K SP4.

    Here is the icon:

    tmpHider_debug-iconprop.gif

    1) I connect the USB drive and navigate to it and nothing happens:

    tmpHider_debug-no.gif


    2) I manually click the shortcut file and my security prevents the loading of this unauthorized DLL:

    tmpHider_debug-manual.gif

    3) I turn off my security and manually click the shortcut file to show that it does work if able to run:

    tmpHider_debug-run.gif

    Maybe the actual exploit would run on my system, maybe not. But this whole exercise with the POC illustrates why I normally don't like them, as I've already indicated in this thread. Without testing the actual exploit -- which is not possible in this case unless obtaining a USB stick encountered in the wild -- one can't be sure whether or not it would work.

    Meanwhile, as indicated by several besides myself that Default-Deny security nullifies this exploit, it's a moot point whether or not it would run on an unsupported/unpatched system:

    • Patching an exploit like this is reactive.

    • Preventing any exploit from launching unauthorized executables is proactive.

    Using a .lnk file to launch an unauthorized executable is no different than using .pdf, .ani, .wmf files to do the same.

    It's the same old stuff, nothing has changed and preventative measures are the same.

    _____________________________________________________________________________​


    NOTE: The above tests pertain only to my Win2K system, and not anyone else's. I would never make a blanket statement that a POC would always work or not work on every such system.

    EDIT- NOTE 2: Several others earlier in this thread could not get the POC to run. Is it possible we've all missed something??

    regards,

    -rich
     
    Last edited: Aug 9, 2010
  25. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    Rmus,
    Your 2K results almost exactly duplicate mine. IMO, a POC should be a clear demonstration of functioning exploit, such as the one on this older PDF POC.
    It's actually been "normal" since the 98 days. Explorer generates a little preview of documents, pages, links, etc whenever the file or link is highlighted. If the link is to a website, explorer will retrieve a copy of the page for that preview. It was supposed to be a little convenience feature, a very useless one IMO. The preview is too small to be of any use, and it requires giving a core OS component internet access. This not only makes it an unnecessary part of the attack surface, it also creates an easy way for a malicious app to connect out if the system does get compromised. IMO, it's one of many examples of things that are "normal" for windows but not necessarily desirable from a security standpoint, like ports opened by unnecessary services, waiting for someone to find a way to exploit them. It's also an example of why I consider an application aware outbound firewall a necessity.
    Eventually, any application or process that opens unknown content or connects to the web will be successfully exploited. But if that exploited vulnerability does not lead to the execution of malicious code, it's a dead end. Using the above linked PDF POC as an example (and a vulnerable PDF app from the same time period), if your PDF reader was integrated into your browser, the POC would succeed against most any security package. If the PDF is freestanding, SSM would intercept the PDF readers attempt to launch the browser. There's too many variables in your question to allow a simple answer. The parent-child settings and the amount of integration between different apps, along with the specific activity of the malicious file(s) will all factor in. Any decent HIPS will detect DLL injection. The better ones will detect process modification and allow control of the parent-child settings. Beyond that, it's primarily a matter of what did the user allow or block in the rules. The scenario you're describing is using HIPS to enforce a policy of containment or isolation. The better ones can to a point, but its' not what they were primarily designed for.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.