In techie circles bringing up the topic of security through obscurity is like bringing up religion or politics at a cocktail party where you don’t know anybody. It might go over really well, or you might find people calling you names that my friends in HR would chastise (or fire) me for printing in the blog.
Security through obscurity (STO – sorry, I am going to get tired of typing “Security Through Obscurity”) is the concept that you can be secure if you hide information. Anyone who has been in the military will probably know it better as “need to know” or “loose lips sink ships” or “don’t ask don’t tell”. OK, maybe not the last one.
Anyway STO is like oxygen (without the little number 2 subscript) a little sustains you a lot will kill you. Everything in moderation… including moderation! Sometimes security through obscurity is the perfect application of defense in depth, but not alone. You use STO when you don’t tell people your password and that is a really smart. When you are presented with a login screen and you get something wrong, a good site will only tell you that your username or password was wrong, not which one. That is security through obscurity (STO) as well. Recently I came across a very amusing failure to use STO where it would have been a low cost and reasonably effective application of the concept.
I recently bought a Lenovo X220 laptop. I love the odd little beast. It has a 12.5 inch screen, which is quite an unusual size. It is small enough to be very portable and large enough to see, but I really love having 3 USB ports intelligently placed so that no USB device can block another port! But, I digress…
A big part of security is having a good back up. Actually having multiple good backups so that if one fails you do have a backup plan (I’d apologize for the pun, but I really am not sorry). To those of us who work in security (and hundreds of millions of other people) this is a good idea, but the concept seemed to get lost somewhere at Microsoft and/or Lenovo. One of the first tasks I do when I get a new computer is to make factory recovery discs. Lenovo has a program that assists you in making your factory recovery discs so that if something catastrophic happens you can restore the system to the exact state it was in when you took it out of the box.
There is a strange bug in the Lenovo factory restore program, but thanks to the failure to hide something that could have been easily hidden I was able to bypass the bug, bypass the copy restrictions and make my legitimate backup discs. I’m not exactly sure what the bug is because I don’t know Lenovo’s intent. The factory restore has 3 options. You can make bootable media, you can make the restore discs, or you can make both. As long as you don’t make the restore discs you can make a gazillion bootable discs, but if you make the restore discs the program will not let you get to the point of making another bootable disc. The bug is either in denying you access to make boot discs or letting you make a gazillion of them in the first place.
Now on to where STO (remember, Security Through Obscurity) might have been a good idea for Lenovo.
I created the bootable “disc” on a thumb drive, but later decided I would like to also have a copy on a CD or a DVD as well as make an extra set of restore discs to keep in a separate location. Remember, data backup works best when you have redundancy. If one back up fails or gets destroyed then you retrieve your other backup. When I tried to make the second bootable disc the program said I could only have one copy of Windows. I called IBM and complained and they did send me a set of restore discs at no charge. I also started looking around and in the system restore folder I found a file called “service_done.ini”. Unlike all of the other files in the folder, the time date stamp was the same as when I made the system restore media. Inside the file it looked like this…
Hmm, the program worked when that file wasn’t there and stopped working after it appeared? Hmm, inside there appears to be a counter. What do you think that might mean? Maybe, just maybe this is how the program knows I already made a set of discs? So, I did the logical thing and moved the file. Lo and behold I could make the factory restore discs again!
It would have been really easy to make it far more difficult for a user to work around the one copy limitation of the program. I am not promoting piracy, you can simply make legal copies the DVDs you already made so you have multiple backups for legitimate purposes. The entire copy protection mechanism in this case is simply a waste of disc space and time and promotes ill will among law abiding customers. Yes, there is a place for copy protection and no you often do not want to spend much on it because it will be defeated, but it would have cost as little to have made a much more obscure and effective copy protection mechanism than the service_done.ini file.
I’d like to have stopped here, but there is also an important lesson about programming best practices in this story too.
Out of curiosity I decided to play around with the service_done.ini file a bit. Where it said “DONE=1” I changed the number 1 to 00335 and then ran the program again. I could make more copies again! I changed the value to 2 and the system would allow me to create more restore discs.
In this specific case there is no security problem, but this is the type of programming approach that leads to serious security problems. The developer either didn’t care (understandable for this specific app) or did not understand the real goal of the program. In this case you really are not trying to see if only 1 copy was made. You want to know if more than zero copies were made. The logic should not be “if done=1 then don’t let Randy make any more discs”, it should be “if done not equal to or less 0 then don’t let Randy make any more discs”. If DONE is equal to something less than 0 there’s a problem! The programmer only accounted for the situation where the file did not exist (make discs) and the situation where “DONE=1”, but there are other situations to account for as well. It is these unaccounted for situations that hackers eat for breakfast.
In a recent post about the Sony hacks I spoke about data validation. http://blog.eset.com/2011/05/24/back-to-the-basics-%E2%80%93-aka-not-sony-again The Lenovo program wasn’t validating data input. I actually put the word “Verboten” as the value for “DONE” and the program let me make discs. A failure to validate data leads to problems such as SQL infection attacks and buffer overflows. Even though this wasn’t a security problem for this application, as a developer you want to have a disciplined approach to writing code securely.
In all probability the one set restriction was a silly Microsoft mandate even though the factory restore program claims that the restore discs can only be used on my system. The truth is that it will only work on systems with the exact same BIOS as mine.
Thanks to Lenovo/IBM for the excellent example for teaching a little about STO and data input validation and also for the free factory restore DVDs! Now, if only I could remember where I put the first set of restore discs, but asset tracking will be another blog!
Director of Technical Education
Cyber Threat Analysis Center
ESET North America
Author ESET Research, We Live Security