Technology

Lately Andy Tanenbaum got into the news once again because a few of his students have created a scenario where RFID tags could be used to compromise databases. Upon looking at the news item a bit closer it clearly has little to do with the RFID tags.

Basically, what it boils down to is that RFID tags could be used to compromise databases through SQL injection. Big deal, innit? The threat may be real, but that doesn't make it a new one. Granted, the attack vector is different, but the attack itself is age-old.

So why make such a fuss about it? Need to get in the news again? One cannot help but wonder.

However, this shows clearly that people still scramble to adopt new technologies without considering security in the first place. It's about time that secure application design is taught in schools and universities.

In a current news item Heise reports that the Dutch security company Riscure found a way to brute-force attack the encryption of the Dutch ePassports. Let's recap: the ICAO has issued a set of guidelines on "Machine Readable Travel Documents" that basically states that passports and other travel documents should use an RFID chip that can be used to read the individual's data contactless. Apparently the field strength is strong enough to be read from several meters distance. However, the transmission is encrypted by "Basic Access Control" (BAC) where the key is comprised of the serial number of the document itself, it's issue date and it's invalidation date. This gives about 56 bit of key length (which is not really that much and it's questionable if it will be safe to use on a mid-term timeframe. Now, the issuer of the Dutch ePassports uses sequential serial numbers and the number of documents issued is basically constant per time unit. This gives a linear connection between the issue date and the passport serial number, thus effectively reducing key length to about 35 bit - which is easily breakable in a few hours without special hardware equipment.
This attack vector is valid for every document that uses BAC and uses predictable serial numbers for the documents!
What hasn't been stated so far is the fact that once the key is known the RFID chip could theoretically be read everywhere. Consider a country that's gone off the deep end with hysterics about terrrorism and thus has installed RFID scanners throughout what they consider critical points. Now they only need those scanners hooked up to a central database where all keys to all passports ever seen entering has been stored and they can easily find out where a person goes (given they take their passport with them).

Jon Toigo is annoyed at the lack of progress the information security field has made since the Medieval. I feel his pain, too. But what are the alternatives? Or rather, why are we still using the same concepts? Are we just too stupid to come up with something new or are the concepts just so basic and so sound that there is no better way? Let's take a look at the items Jon mentions.

1. Access Control: moats and stockades then, firewalls now. Access control is still one of the soundest principles of information security. Control who may access information when and how and you have removed several vulnerabilities and reduced your risk dramatically. However, the technologies being used for access control change considerably over time. Up until the 1980s to 1990s access control meant control of physical access. Computers were large and heavy and access to them could be controlled pretty strictly and fairly easily. Enter The Network - and things shift completely. Or, to be fair, they get expanded. Physical access control is by then pretty much a commodity: people just do it anyway. What's new is that access to the computers is not only available by physical access but by network access as well. While the Light Side had control for an enjoyable while it was only a matter of time until the Dark Side jumped on the bandwagon and started to use the Net for their sinister purposes. So well, Marcus Ranum writes the DEC SEAL and it starts to get a success quite fast: companies hire firewall administrators to take care of these arcane beasts that are tough to tame (alliteration not intended but gladly taken). Fast forward to today: every simple DSL router for home use has a NAT firewall included; the network guys do the firewalls on the side and up come web services with the nice side effect of tunneling "stuff" across HTTP (yes, and other protocols, but HTTP really is ubiquitous by now and a nice example of the ever changing technologies, thank you). So now we have web application firewalls which really are nothing else than application layer proxies. And so it goes, goes round again. (Kudos to Joe Jackson)


2. Signet Rings and Trusted Certificates - now there you've hit a sore spot, Jon. I don't trust the PKI model with a commercial head - much less even if said head is Verisign. The last piece in the puzzle was their Sitefinder "service" which accidentally broke half the Internet. But really, why do we trust signatures, signets or certificates at all? Chances are, the signature is illegibile anyway so a cursory glance of similarity is all we get. Same with certificates (without even the added benefit of Verisign). No solution there, I'm afraid.


3. Edicts and Policies - good point, Jon. However, I consider them to lay out the rules by which we play. We agree upon a set of rules to be able to note deviant behaviour and sanction it. Thus, policies and edits are rather useful tools as they prepare the ground for legal skirmishes or, in some cases, provide the opportunity to find out unwanted behaviour in the first place. I wouldn't want to live without them.


4. Codes and Encryption are powerful tools, too. Unfortunately, many people tend to forget that encryption is a temporary safeguard at best. Even if the encryption algorithm has no known weaknesses it still will fall given enough time. There's the rise in computing power and the change to other technologies (can you say Quantum Encryption? I knew you could!). As long as people recognize this, they are quite secure. All they have to do is select an algorithm that will possibly keep the information secure as long as it has to be classified.

Interestingly enough, the bad guys don't seem to have learned either how to circumvent the safeguards we set up. Either they are as caught in our ways of thinking or there simply Is No Better Way at the moment.

What do you think?

All of this, however, has nothing to do with vendors coming up with new products all along instead of listening to what the customers want - just like in the storage market. Thanks for the eye-opener, Jon!

I hope Shakespeare forgives me the mangling of Hamlet's line about Fair Ophelia, but really, enough is enough.

I've heard quite a few vendor presentations in the last while, most of them by big players in the information security market. Quite a few of them started with antivirus products and moved on to swallow greedily every company that didn't manage to climb the trees upon counting to three. One of those companies seems to have swallowed one bite too many in too short a time and ended up splitting itself apart (that'd be mitosis for you, by the way). But I digress.

Every one of those vendors has an Intrusion Prevention System (IPS) Appliance in their product portfolio. So far, so good. However, the latest ploy of their markedroids is to sell it like this:

[…]In the past we've seen the rise of Intrusion Detection Systems and every company and their neighbor ran to get one. Upon deploying they noticed they got tons of false positives which they'd never wade through and thus phased those systems out again after a while. And let's not forget these things are reactive!
Now we have our brand spanking new Intrusion Prevention Systems that can actually do something about unwanted traffic - it can block it automatically![…]

Yada yada yada.

I take issue on this statement on no less than three four points:

1. An IDS throwing so many false positives is not configured correctly. An IDS is a wonderful tool for analyzing your network traffic and then tweaking your IDS ruleset to adapt to your particular set of protocols and traffic patterns. An IDS in my eyes is also a very wonderful tool to analyze network problems (which rather tells why I don't like the moniker IDS - it's a pattern and traffic analyzer with a configurable ruleset). It is not, however, a silver bullet.


2. So basically what the vendors are saying is that the IDS systems we bought off them five years ago were pieces of crap and we should buy the same pieces of crap with added bells and whistles? Because they never mention that the false positives are gone in their IPS... sneaky weasels, those markedroids, aren't they?


3. So an IDS is reactive. Big deal, most security measures are - simply because it's a mathematically hard problem to enumerate all potential threats and tag them with meaningful probabilities.


4. Hey, vendors, you're s0, like, w4y c001 that you are proactively blocking traffic with your IPS systems. Only if you didn't manage to sell me decent products in the past that did what you marketed they would, can you tell me why I should want to buy another of your systems that goes so far to automagically block network traffic? I'd want to be damn sure that I didn't block anything business related! And, finally, what's so wonderfully proactive about blocking traffic? It's still reactive, only a bit earlier on in the connection setup. Proactive would mean to anticipate malicious traffic and patch the appropriate systems before the malicious and mobile code can reach them.

Which brings us full circle round to what really works: thinking about your problems instead of your symptoms. Rather than liberally deploying IPS appliances across your network you might want to analyze the traffic patterns with dedicated network analyzers (you may even call them IDS if you're cocky!) and then segment your network into different zones with well-defined traffic patterns that can be safely secured by firewalls and other blocking technologies. Take, for example, a web server. It doesn't need to be available via SMB. So block ports 135, 137, 139 and 445 ingress and egress all traffic save that you know is good and valid for the given network. Flat networks are a nightmare for trouble shooting, no matter if they're switched or not. So segment them in any way you can. That's being proactive.

Maximillian Dornseif writes in Barking at Banks that German banks sell indexed transaction numbers (iTANs, authorization codes for individual transactions) as the best thing since sliced bread and that all security woes would be magically cured by their use. He goes on to say that the banks spread misinformation and points to an advisory by his students about how iTANs are of no use against Man-In-The-Middle-Attacks. Which, of course, is right.
However, iTANs are a good tool against phishing - a phisher won't have any idea which TAN will be the next and even if they phish two or three TANs chances are they are of little use to him. And that's not even mentioning that users should get some funny feeling upon a) reading phishing emails as they are translated so extremely bad that it should be obvious they're not from the bank and b) the form asking for the TANs doesn't ask for TANs with specific indexes. So, while iTANs don't help against trojans they are pretty useful against phishers.

Dornseif's and his students' underlying premises are true, however: if the banks would use a sufficiently good mix of low-level and high-level security things would be much harder for phishers. What do I mean by low-level security? Things like not sending out HTML emails but simple text/plain messages, sent from the email servers and domains of the bank itself. And what do I mean by high-level security? Well, a time based one-time password (OTP) would be a better idea than a list of pre-generated TANs. However, the cost/benefit ratio probably won't see us going there. Even better would be HBCI with a Class 3 chipcard reader. In that case, however, the user interface is clumsy (as is often the case with security: it's not exactly user-friendly). So I don't see much happening on that front, either.

As a final note, it's quite interesting how diverse different countries' banks can be. In some countries banks hand out time-based OTP tokens, in the USA on the other hand banks don't seem to get a grasp of the concept of transaction authorization. Quite interesting, actually, as I'm sure it ties down to the mentality and society of the corresponding people.

In my earlier post about Microsoft's HoneyMonkey project I mentioned that the HoneyNet Project will probably latch on and develop something along the same lines.
In the meantime, I was notified of Kathy Wang's Honeyclient project and the client-side honeypots diploma project at the Laboratory for Dependable Distributed Systems at Rheinisch-Westfälische Technische Hochschule in Aachen.

Thanks to Thorsten Holz and whoever else pointed me at the Honeyclient project (I can't remember. Must be age creeping in).

Browsing the web through my News Aggregator I came across the Strider HoneyMonkey Project. Microsoft has added to the honeypot concept (which is passive) with an active component:

The Strider HoneyMonkey project takes the static concept of a honeypot in a new direction. A “honeymonkey” is a computer or a virtual PC that actively mimics the actions of a user surfing the Web. A series of “monkey programs,” which drive a browser in a manner similar to that of a human user, run on virtual machines in order to detect exploit sites. The browsers can be configured to run with fully updated software, or without specific updates in order to look for exploit sites that target specific vulnerabilities. In this manner, the attacks more likely to impact customers can be analyzed and detected.

Sounds like a pretty neat idea. Too bad they don't plan to publish any product. But I'd bet that the Honeynet Project guys will jump on the bandwagon (if Microsoft won't be patenting this, that is).

Off-topic Update: Take a look at the Google Ads underneath the article. Guess "Strider" is pretty strongly linked with Lord of the Rings

The F-Secure weblog reminds of the RISKS Digest's 20^th anniversary today. Thanks to Dr. Peter G. Neumann for handling the digest!

What was new to me was the fact that the Digest is also available as an RSS feed nowadays.

Well, actually it's not only at 11, it's any time you like: The Security Monkey points to a site that has various movies displaying and showing what can be done with Knoppix-related distros. The one he points to shows the 0wning of a Windows based webserver via an insecure IIS installation, but there are other movies, too.

Audit Those PCs says Fred Avolio, telling of confidential data leaking out of a PC loaded with file sharing software and infected by a virus/worm/...

While I agree with what he says about having policies and dealing with infractions current viruses and worms bring their own file sharing software. It's not even necessary to have something pre-installed.

Even if SHA-1 and MD5 are somewhat compromised (there's as yet no real breaking of the algorithms) I'm wondering why the two algorithms aren't used in conjunction?

The main problem is that the cyphertext space has gotten a lot smaller suddenly and collision attacks seem to be feasible. However, if both algorithms are used to compute the hash and both hashes will have to be checked it would mean to generate another (meaningful) message that gives collisions for both algorithms.

This will, of course, cost computing time. But it might give the community a bit of breathing space.

Slowly but surely the number of usable cryptographic hash algorithms is falling asymptotically against zero. You're reading correctly. Zero. MD-4: broken. MD-5: all but broken.
Now Bruce Schneier blogs that SHA-1 is the next candidate for that. Apparently there's a paper circulating describing how they received »collisions in 2⁶⁹ hash operations, much less than the brute-force attack of 2⁸⁰ operations based on the hash length.«.

According to Bruce, it does not affect applications like HMAC for which collisions don't play a role. It sure would make SHA-1 unusable for cryptographic hashes.