applocker poc bypass (but no code)

Not news and only so interesting without any actual code to play with but I'm sure some of you might have missed it.

http://blog.didierstevens.com/2010/01/28/quickpost-shellcode-to-load-a-dll-from-memory/

So far my opinion has been that shellcode designed to break Applocker will only be used for targeted attacks. But since this dll from memory shellcode is also useful for bypassing the more common AV and HIPS protections we might be seeing this in the wild eventually.

Protections?
This requires a lot of attacker code in memory space, I suppose ASLR, anti heap spray and other mitigation as offered in EMET will be quite effective. As well as locking down scripting in Office...

 

@ katio Thanks for posting

*

A few thoughts on how this vector "might" be defeated, by any/all of the following.

Rename Wscript.exe in BOTH System32 & Dllcache



Installing an app like ScriptDefender & making sure JS,JSE,VBE,VBS etc are included.



Enabling the MyComputer in Zone 0 & setting the scripting options to Disable or Prompt.



Even though i have 2 options in there Enabled i have the other above 2 methods also in place

Please be aware, in case you didn't know, it makes NO difference if you don't use IE, as the MyComputer Zone is a local setting & NOT the www one, so helps protect your comp whatever browser you use

 

That doesn't block the basic attack (loading dlls from memory) it blocks only one vector of said attack (an application specific implementation).

Is there anything that prevents this kind of attack from working (at all) with for example a windows media player vulnerability where the dll is embedded in the media file?

 

Does it, OK. Well one's better than none i guess

 

Would running the media player/another app. inside a limited job make it?

 

From what I understand in this kind of attack is that this is a two stage process. First stage is, I quote...

... then consequently and I quote...

So, CloneRangers mitigations(and if may add to disable any scripting or macro on any application) could probably stop the attack dead cold in its first track before it can load the dll in memory. Since the application side vulnerability will be the front gate or rather the backdoor for the exploit to gain access to the system.

I had the impression that the bypassing SRP/applocker scenario was in the context that initially Didier Stevens thought that DLL whitelisting by SRP was quite a painstaking task. Didier Stevens showed later on how to prevent dll being loaded to memory via SRP with such ease in conjunction to prevent Stuxnet like infections during that time MS didn't have a patch yet...
http://blog.didierstevens.com/2010/07/20/mitigating-lnk-exploitation-with-srp/

And as always the code that he uses is always VBA macro in EXCEL. So there is no specific code exploiting other vulnerabilities in other applications.

In your question, running the vulnerable application under Sandboxie can potentially contain the exploit from affecting the system.

 

The question is, how difficult is it really to lad dll from memory from any shellcode. It's easier to download an exe and then go from there because you need to inject less code into the attacked application. That's what we see in just about every case.

A VBA macro gives the attacker lot of control so no wonder he chose that. But is it not possible to use this vulnerability in another context?

You can't stop exploits. It's impossible to write bug-free code, there'll always be vulnerabilities. Sandboxing won't stop it, only contain what the malicious dll can do. EMET can't prevent all types of exploits.

It's all speculation at this point as so far there haven't been any such attacks reported. It's just something to keep on the radar. For 99% of the population who only rely on AVs it has the potential to make a 0day absolutely undetectable.

The .LNK exploit got nothing to do with that. It's loading the dll from disk.

 

Nah, it's related to the so called Binary planting or DLL planting which is quite possible in this case of your theoretical question of an embedded dll in a seemingly harmless media file. For the bottomline for this exploit is the DLL being loaded like in Stuxnet though differing in the initial vector but still not your usual download and execute type as in this case. DLL doesn't just get magically be loaded from memory out of nowhere. Eventually, embedded code or dll FROM DISK will get to be loaded in memory.

I agree Sandboxie wouldn't be able to STOP the shellcode from EXECUTING but both of us agree that it will CONTAIN it, isolating it from affecting the system. Isn't that the Bottomline? The only thing Sandboxie wouldn't be able to contain is the theoretical exploit on the very rare kernel vulnerability(OS vulnerability) with both privilege escalation and remote code execution combined, (a simple privilege escalation requires initial remote code execution attack for a local access), but then again no security application nor SRP even in LUA will be impervious to such a very rare targeted attack but the very common and simple remote code execution is just a simple matter for Sandboxie.

