Moving Day Is Here!

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.

Updated Reverse DNS Tool

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.

Moving Time!

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.

Linux Credit Card!

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.

The Art of Nmap Scanning, Part 1: Source Address Hiding and Obfuscation Techniques

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!

Conclusion

“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!

Socksify Anything

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 )?

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.

Reverse DNS Lookups with dnspython

Hey all,

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

SSHFS: Securely Access a Remote Filesystem

Once again, I find myself singing the praises of SSH. Seriously, is there much of a reason to have any other ports open anymore? The latest trick I have added to my list of things SSH can do is presenting a remote filesystem, securely.  Now, I’m sure most of us are aware that you can transfer files over SSH using a protocol called SFTP. What you may or may not be aware is that you can mount this remote filesystem locally using a nifty little tool called SSHFS. This is incredibly useful in a number of situations, allowing you to access remote files in a way that is easy for the user (as easy as local filesystems), easier to set up than solutions such as NFS, and as secure as SSH itself.

All you have to do on the remote machine you wish to access is have OpenSSH listening somewhere. For the client machine, you need to make sure you have SSHFS installed. To do this on Ubuntu, simply run:

sudo apt-get install sshfs

Now, to mount the filesystem locally, we first need to create a mount point for the filesystem:

mkdir /path/to/mountpoint
chown user /path/to/mountpoint

Where user is your username and sshfs is the location of the mountpoint. Now, to go ahead and mount the remote filesystem, simply execute this command with your own information inserted:

sshfs remote-username@address.of.server:/remote/folder/to/mount /path/to/mountpoint

Enter your password, and that’s it! Your remote filesystem should now be mounted.

Well that’s pretty cool in itself, but what if we want to go farther and have it mount at startup without any interaction from us? No problem, thanks to another cool feature of SSH called public key authentication. This feature allows us to log in to a system without providing the password of the user we are authenticating as, and instead authenticating users based on their RSA keys. If you trust me that this is secure, you can skip the next paragraph, but if you don’t, or you are curious how this works, read on.

The initial key exchange that SSH does is encrypted using an asymmetric encryption algorithm called RSA. In this key exchange, the goal is to exchange a symmetric key (AES, DES, whatever  you want) over RSA, which is unfortunately too slow to handle the large amount of data that needs to be encrypted to secure all of the SSH traffic. It is ideal, however, for assuring that a key exchange stays secure. The way it works is that each participant, both client and server, have a public key and a private key, and you give out the public key to anyone you want to be able to send you data. Once encrypted with the public key, the only way you can decrypt the data is with the private key, which only the local computer has. This technique has the useful property of providing both confidentiality and, as long as the private key is kept secret, authenticity. This means that as long as the private key is kept secret, you can authenticate to a system based solely on the public key, because no one but the authorized machine should be able to decrypt the proper symmetric key if it does not have the private key. If you would like more explanation than the incredibly brief overview I just gave, go check out the Wikipedia articles on RSA and on SSH, it should give you all the information you want.

Now that you don’t feel like you’re doing something incredibly dangerous (or maybe you still do, and you just like danger…:P ), follow these steps provided by OpenSSH on how to set up public key authentication between two hosts.  Once done, all that’s left to do is add the sshfs command that we used earlier to mount the remote filesystem to a startup script somewhere. To do this in Ubuntu/GNOME, you can simply go to System->Preferences->Startup Applications and add a new entry that uses our command from earlier as the command to be executed at login. If you are not on Ubuntu or using GNOME, you should be able to find documentation somewhere on how to make something run on startup.

That’s all there is too it, hope someone finds it useful. Just a short note, if you need to unmount the share, simply execute sudo umount /path/to/mountpoint and you’ll be fine. Enjoy!

Howto: Install Chromium on Ubuntu

Hey all, long time no post yet again. Exams can do that to you…but if you are much more fortunate than I and have some time to kill, I would highly suggest taking the pre-alpha of Chromium (the open source base of Google Chrome) for a spin. For a long while now I’ve been looking for a decent browser replacement for Firefox on my netbook, which is almost unbearably slow. Thankfully for my mobile browsing experience, Chromium seems to be shaping up to be that browser. Still has tons of bugs and crashes occasionaly, but for pre-alpha it’s still really polished and *really* fast. I will be writing a more thorough review once I get the time, but until then you all can just see for yourself.

A big fat warning before we begin: EXPECT THINGS TO BREAK. This isn’t even in alpha yet, so there are no guarantees as to your experience. That said, I’ve had a pretty good experience with it so far.

All you really need to do to get Chromium installed is to add the nightly PPA repository that the developers were kind enough to set up for all of us Ubuntu users and install the chromium-browser package. To do this, simply do the following:

Open up a terminal (or use Alt+F2) and execute the following command:

sudo gedit /etc/apt/sources.list

Now go to the PPA site to get the correct lines to add into the file.  To do this, simply select your version of Ubuntu and it will tell you what lines you need. It should look something like this (the lines for Intrepid):

