SecurID
A short story about Security through Obscurity
Once upon a time some other millennium I used to work as a computer consultant at a small computer security company. I can tell you this story because it is so far far away and none of the involved companies exists today anyway.
In my work I performed mainly two tasks, security testing and installation of security products. This particular company happened to be the Swedish agent for Security Dynamics SecurID authentication system, and we sold quite a lot of it. You know, the small keyring tokens displaying some random number you use to login to your internet bank and such.
The system as as simple as ingenious. Basically the token contains a secret key used to encrypt current time, displaying it in the display. You enter this code into the computer you want to access, it sends a query with the code to the central authentication server ("ACE server"). The authentication server also have the same secret key and (hopefully) the same time, encrypting the time with the secret and checks if it matches the one received from the client. If so, the ACE server replies to the client "Open sesame" and the client grants you access.
As my role as a security tester it felt quite natural to test the products I actually installed at our customers, SecurID no exception.
SecurID had a few suspicious issues. First of all, the communication between the ACE server and the client was of course encrypted. This is quite obvious because if not anyone would be able to confirm the identity of the user logging into the client, the user himself included as long he have access to the network. The tricky part was that no signs of key management for this existed. A small binary configuration file was generated at the server telling the client where to find the server and so. Maybe this file contained the client-server key..?
The configuration file (for the client) seemed to contain random data. It turned out this was more true than Security Dynamics actually wanted to admit. Dumping the file in hex and looking at it in emacs showed something interesting - periodicity of patterns. By adjusting the width of the emacs window, every single column displayed one and the same hexadecimal value. All except for a block in the middle of the file. Obviously Security Dynamics was so embarrassed over the small content of the configuration file, they have padded it with random data, and random data generated from a very weak random number generator. The actual payload of the file was encrypted, but they had encrypted if before padding it with the random data. If they had done it in the reverse order, it would never have been discovered. The size of the payload was too small to contain an asymmetric key.
How did I find out it was encrypted? Every SecurID installation are shipped with libraries linking your own applications with for using the SecurID authentication. This is quite necessary to get a otherwise closed software integrated with third part software (and actually used). The libraries was easy to take a part into separate object filers for every function, renaming and building new wrapper functions printing out trace data for each call. Not only the absolute necessary functions was in the libraries but also functions used internally for encryption etc. Thank you very much.
Building a client application with my "enhanced" libraries, and performing an authentication revealed a call to the decrypt function with the key of the eight ASCII characters "01234567" (or was it "12345678"?) when reading the configuration file. No other calls to the decryption function was done during this phase of the authentication. Neat. If choosing a static key to compile into your application, why not choose a bad one. A good one would have gained nothing in security anyway.
So if no encryption key in the configuration file, how is the communication between the ACE server and client secured? Having access to all internal call to the encrypt- and decrypt functions this was not hard to reverse engineer. It turned out the client encrypted the data to the server using 1) the IP address, 2) the current time and 3) the token code. The problem is that nothing of this is very secret. The IP address of the computer used can not be considered a secret. The current time? Secret? "Yes, I can tell you what time it is, but then I have to kill you"? Not very likely. But the token code, it must be hard to obtain? It is? For the intruder? The guy just typed it into his computer? Actually, he can choose any code he likes.
To make my point, I implemented my own "ACE server", capturing the network traffic and always replying "Oh yes, it's a go!". At that time the marketing guys did wear small promotion jacket pins of a small SecurID card with a token code printed on it. I needed a code for my fake server, so I used that one. Then I went over to the marketing department ..
"Hey you, can you demonstrate a SecurID login into the computer of yours?". The marketing guy looked a bit puzzled at me, knowing I was the lead expert of SecurID at the company, but obeyed. When he reached for his SecurID token, I told him to use his other token. "I only have this" he replied. No, I said, pointing at his pin he did wear on his jacket, that one! He laughed, but I kept insisting so finally he removed it from the jacket looking at the tiny tiny numbers as he fed them in to the login window at his PC. Despite of the fact being a marketing guy he was quite clever so when the computer granted him access he stop laughing realizing the severity of the issue.
A very detailed report was written and sent to Security Dynamics HQ in US about this issue, and a few other like setuid binaries of the SecurID distribution reading UNIX environment variables allowing anyone overwriting any file in the file system and other misdemeanors hardly worth mentioning. A delegation of Security Dynamics CTO with friends flew over to us in Sweden a few days later. The meeting was long, quite interesting and totally unproductive.
The meeting summarized (they in italic);
- Don't believe everything you read on the internet. It is just a hoax.
- Oh no, we have researched and verified everything in this report ourself.
- It is all wrong.
- We can demonstrate it for you.
- We are not interested.
- We are doing quite a lot of SecurID installations and this is an issue. What shall we tell our customers?
- It is your problem.
- Ok, then we'll show them our report.
- Then we will sue.
- What do we tell our customers?
- It is your problem.
...
This was before Security Dynamics and SecurID was bought by RSA Security, and I got the impression economics was more important than both technology and security at this point.
I have no idea if the issues are corrected in the present versions of SecurID.
/By Mikael Q Kuisma