An interesting way to bypass SRP (and potentially other security setups)

Discussion in 'other anti-malware software' started by ssj100, Sep 30, 2009.

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

    ssj100 Guest

    I came across an interesting form of "exploitation" when reading Didier Stevens' most interesting blog. Unfortunately, a lot of stuff he writes goes right over my head. However, I do understand some of what he writes to an extent.

    Basically, the below exploitation (see link at bottom) technique has come about from his attempts at bypassing SRP, even in a LUA - and he has been successful at creating such a POC. The key is that the .dll is not required to be "injected" (where a lot of anti-malware products would then alert the user), but instead it is merely "loaded".

    For my own personal setup, I am well covered even from this type of attack because I combine Sandboxie with LUA + SRP. Since Sandboxie forces containment/blocking of all malware threat-gates, Didier Stevens' unique attack would fail miserably. The only realistic possible hole is if I "recovered" an unknown/untrusted file (that contains his unique attack) out of a sandbox and run the file unsandboxed. Again, this is easily solved by always opening any (untrusted/unknown) newly introduced file with a sandboxed explorer.exe - this is easily achieved with great convenience by having a short-cut (in eg. the Quick Launch bar) that opens up a sandboxed desktop for running or manipulation of the newly introduced file.

    My question here is whether this technique could be used not just to bypass SRP, but also to perform more malicious insults like destroying system files. I suspect that this would be fairly easily done, in relative terms.

    So if this technique can be used to compromise your system, what are ways (apart from my own setup and approach) to prevent it? The "scary" aspect of this technique is that ANY file type could contain the code (if the file type was successfully exploited). So we're not just talking about executable file types here. In theory (I think) you could open a .txt file or a .jpg file or a .xml file etc, and get struck down by a clever malicious malware writer.

    I suspect a tightly configured classical HIPS would block this easily, such as Defense+ or Malware Defender, but I'm not 100% certain. I suspect DefenseWall would block this as long as the file was "untrusted", but again, I'm not sure about this. Would Xiaolin or Ilya please like to comment?

    Now as Joeythedude would suggest, it is important to put things into perspective. This is merely a POC. You are probably more likely to get struck by lightning than get infected by an attack such as this. I am merely posting this out of curiosity and interest. Thanks for reading, and here's the link:

    http://blog.didierstevens.com/2008/10/23/excel-exercises-in-style/
     
  2. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    I saw that before. I think I shall just wait until the POC is out and about before worrying. There are bigger fish to fry as they say.

    Sul.
     
  3. aigle

    aigle Registered Member

    Joined:
    Dec 14, 2005
    Posts:
    11,047
    Location:
    Saudi Arabia/ Pakistan
    dll loading wil bypass most HIPS as though many of them can monitor it but it,s not practical to use this feature in daily life.

    Sandboxes wil stop this as they stop untrusted dll loading, but they wil obviously fail if the user wil execute the file as trusted and that might be quite common.
     
  4. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571
    Well, it doesn't really work that way. There is no DLL file involved at all. Not only is there no DLL "injected" into another process, there also isn't any DLL loading at all. In fact there just plain isn't any malicious DLL file involved. Instead, the attack is based on running a macro to inject and execute shellcode. In other words, instead of loading a DLL file, this attack just writes some code of the attacker's choice into a process that you have write access to and then gets the code executed. No DLL, no nothing.

    How interesting is this, though? Consider that for this to happen, the code that tries to do this has to be executed first. In the case of this example, the malicious Office macro would have to be executed before it could attempt to perform this attack. And who says you have to let that macro execute? ;)

    If you can execute arbitrary code, you can of course attempt to do all kinds of things, like destroy system files. In this case, though, that wouldn't work. Why? Because one is running as a limited user, and limited users don't have permissions to destroy system files (only read & execute access to system files is allowed for LUA by default). We can't assume one is running as admin, because then there would be no need at all for such elaborate attacks to bypass SRP, when you could achieve the same just by writing your badware file in the Windows folder and executing it from there much faster and easier. But you could do other things much more useful: after patching SRP checking off, you could just load any program you want and execute it freely in the context of the limited user account - keyloggers, spam bots, DDoS bots, rogue AV, everything goes. Again, though, those would be limited by the privileges of the limited user account, so they couldn't achieve a system-wide infection and would be trivial to detect and remove.

    Tons of ways exist to help prevent attacks like this.

    The first and most obvious is of course: don't execute untrusted code. IOW, someone sends you a word document, and it seems to contain a macro. And you don't know what that macro does. How about just not executing the macro before you do know what it does, and know that it doesn't do nasty things? This will work against social engineering attacks, but obviously won't help against attempts to exploit some browser/plugin vulnerability to do a drive-by attack.

    If common sense doesn't work, then it's up to software. For this example (Office macro performs the attack), any software that blocks Office macros from running automatically would already stop the attack from happening without user approval. Microsoft Office itself could be used to block the macro. If you're going to execute that macro without knowing what it does, then you need something that prevents the macro from writing into the memory of any processes you wish to protect, to prevent the attack from working. If you were running a virtual machine to execute the macro, for example, the attack wouldn't be able to reach the processes in the real system, so it wouldn't be a very useful attack.

    Not really a big deal attack in any way.

    No. Where did you get the idea that any file type could be used for this? You can't put some malicious script in a .txt file and have the script magically execute when you open the file in Notepad. For that to happen, the program you use to open the text file needs to either 1. try to execute the script because that's how the program was made to work (Office software will try to execute macros, of course, since that is what they do, assuming macro security settings don't prevent it) or 2. have an exploitable vulnerability that makes the program execute the script when you format the script in the right way. This technique isn't special in this regard in any way. You can't exploit file types - you can only exploit the software that handles those file types. If you can. In the case of text files, for example, good luck finding the needed vulnerability in Notepad. :D Of course, if one was so inclined, they could write themselves a "text editor" that not only displays text files but also tries to randomly execute everything found in them, and that would make attacks like this work from text files. But my suggestion would be: don't do that. ;)

    So, in summary, the attack isn't very interesting. Nor very scary. It's the same as they all are: if you let untrusted code execute, it can do stuff. Not surprising. However, it should make one realize that nothing is invulnerable. This attack in particular shows how you can get around even a very tight software restriction policy, and many other security software products that don't watch out for attacks like this. And even for those security software that do, the problem remains social engineering attacks. Sooner or later, most users want to do something that requires them to trust a file. You can't install a graphics card driver, for example, if you block it with some HIPS or toss it in a sandbox. And you can't trust that a virtual machine could be used to analyze what the file does before executing it in a real system, because it's not difficult to code routines to check for virtual machines and sandboxes. You could make that task more difficult for the bad guy by using a customized virtual machine, but how many are going to do that? So, ultimately it all comes down to either trusting the source or performing very extensive analysis that will require a lot of skill and a lot of time. Since practically everyone will have to choose option 1, it makes sense to be rather careful with who you trust.
     
  5. wat0114

    wat0114 Guest

    Hi Windchild,

    what about that technique, I forget what it's called, maybe OLE or meta, something like that, where executable file types can be hidden within other, non-malicious file types such as .jpg?
     
  6. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571
    "Expert" is relative, too! :eek: :D

    My point in saying that the attack isn't very interesting was that it's not something to worry about. It isn't really special: there are many ways to prevent and limit the impact of attacks like this. And those methods are pretty much the same as with all other attacks.

    Beating hearts, though... A live beating heart I've seen. That wasn't very interesting. I'd pay money, though, to see a dead beating heart! Night of the Living Dead! :D

    Indeed. Where LUA doesn't entirely prevent something nasty, it often helps limit the impact and/or makes the job easier for third party security software. Least privilege should be a key part in any security policy. Of course, one can certainly choose to operate without, but that does involve some issues that even very sophisticated HIPS and other security products won't solve - like the issue of users being able to access and even modify each other's files, which is not necessarily something you'd want.

    And that's the nature of security - there are uncertainties and surprises. Some remote code execution vulnerabilities could be used to perform this attack. Some software that allows you to write and/or run scripts could be used. And so on. But, as usual, we have to consider how this attack could happen against a real system. And that boils down to either social engineering or exploiting vulnerabilities to do a drive-by. Social engineering attacks ought to be easy to avoid for someone who would actually know about something as obscure as this attack: just don't execute untrusted code, even if it's "just" an Office macro. Doing that prevents all those "install this codec to view this cool vid" and similar attacks that one could use to pull off an attack like this. And the drive-by attacks aren't that bad, either: keep software patched so you don't fall for old vulnerabilities, and try to configure software that is likely to be targeted so that the exploits are less likely to work. For example, simply disabling ActiveX in the Internet Zone in Internet Explorer prevents a vast number of attacks against IE - even if your IE is vulnerable against some unpatched ActiveX exploit. Remote exploits against Adobe Reader for example? Disable the Adobe PDF browser plugin, and you'll kill practically all of those attacks, or at least turn them into a kind of social engineering ("Hmm, a random site I've never been on is telling me to download/open a PDF file even though I didn't click to download any PDFs. I wonder what I should do...") Do enough of that and you'll end up in a situation where it's very difficult for the attacker to get the actual exploit code running, even if you're not running any security software at all. That's pretty much the kind of stuff Rmus always wisely says. So, it shouldn't be a scary attack. :)

    Yes, it's difficult to know. But there are some good indicators of how likely a program is to contain vulnerabilities. Complicated software is generally more likely to have vulnerabilities than simple software (because it's easier to write 400 lines of perfect code than it is to write 4000), for example. And Notepad is very simple. Software that has been reviewed, used and examined for years and even decades is less likely to be vulnerable than new software that is just out of the code monkeys' keyboards - and so on. You could certainly put code that is designed to do nasty things in a text file. The problem is getting that code to execute when that text file is opened in a simple text editor like Notepad. Me? I can't remember there ever being a code execution vulnerability in Notepad. ;) While few things in the world are impossible, I'd be pretty surprised if someone got owned by a Notepad exploit these days. :D

    Well, allow me to clarify. I mention social engineering because, as software security measures improve in an environment, attackers often turn more and more towards social engineering to own systems inside that environment - because social engineering is hard to prevent with software. So, I wasn't speaking of a reputable company shipping software infected with something bad. I was speaking of the way many users are far too quick to trust things, and that makes them vulnerable to social engineering. It's pretty unlikely that Microsoft would send you malware in automatic Windows Updates. But how about some random little software you find in P2P or on some website? How quick should one be to trust that?

    Your analogy about poisoned milk is a good one. Most people buy milk from large markets that have been around for years and have a good reputation - and where there are people who are accountable if some of their products turn out to be bad. Most people wouldn't accept a bottle of alleged milk from some very shady looking, dirty kind of guy on the street that they've never seen that comes out of nowhere to offer it to them when they're not even out to buy milk. This, of course, in the real world. And that's the problem: in the computer world, people don't act like that. In the computer world, people do accept the milk from the dirty street guy, and gulp it right down without thinking, even if they weren't really looking for milk at that time. And then they fall down incapacitated by some drug and get... well, you know. Many people don't know who's shady and who isn't in the computer world, and that's why social engineering works so well. And it doesn't work only against newbies, because many rather advanced users are also far too quick to trust things. I bet someone could own a pretty decent number of systems just by advertising a new "anti-rootkit" on a security forum, and as the forumites download the "anti-rootkit" for testing and of course run it in a real system with admin rights because it won't work otherwise... :D
     
  7. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571
    Basically, there are two possibilities:

    The purpose of hiding an executable file inside a more innocent looking file can be simply to hide the executable file from prying eyes, in which case the idea is that the executable file should not under any circumstances be executed when you try to open the innocent file - otherwise, the hidden executable could be revealed, and if we're trying to hide it, we don't want that. Digital steganography, kind of: you hide your secret exe you don't want the admin to see inside a big image file. If the admin opens it, he sees a picture. You hope that he won't do any more thorough examination of the file. In this case, the executable file inside the innocent file is not a threat at all, in the sense that it could infect the system with something. It won't, since it can't execute. Creating for example image files with other hidden files inside is easy. But those hidden files won't be executed when you open the image.

    The other possibility is that either by design or because of a vulnerability, some program that handles a given file type will try to execute the entire file or some piece of code the file may contain. It's no problem if it's supposed to work that way: .exe files being executed when the user double-clicks on them is of course like it should be. But this can be a problem if the execution is unexpected: if you can put code in a .PNG image file for example and that gets executed when you open the file in an image viewer because of a bug in the graphics rendering engine, then we have a security issue. Some vulnerabilities like this have been discovered and patched. Since such a vulnerability could be used to execute arbitrary code, it could be used for many kinds of nasty things including attempts to bypass something like SRP - limited only by the amount of code the vulnerability allows the attacker to execute. But as said, these are vulnerabilities, and when they get discovered, there's usually a rush to get a patch out and it will be fixed. I'm not aware of any vulnerability like this ever being discovered in Notepad. :D And I don't seem to recall any case where you could just put a complete, normal executable file inside for example an image file and it would then get executed upon opening the image file. Typically it's just a small piece of code that could run.

    So, there really isn't a way to execute code from "innocent" data files unless the program that handles those files is either designed to execute code inside the files or contains a vulnerability that makes it possible. That's why it's reasonable to differentiate between "data files" and "executables", even though it is true that anything could be executed if you simply feed it to some program that has been intentionally or accidentally made to do so. But to worry about text files containing malicious code? There is no realistic reason to worry about it. Start worrying when someone discovers an unpatched Notepad vulnerability that allows executing code from a malformed text file. But let's not hold our breaths while waiting for that day! :D
     
  8. Kees1958

    Kees1958 Registered Member

    Joined:
    Jul 8, 2006
    Posts:
    5,857
    Yep mainstream technology is still about data and processes. When developers stop dreaming about true OO-platforms and seamles processing clouds then it is time for system and security managers to get night mares on this topics.

    GeSWall and DefenseWall contain both threatgate applications and data (only formats with posisble code in it) so they allready provide containment for these future threats.

    Regards Kees
     
  9. wat0114

    wat0114 Guest

    Windchild, thanks again as always for your awesome insight :thumb:
     
  10. Ilya Rabinovich

    Ilya Rabinovich Developer

    Joined:
    Sep 13, 2005
    Posts:
    1,543
    Very old injection technique. Not interesting.
     
  11. Longboard

    Longboard Registered Member

    Joined:
    Oct 2, 2004
    Posts:
    3,187
    Location:
    Sydney, Australia
    Outstanding post.
    Thankyou.
     
  12. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571
    Well, that's a very good way to summarize it. :thumb:

    If I could write posts like that, I'd have much more time for Scotch. :D

    If there's something interesting about the technique, then it's that it shows a valid way to bypass even a very tight SRP. IOW, it does show that while SRP is very handy, it's not 100 % as they say. :D
     
  13. Ilya Rabinovich

    Ilya Rabinovich Developer

    Joined:
    Sep 13, 2005
    Posts:
    1,543
    Unusual usage of standard API or discovering rare mentioned API's/APIs control codes.

    As about SRP bypass- I don't care as its MS head ache, not mine, DW is invulnerable to it.

    And yes, WriteProcessMemory/CreateRemoteThread it's quite "boring" way to bypass anything. Maybe, working, but boring anyway.
     
  14. Hugger

    Hugger Registered Member

    Joined:
    Oct 27, 2007
    Posts:
    1,003
    Location:
    Hackensack, USA
    OK tiger, that's enough strenuous work for now.
    Nap time.
    Hugger
     
  15. Longboard

    Longboard Registered Member

    Joined:
    Oct 2, 2004
    Posts:
    3,187
    Location:
    Sydney, Australia
    :eek: Another outstanding post :D
     
  16. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571
    Like Ilya said and Didier showed in his blog entry: the macro uses WriteProcessMemory and CreateRemoteThread functions to write code into a process and then execute the code, and this code then patches SRP checking that is done inside the process off, allowing you to bypass SRP. This is an injection technique because the macro injects some code to a process and gets it executed in that process. The process has to be one the user has write access to, of course: in LUA, the macro could inject its code into Excel.exe running in the limited user account or explorer.exe for example, but could not inject code into processes running with higher privileges like an svchost.exe instance running as SYSTEM. It's not DLL injection since there's no DLL, but it's code injection still.

    Attacks that are both new and do not require massive user stupidity to work are interesting to me. But if it's just the same old thing used to do something a little different than before, it doesn't really interest me.

    To give an example of the uninteresting, the whole MBR rootkit thing was very uninteresting to me because MBR infections were nothing new, they were done already in the DOS age, and because it required the user to be admin to work. Boring...

    Of course, when I say it's not interesting to me, I don't mean that it's something people shouldn't talk about. As you said, "interesting" really is relative. Attacks like this are very much worth talking about, since most people aren't aware of them or understand them. But perspective is important: this isn't really a new attack, and there are many ways to prevent it and limit its impact. Ilya mentioned DefenseWall, for example, and sandboxing and virtualization in general will work, as will any classic-style HIPS product that watches for CreateRemoteThread etc. And even just a simple limited user account will limit what it can do: no system-wide infection.

    But certainly, when I have to choose which is more interesting to me, a thread about an attack technique (no matter how old) or a thread about AV test number 193878535325098 then I'll go with the former any time of the day. :D
     
  17. Kees1958

    Kees1958 Registered Member

    Joined:
    Jul 8, 2006
    Posts:
    5,857
    Nahh, MS developed Steady State to be used in conjunction with to LUA

    Good you found value in available mechanismes to reduce the attack surface with LUA/UAC and SRP, pity you keep on telling everybody that LUA is stronger than DW.

    Regards Kees ;)
     
  18. BlueZannetti

    BlueZannetti Administrator

    Joined:
    Oct 19, 2003
    Posts:
    6,590
    This is one of those topics that can be argued from either side of the aisle. In a sense LUA is stronger than DW, and in other aspects DW is more powerful than LUA.

    The power of LUA - you don't make decisions. The account is set to LUA and you are done.

    The power of DW - you have flexibility, but with flexibility comes responsibility. You need to make decisions at some point. In some contexts this is power, in others it is a liability. It depends who's at the keyboard.

    In a sense, mating LUA with SuRun is intermediate ground. Added flexibility to navigate through legacy issues, added responsibility to make the right call if you decide to pull Admin privileges.

    Blue
     
  19. Scoobs72

    Scoobs72 Registered Member

    Joined:
    Jul 16, 2007
    Posts:
    1,108
    Location:
    Sofa (left side)
    From my simplistic understanding, the whole point of LUA was to take away capabilities from users who can't be trusted so they can't do things to a PC that the admin doesn't want them to do. It's not suitable in it's pure form for users who do/should know better, which is why you have to add SuRun back in to give back some of which you have taken away. I think my viewpoint is that if you are going to 'give back' then you're much better adding in proper flexibility with DW, which at the same time gives stronger than LUA protection, rather than trying to frig LUA in a way it wasn't intended.
    Also, the beauty of DW is that the flexibility is there only if you want it. DW runs fine on my wife's PC without her even being aware of it. No flexibility is required.

    So on all counts it is difficult for me to see any scenario where LUA is more powerful than DW. Just MHO.
     
  20. BlueZannetti

    BlueZannetti Administrator

    Joined:
    Oct 19, 2003
    Posts:
    6,590
    That's really the wrong way to view it. That brands LUA as punishment of some sort.

    Daily PC usage should not require Admin level access. Routine usage does not involve the installation of new applications, system level configuration, and so on. Routine usage is running the applications that have been installed on the PC. This shouldn't require admin level access.

    The point is not to "take away capabilities from users who can't be trusted", it is to grant only those capabilities required, when they are required.

    If you're performing an Admin level task (say installation of a new application), then get the privileges needed for that task, but don't retain them when you step back into daily work mode.
    No..., SuRun is a convenience. It allow temporary escalation of privileges for a specific task within a session as opposed to retaining that level of access for a whole session. You are really viewing this from the wrong perspective.
    Once everything is properly vetted and configured, you might be right. They might be equivalent, which arguably makes a case that DW is more "powerful". The point that I'm making is that creating a situation or basing a security strategy on a scenario that requires a user to make decisions on-the-fly is, IMHO, a fundamentally flawed approach for a typical user.

    Blue
     
  21. Scoobs72

    Scoobs72 Registered Member

    Joined:
    Jul 16, 2007
    Posts:
    1,108
    Location:
    Sofa (left side)
    I did say it was my simplistic viewpoint :) Seriously though, whilst most sys admins may hold your viewpoint, I think most computer users who have LUA imposed upon them in a corporate environment would view the reason as one of trust. A quick poll round the office has confirmed that.
     
  22. wat0114

    wat0114 Guest

    I disagree. i do know better and i'm 100% confident i can stay uninfected as admin but I can do everything i need to do as lua, so why not? When i need to make admin-like changes, it is very simple for me to log in as such temporarily for those changes. I run primarily as lua simply because it is far more secure than admin.


    Of course! although there are some responsible people working in a corporate environment, there are also idiots who in no time will perpetrate viruses all over the LAN due to their surfing pron and installing cracks and keygens if they are given admin privs.
     
  23. Scoobs72

    Scoobs72 Registered Member

    Joined:
    Jul 16, 2007
    Posts:
    1,108
    Location:
    Sofa (left side)
    Whilst we are all coming at the LUA subject from different angles the original point I responded to was the relative strength of LUA versus DW and subsequently their relative flexibility. I maintain that DW is a stronger/more flexible solution than LUA that has the same benefit of being able to be used in a zero user interaction environment....for users that can't be trusted :) Comments like "LUA is definitely the way to go" need to be balanced and put into context with the alternative solutions available.
     
  24. Kees1958

    Kees1958 Registered Member

    Joined:
    Jul 8, 2006
    Posts:
    5,857
    Same here and I know this is also valid for Jmonge, my wife does not know it is there, with the whitelist option in V3, even more decisions can be taken away from the average user

    Only in red my slightly different opinion.

    As said I am happy with UAC/Norton's UAC tool on Vista and with UAC on Win7, combine it with Sully's PGS to achieve SRP and you have reduced the attack surface in a flexible way.
     
  25. Kees1958

    Kees1958 Registered Member

    Joined:
    Jul 8, 2006
    Posts:
    5,857
    Surun is UAC on XP, it gives the convienance of not switching to another user.

    Blue, so it offers flexibility, the same as when I decide to run something different with DW. That is the same flexibility mechanism.

    So I can't follow you arguments

    A) DW is weaker because it is flexible

    b) Surun is strong becasue it offers convienant flexibility

    Help :argh:
     
    Last edited: Oct 1, 2009
Loading...
Thread Status:
Not open for further replies.