So use DMCA Counter-Claim!

In a recent event, it appears that the secure-boot key for the TI-83+ calculator was brute-forced, and Texas Instruments is trying to put the genie back in the bottle by sending out DMCA take down notices. Those receiving the notices are responding foolishly to them instead of filing proper counter-claims. I don't know why.

SECURE BOOT

Many devices are configured so that they will only boot a "signed" operating system. This means that the iPhone's hardware will only boot software signed by Apple, so you cannot install Linux or Windows Mobile on it.

Secure-boot is designed primarily for things that load copyrighted material, like music, videos, and games. However, it's a standard feature of hardware/software development kits. Thus, even simple things like the TI-83+ calculator support secure boot.

The TI-83+'s key was recently cracked with brute-force. This is an interesting milestone. While we have known for some time that it is theoretically practical to crack a 512-bit key, the practical achievement of that feat changes how we think of cybersecurity. That means hackers can pretend to be TI and sign their own operating system for the TI-83+ device. It has implications for everything else using 512-bit RSA keys.

Apparently, the key was cracked with a single desktop computer (dual-core 1.9-GHz) in around 73 days of compute time using software called GNFS (GGNFS+MSieve). It required a database of 52-million relations or 4.9-gigabytes, it used 2.5-gigabytes of RAM.

DMCA TAKEDOWN

TI doesn't like this. Their lawyers have been sending out DMCA "takedown" notices to everyone publishing the key, as well as anybody linking to the key.

Curiously, receivers of the takedown notice have posted "responses" on their sites that have nothing to do with the DMCA. Brandon Wilson has replied to this notice with this response. Tom Cross responds to this notice with this response.

I don't understand the purposes of these responses. They aren't proper "counter-notices" under the DMCA. They have no effect. The lawyers who receive them don't care. They have no impact on publicity. It's like sending a letter to Santa Claus that you didn't like your Xmas presents. It's like yelling at your car when it breaks -- the car doesn't really care. Such responses have no effect on anything.

The law is like code. Actually, the law IS code. We use computer "code" as an analogy for the original definition of code as used in law. The original DMCA notice is programmed according to a specific code. If you want your response to have an effect, it must likewise be coded according to the law.

Consider this line from the original TI takedown notice:

"I hereby confirm that I have a good faith belief that use of the Illegal Material in the manner complained of in this letter is not authorized by the copyright owner"

That line doesn't exist because the sender wanted it to be there, it exists because the law [512(c)(3)(A)(v)] requires such a statement. It's code.

COUNTER-CLAIM

You have to respond in the same code. Simply assert that the material was taken down in error, and that you consent to the jurisdiction of the local federal courts to decide the matter, and that you'll have to put the content back on your site within 14-days. Here is an example counternotice from ChillingEffects.org. They have a automatic counter-notice form here.

This situation is a bit more complicated than that. The original takedown notices are in error. It's not like TI sending a takedown notice to blogger.com to remove something on this blog. In Tom Cross's case, he is both the operator AND the person posting the content.

Of course, when you do this, you are asking TI to sue you. They probably won't, but it's a chance you'll be taking. They spam out a bunch of these letters without ever really caring if people comply with them or not. But here's the thing: you can't sit at home and whine about how unfair the man is. You have to be willing to stand up for what you believe in.

THE TIME AND PLACE

The place to make your arguments is in the courts. That's the only place where they will listen.

In your discussions with TI, they don't explain to you why they think it's infringing. They simply promise you, under threat of perjury, that they have good reasons to think so. Likewise, you don't state your reasons for believing the opposite. You simply state, under threat of perjury, that you have good reason to disagree.

Then, you both go to court and explain your reasons.

Making your arguments to TI will have no effect. They have selective deafness. If they listened to your arguments, they might believe them, and would no longer be able to, in good faith, send out takedown notices. Therefore, no matter how many e-mail you send them, they won't listen.

It's like debt collectors (which many in this economic climate may have dealings with). Arguing that you don't owe them anything doesn't work, they don't care, they aren't listening. But can simply tell them that you believe (in good faith) you don't owe them any money. They then have to stop calling you (according to the legal code) and address the issue in the courts.

I AM A BASTERD, NOT A REVOLUTIONARY

I don't like the DMCA. I'm not going to cave to the man like this. I don't think these links infringe copyright. I don't know the link these guys were asked to take down, but I believe it is "http://www.unitedti.org/index.php?showtopic=8888" (or maybe this link to the older Google cache of that page). Therefore, TI may be sending a message to Google in the near future asking them to take this down. If they do, this will be my counter-claim (to Google/Blogger):

