This is the first part in a series of posts that I am writing on the wonderful world of nmap, one of the most useful tools out there for the aspiring hacker. In this post, I will demonstrate a number of ways in which one can obscure, or even completely hide, the source IP address of port scans during a pen test from the eyes of even the most diligent sysadmin’s logs, allowing you to hide in a wonderful shroud of anonymity until you decide when and where to strike. As a bonus, many of these techniques can also be used to scan hosts that might otherwise have been unaccessible or only partially accessible to a normal scan, letting us map out the network much more effectively.

SOCKS Proxy Scanning

Probably the most obvious and straightforward of the techniques in this post, this strategy requires access to a public SOCKS proxy (list here), a compromised/public SSH host,  or (if you wish to abuse the service, and have your scans be incredibly slow and probably not very reliable) Tor. It also requires proxychains (or a similar application, like tsocks) to be installed on your system. Essentially, the idea is that instead of connecting directly to your target, as you normally would, you route your connect scan through one or more SOCKS proxies before finally attempting to connect to the given host and port. To do this is quite easy: simply set up proxychains as in my previous post, and use the following command to scan your host:

proxychains nmap -sT -PO target_host

And that’s pretty much all there is to it. However, there are some significant downsides to using this method to avoid detection. First, any open SOCKS proxies you use might be logging all of your actions (or could even be a honeypot), pretty much defeating the purpose of using it in the first place. In addition, routing your connections through proxies also obviously causes issues with latency, slowing down your scans both because you have to actually complete the three-way handshake (can’t use SYN scans), and because you are simply adding more hops to the route. However, it can be useful in cases where you need to tunnel your scans into (or out of) a network, it allows for the proper execution (through the proxy) of most nmap detection scripts, and is pretty easy to set up, so it’s something to keep in mind.

SYN Scan Spoofing

While this technique does not completely hide one’s IP address from being logged, it does at least prevent a system administrator from being able to determine the true source of a scan, absent any extra probing attempts. Essentially, nmap’s SYN scan spoofing takes advantage of the fact that, because you are not trying to complete the three-way TCP handshake, you can spoof your address to be anything you want without consequence. Of course, you won’t be able to see the results of the scan unless you use your IP address because you won’t receive the SYN-ACK if you don’t (unless you’re using idle scanning, which we will see shortly). However, you CAN hide your real IP address in a sea of fakes, preventing a concerned administrator from being able to trace back the true origin of the scan before you launch your assault. Neat, huh? Here’s all you need to do:

sudo nmap -sS -P0 -D decoy_host1,decoy_host2,decoy_host3 target_host

A brief explanation: the “-sS” flag specifies that nmap should use a SYN scan, and the -D flag allows us to input an arbitrary amount of decoy hosts to add to our scan. The -P0 flag, as before, disables ICMP pings, so once again you might be scanning a host that is down. The more decoys you add, the more hidden you will stay, but the slower your scan will go. If you are on a local network, also note that this will not change your MAC address, and this could definitely be logged (and is a dead giveaway that something bad is going on.) In addition, don’t use the -A flag (or similar), as the version detection techniques used by nmap could expose your IP address (more here if you’re curious). Despite these limitations, this scan is definitely quite effective at hiding your identity, and, because of how easy it is to use, is probably the first one that you want to turn to for general scanning.

Zombie (Idle) Scanning

Probably the coolest (and most complex) of these techniques is the idle scan (more awesomely known as the zombie scan). The concept behind zombie scanning is essentially to, in the great tradition of hacking, turn the logic of TCP protocol against itself. Rather than lengthen this already lengthy post with a description of how this scan works, I will refer the interested person to nmap’s very thorough documentation of the scan. In very short, though, this technique can completely hide your IP address, given you can find a zombie host that is receiving very little traffic and has predictable IP ID’s. Now, these can be pretty tough requirements, as most modern OS’s have  switched to rather unpredictable ID’s, but if you can find an older host (think printers, legacy systems) that has these features this is probably the best attack out of the lot as anonymity goes. The easiest way to go about doing this is to either a.) just scan the network with nmap and look for hosts that look unkempt, or b.) (my preferred method) just use your reverse DNS mapping of the network to find a printer, which in all likelihood will be suitable as a zombie. To check if your chosen host is vulnerable, you can use the useful tool hping3:

sudo hping3 -Q target_host -p port -S

This sends SYN packets to the host and prints out the difference in IP ID’s between the current and previous SYN+ACKs received. This is sample output from a host that could be used for a zombie scan:

HPING [target] (eth0 [target]):
 100949560 +100949560
 100949570 +10
 100949580 +10
 100949590 +10

If you can find a host like this, it truly and completely hides your IP address from the victim host. Here’s all you need to do with nmap:

sudo nmap -P0 -sI zombie_host target_host

That’s all there is to it! Given you found a suitable host, nmap will now scan the target host, and it will look as though the zombie host is the malicious host. Sneaky, huh? Note: if the zombie host receives ANY extra traffic during your scan from other hosts, you could get invalid scan results. Keep in mind that your results might not be wholly accurate using this method, and that scanning using this method can be quite slow.

