Tuesday, June 19, 2012

Microsoft Surface: because the iPad is an existential threat

The term "existential threat" refers to things that threaten your existence. For the last 30 years, nothing has threatened Microsoft's hegomony over the desktop. The Internet didn't. Thin clients didn't. Java didn't. Linux desktops continue to be horrid. The Apple desktop is good enough, but only in the high-margin niche.

But a better Windows than Windows was never going to be a threat. That's not how technology works. Once you dominate a market, nobody is going to rise up and challenge you. Instead, the only threat is that your market becomes obsolete.

Monday, June 18, 2012

Falsehoods programmers believe about networks

Inspired by falsehoods programmers believe about time and usernames, I thought I'd start collecting falsehoods programmers have about networks.
  1. Data on the network cannot be altered.
  2. Encrypted data on the network cannot be altered.
  3. Data cannot be accidentally corrupted, because TCP has checksums and Ethernet has CRCs
  4. If it's inside my perimeter firewall, that means I have total control over it (@armorguy)
  5. If it doesn't return an error, then send() sent all the data that was asked of it.
  6. Packets arrive in the order in which they were sent.
  7. Segment boundaries on a TCP stream are meaningful to the application.
  8. Segment boundaries on a TCP stream are not meaningful to the application.
  9. If you can't ping the target, then it doesn't exist. (@jjarmoc)
  10. If you can ping the target, then it does exist.
  11. TCP RSTs come from end-nodes.
  12. Bytes must be "swapped" from the network byte-order to the host CPU byte-order.
  13. It's an internal web app -- outsiders won't be able to discover where it is (@biosshadow)
  14. The DHCP address will be the same after a reboot (@shewfig)
  15. The DHCP address will remain the same until the next reboot.
  16. Well, it'll last a long time between changes
  17. Packets/PDUs go up or down the network stack, never sideways. (@maradydd)
  18. The IPv4 header is 20 bytes long starting with 0x45 (options are so rare we don't have to worry about them) (@shewfig)
  19. The DHCP server and local router are the same (@schrotthaufen)
What's fun is that you can see these errors happen by monitoring packets, I started this list for programmers, but we inevitably drifted outside programmers to network administrators. It's hard to draw the line, because some misconceptions are shared by both.
  1. There is no IPv6 on my network (@shewfig)
  2. NAT automatically blocks all inbound attacks (@shewfig)
  3. We know all the devices attached to our network at any given time (@armorguy)
  4. VLANs are just as good as physical segmentation. (@jjarmoc)
  5. Ok, VLANs aren't as good, but they are good enough for now.
  6. We have good WIPS/monitors, so we don't have rogue access-points anywhere. (@armorguy)
  7. No need to add it to the DNS; I'll remember it. (@shewfig)

Thursday, June 14, 2012

Norton v Olson: A review of a review

I like Quinn Norton's (@QuinnNorton) book review of Parmy Olson's (@Parmy) "We are anonymous", so I thought I'd write of a review of that review.

First off, Quinn's post should be treated with a bit of skepticism. I think Parmy's book is better than how Quinn describes it. They are competing journalists covering the same subject, so would naturally disagree on the best approach. Also, I think Quinn herself is not objective enough on the subject of Anonymous.

But Quinn's review is otherwise pretty good, with some keen insights.

Wednesday, June 13, 2012

Thunderbolt cables are bidirectional

The Intel/Apple "Thunderbolt" technology is sexy has heck. It's not the 10gbps speed (being only slightly faster than USB3 5-gbps), but the fact that it exports raw PCIe signals.

But it's a bit flaky. I just bought an Apple 27 inch "Thunderbolt" display to go with the new MacBook Air I just ordered online. Apparently, like many other people, I'm getting an intermittent failure with the screen frequently going black.

Tech-support was pretty clueless, with me explaining to them how to diagnose the problem, such as going to the "System Report" to see what the Thunderbolt controller thinks is attached.

Even worse, they didn't suggest the solution I came up with. Instead of using the built-in "input" cable in the display, I grabbed a normal Thunderbolt cable and connected to the "output" of the display (the output is for daisy chaining to a second monitor, or for hooking up other Thunderbolt devices like RAID arrays).

Wednesday, June 06, 2012

LinkedIn vs. password cracking

I'm running through the LinkedIn password hashes right now, so I thought I'd do a live blog of the steps I'm doing. As I do each step, I'll update this blog live. When you reach the end, chances are good I'll be updating it again in a few hours.

Confirmed: LinkedIn 6mil password dump is real

Today's news is that 6 million LinkedIn password hashes were dumped to the Internet. I can confirm this hack is real: the password I use for LinkedIn is in that list. I use that password NOWHERE ELSE. Furthermore, it's long/complex enough that I'm confident NOBODY ELSE uses the same password. Other security pros are reporting the same result. Therefore, we can confirm that this hack is real.

The way I tested to see if my password was in the list was to first generate a SHA-1 hash of my password, then I searched in the file "combo_not.txt" that I downloaded from the Internet containing the 6 million password hashes. I found a match.

To make it easy to calculate your SHA-1 password, I've included a form below. This is done in JavaScript inside your browser, it does not submit your password/hash to me or anybody else:

Enter any message to check its SHA-1 hash
  • Note SHA-1 hash of ‘abc’ should be: a9993e364706816aba3e25717850c26c9cd0d89d

Many of the hashes have their first few digits zeroed out (as described in this ycombinator post) as shown in the this excerpt from the file:

This means instead of searching for the complete SHA-1 output, you want to search for just the later part of the hash. People think that this means that the hacker has already cracked any passwords that have been zeroed out this way, which means that if you see zeroes in your matching password, then your password is already stolen.

Also note that if your password is long enough (like greater than 15 characters) and complex enough, then it's still probably safe. A 15 character SHA-1 password composed of upper/lower case with symbols and digits is too large for "brute-force" and "rainbow tables". However, if you've composed it of dictionary words, then it could fall to a "mutated dictionary" attack.

Update: the following link is a pointer to a download of the file, which by the time you read this, is almost certainly been removed https://disk.yandex.net/disk/public/?hash=pCAcIfV7wxXCL/YPhObEEH5u5PKPlp%2BmuGtgOEptAS4%3D

Update: This is a sorted list of unique passwords. Thus, if 50 people use the password "password", it'll only show up once in this list. Which it does. The password of "password" is hashed using SHA-1 to "5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8", which appears as "000001e4c9b93f3f0682250b6cf8331b7ee68fd8" in this list.

Update: Where do these passwords come from? The answer is the: the cracking underground. When hackers break into a network and steal the encrypted passwords, they crack as many as they can, and then exchange the dumps with their friends. Each hacker uses different tools, uses different dictionaries, and so on. Thus, once they've exhausted your their techniques, another hacker is still likely to be able to crack many more passwords.

Update: It took me only a couple minutes to verify that this hack is real, yet LinkedIn has not been able to:

This reflects poorly on the trustworthiness of LinkedIn. It's proper that you make such a comment before you know what's going on, but they've had hours to verify this, we should've gotten an update by now.
Update:LinkedIn has a semi-confirmation as explained in their blogpost here. However, it only says they confirm that some of the passwords that were compromised correspond to LinkedIn accounts. That avoids accepting blame, after all, in other prominent password attacks (like one recently against Twitter), the source of the hack was not Twitter's fault, but due to "password reuse", as users used the same password for Twitter that they used for other websites, and it's the other websites that were hacked. As I (and other security pros) have confirmed, we don't reuse passwords. This password list comes from LinkedIn, and from no other source.

Update: How fast can hackers crack passwords? The answer "2 billion per second" using the Radeon HD 7970 (the latest top-of-the-line graphics processor). Each letter of a password has 100 combinations (UPPER, lower, d1g1ts, $ymbols). A 5 letter password therefore has 100 x 100 x 100 x 100 x 100 or 10 billion combinations, meaning it can be cracked in 5 seconds. A 6 letter password has 100 times that, or 500 seconds. A 7 letter password has 100 times that, or 50,000 seconds, or 13 hours. An 8 character password is roughly 57 days. A 9 character password is 100 times that, about 15 years. In other words, if your password was 7 letters, the hacker has already cracked it, but if it's 9 letters, it's too difficult to crack with brute force.

Update: A site http://leakedin.org will check this for you. They claim to has the password in the browser (like I do above), then check the database. I don't know if this is true -- but since you are going to change your password regardless, maybe it doesn't matter.

Update: What does password cracking look like? I started the "hashcat" tool to examine the file. It looks like this:

I'm using the latest Radeon HD 7970 graphics card. Note that I'm only getting a cracking rate of 400-million passwords/second, while the 7970 can actually do 2-billion/second. That's because I'm doing "multi-hash" cracking, testing each hash against the entire original list of 6.5 million hashes. That lookup takes longer than calculating the hash in the first place. I can dramatically increase hashing speed by first removing all the easily cracked passwords from the list, making it smaller, and hence making lookups faster.

Friday, June 01, 2012

Chinese/military backdoor: Microsemi and Skorobogatov respond

The original researchers respond to my post making the following two assertions:

  1. The issue exposed by their paper is threat from China.
  2. They have no idea why people have linked China to their paper as it did not come from them.

One of those statements can be true, but not both.

They continue to play the military angle. The truth is that the military cares about chips operating at high temperatures, and could care less about intellectual property, encryption, and backdoors in 99% of applications. The military would happily buy guns from China, for example.

In other words, Skorobogatov continues to attempt to link their paper to China and the military in order to cause FUD, and these links are dishonest. There is an interesting issue for intellectual property, but any link to either China or the military is largely nonsense.

Microsemi/Actel also has issued their official response. It is as dishonest as Skorobogatov. They use the Apple trick of saying "the researcher hasn't helped us reproduce it, so no problem exists". They ignore the real crux of the problem, which is that the researchers were able to read back the configuration, despite Microsemi/Actel's assurances that no such functionality exists in any mode (debug or otherwise).

My interpretation after reading the paper, Microsemi/Actel's response, and the comments to my blog, it sounds like there are multiple levels of security, and that all Skorobogatov did was break the next higher level. Maybe there is a default key for the next higher level that customers didn't realize existed, so are shipping their chips at the lower level. This would explain both the discovery of a "backdoor" and claims that "there is no backdoor". In my experience in cybersecurity, this is pretty typical, that both sides are right.

The important part of Microsemi's statement is that they "confirm that there is no designed feature that would enable the circumvention of the user security" by "Microsemi or anyone else".

To summarize: Skorobogatov appears to have found a way to read the data off of the FPGA and steal intellectual property. This is actually a very important result, although few outside the hardware world would care. Anybody using Microsemi/Actel's chips should be afraid of that threat. The China and military angles, though, are dishonest.

Skorobogatov responds to my original post with the following points, so I thought I'd rebut them individually.
1) We have made no reference to any Chinese involvement in either of the released papers or any reference to espionage. Therefore we don't agree with Robert Graham's assertion that we suggest Chinese involvement. So we have no idea why people have linked the Chinese to this as it did not come from us.
Of course you linked to China, as you did again in this article.