In regards to the material at "http://erratasec.blogspot.com" removed by you pursuant to 17 U.S.C. Section 512. I have a good faith belief that this material was removed or disabled in error as a result of mistake or misidentification of the material. I declare that this is true and accurate under penalty of perjury under the laws of the United States of America.
For the purposes of this matter, I consent to the jurisdiction of the Federal District Court for the judicial district in Northern Geogia. I also consent to service of process by the person providing notification under Section 512(c)(1)(C) or that person's agent. However, by this letter, I do not waive any other rights, including the ability to pursue an action for the removal or disabling of access to this material, if wrongful.
Having complied with the requirements of Section 512(g)(3), I remind you that you must now replace the blocked or removed material and cease disabling access to it within fourteen business days of your receipt of this notice. Please notify me when this has been done.
I appreciate your prompt attention to this matter. If you have any questions about this notice, please do not hesitate to contact me.

Sincerely,
Robert David Graham
robert_david_graham@yahoo.com

Intel’s Atom vs. Cybersecurity

Intel has two new exciting CPUs: the low-powered "Atom" and the fast "Nehalem" aka. Core i7. I thought I'd cover some points related to the Atom processor.

WHAT MAKES IT DIFFERENT

The Atom sacrifices performance for power efficiency. It's roughly 1/10th as fast as the fastest desktop processor, but consumes 1/100th the electrical power.

It's a completely new design. Intel's current processors (like the Nehalem/Core-i7 and the Core2) are derived from the line of processors first shipped in 1998 as the "Pentium Pro" or "P6". The major difference in the designs is that the mainstream processors are "out-of-order", whereas the Atom is "in-order/hyper-threaded". That means for single-threaded applications, the Atom is roughly half as fast in comparison.

The major competitor to the Atom is the "CULV" or "Consumer Ultra Low Voltage" processors from Intel. You'll see equivalent netbook/notebook designs from manufacturers like Asus, Acer, or MSI that look otherwise identical except for the processor: either a 1.6-GHz Atom or a 1.4-GHz Core2-Solo/CULV. Because of the in-order vs. out-of-order, the single threaded tasks will be half as fast on the Atom machines. On the other hand, in applications that can take advantage two threads, the Atom machine is just as fast the CULV machine.

DISPOSABLE COMPUTING

In my pentests, I need computers that I can damage, lose, or deliberately throw away. The Atom forms the basis for more cheap $200 "netbook" computers. This is less than our hourly consulting rate, so fits the bill perfectly.

These are great for "wired" assessments, where I'm running tools like Nessus to scan behind the firewall or sniff packets from a (100-mbps) connection.

These are even better for "wireless" assessments, where I need to leave a computer outside a building scanning, or setting up an "evil twin" to trick employees. Maybe somebody will have discovered the computer and taken it, maybe it gets rained on -- it's only $200, so it's not a big deal.

The devices are also extremely small and portable. We can travel with a bunch of them on the plane in our carry-on luggage. They are also damn sexy: I've never been one to mess up my laptop with stickers and trinkets, but it's fun to decorate the cheap netbooks.

This story is apparently about a pentest/hack where the perp sent netbooks to an office appearing from HP, but likely containing malware.

VIRUS ANALYSIS

I'm infecting my Windows netbooks with viruses. It's pretty easy to clone a small system, infect it with a virus, then restore the cloned image.

I prefer doing this because I get a more "real" assessment of the virus. A lot of them check for VMware, a lot of them check for "known" IP addresses. I can take a netbook to a public cafe, log on there, infect my computer, then sniff the traffic with a second computer. It simulates a much more "real" environment for the virus.

LOW POWER

Like all such geeks, I have a large test lab running many operating systems and servers. These systems run 24-hours a day. This causes a large electricity bill. I've converted most of these to Atom processor systems, such as the Eee Box desktop computer (typically 15 watts), netbooks (10 watts), and I'm thinking of the Acer easyStore home server.

This is has had a noticeable effect on my server room, drastically reducing temperatures. It's a big drop from a system running over 100-watts at idle to one running 15-watts.

Note that the Atom processor itself run at just a couple watts, but the remaining chips in the system run at 10 to 15 watts. I notice that on the lowest power system I have, it's less than 1 watt difference between "sleep" mode and "password cracking" mode.

FULL FEATURE

The Atom processor line supports all the recent major features of Intel processors, such as "virtualization", "NX" bit, SSE3, 64-bit, hyper-threading, and so on.

Strangely, there isn't a single version of the processor that supports all these features at the same time. The ones that support 64-bit don't support the VT virtualization extensions (although you can still do the older form of virtualization). According to this website, a guy is running ESXi on a Dell Mini 9.

