Posts Tagged ‘QOTW’

A few weeks ago, I was sat pondering nuclear bombs. To any of you who frequent the DMZ, this shouldn’t be much of a surprise, as it’s pretty much par-for-the-course for my imagination on a Wednesday night. I started thinking about the electromagnetic pulse released from a nuclear explosion, and how it might affect electronic devices. “But surely,” I thought, “a nuclear bomb would negate any interesting post-blast resilience implications by turning all local electronic devices into glowing dust!”. How wrong I was.

After a bit of research, I came across High-Altitude Nuclear Explosions (HANE). No, this isn’t the title of the latest Michael Bay movie, but rather the concept of detonating a nuclear bomb at an altitude greater than 30km. Whilst this might sound rather ridiculous, certain countries have actually done it. In the early 60s, the USA and Russia performed a series of HANE tests, in order to better understand the potential for anti-satellite weaponry. These tests showed that the electromagnetic pulse and ensuing radioactive fallout was capable of destroying or damaging satellites in space rather indiscriminately. The tests caused numerous satellites to fail after a short period of time, due to severe radiation damage. What’s really interesting about HANE, though, is that the explosion releases a giant electromagnetic pulse, without the hassle of re-enacting that dream scene from Terminator 2 where Sarah Connor’s skeleton is left clinging onto a chain-link fence.

To quote the Wikipedia article:

This high-altitude EMP occurs between 30 and 50 kilometers (18 and 31 miles) above the Earth’s surface. The potential as an anti-satellite weapon became apparent in August 1958 during Hardtack Teak (a HANE test). The EMP observed at the Apia Observatory at Samoa was four times more powerful than any created by solar storms, while in July 1962 the Starfish Prime test damaged electronics in Honolulu and New Zealand (approximately 1,300 kilometers away), fused 300 street lights on Oahu (Hawaii), set off about 100 burglar alarms, and caused the failure of a microwave repeating station on Kauai, which cut off the sturdy telephone system from the other Hawaiian islands.

That’s one hell of an electromagnetic pulse!

After I’d got over the initial excitement of learning that it is actually theoretically possible to sizzle microchips from space using nukes, I decided to post a question on Security SE. In short, I wanted to know how worldwide communications infrastructure, especially the Internet, was protected from such attacks. This is where our resident nuclear weapons “enthusiast” Thomas Pornin came in, with a wonderfully detailed answer.

It turns out that the Internet is, like a condom machine in the Vatican, amazingly redundant. Obviously not quite the same kind of redundant, but redundant nonetheless. If a network link goes down, packets are routed through other links. It’s a self-healing network. This means that you would have to knock out multiple inter-continental network links in order to cause severe disruption. Furthermore, it has plenty of redundant channels that are likely to still function after a large EMP:

• Point-to-point radio links (e.g. microwave)
• IP over Radio (e.g. AX.25)
• Satellites
• Optical fibre cable
• Free-space optical communication (e.g. laser links)
• Brian Blessed bellowing binary from a tall building.

An interesting issue with radio and satellite communication is temporary disturbance of the ionosphere. The electromagnetic pulse would cause electrons to be jiggled about in the upper atmosphere, creating areas of increased and decreased electron density. A lot of long-range radio communication relies on “bouncing” radio waves off of the ionosphere, which means that such communications are likely to suffer strong interference. Longer wavelength signals are likely to be disrupted more than short wavelength (GHz) signals, due to some interesting physics wizardry I won’t go into.

Of course, in the case of a real war, we’d have to worry about anti-satellite weapons knocking out communications too. Thankfully though, under-sea cables are shielded by a big blanket of water, which absorbs electromagnetic radiation. This is why submarines send up a radio mast or buoy. The good news is that our fastest and most reliable network links will actually end up being our most resilient, because they’re on the sea bed. Furthermore, optical fiber cable is not affected by electromagnetic induction, like copper wiring is. So, if all hell does break loose, the phat-pipes should still be able to serve you your daily dose of StackExchange! Yay!

But not everything relies on hardware interlinks. We also have to take into account the systems that facilitate the core functionality of the internet. An interesting example of this is DNS. There are thirteen root nameservers that facilitate the absolute top tier of DNS functionality. Without the root name servers, we wouldn’t be able to reliably translate domain names into IP addresses. Think of them as a set of mirrors for a global directory, where top-level domains (TLDs) are indexed. These entries point to other DNS servers, which point to other DNS servers, etc. We’re left with a large hierarchical map of DNS resolution. Now, whilst thirteen servers sounds rather flimsy, the actual number of servers involved is much larger. A neat technique called anycast allows multiple physical servers across the world to represent a single root name server. This is not the same as cloud computing, which is often touted as a panacea for uptime-critical solutions. Guess what? The cloud is not redundant! But I digress. In order to take down the entire DNS system, you’d need to nuke Japan, England, France, Germany, most of eastern Europe and the entire east and west coasts of America into oblivion. At that point, I don’t think the remaining radiation-resistant insects would be particularly interested in whether the DNS system is functioning or not.

