abene.cs.pdx.edu bl0g

Wed May 30 21:33:01 PDT 2007: Final Entry

This log reads bottom-up and the background is important, so you might start there. `date` headings denote a new entry.

Before performing the flood attack on ago to stop the resets, we tried to send enough ack packets that tcpdump would slow way down. We didn't have a facility to send TCP packets fast enough, so we used pktgen.

One of our other attempts was to forge a 3-way handshake with hping. Since we could listen to the wire and redirect any packet to our attack VM zed using ebtables, we could forge packets from any address. Since we could also see all sequence information, we could create a forged full-open TCP connection to ago in hopes of exhausting resources. Since it is not a "real" connection in that our local system does not keep any kernel state, we can create as many hung-open tcp connections as we want and proved much more effective than a syn flood. While this did appear to slow ago down much (web/ssl/ssh stopped responding) it eventually clogged our own system.

It appears that iptables keeps state, even though there is not an assocated state in the local network stack. iptables keeps connection state based purely on watching traffic and even though hping is generating it, iptables thinks it is routing it. Though there was not time, we were going to launch the attack on a different VM with iptables connection tracking modules completely disabled. This was not possible on zed, as zed was our MitM host and needed conneciton state to redirect SSL and SSH localy.

In the spirit of openness, below are all of our ssh/ssl mitm logs and associated scripts. In addition, we have a patch against dropbear-0.49 which modified the ssh client 'dbclient' and ssh server 'dropbear' as described in previous blog entries. The '+lines' page is a simple readable output which might allow you to see what we were doing without all the garbage included in a full diff patch, though both are included. Note that this attack supports SSH2 MitM, where dsniff supports only SSH1. Also note that this does not MitM key-authenticated sessions.
ssl mitm logsssl-mitm-logs.tar.gz
ssh mitm logsssh-mitm-logs.tar.gz
Dropbear +linesdropbear-0.49-mitm-patch.txt
Full Dropbear 0.49 patchdropbear-0.49-mitm.patch
Initial email to jrbinitrjb.txt (feel free to login via ssh)
TCP Full-connect Forge Scriptforge-tcp-sh.txt

Early morning on the 30th...

Ack! (err... RST!) It appears that ago has gone for broke and started resetting all tcp sessions, including connections from itself. I wouldn't have expected them to do this, but tcpdump -e confirms the mac... so unless it is someone else doing this, forging ago's mac, they are simply DoSing the localnet. This means we can't forge ourselves as ago to connect to phantomd and redirect the flood back at ago to bring the network back up! We started a pktgen attack from our system as well (hence the 1Mpps spikes in ourmon/~400kpps sustained graphs on morris), though all the network traffic and inevitable colisions on the network hub made the attack useless. If we could have redirected phantomd at ago's openvpn or NFS port, it might have worked. In hindsight, we should have put openvpn on phantomd as well so we could stay in even in the event of TCP resets.

Unfortunately, this also means we can't get back into phantomd to zcat /tmp/gconf.[0-9]* and hope for root passwords! C'est la vie.

Tue May 29 18:43:44 PDT 2007

ago decided to comply and turn off tcpkill. We have redirected our 115kpps flood (according to morris) at mitnick to slow them down enough to get a MitM attack in. Here is hoping for a password! We noted in our ssh MitM logs the following entry:
May 29 14:48:53 zed dropbear[2003]: local(force)_user='ago', orig_user='drfriq', pass='Lowpro8q'
[root@geek ~]# finger drfriq@cs.pdx.edu
Login Name TTY Idle When Where
drfriq Joshua Pfaendler < . . . . >
Sadly, this password no longer works, though it is very recent!

It also appears that phantomd got back into their system and changed passwords again. We ssh'd in, changed 'em back and created our own su and sudo commands which log the password to a file (echo '%s' | gzip > /tmp/gconf.$$). We assume that gzip is enough to obfuscate the file so that it isn't obvious; unless of course they use 'file' and decide to zcat it to see what is inside! Out of curiosity, we turned off the authentication for their snort web interface at https://phantomd.cs.pdx.edu/base to see what the interface looks like. It is of interesting note that snort thinks the traffic is mostly TCP, dispite our 115kpps attack coming out of their nic. Certainly it makes sense that pktgen would bypass packet hooks, but it is an interesting point from a forensic point of view. tcpdump doesn't show anything on their system either. Except for a strange process and kernel module running on their system, network tools say very little.

root@phantomd:/var/www/base# kill -9 $$
Connection to phantomd closed.

Mon May 28 22:02:44 PDT 2007

After looking at the SSL MitM logs, it appears that phantomd has changed their blog password. The new password is "!Pe3gasus1". Interesting that this used to be the login password to 'invalid' but no longer appears to be.

Mon May 28 19:59:16 PDT 2007

Since ago is resetting all TCP connections not associated with ago, we decided that it is important to take them down. They had removed our access to their system and changed passwords, so direct login access is unavailable. We decided to start our attack from phantomd since we have access to their system, and dont want to DoS ourselves in the process.