Intel has a nice site for comparing features of the Atom processor.

PASSWORD CRACKING

One of the biggest changes in the Core2 processor (vs. the older Pentium M and Pentium 4) is that the SSE instructions ran at the full 128-bit. Prior to that, while SSE registers were 128-bits wide, they would only process the first 64-bits in one clock cycle, then the second 64-bits in the next clock cycle. Thus, the Core2 represented an 2x increase in SSE speed.

That was one of my biggest questions for the Atom: is their SSE implementation like the old processors or the new processors? I couldn't find this documented anywhere, so I had to benchmark my password cracking code (which uses SSE instructions).

I assumed the worst, but was pleasantly surprised: the Atom processor executes a full 128-bits in a single clock cycle. That means that for SSE code, a 1.6-GHz Atom will be faster than a 1.4-GHz Core2-solo/CULV at password cracking. This is indeed the results that I get. Likewise, my dual-core Atom 330 system (Eee Box) is as fast as my dual-core MacBook Air 1.86-GHz Core 2 Duo (faster, even, because the cooling often kicks in throttling the CPU).

Note that the processors require different optimizations. The Atom requires a very simple code that can be easily hyperthreaded. The Core2 requires manually interleaving two streams of instructions that run in a single thread.

Since 100% CPU usage is roughly the same electrical power usage as 0%, I leave password cracking running in the background on Atom servers.

SMALL DEVICES


These netbooks use close to the same power as other devices in my home. My WRT54G uses 8-Watts, my Acer Aspire uses 12-Watts (picture on right) with screen turned off and battery removed (while running password cracker at 100% CPU). The WRT54G is a WiFi access-point/router from Cisco that is famous for hackers replacing the firmware with their own special Linux distros. With only 4-megs of flash and 16-megs of RAM, it's much more limited than netbooks that start at 4-GIGS of flash and 512-megs of RAM.

You can install "soft APs" to convert a netbook into an access-point, and install other goodies like intrusion-detection systems and firewalls. While they are far from perfect, they can make nice little home devices.

X86 VS ARM

In theory, RISC processors (especially ARM) should be a better solution for low-powered, highly-functional devices. There are lots of nice ARM solutions (like this wallplug computer or bigger devices like this one). The new ARM Cortex 9 looks extremely sexy.

Yet, these don't turn out so well in practice. These ARM devices don't work like computers I'm familiar with. I can't simply stick in a CD or USB drive, boot the machine, and install my favorite distro with my favorite developer tools. Instead, I have to install ARM cross compilers on my Linux box and go from there. It's very annoying. I'd be willing to go through the effort if I'm developing a special device to sell to customers, but I'm not willing to bother if I just want to create a device for myself. It's just easier to get a $200 netbook.

There is also some value with familiarity of the x86 instruction set. While Atom's in-order design is a radical departure from previous Intel CPUs, old rules for optimizations generally apply. More importantly, things like SSE behave the same, and work elegantly, whereas in the ARM process, multimedia instructions are a bit weird.

CONCLUSION

I like the Atom because I can now throw a cheap computer at a problem and solve it, especially my ever hotter server room.

The Sins of the FSF

As Microsoft launches closed-source "Windows 7", the FSF has created a website about Windows 7 Sins, detailing 7 sins that Windows makes. I thought I'd rebut their claims.


1. Poisoning education The FSF claims that Microsoft "Microsoft spends large sums on lobbyists and marketing to corrupt educational departments". Well, so does the "free-software" movement. There are unpaid enthusiasts everywhere trying to convince educational departments to move to open-source like Linux. There are also big multinationals (Sun, IBM) selling hardware/services that lobby government for laws favoring open-source. They are no more truthful about the advantages/costs of open-source than Microsoft is of Windows.

What makes Microsoft different, however, is that they listen to children. They spend hundreds of millions on usability exercises listening to children using Windows. They believe that only by listening to children can you "empower" them. On the 7-sins website, the FSF has a picture of the OLPC or "One Laptop Per Child". The OLPC was created for children by a bunch of professors, but was made without any user input from the children themselves. The only feedback from children are photo opportunities where children are encouraged to confirm how wonderful the system is, in a truly Orwellian fashion.

2. Invading privacy The FSF has a point here, I won't deny this one. I will point out that right now, this privacy invasion is tiny. While it's a bad principle, it's not so bad in practice.

3. Monopoly behavior The FSF claims that "nearly every computer purchased has Windows pre-installed". This is a lie. More computers ship with Linux (a "free" operating system) than Windows. The only place Microsoft dominates is the desktop. Everywhere else, from mobile phones to wireless access-points to home media devices to Internet servers, Microsoft loses out to Linux (and other operating systems). It's the "free" operating system Linux that dominates the world - it's only the desktop where Microsoft dominates.

