Security Week 42: SHA-1 collisions, a real hack for routers, Android/Security/Gloom

Konstantin Goncharov explains the bottom line of tech giants’ epic fails in the new edition of cybersecurity news digest.

When find yourself caught in the eye of the storm, you might have problems understanding what has really happened. While stuck in a traffic jam, you would never know it happened because of an accident, until you reach the spot seeing two jet pilots whose wreckage occupied three lanes. Until then, you simply don’t have enough information to make a correct assumption.

It happens all the time in the infosec industry: this topic is complex and contains lots of details and peculiarities, and due to this complexity the results of certain research might have real leverage years in the future.

This week, our three top pieces of security news have nothing in common, besides meaningful sub-context. When you have no experience in the industry, you cannot properly evaluate the importance of some of the security events or might miss some critical details.

I will try, as hard as I can, to explain this importance with apprehensible examples, as sub-context is vague and flexible, so that anyone could see something different when assessing it. So, sit back and relax with this week’s edition of Security Week, titled Breaking Covers. As always, our Threatpost editorial staff handpicks the three most important news items of the week, which I ruthlessly comment. All the previous editions are available here.

The search for SHA-1 collisions got immensely cheaper
News. Predictions by Jesse Walker made three years ago. The new research which changed the take on the security of this algorithm.

Those who advanced in their Linux exploration a bit further than automatically setting up Ubuntu know that the system prompts one to carefully read instructions. I mean, I would, of course, first try to Google a doc with a sequence of commands, but in some cases everything would fail to work properly and then would totally break down.

This news is similar: without an at least short orientation, the topic is not that easy to apprehend. Whereas it is, by far, the most complex topic in our Security Week series to date, I would dare to explain what it means in simple words.

Well, I'll try something like this

Well, I’ll try something like this

SHA-1 is a cryptographic hashing algorithm. This algorithm could be fed an unlimited sequence and produce a 160-bit piece of data, which then can be used to identify the initial data array. This is impossible if you don’t have that initial data array – otherwise you cannot simply restore the information from the hash, as you cannot turn minced meat into a whole steak.

More precisely, it SHOULD be impossible, even if you have a password like ‘123456’. There are two requirements to any of such algorithms: the impossibility of getting the initial data if you only have the hash, and the impossibility of getting a match to the data array so they both have the same hash.

To be precise, there IS a possibility to do both. The thing is that it means so much heavy lifting computing that it’s not even worth a try. So, you might buy a supercomputer and entrust it with the task of breaking the cipher. Then, 240 years later, it says the answer is 42, but at the moment you wouldn’t care less.

Yet, there’s the rub. First, PCs continue to gain more and more computing power. Second, researchers are constantly seeking bypasses to break cryptographic algorithms. It’s way simpler to find a collision to an encryption algorithm rather than decrypt the initial data array.

Meanwhile, SHA-1 is used in different encryption systems and authorization solutions, and its task is to ensure the data of two different agents match. Once two or more data arrays with the same hash are discovered in a moderately less cumbersome and costly process, the algorithm is not reliable anymore.

Allow me to stop here to spare you an unbearably hard-core AP Calculus lecture: Here’s the bottom line: researchers compile an algorithm to search for a collision, and the algorithm is capable of finding the collision with less effort than the ordinary brute force method. Or, more precisely, we talk now about Birthday attack.

Well, those simple words of mine are not that simple, after all.

Researchers then improve the algorithm and thus reduce the number of decrypt operations. As a result, the attack that previously would take 240 years could bring success in just 120 years, and then in just 12 years, and then in just 2 years. So, as soon as you find out the attack would take not two centuries but two months, you can start worrying.

So the story is as follows: Three years ago a cryptographist from Intel, Jesse Walker, assumed that by 2015 a practical SHA-1 collision attack would take 211 server-years (a weird typical estimation unit based on a typical server).

Thanks to cloud services like Amazon EC2 you might even calculate a cash equivalent of the infrastructure necessary to crack the hash. With $700,000 available, you can, theoretically, get the method of forging a digital signature in a relevantly short time.

But this estimation dates back to 2012. That means even then SHA-1 was not rendered that reliable, but only rich governments actors could have afforded to crack the algorithm.

