2010-09-22

Experiences from the red team.

My experiences from the red team:
Ax0n posted his experiences at CyberRaid 0 and I totally agree, leadership and coordination make a big difference. I am not an experienced penetration tester so my efforts were mostly for naught. The red team had some very talented people but we didn't coordinate our efforts until it was too late.

Shenanigans :
Before the game, unbeknownst to every one, a red teamer spread around a bunch of authentic looking USB keys with some uber proprietary security software. Complete down to the holographic tamper evident tape. He also placed a power strip which had a baby monitor built into it. The baby monitor was ineffective, it was on the 49Mhz band which is horrible for indoor reception. Because the blue team was separated from the game network this did not work either but any one running the dongle got hit with a Trojan horse / remote control app. The USB keys were confiscated by the FBI (literally).

Wasted time:
The scoring system was down, and DNS was not working so in effect the contest didn't start until after lunch. This was poor planning on the contest promoters. The network connection kept going down so that was even more wasted time. The bulk of the points were scored by a group who concentrated on the default password angle. Alot of people were using Metasploit and once the egress filtering kicked in that halted all progress on that front.

MOAR SHENANIGANS !
Ax0n pretty much confirmed my suspicions, (at least from his team) that most services were firewalled off in addition to egress filtering with the exception of services needed to score. This method of defense really hamstrung red teams efforts in that it prevented the scoring mechanism from working. That combined with shall we say, creative interpretation of the rules made it tough going on every one.

What were you expecting?
On day one and the tail end of day two, law enforcement came in looking for mac-addresses and IP addresses, and came up empty handed every single time. The first time we learned that a team caught some one hitting their web apps with a web app vulnerability scanner. They collected a mac address and an IP and turned it into the cops. The mac address was the Cisco switch (duh, routed network) and the IP address has been tossed long ago. The following attempts of catching the l33t hax0r also ended in utter failure. Mostly because Mac addresses are easily changed, especially on virtual machines. They were getting no where and really should have concentrated on doing their job.

After learning about the total ineffectiveness of the blues attempts of catching people most people just opened up on them, full blown Fasttrack scans ...etc

In the end ...
In the last hour we did what we should have done from the start, we talked. The networks were mostly patched and firewalled all to hell so really we were down to actions of last resort. One item of interest was looking for a machine with poorly configured IP forwarding and bounce crafted packets off of it to the scoring server. I think a large part of our lack of success was stepping on each others toes and poor communication.

What I took away from this event:

  • Teamwork!
  • Communication!
  • Egress filtering hamstrung people using remote exploits.
  • IDS's only work if you can use them.
  • Law enforcement is worthless unless you have done the leg work and provide them with useful information.
  • Be professional, being childish gets you nowhere.
  • Beware of default logins and bad configurations.

2010-09-20

What I personally learned at CyberRAID

One last post from me on the inaugural CyberRAID event here in Kansas City.


Leadership
I'm not sure why I was chosen as team captain. Maybe it was because I knew more people on my team than everyone else, because I seemed more confident or because I was one of the first ones present. I wasn't nervous. I felt like I was as prepared as I was going to be. I had my plan, tools and more than half my life behind me that I've spent doing security work in some capacity or another. I thought I was ready to orchestrate a defense team, too, so I happily accepted the position of Captain at the start of the game when people told me "Go up to Dwight! Get our info!" It's not that I can't orchestrate a defense team, but I wasn't as ready as I had thought I'd be, and my plan fell apart pretty quickly.

My plan was to get people organized by what they're good at, and set them on a task. I kind of succeeded at that, but I did plenty of things wrong from the beginning. First, I was stressed but I haven't completely forgotten my manners. My requests probably sounded like a bossy demand followed by "please." Next, I didn't enforce these roles nor did I evaluate how it was going. Some roles changed without much communication. More than once, someone stepped on the toes of someone else who was already working on something. I'm thankful that there wasn't any apparent infighting on my team. Everyone remained rational.

