Archive for February, 2012
QotW #19: Why can’t a password hash be reverse engineered?
Are you a systems administrator of professional computer systems? Well, serverfault is where you want to be and that’s where this week’s question of the week came from.
New user mucker wanted to understand why, if hashing is just an algorithm, it cannot simply be reverse engineered. A fair question and security.SE as usual did not disappoint.
Since I’m a moderator on crypto.se this question is a perfect fit to write up, so much so I’m going to take a slight detour and define some terms for you and a little on how hashes work.
A background on the internals of hash functions
First, an analogy for hash functions. A hash function works one block of data at a time – so when you hash your large file, the hash function takes so many blocks (depending on the algorithm) at once. It has an initial state – i.e. configuration – which is why sha of nothing actually has a value. Then, each set of incoming blocks alter those values. (Side note: collision resistance is achieved like this).
The analogy in this case is like a bike lock with twisty bits on. Imagine the default state is “1234” and every time you get a number, you alter each of the digits according to the input. When you’ve processed all of the incoming blocks, you then read the number you have in front of you. Hash functions work in a similar way – the state is an array and individual parts of it are shifted, xor’d etc depending on each incoming block. See the linked articles above for more.
Then, we can define input and output of two things: one instance of the hash function has inputs and outputs, as does the overall process of passing all your data through the hash function.
The answers
The top answer from Dietrich Epp is excellent – a simple example was provided of a function – in this case multiplication – which one can do easily forwards (O(N^2)) but that becomes difficult backwards. Factoring large numbers, especially ones with large prime factors, is a famous “hard problem”. Hash functions rely on exactly this property: it is not that they cannot be inverted, it is just that they are hard.
Before migration, Serverfault user Coredump also provided a similar explanation. Some interesting debate came up in the comments of this answer – user nealmcb observed that actually collisions are available in abundance. To go back to the mathsy stuff – the number of inputs is every possible piece of data there is, whereas for outputs we only have 256 bits of data. So, there are many really long passwords that map to each valid hash value, but that still doesn’t help you find them.
Neal then answered the question himself to raise some further important issues – from a security perspective, it is important to not think of hashes as “impossible” to reverse. At best they are “hard”, and that is true only if the hash is expertly designed. As Neal alludes to, breaking hashes often involves significant computing power and dictionary attacks, and might be considered, to steal his words, “messy” (as opposed to a pretty closed-form inverted function) but it can be done. And all-too-often, it is not even “hard”, as we see with both the famously bad LanMan hash that the original poster mentioned, and the original MYSQL hash.
Several other answers also provided excellent explanations – one to note from Mikeazo that in practise, hash functions are many to one as a result of the fact there are infinite possible inputs, but a fixed number of outputs (hash strings). Luckily for us, a well designed hash function has a large enough output space that collisions aren’t a problem.
So hashes can be inverted?
As a final point on hash functions I’m going to briefly link to this question about the general justification for the security of block ciphers and hash functions. The answer is that even for the best common hashes, no, there is no guarantee of the hardness of reversing them – just as there is no cast iron guarantee products of large primes cannot be factored.
Liked this question of the week? Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com.
QotW #18: How can we destroy data on a hard drive?
Rather than focus on a specific question this week, we have 9 questions related to the destruction of data, 5 of which are specifically interested in destroying hard drives, as in this modern age where everything is recorded, there are good reasons for ensuring data is deleted when required.
So this post will concentrate on destroying the the drive itself. For the deletion of data from a storage device, have a look at our blog post for Question of the week number 4: How can you reliably wipe data from a storage device?
Matthew Doucette asked simply: How do you destroy an old hard drive?
To which Scott Pack produced the following incredibly detailed answer:
When it comes to drive destruction you typically see one of two main fields:
- Disk Degaussing
- Physical Destruction
Degaussing
Degaussing used to be the norm, but I am not such a big fan. On the plus side it is fast, you’ll normally just dump the disks on a conveyor belt and watch them get fed through the device. The problem is auditability. Since the circuitry is rendered wobbly, you won’t be able to do a spot check of the drives and verify that the data is gone. It is possible, with some level of probability unknown to me, that data could still exist on the platters. Retrieving the data would, without question, be difficult, but the fact still remains that you cannot demonstrate the data is actually gone. As such, most companies now will actually be doing physical destruction.
Physical Destruction
At the low end, say a small box of drives at a time, you’ll have hard drive crushers. They’re often pneumatic presses that deform the platters beyond useful recognition. At the risk of supporting a specific product, I have personally used this product from eDR. It works well, and is very cathartic.
At a larger scale, say dozens or hundreds of disks, you’ll find large industrial shredders. They operate just like a paper shredder, but are designed to process much stiffer equipment. The mangled bits of metal that are left over are barely identifiable as hard drives.
At an even larger scale you can start looking at incinerators that will melt the drives down to unidentifiable lumps of slag. Since most electronics can produce some rather scary fumes and airborne particulates, I would not recommend doing this on you own. No, this is not a good use of your chiminea.
Manual Dis-assembly
If you are dealing with one or two drives at a time, then simple dis-assembly might be sufficient. Most drives these days are largely held together with torx screws, and will come apart with varying levels of difficulty. Simply remove the top cover, remove the platters from the central spindle. Taking a pocket knife, nail file, screwdriver, whatever, have fun scoring both surfaces of each platter. Then dispose of the materials appropriately. I cannot speak to how recoverable the data is afterwards, but it is probably sufficient. The biggest thing to keep in mind is that while most desktop hard drive platters are metal, some are glass. The glass ones shatter quite extravagantly.
Additional Considerations
Before you decide on a destruction method, make sure to identify what kind of data is stored on each device and treat it appropriately. There may be regulatory or legal requirements for information disposal depending on what data is stored on the disk. As an example, see section 8-306 of DoD 5220.22-M.
For hard drive destruction, DoD 5220.22-M section 8-306 recommends: “Disintegrate, incinerate, pulverize, shred, or melt”
All that being said, performing a single pass zero wipe is probably sufficient for your purposes. Modern research indicates that modern hard drives are largely immune to the “magnetic memory” problem we used to see on magnetic tape. I would never bother doing anything more on a household drive unless the drive itself was exhibiting failures
Ryan M asked a very similar question – What is the best method of retiring hard drives?
And Scott also gave these 2 excellent points in his answer:
Electrical Scrambling
In the olden days when you had a room packed with tape there were few things better than a big honkin’degausser for making sure that you knew what left the room. As hard drives supplanted tape, their use simply got transferred to the new medium. The biggest advantage to using a degausser to take care of hard drives is speed. Just pass a box through the unit, ignore the jiggling in your fillings, and walk away with clean drives. The downside is the lack of ability to audit data destruction. As discussed in the Wikipedia article, once a hard drive is degaussed, the drive is mechanically unusable. As such, one cannot spot check the drive to ensure cleanliness. In theory the platters could be relocated to a new device and we cannot state, categorically, that the data will not be accessible.
Wanton Destruction
This is without question my favorite. Not only because we demonstrate, without question, that the data is gone, but the process is very cathartic. I have been known to take an hour or so, dip into the “To Be Destroyed” bin, and manually disassemble drives. For modern hard drives all you need is a torx set and time (possibly pliers). While one will stock up on their magnet collection, this method of destruction is very time consuming. Many companies have developed equipment specifically for hard drive destruction en-masse. These range from large industrial shredders to single unit crushers such as this beauty from eDR. I have personally used that particular crusher, and highly recommend it to any Information Security professional who has had a bit of a rough day.
I’m thinking if I ever need to destroy hard drives, I’ll either blow them up / give them to my kids / use them for target practice or ask Scott to have fun with them.
Dan Beale points out that exactly what approach you take depends on:
- how sensitive is the information
- how serious are the attackers
- do you need to follow a protocol
- do you need to persuade other people the data has gone
Auditability is essential if you are susceptible to regulations around data retention and destruction, and for most organisations this will be essential around regulations such as the Data Protection Act 1998 (UK), GLB or HIPAA (US) and others.
QotW #17: What would one need to do in order to hijack a satellite?
Slightly later than officially planned, question of the week number 17, a weekly feature on security stack exchange is a rather unusual but very interesting choice. We’ve featured it by community votes – and because it’s an interesting study of “how to think about security”.
So, without further ado, Security.SE member Incognito asked: What would one need to do in order to hijack a satellite?.
I did warn you! Well, never fear, it turns out our members know exactly how to do it! So without further ado:
Overview
In terms of radio communications security, most satellite communications systems are repeaters, accepting communication from the highest strength incoming signal at will. Most satellites then contain a command module to order the satellite to perform certain actions as necessary. Due to the highly custom nature of individual satellites, the commands that are accepted and the security for them is highly variable, so there’s a lot of potential for exploitation. As one of our answerers puts it:
When it comes to satellites, the word general does not apply.
Legal Concerns
As a result of the wide variety of frequencies and power requirements in use, chances are, attempting to send commands to a satellite are likely to violate local radio laws – as such, we do not recommend it (although we find the study of security very interesting, all the same).
Finding and talking to a satellite
Clearly, if you’re going to communicate with a satellite, you need equipment with sufficient power and range. You’ll need to be aware of the carrier frequency, the maximum satellite range, the data rate and satellite transmitter power. The location and altitude of satellites also matters – some are geostationary and as such are always in range, while others orbit and may only be in range for a specific period of time. Directional antennas with tracking motors will help an awful lot if the satellite changes position at all. Our answers provide even more detailed radio advice and links, so if you’re interested in your radio, do have a read!
Taking control of a satellite
There are several means by which you can take control of a satellite:
- Direct comms: If you have identified your target satellite, the most obvious method would be to communicate directly with it, sending it the commands you desire. Depending on the satellite you target your options will vary. You’ll need to be aware of the protocol and options available to you.
- MITM: One option for hijacking a satellite is to identify its command and control – the ground station – and intercept its communications. If you can afford to rent a small plane and can fly it over the site, possibly allowing you an advantage.
Doing it legally
It may be possible to purchase satellite time, depending on who you ask – and as such it may be possible to legitimately control a satellite, even if only for a brief period!
The expensive way
Many of the answers given focused on the radio communication protocols – however, Security.SE member and former moderator Graham Lee highlighted the physical security of satellites as a major concern – the only problem being the cost of getting into space. If you can, being able to nudge the satellite is enough to deny service by altering the antenna direction – you may be able to exploit it in other ways, whilst you’re up there. Of course, you don’t need to go up there yourself necessarily – a rocket will do the job adequately well and apparently doesn’t even need explosives!
Summary
Satellite security is an interesting area with many concerns that has perhaps been overlooked in our focus on the security of online stores and the like. Thankfully, people are looking at the security of communications systems that rely on satellites!
This QotW writeup relied on answers from Jeff Ferland, this.josh and Graham Lee primarily. Thanks to all our answerers on this particular question for providing their insights!
Can you improve on these answers? Feel free to visit the question and provide additional detail!