Quite understandably, such organizations aren’t in a hurry to publicly report their success in battling cryptography. So, it’s paramount now to assess when this ‘tool’ becomes available to some deep-pocketing cybercriminals that surely exist.

security-week-42-dog

Recently, a group of researchers from universities in the Netherlands, Singapore and France published a white paper covering the methods of optimizing the process needed to calculate the collision. Would an attacker be armed with their findings, the practical collision attack would cost just $75,000 (In Amazon’s units) and would take just 49 days.

It could happen even quicker, provided sufficient funds. Bruce Schneier, a renowned cryptographist, assumes that the 2012 estimation considered only Moore’s Law, whereas it never took into account the improvement of the attack algorithm (like using GPUs for computation due to their high processing power and affordability). It’s impossible to present an accurate estimation of the effects the algorithm optimization would bring.

Here comes the traditional question: do this research and this estimation practically mean a real threat? Well, not necessarily. How are such ‘vulnerabilities’ exploitable in the wild? There is a nice example based on a less secure MD5 algorithm: we take two different files (in this case, photos of rock stars), perform a series of modifications on one of them and, as a result, get absolutely identical hashes for two absolutely different images.

Are there any real-life examples? A notorious cybercampaign, Flame, used this method to sign a malicious file with a valid (at that time) Microsoft digital certificate. Or, more precisely, the signature was forged, but the hashes matched. Independent estimations prove that such trick, which exploited an even less reliable algorithm, would have cost an actor from $200,000 to $2,000,000, which is damn expensive!

So, what about SHA-1? The algorithm has been around since 1995. Even back in 2005, it was clear the algorithm was not the most reliable of all. Considering the latest estimations, practical SHA-1 collision exploits are still a very distant future, whereas SHA-1 is steadily eliminated as an end-of-life technology and replaced by more reliable hashing algorithms.

By 2017 key browser developers will have deprecated SHA-1. It is time they sped up: since the costs of a potential collision attack went down from $2,770,000 to as low as $100,000 in just three years, what could happen in a year’s time?

Meanwhile, the research of SHA-1 vulnerabilities is of pure scientific value. Figuring out potential consequences is a process as vague as finding out that a human flew to space based on a single news stating “On April 12, 1961, 250 tons of rocket fuel combusted above a Kazakhstan desert.” We’ll live, we’ll see.

A fun fact: the proper name of what we call ‘hash’ is ‘digest’ or ‘message digest’. As it turns to be, you have just read the digest about the digest. Hail recursion!

Vulnerability in Netgear routers is practically exploitable
News. Description of the vulnerability.

A vulnerability was found in Netgear N300 routers. Here’s another hole in a router, again, – so different, yet looking quite the same. We have already discussed a couple of bugs in Belkin routers in one of our previous editions. But as for Netgear, the situation looks quite gloomy.

Let’s open the router’s web interface, type in the password (but a wrong one, since it’s not our router and we don’t know it). Then we are redirected to the Access Denied page. If you try to open the BRS_netgear_success.html page, you… would not get anywhere, either, but just for a couple of times. Once you try this trick several times, you succeed.

security-week-42-netgear

Of course, you ‘d better be logged in the local network which makes the venture harder. However, if the router feeds public WiFi in a café, there is no problem in getting inside the network. And if the owner, out of the blue, decided to open access to the web interface, everything gets tons easier.

By the way, does anyone know why the web access should be open to an outsider? And by that we mean the access to a router itself and not to some instances in the local network. I think there is absolutely no reason to do that and there are many reasons NOT to do that.

However, the situation with the Belkin router evolved quite lawfully: the vendor was notified, and in two months the company offered a beta of the new firmware. It seemed like everything was good, then the bad news broke: the vulnerability had been already been exploited in the wild.

Compass Security, a Swiss security company, discovered a rogue router with its settings changed: the DNS server did not belong to a service provider, as usual, but to God knows whom. That unknown agent received all DNS requests. The attack server, when researched, happened to have served over 10,000 hacked routers.

https://twitter.com/NETGEARhelp/status/653682920540999680

A fun fact: Compass Security tried really hard to get response from Netgear for quite a while. When the conversation finally happened, the company even got the beta of the new firmware to run a test. But then, out of the blue, a new player emerged – a company called Shellshock Labs, published their research without consulting anyone (which is bad).