Moreover, Microsoft is losing the war for the desktop. Computing has moved to the cloud, where Linux dominates. Less and less time is spent with applications installed on the desktop and more and more time is spent with web-based services accessible via any device, such as mobile phones.

Microsoft is in the position IBM was in the 1980s, when the world moved away from mainframes (dominated by IBM) and embraced desktop computers. Today, people are moving away from the desktop. Linux will never unseat Microsoft on the desktop - but it will become the eventual victor as the desktop becomes irrelevant. The FSF demeans itself by continuing to fight against a has-been company like Microsoft trying to undo its victory of the past; it should be fighting for new markets in the future.

4. Lock-in The FSF claims "Microsoft regularly attempts to force updates on its users, by removing support for older versions of Windows and Office". This is so not true. Microsoft does the reverse, supporting old technologies long after it becomes uneconomical to do so. Microsoft continues to support Windows NT, developed in the 1990s - as long as you pay extra for it. The only thing that stops is free support.

Even Linux deals with the fact that technology changes, and they have to remove support for older stuff from the default kernel. The 'atime' issue is one of the more amusing examples of this. If you've got an old version of Linux, and there is a problem needing to be fixed, you'll have to pay somebody to fix it -- just like Microsoft.

More amusing is the GNU public license viral "lock-in", which is more of a fight against other open-source licenses rather than a fight against closed-source.

5. Abusing standards The FSF claims that Microsoft tries to block standardization. This isn't true. I've been through numerous standardization efforts, I know how this works. Standards are driven by people who have a narrow focus on an ideal implementation, but who have little experience in the dirty practical details. In this case, they are driven by people who have never created their own word processor, but who want to tell word processing companies how to do their job. Microsoft is fighting for support of features that would be obvious to anybody who has written world-processing software, but which the standards body doesn't understand.

The Internet was created by people who created working implementations FIRST, and then standardized the implementation SECOND. Microsoft is fighting a standards process that works the other way around. Adopting Microsoft's format would be the smartest thing for the standard's body to do.

6. Enforcing Digital Restrictions Management (DRM) I agree partially with the FSF here. I believe that if YOU buy something, it should support YOUR rights. It should not support SOMEBODY ELSES rights over YOURS. On the other hand, I don't use Microsoft's Media Player - I use VLC. The media player isn't part of the operating system, it's just an application. Using Windows does not stop you from using things like iTunes or VLC.

7. Threatening user security This is another outright lie by the FSF. The history of Windows vulnerabilities is no worse than Linux. A "virus" is something that spreads among desktops - since Linux has virtually no desktops, it of course has virtually no viruses. The lack of Linux viruses doesn't mean Linux is better, it simply means that hackers go after the biggest target.

More importantly, Microsoft has become the leader in security, both in terms of how code is written (like the SDL) as well as features in the operating system (like ASLR). It is Linux and the open-source community that is catching up with Windows security, and not the other way around.

Summary The FSF pretends to claim the "moral high ground", so few question them. Yet, they are an Orwellian organization based upon the 1984 slogan that "Freedom is Slavery". While they the polar opposite of Microsoft, that doesn't make them any less sinful.

$169 Eee 900 disposable computer

At Woot.com, they are selling a Eee 900 netbook for $169 (today only, of course).

It's a limited computer, of course, but that's not the point. What makes it wonderful is that it's disposable. We use these in pentesting, leaving it behind attached to a wired network, or wifi scanning. It has an Atheros WiFi chip, which is the best under Linux for Wifi pentesting. The great thing about it is that if it's destroyed, lost, or stolen, you are out just $170. What's also cool is that you can boot from SD cards with different versions of Linux (e.g. Backtrack), for a complete set of pentest tools.

Another option, btw, is the Acer Aspire One AO751h. I saw one at Costco for $329. It also has an Atheros WiFi for pentesting. However, that unit is 11.6 inches with a full sized keyboard. I've sat in a cramped car pentesting with the Eee 900 -- it would've been much easier with that Acer unit.

I got my mom a Eee 1000he (she travels a lot) for $300. Unfortunately, she doesn't get the idea of "disposable" computer and takes care of it like it's something valuable. She keeps it in the case, even with the slip of cloth inside between the screen and keyboard. She wipes off fingerprints. In my mind, she should treat it more like I treat my MacBook Air, which has picked up numerous dents and scratches since I got it 10 months ago.