I've lead teams on many projects in my career, but I have no formal management experience or training. I've been an IT worker in a crisis situation more times than I can count. I've never had to lead a crisis response, though. To manage people and work on technical things at the same time is a truly herculean task -- one that I feel I only barely stumbled through.

I learned a lot about myself and hardships faced by leaders in a crisis situation. I also gained a new perspective on IT workers. Among my team, I had some of the most brilliant and capable security minds I know of in the region. On the first day, we had grand ideas and the right mindset, but our implementation of them was slipshod at best. Our good communication skills were the only thing standing between what we had (which was still a good effort) and unabashed anarchy.

Things I learned about leadership and IT teams (and thus, what I need to work on myself):

#1: Technical leaders must lead first and foremost, and help second.

#2: Groups of geeks require a little bit of guidance to avoid replicating (or undoing) work.

#3: Good communication is vital, and its prerequisite is good rapport.

#4: Change management is an extension of good communication. Yeah, I went there.

On the technical side, there were so many things that I'd do different right from the start.

#5: Get visibility to the DMZ network and I'd immediately scan it from the outside while the firewall and system admins work to start locking down obvious things.

#6: Additional Virtual Machines on the DMZ. It would have been great to have a decent (and familiar) IDS on a Span Port. It might have also been fun to have a few honey pots sitting on the DMZ. Had I thought about this ahead of time, I could have totally made it happen. These are tools any one of us could have brought along for the ride in VMs.

#7: Egress filters from the start. There's no good reason not to. They make sense in the enterprise, and they make sense in the game.

Things I'm taking back to the office:

#7: Egress filters! I'm mentioning it twice. Blind SQL injection and RCE exploits are very popular, so crafty hackers and pen-testers often try to leverage these vulnerabilities to launch some process that can notify them that their exploit has worked. This might be popping an xp_cmdshell to launch ping with a special payload they can look for in return, or it may be something much more quotidian, such as a reverse_tcp or meterpreter call-back from metasploit. Again, egress filters make sense in the real world. To further this point, watch out for obscure tunneling through ICMP and DNS. Ideally the DNS server your DMZ uses should not allow recursion.

#8: We all know that despite our best efforts, a dedicated adversary will find a way in. For some reason, this exercise made it sink in a little better. It's been a while since I've worked somewhere that was breached on my watch. This further boosts my desire to learn more about modern post-breach activities both defensive (forensics, containment) and offensive (post-exploitation, pivoting). I have some serious reading and research to do!

Who else was at CyberRAID, CCDC, SANS ICE II or any other recent exercise like this? What did you get out of it?

2010-09-17

Cyber-RAID 0 - Blue Team Wrap-Up

First and foremost, I owe a huge thank you to all my team-mates. Blue Team 2 (which I was on) took home first place in the Defense category by a margin of 5% or so. Like I said yesterday, we had an all-star team with such an awesome range of talents. There's no way any one or two of us could have done as well on our own. We used everyone's skills, and we learned quite a bit from one another. I also learned a lot from watching the Red Team work.

The VMs on each team's network for this exercise:
10.10.9.11 - Secondary DNS Server - Red Hat Linux 7.3 (Valhalla)

  • DNS had to remain open to the outside world. Marks would occur against your network if the scorebot system could not get your system to resolve the addresses it's supposed to be hosting.
  • SSH: the scorebot user must be able to log in.
10.10.9.14 - Active Directory - Windows Server 2003
  • DNS had to remain open to the outside world. This one was properly configured.
10.10.9.15 - Exchange Server - Windows Server 2003
  • OWA on port 80 had to remain open to the outside world.
10.10.9.56 - PBX Server - Older Debian install
  • HTTP had to remain open to the outside world.
10.10.9.69 - DB Server - Older Debian install
  • SSH: the scorebot user must be able to log in.
  • MySQL had to be open to the outside world, allowing the scorebot user to select from a special table.