As for your other questions with the absence of a working exploit or code to test our defences only Didier can answer those in finality. Might as well ask him for more inputs. But then the potential harm it may cause if it get into the hands of a malware writer. If this is just a simple remote code execution thing, then a properly configured SRP or any antiexecutable will block any dll loading. Unless this is coupled with privilege escalation, which is quite unlikely.

Speculating on this, I don't think this shellcode via VBA macro from a vulnerability in EXCEL(is it already patched?) can be easily ported to other applications. There must be exactly similar vulnerabilities to the applications concerned or underlying system vulnerability to be able to do similar actions. Unless Didier says otherwise and comes foreward to enlighten us more or if rather he keeps to himself some zeroday system or kernel vulnerability and exploit up to his sleeves(just kidding) which as I have said before is very unlikely. But who knows? ha ha

It is so easy to mitigate such exploit for this theoretical Shellcode not to get executed, simply by turning off Macro and scripting if you don't use it and turning it on if you want to run your own Macros and scripts in Excel.

 

I was thinking:
The dll is embedded, so it is on disk. But it could be encrypted/obfuscated.
Buffer overflow or whatever results in shellcode being executed which in turn decodes the dll and loads it, bypassing all known AVs, most HIPS and certainly any kind of SRP/AL configuration.
Another scenario: the dll is embedded in a simple html file, browser exploit->shellcode loads the code from memory.

Sandboxing for me is only the last line of defense. Even in the most locked down environment remote code execution can wreak havoc, of course depending for example on what data can be accessed and how network access is regulated. But the first goal should always be to prevent the execution in the first place. Execution whitelisting has always been the best answer but if the dll from memory actually does work like I suggested in my examples above I see a definite need to address this issue.

 

We all know any blacklisting AVs will always be behind and be playing catch up.

We need to get the facts straight from Didier. So far so little was given and will end up just speculating.

This is how he said he was able to bypass SRP by loading a dll... http://blog.didierstevens.com/2008/06/05/bpmtk-how-about-srp-whitelists/

But how about if you whitelisted all the allowed dlls and prevent any malicious dll to be loaded.

Yes, it is possible to load dll from memory without writing into hard disks but I am still questioning how he was able to bypass the interception by some HIPS/SRP of the load library calls.

Regarding the original source of the idea of loading dll from memory...
http://www.joachim-bauch.de/tutorials/loading-a-dll-from-memory/

Sandboxie in particular has anti execution control and you can have a whitelist of allowed executables. What can a malicious dll do if allowed in the sandbox security wise?

 

