applocker poc bypass (but no code)

Discussion in 'other security issues & news' started by katio, Nov 18, 2010.

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

    Joeythedude Registered Member

    Joined:
    Apr 19, 2007
    Posts:
    519
    I added the EMET tool and configured firefox and excel for all options.

    No changes to the result - cmd window still launched.
     
  2. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    Thanks... I guess this just shows that one solution is not effective against everything.
    As it has been shown, at least the likes of Sandboxie would contain it. It would be bypassed, even with restrictions on what processes would be allowed, though. But, all contained.
     
  3. katio

    katio Guest

    No surprises there, this POC doesn't use memory corruption, instead it relies on bad design/defaults.

    I'd be more interested in the results of the Adobe PDF based POC (hint, hint ;))
     
  4. wat0114

    wat0114 Guest

    I confirm the same as you, Joey. One difference, though, is that excel (using 2010) crashes immediately after cmd.exe launches. Also using EMET for excel. I wonder if this particular Excel poc will launch AppLocker-unauthorized executables such as a keylogger?
     
  5. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    Let's hope that all the caffeine I got inside me these last few days isn't making me imagining things, but are you talking about Protected Mode? :D ;)

    If it is... and I hope I still have a few stuff in mind right, as I should (lol), the only thing that Protected Mode would prevent would be for this stuff to reach a higher object... reach, as in modify (be it deleting, writing, modifying) it. But - I hope I'm not wrong - it would just make this "bad" object load into memory with a low IL (if we're talking about Windows Vista/7). As for Windows XP, this effect would not happen, due to lack of integrity levels.

    It would still be able to read from higher objects with higher integrity levels levels... unless the source object (acrord32.exe) would have a NoReadUp policy applied to it o_O

    But, one would have to be messing with Adobe Reader X default ILs, and find out what exactly would need to be changed, in order to make acrord32.exe even be started with an explicit low integrity level, with NoReadUp policy applied to it.

    I came to the stage of being able to having it running fine to a point, just like that, when I tested it when Adobe Reader X came out... But, I hadn't figured out all that needed to be changed... and I haven't been able to use any virtual machines... My spare disks are .... well... dead :( haha

    I hope I'm not wandering away... As I said... lots and lots of caffeine... and lack of proper sleep :D

    Anyway, if some of this is not 100% accurate... someone could correct it... without a constant practice, I do tend to forget certain things. :D
     
  6. wat0114

    wat0114 Guest

    Maybe now I'm starting to finally understand this exploit, at least this particular Excel one, and that is the executables launched by it are built into the macro. No wonder I was puzzled by the different "look" of both the command console and regedit editor when the macro launched them o_O This is why making cmd.exe and regedit.exe unauthorized for limited users in AppLocker will not (probably not) work to stop it.
     
  7. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    As I mentioned in my previous post, besides the containment by tools like Sandboxie, I believe that only way to prevent further problems (credentials stealing, etc), would be for apps like Word, Excel... Adobe Reader X, etc to be running with a NoReadUp policy applied to it. This would make this policy apply to the child processes... So, even if loading into memory, having a low integrity level (only Vista/7) and a NoReadUp policy applied to it, it wouldn't be able to read from objects with higher integrity levels. Unless one also runs the web browser with a low integrity level... ahaha lol

    I think Microsoft should apply such by design (as in, automatically do it... and not up to the users to mess with such)... Why didn't they o_O

    They also should have come up with something like NoReadAlike, preventing one low integrity level object from reading one other low integrity level object :D

    Am I being delusional? lol
     
  8. katio

    katio Guest

    This POC could do anything a keylogger running with the same permissions as Exel could do. Some space constraints apply but a dll can execute anything just like an ordinary dropped exe file.

    Not really. I was talking about EMET most likely blocking the exploit (no quotes here because this time it's about the buffer overflow or what ever vuln that will be prevented from being exploited in the first place).

    The reason I'd like to play with that is to figure out if it's easier to detect a full dll from memory attack compared to a smaller shellcode+dropper from the perspective of anti memory corruption techniques.
     
  9. wat0114

    wat0114 Guest

    On the surface, this seems like a great idea. i wonder if Sully's Safe-Admin could do this? ;) It can apply different ranges of integrity levels to files/folders, so I'm thinking it can via that functionality or another. Microsoft should be offering him a seat as one of their Technical Fellows, along the lines of a Mark Russinovich, he's that smart :)
     
  10. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    I didn't want to sound too obvious... :D

    But, you need to consider a larger scenario. It's not what Sully's app can or cannot do... It can do it. How so? Windows Vista and 7 do have integrity levels, and they're not off limits to be messed with. The problems lies in knowing every object which would be needed to be applied such integrity level policies.

    I tried it when Adobe Reader X came out. I could make it work to a point, with a few error messages... Before I could investigate further, my spare hard disks just failed, and I couldn't test any further until now... and still cannot.

    I think that something like Adobe Reader, Word, Excel... would demand more hard work. Something within the line of AppLocker's Audit Mode would be nice... A report of what would have happened in case such integrity levels would be applied. lol

    A web browser, media player... one more or one less object... not too much hard work... but some application like those mentioned above would be more time consuming to find out what exactly needs to be given the same integrity level, not to cripple things... I think.

    Who knows what the future of SAFE-Admin brings to us. lol
     
  11. wat0114

    wat0114 Guest

    Heh, heh...I had a feeling you were alluding to it :D Yes, lowest integrity level, for instance, can hamper a program, but I think if set up carefully, it can be a powerful tool to help mitigate threats. Sully will no doubt perfect it eventually. He deserves a nice, long vacation when he's done :)
     
  12. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    Interesting thread! As I mentioned to wat0114, I'm a bit behind and am just now sifting through all of the posts.

    I've written before that I normally don't pay much attention to POCs, for a couple of reasons.

    First, not many make their way into the wild as exploits, especially widely distributed in exploit packs. So, I ususally wait for the exploit to see what is going on.

    Second, most exploits download malware executables which are easily blocked.

    This POC, however, does not download anything, rather, uses embedded shellcode to carry out the work. Use of shellcode is not new, of course, but it's mostly used to download and execute.

    Some background (if you are new to shellcode) or review for those who know:

    Definition of: shellcode
    http://www.pcmag.com/encyclopedia_term/0,2542,t=shell code&i=61966,00.asp
    The WMF exploits are good examples. This was one of the informative explanations of what was going on:

    WMF FAQ: What you need to know
    http://www.cso.com.au/article/147925/wmf_faq_what_need_know
    The "malicious code" is shellcode - the instructions that initiate the attack. Buffer Overflow became the topic of the day, and a number of products protected against the overflow, meaning that the shellcode could not carry out its instructions.

    ThreatFire had an excellent analysis of the WMF shellcode:

    ThreatFire Research Blog: Shellcode analysis -- download n' exec
    http://blog.threatfire.com/2007/12/shellcode-analysis-download-n-exec.html
    Some PDF exploits use shellcode in the same way. From Websense:

    Adobe PDF Exploit Code Analysis
    http://securitylabs.websense.com/content/Blogs/3311.aspx
    And a wepawet analysis:

    Analysis report for pdf.pdf
    http://wepawet.iseclab.org/view.php?hash=e01b6d89f16bd33a08f90811b7c717af&type=js

    Scroll down to:

    Shellcode and Malware

    and you see the ASCII conversion showing the URL from which the malware is downloaded:

    Code:
    ....d.d...2.d..d
    ...2d.d.*..-....
    ..........http://etomerin.cn/x0/exe.php
    
    Anti-execution products by design intercept the payload - the malware executables as they write to disk and attempt to execute.

    They do not stop the shellcode from initiating its commands.

    Since the POC under question does not write anything to disk, the standard Anti-execution product, which analyzes a file on disk and compares with a White List, will not be able to intercept anything.

    Prevention will be by

    1) Stopping the shellcode from executing

    2) containing what the shellcode attempts to do.

    3) ______?

    Some here are focussing on particular applications (Excel, Word). Note that Didier Stevens cautions that one shouldn't focus on applications (delivery methods), since he is working on a PDF POC, and your imagination can think of other applications to execute shellcode.

    The usefulness in the wild of this technique will depend on the goals of the cybercriminals. One limitation, it seems to me, will be how small of a file size can be made to include all of the instructions necessary for the shellcode to achieve the desired results, plus whatever else is embedded. This XLS file is 22MB. The standard malware dropper is a few KB. (It will be interesting to see how small the PDF file can be made).

    Didier Stevens alluded to exploits in stages for attacking a network because of the large amount of shellcode necessary. From his post #20 above:

    Until the uninformed, unprotected pool of willing victims of today's exploits dries up, my guess that such a technique as has been demonstrated may be limited to specific targets, where known types of data could potentially be mined. Otherwise, it's just still too easy to add to existing botnets using tried and proven trojan dropper methods.

    But that is just conjecture.

    Meanwhile, I'll wait for the first emergence of such malware in the wild! Until that that happens, all is speculation!

    regards,


    rich
     
    Last edited: Dec 31, 2010
  13. wat0114

    wat0114 Guest

    Great analysis once again Rich! I've always liked your calm, cool approach to the way you explain how these exploits work and how easily they can be avoided in the first place :)
     
  14. katio

    katio Guest

    Very good summary and analysis, thank you rich!
     
  15. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    Just to clarify one thing, I didn't make reference to specific applications. It just happens that I mentioned, at least, 3 of the most used applications by people: Word, Excel and Adobe Reader... I did mention the word "etc".

    And, my posts were more like in the situation this would be likely to happen; not that it would.

    Again, this was just me trying to see this from a certain technical analysis (leaving a likely infection aside), and wondering why certain security implementations of Vista/7, more specifically integrity levels don't work in certain ways, and what one could actually do to achieve them:

    This was more like an exercise of my mind, than anything else. Still, the same is valid for real infections (be it to memory or writing to disk), and even in the likely event that such "infection" that has been discussed would turn out to be real.

    Again, I wasn't mentioning specific applications. I just focused on the mostly used ones (I think they are...) and how much hard work would they demand to apply the integrity levels.

    Anyway Rmus... always a pleasure reading your posts. ;)
     
  16. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    Thanks, m00nbl00d, and to the others.

    I wasn't referring specifically to you regarding applications, rather, just to paraphrase Didier Steven's comment in his Post #22:

    This is reminiscent of the old WMF exploit. By design, the .wmf filetype is associated with the Windows Picture and Fax application. Clicking to open a WMF file, or encountering it in a remote code execution exploit on a web site automatically opened the file in that application.

    So, some early preventative suggestions included dissassociating .wmf from the Windows Picture Viewer.

    However, it soon became clear that the culprit was not that application, nor even that file type, .wmf. Rather, it was a Windows DLL which is also used by other Viewer applications, such as the popular Irfanview. It was demonstrated that media file types such as .jpg could be boobytrapped to execute the shellcode in a number of Viewer applications.

    Before the Microsoft patch, therefore, some prevention methods were:

    1) protect against buffer overflow so that the shellcode could not execute

    2) have anti-execution protection to block the payload -- the trojan executable -- from executing.

    In the current situation, Didier Stevens points out the difficulties in prevention, in his post #25:

    And so it goes -- the cat and mouse game continues!

    ----
    rich
     
  17. Lucy

    Lucy Registered Member

    Joined:
    Apr 25, 2006
    Posts:
    404
    Location:
    France
    With Standard Microsoft tools available, 1) is not achievable as SRP and AppLocker do not protect against it by design. I don't know about third-party security applications.

    2) is mitigated by sandboxing. By sandboxing, I mean using a standard user account or any external tool, be it, Geswall, Defensewall, or Sandboxie..., or by applying a lower integrity level to the processes (lower than user's so that it can not read/modify user's files), be it the downloaded ones or the internet facing ones which will read and "execute" the downloaded files. For the latter, if it is easy for PDF applications started with version X of adobe reader and version 7 of IE), it is impossible with the "office" application whose purpose is to create and modify user's files.

    So I guess the answer to 3) can only be (as written by Didier Stevens):
    - understanding design and "weaknesses" of the policy /security enforced
    - take it into account to "hide" sensitive and confidential data so that would such a scenario happen, the consequences would be bearable (no info leaked).
    so for 3):
    - confidential data stored with necessity of providing admin credentials, or encrypt it, or store it outside of your computer.

    Once more, I carry on supposing that there is such a huge open field for easier scenarii that it is unlikely we see it in the wild. So we shouldn't worry too much. I invite you to carefully listen and apply advises given by Rmus.
    On the contrary, a targeted attack against few users in a company could end with catastrophic consequences:
    For example, most developpers in companies run with admin rights, and often have access to the entire network of their company. Sending a PPT christmas gift embedding such an info stealer could lead to data leak. To think about. Most companies wouldn't be prepared to it. And it is not these poor AV which could do a thing...
     
  18. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    Simply adding a lower integrity level won't cut it. I mean, applying a lower integrity level than the user had won't stop a lower integrity level XYZ object from reading objects with higher integrity levels.

    As I mentioned in one of my posts, it is necessary to apply a NoReadUp policy so that a lower integrity level object cannot read from higher integrity levels.

    Just applying a lower integrity level, by itself, it won't stop this/these object(s) from reading other higher objects.


    Regards
     
  19. Lucy

    Lucy Registered Member

    Joined:
    Apr 25, 2006
    Posts:
    404
    Location:
    France
    Yes,

    Right, it restricts drastically the actions which can be performed. I used too quickly the info from Didier Stevens.

    Anyway, I store my private files / sensitive data under an admin account, which is one of the possible strategies to avoid stolen data from an info stealer.
     
  20. trismegistos

    trismegistos Registered Member

    Joined:
    Jan 29, 2009
    Posts:
    363
    I also tested officekat.xls and I agree with what wat0114 said in this thread... -http://ssj100.fullsubject.com/t319p15-excel-macro-testing#2682

    ... what a diabolical bypass this is... :eek:
     
    Last edited: Jan 11, 2011
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.