deb http://ppa.launchpad.net/chromium-daily/ppa/ubuntu intrepid main
deb-src http://ppa.launchpad.net/chromium-daily/ppa/ubuntu intrepid main

Add these to the end of the file, save, then exit.

Now you need to add the repository key. Simply execute this command:

sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com fbef0d696de1c72ba5a835fe5a9bf3bb4e5e17b5

Great! The repository is now installed and verified. Now, simply update the repositories and install the package by running the following commands:

sudo apt-get update
sudo apt-get install chromium-browser

That’s it! Chromium should now be installed on your system, ready for you play around with. Enjoy.

Howto: Restoring DVD Backups on Ubuntu with DeVeDe

As a follow-up to my previous post on using Handbrake to rip DVDs, I wanted to do a short write-up on how to use a program called DeVeDe to restore those MKV, AVI, and MP4 files that you ripped earlier back to a DVD that you can use on any DVD player.

Before finding DeVeDe, I had been looking for a good solution for DVD creation on Linux for awhile. However, nothing had really impressed me very much. They generally had clunky, bloated UIs and didn’t support a wide range of file formats. DeVeDe changes all that; it uses the same mencoder backend that Handbrake does, allowing it to support a wide range of files (pretty much anything mencoder supports). It also sports a very simple but powerful UI, allowing you to make pretty much any customization you want to the menu and to have very complex DVD title structures. This is while also not being overly complex for entry level users, and pretty enough that it doesn’t burn your retinas to look at it.

Sound good? Then let’s get started. First, you of course need to install it. To do this on Ubuntu (Hardy/Intrepid/Jaunty, probably others as well), simply open up a terminal and execute the following command:

sudo apt-get install devede

That’s it! Alternatively, you can install it through Synaptic by searching for devede and installing the package. But what fun is that?

Now that DeVeDe is installed, let’s open it up and take a look.

Select Disc Type - DeVeDe

As you can see, you’ll first be prompted for what kind of CD/DVD you want to make. For this tutorial, we will assume you’re making a normal DVD, but there are a lot of other options you can follow if you wish.

Main Screen - DeVeDe

Now we are presented with the home screen, the place where all the magic happens. You are started out with the most simple DVD possible: a single DVD title, generically named, and a simple default menu. From here, you can do pretty much anything you want to do. In the interest of keeping this simple, we will assume that you just want to burn a backup of a single movie.  First things first: let’s name the title. To do this, simply click on Properties.

Title Properties - DeVeDe

Here, simply enter whatever you want the title to be named, and select the action you want taken after its finished (I would suggest just going to the menu afterwards). After you’re done, click OK.

We now need to add a video file to the title. To do this, simply click the Add button under the Files box on the right.

File Properties - DeVeDe

Click the file dialog button and select your video file. I would also suggest changing the format from PAL to NTSC if you are living in the U.S., most DVD players expect NTSC content here. If you know differently for yours though, or it can handle both, then don’t worry about it. If you do need to change to NTSC and you’re adding a lot of video files, you can make this the default on the home screen. From the add file dialog screen, you can also chose what audio track you want to use (if there are multiple), and you can add your own custom subtitle files simply by clicking the add button next to the subtitle box and selecting the sub file. There are also a number of very useful advanced settings that you can mess around with if you feel so inclined  (default settings have worked for me though). Before you finish, I would advise clicking the Preview button as well. It will encode a sample of the video with your settings and play it back so that you can preview what the DVD will look like when finished, and to make sure everything is in sync (very handy feature!).  Once you are satisfied with your settings, simply click OK.

Now, you need to configure your menu. For me, I really don’t care what the menu looks like, so I just leave the default in. However, I’m sure there are many out there who don’t share my thoughts, and would like to customize away. If so, simply click the Menu Options button at the bottom of the home screen.

Menu Options - DeVeDe

From here, you can make pretty much any change you want to. Add music, add a custom background, title the Menu, change the font, everything. I won’t go through this in depth, but you can play around with it and see what happens! You can also preview the menu from here, so you can see what it looks like as you’re making it.

You’re almost done now! The last thing you need to check is under the Advanced Options tab at the bottom. If you have a multicore CPU, I would advise selecting the Use Optimizations For Multicore CPUs option. This will greatly speed up your disc creation time. Once you’ve checked this, go ahead and click Forward.

Final Disc Structure - DeVeDe

You will now be prompted with where to save the ISO image of the DVD. An ISO image, for those who don’t know, is basically a bit for bit copy of a DVD, and we will use it to actually burn our DVD.

Save ISO - DeVeDe

Once done, just click OK and go get a cup of coffee. It will be a little while, as DeVeDe needs to encode your video into the proper format.

After it finishes, get a DVD and insert it into your DVD burner. Open up the folder where you saved the ISO, double click the file (right click->Disk Burner on Jaunty), and click Burn. Wait for it to finish, and then you’re done! Go plug it into any DVD player, and it should work like any other disc.

Image Burning

And that’s it! I hope this was helpful to some of you out there wondering how to create DVDs in Ubuntu, feel free to ask if you need help or clarification.