The biggest threat HANE poses to our infrastructure is to our power grid. The world is coated with a mesh of power wiring, stretching over hundreds of miles of land. Since the cables are so long, and are very likely to cut through the magnetic lines of flux in a perpendicular manner, the induced currents could be massive. Local substations would burn out, street lighting would fry, circuit breakers would pop, and fuses would blow. Without power, our worries about communications infrastructure being disrupted would be rather pointless. The servers that host anything worth accessing would be down anyway, and it’d be likely that you couldn’t boot your PC or charge your laptop, due to lack of power. Even when sections of the power grid come back online, the demand would be massive, causing further outages and brown-outs.

So, how can we protect ourselves? Here’s a few ideas:

• Wrap everything important in a giant Faraday cage. Not exactly practical for power plants or datacenters, though.
• Ensure that significant chunks of the world’s communications infrastructure is built around trans-oceanic cables and optical links.
• Ensure that nation-critical services are distributed globally, with the ability to self-heal if remote systems become unreachable.
• Be prepared to switch to lo-tech communications in the event of such a disaster.

Perhaps the thing to take away from this analysis is that nukes are dangerous, and there’s not much you can do to prevent their aftermath. The best policy is to not detonate nukes at high altitude, or if possible, not to detonate nukes at all.

Nukes are bad, m’kay.

Liked this question of the week? Interested in reading it or adding an answer? See the question in full. Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com.

Carolinegordon asked Question of the Week number 29 to try and understand what risks are posed by giving developers admin rights to their machines, as it is something many developers expect in order to be able to use their machines effectively, but that security or IT may deny based on company policy.

Interestingly, for a question asked on a security site, the highest voted answers all agree that developers should be given admin rights:

alanbarber listed two very good points – developer toolsets are frequently updated, so the IT load for implementing updates can be high, and debugging tools may need admin rights. His third point, that developers are more security conscious, I’m not so sure about. I tend to think developers are just like other people – some are good at security, some are bad.

Bruno answered along similar lines, but also added the human aspect in two important areas. Giving developers and sysadmins can lead to a divide, and a them-and-us culture, which may impact productivity. Additionally, as developers tend to be skilled in their particular platform, you run the risk of them getting around your controls anyway – which could open up wider risks.

DKNUCKLES made some strong points on what could happen if developers have admin rights:

• Violation of security practices – especially the usual rule of least privilege
• Legal violations – you may be liable if you don’t protect code/data appropriately (a grey area at best here, but worth thinking about)
• Installation of malware – deliberately or accidentally

wrb posted a short answer, but with an important key concept:

The development environment is always isolated from the main network. It is IT’s job to make sure you provide them with what ever setup they need while making sure nothing in the dev environment can harm the main network. Plan ahead and work with management to buy the equipment/software you need to accomplish this.

Todd Dill has a viewpoint which I see a lot in the regulated industries I work in most often – there could be a regulatory requirement which specifies the separation between developers and administrator access. Admittedly this is usually managed by strongly segregating Development, Testing, Staging and Live environments, as at the end of the day there is a business requirement that developers can do their job and deliver application code that works in the timelines required.

Daniel Azuelos came at it with a very practical approach, which is to ask what the difference in risk is between the two scenarios. As these developers are expected to be skilled, and have physical access to their computers, they could in theory run whatever applications they want to, so taking the view that preventing admin access protects from the “evil inside” is a false risk reduction.

This question also generated a large number of highly rated comments, some of which may be more tongue in cheek than others:

The biggest risk is that the developers would actually be able to get some work done. Explain them that the biggest security risk to their network is an angry developer …or just let them learn that the hard way. It should be noted that access to machine hardware is the same as granting admin rights in security terms. A smart malicious agent can easily transform one into the other. If you can attach a debugger to a process you don’t own, you can make that process do anything you want. So debugging rights = admin

My summary of the various points:

While segregating and limiting access is a good security tenet, practicality must rule – developers need to have the functionality to produce applications and code to support the business, and often have the skills to get around permissions, so why not accept that they need admin rights to the development environment, but restrict them elsewhere.

This is an excellent question, as it not only generated interest from people on both sides of the argument, but they produced well thought out answers which helped the questioner and are of value to others who find themselves in the same boat.