10.10.9.70 - Web Server - Older Debian Install
  • HTTP had to remain open to the outside world, and a flag file in the web root had to remain intact (subject to MD5 checksum)
  • FTP had to be open to the outside world, allowing the scorebot user to retrieve a file.
  • SSH: the scorebot user must be able to log in.
10.10.9.89 - DB Server - Older Debian install
  • SSH: the scorebot user must be able to log in.
  • MySQL had to be open to the outside world, allowing the scorebot user to select from a special table.
10.10.9.91 - Web Server - Older Debian Install
  • HTTP had to remain open to the outside world, and a flag file in the web root had to remain intact (subject to MD5 checksum)
  • FTP had to be open to the outside world, allowing the scorebot user to retrieve a file.
  • SSH: the scorebot user must be able to log in.
10.10.9.253 - Solera IDS and packet capture VM
  • This wasn't a target, and didn't have anything the attackers could get their hooks into. It was provided to us, but none of us knew how to use it, nor did any of us have time to play with it. We instead relied on local logs and traditional packet captures from Wireshark and tcpdump.

Gotchas:
All the systems had many extra services running. There were default passwords on database, web-app and shell accounts. Anonymous FTP (with upload ability) was allowed on the two FTP servers.

This was a self-contained and isolated network, making traditional methods of patching impossible. What's more: in order to protect the Blue Team laptops, the VMWare server had dual interfaces. Blue Teams were only given enough infrastructure to connect to the management interface of the virtual environment. That means that Blue Team only got console access to the environment. The hosts themselves were natted to the hostile network through a Cisco ASA.

Day 1, with more detail:
Our first action was to snapshot all of the VMs. This would let us revert them in the case of complete ownage or if one of the red-teamers rm'd our boxes. Next, we figured out who was good at what kinds of things. This would come in handy later on. Next, we all started exploring the VMs through the VMWare consoles. There were eight VMs and eight people. You'd figure we could have each taken one of the VMs and started hardening or patching them. But no, everyone immediately opened 3, 4, or 5 VMs at once and started trampling on other peoples' sessions. I was just as guilty as everyone else.

I think most of us were more prepared for a totally Windows-centric environment. Several of us brought Windows Update patches on DVD. Our team started patching those right away, while two guys with firewall experience worked to restrict only incoming services we needed.

It was already too little, too late. Surbo from i-Hacked completely and totally pwn3d our exchange server early on in the game while my friend Eric was busy trying to figure out what in the hell was going on. At this point, scoring hadn't started yet, so the firewall guys shut down all incoming traffic.

Before lunch, the systems people started hardening and patching the boxes as best as we could without having Internet access. We all had reasonably good communication, and we all had some good ideas. Egress filtering came into mention before lunch. The firewall guys built up a good rule-set that would allow all scored incoming services to work properly once the "deny all" rule was pulled, while disallowing any connections out from the systems that weren't absolutely needed. All of this was to shut down any phone-home scripts.

After lunch, we opened up the firewall ruleset to the world and started watching the score board. A lot of time was spent yesterday troubleshooting the firewall and various services, making sure we had as few marks against us as possible.

BIND on our Red Hat Linux box (using a 2002-era version of that distro!) ended up being brutally misconfigured. It was also a horribly vulnerable version, but no red-teamers seemed to exploit it to properly pop a shell. Yesterday, no blue team could solve the issue.

Toward the end of the day, our Pointy-Haired Boss demanded that he wanted the company's computers to be able to access http, https, smtp, dns, mysql and postgresql outside the network. Firewall changes that we made broke all our incoming services for a while, due to using the wrong IP addresses in the DMZ rules.

We got these changes implemented, and then found that our PHB was using his personal laptop to connect out over those ports to verify that the changes were made. After that, scoring was complete for Day One.

Day 2
One of the game rules was that we couldn't explicitly block anything by IP address either inbound or outbound. First thing in the morning, we created a group for our DMZ servers then placed full egress filtering on them. At some point in the morning, the PHB verified he could still get out to the other networks from his laptop on our DMZ. He had no idea what we had done.

In normal IT shops, this is known as adhering to the letter of the law instead of the spirit of it. It's a type of insubordination that IT guys can use against management when they really think they know what's better for the company. I really don't like resorting to these kinds of tricks in the real world, but since it's a tool that IT guys have in the real world, it's a tool my team was willing to use. Later on in the day, the PHB came back around and asked us to prove to him that our DMZ servers could also get out. This was a much more blatant deception. Our firewall guy dropped the egress rule while one of our Linux guys feigned a bit of ignorance to stall the boss for 15 seconds or so while we pulled the shields down.

These were risky moves. If at any time we would have been found to be out of compliance with the boss's demands, it would have cost us an instant 5,000 marks against us. In the real world, moves like this could potentially cost you your job. Of course, in the real world, you can often talk the boss out of making bad decisions, and the boss would likely have to provide a good business reason to implement the features that were being asked of us.

Things were going more smoothly on day two. We hooked up a switch to the DMZ to give our personal laptops some visibility to the front-end of our network. This helped things immensely, and it's something I'd do immediately on the first day of an event like this in the future. I brought speakers, too, so that my team had some tunes. We rocked out to 808 State, Paul Van Dyk, Daft Punk, Juno Reactor, Steve Porter, Orbital, White Zombie and more. At a reasonable volume, of course.

With the exception of the badly configured BIND server, our team and Team 3 were holding steady on marks against us. We both started to identify some SQL injection and default usernames being exploited on our networks. Team 3 had gained on us a lot at the end of Day One, but we held a margin of about 200 points ahead of their team for the entirety of Day Two.

More demands rolled in. We had 30 minutes to open Exchange's SMTP to the world, and we had to add a new zone with MX, A and NS records to the active directory's DNS server. Our Windows admins aced it.

While that was going on, I was digging into BIND on the redhat box. I was the first blue-teamer to finally dig into the issue and fix it. Only one other team was able to resolve this issue, and it took them a while after I had fixed my team's. I'll spare you the details, but it was really, really misconfigured.

At this point, several attackers had some kind of hooks into a few of our systems, but they were having trouble scoring phone-homes. With all our tasks out of the way, we went into incident response mode, booting and cleaning up after red teamers.

One last PHB demand for the day: Set up VoIP trunks and extensions on our Asterisk server, and allow the protocols needed to talk between networks. We weren't going to actually communicate over it, but we needed to at least show that we could get into the interface and configure Asterisk with FreePBX. Since my machine was plugged into the external switch and since no one on my team (even me) had any Asterisk experience that would make them any better for the job, I went ahead and took the charge on that one. It required collaborating with my team-mates to grok the config files and tweak the databases so I could get logged in.

There was about half-an-hour of incident response left after that. About 10 minutes before scoring closed, the game organizers joked that he'd remove 10,000 marks from any team who could provide him with full packet captures of the entire exercise from Solera by the time scoring closed. I say he was joking, because that VM had only 2GB of hard drive space on it, so there's no way it could have stored it all. Even if it could have stored it, I doubt anyone could have exported all that data in 10 minutes.

All of the tasks required collaboration, and the entire exercise calls for a team of people with diverse skills.

Evil WiFi: Subversive Wireless & Self Defense (BSidesKC)

I'm used to talking among smaller groups of people around a table, but that was the extent of my public speaking experience until my presentation at B-Sides KC. Thanks for all who participated. It was a pleasure interacting with you today!

I think the presentation went pretty well. B-Sides seems like a great place for shy security nerds to practice their presentation and speaking skills. Predictably, I think I said "Um" quite a bit. I'll get better, I'm sure.

When my original Evil WiFi rig left a trail of dead newbs in its wake at DefCon last year, I decided I should probably refine it a little bit. A presentation was in the back of my mind. When I got laid off at the beginning of this year, I started playing with it in earnest again. I even drew up a quick outline that I was thinking of submitting to Black Hat and DefCon. I'm honestly still not 100% happy with the setup. I'd bet I could get most of this running on a single netbook, and use some of the newer features of Metasploit.

I wish we would have been able to record the talks. The audience added a lot of insight. I also had a big pile of notes to go with these slides. I deleted them, entirely on purpose, so I could wing it during the presentation. I know the material.

The ongoing theme of the talk was that wireless technology is helplessly broken for all but a few savvy users. Of course, most of the people who attended my presentation were savvy users themselves: hackers, penetration testers, sysadmins and mostly highly-technical folks that "get it" - I'm hoping they can take this back to their day jobs and use it wisely. Not all hope is lost if you need WiFi in the enterprise, though. You just have to know the threats and use your head.


I also demonstrated the effectiveness of my current Evil WiFi rig with its new captive portal functionality, and explained how the mechanics of the system work. It surprised me that the audience enjoyed watching me fumble my way around, but the demo seemed effective enough considering parts of it were somewhat staged for display purposes (browsing to my captive portal from localhost just to show how it looks and what firewall rules it adds) but once I enabled Karma, we started seeing a few folks get tangled up in in.

I didn't demonstrate Hamster & Ferret for a few reasons. Complete strangers using my access point, 18 U.S.C. § 1030 (and related codes) and the presence of FBI agents in the room had something to do with it.

2010-09-16

Cyber-RAID 0, Day One - Blue Team

Asmodian X is Red-Teaming, but here are some of my thoughts on Cyber-RAID 0 from the Blue Team side.

First: today was one of the most frustrating and stressful days of my entire IT career. That's saying something, considering that I'm officially off the clock, on vacation with a "four-day weekend." I'm burning vacation days to participate, and some good friends of mine with strong ties to the financial, law enforcement and education industries sponsored my attendance at this event. Being stressed out doesn't mean I'm not having fun, though. This is my first time in a game like this, so it's new and exciting to me.

Next, I have an all-star team working with me. We got to self-organize into groups, so I already knew some of the people on my team, and what they're capable of.

Blue Teams

The "Blue Team" is actually 4 teams with 8 members each. The goal of each blue team is to get as few marks against their network as possible. Each "network" is a VMWare server with 8 VMs. Each team gets a nearly identical setup, save for a few passwords being different. Marks are racked up based on the integrity of mandatory services. Your exchange server goes down? That's a certain number of marks against your team. An attacker deletes or modifies a certain file on your web server? More marks against you. These accumulate periodically until you restore the services to their intended state. I won't go into what all services are checked or what kinds of virtual machines we're running, since some of my red-team buddies might take advantage of the information. It's safe to say that there were many services running that didn't need to be.

By gathering enough data to implicate a specific attacker, each Blue Team can recover some of the marks against their network as well as getting the attacker "arrested" - sidelined for 30 minutes.

The Red "Team"
The Red Team is full of lone-gunmen who are free to collaborate if they wish, but they're much less structured than the Blue Teams are. Each Red Team member scores points for themself by getting phone-home scripts or binaries to run from the Blue Team network. Ideally, they exploit remote-code-execution vulnerabilities, pop a box to get a session or shell, or otherwise get the Blue Team's systems to contact the scoring server on their behalf. The goal of the Red Team attackers is to score as many points as possible. If they can persist their hold on a Blue Team network, they can continue to rack up points by running their phone-home processes repeatedly. Note: these scripts can't be run in an infinite loop effectively to rack up tens of thousands of points per minute.

The Pointy-Haired Boss
Toward the end of the day, our Virtual CEO decided to DEMAND that we change our firewall rulesets to open certain ports for outbound access to any remote server. As you can imagine, per the rules of the game, many of the blue teams had opted to implement egress filtering rules that would allow the services to be contacted from the outside, but to disallow any outgoing connections originating from our servers in order to foil any successful "phone home" attempts, even in the event of a complete system compromise. This demand was certain to throw a wrench into egress filtering rules, but the team I'm on dealt with it well enough. Tomorrow, more demands will be thrown at us, and the usual fare of IT issues will be simulated: password resets, account creation, etc.

Results
"We have met the enemy, and he is us!"

At the start of the game, each of the Blue Teams caused more problems for themselves than the attackers did: team-mates accidentally knocking out power to production systems, intentionally telling Red-Teamers to "Piss Off" by modifying an integrity-monitored web page, and failing to fully understand this network that was just dropped into our laps are only three examples of the sort of frustrating things I saw today, and pretty much every team had the same problems.

There's still a half-day ahead of us, but the last time I checked, our Blue Team team was in the lead (by virtue of having nearly a thousand fewer "marks" against us than our closest competitor) but I have a feeling we'll need to work hard to stay in the lead. The members of the Red Team seem to be having a very, very rough go of things as well. The top attacker, last I saw, had a mere dozen points. My guess is that the attackers are landing a few successful exploits, but are having difficulty with the way points are awarded.

We'll see how it turns out at 13:00 tomorrow afternoon. B-Sides runs all day tomorrow as well, but Cyber-RAID participants will miss out on the first half.

Evil Wifi - Captive Portal Edition

As part of my presentation for B-Sides KC later this week, I decided to revive my Evil Wifi project for a demonstration. I'll post my presentation slides and some talking points this weekend. Since my daily-use laptop is a MacBook running Mac OS X Snow Leopard, I put this together for OS X. I do understand that OS X isn't free, but it works, and well. It's also something fun (and perhaps evil) you can do with that new netbook after turning it into a hackintosh, as so many friends of mine have done lately.

If you haven't read my Evil Wifi series from last year, I suggest you start with Part 1.

Originally, my Evil Wifi setup was a stand-alone rig with a laptop and a wireless router. The router has a tempting SSID for freeloaders (such as "Guest") while also running KARMA, a set of wireless driver modifications that will rope in any wireless devices that are broadcasting the names of their preferred networks in hopes of finding one to connect to. The router would hand out my laptop's IP as the DNS and default route.

The laptop was running Hamster and Ferret, a suite of sidejacking tools from Errata Security. These tools allow an attacker to gather and re-use session IDs from other network users. Additionally, it was running Metasploit for two reasons: a fake DNS server that resolves all domain names to itself, and a fake HTTP server with a specially-crafted page designed to facilitate the capture of many popular session cookies, which Hamster and Ferret would see and store.

Captive Portals are those wireless hotspots that require you to pay, enter a password, or acknowledge a terms-of-service agreement before continuing. No one could get out to the Internet through Evil Wifi. I intentionally designed the landing page to look like a captive portal that required a password. Most users would find themselves somewhat puzzled, then move on to a different network. Some people have asked if I could have configured the laptop to allow outbound traffic, and others (Like John Sawyer of Dark Reading) actually figured out how to do it. I thought about it last year, via Internet Connection Sharing, but I'd have lost the ability of Metasploit to gather a bunch of potentially valuable session IDs quickly.

I've been thinking of way to combine the best of both worlds, and I think I've nailed it.

To continue, you'll need a configuration much like the original Evil Wifi, but with a few tweaks. Here's how I did it using Mac OS X. Keep in mind that Linux works fine and also has Internet Connection Sharing, but you'll have to tweak some of the steps, and come up with equivalent iptables rule sets.

Laptop:
Router:
OS X Setup:
I configured en0 (my ethernet port) for a static IP of 192.168.1.2, netmask 255.255.255.0.

My first experiment with OS X's built-in Internet sharing showed that it starts a program called natd and inserts a rule to the ipfw firewall to divert traffic through natd on port 8668. Avid BSD users are probably familiar with all of this. It's exactly how I configured my first FreeBSD home router back in the 90s. Since Internet Sharing also does a bunch of other stuff that I don't want it to do (starting a caching name server, adding a virtual IP address, and some other shenanigans) I do this stuff through the staging script instead of relying on OS X's Internet Sharing wizard. The staging script comes later on.

Also, XAMPP runs as "nobody" but a small bit of web code will need to add firewall rules, so I granted the nobody user to use ipfw without a password, via /etc/sudoers on my laptop:
nobody ALL=(ALL) NOPASSWD: /sbin/ipfw
XAMPP Setup (any AMP stack will work):
Edit httpd.conf, find the line that says "Listen 80" and change it to "Listen 81" - uncomment it if needed. On OS X, this file is in /Applications/XAMPP/etc/

Create a php script that uses the $_SERVER[remote_addr] variable to modify the firewall rule set. This page will be called by a form action or link from the metasploit capture page. Mine is really simple, and I called it "control.php" in the document root. On OS X with XAMPP this is in /Applications/XAMPP/htdocs/
<?
HEADER('Location: http://www.some-local-business.com/');
$cmd="sudo ipfw add 100 skipto 2000 ip from " . $_SERVER[REMOTE_ADDR] . " to any >/dev/null" ;
system($cmd);
?>
It simply redirects you to another site, and adds a rule to the firewall, telling it to skip past any rules before 2000 for your the IP address that visits this page. Since I'll be giving this demonstration at a hotel next week, the header will redirect to the hotel's web site. Since XAMPP gets finicky if it is started from the command line, you'll have to fire up the XAMPP control app and start Apache manually. MySQL and FTP need not be started for this project.



Metasploit setup:
Download and update Metasploit Framework. I prefer to get it from the subversion repository.
The HTML file that's used with the http capture module is located under the metasploit directory, then data/exploits/capture/http/index.html
The default is ugly and almost screams "you got owned!"
The Lab-O-Ratory

This is what I came up with. You can view source and steal it if you want, but you can probably craft something better. Yes, it's ugly. No, I don't care. I've seen worse. Note that the "Accept" button activates the control script that I have set up on XAMPP.

Along with that is also the karma.rc - I can't remember if this one comes stock with Metasploit or not, but it's the one I use.

Staging script:
This sets up our firewall rules the way we want, prepares Hamster for use, and fires up Metasploit. Drop this script somewhere and make sure the paths are correct for Hamster and Metasploit Framework.

#!/bin/sh
sudo sysctl -w net.inet.ip.forwarding=1
sudo /usr/sbin/natd -interface en1 -use_sockets -same_ports -unregistered_only -dynamic -clamp_mss -enable_natportmap -natportmap_interface en0
sudo ipfw -f flush
sudo ipfw add 10 allow ip from 127.0.0.1 to 127.0.0.1
sudo ipfw add 1800 allow ip from 192.168.1.0/24 to 192.168.1.0/24
sudo ipfw add 1900 deny ip from 192.168.1.0/24 to any out via en1
sudo ipfw add 2000 divert 8668 ip from any to any via en1
cd ~/hamster
sudo ./hamster&
cd ~/msf
sudo ./msfconsole -r karma.rc

Fonera Setup:
This one goes together just like it did in Part 1, but a recap:

Start with a rooted and re-flashed Fon2100. I used OpenWrt 7.09 (yes, I know it's old) - Be sure to change the root password!

I then installed all of Digininja's Jasager goodies found on his site, using the tarball method. I needed a few extra packages to make everything work - I bundled them up here. Unpack them, upload them to the fon, and install them with "ipkg install *.ipk" if you need to install them.

Change the dchp server configuration to set 192.168.1.2 as the default route, and add a public DNS server, then 192.168.1.2 as the default DNS servers. I used one of Google's public DNS IP addresses for the public one. On OpenWrt 7.09, these tasks are accomplished by adding lines to /etc/dnsmasq.conf:
dhcp-option=3,192.168.1.2
dhcp-option=6,8.8.8.8,192.168.1.2
If you go back to Part 1, you'll see I also did some other tweaks, like set Karma to start by default. There is a lot of information about getting Jasager up and running, but the dnsmasq configuration is the most important bit, particularly getting the public nameserver in front of the fake one we're going to fire up with Metasploit. You'll see why in just a bit.

I also changed the default SSID from "OpenWrt" to "Guest" to make it more attractive to freeloaders. You may prefer to use "linksys", "default" or any of the popular SSIDs. This is set in /etc/config/wireless.

Putting it together:
Fire up the Fonera Router

Start up XAMPP's apache server.

Run the staging script. It should come to rest at a Metasploit prompt. This is doubly fun, because it's running modules in the background to help Hamster & Ferret, but you can just as easily launch attacks from the Metasploit console if an interesting computer falls into your trap.

Browse to the Jasager interface. This should be at http://192.168.1.1:1471/ - enable KARMA mode if desired. You may wish to keep Jasager open in its own window or tab. There's usually some interesting stuff going on.

Set your browser's proxy to http://localhost:1234 to allow Hamster to inject cookies.

Browse to http://localhost:1234 and tell Ferret to watch en0 for traffic.

Here's what happens:
Victims or freeloaders connect to Jasager, and DNS resolution will hang for a few seconds because the public DNS isn't available. This DNS request will time out (usually in 5-10 seconds) and then it'll try the second DNS server in the list. That's metasploit's fake DNS server.

At this point, any service they've tried to connect to will likely get captured by Metasploit. If it's a web browser (likely) they will get roped into Metasploit's HTTP capture and they'll get our Captive portal page, complete with the iFrames that force the browser to divulge session cookies for popular websites. These iframes will also take a few seconds to resolve, but that's okay. All the while, Ferret is gathering these session ID for us.

Once the victim clicks the "Accept" button on the captive portal, the firewall rule is created that allows outbound access, including DNS. It will instantly redirect them to a website -- preferably one that's plausibly related to a nearby business. They get out, through us. Hamster catches everything. The victim is none the wiser.

Is it possible to give Evil Wifi EVEN MORE teeth?
Of course it is! You could create scripts that automatically attack new wireless clients, wrap the wireless up with SSL Strip to catch some REALLY sensitive session IDs, and any number of other malevolent things. At this point, I think I've proven how broken things are, though.

Defense?
I have plenty of thoughts on defense. There are ways to defend yourself in the wild, ways to defend your enterprise users from attacks like this, and ways that operating system vendors could prevent KARMA-style attacks from working at all. For that, you'll have to see my presentation at Security B-Sides KC. As I said at the beginning of this post, I'll have the slides uploaded and some notes posted later.

2010-09-13

Sony has a problem.


This is that problem.

Sony has ignored, at least aesthetically, and likely functionally, that we have come to expect new features to be seamless. Wii motion control doesn't have a giant ping pong ball on the end of it. An iPhone and other smart phones have motion sensors that don't have ping pong balls hanging off of them. Laptops with motion sensors don't have ping pong balls to detect sudden drops and park the hard drive. Yet, Sony is directly marketing their total lack of understanding of how to seamlessly integrate a modern feature into their system. The only visual notice you have of motion control on Wii is the sensor bar. On XBOX the upcoming Kinect does motion with out a controller but tries to solve that by throwing a large amount of video, audio and sensor processing at the problem. That may well be an overkill approach to simple control compared to just putting motion sensors in existing controllers, however it allows a broad range of extended uses such as biometric recognition. Overall, simple motion control is a problem that was solved by proximity sensors and 3 axis accelerometers, which Nintendo and Sony seem to have successfully implemented. Sony just couldn't seem to get over the "look at us, we are hip and trendy again" goiter on the end of their controller that directly signals that Sony just doesn't get it.