What Kind of Malware Can Bypass Anti-Exes?

Discussion in 'other anti-malware software' started by Brandonn2010, Jun 15, 2012.

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

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    I imagine FF and SeaMonkey are similar enough. I was hoping you wouldn't say chrome or IE. No way I'll install either of them even for a test. Dropping a file is not really a security issue unless it can be made to execute. Browsers drop files all the time. As for Proxomitron, it filters javascript quite heavily here. That's why I asked if I needed to bypass it. I don't have an XP disk. For a virtual system, I'd have to use 2K. The other option is a real system.
    For the purpose of this "test" that's fine. For me, the AE will have to be SSM, which may block the registry file as well. In a real world situation, I'd consider just a "normal" AE insufficient. For me, the AE (HIPS) is one component of an interlocked package of several components, all of which are freestanding but configured to protect each other. That's the biggest problem I have with the way this thread has approached the subject. On a real system, it's not the malicious code vs an AE, HIPS, or the built in mitigation features. It's how the package works as a whole. In the end, that's what really matters. Beating any single app or feature is entirely possible, maybe even easy. Beating an interlocked and layered package is a much taller order.
     
  2. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    Dropping a file just signifies malware being able to write to the disk. If it's able to write to a file that already exists I think that could be plenty dangerous.

    Being able to write to the registry is quite dangerous as well.

    If I have enough fun bypassing a typical AE maybe I'll do something more fun like bypassing SSM. I think it would be interesting to see if some of the things I've learned could actually work for that.
     
  3. 1000db

    1000db Registered Member

    Joined:
    Jan 9, 2009
    Posts:
    718
    Location:
    Missouri
    AE's are designed to keep the file written to disk from executing, which means that the file dropped is no more dangerous than anything else. I would think that in order to be considered a legitimate bypass; the execution of the dropped file, with the AE being fully functional, should be critical. For what it's worth I always considered social engineering and script blocking to be the biggest weaknesses with AE's. You might well be able to break or exploit an AE protection; I'd definitely be interested to see your results. Go for it! ;)
     
  4. ronjor

    ronjor Global Moderator

    Joined:
    Jul 21, 2003
    Posts:
    107,481
    Location:
    Texas
    Just to be clear, this is not a anti-malware testing forum.
    https://www.wilderssecurity.com/showthread.php?t=180128
     
  5. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    If I can drop a .dll file with the right name next to the right .exe the next time it's launched I'll have loaded the .dll into RAM. Just a quirk of Windows.

    That's one of a million examples where writing to the disk is a great way to take over a system. If you can write to a file you can patch or corrupt it to, meaning configuration files for programs can be changed.
     
  6. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
  7. STV0726

    STV0726 Registered Member

    Joined:
    Jul 29, 2010
    Posts:
    900
    ^ +1

    This is paramount.
     
  8. Spiral123

    Spiral123 Registered Member

    Joined:
    Jan 10, 2007
    Posts:
    130
    +1 as well.....
     
  9. They can, if you're not careful (e.g. surfing an untrusted site in one tab while making an online purchase in another).

    Also you don't necessarily need to execute something to get persistence. Perhaps an attacker could e.g. put a malicious DLL on the hard drive, and create a registry entry to load it into some process. Mark Russinovich's last lecture featured a trojan like that IIRC.

    Policy sandboxes, filesystem sandboxes, hardening against memory attacks. The problem with Windows is that even now it's way behind the times on all those things.
     
  10. STV0726

    STV0726 Registered Member

    Joined:
    Jul 29, 2010
    Posts:
    900
    Eh...behind in comparison to what? Certain breeds of Linux? I'd believe that.

    Certainly you're not talking about Mac OS X, which is miles behind Windows.
     
  11. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    What if your victim is way too paranoid, and it only allows .dlls by hash value and digital signatures? Now, you got to both steal a certificate, or do some collision, which is probably way out of your resources. But, what if only .dlls whitelisted by hash can run?

    So, how are you going to bypass the hash value whitelisting... without the so precious collision, and assuming that it's using MD5? Maybe it's possible to crack others, but it would probably require way lot more resources to accomplish... so, it wouldn't be so trivial to do it.

    You may drop a .dll file with the right name next to the right .exe and the next time it's launched you won't have loaded the .dll into RAM., because the anti-executable didn't allow the hash to run, at all... no hash match... or not even a digital signature.

    Or, can you? If you can, than that would be far more interesting. ;) Because, I know anti-executables can be bypassed. The question I got is: Can they be trivially bypassed as you say? And, I'm not having under consideration malware that never touches the disk... I don't consider something that only runs in memory a bypass... and simply because it's out of any of the current anti-executables protection scope. So, if they can't protect against that, they can't be bypassed that way. Otherwise, anything could be considered 100% bypassable in many ways, because it's out of the scope of their protection.

    So, you will provide a PoC that will exploit Firefox, and it will place a .dll with the right name, next to right .exe, and it will run the next time the process is run, regardless of how well an anti-executable is configured and regardless of how it works?
     
  12. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    I'll be interested to see if you can replace/modify a file that's necessary to an application or the OS itself without my system alerting to the action or blocking it entirely. I'm also quite curious to see which of my OS defends itself better.

    Been a long time since I installed or used FF.
     
  13. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    Gullible Jones is correct. An attacker does not need to execute a new payload just to gain persistence. They can simply do it from within the Whitelisted process. I've confirmed this now with two programmers.

    Coincidentally I blogged about Trusted Path Execution last night (Grsecurity 'Anti-Executable') and decided to go in depth into AE's. https://insanitybit.wordpress.com/2012/06/26/trusted-path-execution-and-antiexecutables-10/

    @M00n
    I know about doing it by hash. The .dll was only one example of what I can do if I can write to the disk. If I want persistence, of course, I could simply write directly to the registry.

    A collision is definitely outside of what I'm capable of and it would be a waste of my time (and money, which I do not have hundreds of thousands of lol) anyways as I can do so much without it.

    Assuming they aren't using any hash to check the .dll file trick is great. If they are there are tons of other things I can do.

    If I drop 'antimalware.txt' on my desktop and call it an AV and a virus installs does that nto count as a bypass?

    An AE does virtually nothing to prevent infection. See my blog for details. Yes, if I do everything from RAM I have bypassed the AV just as if I use ROP on a locked address it's called a bypass of ASLR.

    No, the .dll thing is too easy to mitigate and, again, I'm not interested in hacking anyone's machine here. Writing the custom .dll would also take a lot more time than I'm willing to spend lol

    I'll simply write a startup entry or some other registry key and drop a file somewhere like the desktop. As an attacker that should prove that I can pretty much do anything I want.

    I *might* try to privilege escalate with some tricks I really want to try out (spawning a thread under a new process etc) but otherwise being able ot read/write to the disk and registry should be proof enough that an AE isn't stopping anythin critical at all.

    @Noone_particular

    It's possible I won't be able to. If I'm writing to the registry you'll probably get some alert.

    edit: And let's be honest. If I can do this a hacker can do it in about 1/10000th the amount of time/ effort.
     
    Last edited: Jun 26, 2012
  14. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571
    Or...

    Short answer to thread title: Anti-Exes will be bypassed (or circumvented or avoided, or whatever word you prefer) by any malware that does not infect systems by first creating files containing its malicious code in the file system and then later executing these files using system calls traditionally monitored by Anti-Exes such as the usual CreateProcess and LoadLibrary calls. Assuming the malware is spread by a drive-by exploit in a browser for example, if the exploit shellcode attempts to do something other than the traditional create evil file then execute evil file, an Anti-Exe will be bypassed by it. Malware that only lives in memory will bypass Anti-Exes. What would a malware lose if it couldn't freely create and execute files? The easiest way to gain persistence on the system, keeping the infection alive until it is detected and killed. Persistence is not necessary for an attack to succeed in its goals, but not having it can make things annoyingly difficult. Let's assume your goal is to steal banking credentials from Joe Average, and you do this by memory-only malware waiting for Joe to log in to his bank. Every single damn time Joe reboots his little laptop or does anything that kills the infection in memory like killing the process that happens to be running the evil code, your infection dies, and you have to get your malicious code running on it all over again. Tedious. Maybe Joe doesn't visit his bank every day. Maybe he does it twice a week instead. If you infected him by a drive-by on some website, will Joe really run into another of your infected websites any time soon? And if he will, will the exploit you used the last time still work, or did some automatic update patch the vulnerability it used? The traditional way of hiding the malware in the file system at least makes sure you don't have to try to keep reinfecting the system all the time to keep your malicious code alive. That's all, folks. :D

    I realize this may sound like nitpicking, but. If an attacker puts a malicious DLL on the hard drive, and creates a registry entry to load the DLL into some process, what does that do? It loads the DLL into some process and then executes the DLL inside that process. That is, if the DLL contains any code that will execute (if it's just a library for graphics, for example, and contains nothing that will run, then, yeah, nothing will be executed, but not because of a lack of trying).

    Any Anti-Exe that doesn't monitor DLL loading can be bypassed while still using the traditional method of storing malicious files on the disk to gain persistence - just make your malicious file a DLL, and you've got it. If you're a really funny dude, you don't even need any of the boring old autostart methods malware likes to use, you could just try to use a DLL hijacking vulnerability in some common enough software and have that software execute your evils for you. Such plans might be screwed up by file permissions, for example: if you want Firefox to load your DLL for you, and you try to place your DLL in Firefox's folder, but because the user is running as non-admin and has no write access, that sucks. So, it goes without saying, that Anti-Exes, like pretty much anything related to security, works better when you're not running around with A God Am I privileges on the system. :D
     
  15. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    The DLL was purely one example. You can gain persistence without it just by making use of read/write access.

    I think anyone who visits this forum understands that all things are bypassable. It's all a matter of cost. The cost is, in this case, basically not there - or at least that's what I'm arguing.

    I know at least one user isn't running a fully patched XP if I recall it's noone_particular. Packaging in some privilege escalation exploits that can be used from within Firefox would be fun since at that point I can do just about anything from then on.

    But I think I'll write the POC regardless of whether or not anyone believes the cost is low. Its just going to be a fun project.
     
  16. Sordid

    Sordid Registered Member

    Joined:
    Oct 25, 2011
    Posts:
    235
    Think the problem here is that there is no "standard" for AE aside from one inferred by its name. This has been a source if contention the entire thread. So believe it a wee bit wise to suss that rather than invest coding time.

    In order to BYPASS an "AE", one must *execute* arbitrary code *without user interaction*.

    Anything else is circumvention and exploit through non-design. An XSS attack is not a UAC bypass for example.

    A true AE can be bypassed via collision at the whitelist.

    Moonblood has been on point this entire thread. & IMO solved this hyper-ambiguous question pages ago.

    Rather easy if you're just willing to analyse deeper: if AE exploits are so cheap and basic...where are they all? & why are people using collisions and jacked china certs if a simple PoC from some random WildersSec member can trump it off some tinkered metasploit gear. Occam's Razor not required here.
     
  17. SpikeyB

    SpikeyB Registered Member

    Joined:
    Mar 20, 2005
    Posts:
    479
    I don't doubt that you can drop a file and make a registry change. When I used XP with SRP enabled I came across a number of sites where I would get an alert from SRP telling me a file had been stopped from running. When I checked, there was indeed a file (always an .exe) on the HD. Rmus has plenty of posts explaining similar events

    What I question is can you drop a file that can actually do anything useful (in a malicious sense). An .exe would be blocked, a .dll would be blocked (at least with some AE products).

    I don't feel that what you are suggesting proves you can bypass an AE (in the sense that you can run rogue files from the HD).

    I guess the RAM attacks you talk about are possible as mentioned in this post from 2005: https://www.wilderssecurity.com/showpost.php?p=536454&postcount=33 and I am sure there is plenty of damage you could cause in a single session. Why is the general infection method still to drop a file and a registry entry to start the file at every boot? I guess there is a reason why things have not changed much since then.
     
  18. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    Because no one actually uses an AE lol so why would anyone bother?

    Sure, I could.

    What I've been arguing from day 1 is that an AE doesn't stop anything important. It does nothing but prevent a new file that's on the HDD from executing. That's meaningless in terms of protection, anything that .exe can do you can do from the exploited program. It's a matter of ease of use for mixing and matching payloads with exploits - I explain this in the blog post. If your question is "Why doesn't malware already work like this?" I cover it in the post, it's nothing critical, it's more about the fact that malware has become a business via blackhole exploit kits etc and being able to mix/match payloads and exploits helps.

    The simple matter is that without dropping and running a .exe I can do anything that any other malware is capable of doing.

    What's more interesting is that I can probably run a file from the disk even with an AE given enough motivation. Without a whitelist for .dll files this is trivial. With one I'd probably need an escalation exploit so I can start disabling and enabling startup entries.

    So basically:
    1) Get into RAM
    2) Drop the file
    3) With my shell I use a priv escalation exploit
    4) I start enabling and disabling relevant startup entries

    But even without that I can still do a huge amount of damage just by reading/ writing to the registry/ disk.

    So whether you consider it a bypass or not doesn't really matter. The simple *fact* is that I can take over a box with just as little effort involved whether you've got an AE or not.
     
  19. LoneWolf

    LoneWolf Registered Member

    Joined:
    Jan 2, 2006
    Posts:
    3,652
    Personally I'd like to see proof on this, and by proof I mean a working POC, not another post on how this can be done. No offense intended but like the saying goes "The proof is in the pudding"
     
  20. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    It's strange that I need to prove it as you should know that a compromised process has the same rights as a regular process so the logic goes:
    Firefox.exe can write to /path/to/file
    Compromised Firefox.exe can still write to /path/to/file

    ie: an attacker can write to /path/to/file

    But, yes, I'll write the POC in a few weeks.
     
  21. SpikeyB

    SpikeyB Registered Member

    Joined:
    Mar 20, 2005
    Posts:
    479
    I hope you have the patience to spell this out for me.

    You take over a process in memory and write a startup entry in the registry. I'm with you so far. What does the startup entry actually start? I presume it starts a file from the HD. If that file is a modified or new file the AE will stop it running (I'm assuming a hash not a path rule to block execution).

    Are you perhaps saying you will disable the AE startup entry?
     
  22. LoneWolf

    LoneWolf Registered Member

    Joined:
    Jan 2, 2006
    Posts:
    3,652
    Right, I understand this.

    OK thanks, I'll be looking for it.
     
  23. STV0726

    STV0726 Registered Member

    Joined:
    Jul 29, 2010
    Posts:
    900
    Just want to make sure everyone's aware that Windows since XP has been well aware that DLLs can cause damage and by default Software Restriction Policies apply to DLLs as well, along with many other "Designated File Types" that can be executed.

    SRPs also have an add-in functionality that I've always used in which you can specify specifically that only administrators can determine who is a trusted publisher. Two checkboxes are available on that setting console, dealing with verifying publisher information to make sure it's valid. I leave those both ON. This is under SRP - Trusted Publisher (Authenticode).
     
  24. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571
    Creating persistence by making use of write access without using it to create new executable files (which includes modifying existing ones, thus changing the hashes, which ought to be noticed) on the system can be somewhat non-trivial, though, and can in many scenarios be very easy to detect. For the purposes of discussion, how would you do it? Off the top of my head, I'm inclined to believe that the smallest changes are hardest to spot, so targeting some legit program's configuration file would be a prudent measure, as such files change constantly and are unlikely to be monitored for changes. Let's say it's a browser's config file, and you use that to have the browser load your exploit site every time the user runs the browser. That way, you can keep updating the exploits as you go, and you'll avoid making anything but the smallest changes to the local file system.

    The cost of moving away from the create-file-then-execute-file method of infecting systems is in my opinion larger than you believe, but certainly not so large that it would stop the attacks. The limitations on exploit shellcode length, the complications in gaining persistence for the malicious code, and such, make the old way much more appealing.


    Though I think I understand what you're trying to say, that is a somewhat hilarious definition of the bypass, because then every remote code execution vulnerability exploited is a bypass of an "AE", and AEs were certainly never meant to prevent such exploits and couldn't, and that is certainly circumvention through non-design as you put it. I think a rather more useful definition of an AE bypass if you want to be strict with the terminology (so that bypass does not include "anything that just completely avoids doing what the security measure in question is trying to prevent", memory only against AE and XSS against UAC and so being the idea here) would require executing arbitrary code present in a file on the file system, or something to that direction, so you'd rule out the memory only approaches which exploit shellcode certainly falls under. Using such a definition, scripts would bypass the stereotypical AE - office macros etc. As has been said before, that's pretty much all an AE does: prevent executable files existing in the file system from being executed.

    Except for the trivial persistence part, which will in my opinion continue to be an important consideration in the malware coder's mind in the future as well, all the way until the day that even Joe Average has systems that seldom reboot or shut down important processes.

    I'd hope he's saying something like this:

    He exploits a vulnerability to get his evil shellcode running in memory in the exploited process, but instead of then downloading and executing malicious files, he does his malicious work with the exploited process - a process that the user started himself and looks entirely trustworthy still - instead of any new, independent malicious program. An exploited Firefox, with evil code running inside it telling it to do evil stuff, can do everything the user account it's running in can do - not counting sandboxing, virtualization, integrity levels and what not for the sake of simplicity - so the malicious code now running inside it can read your files or create new ones or change stuff in the registry, anything the user could do. Then, if he wants persistence for his malicious code, that's where the registry startup stuff comes in, as he can try any number of tactics since he has write access now: he could create a registry entry, yes, such as even a normal HKCU Run key that loads Firefox with stern orders to open his exploit website's URL right up, so that every time the user logs in Firefox automatically browses to his evil site and gets owned (as long as the vuln isn't fixed). He could then attack other processes running as the same user, to get his evil code inside Explorer's process, for example, since that's always running anyway if someone is logged in.

    That kinda thing, basically.
     
    Last edited: Jun 26, 2012
  25. STV0726

    STV0726 Registered Member

    Joined:
    Jul 29, 2010
    Posts:
    900
    From what it sounds like you're saying I'm inclined to agree...

    If I'm understanding you correctly, you are outlining the difference between an actual bypass versus a circumvention.

    A true bypass of an AE would be using an exploited browser to do dirty deeds. Or, using an admin exploit to bypass restrictions the AE places on non-admins.

    But what would you consider a RAM-only attack? A circumvention?

    As for who uses AEs...well...businesses. Whether or not they use them primarily for application/employee control or for security is irrelevant. The fact is they use them (along with other app control measures like Novell) so for businesses to be infected malware authors/attackers must first either bypass or circumvent the SRP/AppLocker/Novell policy.

    I think what HungryMan means is very few CONSUMERS use AE....
     
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.