Astroturfing AV: When the wolves guard the hen house

Like any typical morning, I woke up, picked up my iPhone, fired up a twitter app and prepared to be educated about current happenings in the world. I was initially bored when I stumbled across a blog post on the Kapersky Lab Security sponsored site "threatpost" entitled “Some Researchers Lack Basic Ethics”. I assumed that I would read another generic article about AV researchers selling warez to the Russian Mafia or something truly nefarious along those same lines. Instead I was treated to a thinly disguised PR talking point by a Kaspersky researcher, Roel Schouwenberg. The central theme to Schouwenberg's post was the vilification of ethicless researchers who demonstrate how easily an attacker can evade signature based AV systems.

The evil ethics-lacking incident drawing the ire of Schouwenberg is a University of Michigan project, Polypack. The Polypack Project is a website that demonstrates how Crimeware-as-a-Service, a generic term describing anyone who creates malware for a system, works with specific detected malware sample that the user uploads to the site. To quote Schouwenberg:

“The idea behind the site is that people can upload (detected) malware files and make them undetected by as many anti-virus products as possible.”

Being able to tell how easy a malware sample can be made undetected by various AV products...could you think of anything worse for an AV sales person?

I visualize how this conversation went down: A Kaspersky sales guy didn’t make his anti-virus product sales numbers and blamed it on the Polypack Project. Without further questioning, the PR people immediately dispatched a researcher to debunk the accuracy and validity of this project. You can tell this isn’t an earnest effort by Schouwenberg to educate a reader, at no point does Schouwenberg ever provide a link to the project so that the reader can review and make the decision for themselves Schouwenberg and the PR people are banking on the laziness of their reader.

The Polypack Project can be found here with the research paper here. Contrary to the claims of PR people at an AV sales company, I think this project is a good piece of engineering and evaluation of a failing technology. Through this project, a user can determine which AV system fails to detect a higher number of malware (aka viruses). In turn, a large company can spend less money, time, and resources deploying a highpriced signature based AV system if they know it has the most holes. Hrm, why is Kapersky afraid of this sort of open testing? The crowning jewel of Schouwenberg's post is when he cites numbers for how many samples are received and analyzed in a day. He makes the numbers sound almost overwhelming and intends to convey the message that “we can’t protect you from the bad guys if we have to spend time handling shortcomings in our engine pointed out by projects like this”. Schouwenberg fails to point out that technology like the Polypack Project is useless to criminals as criminals have their own tools for these types of testing.

Unfortunately for Kapersky (and other AV sales companies), projects such as the Polypack Project highlight the fallacy that signature based AV products can protect anything other than sales numbers. Could you imagine a slightly different scenario: "Cigarette company employee states that research into tobacco/cancer link is unthical?"

@30k feet

I'm logged on to the Internet (for $10) on Delta using "gogo internet", a WiFi service on the plane. So, I pulled out my WiFi tools to see what was going on.

Here is my speedtest. It claims I should be getting 1.7-mbps down with 128-ms latency, but subjectively it feels slower. As I'm browsing, it can suddenly stop and take many seconds for a website to appear. I bet that it's because the wireless connection to the ground isn't continuous, but keeps coming and going.


The network is 802.11abg (2.4-GHz and 5-GHz). Unfortunately, my tools only run on 'bg' adapters, but NetStumbler uses the 'a' adapter built into the laptop to show all the possible access points, as shown in the picture below:


There appear to be three access points at three locations in the plane (on three channels 1 6 and 11). I can tell they are at three spots because their signal strengths are different. I'm guessing they are in the front, middle, and back of the plane. These are Cisco access points that create multiple virtual access points for each physical access-point. Of these virtual access-points, one is open with a visible SSID of "gogointernet", the others are WEP and WPA encrypted and invisible. I have no idea why they are there. Notice also that we see the obligatory laptop with the peer-to-peer network "Free Internet WiFi" somewhere on the plane.


When I look at channel 1, I see a Blackberries and iPhones connected. I see these throughout the airport (along with Nintendo DSs and PSPs). I think these devices are automatically connecting to whichever access-point they can without their owner's knowledge. I walked down the plane and didn't see anybody with their phone out, so I'm guessing their phone is in their pocket/bag (and not turned off like they were asked).


If we look at the raw beacon packet, we can see that these devices are typical Cisco access points:


