Posted by Scott Laird
Wed, 13 Jul 2005 02:11:30 GMT
I’ve spent most of the past two days working on a little project at work that needs the ability to generate Java JKS keystore files (compatible with the Java keytool program) containing X.509 certificates signed by a private certificate authority.
If you think that sounds simple, then you’ve obviously never worked with X.509.
This turns out to be astoundingly difficult, largely because X.509 is insane. It doesn’t help that Sun’s keytool program is missing a lot of functionality–if you want to rename keys or extract the private keys from the keystore file, then you’ll need to resort to coding it in Java. It’s also really hard to find usable certificate authority software. I’ve been looking for it at least 8 years for a complete open-source corporate CA! There are lots of partial solutions out there, but none of the ones that I’ve used have actually been able to solve all of the problems that I’ve needed solved. I’ve always fallen back on scripting openssl directly, and that always requires a day or so of digging through OpenSSL documentation to find the right incantations to get it to work.
In the end, all I needed to do was run openssl 3 times per key generated (make key, sign key, convert to PKCS#12), then run a bit of Java code out of Jetty to convert the PKCS#12 key to a format that keytool can read. Don’t ask why I had to drag Jetty into the picture–that’s like requiring Apache in order to get your version control software to compile or something–it just doesn’t make any sense. Sigh.
For future reference, here are a few useful references:
Posted in Computer Security, Computer System Administration, Work | Tags cryptography, openssl, rant, x509 | 4 comments
Posted by Scott Laird
Thu, 07 Jul 2005 23:46:19 GMT
CNet says that there’s a security bug in zlib 1.2.2. There’s no exploit yet, but since everything uses zlib, this will probably turn into a problem for those who don’t upgrade to 1.2.3 once it becomes available.
Since libpng and OpenSSL both use zlib, we’re going to see a lot of network-based programs with issues.
Posted in Computer Security | Tags linux, openssl, security, zlib | no comments
Posted by Scott Laird
Tue, 28 Jun 2005 02:43:19 GMT
It’s amazing the ways that people can find to steal money. The latest scam goes like this:
- Set up the local equivalent of a CLEC in some third-world country.
- Publish exorbitant rates for a block of numbers (say, $5/minute).
- Sign up with a US-based VoIP provider using a freshly-stolen credit-card number.
- Verify that the VoIP provider doesn’t know about your rates, and only charges a small fee to dial the country in question (say, $0.10/minute).
- Have a SIP auto-dialer call your numbers via the VoIP provider until the CC is declined or the account’s balance limit is hit.
- Repeat.
- At some point in the future, the VoIP provider will receive a massive bill from their upstream provider, while the Telco in whatever third-world country you’re using will hand you a big check.
This is just a twist on the old “modem dialer” scam, but it’s been costing VoIP providers big money. NuFone has apparently lost $400,000 recently, and other providers are reporting huge fraud rates–according to Teliax, roughly 1/3 of their new customer signups are fraudulent.
There’s a long thread following this on Digium’s list server.
It looks like this has helped kill at least one VoIP provider: LiveVoIP has declared bankruptcy, although they had a spotty reputation to start with.
Posted in Computer Security, Asterisk | Tags asterisk, fraud, nufone, scam, voip | 3 comments
Posted by Scott Laird
Tue, 17 May 2005 20:13:57 GMT
Bruce Schneier posted a link to an AES timing attack from Dan Bernstein.
This is similar to last week’s hyperthreading vulnerability, in that it exploits cache timing variances to extract sensitive information, but DJB’s attack is demonstrated working over a network–it doesn’t require that the attack code run on the same physical CPU as the encryption code. Instead, it exploits the fact that AES implementations need to do data-dependent lookups from tables, and the tables don’t fit entirely into the CPU’s fastest cache. Therefore, by closely watching the time it takes for a server to encrypt a packet and return a result, you can learn something about the key itself. By feeding the server millions of carefully-crafted packets and examining the timing results produced, he was able to narrow the keyspace substantially.
In this case, he was able to recover all 128 bits of a randomly-generated AES key in around a day. Most likely, the process could be optimized substantially by testing high-probablility keys against a known plaintext in parallel with the AES. I wouldn’t be surprised if an hour’s worth of traffic was enough to narrow the keyspace enough to make a brute-force attack possible. His notes also suggest a number of other optimizations that may lower the amount of work even further.
In general, any data-dependent timings anywhere in a crypto system will subject the system to this sort of problem. Unfortunately, it’s nearly impossible to eliminate all of the data-dependent timing issues on any modern computer–between cache issues, hidden optimizations in certain instructions, measurable delays when switching between cache banks, and an utter lack of comprehensive performance documentation, there’s really no easy way to avoid this class of problems on modern CPUs. The best you can do is minimize the amount of variance and force the attacker to use larger and larger amounts of traffic.
All in all, this probably isn’t just a theoretical attack. It isn’t something that random hackers will use, but it’s fast enough to be usable by a determined attacker with relatively low-latency network access to the victim’s system.
Posted in Computer Security | Tags aes, cryptography, djb, security, timingattack | no comments
Posted by Scott Laird
Fri, 13 May 2005 00:27:44 GMT
KernelTrap is reporting that a SFU grad student has found some sort of hyperthreading vulnerability. Details are slim, but he’s claiming some sort of information leakage between threads on a HT CPU, saying that this could lead to the disclosure of things like RSA private keys.
If I had to guess, I’d say that this is some sort of timing attack. Most likely, the leak occurs when one HT thread runs a predictable chunk of code with secret data while the other HT thread runs some sort of monitoring code, watching for things like cache misses or utilization of the various shared resources. Or maybe, Intel shares the CPU performance counters between the two threads so the attacking thread can simply extract detailed timing information from the other thread’s work, and then use the timing information to reconstruct details on what the attacked thread was doing. There’s a decent body of work on attacking smart cards using similar techniques.
Update: After doing a bit of research, it looks like Intel does share performance counter data between threads, and some of the data shared is really interesting, like branch prediction data–if you’re attacking a known body of code, you may actually be able to extract enough data from this to get a decent peak at the private key.
Update 2: The paper is online. If I’m reading this correctly, the basic attack uses timing measurements against the L1 and L2 caches to see when the RSA thread moves on to a new cache line worth of data. The attack doesn’t need access to anything more advanced then the CPU’s cycle-counter clock to be able to recover roughly 310 bits from a 512 bit key.
Personally, I find this to be fascinating from an academic standpoint but not terrifically useful in the real world. I don’t generally want untrusted users to have any access to systems with valuable keys. Historically, it hasn’t taken most attackers very long to turn untrusted shell access into a root exploit. In almost any case, a root exploit is more worrying then the loss of 310 bits from a 512 bit key–if the attacker had root, odds are they could recover the entire key directly.
This is clearly a problem that needs to be fixed by Intel, but I’m not planning on running around disabling Hypertheading on all of my systems today. It’s just not that dangerous of an exploit for most users.
Posted in Computer Security | Tags cryptography, security, timingattack | no comments
Posted by Scott Laird
Thu, 28 Apr 2005 18:20:56 GMT
Phil Windley says that Visa and Mastercard are starting to crack down on small merchants, requiring them to meet some sort of minimum information security standards or lose the ability to accept Visa or Mastercard purchases online. This is clearly a good thing.
He lists 12 basic requirements:
- Install and maintain a working firewall to protect data
- Keep security patches up-to-date
- Protect stored data
- Encrypt data sent across public networks
- Use and regularly update anti-virus software
- Restrict access by “need to know”
- Assign unique ID to each person with computer access
- Don’t use vendor-supplied defaults for passwords and security parameters
- Track all access to data by unique ID
- Regularly test security systems and processes
- Implement and maintain an information security policy
- Restrict physical access to data
The actual questionnaire from Visa goes into a lot more detail (“Do changes to the firewall need authorization and are the changes logged?”). A quick skim of the questionnaire shows a bit of Windows bias (you can’t pass unless you have virus scanners on all your servers–that’s kind of weird in a Unix environment), but it looks like a great step forward. It’s nice to see someone in a position of influence raising the security baseline.
Posted in Computer Security | Tags cryptography, mastercard, security, standards, sysadmin, visa | 1 comment
Posted by Scott Laird
Wed, 16 Feb 2005 19:10:17 GMT
I’m not an expert in cryptography, but I try to pay attention to what’s happening in the crypto world. Today, Bruce Schneier announced:
SHA-1 has been broken. Not a reduced-round version. Not a simplified version. The real thing.
The research team of Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu (mostly from Shandong University in China) have been quietly circulating a paper announcing their results:
- collisions in the the full SHA-1 in 269 hash operations, much less than the brute-force attack of 280 operations based on the hash length.
- collisions in SHA-0 in 239 operations.
- collisions in 58-round SHA-1 in 233 operations
So, unless I’m mis-reading this, SHA-1 lost a factor of 2,048; that’s enough to start moving away from SHA-1, but not enough to run screaming in the streets. The last time that SHA-1 attacks showed up, similar attacks were possible against MD5 and possibly also the newer SHA family members; I’m not really sure if there are cryptographic hashes in common use that aren’t at least slightly tainted right now.
Posted in Computer Security | Tags broken, cryptography, security, sha1 | 5 comments
Posted by Scott Laird
Tue, 08 Jun 2004 21:45:06 GMT
Boing Boing has a link to a Bruce Schneier story in Computerworld that talks about the ’Witty’ worm from March 2004. This was the first that I’d seen about Witty, but it sounds freakishly scary: it was targeted on ISS’s BlackICE/RealSecure intrusion-detection systems. It was released under 48 hours after the vulnerability in BlackICE was made public. It infected 100% of the vulnerable systems on the net in 45 minutes. It was launched from a coordinated set of ‘drone’ machines. And it slowly destroyed the systems that it infected by overwriting random blocks of their hard drives.
Fortunately, there were only 12,000 vulnerable systems on the net. This time. The problem is that the code for Witty is out in the wild now. It’s only 700 bytes long, and it should be easy for an attacker to modify it to fit the next UDP exploit that shows up. Can you imagine what would happen if this blew through 20 million Windows boxes?
This might be a good time to run backups.
Posted in Computer Security | Tags security, virus, windows | no comments
Posted by Scott Laird
Fri, 24 Oct 2003 18:35:19 GMT
Amazing–a book on role-based access control. Enhanced security models like RBAC and MAC have been making their way into Unix and Linux for years, but I still haven’t found a good introduction to either model. Maybe this is finally it. The Linux Journal reviews it:
A good overview of implementing RBAC in the enterprise for students as well as corporate-level decision makers. [Linux Journal]
Amazon has it for $79, or £55 from amazon.co.uk.
Interestingly enough, the UK Amazon has an ebook on HIPAA and RBAC that I didn’t see when searching on amazon.com. That’s strange because HIPPA is a US thing, not a UK thing. I’m not particularly interested in HIPAA, though, and I prefer paper books.
Posted in Books, Computer Security, Computer System Administration, Work | Tags books, rbac, security | 1 comment