2) As far as we are concerned the back door was implemented by the manufacturers at the design stage and we suggest that in the papers.
You have no evidence that it's a "backdoor" and not something that customers can disable. Maybe the chips you've tested haven't had the higher layer of security turned on.

3) We do not know if the chip was certified to hold secrets or not. We quote Actel and their website which says that the ProASIC and other flash lines are sold to the military as well as into automotive, aerospace, medical and consumer systems. It is a very secure device with AES encryption, if you use it, then you want to protect the IP and there is no better way that using AES with no read-back.
Military means "high temperatures", not "AES encryption". You are deliberately misleading people who think that every thing the military does must be encrypted.

4) It is not just a simple JTAG hack, there is a lot more involved than that and it's contained in the paper.
Yes, I've read your paper. And your PEA trick seems quite impressive. But you link to China and the military, which puts your work in my world of cybersecurity. All your issues about reverse engineering, backdooring, and trojans already exist in my world. The "taxonomy" of hardware trojans that is reference [1] in your paper (which links to China, by the way) is pretty primitive and naive compared to the taxonomy of software backdoors/trojans in cybersecurity. In my world, what was important is that you fuzzed the JTAG port, not that you used PEA to guide the fuzzing.

5) We do not agree it is just a debug port, you do not need a debug port to circumvent the security on the chip and read back the IP whilst telling everyone else no such feature exists.
Yes, I agree that this is the real story, to which you do disservice with the China/military FUD.