I think if you are experienced with windows hacking (which I'm not) the link to joachim-bauch.de would be quite useful. Looks like it's all there, including working code. He explicitly states that he doesn't need to call LoadLibrary or LoadLibraryEx which is required for HIPS, SRP or AL to actually block the loading.

Everything the parent process has permission to do. Example: in the case of a browser exploit that means accessing current cookies and uploading them to a remote website or logging keystrokes/passwords. No big deal if you use the Sandbox wisely. But it also could be used to proxy traffic for a DoS. Or set up an IRC, download compromising files to the harddrive to blackmail you later. Practically it can do anything a random exe started in the sandbox could do and in the case there's currently a kernel exploit available, it can break out and own the system.

 

Forgot also posting this link:
http://www.harmonysecurity.com/ReflectiveDllInjection.html

 

This is not a vulnerability. And I've used it in another context: I made a PDF file that exploits a vulnerability and then launches this shellcode.

--------------
Didier Stevens
http://blog.DidierStevens.com

 

I've posted the code some time ago: http://blog.didierstevens.com/programs/shellcode/

--------------
Didier Stevens
http://blog.DidierStevens.com

 

Welcome to Wilders!

We are honored by your presence.

So there is no esoteric vulnerability.

But this exploit will not be able to bypass SRP if wscript.exe and cscript.exe are blocked, right? (And along with blocked cmd.exe, regedit.exe, command.com, debug.exe, ntdvm.exe, etc.)

This requires dll injection or patching?

It will be nice if you will be able to compile this as a single executable leak test for non-hackers but security enthusiasts slash paranoid freaks like me.

 

Hmm, interesting

Just tried the 2 Didier Stevens POC's first with IE options set to allow scripting, & then with prompt & with BIN & DLL & CMD also included in ScriptDefender = same results ? Maybe SD requires a reboot to take effect, but i didn't think it did in the past !





Had to get through PG though first



If blocked by PG



Will try a few other things & see

 

Don't focus on the scripting aspect, this is just one way to deliver and execute the shellcode. Like I said, I also did this with a PDF document.

Neither. This shellcode works on the process it is executing in, and not on another process. And what this shellcode does is very similar to what a normal program would do (creating new memory pages and starting a new thread), so difficult to detect by behavioral observation.

 

I've also used this in a spreadsheet: http://blog.didierstevens.com/2010/02/08/excel-with-cmd-dll-regedit-dll/

Paul Craig, author of the iKAT kiosk hacking tools, included a
digitally signed version of my cmd.dll spreadsheet in iKAT version 3.0.
This way, you can also use my spreadsheet on systems that require
macros to be digitally signed (that's the default when you install
Office 2003).
http://ikat.ha.cked.net/Linux/
Download ikat3.zip and look for officekat.xls

 

Thank you for the replies Didier Stevens! Great to have you here
Re the PDF POC: It's that one, right?
http://blog.didierstevens.com/2010/03/08/pdf-info-stealer-poc/

You say that it "can be designed to evade or bypass AV". Does that mean I was right with what I wrote above:
"The dll is embedded, so it is on disk. But it could be encrypted/obfuscated." (and randomly I have add).
Otherwise AVs could detect a malicious embedded dll by its signature.

Any chance you release that one as well, maybe modified to only launch calc.exe?

 

Thanks for the warm welcome all!

Correct.

Yes, but it is not embedded according to the PDF standard, but with my own method. And remember, this is shellcode. I'm not limited to using this in files.
I could also use it in a networked service vulnerability, for example in a vulnerability in an FTP server. I send malformed packets, with this shellcode and the DLL, to the vulnerable service. The DLL will never be written to disk on the attacked system.
Of course, this shellcode is large, and most network exploits are limited in the size of the shellcode they can pack, so you would need to do this in stages.

No, this is an info stealer, I'm never going to release that. But I will consider releasing a PDF I made that launches cmd.dll from memory.

BTW, what is the policy of this board regarding posting of PoCs?

 

Welcome man!

A question regarding the PoC: A applocker policy using the Wizard method creating rules by Signature & Hash (not only exe's but script and dll's too) rules will neutralize it right?

 

If you take the PoC where an EXE is the vector, it will.
But test it with the spreadsheet I referred to. Nothing, except the .XLS, will touch the disk. I believe you can make a hash rule for a spreadsheet, but then I only have to change one bit in the spreadsheet, and I bypass the rule.

But again, the prevention methods talked about here target the vector (.EXE, .PDF, .XLS, ...) delivering the shellcode, and not the shellcode itself.

 

@ Didier Stevens

Hi, tried those extra tests you posted by double clicking them just to see

regedit.dll = Didn't work just by DC, didn't expect it would, but worth a try

officekat.xls = I don't have Office so it didn't work !

cmd.exe After allowing through PG



I was amazed at the amount of tests available on http://ikat.ha.cked.net & couldn't resist trying most of them i had time to. Passed on nearly every one & that was after allowing scripting Oh i like the Save the sheep image on there, very nice

I see you mentioned ReactOS on your www, which i briefly played with months ago. Looked fine to me so far

Please be aware, i'm no vulnerability etc expert, just enjoy testing & hopefully learning some things on the journey.

POC's are fine, but malware isn't, except by PM

 

But that would usually get picked up by SRP/AL, HIPS, AV. I think a browser exploit would be promising as you can send lots of attacker controlled data which is usually only cached in memory.

That would be great.

 

SRP and AL don't pick up shellcode in memory and on the network interface.

Most AV performs only limited scan of memory (compared to disk scan) and/or network traffic.

HIPS maybe, depends on what it scans.