In order to login to phantomd at all due to ago's RSTs, we forged our ip as being ago's, and directed ebtables to forward all packets destined to ago's mac to our attack system zed.
-p IPv4 --ip-dst -j dnat --to-dst 0:5:dd:68:14:7 --dnat-target ACCEPT
After breaking into phantomd's system last week, they changed their passwords and disabled root's ssh login, making our ssh key auth backdoor stop working. We could still login as their user 'invalid' with our ssh key, as it had not been removed from .ssh/authorized_keys2. They are running X windows and administrate their machine from the console. As their user, I ran vino-preferences and setup remote access via VNC. After VNCing to their system (over our vpn, posing as ago to avoid the RST), I found the screensaver password, which I shotdown with killall gnome-screensaver. The hope was that they had left open a root prompt which I could then retake the system with. Unfortunately, they did not. They did, however, have a 'sudo gedit /var/www/html/phantomd/index.html' window. Thus, gedit was running with permissions of root. After browsing around gedit's preferences, I found a python plugin which allowed a python interpretave interface from within gedit. With this, I executed 'import os; os.system("/bin/sh");' and hoped for a root shell. gedit locked up, and appeared to stop responding. I clicked over to the terminal which 'sdo gedit' was launched from, and there was sitting a friendly '#' prompt. This was enough access to restart sshd with allow-root login and we are back in as root! We changed their root and 'invalid' user passwords in hopes of holding the system a bit longer to take ago down. The next couple days could be interesting...
We have also updated the phantomd blog: phantomd bl0g

Taking ago down
We used the pktgen module which creates a kernel thread to send a cached udp packet out the interface in a tight loop as fast as possible, bypassing all routing code. It is for debugging and does a great job at sending lots of packets, really fast. We saw traffic between a FiOS connection and ago's box via UDP port 1194, which we assume to be openvpn. Knowning that ago is using a UDP service, we can flood it with packets to that port (pktgen is limited to udp packets) to use as many resources and compute time as possible.

Side effects
We clocked the packet rate at roughly 135kpps, and phantomd is surprisingly still responsive. Ago, on the other hand gets about 12% dropped packets (hping ACK to port 80). The other great side effect is that the RSTs coming out of ago are few and far between. So much so that web traffic and SSH connections work without a hitch to the other systems in the network. Finally, the lab is usable again, even though it reuqires a 135kpps flood to ago in order to use it. Ironic that a flood of this magnitude offers QoS!

Now that we have effectively knocked ago off, we are in a position to pretend we are ago again. If they ssh to their system, they will hit our system first as they are gagged and cannot send resets in a timely manner. We hope that they will login to our system with their password so that we might login to theirs and shutdown this attack, locking them out of their system more permanently. Once ago's attack is done, we will direct our 135kpps attack at mitnick, and hope that we can get their login/pass in the same way.

phantomd's console via vnc :)

Fri May 25 19:43:15 PDT 2007

Our MAC has been hard-coded in the router, though we found a way to thwart the attack described below with the random mac-source arps. Since we are runing Xen, and since all virtual machine packets move through domain0's bridge (xenbr0) we can use ebtables to DNAT the destination MAC address to whatever we wish, regardless of what it was. This is possible since we are plugged into a hub and can see all of the packets in order to dnat them. This creates the opportunity to really be anyone, without needing to use ARP to get the packets directed at us. I am still exploring the possible attack options for this. One possibility is of a MitM without needing to do the ARP MitM before hand. I'm still working out the details on how to make this work. There is still the problem of RSTs, but perhaps we can make that not matter by using blacknets as source addresses... we will see.

Currently there is a real-time RST attack on the network. Originally, ago decided to RST any TCP flows which were not its own. To get arround this, we used the MAC DNAT described above to become ago by redirecting packets going to ago's mac to our mac. OpenVPN was then installed so that we can communicate with our system via UDP to administrate it remotely; this was only possible after using ago's ip to avoid RSTs.

Since ago DROPs packets to ports instead of doing host-prohibited, the ACKs the router was sending to ago's mac were ignored. Were ago not setup to drop packets to unknown ports, it would have responded to the acks which were involved during the impersonation of ago, and dropped our http connection used to download OpenVPN. Thank you ago for droping instead of RSTing; yet another reason not to DROP packets.

Shortly after (couple hours) we installed OpenVPN so we can administrate our system, levin started RSTing all of ago's TCP flows in retaliation. Now TCP is verboten on the subnet; our trick of being ago no longer works. We can still get to our box via udp, but any attempt to send a tcp SYN+ACK is responded with a RST to both the sender and recipient.

I am playing with things like shrinking the window to really-small or using fragrouter to make the packets not look like TCP, but I'm not sure if this will be enough to evade the RSTs. More soon ...

Wed May 23 14:12:47 PDT 2007

I think its time for port security. I was only able to login to my system by sshing to zed ( mac) and then sshing into abene. The network is overrun by forged arps of random macs. Even capncrunch is being forged, and they no longer exist. I am not certain who is doing this, but it is not phantomd since they are also being attacked with random arp replies. I speculate that it is mitnick since they state in their blog that they think that the MitM is either abene, or phantomd. This could also be resolved by getting our MAC hard-coded in the router. I'll ask again and see if it can be done.

Tue May 22 15:18:43 PDT 2007

Installed / configured snort. There is sooo much arp traffic, that we added 'not arp' to the expression and removed rules which don't make sense (like IIS, etc...). We also may have levin's root password, though we can't test it 'cause they are key authenticated. We are presuming that since our SSH MitM effectively DoS's their login since they are key-only, that they decided to try (in vain) to login as root. Below is the log snip. Hopefully the will login at the console, enable password logins and give us their password :)

Tue May 22 14:19:09 PDT 2007