FTP Bounce Scanning

The final technique I will be presenting here is FTP bounce scanning, a slightly more obscure but definitely useful method of port scanning. When the FTP protocol was first defined in RFC 959, it contained an interesting specification: that the PORT command could be used to attempt to connect to a port on another machine. While useful, certainly, for connecting to other FTP servers easily, it’s writers (fortunately or unfortunately) didn’t realize that this could and would be abused. The specifications were changed, but many older FTP servers still have this vulnerability (especially many network printers, oddly enough). If you can find a host that has an FTP server with this problem (which, nicely enough, nmap can scan for with the -A flag), you can use this scan to force the FTP server to act as an unwilling proxy for your scan, completely hiding your IP address. It can also, nicely, be used to scan inside a network in the case that the FTP server is exposed but the rest of the network isn’t. In addition, you could also possibly use it to launch further attacks against the host, as FTP bounce servers can be used to proxy arbitrary data onto a TCP connection. So what’s the downside? It is SLOW. Very, very slow. I’m working on a script that can divide the scanning amongst multiple FTP bounce servers, which could speed things up a bit, but it still has some bugs to work out (I’ll update here with a post when I get time to finish it). Really though, it’s best to keep this one for when anonymity is a must and speed is not a concern. For those situations, though, it works perfectly. Here’s how to do it:

nmap -P0 -b ftp_bounce_host target_host

Wait awhile, and you will hopefully have a list of open ports, and your victim will be wondering why a network printer just tried connecting to some ports on their system. Win!


“When you do things right, people won’t be sure you’ve done anything at all.” –Futurama

Although each technique here is great at hiding your identity while port scanning, that doesn’t give you a license to be stupid and scan anything and everything. Be selective (and be legal). While it’s great to know that J. Random Sysadmin isn’t going to be able to track you down if he notices something, it’d be best if he never noticed anything at all. After all, it may put people on their guard, which could make your job much, much harder. Chose which hosts and ports you want to focus on selectively (see my reverse DNS scanning guide), only enable features in nmap that require extra connections when you have to (nmap documentation), and, for the love of zombie jesus, don’t use -p1-65535 unless you ABSOLUTELY have to. Stick to those rules, and things should go quite well.

In my next post, I will be exploring the IDS/IPS evasion techniques built into nmap, that can allow you to scan behind otherwise restrictive firewalls. Until then, have fun scanning!

Reblog this post [with Zemanta]

Socksify Anything

April 15, 2010

As a follow-up to one of my posts awhile back, I figured I’d share a small tip with those who don’t use SOCKS proxies quite as often as I do. In my previous post, I showed how to set up an SOCKS proxy that tunnelled your (now encrypted) traffic through a remote SSH server, as well as how to configure Firefox to use that tunnel. But what if your application doesn’t support SOCKS proxies? And what if you want to tunnel through multiple hosts (I’m sure you could think of a situation :P)?

Well, you’re in luck: proxychains can handle all of that. When used to execute an application, proxychains acts a middleware layer, intercepting all TCP connections, wrapping them in the SOCKS protocol, and routing them through the proxies of your choice. If you’re on Ubuntu, it’s, as usual, brilliantly easy to install. One “sudo apt-get install proxychains” and you’re good to go. Now how do we go about using it?

The first thing you need to do to use proxychains is to set up a configuration file. On Ubuntu (and I’m assuming, any other install), there is a default file in /etc/proxychains.conf that you can look at for guidance, but I have included mine for reference just in case. Now, there are three places proxychains will look for a config file when it is executed: in the local directory, at ~/.proxychains/proxychains.conf , and in /etc/proxychains.conf (and they are prioritized in that order). Chose yours according to what works best for you. I’d assume that either your home folder or etc folder would be the best, as it will work without a fuss no matter what your $PWD is. Now, the proxychains config has a good number of options, so you’ll need to know what’s best for you. For most, the dynamic chain is best: it functions as long as one of the proxies in it’s configuration page is online. I’d also recommend enabling proxy_dns if it’s not on, to prevent DNS leakage. The rest of the default options should be fine. After that, all you need to do is add your proxy in the form of “proxy_type host port”, which, if you’re using an SSH proxy like in my previous post, will be something like “socks4 6789” .

Now save the file, and you’re ready to go. If you, say, want to update your system, all you need to do is “sudo proxychains apt-get update”, and away it goes. If you want to chain your traffic through multiple hosts, simply add more to your config file, and run “proxychains ./myapp”. Enjoy!

Update 04/16/2010: As mentioned in a previous post, tsocks is also a good application for socksifying connections, and worth trying if proxychains doesn’t work for you. However, you can’t (as far as I know) use it to chain multiple proxies together, so keep that in mind.

Reblog this post [with Zemanta]

It seems that not a week goes by any more that I don’t find some new, fun trick to do with SSH. A few weeks ago, I found one that to me has been especially useful.