A recent episode of the series "Burn Notice" showed the main character leaving behind a netbook monitoring a network. It looked like a product placement and was not material to the plot, but it shows the sort of thing I do with pentesting.

SQL injection not sophisticated

I was reading this news story about the recent 130-million stolen credit card numbers. The story says:

According to the Justice Department, the suspects used a sophisticated hacking technique called an "SQL injection attack"...

SQL injection is not sophisticated. It is extremely easy. A million teenage hackers around the world know how to break into websites using SQL injection.

This is the reason SQL injection is so common. The programmers who create websites believe that SQL injection is a "theoretical" vulnerability that does not endanger their websites in practice. They are wrong -- it's easy for someone of average hacking skill to exploit.

Because these programmers don't believe in the problem, SQL injection problems are wide-spread. They seem to be everywhere I look. Here are some recent examples:

• Breitbart.com
  
• UN.org
  
• http://dev.indigopapa.tv/clients/arctic/statsXML.php?name=pe'n
  

The news article should have instead said "Hackers used the well-known SQL injection technique" rather than the "sophisticated" technique.

UPDATE: Dan Goodin at The Register gets it right, describing it as a garden-variety exploit. I guess that's the difference between IT press and mainstream press: for one, it's "garden-variety", for the other, it's "sophisticated".

Clear(tm) WiMax

I got the "Clear" WiMax service. Here is a quick review of the service.

As the picture shows, Speedtest.net reports that I'm getting 7-mbps and 500-kbps up with 73-ms latency. This is competitive with wired speeds. I usually get high-speed service all around Atlanta. I also get service in Portland and Las Vegas, the other two cities currently supported. I'd guess that I will get service in future cities Clear will support.

However, coverage sucks. Signal at home sucks, even though it's in the middle of the coverage area, and occasionally I don't get coverage in other parts of Atlanta. More importantly, Clear doesn't work outside of metropolitan areas.

In contrast, while my AT&T 3G is much slower, it always works -- even in unpopulated areas. If the 3G service doesn't work, AT&T's service backs off to 2G "EDGE" dial-up speeds, so I can still at least send/receive e-mail.

The reason for Clear's coverage issues is that it can't have the same coverage as mobile phones. In the case of mobile phones, a carrier will buy spectrum from the government that covers an entire city, or possibly an entire state. That means they can put up towers wherever they want to maximize coverage and connectivity. Clear's WiMax is different. They are using the 2.5-GHz "education" band. This is spectrum given away to education institutions (high-schools, universities, churches) a few decades ago. It was intended for local education TV broadcasts, but virtually no school used it. Clear has leased this spectrum for their WiMax service. This means that coverage is spotty because they need to have to nearby school license their spectrum. This means coverage is likely never going to be as good as mobile phone coverage.

The Clear service is unlimited, so I can run BitTorrent on the connection (in theory, I haven't tried it yet). In contrast, AT&T has a bandwidth cap of around 5-gigabytes. I few months ago, I left last.fm running, exceeded the AT&T bandwidth cap, and got stuck with a $500 overage bill.

Both AT&T 3G and Clear cost roughly the same. I've got two USB Clear adapters for $55/month (so two people can use it simultaneously).

I haven't done any security yet. I'll get around to cracking the baseband adapter on my adapter, and writing software for the USRP. This will probably take a while before I get around to it.

UN's website still vulnerable after 2 years

Two years ago today, I blogged about a defacement of the UN.org website. I noted that while they removed the defaced webpages, they had not yet fixed the vulnerability.

I checked today, and they STILL haven’t fixed the SQL injection vulnerability that led to their defacement. Hackers can still deface their website at will. Just put a quote in the ASP parameter and off you go, such as http://www.un.org/apps/news/infocus/sgspeeches/statments_full.asp?statID=10'5.



There are a couple lessons here. The first is that no matter how simple the fix, organizations like the UN cannot do it. Despite the fact a high-school intern can fix the bug in 5-minutes, the bureaucracy means that the organization must spend tens of thousands of dollars to fix the bug. A project manager needs to coordinate with external consultants. They need to plan the timeline of the change, and verify it works. They need to get agreement from various levels of management who don’t understand cybersecurity and are likely to veto the change.

The other lesson is that the cost of NOT fixing the bug is low. The UN can simply live with the problem, and clean up after every hack. The site only contains articles, it contains nothing else interesting (like private financial information). Even with such a simple and obvious vulnerability, they are unlikely to get hacked more than once or twice a year (indeed, it appears they haven’t gotten hacked for the last two years).

Together, both these things means that it’s cheaper for the UN to cleanup after each break-in rather than fix the vulnerability. At least, this is what their management feels.

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.