Liked this question of the week? Interested in reading it or adding an answer? See the question in full. Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com.

What is the QotW?

At nearly 3,500 questions we have a wide variety of topics, answers and styles, and in general when someone comes to the site they are looking for answers to a specific problem, or to give answers to questions in their field so they may not see the vast majority of questions. Question of the Week posts on meta.security.stackexchange.com allow the community to vote for their favourite question to be discussed on the blog. This blog itself is quite young – we have 44 posts published, of which 24 are QotW posts.

Why do we do it?

On the Internet, getting visitors to your site is the key metric – QotW is another avenue to get what we do in front of a wider audience. Our QotW blog posts link to questions, answers, community members and external sites where relevant in order to add context and depth, showcasing our site, and this is demonstrated in our referrer stats: we get good traffic from slashdot, reddit, facebook, twitter as well as Bruce Schneier and Dan Kaminsky’s blogs, and even explainxkcd.com so we are doing something right and gaining visibility.

How do we do it?

@Iszi’s answer here lists the process in detail, but to summarise:

We post a QotW meta question on a Friday to invite ideas for the following week. In order to avoid dupes, we maintain a list of previous questions featured on the blog, as well as those which have been proposed but not yet published.

By Tuesday we have topic and author decided (typically individuals volunteer on our chat room, the DMZ - feel free to become a volunteer, we can add you as a contributor role on the blog site.)

The administrators manage the workflow planning through a Trello workspace.

QotW posts aren’t expected to be in depth treatises so drafts are ready by Thursday morning so they can be reviewed in time for a midday Friday publication (we’ve gone with UTC timing for this schedule as we have members from Australia to west coast USA)

Why should you contribute?

First, and most importantly, because you want to. You’ve seen something interesting happening on the site, or have an interesting topic you want to cover and you’d like to share it with the world.

Did we mention it is a nice addition to your careers.stackoverflow.com or LinkedIn profile?

In addition, you help grow the community you are a member of (now over 8000 individuals – a good blog post can more than double the rate of new users joining that day). Your words and name will be attracting the up and coming security experts of tomorrow.

We welcome all contributors to the blog, and the light touch of the QotW posts is a relatively easy way to start security blogging. Seasoned reviewers will be more than happy to assist.

Liked this post? Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com.

This week’s question of the week was asked by user jtnire who was asking a question very near and dear to those security professionals who came out of networking or systems backgrounds. He was doing some network design and came across a classic statement that, “VLANs are Not a Security Tool”.

As of this writing, jtnire had not accepted any answers, however user Rory McCune was leading the pack of answers. Rory focused primarily on the classic human problem of misconfiguration, particularly easy when we’re talking about typing Gi/0/4 when you meant Gi/1/4, as opposed to plugging a cable into the wrong port. He also specifically called out VLAN Hopping, which can abuse a misconfiguration to allow a malicious user access to a non-authorized VLAN.

User and moderator Rory Alsop, speaking from an audit perspective, expanded on what the other Rory mentioned and focused more generally on what would make him double-take. He pointed out that VLANs are generally used for cheap network segmentation and that if you’re using them for as a security tool, then you probably want to do it right and use a physically isolated network instead.

Jakob Borg came in with a completely different approach. He explained that, as an ISP, VLANs are a crucial component of their environment and when done right can be a very powerful tool from both a security and service prospective. User jliendo largely agreed with Jakob that configuration is king, and when configured properly is an excellent tool in your security arsenal. He also went into more technical detail about some of the possible attacks against VLANs and how they can be mitigated.

In this author’s opinion this is a fantastic question as VLANs are becoming an extremely common mechanism for network isolation. The answers also did a great job of coming at the problem from all manner of angles, from external auditors to in the trenches technicians.

Liked this question of the week? Interested in reading it or adding an answer? See the question in full. Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com.

This weeks question of the week was asked by user Yoav Aner, who wanted to understand the legal and ethical concerns of executing an attack on a web site which carried a notice inviting attacks. Yoav specifically wanted to know what, if any contractual implications there were and if it were not specified, how far would be too far. This spun off into two further questions - What security measures to have before openly allowing security researchers to hack your site and What security concerns should one bear in mind when hacking open-invitation websites? so this post will look at all three.

Before we start, I must re-iterate: we are security professionals here, not lawyers, so if in doubt, consult a lawyer.

Legal and ethical concerns:

The answer Yoav accepted was provided by Rory McCune, who raised the point that ultimately, a no holds barred approach is extremely unlikely to be acceptable in any circumstance. Rory highlighted the importance of ensuring the page in question was written by the administrators of the site, as opposed to being supplied through user content. Clearly, unless it is clear the page was written by someone with the authority to make that kind of invitation, attacking it would definitely be hostile.

