Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 42

Thread: Writing Buffer Overflow Exploits using BackTrack

  1. #21
    Super Moderator lupin's Avatar
    Join Date
    Jan 2010
    Posts
    2,943

    Default Re: Writing Buffer Overflow Exploits using BackTrack

    Quote Originally Posted by oldschool View Post
    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.
    Capitalisation is important. It's the difference between "Helping your brother Jack off a horse" and "Helping your brother jack off a horse".

    The Forum Rules, Forum FAQ and the BackTrack Wiki... learn them, love them, live them.

  2. #22
    Just burned his ISO
    Join Date
    Feb 2010
    Posts
    7

    Default Re: Writing Buffer Overflow Exploits using BackTrack

    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.

  3. #23
    Just burned his ISO
    Join Date
    Mar 2010
    Posts
    5

    Default Re: Writing Buffer Overflow Exploits using BackTrack

    Quote Originally Posted by lupin View Post

    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.

  4. #24
    Super Moderator lupin's Avatar
    Join Date
    Jan 2010
    Posts
    2,943

    Default Re: Writing Buffer Overflow Exploits using BackTrack

    Quote Originally Posted by Noble_Hikikomori View Post
    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...
    Capitalisation is important. It's the difference between "Helping your brother Jack off a horse" and "Helping your brother jack off a horse".

    The Forum Rules, Forum FAQ and the BackTrack Wiki... learn them, love them, live them.

  5. #25

    Default Re: Writing Buffer Overflow Exploits using BackTrack

    Awesome work Lupin! Thank you for the time and effort you put into providing this tutorial.
    15" MBP 8 gigs o ram 256 gig SSD in drivebay + 256 gig 5400 HD
    1000HE EEE 30 gig SSD 2 gigs Ram

  6. #26
    Just burned his ISO
    Join Date
    Mar 2010
    Posts
    1

    Default Re: Writing Buffer Overflow Exploits using BackTrack

    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?

  7. #27
    Super Moderator lupin's Avatar
    Join Date
    Jan 2010
    Posts
    2,943

    Default Re: Writing Buffer Overflow Exploits using BackTrack

    Quote Originally Posted by gilesc View Post
    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....
    Capitalisation is important. It's the difference between "Helping your brother Jack off a horse" and "Helping your brother jack off a horse".

    The Forum Rules, Forum FAQ and the BackTrack Wiki... learn them, love them, live them.

  8. #28
    Member
    Join Date
    Jan 2010
    Location
    The new forums
    Posts
    462

    Default Re: Writing Buffer Overflow Exploits using BackTrack

    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.
    Last edited by Lincoln; 03-19-2010 at 05:33 AM. Reason: spelling

  9. #29
    Super Moderator lupin's Avatar
    Join Date
    Jan 2010
    Posts
    2,943

    Default Re: Writing Buffer Overflow Exploits using BackTrack

    Quote Originally Posted by Lincoln View Post
    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.
    Capitalisation is important. It's the difference between "Helping your brother Jack off a horse" and "Helping your brother jack off a horse".

    The Forum Rules, Forum FAQ and the BackTrack Wiki... learn them, love them, live them.

  10. #30
    Just burned his ISO
    Join Date
    Jun 2009
    Posts
    3

    Default Re: Writing Buffer Overflow Exploits using BackTrack

    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.

Page 3 of 5 FirstFirst 12345 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •