Mayhemic Labs

Pop quiz hot shot...

It's a chaotic Thursday afternoon. A series of bombs have gone off across your city paralyzing local transportation and infrastructure. You and co workers are trying to get information about loved ones and friends but your Internet link seems to keep going down. Local law enforcement has just entered your operations center saying that they're evacuating the building due to a suspicious van that's sitting unattended across the street...

...and you just got word that your website was defaced.

What do you do?

Sadly, it can't be as simple as "Call Keanu Reeves."

Tabletop exercises are incredibly useful from the perspective of Information Security folks: Drilling incident response so that it comes second nature can make the times when a crisis happens so much easier. However, all to often we focus on everything within our little silo: "A firewall just got down", "A server was compromised", "A worm is spreading across the LAN", etc. Bringing in a fresh set of eyes to look at exercises and suggest additional variables to toss into the equation can keep teams on their toes and start to think about problems beyond their area of control.

Recently, I was in a discussion with some peers regarding a recent exercise one of them had where there was a fire drill during the middle of it. While they were lamenting this, I asked "Well, what happens if there was a fire drill during an incident? Or worse, a fire?" seizing upon this dicussion followed and scenarios like the one described above started to form. They all boiled down to one question: What happens when the real world intrudes on your incident handling process?

While most businesses have some kind of Continuity of Operations plan, how many folks know how it applies to them? More importantly, how does it fit within your own procedures? Most IT pros know how to handle a virus outbreak on an internal network, but it's a completely different monster when halfway through the entire staff has to be evacuated due to a natural or man made disaster.

Some questions to consider (and discuss with your staff (and bosses)):

• What if something happens and your operations center is no longer able to be staffed during an incident?
• What's your chain of command? Who's in charge if there is a event similar to a Case Orange scenario with regular staff being incapacitated or unable to communicate?
• How do you contact people when regular lines of communications are down?
• Is security a stakeholder in the DR process?
• If all company sites are inaccessible and information is unable to reach your staff, where is your rallying point?

A lot of security professionals know that electronic networks are fragile and vulnerable, still, how many of us assume that telephones, cellular networks, and power will be up during an attack? Exercises should start preparing staff for a large scale disaster that may impact these services and designing processes to work around them.

For those of you who haven't been following the project, WebLabyrinth has gone through some changes and has had some new reporting and alerting features added to it. Recently, it was featured on a Technical Segment on PaulDotCom Security Weekly Episode 240 which was posted to YouTube your viewing pleasure.

WebLabyrinth is also featured prominently in Paul's "Offensive Countermeasures: Bringing Sexy Back" presentation that he recently gave at SOURCEBoston. If you're interested in learning more about WebLabyrinth and other "Offensive Countermreasures" Paul and John are teaching a class this Summer at Blackhat. If it's anything like his presentation, I highly recommend signing up.

Debian Squeeze was released last month and one of the new features was the faster dependancy based booting. However, if you attempt to upgrade your 5.0/lenny installation and you are running OSSEC, the bitchin free host-based intrusion detection sytem, the upgrade process doesn't go without a hitch: During the upgrade, the process to upgrade the System V init scripts barfs:

error: Unable to migrate to dependency based boot sequencing.
error: Problems detected: 
insserv: warning: script 'K20ossec' missing LSB tags and overrides, 
insserv: warning: script 'ossec' missing LSB tags and overrides

Fantastic. Squeeze and OSSEC have decided to be the two kids that don't get along on the local playground.

After some Googling, the main link that came up was someone asking on the OSSEC list asking "OSSEC Y U NO UPGRADE CLEANLY?" with no reply. Further research showed that the problem is that the stock OSSEC script doesn't have the Linux Standard Base init headers. Thankfully, Debian has a wiki page on how to LSBize your init script, which gives a great overview on how to make LSB compliant init scripts. 

So after taking a look at that along with the stock init script, whipping up a LSB header is fairly simple.

# OSSEC         Controls OSSEC HIDS
# Author:       Daniel B. Cid <dcid@ossec.net>
# Modified for slackware by Jack S. Lai
# Modified for Debian Squeeze by Ben Jackson <bbj@mayhemiclabs.com>
### BEGIN INIT INFO
# Provides:          ossec
# Required-Start:    $local_fs $remote_fs $network $syslog $named
# Required-Stop:     $local_fs $remote_fs $network $syslog $named
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# X-Interactive:     true
# Short-Description: Start/stop OSSEC Host Intrusion Detection System
### END INIT INFO

Simply replacing the exiting header with this This script does err on the side of caution for the dependencies: Does OSSEC need a DNS service to start? Who knows? But it solves the problem, the update script runs cleanly, and the system boots without a hitch.

Now, as the previous post stated, I love me some honeypots. So I got introduced to a fun tool on PaulDotCom Security Weekly Episode 225. During the show's technical segment, John profiled a simple python script called SpiderTrap. John is a big fan of honeypots and what he calls "offensive countermeasures", rather than simply blocking attackers that probe your network, John enjoys messing with them and keeping them busy until they give up and frustrated. SpiderTrap, written by his intern than Robish, reflects that methodology, it is a small web server that serves up a never ending maze of random links. When a web scanner encouters this, it attempts to map out the entire web application, which, theoretically, will never happen with SpiderTrap.

SpiderTrap is cool, however, I instantly thought of some shortcomings: First, it needs a dedicated host to run on, and second, it doesn't help your existing web applications. The gears started turning and it occured to me that the script would be fairly trivial to implement in PHP and that Apache's mod_rewrite could handle spoofing a never ending maze links. Thankfully, I had a few free nights coming up during the next weekend, so I coded something simple up.

What came out of my coding sessions was WebLabyrinth. WebLabyrinth, like SpiderTrap, is designed to create a maze of bogus web pages to confuse web scanners. However, unlike SpiderTrap, it can be run on any Apache server with mod_rewrite and PHP. This allows users to embed it within existing websites. Also, I added a feature which allows the web pages to consist of more then just a few links: It uses a Dissociated Press function to randomly generate text (courtesy of David Pascoe-Deslauriers' BSD licensed code). Included in the code is the first chapter of "Alice's Adventures in Wonderland" (which just seemed so right to use for this purpose), but any text can be used.

So, a few words of warning, while v0.2.0 does try to detect Google's spider and block it, it current detects no other search engines. Also, if an overly agressive scanner gets trapped, it may be a drain on system resources. I will try to address both these issues in future versions.

Now, partially for the above reasons and partially because I don't want to pay for some idiot scanning my server, there is no demo site available. However, Mr. Strand was very nice and created a video for PaulDotComTV showcasing the tool

It's a fairly simple idea and there isn't much to do from here, however, I am mulling some additional ideas for future versions. I am always open to suggestions, so please feel free to contact me.

While catching up on my podcasts, I was listening to PaulDotCom Security Weekly Episode 220. During the news stories they talked about an article in Network World regarding the effectiveness of honeypots in the Enterprise and how they were the best thing since sliced bread. Everyone agreed with the article and sung the praises of honeypots and how they almost always were great indicators of issues on the network and almost always caught malware propagating across their networks.

Honestly, this left me scratching my head. I have been running honeypots in an enterprise environment for over two years and they have been little more then novelties.

Now, don’t get me wrong: I love me some honeypots. When I first found out about honeyd back around 2002 or so I fell in love. I coded up an entire suite of scripts to mimic default installs of various Linux distributions. I used it in my university’s CTF competition to light up the /22 they gave us with over 700 decoy computers. I bought an extra IP for my DSL connection at my home solely for running it. I presented on it at The Last HOPE. It’s an amazing tool. When I got the green light at my work to set it up on the LAN for monitoring I was pumped! When running it at home I received an amazing amount of attacks! Surely the network, which was still thought to resemble the wild west would give us an amazing picture to how bad things are. The office had informal bets to see how long the box would last before it was exploited.

Well, that was over two years ago. We’re still waiting.

Honeypots are a double edged sword detection wise. When positioning them, a lot of folks place them in a DMZ open to the wild of the Internet. While this allows you to see exactly what is being flung at your network, most people don’t realize the amount of shit that gets rained down on your servers. In an average day one can see attacks from upwards of 20-30 hosts. This is wonderful, but correlating these to attacks on your infrastructure can be insanely time consuming. For each attack you need to ask:

• What was the attack?
• Do I have hosts vulnerable to that particular attack?
• Did this malicious host launch that attack against those servers?
• Was that attack successful?

While important questions, these alerts pile up. It’s very easy to end up chasing your tail and quickly become overwhelmed.

The flip side of this is positioning them inside your network. While you (hopefully) won't be overwhelmed with attacks, you'll run start running into the opposite where you'll be wondering if you'll be seeing any events. If you don't have some kind of automating alerting system, you may start not notice if and when an attack happens. Whoops.

Honeypots provide great information for network based attacks. For the scenarios described in the Network World article and above they function admirably. However, I feel comfortable in saying that over 95% of attacks coming into most networks are web based attacks that come in via one path: Users’ web browsers. Trojans like Zeus, Gozi, Sasfis, Koobface, and Conficker thrive in most modern enterprise environments. Recently there was a great post on the RSA weblog by Uri Rivner comparing the amount of data stolen by the Zeus Trojan and Wikileaks (Zeus wins. Handily). What do these crimeware kits have in common? They don’t probe other computers, they don’t scan, they just phone home to their C2 infrastructure. Honeypots are as useful in detecting and preventing these situations as a bowl of Tapioca pudding would be.

Like all security devices, honeypots have their place. Having nodes reporting into existing alerting structure (SIEMs) as tripwires and “patient zeros” are a good idea. However, with some of the price tags on these pieces of software one has to do a cost benefit analysis regarding their existing infrastructure. Would you be better served by a honeypot or hardware for an IDS system, another firewall, a SIEM, a log server, vulnerability scanner, or some other piece of security infrastructure? While they can and will catch certain attacks, however, they are one small piece in what you should be deploying and they should be one of the last pieces of your puzzle rather then your first.

So, I've been kind of pissed that the iphone seeminly had more robust potential as a pentesting platform, compared to Android. In a, shall we say, moment of discomfort, I shitcanned AT&T for Sprint and got a Galaxy S phone. And of course, there's no native port of Metasploit yet.

If you're in my boat, fear not, there is a solution: Chroot'd ubuntu. Just follow the instructions at http://bit.ly/g2jQmz to get yourself a functional Ubuntu environment, then load it up with your tools of choice. Metasploit works quite well!

Pics later, if anyone cares.

savant

The hell?! Ok, so in the sake of full disclosure - this is not running *ON* the Apple IIe. As far as I know, nobody has ported Ruby to Apple IIe. I can't imagine how painfully slow that would be. I used the native Apple Super Serial Card and a DB25 <-> DB9 null modem cable. The other end terminates to a USB to serial adapter hooked up to a net book running a persistent install of backtrack 4. From there, a little /sbin/getty action and I've got shell access over serial. I'm using ProTERM 3.1 as the terminal emulator on the Apple IIe connected to a vt100 terminal type. savant

As some of you may have noticed, ICanStalkU was down for a while, and came back with a new look and a few less features. For those of wondering what happened, lets set the wayback machine to last Wednesday, October 20th:

e-Mail: "This is a notice that your OAuth token for ICanStalkU has been suspended from interacting with the Twitter API."

Ben: "Oh, for %#$& sake..."

We were dead in the water. Our Twitter account was suspended, which while annoying, wasn't a big deal in the grant scheme of things. What killed us was the fact that we could not longer access the search API and therefore couldn't find photos. This left us with three options:

1. Shake our fists at the sky, pack our saddle bags, and ride ICanStalkU into the sunset.
2. Shake our fists at the sky, thumb our nose at the suspension, set up another account for API access, and try to keep ahead of any further suspensions.
3. Shake our fists at the sky, contest the suspension, and remain dead in the water while Twitter does whatever they do.

We decided that we should cast the die with option #3 and see what happens. After a couple days we got a response. Turns out, Twitter caught wind of our little party and decided to set fire to our tree fort. Apparently you can't @-reply people on an automated basis even if you do it only once an hour (despite other accounts that do the same thing) and the ICanStalkU website violated the "API Terms of Service by appearing to modify the content of tweets from their original text to text that the user did not explicitly generate"

We disagreed with their findings, but since Twitter is master of their own domain, complaining would likely get us nowhere. So, we went the other route and attempted to find an amicable solution. What we came up with was two major changes:

1. The account could no longer @-reply people.
2. The website needed to be changed so that it no longer appeared to be a tweet stream (no avatars, no text appearing to come from a user, etc)

So, we went ahead and made the changes, took advantage of the downtime to make some changes on the back end, and threw the switch. We would like to give a shout out to Brian, who, once we had our account reviewed, worked with us quickly to resolve the situation.

So, we're back up, stalking folks, and hopefully suspension free for the foreseeable future.

I was recently was asked to do a presentation regarding Information Security for his alma mater's IEEE. I believe that death by PowerPoint is one of the most painful ways to go out, so I tried to keep it light while staying on the subject manner.

• Malware, Big Hacks, and Stalking: Information Security at a Glance (PPT, 4.8MB)
• Malware, Big Hacks, and Stalking: Information Security at a Glance (PDF, 3.0MB)

Share and Enjoy!

It was entertaining watching people attempt to get past Security @ Blackhat without a badge. Apparently, there are those who have forgotten how to do reconnaissance. When performing reconnaissance of a sensitive target, it is best to survey many times. Foremost, it helps to identify patterns. However, when surveying multiple times, it increases the chance one could be detected. Try to avoid the below issues and you will be on a path towards success.

Do not get caught:

1. Filming places not normally recorded. Think if someone came to your property to film your neighbors. Wouldn’t that seem suspicious?
2. Lounging in sensitive areas with no valid reasons. When was the last time you let a stranger on your network or yard?
3. Holding maps or reconnaissance information with no valid reason. Ask yourself “In the first place, why would someone need this information?”
4. Asking strange and/or appear to have abnormally long interest in security personnel, measures/policies/procedures, entry points, ACLs, and/or perimeter information. Enough said here.
5. Surveying drills, exercises, and actions of security personnel to any threat, possible or not. See point #12.
6. Monitoring scanners, mailing lists, discussions and/or other forms of communication for estimating response times.
7. Causing unexplained fire/IDS/IPS alerts. One does wants their target to be relaxed, not paranoid.
8. Mapping routes, timing networks, physical routes, and monitoring traffic flow in or near sensitive areas.

Do not:

1. Question security or facility personnel in any lengthy manner. While in accordance with point #12, those should attempt to keep distance from those who must remain vigilant.
2. STARE or continually hit the target’s network.
3. Do not avert gaze and/or retracing steps. Seems suspicious.
4. Appear uncommon, different, and/or out of place. Vendors, shoe shiners, panhandlers, and 3rd party unknown tech support people come to mind. It wouldn’t be fair not to provide counter intelligence.

For those responsible for sensitive areas:

1. One should remain vigilant and watch for observation behaviors.
2. Use all techniques available such as field interrogation techniques.
3. Document incidents to local police, terrorism task force, and or state/local fusion centers.