Another excellent point raised in this answer was that some companies actively invite finding bugs in their web sites and products, provided you follow a number of guidelines. More on this can be found in the answer itself.

Finally, Rory touched on what many people may forget – although the website may invite attempted break-ins, it may actually be illegal where you are even to make the attempt.

Our next answer was provided by Security moderator, user and blogger Rory Alsop. According to Rory, one problem when dealing with this kind of issue is that no test cases have yet passed through the courts – so until they do, it’s unlikely any precedent has been established for dealing with these kinds of issues. Rory also raised the criminal activity point again. Always understand that the law of your country/jurisdiction still applies.

Next up, Rory explained that during a penetration test a contract established for the work may include rules about what should happen, how far a test may go, who should be notified if a vulnerability is found etc. Even with this safeguard, there is still the potential for legal action should something break. Rory advised logging absolutely everything that was going on so as to have proof of actions.

When applied to the website scenario, Rory pointed out that in this case there is no signed contract establishing this understanding, just an implication of one which neither party is legally bound to.

That is all for answers on this question. I tend to miss questions on ethics on the main site, so writing them up is actually quite interesting. As such, I am going to summarise the key points below:

1. The rules of engagement are not well established. Assuming a “feel free to hack this message” we have no idea to what extent that is actually what they mean. By contrast, penetration testing is usually better scoped.
2. The author of the page might not have the authority to make such an invitation. As I was reading this, I did wonder – if this is a shared host, the administrator of the site is a different person from the company who owns and maintains the box. So even though the site author can put up this message, they’re not actually entitled to make that call (and it probably violates the ToS on their hosting package).
3. It may be illegal to engage in the act of attempting, whether or not the site in question has given you permission.
4. Some sites actively encourage hunting for bugs.

Security concerns when hacking open-invitation websites:

Iszi raised the following worries on his question

• The site could be a honeypot, run by government or other entities looking to gather information about active (or would-be) hackers.
• The site could be set up by a black-hat as a honeypot to gather a list of interesting, hackable amateurs to target.
• A third-party black-hat could potentially access the site’s logs and farm them for data about interesting, hackable amateurs to target.

Lucas Kauffman confirmed that he had a school project where he faked an open sendmail relay and

just piped all the incoming emails to a python script that got all the destinations out, generating my own spamlist. I think in the end after about 3 weeks I had close to 300.000 different email addresses.

Rory Alsop focused on the reputational and professional risks, as the host of the site will be able to see everything you did in their logs…do you ever mistype commands, use dir instead of ls, accidentally stray outside the scope of the test? This will be recorded and could negatively impact you.

Think about what you are divulging when hacking a website….

• Your methodology
• Your tools
• Your mistakes?
• etc

Finally – Yoav also asked a question focusing on the other side,

What security measures should I have in place before inviting people to hack my website?

Ttfd’s answer went into some considerable detail on the practical logistics – how you think about the problem is probably as important as actually implementing security in this situation:

1. Do you have the money to do that?
2. Do you have the resources? (servers, security teams and etc)
3. How far can you limit the damages a hacker can make to your system? I.E. If a hacker hacks into your server what access will he have ? Will he be able to connect to your database and retrieve/store/update data? Is your data encrypted ? Will he be able to decrypt it? (and so on)
4. Can your security team find how a hacker exploited your system?
5. Does your security team have the skills to fix problems that may occur ?
6. Probably many more questions that you need to ask and answer before you decide.

M15K gave a summarised answer

I can’t imagine very many positive scenarios in declaring open season on you’re front door will result in something useful. But let’s say you do, and you do get some positive feedback. Are you and your security team in a position to remediate those vulnerabilities?

Interesting stuff! All in all, this looks like a relatively risky business on both sides, so core to the decision must be a full understanding of the risks, and how these match to your risk appetite. If you are hosting such a site, you may get some valuable information into attack techniques, but you need to protect yourself from an escalation from the attack environment to your own systems. If you are testing the site, think about the risks you may be facing, and plan accordingly.

Liked this question of the week? Interested in reading it or adding an answer? See the question in full. Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com. 

Asked over on Programmers in January, this question is our 5th highest rated of all time, so it’s obviously resonating with our community.

With businesses the world over reliant on the accuracy, availability and integrity of IT systems and data this type of request demonstrates not only unethical behaviour, but a willingness on the part of the boss to sacrifice the building blocks used to ensure their business can continue.

