eBook
Available on Compatible NOOK devices, the free NOOK App and in My Digital Library.
Related collections and offers
Overview
- Not just another "hacker" book, it plays on "edgy" market success of Steal this Computer Book with first hand, eyewitness accounts
- A highly provocative expose of advanced security exploits
- Written by some of the most high profile "White Hats", "Black Hats" and "Gray Hats"
- Gives readers a "first ever" look inside some of the most notorious network intrusions
Product Details
| ISBN-13: | 9780080481111 |
|---|---|
| Publisher: | Elsevier Science |
| Publication date: | 05/19/2003 |
| Series: | Cyber-Fiction |
| Sold by: | Barnes & Noble |
| Format: | eBook |
| Pages: | 448 |
| File size: | 8 MB |
Read an Excerpt
Stealing the Network
How to Own the BoxBy Ryan Russell Tim Mullen (Thor) FX Dan "Effugas" Kaminsky Joe Grand Ken Pfeil Ido Durbrawsky Mark Burnett Paul Craig
Syngress
Copyright © 2003 Syngress Publishing, Inc.All right reserved.
ISBN: 978-0-08-048111-1
Chapter One
Hide and Sneak by Ido Dubrawsky
It wasn't that difficult. Not nearly as hard as I expected. In fact, it actually was pretty easy. You just had to think about it. That's all. It seems that many security people think that by putting routers and firewalls and intrusion detection systems (IDSs) in place that they have made their network secure. But that's not necessarily the case. All it takes is some small misconfiguration somewhere in their network or on a server somewhere to provide enough of a crack to let someone through ...
If you want to hack into someone else's network, the week between Christmas and New Year's Day is the best time. I love that time of year. No one is around, and most places are running on a skeleton crew at best. If you're good, and you do it right, you won't be noticed even by the automated systems. And that was a perfect time of year to hit these guys with their nice e-commerce site—plenty of credit card numbers, I figured.
The people who ran this site had ticked me off. I bought some computer hardware from them, and they took forever to ship it to me. On top of that, when the stuff finally arrived, it was damaged. I called their support line and asked for a return or an exchange, but they said that they wouldn't take the card back because it was a closeout. Their site didn't say that the card was a closeout! I told the support drones that, but they wouldn't listen. They said, "policy is policy," and "didn't you read the fine print?" Well, if they're going to take that position.... Look, they were okay guys on the whole. They just needed a bit of a lesson. That's all.
So, there I was, the day after Christmas, with nothing to do. The family gathering was over. I decided to see just how good their site was. Just a little peek at what's under the hood. There's nothing wrong with that. I've hacked a few Web sites here and there—no defacements, but just looking around. Most of what I hit in the past were some universities and county government sites. I had done some more interesting sites recently, but these guys would be very interesting. In fact, they proved to be a nice challenge for a boring afternoon.
Now, one of my rules is to never storm the castle through the drawbridge. Their Web farm for their e-commerce stuff (and probably their databases) was colocated at some data center. I could tell because when I did traceroutes to their Web farm, I got a totally different route than when I did some traceroutes to other hosts I had discovered off their main Web site. So, it looked like they kept their e-commerce stuff separated from their corporate network, which sounds reasonable to me. That made it easy for me to decide how I would approach their network. I would look at the corporate network, rather than their data center, since I figured they probably had tighter security on their data center.
Tools
First off, my platform of choice should be pretty obvious. It's Linux. Almost every tool that I have and use runs under Linux. On top of that, my collection of exploits runs really well under Linux. Now, OpenBSD is okay, and I'm something of a Solaris fan as well, but when I work, I work off a Linux platform. I don't care whether it's Red Hat, Mandrake, or Debian. That's not important. What's important is that you can tune the operating system to your needs. That's the key. You need to be able to be sure that the underlying operating system is reliable. On a related note, my homegrown tools are a mixture of Bourne shell, Expect, and Python scripts. There's a small amount of Perl in there as well, but most of the scripts are written in Python. Code reuse is important if you want to be successful at this game.
For network scanning, I prefer nmap. It's a great tool. I used to use strobe, but nmap provides so many more capabilities—everything from regular connection scans to FIN scans, UDP scans, slow scanning, fast scanning, controlling ports, and so on. It's my scanner of choice for identifying targets on a network. I occasionally rely on it for identifying the target operating system; however, I've found that, in some cases, this crashes the target machine, and that's something of a big giveaway.
For identifying the target operating system, I tend to rely on banner-grabbing. While nmap does provide for remote operating system (OS) fingerprinting, it can sometimes make mistakes. I've seen nmap identify a Solaris 7 host as an OpenBSD system. Banner-grabbing still remains sort of the "gold-standard" for remote OS fingerprinting. Most system administrators just don't get it. They could make my job much more difficult if they would just take the time to reduce the identification profile of their systems. It doesn't take much—just a little effort. Banner-grabbing can be a bit risky, since it usually involves a full connection in order to get this information; however, bringing your intended target down by using nmap's OS fingerprinting capabilities is not necessarily a good idea either.
So what are good port choices for OS identification? Well, two of the more useful TCP ports for banner-grabbing include port 80 (WWW) and port 25 (SMTP). Port 21 (FTP) and port 23 (telnet) are not really good choices. If the other side is smart, they've got ports 21 and 23 locked down through router access control lists (ACLs), firewalled, or access-controlled through TCP wrappers. Any way you look at it, it's a pretty safe bet that those two ports are logged somewhere. While, yes, you probably will get logged with WWW and SMTP as well. The difference is that the information usually is buried deep down in some log file that admins won't really look at, because they get thousands of connections all day, every day.
Now, for applications I rely on a variety of tools. Almost all of them are chosen for simplicity and for the ability to modify them for my own needs. For Web servers I prefer RFP's Whisker program. Yeah, I've tried Nikto and like it a lot (I even use it as a backup for Whisker), but I've gotten to really trust Whisker. You need to trust your tools if you're going to be successful with them. "But what about SSL servers?" you ask. Well, for those, there's sslproxy. While it in itself is not a tool to hack with, you can use it to provide the encryption to run Whisker against an SSL server. Nice, huh?
For Microsoft SQL Servers, there's LinSQL. This is a wonderful tool, essentially a Microsoft SQL client for Linux that I've modified to fit my needs. It never ceases to amaze me that network administrators put Microsoft SQL Servers in positions where they are accessible from the Internet. Another item that astounds me is how many times I've come across a Microsoft SQL Server where the sa account password is blank. Sometimes, that is enough to provide direct access to the network. LinSQL relies on the xp_cmdshell extended stored procedure to execute any commands you send to the operating system. Some administrators are smart enough to remove that procedure from the SQL Server. For those cases, I use SQLAT, for SQL Auditing Tools.
SQLAT is another Linux/BSD-based tool kit that can be used against Microsoft SQL Servers. SQLAT is essentially a suite of tools that can do dictionary attacks, upload files, read the system Registry, as well as dump the SAM. There is also a tool for doing a minimal analysis of a SQL Server with the output viewable as HTML. The tool suite requires access to the sa account in order to run some of the tools, but this usually is not a problem. If the SQL administrator has removed the xp_cmdshell extended procedure, the tool temporarily restores xp_cmdshell. In order to do this, the dynamic link library (DLL) containing the xp_cmdshell code must still be on the system. SQLAT provides a wealth of information about the SQL Server and makes cracking it much easier. Once I've gathered the necessary information about the SQL Server, I can obtain access to the system very soon thereafter.
My toolkit is wide and varied, and it contains a whole slew of exploits I have acquired over the years. I keep everything in what I call an "attack tree" directory structure. Essentially, I have exploits broken down between UNIX exploits and Windows-based exploits. From there, I break down these two categories into the subcategories of remote and local. Then I subdivide the remote and local categories into exploits for various services. The next level is the breakdown of the exploits based on the operating system they affect. The structure of the attack tree is mirrored in the attack tree directory structure. If I needed an exploit against say, Solaris 8's snmpXdmid service, I would go to the directory named /exploits/unix/remote/snmp/solaris/8 to look for the exploit code or a binary that has already been compiled and is ready to run. The tree structure looks something like this:
Exploit Attack Tree Structure
[ILLUSTRATION OMITTED]
This is by no means exhaustive. I also keep exploits or information about exploits for network devices like Cisco routers and switches. I have a directory dedicated to default passwords for various systems and accounts. All in all, I have a pretty big toolbox for cracking into networks.
Once I get into a system, I usually try to dump out either the SAM or capture the UNIX password and shadow files. If I can get those, then I download them to my local system and run them through John the Ripper. It's the best open-source password cracker around in my opinion. I've used it for a long time, and I've traded john.pot files with friends. My john.pot collection is now over 10MB, and my password list that John uses is almost 60MB. On a Windows box, if I can get access and obtain the SAM, I'm pretty much guaranteed that I'll have a password that I can use to further exploit that access.
The Scan
If you're going to scan a target, you need to pick the right time of day to do it. You must consider the possibility of detection seriously, especially since IDSs are getting better and better. Although the night might be a good time to scan, since they would probably be running a skeleton shift in terms of NOC personnel, I figured that the day would be a better choice. During the day, the volume of traffic going to and from their site would help hide my scans.
To start with, there was no point in doing a scan that pinged their hosts. Some IDSs trigger on that kind of activity, even if it's fairly low level. And most networks, if they're tight, will filter inbound ICMP echo requests. So, I started off by doing what can be called a "blind scan." This scan basically scans for some common ports using what is called a TCP SYN scan. With this type of scan, nmap completes two out of three steps of the three-way handshake TCP uses to establish a connection. This tends to allow me to avoid being detected by IDSs if I'm also careful to slow down the scan.
I prefer to use a SYN scan rather than a full-connect scan, because a connect scan will probably log the connection somewhere and may alert the network administrators that something suspicious is going on. So, for these guys, I slowed the scan down and looked only for ports 20, 21, 22, 23, 25, 80, and 443 (I expected to find 80 and 443, but I wanted to look for the others as well).
The initial scan went well. I identified six interesting hosts. How do I define interesting? Good question. Interesting means that there were multiple ports open on the host and that some of them were running services that could provide an avenue into the network. Some of these hosts were running two services, although both services were tied to the same application—a Web server. They all appeared to be behind a router that was providing some filtering features (looks like I guessed correctly), and they varied in their OS mixture. I made a list of systems and services I found (the IP addresses have been changed to protect the "innocent").
I had this list, but now I needed to find out some more information. First off, the Cisco devices—what were they? Were they routers or switches? Since I had access to the Web servers on these devices, that's where I started.
(Continues...)
Excerpted from Stealing the Network by Ryan Russell Tim Mullen (Thor) FX Dan "Effugas" Kaminsky Joe Grand Ken Pfeil Ido Durbrawsky Mark Burnett Paul Craig Copyright © 2003 by Syngress Publishing, Inc.. Excerpted by permission of Syngress. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
1. Hide and Sneak—Ido Dubrawsky2. The Worm Turns
3. Just Another Day at the Office
4. h3X’s Adventures in Networkland—FX
5. The Thief No One Saw
6. Flying the Friendly Skies
7. dis-card
8. Social (In)Security
9. BabelNet
10. The Art of Tracking
Appendix The Laws of Security