Of course, it’s kind of cool to name a research company after a notorious bug in bash, but it does not override the ‘do no harm’ rule. However, the research by ‘shellshokers’ helped to understand where the bug came from. The firmware code makes it possible to get access to the web interface without a password just once, during the first launch. To disable this option, the flag should have been there, but it wasn’t. And yes, finally, the firmware was updated.

87% of Android devices are insecure
News. The researchers’ website, including the rating of device security by vendor.

security-week-42-lemur

No way! It never happened before and here it comes again! We are talking about another scientific research (thankfully, not as hardcore as the one about SHA-1). Researchers from University of Cambridge did a fascinating thing: They gathered data on 32 critical Android vulnerabilities, then selected 13 most critical ones and checks a massive amount of devices by different vendors to find out whether they are vulnerable.

Here’s how they did it: The developed the Device Analyzer app to gather telemetric data on the devices which participated in the experiment, including the OS version and the build number. Thus the researchers managed to accumulate data on over 20,000 smartphones.

By counterpoising the OS version and the vulnerability data, the researchers could evaluate the scale of the problem. That’s what they got:

security-week-42-vulneruble-android

The results were normalized to show that 87% of devices were susceptible to this or that critical vulnerability (in some instances, to more than one bug) at the certain time. Of course, we have to stress the word ‘potentially’: as we could see from the Stagefright story, even the most dangerous vulnerability cannot get maximum leverage due to practical limitations.

However, the researchers got even further and developed a scorecard to evaluate the level of ‘dangerousness’ among different vendors and called it FUM Score. It is based on the time it takes a vendor to react on the disclosure of a new bug and the time it takes to present a final patch.

The winners here are, of course, Nexus devices: they get security patches quicker than anyone. LG occupied the second position and Motorola is the third in this rating. Well, we can hardly call them winners, as all participants are, in fact, losers.

The scorecard takes into account the share of updated devices, which means that, besides a vendor issuing the patch, the user has to update the device, after all. The older the device, the worse: in a separate rating among the 2 to 3-year-old devices the scores are dreadful. Why is that so? The owners never update them, but still use them.

Well, the approach does contain a couple of debatable assumptions and a lot of guesswork, and the findings are somewhat expectable. The researchers say that one of their objectives is to motivate vendors improve the way they deliver security patches. What is important, though, is the means to see that the ecosystem cannot possible be 100% secure.

Whereas Android, dreadfully segmented, server the most suitable example of an insecure ecosystem, such are abundant. You may stand by your assumption that iOS is more secure, but the first story in our digest about, well, digest, proves that no system is 100% secure, due budget limitations. This is a vital element when choosing the security strategy.

What else happened:
Apple purged App Store of apps, which helped hackers to expose, hijack, and modify encrypted traffic via installation of root certificates – for adware blocking or worse things. As far as I understood, new apps with the same capabilities are no more. Why was it possible before then?

European Aviation Security Agency (EASA) disclosed a bug in ACARS – the system used for exchange between the aircraft and the ground station. It goes without saying that it’s quite simple to send a fake message via the system which does not presuppose any packet verification.

Of course, the vulnerability does not allow hijacking flight controls, yet it could be used to send a misleading message to pilots. The bug in ACARS was discussed (in various PDF files) as far back as 2013, but exclusively by security researchers; this time a regulatory body itself raised the issue. Good news!

Oldies:
Indicator-734

A dangerous resident virus. It infects .COM files as they are uploaded into the memory. The virus encrypts the beginning of the file using 10h bytes of BIOS. That means the files could be decrypted and run only on a computer running the same version of BIOS. If the beginning of the file cannot be decrypted, the virus blocks the operations of the file (running int 20h), having launched its counters before. Depending on the state of the latter (approximately once in an hour), the virus draws a red cross on the screen with the sign ‘VINDICATOR’ in the center. The virus hijacks int 1Ch, 21h.

Quoted from “Computer viruses in MS-DOS” by Eugene Kaspersky, 1992. Page 70.

Disclaimer: this column reflects only the personal opinion of the author. It may coincide with Kaspersky Lab position, or it may not. Depends on luck.

Tips

How to travel safely

Going on vacation? We’ve compiled a traveler’s guide to help you have an enjoyable safe time and completely get away from the routine.

Sign up to receive our headlines in your inbox
  • For all other countries