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.

Linux Credit Card!

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.

Reblog this post [with Zemanta]

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]

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

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

Reblog this post [with Zemanta]

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

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

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

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

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

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

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

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

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.

A few days ago, AT&T announced the specifics on a trial of their new pricing program, and, in true AT&T fashion,  continued their rape the American consumer in another attempt to keep us in their profitable technological dark age. I suppose that may be a little harsh, but hey, I am not so happy right now. I’m sure you will forgive me my moment of rage. So what is their new, creative pricing plan? Make you pay more (a lot more, of course) to get the service you have today.

Apparently, AT&T has decided that they are tired of people’s access to “unlimited” broadband services (godless freeloaders), so they have decided to start running trials in which users are charged by the gigabyte for Internet access. What this essentially means is that without any discernible increase in the cost of providing their service, they have taken it upon themselves to greatly increase the cost of their service to the average consumer. To get the same unlimited access that you’re paying 20-35 dollars a month for now, you will have to pay (at least) 150 dollars to AT&T for in the future. Let me repeat that: AT&T is implementing a 500% price hike for no apparent reason. Well, other than greed, that is.

Now, to be fair, AT&T has put forth a few arguments on why this price hike is necessary. The first and foremost among these arguments is that people are actually using the bandwidth that they paid for. And they can’t have that. They first tried to bump up their profit margins again by trying to force web companies like Google and Yahoo to pay more for all of their web traffic to be prioritized , a potentially disastrous proposal for the internet as a whole, and a definitive death blow to the cause of net neutrality. Unfortunately, the do-nothing attitude of Congress rejected the net neutrality bill that would have prevented such a thing from taking place, but at least Congress restrained itself from making the telecom’s brilliant idea law. Because of this setback, the AT&T and the telecoms were forced to go back to the drawing board. Looks like they’ve decided that if they can’t take from the provider side, they’re going to take from the consumer. And they want it all.

The second most quoted reason for the price hike is much more sickening, however. AT&T has gone around proudly declaring that they need the money to keep pace with technological innovation, so as to continue to provide their customers with “superior service.” Hrm…you mean like the $200 billion dollars in taxpayer money you and your telecom buddies were given back in the 90’s to achieve the goal of 86 million U.S. homes with symmetrical 46mbps internet connections by 2006? Or was that not quite enough for you? While they’ve sat counting the money they robbed from the American people, we have quickly slid from 1st worldwide in broadband penetration to 25th. And please, spare me the “we’re too large of a country, Japan has it so easy” rhetoric. In case you didn’t realize, Japan is a country  about the size of California, and I don’t think that ANY Californians have yet to be blessed with the 100mbit/s internet connections that most Japanese citizens enjoy. Oh, and telecom companies? I’m still waiting for my $2000 refund check (or, preferably, my faster internet connection). And don’t think I’ll forget.

Their third line of reasoning is just silly. AT&T argues that because it worked in Europe (an arguable point) and on cell phones (a ridiculous point), it should now be the rule rather than the exception. I can’t help but wonder at how they decided that Europeans liked paying more for their internet connections. My guess is that their definition of “worked” is that people didn’t storm their corporate offices with pitchforks. Well, either that or the entire continent is comprised of masochists. You can decide which is the more likely scenario. But believe me, if I or any of my friends could have an unlimited 3G connection that didn’t cost an arm and a leg, we would subscribe in a heartbeat. However, providers just will not do that, regardless of the MASSIVE consumer interest in such a service. Why? They make more money per kilobyte when they charge by the kilobyte than when they give people an unlimited pass. It has nothing to do with need, or an increase in traffic, or a better way of thinking about providing internet service for consumers. It is about them padding their already enormous profits with more of your hard earned money.

I mentioned in the title of this post that this was a cautionary tale. I want to clarify what I mean by that. First, I want to caution the American people: if we continue to let the large corporations in this country dictate the progress of technological innovation for their own gain, we will fall further and further behind the rest of the world. Technology, with all its benefits, has made this country the great place that it is, and to let that slip away for the short-term profit of a wealthy few would be one of the worst decisions that we could make. The hard economic times that we are now in would devolve into something much worse without our technological upper-hand. Second, I want to caution the telecom companies, specifically AT&T: be careful on the ground on which you tread. You’ve already been lucky so far that the U.S. government has not taken action against you for your monopolistic business practices now and your blatant fraud back in the 90’s.  Price gouging your customers to the point of ridiculousness while simultaneously stealing their tax dollars is not going to win you any friends. Eventually, your misdeeds and lies will come into the public light (probably after you pushed peoples’ pocketbooks just a bit too far), and people will be calling for heads to roll. When that happens, you’re going to need all the friends you can get.