DLL exploit testing
+3
arran
languy99
ssj100
7 posters
Page 1 of 1
DLL exploit testing
The latest "big news" Windows vulnerability is still causing a bit of a stir (conveniently following on from the LNK vulnerability):
https://ssj100.forumotion.com/security-f7/news-zero-day-windows-bug-t255.htm#1977
After some help from MrBrian (thanks!), I've managed to reproduce such a POC exploit. The exploited program is the popular VLC Media Player. The POC exploit for this program automatically calls up a (potentially malicious) DLL file when a .mp3 file is played in the program. To simplify, this is all one would potentially have to do:
1. VLC Media Player is installed on the system (and is the default music player)
2. Download a .mp3 file
3. Play the .mp3 file in VLC Media Player via double click
4. Potentially malicious DLL file is spontaneously loaded
In the next post, I'll be testing this POC against various anti-malware mechanisms. Note that VLC Media Player released an updated version (1.1.4) to patch this vulnerability a few days ago.
https://ssj100.forumotion.com/security-f7/news-zero-day-windows-bug-t255.htm#1977
After some help from MrBrian (thanks!), I've managed to reproduce such a POC exploit. The exploited program is the popular VLC Media Player. The POC exploit for this program automatically calls up a (potentially malicious) DLL file when a .mp3 file is played in the program. To simplify, this is all one would potentially have to do:
1. VLC Media Player is installed on the system (and is the default music player)
2. Download a .mp3 file
3. Play the .mp3 file in VLC Media Player via double click
4. Potentially malicious DLL file is spontaneously loaded
In the next post, I'll be testing this POC against various anti-malware mechanisms. Note that VLC Media Player released an updated version (1.1.4) to patch this vulnerability a few days ago.
Re: DLL exploit testing
POC exploit on Administrator account, Windows XP, SP3, 32-bit:
1. SRP (setup as described here: http://www.mechbgon.com/srp/ ): BLOCKED
2. Faronics Anti-Executable 2: BLOCKED
3. COMODO Internet Security 4.1.150349.920 (default configuration): BYPASSED
Note that CIS (like with all classical HIPS software) can be configured to easily block this exploit, as described by MrBrian here:
http://forums.comodo.com/guides-cis/using-comodo-internet-security-as-an-antiexecutable-t60303.0.html
4. Online Armor Premium Personal Firewall v4.5.0.234 (default configuration): BYPASSED
5. Malware Defender 2.7.2 (default configuration): BYPASSED
6. Sandboxie 3.48: CONTAINED
7. DefenseWall 3.06: CONTAINED
8. GeSWall 2.9 Professional: CONTAINED
9. Returnil System Safe 2011 v3.2.10143.5401-REL2: BLOCKED
10. AppGuard 1.4.7: BYPASSED
11. PE GUARD 2.1: BYPASSED
12. Prevx 3.0.5.189: BYPASSED
13. Mamutu 3.0.0.12: BYPASSED
14. BluePoint Security 1.0.38.99: BYPASSED
15. ProcessGuard 3.500: BYPASSED
1. SRP (setup as described here: http://www.mechbgon.com/srp/ ): BLOCKED
2. Faronics Anti-Executable 2: BLOCKED
3. COMODO Internet Security 4.1.150349.920 (default configuration): BYPASSED
Note that CIS (like with all classical HIPS software) can be configured to easily block this exploit, as described by MrBrian here:
http://forums.comodo.com/guides-cis/using-comodo-internet-security-as-an-antiexecutable-t60303.0.html
4. Online Armor Premium Personal Firewall v4.5.0.234 (default configuration): BYPASSED
5. Malware Defender 2.7.2 (default configuration): BYPASSED
6. Sandboxie 3.48: CONTAINED
7. DefenseWall 3.06: CONTAINED
8. GeSWall 2.9 Professional: CONTAINED
9. Returnil System Safe 2011 v3.2.10143.5401-REL2: BLOCKED
10. AppGuard 1.4.7: BYPASSED
11. PE GUARD 2.1: BYPASSED
12. Prevx 3.0.5.189: BYPASSED
13. Mamutu 3.0.0.12: BYPASSED
14. BluePoint Security 1.0.38.99: BYPASSED
15. ProcessGuard 3.500: BYPASSED
Last edited by ssj100 on 1/10/2010, 18:04; edited 7 times in total
Re: DLL exploit testing
What about the latest V5 of comodo, it now can handle DLL's among other things.
languy99- Valued Member
- Posts : 54
Join date : 2010-07-20
Re: DLL exploit testing
I use VirtualBox to test and apparently version 5 doesn't run in it? Anyway, didn't egeman say that DLL handling has been taken out of CIS 5 (but might be implemented back later)?languy99 wrote:What about the latest V5 of comodo, it now can handle DLL's among other things.
Also, as I already mentioned, CIS 4 can be configured to block the exploit. However, it's highly unlikely CIS will ever block the exploit in default configuration, because that would not play well with the "average user" - they'd potentially be getting many pop-ups asking whether they should allow (safe) DLL's to load.
Re: DLL exploit testing
right D+ will not handle DLL right now but from what I know the sandbox should be able to sandbox that dll because of the command line heuristics. I have VMware, why don't you send me the POC and I will test it out.
languy99- Valued Member
- Posts : 54
Join date : 2010-07-20
Re: DLL exploit testing
Just tested it with COMODO Internet Security 5.0.159634.1091 RC - installation went smoothly and everything seems functional. However, it failed against the POC exploit - the DLL is loaded and it's not running sandboxed. Instead, the executable component of VLC Media Player 1.1.0 (a trusted and well known program) is running sandboxed as partially limited.
Sure, give me some time and I'll send you the files required to reproduce the POC (with instructions). You'll need to supply your own .mp3 file though.
Sure, give me some time and I'll send you the files required to reproduce the POC (with instructions). You'll need to supply your own .mp3 file though.
Re: DLL exploit testing
that's fine, I actually am working with a different version of CIS v5 right now. There were some problems in it reporting that files that were sandboxed showing up as not sandboxed.
languy99- Valued Member
- Posts : 54
Join date : 2010-07-20
Re: DLL exploit testing
I'll send the files to you via e-mail (once you PM me your e-mail address). Here's what should pop-up if the DLL successfully loads:
This means the POC file "wintab32.dll" has successfully loaded. I suppose you'd be wanting to check if this file is sandboxed in CIS. With Sandboxie, it's hard to tell, but I know it's running sandboxed because after deleting the sandbox, the pop-up is eliminated. DefenseWall and GeSWall show the pop-up box running untrusted/isolated, meaning they successfully contained the POC.
SRP, Faronics, and Returnil all automatically block the DLL from loading, while allowing the .mp3 file to play. I was expecting BluePoint Security to do the same (since I thought they'd added DLL blocking following the discovery of the LNK exploit), but it failed.
This means the POC file "wintab32.dll" has successfully loaded. I suppose you'd be wanting to check if this file is sandboxed in CIS. With Sandboxie, it's hard to tell, but I know it's running sandboxed because after deleting the sandbox, the pop-up is eliminated. DefenseWall and GeSWall show the pop-up box running untrusted/isolated, meaning they successfully contained the POC.
SRP, Faronics, and Returnil all automatically block the DLL from loading, while allowing the .mp3 file to play. I was expecting BluePoint Security to do the same (since I thought they'd added DLL blocking following the discovery of the LNK exploit), but it failed.
Re: DLL exploit testing
In real life experience how would the malicious DLL file get on your computer?
arran- Member
- Posts : 41
Join date : 2010-05-09
Re: DLL exploit testing
Good question - I don't really know. I guess this is why it's (only) a POC. I don't think there's any in-the-wild malware currently out there that uses this attack vector.arran wrote:In real life experience how would the malicious DLL file get on your computer?
Re: DLL exploit testing
The process of getting the malicious file on your computer is called "remote binary planting".
Please read the full article:
http://www.computerworld.com/s/article/9180978/Zero_day_Windows_bug_problem_worse_than_first_thought_says_expert
Attacks reported in the wild:
http://www.scmagazineuk.com/claims-made-that-there-is-active-exploits-in-the-wild-for-the-windows-dll-vulnerability/article/177478/
Please read the full article:
http://www.computerworld.com/s/article/9180978/Zero_day_Windows_bug_problem_worse_than_first_thought_says_expert
Attacks reported in the wild:
http://www.scmagazineuk.com/claims-made-that-there-is-active-exploits-in-the-wild-for-the-windows-dll-vulnerability/article/177478/
DarthTrader- Member
- Posts : 21
Join date : 2010-07-28
Re: DLL exploit testing
DarthTrader wrote:The process of getting the malicious file on your computer is called "remote binary planting".
Please read the full article:
http://www.computerworld.com/s/article/9180978/Zero_day_Windows_bug_problem_worse_than_first_thought_says_expert
Attacks reported in the wild:
http://www.scmagazineuk.com/claims-made-that-there-is-active-exploits-in-the-wild-for-the-windows-dll-vulnerability/article/177478/
As per usual, little to nothing is stated on the infection specifics of these malware. The first link only explains:
The main enabler for this attack is the fact that Windows includes the current working directory in the search order when loading executables," he said. Hackers can use that to trick a wide range of Windows applications into loading malicious files, just as they normally do their own .dll or .exe files.
While the second link...:
Remember, it is extremely easy to exploit this and it doesn't require any advanced knowledge so be sure to check Microsoft's recommendation above or be very careful about files you open from network shares.
Given such a lack of information in the two articles, can it be assumed that as long as people don't open something they're not sure about, these exploits can be avoided?
I see this all the time in these newest malware alert articles, where practically nothing is explained on how, specifically, a user typically gets infected by them. It is, however, not uncommon to see recommendations to protect oneself with the latest updated av product
wat0114- Advanced Member
- Posts : 152
Join date : 2010-05-11
Re: DLL exploit testing
I will leave it to you to investigate the matter further. For me it is pointless to engage in a discussion about how files of any kind get on computers. Such a discussion would be endless.
There is nothing in any of the malware testing standards that requires the tester to explain how a malicious file got on someone's computer.
There is nothing in any of the malware testing standards that requires the tester to explain how a malicious file got on someone's computer.
DarthTrader- Member
- Posts : 21
Join date : 2010-07-28
Re: DLL exploit testing
Thanks for the comments. As I've said before, the way newly introduced files are handled is pretty much what makes you or breaks you. I always open newly introduced files via a sandboxed explorer.exe, as well as having a system-wide anti-execution mechanism handy (SRP). In this way, any newly introduced file I recover on to my REAL desktop and open/run is unable to infect my system.
The same concept applies for malware threat-gates (eg. web browser, games played online outside of the web browser, chat messenger programs, USB drives etc) - all of them are always opened/run sandboxed, and all of them are under an anti-execution mechanism. In this way, no matter what exploit is being used to attack your system, you get as close as possible to "100%" protection as possible. Any drive-by or spontaneous executions will be blocked by SRP (or Sandboxie's anti-execution mechanism) and/or contained by Sandboxie.
In recent times, there has been a huge marketing shift towards increasing "logging malware" (eg. keyloggers) awareness by various anti-malware companies. However, applying the above strategy covers every attack vector of even this type of malware - anything that needs to be executed will be blocked (I have never come across any eg. keylogger which didn't require initial traditional execution...if someone has even a POC, please PM me!).
Even in the event that logging malware went beyond simple execution, sandboxing and/or anti-scripting would come to the rescue. In my security setup/approach post, I describe the use of 2 separate sandboxed browsers - one for general use, and the other for more sensitive use (like internet banking). For general use, I personally use Firefox with NoScript. I don't often delete my Firefox sandbox, and there is simply no need to - NoScript pretty much blocks any possibility of fancy logging malware from running. For more sensitive use (like internet banking), I use a sandboxed Internet Explorer - this sandbox is always emptied at the end of each eg. internet banking session. Therefore, the environment that internet banking takes place is always completely safe each time.
Various anti-malware-logging mechanisms have been shown to be bypassed by POC's time and time again. I still believe the above strategy (as described in more detail in my security setup/approach post) gets one as close as possible to 100% protection against ALL types of malware. And the beauty of it is that it doesn't require annual fees and there are pretty much no pop-ups even if your software changed.
This is why I am always interested in testing new types of exploits and malware. So far, all of them have been blocked by an anti-execution mechanism and contained by Sandboxie.
The same concept applies for malware threat-gates (eg. web browser, games played online outside of the web browser, chat messenger programs, USB drives etc) - all of them are always opened/run sandboxed, and all of them are under an anti-execution mechanism. In this way, no matter what exploit is being used to attack your system, you get as close as possible to "100%" protection as possible. Any drive-by or spontaneous executions will be blocked by SRP (or Sandboxie's anti-execution mechanism) and/or contained by Sandboxie.
In recent times, there has been a huge marketing shift towards increasing "logging malware" (eg. keyloggers) awareness by various anti-malware companies. However, applying the above strategy covers every attack vector of even this type of malware - anything that needs to be executed will be blocked (I have never come across any eg. keylogger which didn't require initial traditional execution...if someone has even a POC, please PM me!).
Even in the event that logging malware went beyond simple execution, sandboxing and/or anti-scripting would come to the rescue. In my security setup/approach post, I describe the use of 2 separate sandboxed browsers - one for general use, and the other for more sensitive use (like internet banking). For general use, I personally use Firefox with NoScript. I don't often delete my Firefox sandbox, and there is simply no need to - NoScript pretty much blocks any possibility of fancy logging malware from running. For more sensitive use (like internet banking), I use a sandboxed Internet Explorer - this sandbox is always emptied at the end of each eg. internet banking session. Therefore, the environment that internet banking takes place is always completely safe each time.
Various anti-malware-logging mechanisms have been shown to be bypassed by POC's time and time again. I still believe the above strategy (as described in more detail in my security setup/approach post) gets one as close as possible to 100% protection against ALL types of malware. And the beauty of it is that it doesn't require annual fees and there are pretty much no pop-ups even if your software changed.
This is why I am always interested in testing new types of exploits and malware. So far, all of them have been blocked by an anti-execution mechanism and contained by Sandboxie.
Re: DLL exploit testing
No doubt, ssj, your security setup/approach will stop most, if not everything, presently in the wild and what's to come in the foreseeable future. I guess all I'm trying to get at is all these latest malware threats, especially this one and the x64 exploit being ballyhooed in another forum, whos name I'll not mention, are being hyped by security experts as just short of the next doomsday scourge, endangering everyone who dares to venture on the web. There's so much emphasis on how malicious these threats are, but very little mention on how easy it is to prevent them in the first place by using a decent security approach, which would even include simply running as a standard use and some common sense. It seems they want people to believe these malware typically get on to pc's with no user intervention at all. Maybe to some extent drive-by downloads occur, but that is most likely going to happen when users stupidly or ignorantly venture into dubious sites. My feeling is it's an agenda to instill and maintain fear in typical home users to "keep up to date with the latest antivirus solution such as..."insert big name av product here".
wat0114- Advanced Member
- Posts : 152
Join date : 2010-05-11
Re: DLL exploit testing
ssj100,wasn't ShadowDefender listed as "CONTAINED" in your original post?
noor
noor
noorismail- Moderator
- Posts : 193
Join date : 2010-06-23
Re: DLL exploit testing
A nice link posted by MrBrian
http://www.wilderssecurity.com/showpost.php?p=1741122&postcount=123
My wish came true
http://www.wilderssecurity.com/showpost.php?p=1741122&postcount=123
My wish came true
wat0114- Advanced Member
- Posts : 152
Join date : 2010-05-11
Re: DLL exploit testing
There is one very easy way that the malicious DLL file can get on a users pc.
most movies you download these days are winrar zipped files.
The malicious DLL file can be placed inside a winrar zipped file along with the movie or music files that you download. so as soon as you unzip the files and use VLC to play you movies VLC executes and runs the malicious DLL file, most average users would get infected, but easily prevented by us power users with properly configured anti executable.
most movies you download these days are winrar zipped files.
The malicious DLL file can be placed inside a winrar zipped file along with the movie or music files that you download. so as soon as you unzip the files and use VLC to play you movies VLC executes and runs the malicious DLL file, most average users would get infected, but easily prevented by us power users with properly configured anti executable.
arran- Member
- Posts : 41
Join date : 2010-05-09
Re: DLL exploit testing
noorismail wrote:ssj100,wasn't ShadowDefender listed as "CONTAINED" in your original post?
noor
No, I never tested Shadow Defender here. However, all significant changes to the system would most likely be discarded after a reboot (when in Shadow Mode).
Re: DLL exploit testing
Oh so true IMO.wat0114 wrote: being hyped by security experts as just short of the next doomsday scourge, endangering everyone who dares to venture on the web.
Again true, but not as easy to come to fruition. A high percentage just can't/won't invest the time to educate themselves. No solution to this problem I am afraid.There's so much emphasis on how malicious these threats are, but very little mention on how easy it is to prevent them in the first place by using a decent security approach, which would even include simply running as a standard use and some common sense.
Again, you can lead a horse to water but you can't make him drink.Maybe to some extent drive-by downloads occur, but that is most likely going to happen when users stupidly or ignorantly venture into dubious sites.
This is the gamble. There is an ample supply of users who don't want to be bothered with learning much about a computer. The same thing occurs with cars. You take them to a mechanic and have the oil changed, not much more. Same thing is true with everything. If your interests lie elsewhere, so will your attention go there where it belongs.My feeling is it's an agenda to instill and maintain fear in typical home users to "keep up to date with the latest antivirus solution such as..."insert big name av product here".
I haven't given up, but come to terms with the fact that many users simply will never be free from exploitation. I try my best to help those I know, but find myself telling them the solution in vague terms and letting them either take interest or not. I don't volunteer as much of my time as I used to, whether being paid or freebies. If they want to learn more and put forth some effort, I lavish them with attention to help them. If not, I don't waste my time anymore.
POCs like this are great for us who care. It helps us to learn of any gaps in our defenses. The ones who benefit from this, yeah, they are always going to make it as worse as possible because that is thier market. We however, just waste our energy by trying to fight it. Those who take a keen interest, lets talk about how you go about finding security whether Admin or User. Lets talk about the possible exploits and the various means we have to stop them. Lets talk about getting really complicated with our solutions or making it simple. Because we are interested, we desire to learn many aspects.
Those who are new to the issues, lets guide them along. Lets give them what they want -- knowledge and experience. Lets encourage them to experiment to find the method they want.
Those who time after time after time click on all the wrong things, and go to all the wrong places ... well, what can you do? You tell them once, you tell them a thousand times. Yet they still have troubles. I have been leaning towards leaving the endless game of "what do I do now" and focusing on "what would I do if" things.
I feel too that the argument of using LUA or not, using SBIE or not, its all relative. Hey, I highly recommend LUA to lots of people. It is the easiest solution to many issues. But it is not the only solution. HIPS or not? Firewall or not? AV or not? Its some sort of competition with some folk (no-one in particular, just generalizing ) . There are many ways to go about having a secure system, and the one that works for each person is the correct one. I can say LUA is a PITA and inferior to being admin the same way you can say LUA is much safer and admin suxors. We are both right as long as it works. I wish there was less of a debate about what is the 'best' method and more debate over all the ways that are available to us (again, not poking at anyone specific).
Some things, like this POC, are so easy to stop. I would most likely never ever ever have an issue with it, and I am using Admin 24/7. Childs play really. Its a shame everyone doesn't have the urge to learn how to stop something like this. Even enabling Kees 1806 reg setting to block downloaded files from executing could mitigate this issue, and that is a really basic and easy method.
Sul.
Sully- Member
- Posts : 13
Join date : 2010-05-16
Re: DLL exploit testing
Completely agree with everything you wrote Sully.
For me personally, computer security is 50% pure fun and 50% boredom haha. I would probably never get infected even if I ran as full blown admin and used an unpatched IE 6 etc. Why is this? Simply because I have reasonable computer common sense and experience.
People like "demoneye's brother" are always going to get infected no matter what...unless you apply default-deny anti-execution and hide the "admin" password from them.
After trying out many security software combinations, I concluded that anti-execution and sandboxing (together with the respective security approach) is the only way to get as close as possible to 100% protection (taking into account ALL modern-day malware attack vectors). As I already said, this is why I am always interested in testing out "the latest and greatest" malware exploit to see if it can bypass this "100%" protection. So far, no exploit has succeeded, thus backing up my statements.
Whether this exact strategy (as I describe in my security/setup approach post) can apply to the general public and the "average user" is another story all together. The galling thing is that people who visit these types of security forums and take enough interest to read the comments are probably the ones who NEVER get infected by malware anyway.
For me personally, computer security is 50% pure fun and 50% boredom haha. I would probably never get infected even if I ran as full blown admin and used an unpatched IE 6 etc. Why is this? Simply because I have reasonable computer common sense and experience.
Have a read here: https://ssj100.forumotion.com/security-f7/what-is-the-actual-risk-of-getting-infected-t54.htm#252Sully wrote:Those who time after time after time click on all the wrong things, and go to all the wrong places ... well, what can you do? You tell them once, you tell them a thousand times. Yet they still have troubles.
People like "demoneye's brother" are always going to get infected no matter what...unless you apply default-deny anti-execution and hide the "admin" password from them.
After trying out many security software combinations, I concluded that anti-execution and sandboxing (together with the respective security approach) is the only way to get as close as possible to 100% protection (taking into account ALL modern-day malware attack vectors). As I already said, this is why I am always interested in testing out "the latest and greatest" malware exploit to see if it can bypass this "100%" protection. So far, no exploit has succeeded, thus backing up my statements.
Whether this exact strategy (as I describe in my security/setup approach post) can apply to the general public and the "average user" is another story all together. The galling thing is that people who visit these types of security forums and take enough interest to read the comments are probably the ones who NEVER get infected by malware anyway.
Re: DLL exploit testing
Yeah, I totally agree with this. Even the beginners who don't know much are better off than most simply because they are taking an interest. It isn't rocket science. Computers are very stupid, doing exactly what they are told. Once you know what is being told and how it is being told, even a moderate amount of knowledge goes a very long way.ssj100 wrote:The galling thing is that people who visit these types of security forums and take enough interest to read the comments are probably the ones who NEVER get infected by malware anyway.
Sul.
Sully- Member
- Posts : 13
Join date : 2010-05-16
Re: DLL exploit testing
Sully, ssj.. you two have collectively hit the nail on the head. Nice posts
It should be possible t oview all zipped files before extracting them, or am I missing something?
arran wrote:so as soon as you unzip the files and use VLC to play you movies VLC executes and runs the malicious DLL file,
It should be possible t oview all zipped files before extracting them, or am I missing something?
wat0114- Advanced Member
- Posts : 152
Join date : 2010-05-11
Similar topics
» Excel exploit testing
» java_rhino exploit
» 0-day exploit speaks Chinese, bypasses UAC
» Windows exploit protection mostly unused
» Buffer overflow exploit writing tutorial
» java_rhino exploit
» 0-day exploit speaks Chinese, bypasses UAC
» Windows exploit protection mostly unused
» Buffer overflow exploit writing tutorial
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum
|
|