I was sitting in the Tulsa International Airport, once again wishing that airports would just suck it up and provide free wireless access throughout their terminals. It’s a real pet peeve of mine, as layovers become incredibly more painful when I can’t waste away my time stumbling about the internet. I might even have to do something *shudder* productive…

Anyway, there I was, sipping some coffee and working on a project, when I noticed that there was an open wireless network available that was not one of those god forsaken Boingo hotspots. Being the curious person that I am, I decided to see if I could connect. Sure enough, it let me right on. Being the cautious person I am, I went to an HTTPS secured site to see what would happen. And sure enough, the normally valid certificate was invalid, pretty much guaranteeing someone was trying to listen in.  I was still happy though, at least I still I had internet access and could keep myself mildly entertained with that.

However, I was feeling especially curious that day, so I decided to try to tunnel my traffic over SSH to a box back in my apartment, keeping my oh-so precious personal data away from prying eyes. Besides, beats working. After a little digging through man pages, this task, to my surprise, turned out to be much simpler than I had expected. All you need is one SSH command and an SSH server that you have access to and has forwarding enabled (the default OpenSSH installation on Ubuntu does).

If you don’t have an SSH server set up and you’re using Ubuntu at home, simply execute this on your home machine:

sudo apt-get install openssh-server

This will install and start the service. Make sure that a.) your user password is of decent strength (SSH is a common target for password bruteforcing) and b.) that you have port 22 forwarded on your router if you are behind a NAT so that you can access it from outside of your local network. The SSH client should already be installed on a default Ubuntu install (you can also do this using PuTTY on windows).

Once you have these two things ready, just open up terminal on your laptop/netbook/mobile device and type the following:

ssh -Nf -D randPortNum

Replace randPortNum with a port number of your choosing (something above 1024 if you are not root, which is probable), remote-username with your username on the remote system, and with the hostname or IP address of your SSH server. If you are using your home server, I’d suggest using DynDNS to get a simple domain name to access it with. If you do not feel very comfortable with the command line, or you are lazy like me (I hate having to close the window after I’m done…), you can execute this command using Alt+F2, and the SSH client will prompt you for your password.

Now let me explain what exactly this command is doing. The N and f flags both specify that the command is to be forked into the background, so that you can do whatever you want after you execute it. Close the terminal, keep using it for something else, anything you please (just not killall ssh!). The D flag is the one doing the really interesting stuff: the OpenSSH developers decided it would be cool to put SOCKS proxy functionality straight into the client, and the D flag is how you access it. Basically, you are just telling SSH to start “local dynamic application-level port forwarding” (SOCKS proxy) from the specified port on your local machine to the remote host. Now, any program on your computer that supports SOCKS proxies will be able to connect to that port on your machine and have its traffic automagically forwarded (and encrypted!) across the internet to your remote machine, where it will then go out to its destination.

To add to it, tons of programs do support SOCKS proxies, more than you might think. Firefox, Opera, Pidgin, Deluge, Transmission (Tracker only), the list goes on. On top of that, using some programs (like tsocks) you can actually use any TCP based program over it. Very cool stuff.

To go ahead and encrypt your web traffic, open up Firefox (if you need Opera instructions, they’re probably very similar).  Go to Edit->Preferences->Advanced->Network->Settings (Configure How Firefox Connects To The Internet) . Select “Manual proxy configuration”, enter “localhost” for your SOCKS host and the port number you chose earlier as your port. Either SOCKS 4 or 5 should work (I use 5). Now, it should look similar to the picture below:

An Example Configuration

An Example Configuration

Now just click OK, close out the Settings dialog, and you’re done! Go here and check it out, your IP is now the same as the remote host’s. If you’re really paranoid, you can also make Firefox tunnel your DNS queries over the proxy. This prevents the nameserver of the local network feeding you bad DNS information or keeping tabs on what you are viewing (you are still relying on the remote nameserver being trustworthy though :P) . To do this, open up a tab, enter the address “about:config”, search for “network.proxy.socks_remote_dns” and set it to true. And that’s it!

This trick can be immensely useful in many situations, from securing your traffic across untrusted local networks, to getting around packet shaping/filtering, to remaining anonymous online. I now use it all the time on my laptop, and very rarely trust the local network. A word of warning before I sign off though, I was lucky on that hotspot because the attacker was not trying to launch a MITM attack against my SSH traffic. If they had, the keys would not have matched my previous connection attempts to my SSH server, and I would have been warned in big bold letters that I was being listened in on, and the SSH client would have quit. In this situation, securing your traffic may be more difficult, but not impossible. I may post later on how one might go about this.

Anyway, hope someone else finds this as useful and interesting as I do. As always, feel free to ask if you have any questions.

UPDATE 04/15/2010: I have done a follow-up post to this article describing how you can use proxychains to allow any program that uses TCP sockets to tunnel traffic over SOCKS proxies, not just ones that have built-in proxy support. I also show how to chain multiple proxies together.