Behaviour like this, if discovered by an audit team, could lead to much wider and deeper audits being conducted to reassure them that the financial records haven’t been tampered with – never mind the possible legal repercussions!

Some key suggestions from our community:

MarkJ suggested getting it in writing before doing it, but despite this being the top answer, having the order in writing will not absolve you from blame if you do actually go ahead with the action.

Johnnyboats advised contacting the auditor, ethics officer or internal council, as they should be in a position to manage the matter. In a small company these roles may not exist, however, or there may be pressure put upon you to just toe the line.

Iszi covered off a key point – knowing about the boss’s proposed unethical behaviour and not reporting the order could potentially put you at risk of being an accessory. He suggests not only getting the order in writing, but contacting legal counsel.

Sorin pointed out that as getting the order in writing may be difficult, especially if the boss knows how unethical it is, the only realistic option may just be to CYA as best you can and leave quietly without making a fuss.

Arjang came at this from the other side – perhaps the boss needs help:

This is not just a case of doing or not doing something wrong cause someone asked you to do it, it is a case of making them realize what they are asking

I am pretty cynical so I’m not sure how you’d do this, but I do like the possibility that the best course of action may be to provide moral guidance and help the boss stop cheating.

Most answers agree on the key points:

• Don’t make the requested changes – it’s not worth compromising your professional integrity, or getting deeper involved in what could become a very messy legal situation.
• Record the order – so it won’t just be your word against his, if it comes into question.
• Get legal counsel – they can provide advice at each stage.
• Leave the company – the original poster was planning to leave in a month or so anyway, but even if this wasn’t the case, an unethical culture is no place to have your career.

The decision you will have to make is how your report this. At the end of the day, a security professional does encounter this sort of thing far too regularly, so we must adhere to an ethical code. In fact, some professional security certifications, like the CISSP, require it!

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.

ZM15 asked this interesting question just before Christmas over on Superuser. It came over to Security Stack Exchange for some security specific input and I was delighted to see it, as I have done a fair bit of work in the practical elements of securing communications – so this blog post may be a tad biased towards my experiences.

For those not in the know, Powerline ethernet is a technology which allows you to transmit ethernet over your existing mains wiring – which is very useful for buildings which aren’t suitable for running cabling, as all you need to do is pop one of these where you want to connect a computer or other ethernet enabled device and they will be able to route TCP/IP packets. There are some caveats of course, the signal really only works on a single phase, so if you have multiple phases in your house the signal may not travel from one to another, although as DBasnett commented, to get around this, commercial properties may inject the signal deliberately onto all phases.

 Early Powerline adapters had very poor signal quality – noise on the mains caused many problems – but since then the technology has improved considerably, partly through increasing the signal strength, but also through improving the filters which allow you to separate signal from mains.

This is where the security problem lies – that signal can travel quite far down wires, and despite fuse boxes offering some resistance to signals, you can often find the signal is retrievable in the neighbour’s house. Damien answered:

I have experienced the signal bleed from my next door neighbor. I … could identify two other powerline adapters using the same network name. I got anywhere between 10 to 20Mbps of throughput between their adapters and mine. I was able to access their router, watch streaming video and see the computers on the network. I also noticed they had gotten IPs on my router also.

This prompted him to enable security.

Tylerl gave an excellent viewpoint, which is as accurate here as it has ever been:

Many of the more expensive network security disasters in IT have come from the assumption that “behind the firewall” everything is safe.

Here the assumption was that the perimeter of the house is a barrier, but it really isn’t.

Along even weirder lines, as is the way with any electrical signal, it will be transmitted to some degree from every wire that carries it, so if you have the right equipment you may be able to pick up the traffic from a vehicle parked on the street. This has long been an issue for organisations dealing in highly sensitive information, so various techniques have been developed to shield against these transmissions, however you are unlikely to have a Faraday cage built into your house. (See the article on TEMPEST over on Wikipedia or this 1972 NSA document for more information)

For similar wireless eavesdropping, read about keyboards, securing physical locations, this answer from Tom Leek and this one from Rook - all pointing out that to a determined attacker, there is not a lot the average person can do to protect themselves.

Scared yet?

Well, unless you have attackers specifically targeting you, you shouldn’t be, as it is very straightforward to enable security that would be appropriate for most individuals, at least for the foreseeable future. TEMPEST shielding should not be necessary and if you do run Powerline ethernet:

Most Powerline adapters have a security option – simply encryption using a shared key. It adds a little overhead to each communication, but as you can now get 1Gb adapters, this shouldn’t affect most of us. If you need >1Gb, get your property wired.

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.

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.

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:

1. Disk Degaussing
2. 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.

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:

1. 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.
2. 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!