From a security point of view, there is nothing too interesting here. Like the inflight entertainment systems, the gogo WiFi service isn't interconnected with anything else in the plane, so there is no danger to the plane from this system being hacked. Ultimately, it's the same threat as any other WiFi hotspot (i.e. your cookies/passwords can be stolen if you don't encrypt everything).

The Ex Factor: Preview

About what percentage of the thousands of Identity Theft victims each year actually know their attacker? If you listen to the media and the InfoSec Gurus, you might think that virtually all the Identity Theft incidents are committed by cloaked assailants somewhere beyond the Great Divide, phishing and targeting the masses.

There are two reasons this couldn't be further from the truth: First, the incidents that qualify as "actionable Identity Theft" are restricted to tangible monetary losses, and therefore most attacks go unreported and ignored. This has lead us to a woefully narrow definition of what counts for Identity Theft.

Second, the current popular mindset about Identity Theft does not acknowledge the startling success rate of attackers who know their victims. Between 50-80% of Identity Theft victims know their assailant. While a stranger can only have monetary goals, an attacker who is inside the "trusted network" may have multiple motivations. The proximity a friend, family member, or colleague has to their target enhances their likelihood of success dramatically. While we find comfort in the thought that members of our trusted network will not try to attack us, people sometimes do fall out of favor. Whether it's an ex-employee or an ex-girlfriend, the important issue to realize is that trust is dictated by actions.

At Security Bsides in Las Vegas, July 29th, Elizabeth Wharton and I will give you the tools and tricks to recognize those "skeletons in the closet" that may still be part of your trusted network, and show you how to make them just a memory.

Heres how we do that voodoo that we do (iPhone Hacking)

The Internet was buzzing a few weeks ago with Charlie Miller’s iPhone SMS exploit. Reading the vague details available in different news stories it reminded me of some work I had done many months ago that involved a USRP, OpenBTS, and several different phones. The results were pretty spectacular for the same reason Wifi fuzzing found tons of problems: when a developer assumes that there is strict control over both ends of a transaction they don’t do as much error checking as they should. After all, since it's only your code (or other code from friendly people) sending data, then the code receiving data doesn't have to check input.

LORCON helped disprove that idea with Wifi. The USRP+OpenBTS combo is doing the same for GSM based handsets.

The crinkly bits is that to find bugs with OpenBTS, you have to trick a cellphone into connecting your hostile base-station rather than a commercial cellphone tower. This is why I found Charlie Miller's and Collin Mulliner's research interesting: they claim they discovered a way to inject SMS locally for testing that wouldn’t be seen by your provider, making fuzz testing easier. I have seen local SMS injection exploits before but never for the iPhone, so I thought i’d spend a day poking around and see what I could come up with. The rest of the blog post is an accounting of how I spent the time searching for this vuln, how I duplicated a vuln that fits their description, and what to do next.

The first thing I needed was an iPhone. I have one I use everyday, but I'm afraid of bricking it. Instead I dug up an old first-gen iPhone. I assumed that executing the fuzzing code mentioned in the abstract would require jailbreaking the phone since it seems impossible to accomplish that task within the iPhone SDK. I was delightfully surprised to find that using redsn0w made jailbreaking the 3.0 firmware a snap. I installed some basic apps I thought I would need, including the iPhone toolchain (you can compile code directly on the iPhone), ruby, OpenSSH, and the mobile terminal. After looking through the Cydia repository I saw there were some apps that allowed for the sending and receiving of SMS messages. These seemed to be a great place to start. The first example I found is called "aSMS", which has a Google Code project: http://code.google.com/p/iphone-sms/

The aSMS app is a bit odd, the front-end is in the browser, and the backend is a built-in webserver on the iPhone. I spent a few minutes going through the source and found it used what appears to be a baseband debug trick to send messages. The word "baseband" is one way of referring to the separate CPU and operating-system that runs the cellular radio. "Baseband hacking" is were do things like unlocking a mobile phone so it can run on any carrier, and enable features a carrier doesn't want you to use (like tethering or MMS). More specifically the trick uses the device /dev/tty.debug. Googling for "tty.debug" and iPhone led me to another Google Code site and a tool called sendmodem: http://code.google.com/p/iphone-elite/downloads/list

Sendmodem came with a makefile, a .c source file, and a compiled binary. As a side note: this is the best possible situation for a person like myself. If I can’t find the answers I want in the source I can reverse the binary to look at additional items that get added at build time. If that doesn’t yield the answers I am looking for, I can compile my own version and debug it. Something I found funny was the note of the sendmodem wiki that states this code come from the aSMS app I started out with. The wiki also sent me here (http://www.developershome.com/sms/howToSendSMSFromPC.asp) which provided information on how to send a SMS using AT commands and a cellular modem. And finally the wiki provided me a list of undocumented AT commands (http://code.google.com/p/iphone-elite/wiki/UndocumentedATcommands)

With all this information, I started poking around my iPhone. The first thing I wanted to do is see if all the information I had been reading about was still around in the newest v3.0 OS my test phone is running. Nothing would be worse than spending hours on an assumption only to find that the feature you need was removed a few revisions ago. The first thing I tried was using the tty.debug trick to send a text message. I wrote a small ruby script for that:



It worked. I then tried to send a test message to my own number. I figured this could be the simplest way to achieve the functionality for fuzzing. However, this didn't work so well. Every time I sent a text message to the same number it originated from the baseband would disconnect and no longer receive text messages until the device get a reboot.

After a little over two hours into this exercise, I had a lot of information but a lot more epic fail. I'm the king of Thomas Edison's quote of "I have not failed, I've just found 10,000 ways that won't work". Feeling the path I was on was fruitless, I tried another direction: I looked through the filesystem for anything called "sms". Although I got a lot of hits, but the most interesting thing is "sms.db" in "/private/var/mobile/Library/SMS". Using the "file" command I discovered the database is a SQLite3 database. Since that is a fairly well documented database, and there are tons of tools to view the contents, I copied it off the phone and to my MacBook. The used "SQLite Manager", a Firefox plugin which can be found here: https://addons.mozilla.org/en-US/firefox/addon/5817


The sms.db overview and structure as seen in SQLite Manager.


The result of the SQL query "SELECT * FROM message"

After examining the different tables and data it seems that this is where SMS messages are stored to be later retrieved for viewing and such. Using this as a ending point I can work my way backwards to where the messages come from.

Next I enabled syslog debugging, so I can information while sending a SMS message to the device, this should help identify processes that are involved in receiving and processing messages.

The last message in the log reads "CommCenter[30]: removing received message 2147483653".

CommCenter is involved in receiving and processing SMS messages to some degree. Searching the disk for CommCenter gives a lot of results but one catches my eye: /private/var/CommCenter/spool. The word "spool" looks similar to the Unix "mailspool", and is likely the place to store files that are being sent or received by the device. The spool directory has two subdirectories MobileOrginated and MobileTerminated. Both directories were empty, but if the Unix style spool architecture is being used, temp files will be created as messages are sent and received and removed when no longer needed. I wrote a quick and dirty Ruby script that will monitor the directory and copy any files it finds, even if they live for only a second.


Simple Ruby script to check and see if Directory is empty, if not copy the contents to /tmp/

I then run the script and send a SMS to the target phone. I get the expected output that a file has been created and moved to /tmp. The file is named r.sms.2147483652


The contents of the /private/var/CommCenter/spool/MobileTerminated direcotry.

Examining the contents its pretty easy to see that this is the incoming message I sent from another from. I ha the phone number that the message was sent from, the message, and some unprintable characters. I then copied this file off the iphone to my macbook and used hexdump to view the message to see what the unprintable characters are.


The text message in hexdump.

Doing the same for the MobileOriginated directory got a file called p.sms.58. The structure seems almost the same with the destination phone number and the message surrounded by a few unprintable characters. The message I sent was "What up Homey!"


The p.sms.58 message in hexdump.

I now know an intermediary point in the SMS delivery process. I attempted to create my own file in the MobileTerminated directory to see if it would be delivered as an SMS message, but no luck. Something is copying the files there then notifying CommCenter there are messages to be processed. The next step was to analyze the CommCenter binary and find any clues on how it operates and where the signal to process messages comes from.

I created a tar file of the iPhone filesystem with the command "tar czvf /tmp/fs.tgz /" and let it run. Although this is not the most efficient way to do this (a copy of the tar file is going to end up in the tar file) is it pretty fast. I then used WinSCP to copy the file down to a VMWare Fusion image of Windows XP running on my Macbook. My Windows image has most of my reverse engineering tools, including IDA Pro and HexWorksop. It also has the Windows version of Ruby installed because Ruby is pretty useful for reverse engineering binaries. The fs.tgz file is unzipped with WinRAR and the search for CommCenter begins. CommCenter is located in /System/Library/PrivateFrameworks/CoreTelephony.framework/Support

I loaded the file, selected the CPU (ARM), and configured my analyze options. Although IDA Pro is the best tool for this type of work it sometimes doesn't get everything, so I had to go through the disassembled code and fix a few things. The problems were pretty forward and easily fixed. An example problem was this:


This will become more readable like this:


After a few minutes of analysis it seems clear that the baseband module receives the message, and then CommCenter reads it using an AT command. At this point we can break testing into two different parts: CommCenter and MobileSMS.

CommCenter Testing: Fuzz From SMS.db to MobileSMS UI

MobileSMS is the application that handles reading the files from the database and displaying them. Testing MobileSMS is as simple as writing malformed messages to sms.db and then running the SMS application. Well, it would be simple if it wasn't for the database triggers. Trying just to insert a message ends with an error. The is answer is to delete the triggers then recreate them. Here is how to do it in SQL. This statment can be entered into the SQLite Manager:

drop trigger insert_unread_message;
drop trigger mark_message_unread;
drop trigger mark_message_read;
drop trigger delete_message;
CREATE TRIGGER insert_unread_message AFTER INSERT ON message WHEN NOT new.flags = 2 BEGIN UPDATE msg_group SET unread_count = (SELECT unread_count FROM msg_group WHERE ROWID = new.group_id) + 1 WHERE ROWID = new.group_id; END;
CREATE TRIGGER mark_message_unread AFTER UPDATE ON message WHEN old.flags = 2 AND NOT new.flags = 2 BEGIN UPDATE msg_group SET unread_count = (SELECT unread_count FROM msg_group WHERE ROWID = new.group_id) + 1 WHERE ROWID = new.group_id; END;
CREATE TRIGGER mark_message_read AFTER UPDATE ON message WHEN NOT old.flags = 2 AND new.flags = 2 BEGIN UPDATE msg_group SET unread_count = (SELECT unread_count FROM msg_group WHERE ROWID = new.group_id) - 1 WHERE ROWID = new.group_id; END;
CREATE TRIGGER delete_message AFTER DELETE ON message WHEN NOT old.flags = 2 BEGIN UPDATE msg_group SET unread_count = (SELECT unread_count FROM msg_group WHERE ROWID = old.group_id) - 1 WHERE ROWID = old.group_id; END;

Once that is done a simple insert statement should work:
INSERT INTO "main"."message" ("ROWID","address","date","text","flags","replace","svc_center","group_id","association_id","height","UIFlags","version","subject","country","headers","recipients","read") VALUES ('4','111111111111111111111111111111111111111111111111111111111111111','999999999999999','aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa','38','0',NULL,'3','0','0','9882987','0','hjdfbvljhvbzjldhvbjlvbjdbvjhdbvjhdvhjdg','aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa','aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa','aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa','0')

You can figure out the columns and what value they are expecting from looking at the table description. To understand what they mean I found a URL in the SendSMS code that explains SMS fields and formatting: http://www.dreamfabric.com/sms/. This information is useful if you want to make a fuzzer more accurate and directed. One problem is that the information does not exactly match up with he database format so it requires some experimentation to find out what each field means. The results follow:

Field Name	Input expected	Description
ROWID	INT	The datbase row, used as a key
address	Text	The phone number in the From field
date	INT	The time the message was recieved in Unix time
text	Text	The message body
flags	INT	Show if a message was sent or received. 2 is for sent and 3 is for received
replace	INT	Shows is a message is replacing a current message, like is a newer version is received.
svc_center	Text
group_id	INT	Used by the SMS UI to group messages. If this is set to a id that is not also in the msg_group table, the message will not be displayed.
association_id	INT
height	INT
UIFlags	INT	If sent to 1 the UI will act as if a URL is present.
version	INT
subject	Text
country	Text	Country Code. The United States is set to us
headers	Blob
recipients	Blob
read	INT	Shows if message has been read or not. 0 means it is unread, 1 means it has been read

This information was collected by a trial an error process of sending and receiving messages then duplicating them with different options. If that didn't work I took the SMS message apart and traced it through CommCenter to its insertion in the database. If the field is still blank I can't find anywhere it is actually used and may be used for MMS which I do not have enabled because I am on ATT. Below are some pics of my trial and error process.


The SQLite view of the test messages.


What the testing actually looks like on the iPhone. You might notice the red exclmation points next to the final two messages. This means the SMS was unable to send and it may happen after mucking arounf witht he database enough. Luckily you can just delete the database, kill -HUP the Springboard process, then restart the MobileSMS application. This will recreate a virgin database for you. The failed messages look like this in syslog:

Jul 23 18:24:49 daveTestIphone2g MobileSMS[85]: no URLs for message: Incoming test
Jul 23 18:25:07 daveTestIphone2g com.apple.SpringBoard[26]: told to send sms 18
Jul 23 18:25:07 daveTestIphone2g CommCenter[30]: queuing sms message with id 18
Jul 23 18:25:16 daveTestIphone2g com.apple.SpringBoard[26]: internalID: [18]
Jul 23 18:25:16 daveTestIphone2g com.apple.SpringBoard[26]: notifying clients of event: 3 (recordID: 18)
Jul 23 18:25:16 daveTestIphone2g SpringBoard[26]: send error: < 0x2483d0="">
Jul 23 18:25:16 daveTestIphone2g MobileSMS[85]: send error: < 0x191ad0="">
Jul 23 18:25:16 daveTestIphone2g MobileSMS[85]: _SMSMessageSendError

As far as a fuzzer actually goes using Ruby and the SQLite gem means that a fuzzer could be whipped up in a few minutes. Knowing the field input types and the rules around what gets processed vs what doesn't helps speed this process along. A simple script will just open the database, insert several rows, close the database the kill -HUP the SpringBoard process. The HUP seems to help the UI close then reopen the database and process your new messages.

Things to try involve long strings, unusually high numbers, and setting values that aren't normally set. Below is an example of a crash received after processing a database full of fuzzed messages. The offsets have been removed so we are not accused of releasing 0-day, how ever if you follow the above steps it is pretty easy to duplicate.



CommCenter: Fuzz From Baseband to SMS.db

Back to testing the code that recieves the message and puts it in SMS.db. Looking back at the sendsms tool it seems the best way is through the use of "/dev/tty.debug". Since the sendsms command to my own address doesn't work lets look at other ways to do it. http://rednaxela.net/pdu.php helps you by allowing you to put put in a SMS PDU and it will tell you what it means or you can create your own. A sample SMS PDU is needed. Using minicom on the iphone I connect to the baseband and issue a few commands that give me a binary SMS PDU.

I need my SMSC number and since it is not stored in the SMS.db file typing a debug code on the keypad will show you. I type *#5005*7672# Here is what it looks like:


Next I went back to the Rednaxela site and build a test mesage:


Taking a tour of CommCenter in IDA I trace some code from the function that begins processing spooled messages in MobileTerminated, the the trigger for it.

The function that process SMS messages:


And the command that beings the processing is +CMT:


Starting Minicom I sent the message and play around with various AT commands.


It seems that sending a message with AT+CMGS=length of message produces the desired result. Creation of a test message is easy and it reads "Testing Local Testing". After hitting CTRL-Z after pasting in the PDU I got this on the phone:


Referring back to the website earlier that describes a SMS PDU and all the different options allows for quick fuzzer creation. You can write a small Ruby script to take your fuzzzer output and write it to /dev/tty.debug and monitor the results. This path finds as many bug as the other and they should be tracked down and verified.

In Closing

This paper shows the extent that researchers can follow breadcrumbs to reproduce a work. That's the risk of partial disclosure: a simple description, such as "SMS crash on an iPhone" can give researchers enough hints to reproduce the work.

I haven't figured how how to successfully exploit the crashes I've found. The SMS network only allow 160 characters through their networks. It might take a multistage process (send many SMS messages with shellcode, then a final message that overflows a buffer to run it). Or, it might be something simple to overwrite a few bytes to unlock a phone.

The Economist on the Kindle

You can now get a subscription to the Economist on the Kindle (or Kindle readers on devices like the iPhone).

Economics is the red pill. It explains how the world really works. Whereas a normal newspaper will report an event as inexplicable, The Economist might explain how it's the expected result of an economics concept, like decreasing marginal returns, incentives, opportunity cost, etc.

For example, last year a hurricane took out oil refinery production in the south. The result was long gas lines, with people waiting hours to get gasoline. Typical news stories talked about how the government should act to reduce prices, shorten lines, and crack down on "gougers". Economics explains that the gas lines are the direct consequence of the government's anti-gouging law, and that if the government allowed "gouging", prices would rise a little bit and the lines would disappear.

If you know basic economics, The Economist is a great explanation of the news. If you don't, then it's a great use of the news to explain basic economics. Or, a combination of both: I studied economics in college, but it wasn't until I started ready The Economist that I really started to grok the subject.

If you want to learn economics, I recommend Principles of Economics by Greg Mankiw.

PS: The Economist has a left-wing bias like much of the rest of the media, but at least it's a saner left-wing bias. For example, it believes in global warming, but correctly points out that the "cap-and-trade" mechanism used in Europe (and soon to be used in the United States if the Senate bill passes) is expensive and corrupt, compared to a more efficient and transparent carbon tax.

PPS: The Kindle isn't the future of publishing, but it certainly fits my lifestyle of heavy reading and traveling.

PPPS: This CNN story on the upcoming federal minimum wage increase is another good example. Economists believe that increasing minimum wage increases unemployment. The Economist magazine mentions this when reporting on minimum wage, other news sources (like CNN) don't.

Asynchronocity and Internet Scale

Schools teach you the wrong way to write network code. They teach you the "synchronous" method. You send a request, wait for a response, then process the response. This doesn't scale to large programs that must interacts with thousands of peers at gigabit speeds. These types of programs require "asynchronous" coding.


The problem is that while you are waiting for a response, you can't do anything else useful. You can't simultaneously interact with a second system, for example. Normally, this isn't a problem because computers respond so quickly that you don't notice the wait. You can also hide it by using multiple threads, but if you had 10 threads, then 10 slow systems will noticeably slow your code.

Asynchronous coding solves this problem by never waiting. It sits in a loop processing events, either incoming packets, or timeout events.

Let's use a TCP connection as an example. As everyone knows, the client sends a SYN packet to the server, the server responds with a SYN-ACK, then the client sends an ACK. This SYN-SYNACK-ACK is known as the "three-way-handshake".

In synchronous code, you send a SYN, then stop and wait for a SYN-ACK. When you get a response packet, you first test it to make sure it conforms to the SYN-ACK you were expecting, otherwise you handle some sort of error.

In asynchronous code, the receive thread sits in an "event dispatch loop". It processes incoming packets. If an incoming SYN-ACK is received, it looks it up in a connection table to see if anybody has sent a SYN packet. If so, it dispatches the SYN-ACK as appropriate.

Imagine you are writing a port scanner, like nmap. One way you could write this is to launch many threads, where each one sends out a SYN packet, then stops and waits for the SYN-ACK. This could could generate thousands of packets per second.

Or, you could write your mapping program with two threads: one that does nothing but sends out SYN packets, and a second thread that receives SYN-ACKs in response. This code could generate a million packets per second.

Recently, a hacker released a TCP DoS tool called NKiller2. The tool uses asynchronous network code. It can appear confusing to people accustomed to synchronous programming. A synchronous coder might expect it to launch many threads, where each thread sends out a SYN and waits for responses for that one connection. This would be too slow - it would probably DoS itself creating too man threads before it was able to DoS the victim.

Instead, NKiller2 is written asynchronously. It runs two threads, one thread that spews out SYN packets, and another thread that responds to incoming packets. This may not be obvious, because both steps are part of the same thread of execution. The code has an event dispatch loop that looks like the following:

while () {
. . .…
send_syn_probe(Target, Sniffer);
. . .
state = check_replies(Target, Sniffer, &reply);
switch (state)
{
case S_SYNACK:
send_probe(reply, Target, S_SYNACK);
}
}

If you are used to synchronous programming, you might assume that the "send_syn_probe()" and "check_replies()" function are related, that it first sends a SYN then checks for a reply to that SYN. That's NOT what's going on.

Instead it's really running two threads, one that sits in a loop sending SYNs, and another that sits in a loop processing replies. The code just combines both into the same loop. You could put the "send_syn_probe()" function at the bottom of the loop, AFTER the "check_replies()", and the code would behave the same.

Or, you could create two versions of this program. Create one that sends SYNs, but has the "check_replies()" commented out. Create a second program with "send_syn_probe()" commented out, but which only receives replies. Now run them both at the same time, and you'll get identical results as the original program.

This code also uses the technique of being completely "stateless". One way to write this code would be for it to create a small connection record. However, since it is creating millions of connections, it would need a large table in memory to track what each connection is doing. Instead, it's much simpler. It will reply to a SYN-ACK packet regardless if it sent a matching SYN packet.

That would be one (of many) easy ways to see if somebody is running this tool against you. Whenever you suspect somebody is DoSing you, send them a SYN-ACK packet out of the blue. If it's a normal, stateful system that tracks SYNs it sent, then the suspected attacker will respond with some sort of error. If it is stateless, Internet scale attacker, they will respond with a data packet.


Internet scale programming like this is all around us. When the Internet worms were ravaging the Internet, a common technique was to set up "tarpits". A tarpit would accept an incoming TCP connection, but never respond. The worm on the other end would stop and wait for a response. Since the tarpit would never respond, the worm would wait forever, stopping its spread. Some worms would launch a hundred threads, each thread would eventually find a tarpit and be halted. (Note: I first tried this with the Morris Worm, it effectively slowed it down, but it would eventually timeout connections and move on - the first worm was written better than most following worms).

Another example of this is Internet-wide scanning. Kaminksy used this approach for scanning for DNS servers: have one thread spew out DNS packets, and a second thread receive them. I used the same technique for scanning for SNMP vulnerabilities. I wrote it for the military to scan Class A networks (with 16-million addresses), but it would scale to the entire Internet. My SNMP scanner was also stateless: it would accept any SNMP response regardless if it actually sent the system a request. This was actually pretty interesting seeing how many SNMP responses didn't match correctly with a request I sent (such as multi-homed hosts).

It works the other way around, too. IronPort used this approach to receiving large amounts of e-mail. They called the operating system they built around this idea "AsyncOS". (They also use this for sending spam).

Asynchronicity is why BlackICE/Proventia IPS is faster than application gateways. Fundamentally, they do the same thing: process application layer data and block it. However, BlackICE does this asynchronously, with a single thread. Application-layer gateways tend to be written synchronously, with a limited amount of threads waiting for data.

Conclusion

They teach you synchronous coding in school because it's easy to understand. However, in order to write software to "Internet scale", you have to learn how to write asynchronous code. This applies to worms, DoS tools, port scanners, firewalls, IPS, e-mail gateways, and so on.

Why people don't get security

Security is only as strong as your weakest link.

Everyone has heard this. It seems obvious. Yet, people repeatedly fail at understanding it.

Recently, a startup called "StrongWebMail" offered a $10k competition to hack their CEO's webmail account. They give you the CEO's password. Their hook is that they also authenticate by calling you back on the phone, so knowing their password isn't enough. Hackers broke in and claim the reward using a typical cross-site-scripting attack.

When conceding, StrongWebMail said this:

It is important to note that the front end protection offered by StrongWebmail.com was not compromised. In fact, Lance [James] and his team were forced to find a way around the phone authentication. We are working with our email provider to solve this vulnerability and ensure that the backend email software is more secure.

This misses the point. The flaw used to crack the system wasn't something rare or unusual, it was instead the most common flaw in web applications. It is a type of flaw that was first exploited over a decade ago in webmail applications.

At the same time, all webmail providers can fix flaws like this within hours, not wait weeks for some other organization to fix the flaw.

This is like advertising you have elite commandos protecting the front door of your bank, yet leaving your back door open. Sure, no other bank has commandos, yet no other banks leave their back door open, either.

Nobody cares about the strength of your strongest feature. What people care about is the strength of your weakest feature. By this measure, StrongWebMail is less secure than any other e-mail system and you would be a fool to rely upon it. It doesn't matter how strong their strongest link is when they have so many weak links.

UPDATE:

By the way, the simple fact they had this contest in the first place means they cannot be trusted. It's a magic trick most frequently used by snake-oil salesmen.

UPDATE:

I misspelled the name in the first post. It should be "StrongWebMail" not "StrongMail", which refers to a completely different company.

Why deep packet inspection is faster

Snort recently added a more complex NetBIOS, SMB, DCE-RPC protocol parser into its code. In other words, it added "deep packet inspection" (DPI) for these protocols.

This means Snort is now slower, right? If you've got an internal network full of these sorts of packets, shouldn't you be worried that your Snort boxes might be overloaded with this new deep-packet-inspection code?

Nope. Snort is now faster.

The reason is that deep packet inspection is actually FASTER than blindly searching traffic for patterns. The more you understand about the structure of a packet, the LESS work you have to do analyzing it for intrusions.

This was the curious thing we found with BlackICE/Proventia (the IDS/IPS that does more deep packet inspection than any competing product). As everyone knows, adding signatures to an IDS makes it slower. We found the reverse: as we added signatures, the product got faster. The reason was because as we added signatures, we also added more deep-packet-inspection logic. This then meant we needed to do less work later on, and the faster the product became.

This is why Snort still struggles at 1-gbps, whereas Proventia scales to 6-gbps: Proventia does more DPI.

Not all DPI will speed up code, of course. When DPI can be done in a single pass, then it will speed things up. Some DPI, though, requires you to backtrack, which further requires you to buffer old data so that you can backtrack to it. This is the case when looking for intrusions within Word documents. Also, decompression streams can be slow: a 1-gbps gzipped stream can easily expand out to 10-gbps worth of data. If you put Proventia in front of your servers sending out compressed HTTP traffic, you might want to turn off the decompression feature for that reason.

Also, a lot depends upon how you write your DPI logic. The Snort NetBIOS/DCE code isn't horrendously bad, but it's slower than it needs to be. For example, it uses the "ntohs()" function to swap bytes, which is a bad way of coding. Most DPI code, like that you find in e-mail servers, is a lot worse. That's why DPI is considered "slow", it's because most programmers don't write DPI code well.

UPDATE

Consider this rule I downloaded from EmergencyThreats.net.


alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (\
msg:"ET P2P ABC Torrent User-Agent (ABC/ABC-3.1.0)"; \
flow:to_server,established; \
content:"User-Agent\: ABC/ABC"; nocase; \
sid:2003475;)


This is blind to the HTTP protocol. It is slow, because it must search everything that goes across those ports. It's prone to false positives, because the pattern may exist for reasons unrelated to the original attack.

However, with hypothetical DPI extensions to Snort, you might write it like the following. Since it reduces the range of the pattern down to just that header field, it would be faster, and less prone to false-positives.


alert http $HOME_NET any -> $EXTERNAL_NET any (\
msg:"ET P2P ABC Torrent User-Agent (ABC/ABC-3.1.0)"; \
header.useragent:"ABC/ABC"; \
sid:2003475;)


No killer robots soon

I'm reading this Slate article about whether you should be worried about robots eventually taking over. The author of that article has a "Harvard Ph.D. in security studies" and "helped write the new president's defense policy agenda". The article was disappointing.

The point he misses is that today's robots are not autonomous. The "Umanned Aerial Vehicles" (UAVs) dropping bombs in Afghanistan still have pilots, it's just that the pilots are located at a military base safely in a bunker rather in the vehicle itself. They don't make decisions to drop bombs, those decisions are likewise made by people, then remote signals sent to the UAV to drop them.

What we have today is not "robotics" so much as "telerobotics". They aren't mechanical soldiers so much as remote tools used by human soldiers -- soldiers who are not in harms way.

I'm an investor in a company that makes remote controlled guns that can, among other things, be controlled through the Internet. They sell them to the military. One of the main features is how and when these devices will actually fire a weapon.

The next level of telerobotics is "programmed response". My companies telerobitic guns have the feature where they can remember scans of the environment, and if something appears in the environment that doesn't belong there, the guns will swivel around, aim at the object, and shoot it. Yet, this still a sort of telerobotics: while the device itself chose to shoot, it did so on precisely programmed responses. It's still humans in control, with the robotics doing precisely what they are told to do.

I've walked past one of these units and had the gun slowly swivel as it followed me across the room. It's a bit unnerving. You do get a Terminator-like, sinister feeling about the device, yet, there is no intelligence lurking back there. It's just following lines of code.

When the robots rise up and enslave us, they won't be the military robots, but our personal robots like washing machines, toasters, and cars. The military is a bunch of control freaks. They don't like the idea of anything, not even their own soldiers, making decisions on their own.

Finally, I'd like to point out that this problem is "AI-complete". The robotic revolution requires artificial intelligence (AI), and if we ever perfect AI, we'll have a lot more to worry about than the errant robot.

Sidejacking poem

"Hackers Can Sidejack Cookies", according to a poem recently published in the New Yorker.

For those who don't know, "sidejacking" is a new variant of cookie hijacking I came up with two years ago at BlackHat. Also, my recent post on the new Star Trek movie comes up on top when you Google "star trek sucked". The moral of the story is that if you produce enough original content, odd bits will eventually start filtering through the mass (un)conscious.

Scan 3rd party websites for safeness

Since I'm a right-wing wacko who enjoys Druge Report, I noticed this this article that claims the U.S. Attorney's Office in Massachusetts told employees not to log onto the Drudge Report because it contained viruses.

Drudge itself isn't hosting malware intentionally, but malware may get through. One possible reason is that they are using a advertising aggregator that isn't too picky about which adds it serves. Another possible reason is it has an exploitable bug, hackers have broken in, and are now attacking visitors.

A good example of this is the related news aggregator BreitBart.com which right this moment has an obvious SQL injection vulnerability. Pick any article with an "id" field in the URL, add a quote, and you get an SQL error message back. If you edit the following URL as shown to add a quote ' character in the id field, you will get the following SQL error message:
URL:http://www.breitbart.com/article.php?id=D986V0E80
Edit:http://www.breitbart.com/article.php?id=D986'V0E80
Message:

Query failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'V0E80' ORDER BY issue_date DESC LIMIT 1' at line 3

This means that BreitBart has probably been taken over by hackers, who are either now delivering malware, or are waiting for the next QuickTime/Flash/PDF 0day in order to deliver that.

I feel safe browsing these websites because I browse inside a virtual machine, which has non-root privileges, using NoScript and AdBlock within Firefox. I may be a little extreme, but at MINIMUM, user should browse the Internet without root privileges.

Large organizations might consider scanning websites that are popular among their users to look for obvious vulnerabilities like SQL-injection. Like it or not, popular websites like CNN are part of your infrastructure, and when they get hacked, your users can get hacked.

How to measure download speed

There are lots of "speed tests" websites that will measure your download speed, such as the ones provided DSLreports and SpeakEasy.

Or, you can BitTorrent a Linux distro. The advantage is that instead of incoming data from a single site, you get hundreds of streams of incoming data from all over the Internet. The only limitation will be the download link.

I just got a new cable modem line. It's supposed to be 15megs down, but DSLreports said it was only 8mbps down. That could be a limitation with DSLreports, though, so I downloaded CentOS (popular version of Linux) to be sure, and I'm indeed limited to 8mbps down.

The graph of traffic shows that the traffic quickly ramps up and pegs at the maximum. I accidentally had the maximum set to 900-Kbytes/second, I had to up the limit, at which point the traffic averages at 1000-Kbytes/second, or 8-mbps.

Star Trek Sucked

Everyone else is going to love the new Star Trek movie, but not me. It's got great visuals, great casting, great acting, great editing, and just about everything you'd want in a Hollyword blockbuster movie. It's got all the appropriate "in" jokes that left the Trekkies in the audience giggling throughout the movie. For me, though, it's not what I want from a Star Trek movie.

First of all, I hate time travel. It's a form of "deus ex machina". If you allow time travel in your universe, then the universe has no rules because people can go back and change what happened. Everything becomes a loose end. If the bad guys blow up a planet, just go back in time and kill their grandfather. It means no story truly exists, because someone can come back from the future and change the story. It's the second worst plot device in sci-fi (the worst is where at the end you realize it was all a dream). Time travel is the last refuge of incompetent writers; if they can't figure out how to fit a prequel into the Star Trek universe, they simple go back in time and change the universe.

Second, the movie isn't sci-fi enough. What makes sci-fi different than other genres is that the "setting" is as interesting as "plot" and "character". Blade Runner would have been a good movie, but what made it a great movie was the distopic, cyberpunk vision of the future. In the new Star Trek, the setting is more of an update to the latest fashion rather than the latest technology. It sure is pretty, but it's not interesting.

Lastly, and most importantly, is that the movie is the opposite of Rodenberry's original vision. Rodenberry showed us future not just where technology had improved, but where people had improved as well. Spock's logic wasn't something to look down upon, it was something to look up to. Things like the "Prime Directive" showed the importance of ethics. In this new Star Trek, the opposite is true. Kirk acts like a small minded jerk, demonstrates no moral fiber or great character, and yet is mysteriously promoted above those who do show character. I suppose this is what Hollywood has to do in order to sell movies. Everyone wants more money. However, if you are producing a movie, you don't make one that glorifies hard work, risk taking, education, or saving. Instead, you show movies where rich people steal money and act like greedy bastards, so the audience can feel better about themselves for their lack of industry, risk taking, education, or savings.

It was Rodenberry's belief in mankind that made the original Star Trek series a commercial flop, but cult favorite. I guess you can have one, or the other, but not both.

How to stop the swine flu

Don't do this:


UPDATE: ...or maybe do it. Exposing ourselves to non-dangerous strains may be the best way to build immunity to the dangerous strains.

Cyberspies, #2

As I blogged, that WSJ story on cybespies was crap. However, that story had "legs". When a story gets attention, other news organizations jump on it and create their own version of the story. You can see similar stories, like these from the BBC, Reuters, and CNN.

Every journalist knew the story was crap. It was ethically questionable (relied upon anonymous sources that couldn't be challenged). The original journalist who wrote the story knew it was crap. Her editor knew it was crap (indeed, probably asked the journalist who wrote it to sex it up). Other journalists who wrote their own version of the story knew it was crap.

So, each journalist had to make their own ethical decision. It's obvious that the public wants to read about the story, so do you feed the public's appetite, or do you stand up for ethics and quality news? Most organizations made the wrong decisions. CNN's version of the story is probably the most reasonable: they tracked down the original anonymous guys making the claim, and then did their research debunking the claims. CNN also used the correct word "hackers" whereas everyone else used the misleading word "spies". (hackers hint independent people, spies implies people who work directly for their governments).

However, it is The Economist that made the best choice in their version of the story, where they point out what all the other journalists knew:
But the most likely explanation for the sudden spate of scare stories is rather more mundane: a turf war between American government agencies over who should oversee the nation's cyber-security.

I highly recommend The Economist weekly news magazine. It is the most intelligent source of mainstream news available. Other sources like the New York Times or Newsweek or cable news channels target a dumber audience and consequently have dumber news, The Economist targets a more educated audience.

As a side note, I'm disappointed that the news organizations didn't contact any pentesters who had broken into power grids (such as myself).

Tales of hacker tools Vol 1: View Source

5am and I can't sleep. I am obsessed with "Alternate Reality Games" or ARGs. I started with Majestic from EA and I was hooked from there. With the upcoming Terminator: Salvation, it seems WB thought that an ARG would be a good way to promote the upcoming movie.

There are two sites (that I have found so far): Skynet Research and Resist or be Terminated. Both are funny videos to watch and accept user created submissions. On the Resist site you can sign up and play a simulator that lets you collect resources, build military units, and attack other players. Since I love all three of those things, it seemed like a win-win. The problem is, for a detail-oriented person, the documentations on gameplay is...well there is none.

I decided to use the very dangerous but time honored hacking technique of "View Source". This technique is not for rookies and I am sure it must violate some international law, but I am a maverick and I really want to win this game. Here is what I found:

Medieval game? An empire? Galava? MUD?!?! What does this have to do with John Connor and his plucky band of resistance fighters and their battle with Oba^H^H^HSkynet? Using another hidden hacker tool, Google, will lead you to a new site. Although the names have been changed, the basic layout of this game is the same as the Terminator game. Even better, they have documentation and forums. What works in the Galava game also works in the Terminator game. Armed with this information my performance has spiked in the last 2 hours.

The moral of this story is beware of hacker tools like "View Source" and "Google". They could give unauthenticated, 3rd party attackers insight into your application design, and can cause unexpected results.

RSA 2009

I was trying to figure out the mood at the RSA security conference. Due to the recession, attendance is down 30%.

First of all, it appears that the recession affects cybersecurity less than other parts of IT. I would personally describe cybersecurity as a luxury, but compliance (HIPAA, SOX, PCI, etc.) make it a non-luxury. Companies cannot cut back on security and stay within compliance.

Second of all, it seems there has been a shift from products to consulting/services. Companies are encouraged to shed full-time employees (which commit the companies to things like health insurance and severance packages), so they fill the gaps by hiring part time employees (aka. consultants). Likewise, companies may find that if they can’t hire more people to manage more firewalls, they will stop buying firewalls, so hiring freezes can indirectly freeze product spending.

Thirdly, it appears that federal government sales are up. It appears that government departments are flush with cash. Any company that does a substantial amount of business with the government is going to post good earnings this quarter.

Fourth, it seems that when analysts go up to a booth, they are looking for work ("can I advise your on your marketing strategy") rather than information ("tell me about your product"). I've heard about a lot of layoffs in the analyst community. This is part of the larger trend that companies are trying to figure out how to do more with the products they already have, rather than buy new products. I know from experience that companies only use 20% of the functionality of their security products. I'd suggest to analysts looking for work that they write reports on how companies can use that 80% of other functionality of the products they already own.

Why "cyber commands" fail

Defense Secretary Gates has announced that he wants offensive cyber warfare capability.

It's not going to work. Hacking is "asymmetric" warfare. The military is trying to shoehorn it into traditional "symmetric" warfare.

Hacking doesn't work the way it's portrayed in the movies. In the movie Swordfish, the villain puts the hero in front of a computer open to a website, puts a gun to the hero's head, and tells the hero to hack into the website in 60 seconds "or else". That's not the way hacking works, the best hackers in the world could not do that.

However, you could tell a good hacker to break into any website in 60 seconds. In hacking, it's difficult accomplishing a specific, narrowly defined goal. The broader the range of goals, the more likely the hacker will succeed at one of them.

What the military wants is a hacker squad that they can give a specific objective, and have the hackers carry out that objective within a specific timeframe. For example, they might tell hackers to take out Iran's radar at midnight so that fighter jets can enter their airspace a few minutes later to bomb their nuclear plants. That's not going to work.

What you could do is tell hackers to go after Iran and do whatever they can to disrupt their nuclear developments. One hacker might find a way to shut down safety controls and cause a nuclear meltdown, another might jam the centrifuges, another might change the firmware on measuring equipment to incorrect measure the concentration of U238.

Or, you could give the hackers six months to infiltrate Iran's computers, then come back with a list of options. Maybe disabling the radar system will be one of them, maybe not. But that's not the sort of thing the military is tasked to do - that's more an intelligence operation the CIA would be doing.

I use this scenario as an example because something similar happened in the first Iraq war in 1990, where our "hackers" were able to disable their radar by hacking into their phone network. This happened because of circumstance and luck, not because it was a carefully laid out plan to disable their radar that way.

China and Russia understand this. They don't directly employ hackers or tell the hackers to accomplish certain goals. They let the hackers have free range to do whatever they want. If the hackers come across something interesting, such as plans for the Joint Strike Fighter, the government buys it, but no government official ever told the hackers specifically to steal those plans.

The reason China and Russia can do this is because that's already the way totalitarian regimes work. A good example is the Russian "Nashi" organization. This is a militant, nationalistic youth group encouraged by the government. Among the things these thugs do is beat up journalists critical of the central government. They also show up at anti-government demonstrations to rough up the demonstrators. In this way, the government gets what it wants (suppressing dissent) without having to do the dirty work itself.

I mention the Nashi because it appears that youths affiliated with that group were also responsible for some of the cyber attacks against Estonia in that dispute in 2007. It is probable that no Russian government official directed the attacks - that's the entire point. By encouraging nationalistic groups, things like this happen without the government having to direct anything.

There are problems with this technique. Sometimes the youth groups don't do enough, sometimes they get out of hand. China props up Japan as their primary adversary, and last year, riots demonstrating against Japan got out of hand, and the Chinese government had to back down on their anti-Japan rhetoric. Whatever the costs, though, it allows the government to keep their hands clean.

So how can the United States get in on this sort of asymmetric warfare action?

The first thing is that you have to stoke some sort of nationalism in the way that Russia and China do. I'm not sure this is in our character (especially under the current president), however, so we'd probably have to find some alternative. Instead of pro-USA nationalism we could instead focus on human rights activism. The government could spend a lot of time talking to the press about the sorts of human rights abuses that go on in Russia and China. Get our own USA hackers thinking about human rights as their own causus belli.

The second thing they need to do is create a climate where our own hackers can operate. I would gladly hack into Iranian computers, but I'm not sure how this fits into US law. (I don't mind breaking Iranian law, but I'm a stickler as far as US law is concerned).

This would be similar to the "letters of mark and reprisal" used by governments during the 1700s. In those days, national navies were too small to patrol the entire ocean. Therefore, governments licensed privateers to prey upon a hostile nation's shipping. The privateers kept half the booty, and gave the other half to their respective government. This is essentially what China and Russia have done.

A third thing our military would need to do is train our hackers in the target language. Foreign hackers usually learn English, but American hackers rarely learn foreign languages, especially Russian, Chinese, or Farsi (Iranian). If we want to encourage our hackers to go after those countries in the same way they come after us, we need to encourage them to learn those languages. The military runs an excellent school in Monterey. They should recruit people at conferences like Defcon to take their language aptitude tests (right there at the conference), and for hackers who score well, pay them to attend their 6-month high-intensity language courses.

The fourth thing our military would need to do is fix their horrid purchasing processes. I experienced this when selling BlackICE to the military: it almost cost us more going through the byzantine purchase process than we got in money from the purchase. Let's say that you found a robustly exploitable Windows server vulnerability. It's worth $100,000 to our military. There is no way they could buy it. If you tried selling it to them, it would cost you more than $100,000 to go through their obstacles.

Note that I think the individuals who run our military are very, very smart. I've met several generals and colonels who understand this. The problem is that while individuals are smart, the organization is dumb as a rock. The organization crushes precisely the sort of creative thinking need to have a successful "cyber" offensive capability.

Ode to 50cent

I was recently on a plane for a LONG, LONG time. For me this is roughly equivalent to putting a cat in a box and dangling it over water. I get bored easy and after watching all the television shows I had brought with me I decided to play with IDA and any unsuspecting binaries from my laptop that I randomly selected. While doing this I noticed iTunes kept crashing, predictably and reliably in the same place. I decided to use gdb to see what the hubbub was all about. However I got dissed and iTunes would not allow itself to be debugged.



This would not do. Not knowing anything about the anti-debugging capabilities of iTunes I decided the best way (and the laziest way) for a programmer to try and keep me from debugging is ptrace. I set a breakpoint on ptrace and tried it again. I got a nibble. I typed return, and then let iTunes continue on its way. It worked somewhat: it would continue but I was prompted over and over again to complete the same task and if I deleted the breakpoint iTunes would exit. I decided to modify ptrace to return immediately. I did so with the following command:

set *(int)ptrace = 0xc3


0xc3 translated to ret. After I did this I deleted the breakpoint and let iTunes go about its normal activity, or as 50cent would say, “sit back and let the money pile up.”


B00m, we have a crash.

Now I can examine the information from the crash and work on how exploitable the problem is. The exploitability is a post for another day; I just thought some folks could use a nifty trick if they found themselves in a jam.


(This post was written to 50cents “How to rob.” Also I typed some commands in gdb that produced errors becasue my regular alias file was not loaded.)

SSL acceleration

This Slashdot article discusses building an SSL accelerator for $5k worth of hardware rather than $50k for a "hardware" accelerator like F5, that has similar performance.

Probably not necessary. You can probably do SSL just on the servers themselves without too much of a performance hit. If you need more performance, an SSL accelerator probably wouldn't help that much, you'd probably need a load balancer instead -- like F5.

THIS IS SO AWESOME!!!

This story from Slashdot and Telegraph.co.uk:

During his captivity, U.S. Marines forced Saddam Hussein to watch "South Park: Bigger, Longer And Uncut". That movie portrayed Saddam Hussein as Satan's gay lover. (This character also appeared in several of the South Park TV shows).

I'm not too happy with the invasion of Iraq, and I didn't want Saddam to face the death penalty, but I always wanted him to face exactly what we thought of him. Ever since I saw the movie, I have thought to myself "I hope that if we ever catch the bastard that we force him to watch this". And, apparently, we did. I would pay money to shake the hands of the Marines who did this.

By the way, it should be remembered that the South Park movie was a musical as heartwarming and endearing as "The Sound of Music". One of the songs, "Blame Canada" was nominated for an Oscar.

On the other hand, I forbid my parents from watching the movie, because it is not "age appropriate". Senior citizens are not at the developmental stage where they can handle it (although children are, of course). Sadly, I suspect my dad has been sneaking behind my back watching South Park episodes.

Has the power grid been penetrated by enemies?

This Wall Street Journal article "Electricity Grid in U.S. Penetrated By Spies" is an example of "yellow journalism". It makes eye catching claims whose only source is anonymous government officials, backed up by pseudo-experts that nobody has heard of before.

The source of this story probably has to do with this:

Last week, Senate Democrats introduced a proposal that would require all critical infrastructure companies to meet new cybersecurity standards and grant the president emergency powers over control of the grid systems and other infrastructure.

There's no coordinated conspiracy here, but there are a lot of government officials who stand to gain by this attempt at drastically increasing government control over the Internet. They will certain call up reporters they know and attempt to get them to write scare stories precisely like this.

Another quote from the story is:

Last year, a senior Central Intelligence Agency official, Tom Donohue, told a meeting of utility company representatives in New Orleans that a cyberattack had taken out power equipment in multiple regions outside the U.S. The outage was followed with extortion demands, he said.

I know of a similar story, told to me by the people who investigated the incident. It appeared that hackers had broken into the power control systems (in a country outside the US), caused a small blackout, and had made ransom demands. As it turns out, it was an inside job, not an attack from the outside. Both the outside "hacker" and the inside guy (who flipped the appropriate switch to cause a blackout) were arrested and put in jail. (The timing and details are similar enough that it's my guess the stories refer to the same incident).

Notice how my story has an ending, whereas Tom Donohue's story doesn't. Seriously, how could the CIA not know how the story turned out. The hackers made ransom demands, but then what?

My conclusion is that the CIA and/or Tom Donohue is lying. They are claiming something to be solid research which is only vague innuendo and rumors.

Dallas FBI raid, part 2

Wired Thread Level has a writeup of that recent Dallas FBI raid that seized all the computers at a couple of colos. In particular, they have a copy of the warrant authorizing the raid. It confirms what I said in my previous blog on the subject.

Being technical means I'm more interested in reading the search warrant itself than I am reading the Wired story. Being technical, I wish more news articles were like that Wired article publishing the raw, technical sources of their data rather than digested summary of the content. I hope one day that it will be journalistic ethics that interview notes and other material be posted online next to the stories.

In any case, if you read the warrant, you see it's about this guy Mike Faulkner. It certainly appears this guy is up to no good. The warrant lists a number of places to search, such as his home, business, mail post office box, and so forth. However, is also lists the "Core IP" location that made the news. I've read the affidavit twice and found nothing that implicates "Core IP" other than the fact that one of Faulkner's business was once a customer of Core IP. There is certainly nothing that justifies the grabbing of all the customer equipment at the Core IP location.

As I said in my previous post, the FBI is good at crime, and it appears probable that Faulkner is a criminal. On the other hand, they are bad with computers, and there is nothing that justifies the way they raped Core IP and its customers.

Why SSL sucks, #458738

I accessed "mail.yahoo.com" and got this error message saying the certificate is bad. Normally, this would be cause to panic. While lesser sites might get SSL wrong, the big sites should get it right. Therefore, if you see a certificate error at a big site like Yahoo!, you should assume somebody is trying to man-in-the-middle your connection.

However, on closer inspection, it appears that Yahoo! fouled up. It's the result of "mail.yahoo.com" incorrectly using a certificate for "login.yahoo.com".

The fact that even a large site like Yahoo! cannot get SSL is pretty damning for SSL.

FBI takes down Dallas ISP

The FBI raided a Dallas ISP and took all the servers belonging to roughly 50 people.

This seems excessive. I want to see the search warrant. In America, a search warrant is supposed to be limited to a specific item being searched for. What makes our country free is that the national police can't come in and grab everything like this.

Unfortunately, in my personal experience, the FBI is a bit corrupt. Few FBI agents that deal with "cybercrime" know anything about computers. As a consequence, they can be easily manipulated to do terrible things like this. It is quite plausible that the MPAA manipulated them to do this massive server grab in order to track down who released the recent Wolverine flick to the Internet.

On the other hand, the FBI is very good at crime in general. There could be legitimate reasons for the massive grab. We'll just have to wait until data is published (i.e. the search warrant authorizing this).

GPU cracking for $250

ATI and nVidia have just shipped their spring refresh cards. Both now sell an essentially top-of-the-line card for $250 (either the ATI HD 4590 or the nVidia GTX 275). If you do password cracking for pentests, you might want to pick up a few of these cards.

Both would be an excellent card to buy for password cracking. Either would increase password cracking speed by around 10x. I prefer the nVidia card because the CUDA programming support is easier to work with, but I suspect the ATI card may be slightly faster for crunching numbers.

Note the way I say "top-of-the-line". For graphics, the more expensive GTX 285 is better than the GTX 275. However, both cards have the same number of "stream processors" at roughly the same clock speed. Therefore, both should crack passwords at the same speed. What makes the GTX 275 cheaper is the fact that it less backend graphics resources (fewer raster units, slower memory speed, narrower memory bandwidth, smaller frame buffer). We don't care about these other graphics resources -- all we care about is the number of "stream processors" and how fast they run.