Debugging buffer overflow exploits

I am trying to achieve root on a free windows box right now. I have set up an environment locally to test a buffer overflow against a vulnerable service.

The exploit I found (on exploitdb) for the service said that it was written for Win7 SP1 x64. The machine I am testing on is Win10 Pro x64. I am currently trying to generate an windows/x64/messagebox python payload using msfvenom. Upon executing the python script that performs the exploit the vulnerable service crashes, but I see no message box. I am not sure how I go about debugging this script to see what exactly is going on.

I have a suspicion that the way I am executing the payload, it isn't possible to open a message box. I have tried using windows/x64/shell/reverse_tcp but it doesn't appear as though I can catch that using netcat.

Comments

  • @RNGesus said:

    The exploit I found (on exploitdb) for the service said that it was written for Win7 SP1 x64. The machine I am testing on is Win10 Pro x64.

    For some exploits this doesn't matter. Sometimes the exploit isn't written for a specific OS, just that is the OS it is tested on.

    I am currently trying to generate an windows/x64/messagebox python payload using msfvenom.

    Any reason you went with this? I dont think I've ever knowingly used this payload in MSFVenom.

    Upon executing the python script that performs the exploit the vulnerable service crashes, but I see no message box. I am not sure how I go about debugging this script to see what exactly is going on.

    I am not sure - I dont know what exploit you are using or what messagebox does. If it is clear text comms then you can try to use tcpdump/tshark to capture the traffic on the wire and see what that says (but this is rare).

    You could possibly read the config files for the payload and see if anything there stands out.

    I have a suspicion that the way I am executing the payload, it isn't possible to open a message box. I have tried using windows/x64/shell/reverse_tcp but it doesn't appear as though I can catch that using netcat.

    So if it is the box I am thinking of, I used windows/shell_reverse_tcpwhich worked well (but it also depends on which exploit).

    If netcat isn't catching, then you can always try meterpreter.

    I might be getting confused but I am fairly sure windows/x64/shell/reverse_tcp is a staged payload. This means it expects the listener to be able to send more malicious content, which obviously netcat cant do. For more on this, have a look at https://www.offensive-security.com/metasploit-unleashed/payloads/

    TazWake

    Note: https://www.nohello.com/

    Happy to help people but PLEASE explain your problem in as much detail as possible! If you say vague things like "It's not working", I cant help. This isn't Twitter so my DMs are always open.

  • @TazWake said:

    For some exploits this doesn't matter. Sometimes the exploit isn't written for a specific OS, just that is the OS it is tested on.

    Any guidance on knowing when it should matter? I would think it would for buffer overflows because of the storage size of various types in memory.

    I am currently trying to generate an windows/x64/messagebox python payload using msfvenom.

    Any reason you went with this? I dont think I've ever knowingly used this payload in MSFVenom.

    Yes, I am not familiar with msfvenom, metsploit, or buffer overflows. This seemed like an obvious payload with few moving parts to see if I was hitting the buffer overflow.

    So if it is the box I am thinking of, I used windows/shell_reverse_tcpwhich worked well (but it also depends on which exploit).

    I think you are thinking of the box I am working through. In fact, I think you have replied to me on the official forum thread, haha!

    If netcat isn't catching, then you can always try meterpreter.

    Is it pretty safe to make the assumption that I can use netcat unless the payload calls out meterpreter, vnc, etc?

    I might be getting confused but I am fairly sure windows/x64/shell/reverse_tcp is a staged payload. This means it expects the listener to be able to send more malicious content, which obviously netcat cant do. For more on this, have a look at https://www.offensive-security.com/metasploit-unleashed/payloads/

    I did some more investigation, and you're correct. windows/x64/shell/reverse_tcp is in fact a stager. I was looking for windows/x64/shell_reverse_tcp originally, saw the stager, and thought it was the 64-bit version of windows/shell_reverse_tcp.

  • @RNGesus said:

    Any guidance on knowing when it should matter? I would think it would for buffer overflows because of the storage size of various types in memory.

    I dont have a good answer on this but then I suck at this bit of boxes. In general I find trial and error matters. It may depend on how self-contained the application is.

    Normally you would expect quite a difference between an exploit tested on Win7 and an exploit on Win10 as the OS underwent quite significant changes.

    However, I have certainly found some boxes where a Win 7 exploit is significantly more effective than a Win 10 one. It may because the exploit is targeting an application which might not have changed on different underlying OSes.

    For me, solving this conundrum would probably take more time and effort than I am willing to spend all at once here, so I fall back on the trial and error approach a lot more than I probably should.

    Is it pretty safe to make the assumption that I can use netcat unless the payload calls out meterpreter, vnc, etc?

    I dont think it is that simple - but I am open to corrections. Certainly the unstaged, reverse_tcp shells tend to work with netcat but again, trial and error.

    Anything which gets more complex, I'd probably go for a metepreter handler.

    TazWake

    Note: https://www.nohello.com/

    Happy to help people but PLEASE explain your problem in as much detail as possible! If you say vague things like "It's not working", I cant help. This isn't Twitter so my DMs are always open.

Sign In to comment.