Writing Buffer Overflow Exploits using BackTrack

[lupin]

Well, I succeeded in adapting the minishare exploit to work under XP SP3.

I won't write a long post about how I did it, I'll just give the essential information which should be all that's required, especially if you were learning the processes involved rather than just treating it as a copy and paste exercise.

The only 2 differences were;

1) The location in memory for the first usable memory address for the JMP ESP was different in the XP SP3 Shell32.dll file so that address had to replace the one in the original exploit.
2) The shellcode that I produced using the msfpayload and msfencode tools was different to what lupin had provided on his examples. Not sure why, maybe the version of the program I have is different. I'm using BackTrack4 Final (the latest distro as of the date of this post).

Please feel free to contact me if you would like to discuss this further or ask any questions.

Thanks.

Did a quick post about getting the tutorials working under SP3 here that explains some of the issues around this. Yes, you are right in saying that the JMP ESP address needs to be changed, as Service Pack 3 provides a new version of shell32.dll which is obviously structured differently from the one provided with SP2. Since we use a hard coded address for that JMP ESP instruction the address needs to change when the module changes.

There are a number of reasons why the shellcode might be different. Newer releases of Metasploit sometimes contain slightly modified versions of shellcode, different parameters fed to msfpayload will modify the shellcode generated and the shikata_ga_nai encoder in msfencode can produce different encoded output on subsequent runs. Differences in the shellcode are not overly important as long as it does what you need it to however.

[oldschool]

Thanks for the update, lupin. Very well explained as always.

Another reason for the altered shellcode that I didn't think of at the time was that my IP is different to yours so that would have been taken into account, although probably wouldn't have altered the code as much as it was.

Still, it performed as expected which as you say is the main thing. I'll stop rambling on now and give the other exploits a try.

[Noble_Hikikomori]

This reproduces the Internet Explorer Aurora '0 day' exploit, used (allegedly) by the Chinese to hack Google.

So the 'sophisticated' attack used on Google revolved around a '0 day' exploit? I thought it was something else, something more... more... sophisticated.

[lupin]

So the 'sophisticated' attack used on Google revolved around a '0 day' exploit? I thought it was something else, something more... more... sophisticated.

I think its more the whole operation that was considered sophisticated, not just individual elements of it (such as the initial exploitation vector - this 0 day.) Apparently the attack was well targeted at specific individuals within the companies, and the malware installed by the exploit was fairly unique. And of course not everyone thought it was that sophisticated. From what I have heard of it, it all seemed pretty run of the mill to me, but then again those on the inside may see more of the full picture of what was done. The rest of us just get small pieces of detail...

[freemymind]

Awesome work Lupin! Thank you for the time and effort you put into providing this tutorial.

[gilesc]

I should just mention - tutorial 1 was great... took me a while to get a successful exploit, but practice makes perfect.

However, when getting the vulnerable code for tutorial 2 from Rapidshare AVG reported it had a Trojan in it when I executed it on my victim system - I promptly trashed my vmware build.

Anyone else come across this? Anyone have a known good vulnerable BigAnt?

[lupin]

I should just mention - tutorial 1 was great... took me a while to get a successful exploit, but practice makes perfect.

However, when getting the vulnerable code for tutorial 2 from Rapidshare AVG reported it had a Trojan in it when I executed it on my victim system - I promptly trashed my vmware build.

Anyone else come across this? Anyone have a known good vulnerable BigAnt?

*sigh* Yes, you are correct, that installer has an additional added "feature" that triggers as you as you start it and before BigAnt is actually installed. I guess that explains why it had been removed from the Exploit-DB archive (which is where I got it from).

The funny thing is I had actually noticed this Trojan on my test VM a while ago, and removed it, but I assumed that it had got there via some of the other irresponsible stuff I do on that machine and I didnt link it to the BigAnt installer.

I will do a detailed post on how to analyse and remove this on my blog (it will make a good malware analysis post if nothing else), but in the meantime it runs as both a fake Adobe Update Manager and a fake Office Startup Agent executable, running from somewhere under C:\Program Files\Adobe and C:\Program Files\Microsoft Office\ from memory. Create a batch file that uses taskkill to kill both executables and then to immediately delete them. Doing it manually is too slow, as one process monitors the other to make sure its still working and will start it up again if its stopped.

If you delete the trojan the BigAnt server thats installed will be exploitable via the method described in the blog entry, however I understand if you dont trust that version now. I will try and track down a trojan free version and post it. And I will check this one for "bad shit" first....

[Lincoln]

I am the original author and I didn't know that it was taken down from exploit-db or even corrupted for that matter. I downloaded the app from cnet or freedownloadcenter (I can't remember) and it either was originally corrupted or it picked something up from my test machine on the way. More than likely it's the latter, so I want to apologize to lupin, gilesc, and everyone else.

While we're on the topic, I think its good time to mention some best practices when doing exploit development. The following isn't meant to mitigate any of the above, but should be noted.

A lot of this will sound like common sense to most, but I think it's worth repeating. When working in a test environment, more specifically testing exploits, it's always a good practice in a virtual environment with a connection to the host only. This is a precautionary measure, so that if the above happens, it's only happening to the virtual machine, which can be turned off/destroyed in seconds. On top of that, if you take regular snap shots of your virtual machine, you can revert back to the original setup at any time. It's a good habit to take at least take one snap shot of your test machine completely clean with all your debugging/analysis tools.

The second is, when testing software from public download sites, sometimes (not often, but it does happen) they come installed with malware already.

The original install file has been nuked months ago with my old machine, I will try and see if I can get a working *clean* copy and work with lupin to fix the issue.

[lupin]

I am the original author and I didn't know that it was taken down from exploit-db or even corrupted for that matter. I downloaded the app from cnet or freedownloadcenter (I can't remember) and it either was originally corrupted or it picked something up from my test machine on the way. More than likely it's the latter, so I want to apologize to lupin, gilesc, and everyone else.

While we're on the topic, I think its good time to mention some best practices when doing exploit development. The following isn't meant to mitigate any of the above, but should be noted.

A lot of this will sound like common sense to most, but I think it's worth repeating. When working in a test environment, more specifically testing exploits, it's always a good practice in a virtual environment with a connection to the host only. This is a precautionary measure, so that if the above happens, it's only happening to the virtual machine, which can be turned off/destroyed in seconds. On top of that, if you take regular snap shots of your virtual machine, you can revert back to the original setup at any time. It's a good habit to take at least take one snap shot of your test machine completely clean with all your debugging/analysis tools.

The second is, when testing software from public download sites, sometimes (not often, but it does happen) they come installed with malware already.

The original install file has been nuked months ago with my old machine, I will try and see if I can get a working *clean* copy and work with lupin to fix the issue.

Good advice there. I have also made an entry on my blog discussing some related issues here. Basically, you need to be careful when doing exploit development work, or even just when downloading and running stuff from the Internets (there are a few examples of why in that blog post).

Based on what I saw when I tested that installer, the trojan is embedded inside it, so either you have/had a file infector virus on your test machine or the installer was already Trojaned when you downloaded it. Im going to look at the Trojan in more detail once I finish work, so I will know more soon, but I personally think its more likely that the file was already infected when it was downloaded.

Anyway, will try and get a clean and vulnerable copy of BigAnt server up soon.

[nanoSpl0it]

Thanks for the great tutorial! I have been teaching myself local/remote exploit with online tutorials like yours and reading a couple books. I read through the first one, looks good. I will actually try it soon and go through the rest of them.

Of course I will be cautious of malware/trojan and the likes.