Slashdot Mirror
Protected Memory Stick Easily Cracked
Martin_Sturm writes "A $175 1GB USB stick designed to protect your data turns out to be a very insecure. According to the distributer of the Secustick, the safety of the data is ensured: 'Due to its unique technology it has the ability to destroy itself once an incorrect password is entered.' The Secustick is used by various European governments and organizations to secure data on USB sticks. Tweakers.net shows how easy it is to break the protection of the stick. Quoting: 'It should be clear that the stick's security is quite useless: a simple program can be used to fool the Secustick into sending its unlock command without knowing the password. Besides, the password.exe application can be adapted so that it accepts arbitrary passwords.' The manufacturer got the message and took the Secustick website offline. The site give a message (translated from Dutch): 'Dear visitor, this site is currently unavailable due to security issues of the Secustick. We are currently working on an improved version of the Secustick.'"
At least the manufacturer is doing the right thing and eating crow over this. Here in the US the company would probably have just sued the hackers under DMCA while continuing to sell the defective product.
Destroying the contents on a bad password attempt is crazy. Especially when you use very cryptic passwords. People tend to type wrong, hold the shift key down too long, not hold the shift key down when necessary. Sometimes I have to type my passwords two or three times before getting it right. Destroying important sensitive information because I accidentally typed it wrong is just plain stupid. These kind of technologies will only be a pain for people using them legitimately, and anyone who wants to hack to get the information will generally be able to find some way to get it, thus it is only extends the problems and provides no solutions.
...... Since there are a ton of these products out there. Does any third party verifiy that they are secure as they are claimed to be? Or are we truly at the mercy of the marketing spin that these companies put out?
This is my opinion. To make sure you don't steal it, it's covered by the DMCA.
The whole thing is just stupid. Oh where to start ...
....
- self destruct, great, so if you want to destroy someones data, just grab their memory stick and intentional use bogus passwords. Now that's brilliant. A MS with a builtin self DOS.
- No security support in hardware, just desolder the actual memory and stick it into your favourite $15 MS. Brilliant.
- So smug in their design they don't even encrypt the data. Outstanding.
- Software designed apparently by a 12 yo. Oh wait, a 12yo probably wouldn't have made it so dumb. Maybe it was a 6yo, were there identifiers named after Spongebob characters?
Actually, the bigger problem is that so many govt agencies approved of this thing, apparently, without it going through any type of remotely rigorous testing and verification. As much as our US govt agencies get ripped for doing stupid stuff, it's clear that they don't have the market cornered on such activity.
Hey, I have a secure self destructing bridge to sell to
Depends on how much trouble you'll get in if law enforcement agents manage to get at the data... seeing as how that's the only *possible* use I can imagine these things would ever be put to.
Proud neuron in the Slashdot hivemind since 2002.
Instead of low level commands such as SendToStick(), we could see routines such as GetWriteProtectState(), RefreshFileBrowser(), and the most significant one, VerifyPassWord().
Screenshot of debugging windows
Obviously, this routine caught most of our attention. We used the debugger to study it, and found that its result was passed to the main program using an EAX register. The debugger allowed us to place a breakpoint immediately after the call to VerifyPassWord(), upon which we entered a fictional password and changed the return value 0 in the register to 1.
Tell me again why we as Software Engineers are supposed to use descriptive method and variable names? Sure, it may be useful during testing/building/debugging/etc; nobody will argue that. However, if your "secure" product can be easily hacked due to the fact that you use descriptive class/variable/method names, maybe the practice should be reviewed.
Now in this particular case, there were other flaws with the design (all verification happening on the pc?!?) What happened here though is that the hackers were looking for a place to start by looking through a debugger. During that exploration they discovered a gaping security hole. I'm not saying that they wouldn't have found the design flaw to begin with -- I have no doubt that they would have. But maybe we should look to the security through obscurity methodology as an additional layer of protection.
Your sig(k) has been stolen. There is a puff of smoke!
Well, not completely. A spokesperson for the product is reported saying:
This is quite a different statement from the one made near the start of the article.
Funny part is, all they did was run the program in a debugger, put a breakpoint after the clearly labelled "VerifyPassWord" function, and change the return value from 0 to 1. Pretty embarassing. But the article went pretty easy on them after that. Really good read by the way.
They had added it to close a previous security problem I'd pointed out with their product that stored an internal customer id in a cookie to grant access to a web app - problem was, the customer id's were allocated sequentially, so anyone brute-forcing it would get access to all their customer data in minutes, including the adress books of the entire top management team.... base64 "encrypting" the customer id was supposed to prevent anyone from trying that trick again... I left that company pretty much as soon as I could..
I am also curious. . . What does the law in the Netherlands say regarding corporate mandates? Are Dutch corps allowed to put other things ahead of generating profit for shareholders?
-FL
the result is revolutionary, ultra safe and approved by the French intelligence service.
I think that says quite a lot for the French intelligence service. Unless they wanted an insecure device to be marketed as secure.... black helicopters at the ready.
Very simply, no. It increases the bar, but it doesn't make it any less readable. I spend my days with assembler code written by someone else, figuring out how it works and how it does what it does. You get an 'eye' for certain things. You start seeing certain things, how functions run, what functions do what, not by reading the code, just by looking at it. You start being able to interpret the return values of functions, you can 'feel' the code.
And those guys rarely leave any clues left in the code, often every single bit of string is encrypted layer after layer. There ain't much you get out of the code. And still it's not really 'hard' to read, despite runtime encryption of code and data.
I doubt that people who display this lack of skill could develop something similar to some of the gems of obfuscation software I had crawling over my desk the last few months. Functions give their meaning away by the way they look, especially when a stock compiler created the assembly. Certain things simply 'look' a certain way when a standard compiler assembled them. You don't need to know that this is going to compare strings, read files, mess with the registry or start a connection to somewhere, when a standard compiler created the code, glancing at it is usually enough to 'feel its vibes' (I'm lacking better words, it's really a matter of experience, IMO).
So no, stripping the symbols is hardly enough to make it any more difficult for experienced disassembly readers. It will certainly throw a few people who just started learning, but it won't matter much to a professional.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.