April 26, 2010
Well, the day is here! I am officially moving my blog off of wordpress.com hosting onto duststorm’s VPS. You will still be able to access it at spareclockcycles.wordpress.com, but the main site will be spareclockcycles.org, so update your bookmarks accordingly. There will be a lot of messing around with DNS and the like going on over the next few hours, so I apologize for any downtime. I will put up a post when the move is complete.
April 25, 2010
A few posts ago I released some rather simplistic code to do reverse DNS lookups. While useful, many improvements could obviously be made. The lookup speeds were pretty dismal (15-25 lookups a second), stemming from my poor handling of timeouts and the fact that I had lazily ignored multithreading because I wanted to get something working fast. In addition, the code was just a giant blob thrown together into a Python file, which probably made a few peoples’ eyes bleed.
Because of these issues, I took the time today to rework the code so that everything is *much* cleaner now (everything broken nicely into classes and such), and is, in addition, fully multithreaded. To do the threading, I adapted a basic thread pooling class shamelessly taken off the interwebs to use Python generators for speed and RAM considerations, and to allow for thread callbacks to be synchronized. As a result, with 35 threads in the thread pool, I am now getting about 400-600 DNS lookups / second. Not bad for 45 minutes of work 😛 . You can grab the new code here.
April 24, 2010
Just got done registering my shiny new domain name (only $4 at netfirms.com with the coupon code DOLLARDOMAIN for those interested), so from now on you can all access my blog at http://spareclockcycles.org . You can also now contact me directly at supernothing AT spareclockcycles D0T org .
In addition, thanks to the generosity of my good friend duststorm, I will be moving this blog off of wordpress.com hosting onto his dedicated VPS. I decided to do this for a number of reasons, most of them related to the limitations of wordpress.com blogs. Hopefully, this will allow me to add a significant amount of functionality to the blog (like being able to host source files locally -_-), as well as possibly expanding the site beyond blogging into a general forum for discussions on security and the like. I should be completing the move sometime in the next week, so I’ll keep everyone posted.
April 21, 2010
It’s exam time, so I probably won’t be posting much in the next week or two, but I wanted to share something a friend just sent me. The Linux Foundation has now partnered with Visa to offer a Linux credit card. For every card activation, the Linux Foundation will receive a $50 donation, and gets a small percentage of every purchase you make as well. So if you’re looking for a new credit card, and you want to support the Linux devs in making Linux even better, you might keep this one in mind.
SIDE NOTE: I totally almost called this article “Tux Bux”, but I think we can all agree that not doing that was for the best.
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!
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 127.0.0.1 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.
April 13, 2010
Sorry once again for the long lull in posting. School has not been kind towards my desire to blog. I will hopefully be posting more frequently in the coming weeks and months.
Anyways, now that the apologies are out of the way, here’s a little something I was messing around with this morning during class. It’s often useful to be able to do reverse DNS lookups of a given IP range to find hosts with interesting domain names, whether they’re interesting because it looks like a network administrator has forgotten about them, or because they look like they weren’t meant to be found (you’d be surprised how many machines rely on this sort of security through obscurity), or just because they have something like “mail” or “proxy” in their name. A simple way to do this is to write up a short bash script that uses the host or dig commands. However, this is slow (because you have to spawn a ton of processes), and I don’t get to use Python.
Enter dnspython. dnspython is a great tool for working with DNS, so I’d suggest you look through their site if you’re interested in messing around with DNS at all. Doing a reverse lookup of an IP address is quite easy:
from dns import resolver,reversename addr=reversename.from_address(\"192.168.0.1") resolver.query(addr,"PTR").__iter__().next().to_text()
This will probably throw a NXDOMAIN error, being a local address and all, but you get the idea. Taking this, it’s obviously very easy to make a fast, effective script for scanning large ranges of IP addresses to find potentially interesting hosts.
I took a bit and wrote up a short python script to test how well it works, and it seems to be pretty effective, doing about 14-20 lookups / sec . I have attached it in case anyone would find that useful. Usage instructions are included: revdns.py . Be sure that you have dnspython installed, or else this will probably not work 😛 .
Hopefully I’ll be back soon enough with some more interesting and in depth things I’ve been working on.
UPDATE 04/24/10: So yeah, I just realized that I mistakenly referenced “PyDNS” as the name of the module I used, when in fact it was the incredibly useful dnspython module. My bad. That’s what I get for not checking my posts thoroughly. I updated all the references to it accordingly, but I figured for the sake of honesty I would clarify here as well. I also updated the source to deal with lookup timeouts a little better, if you care. Happy hacking!
UPDATE 04/25/10: I just released a much, much better version of this tool here. The code is now multithreaded, and handles timeouts much more intelligently. With these improvements, speeds are between 400-600 lookups/sec. Enjoy