We would like to get ago's root password, so we have engineered a way to require them to either login directly as root, or su up to root. These are the steps taken:
  • renamed the wheel group in /etc/sudoers to whee1 (one, not L)
  • turned off all mingetty entries in /etc/inittab to disable console login
  • set /boot/grub/grub.conf's timeout=0 so if they reboot
  • they get 0 seconds to choose bootloader options.
  • removed suidroot lsof utility which we used as a backdoor.
  • kept our DSA keys in place at authorized_keys as a backdoor.
  • hard-coded's mac as out MitM MAC so we can stay there.

    Tue May 22 10:22:53 PDT 2007

    We now have levin's blog and password. They were using basic auth and SSL MitM worked. They seem to have a rather un-interesting blog and I wonder if it is fake: levin.html
    The user/pass for levin's blog is jrb/nachonachoman.

    Tue May 22 09:50:50 PDT 2007

    ROFL: Excerpt from mitnick blog below. They think that 00:05:DD:69:14:07 is the real router but they have it backwards! :DD:69 is us!!! They are trying to DoS the poor cisco! Jim, I sure hope it is faring well :) ... that and I hope they hard-code what they think the router's mac is 'cause we'll own the MitM perminently!!!
  • After arpwatch ran a while, determined that many IPs were being announced with the MAC 00:05:DD:69:14:07, including the router; when the router subsequently flip-flopped to the very similar MAC 00:05:DD:67:14:07, a 'battle' would ensue with multiple flip-flops, about 3 per second. I believe, but am not positive, that the real MAC of the router is 00:05:DD:69:14:07, because I tested various connects with lynx to google.com, etc, with 'arp' reporting this as the MAC, and connectivity was not impaired. However, it's possible that either somebody is proxying or I'm simply wrong.
  • Installed 'nemesis' with the intention of attempting a DOS attack against 00:05:DD:67:14:07. At this point a member of phantomd walked in, meaning there were people on both sides of me, so I switched to something else.
  • Configured snort for syslog output and enabled the arpspoof preprocessor with only our IP and MAC, since I'm not absolutely positive of anybody else's MAC. This didn't appear to give any results after a couple minutes, and that plus the fact that the vast majority of arpwatch output is noting flip-flops in the router's MAC, plus the plainly visible output on the screen of morris, leads me to believe that it's possible that we are the target of a (unicast?) ARP poisoning attack in which the attacker wishes our machine alone to believe the router is it. Still not sure on this though, but it would make sense because we are on top in points.
  • Constructed a crude DOS attack against 00:05:DD:67:14:07, a shell script to run nemesis endlessly to inject a TCP SYN packet aimed at port 22 allegedly from ago's IP and an unused MAC. After testing this a bit and looking at the arpwatch logs, I had a 'duh' moment when I realized the other machines having flip-flops reported were all flip-flopping to/from 00:05:DD:69:14:07. It would make sense that that is the fake MAC, so retooled flood.sh to blast SYN packets on port 22 at that address. Sadly, initial testing revealed no effect on the frequency of the router flip-flops reported by arpwatch, leading me to believe that this approach is ineffective against our mystery attacker. It should be noted that about 2 minutes after I started flood.sh, a member of phantomd burst into the lab and started checking things out on his machine. That machine also seemed to have the most hard drive activity during the attempted DOS.
  • `

    Tue May 22 09:42:50 PDT 2007

    SSH MitM snagged us the user invalid@phantomd.cs.pdx.edu which had sudo /bin/sh priveleges and allowed us the capture the flag. I cant believe that their flag simply contains 'segfault' ... but it is clever, and based on the mtime, I doubt it is fake.

    I placed our keys in /root/.ssh/authorized_keys2 and also /home/invalid/.ssh/authorized_keys2 as a back door. Root ssh login works!

    We also re-ripped mitnick's blog, in case you've not read it recently: mitnick3.html

    Sun May 20 22:51:51 PDT 2007

    In a email thread between Steve Bellovin and Bill Sommerfeld, they note that some ssh client implementations maintain a separate database for types of host authentication. For instance, If I am used to connecting to ago and I know the RSA key for ago, everything is fine until ago changes to DSS instead of RSA, and now my system is unaware of the DSS signature. Thus, we are back to the original key distribution problem. By default, the OpenSSH client (and I expect others as well) only saves the ssh-rsa signature, and not the ssh-dsa signature. Because of OpenSSH's failure to save both, we are able to exploit this. As of a few moments ago, our dropbear MitM has disabled RSA and allowed only DSS host authentication. This changes the message output of the OpenSSH client from something like "WARNING: SOMEONE IS DOING SOMETHIN NASTY" to something like "Uknown host key; install?" or worse, something automatic as is configured on all of the CAT systems: "Warning: Permanently added 'ago.cs.pdx.edu,' (DSA) to the list of known hosts." (note it says DSA and not RSA, as it would in most circumstances). Perhaps this will snag us more victims. For the past 24 hours, they have been getting the "SOMEONE IS DOING SOMETHIN NASTY" message, and now they are getting the friendly "Host key unknown" message. Time will tell!

    The thread between Bellovin and Sommerfeld is here: http://arcknowledge.com/ietf.secsh/2002-07/msg00036.html

    Sun May 20 22:38:58 PDT 2007

    Before we reloaded abene the first time, we took a tar of the entire system image (exculuding stuff like /usr/src). We weren't sure what to do with it yet, but knew it would be important later. We have extracted that image into /var/ftp and it is now world-readable with anonymouse access. If anyone reports a capturetheflag file like the one below, it is our decoy, and the attacking team should have known better (especially since we are running fedora core, and the extracted image is Ubuntu)! Muahahahaa... decoys...

    Sat May 19 22:39:24 PDT 2007: SSH MitM: Implemented, tested, proven!

    The Theory
    About two weeks ago, we set out to make ssh MitM work. dsniff includes ssh v1 MitM support, but not v2. Since everyone works on v2, we had to re-write the attack. The attack takes a similar form of SSL MitM and has the same basic steps:
  • Get in the middle (arp or however)
  • Redirect a connection to yourself
  • Accept the connection and connect to the original destination host
  • Looks like: Alice -==SSH=> Eve -==SSH=> Bob
    So we understand this simple MitM concept. The trick, once again, is to make Bob think that Eve is Alice, and for Alice to think Eve is Bob. If Alice knows Bob's key ahead of time, this is not possible (just like in SSL) as she can compare the host fingerprint and know something is wrong. We assume that alice is inept: she does not check the fingerprint and ignores all warnings from her system that the system she is connecting to is evil.

    The other half of the equation is to make Bob think that the connection came from Alice. Note that Bob doesn't authenticate Alice with a key, but rather a user and password which Eve can proxy.

    Implementation of this attack is a bit tricky. We chose to modify the ssh daemon/client "dropbear" which is freely available and open source. It has a smaller codebase than openssh and was certain not to step on any pieces of openssh which we had on our system for our own administrative access. We changed the code from dropbear to accept *any* user/password pair as success. In addition, dropbear was modified to always login as the same user, regardless of the incoming user/pass pairs. We will call this user 'victim', which is passed as an argument to the daemon. Before forking victim's shell, it creates the environment variables ABENE_SSH_USER, ABENE_SSH_PASS and ABENE_SSH_RADDR which hold, respectively, the incoming user, password and the ip:port tuple from which the incoming connection came.

    Here we tell dropbear to listen on port 22XX, where XX is the last octet of the ip address for the victim. Dropbear uses the specified dss and rsa keys, and always logs in as the local user 'victim' on our attack virtual machine zed; victim has a special shell defined which it launches:

    Above, dbclient is the ssh client implemented by dropbear. It was modified to give output which resembles openssh and putty's password prompt, so that if the environment-passwd user/pass pairs were wrong, it will prompt again, but in the context of victim, and not the source machine. dbclient performs a similar operation we have done in the past with webmitm by writing an iptables rule after bind, but before connect so that the source address in the logs of the destination victim appear to come from the original source. Since dbclient is running as the user 'victim' and not root, it must call the suid-root perl script /usr/bin/sshmitm_iptables on victim's behalf, as shown below. The function remove_iptables deletes the iptables entry when dbclient exits.

    The Victim
    About 11am Saturday morning, I got this all written and in place. ARP MitMs were already going for the SSL attacks and I had added the necessary ssh MitM lines to /etc/rc.local and redirect rules in /etc/sysconfig/iptables so that when the system reboots, we would be sshmitming (yes, verb). The local accounts for the attack are ago, levin, mitnick and phantomd. Logs live in /home/$TEAM/logs for all IO of ssh. I had an event scheduled for 12:30 in Salem today and my girlfriend was pushing me to go "We're going to be late! Hurry up! You can start the attack when you get back!". So I hibernated my laptop and left. During the drive south, I realized that zed has a cronjob to reboot every two hours to fix an instability related to too much arp-noise. I realized that MitM would be live as of noon. I began to speculate... well, either it'll work and hopefully nobody gets a "SOMEONE IS TRYING SOMETHIN NASTY" message; or, something is broken and I'm sshmitming port 22 into oblivion, and have effectively locked everyone out until I get back and fix it; or, the shell-script-glue has a hole in it and when I get back, they will have found a way into my system.

    After ariving home ~7pm, I hastily reheated last nights pizza and jumped on the laptop to figure out what had gone on.

    OMG, I proclaim. We got one! (you can still see the useradd and test of 'foobang').

    So, I logged in from ruby.cat.pdx.edu so that it did not look suspicious, ssh'd to sri@ago, and hoped that sri had sudo access (he did). Below we show our military victory and all of its fanfare!

    After breaking in, we placed ssh our auth keys in root and sri's .ssh/authorized_keys2, and placed sri's id_dsa.pub in root's authorized_keys2 as a back door. This is generally quite effective, since people rarely look in .ssh for changes; authorized_keys didn't even exist before we placed it (which could be good or bad...) That, and tripwire did not appear to be installed. I re-enabled ssh-as-root in /etc/ssh/sshd_config. I also wrote a quick C proggie to seteuid(0);setuid(0);system("/bin/sh");, called it /sbin/lsof and chmod 6755'd it just-in-case. To logout, we used 'kill -9 $$' to keep .bash_history from being written. The tracks aren't perfectly hidden, but hopefully this will not trigger alarm.

    Fri May 18 22:22:59 PDT 2007

    This must be the day of password work 'cause we now have Ago's blog password! We have mirrored the blog here: ago.html

    user: blog
    pass: iv^21Ais

    This MitM stuff is awesome! ... and ssh MitM will be even better :)

    Fri May 18 17:21:24 PDT 2007

    Sadly, Levin did hard-code the router's MAC. It seems that we can no longer do transparent MitM since they are sending their packets directly back to the router, and not through us. Fortunately, the router still sends us packets for levin and we wroute them on its behalf. This allows us to do a direct connection. The only downside is that they will see a log entry of in the logs, for all SSL connections. Hopefully we get a password before they realize what is going on...

    Fri May 18 12:43:26 PDT 2007

    We have phantomd's blog login and password. They were using Basic auth and as such, we were able to decode the password. We have mirrored their blog here: phantomd.html

    user: blog
    pass: F9*h%4k

    We noticed that mitnick, ago and levin are not accepting our arp replys as redily as they once had; this could be the reason that their blogs were down. We were getting packets to them, but their responses were going to the router. To counter this, we have started sending 3 arp-reply bursts, each second to each host we are arp MitMing. This seems to have increased the reliability of our attack substancially and we now get 100% bi-directional without dropping packets.

    Now back to sshmitm code... we're getting close!

    Thu May 18 01:02:00 PDT 2007

    We did an nmap scan on all our neighbor hosts and found some interesting things.1. All the hosts don't seem to have their 'secondary' services running
    2. Mitnick closed their port 80.
    3. Mitnick seems to use lighttpd 1.4.13, which exposed to 2 vulnerabilies, each allowing for a DoS attack. Those two vulnerabilities are:
    a. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1869
    lighttpd 1.4.12 and 1.4.13 allows remote attackers to cause a denial of service (cpu and resource consumption) by disconnecting while lighttpd is parsing CRLF sequences, which triggers an infinite loop and file descriptor consumption.
    b. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1870
    lighttpd before 1.4.14 allows attackers to cause a denial of service (crash) via a request to a file whose mtime is 0, which results in a NULL pointer dereference.

    We will probably try the DoS attack after we successfully MitM attack ssh, so that they won't get suspicious

    Thu May 17 22:33:21 PDT 2007

    The mitnick guys note that phantomd might be open relay, based on their nessus scan. While the test message never showed up in my mailbox, it is interesting to note the relay issue. It probably fails to show in my mailbox due to PSU's smtp black hole.

    After watching the tcpdump logs, I do note phantomd sending SYNs to mail.nsci.us, but no full connection, courtesy PSU ACLs:

    Since we have MitM'd phantomd's mail server, we have forced all port 25 from phantomd to a super-sekret open-relay host on the internet at to allude PSU's ACLs:
    iptables -t nat -A PREROUTING -s -p tcp --dport 25 -j DNAT --to

    Now we'll see if I get that message. Heck, if it comes through, we might just update our professor about blog changes via phantomd!

    Thu May 17 19:58:51 PDT 2007

    It appears that mitnick is quite happy with their new SSL certificate. They updated their blog, noting apossible exploit on Levin's ProFTPd server. Unfortunately, their attack on Levin did not work. The updated mitnick blog is here: mitnick.html. We have written a script to automate reporting new ssl logs. It's basically a diff against the ssl MitM logs. I was surprised to see that they had updated their site while I was testing the diff script!At first I thought it a bug, but it definitely works as intended!

    For some reason, lighttpd keeps bombing. I just wrote a cron script to restart it if it dies, checking every minute. uptime++

    Now, back to writing ssh-MitM :)

    Wed May 16 21:31:44 PDT 2007

    Captured Mitnick's Blog. No password yet since they are using HTTP digest mode. Their blog is here: mitnick.html. In our logs, we show the "Authorization:" header from their connection. Even though digest does not make passwords available, it does not protect against replay. For this reason, we can replay the "Authroization:" header whenever we wish and see their updated blog. While it would be cute to have their password, it is not necessary.

    By using tools like stunnel, we can telnet to mitnick and replay the message below to re-read their blog any time we wish.

    Now that we have mastered SSL MitM, we move onto a harder target: SSH MitM

    Tue May 15 23:57:22 PDT 2007

    Well the last blog entry was wrong; levin did not hard-code the router's mac. I'm not sure why we weren't seeing bi-directional packets, but we are now. Calling "tcpdump arp" looks beautifully messy, and our spoofed mac of 00:05:DD:68:14:07 sure looks convincing since its vendor ID is cisco, and is very close to the real router. Ahh, yes... so the fun begins!

    We have successfully SSL MitM'd all four hosts: levin, mitnick, phantomd, ago. Each certificate was pain-stakenly rewritten to keep the same serial number and nearly the same C/ST/L/O/UO/CN/E fields. Depending on which apeared to be least used (ie: Levin's O=Levin, OU=Strait out of Levin, so O is least used), we placed the string "SHA1 9C:A1:73:E9:9E:E4:33:61:00:98:CA:8A:85:E7:13:AB:1F:3F:51:60" or whatever the approprite SHA1 string was for the original certificate. The hope is that "users" will see the SHA1 string and assume that it is legitimate since it says SHA1 and it matches what the "sysadmin" gave the "user." When users login to their respective blogs, we will get their logins and passwords since they are *all* using basic-auth.

    Since SSL requires a different port for each certificate, we are running webmitm on ports 443XX where XX is the last two digits of the victim's ip. Note that levin's certificate can be seen at, though it does not forward through to levin since the "Host:" is wrong in that URL. We use iptables rules to redirect packets to these ports as appropriate using our mitm scripts.

    Tools such as webmitm perform MitM by accepting an incoming port 443 connection, and proxying to the host found in the "Host:" header field. Since they connect directly to the system, an opponent might notice that the connection was coming in from zed ( and wonder who .60 is since it is not assigned. If this individual who is scouering the logs notices that the connection came from the subnet even though her connections come in from, she may be concerned that someone is snagging the connection and doing an MitM. This is where linux's SNAT comes in extremely handy.

    We added code to webmitm.c to bind() to a local tcp port before calling connect() to the victim host. Since webmitm now knows what the source port is before connecting, it can write an iptables rule to SNAT packets from the originating address. We add the following code to webmitm:

    Thus, if we (zed) initiate a connection, coming from the recently bounded port (lssin.sin_port), then SNAT the connection to the ip:port (csin.sin_addr:csin.sin_port) of the client (presumably a web browser), then the logs of the victim will not appear to be wrong. In fact, since we are SNATing the source IP and port, the only way to recognize that this connection did not come from the same system would be to analyze the TCP sequence numbers and realize that they are different. We delete this rule when the connection is torn down. This creates a bit of buildup/teardown overhead for new connections, but we will call this "negligable". There are probably a few other subtle differences as well, but with IP and port the same, what is a victim to do ...

    During the rewrite of the certificates, I noticed that the CN for mitnick.cs.pdx.edu is "Kevin Mitnick" and so the warning notice is quite comical, knowing the bit of Mitnick background: "You are connected to a site pretending to be Kevin Mitnick, possibly to obtain your confidential information" ...

    Tue May 15 21:37:13 PDT 2007

    Since the discussion below, people have updated their systems; probably after the lecture where ARP MitM was so pounded into them. I'm thinking the test question had something to do with it. In any event, we can only MitM mitnick, ago and phantomd at 1-second intervals. The host levin appears to have hard-coded the router's MAC address as we no longer get bi-directional traffic.

    Tue May 15 18:16:44 PDT 2007

    MitM Reconisance
    In order to do a low-impact MitM attack, we must know which hosts are susceptable and how long before they re-arp. We want to re-arpoison at an interval which keeps the victim's table fresh, but not so often that a network admin might think something is up. We also need to know which hosts have hard-coded the router's mac in their ARP table. We can tell that they have hard-coded their MAC if we send an arp spoof and realize that we see the incoming packet (showing that we poisoned the router's arp table) but no return packet. If we see the incoming packet, but no return packet we know that they have hard-coded the router's arp cache and that they can not be poisoned. This affects the kind of MitM attack we can perform.

    We have arp-spoofed MitM'd each of the hosts below and show the re-arp times of the hosts. It is interesting to note that we were able to get bidirectional communication for all hosts! This means that we are the only ones with a hard-coded mac in our arp table... this also means that MitM will be sneakier since we can make it look like the host connecting to their system is the real ip, and not us with SNAT magic.

    Another counter-measure abene has put in place is to drop packets which have an external source ip which come from a MAC which is not known to be the router's. We did try to ARP-MitM abene from zed and lost remote access to it. Zed had to re-arp the proper mac to the router so that it would start unicasting packets to the right ip. If we were not running virtual machines, this would not have been possible since it would have dropped our box off the "!" net for ~3hours while waiting for the cisco arp cache to timeout. Below we show the packets dropped during our attack on our own system from zed. We believe that an arp DoS of abene is more acceptable than a MitM from another team. A script is in the works by one of our team members to gratuitously update the router with our IP,MAC tuple since it cant be hard coded. If we do this every second, the time we could be down for is one second.

    Chain PREROUTING (policy ACCEPT 97073 packets, 6119K bytes)
    pkts bytes target prot opt in out source destination
    158 6340 DROP all -- * * ! MAC ! 00:05:DD:67:14:07

    For mitnick and levin we see very consistent rearp times. The host ago and phantomd, however, have something strange going on with them. They appear to refresh their arp cache very quickly after we do an arpoison. It is unclear whether this is their host reacting to our arp takeover, or if it is somehow the nature of their operating system; perhaps we will know when we MitM their box and read their blog. We have found that by sending arpoisons as frequently as every second that we can control the entire packet stream. This is a bit agressive, but maybe they wont notice!

    These are the start/stop minute:second elapsed times from tcpdump. We get these by pinging the hosts externally and listening via tcpdump on zed in non-promisc mode and manually noting the first-packet time and last-packet-from-victim time. Even after the last packet from the victim, we see data coming in from the router since its arp timeout is ~3hrs. Before the attack, 'tcpdump -nn host levin' is silent. Immediately after issuing our arp attack script, packets begin flowing in and out of zed, in both directions (we have turned off icmp_redirects so as not to notify the host that something is up).



    ago: 47:39-48:26=47s,


    Thu May 10 17:52:30 PDT 2007

    It does not appear to have been an attack, but the last access was on Saturday May 5th. It is back up and running now. ... and now, back to the MitM...

    Fri May 4 14:27:45 PDT 2007: The week of abene-in-the-middle

    We have two virtual machines with external facing unused ips:

    zed: [00:05:DD:68:14:07]
    victim: [00:05:de:69:f6:33]

    Note the that the Cisco router is 00:05:DD:67:14:07; only one digit off from zed; if the victim is not paying attention, this may be assumed as legitemate. Traditional arp-based MitM attacks simply send gratuitous arp responses to the victim and the router to redirect them. Since it may seem strange for a network analyst to see an arp reply without an arp request (except in HA environments), we also spoof an arp reply before the response in hopes that it looks "normal" to someone who is not paying close attention to the source mac addresses. We got this working last night.

    15:17:50.598546 arp who-has (00:05:de:69:f6:33) tell
    15:17:50.613711 arp reply is-at 00:05:dd:68:14:07
    15:17:50.628566 arp who-has (00:05:dd:67:14:07) tell
    15:17:50.645723 arp reply is-at 00:05:dd:68:14:07

    This week much research was done for MitM strategies. We will test this MitM attack on our victim host with webmitm and a fake certificate next week. Between the bind() and connect() socket calls within webmitm, we will call
    iptables -t nat -A POSTROUTING -j SNAT --to $REAL_SOURCE_IP.
    This will allow the logs on the victim host to appear as if they are really coming from the original source ip. Since we are the return-route, Linux will properly reverse the SNAT and return the packets to webmitm in userspace.

    Planning has begun on how to perform SSH v2 MitM, even though it is claimed to be immune. The basic idea is to force the ssh daemon to authenticate without a password and launch a shell script to ssh to the real server whith the username specified. An iptables rule to rewrite the outgoing address will be used so that it appears that the incoming connection actually came from the source address it is coming from. The host levin is the only other team who is forcing public-key only authentication, so the other four teams are likely candidates for this MitM attack. Ago sends a banner message of "***** ago ssh *******" which should be fine since we are doing passthrough. Even though levin forces private-key auth, we may try to trick them into entering their password anyway; presumably they have one and if they are not paying attention and if it asks,perhaps we will get logins to their system as well.

    We have asked our network administrator to hard-code the MAC address of abene as 00:08:74:92:74:FB, though he has not been able to do this yet. As a precautionary measure, we have added the following iptables rule to drop all packets from outside of with a source mac which is not 00:05:DD:67:14:07.

    iptables -t nat -I PREROUTING -s ! -d -m mac --mac-source ! 00:05:DD:67:14:07 -j DROP

    Thus, if some other team manages to tell the router that they are us, and they then forward packets to us from them, we will drop them since their mac is different; that is unless that manage to spoof the mac of 00:05:DD:67:14:07, which is unlikely. This is a fail-closed firewall rule. If we are MitM'd, then abene will disapear as it will drop packets. We have decided that this is better than potentially being MitM'd. In addition, we have hard-coded the router's mac in our ARP cache as 00:05:DD:67:14:07.

    Sun Apr 29 23:22:04 PDT 2007

    We show capncrunch.cs.pdx.edu as being down! Not certain if it is due to someone else's flood, but they don't respond to pings or show any ports open. They do, however, respond to arp requests so the host is up ... but hiding. Below are the details.

    [root@zed ~]# cat scan.capncrunch

    Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2007-04-29 23:16 PDT
    Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port
    All 1680 scanned ports on capncrunch.cs.pdx.edu ( are open|filtered
    MAC Address: 00:08:74:92:74:FE (Dell Computer)
    Too many fingerprints match this host to give specific OS details

    Nmap finished: 1 IP address (1 host up) scanned in 51.216 seconds

    [root@zed ~]# arping capncrunch
    ARPING from eth0
    Unicast reply from [00:08:74:92:74:FE] 1.401ms
    Unicast reply from [00:08:74:92:74:FE] 0.856ms
    Sent 2 probes (1 broadcast(s))
    Received 2 response(s)

    Fri Apr 27 19:43:32 PDT 2007

    We have changed the system's certificate to be self signed. All users have been notified of the change and have been instructed to install the certificate. If you have not yet installed the certificate, download and install the certificate from here: https://abene.cs.pdx.edu/abene.cs.pdx.edu-ca.crt. The certificate holds a SHA1 fingerprint of 3a:bf:42:dd:bb:95:f1:a3:5c:50:97:59:b8:84:27:30:16:7a:b8:98

    Fri Apr 27 14:47:45 PDT 2007

    After much work, we have built abene.cs.pdx.edu with an extensive architecture which offers isolation and separation of privelege for each service offered on the system. All firewall rules are default-deny.


    Each service is run within its own VM (virtual machine) and manged by the priveleged vitual machine domain0. The virtualization system we have chosen for this project is Xen. The VMs present have detailed operation information below, each with its own section. For quick reference, the VMs under abene.cs.pdx.edu are:

  • mail.abene.cs.pdx.edu
  • nfs.abene.cs.pdx.edu
  • www.abene.cs.pdx.edu
  • zed.abene.cs.pdx.edu
  • victim.abene.cs.pdx.edu

    Network Architecture

    Abene has two network interfaces; one is physical, and one is virtual:
  • eth0:
  • dummy0:

    In addition, Abene has two multi-interface bridges which serve the internal/external world. The hosts within these bridges are as follows:
  • xenbr0: [domain0, zed, victim]
  • xenbr1: [domain0, mail, nfs, www]

    Each VM which exports a service has an address within the network and is bound only to the internal network on xenbr1. Domain0 performs network address translation (NAT) for each host behind it (all of xenbr1), thus routing between [xenbr0,xenbr1]. Domain0 forwards only the necessary ports to VM for operation of the services offered. Thus, each VM is isolated at the network level in addition to the metaphysical VM level by exposing only valid services to the network.

    Network Services

    serviceportsresident VM
  • http
  • tcp/80www.abene.cs.pdx.edu
  • https
  • tcp/443www.abene.cs.pdx.edu
  • whoami
  • tcp/565www.abene.cs.pdx.edu
  • ftp
  • tcp/20,tcp/21mail.abene.cs.pdx.edu
  • ssh
  • tcp/22mail.abene.cs.pdx.edu
  • smtp
  • tcp/25mail.abene.cs.pdx.edu
  • nfs
  • tcp/udp: 2049,111 and dynmic RPC portsnfs.abene.cs.pdx.edu
  • discard
  • udp/9domain0 (abene.cs.pdx.edu)

    abene.cs.pdx.edu [00:08:74:92:74:FB/]

    SSH access to this system is only available via port 2222. In addition, password authentication is disabled and the only access is by using public-key authentication. Our team's DSA public keys have been added to /root/.ssh/authorized_keys2. This host stores /etc/capturetheflag. This system has a host-firewall which defaults to deny.

    NTP Service
    We run NTP to keep all the virtual machines clock-synchronized. This is important for FTP authentication described below. This port is not explicitly opened via the firewall, though the RELATED firewall allows time-update packets from the outside world if we have requested them. While an attack surface does exist were one to know the source address for the NTP server we are using, we do not expect this attack to succeed. The daemon ntpd runs as the user ntp to limit any possible attack.

    Discard Service - 1st extra service
    The discard service is implemented on this system with the iptables rule:
    iptables -A INPUT -p tcp --dport 9 -j DROP

    We do not expect any opponent to realize that this is not a real service in terms of being bind()ed to a socket() and discarding packets; but if they can proove that this is fake, they get points! Since we reject packets with icmp-host-prohibited for ports which are closed, this port appears to be open and actively discarding packets as it does not report icmp-host-prohibited

    mail.abene.cs.pdx.edu [00:16:3e:3a:f6:25/]

    This VM has a host-firewall which defaults to deny.

    Mail Service
    Mail is running using postfix and allows delivery to local user accounts: jrb@abene.cs.pdx.edu. We have changed the 220 banner so that it does not appear to be running Postfix.

    FTP Service
    FTP is running using pure-ftpd and allows local user home directory read/write access. Because FTP access is plain-text, we have implemented a sort of two-factor/challenge-handshake authentication: something you know, and an algorithm you know. Our server is time-synchronized via NTP and uses the last two digits of the time of day to prepend to the password (the current time is also conveniently placed in the 220 banner). For example, if it is currently 9:37pm, the password above would become "37yourpasswordhere". It is zero-padded, so if it 11:09pm, the password would be "09yourpasswordhere".

    We understand that this is only a decoy and a style of security-through-obscurity, but it may be enough to detect attack attempts and force a password change before any damage could be done.

    We are using both ip_conntrack_ftp and ip_nat_ftp to support NATed+port-forwarded FTP in both standard and PASV mode.

    SSH Service
    This virtual machine has port 22 forwarded into it for our local users (jrb) to use. In the case that this system was compromised due to a local root exploit were someone to find a local account password, they would be unable to breach the security of domain0, where /etc/capturetheflag is stored.

    nfs.abene.cs.pdx.edu [00:16:3E:3A:F6:26/]

    This host allows only host-key authenticated ssh access and is not directly accessible from the outside world. To access NFS, one must ssh to abene.cs.pdx.edu:2222 and then ssh to nfs. This VM has a host-firewall which defaults to deny.

    Network File System (NFS)
    NFS is a strange animal. It requires ports 111 and 2049 in addition to the RPC services [status, nlockmgr, rquotad, mountd]. Since the latter services use dynamic ports, we need to perform shell-script magic to extract the ports in use from 'rpcinfo -p localhost'. The script then opens these ports on the local virtual-machine firewall.

    Since we are doing port-forwarding to internal machines from Domain0, we must also perform port forwarding of these ports into the NFS server. By using ssh host keys from Domain0 to nfs.abene.cs.pdx.edu, we are able to extract the ports from that host in the same fassion as above and forward these ports into it. This is done each time nfs.abene.cs.pdx.edu boots. The source address of is required at the NAT level to allow access. /etc/exports holds:


    This host allows only host-key authenticated ssh access and is not directly accessible from the outside world. This VM has a host-firewall which defaults to deny.

    http / https
    HTTP and HTTPS are implemented using lighttpd, which is a lighweight http(s) server. It supports everything we need it for and uses much less resources than Apache. We chose to use the HTTP RFC2617 Digest authentication instead of Basic authentication. Digest authentication uses nonces and does not transfer passwords in plain text. In example: Our digest login uses this as the HTTP Authorization header:
    Authorization: Digest username="jrb", realm="abene.cs.pdx.edu", nonce="a99644187cdfd0df90333e2b1924ed4b", uri="/", response="9b48bb356423dde2a7b35ecec4e3c875", qop=auth, nc=00000025, cnonce="465ce598666433cd"

    Basic auth uses:
    Authorization: Basic YmxvZ3VzcjpOZXZSZ2V6aXQ=
    Which is the base64 representation of the user/password pair. This decodes to blogusr:NevRgezit which was at one time the user/password for http://phantomd.cs.pdx.edu/phantomd/. It is no longer and they appear to have changed it. They have also used blog:Acad3mi0 as a password, though this is no longer active either

    whoami - 2nd extra service
    The whoami service simply reports the IP of the connecting system. From abene, this is shown as follows. Because of the border router acls, this service is only available from
    [root@abene pktlogs]# nc www 565


    This is our MitM attack host. More about this later...


    This is our MitM test-victim host. More about this later...

    Tue Apr 24 14:05:37 PDT 2007

    SSL is up. Welcome to the secured blog page!

    Mon Apr 23 22:30:55 PDT 2007

    The basic services are up. Hurray for us!