Un-patched Systems
https://www.cnet.com/news/most-android-users-running-outdated-security-patches-report-says/
An article on March 23, 2017 from C|Net reports that 71% of Android users on major U.S. cellular carriers are running phones with outdated security patches. This is an astonishing number. Unfortunately, it is not a surprising number.
Software updates have become a required component of using any device that has software in it. Bugs and vulnerabilities are discovered regularly in software, and any product needs a way to update the software running on it. However, the mechanism to update products over the years has remained largely unchanged.
I can think of four major categories of software update strategies for products:
1) A software update is silently released on a web site, requiring the user to look for it.
2) The user is notified of an update when they log into the administrative interface of the product.
3) The user is notified of an update on one of their primary user interface devices.
4) The product refuses to operate until it is updated.
There are probably a few cases that don’t fit into these four, but they are rare. I could argue that in 2017, options 1 through 3 are unacceptable. End users are not qualified to make determinations as to which security patches they should apply and when. Furthermore, in 2017, most devices are always connected to the Internet one way or the other. Automatic updates forced by the product manufacturer are a lot easier to accomplish today. In the case of an Android cell phone, the device by its very nature is almost always connected.
Gaming machines like the Sony Playstation already enforce this dynamic. When a software update is available for this device, online gaming and streaming video no longer function until the user agrees to install the software update, assuming it wasn’t already automatically installed for them. When can we expect the same level of security awareness from the rest of our software and devices?
Repetitive nature of problems
Working in the Information Security industry, I follow as much information as I can on the attacks and vulnerabilities that occur in our industry. Sometimes these attacks occur as a result of new or unique attack on a product or technology. However, this is usually not the case. We see the same vulnerabilities, and the same basic attacks utilized over and over again.
At some point, we as an industry have to get tired of solving the same problems. We often suggest the same solutions to these problems, even though they don’t fix anything. I’m not saying they don’t fix the specific problem, but they do nothing to address the entire category of problems.
For example, in 2008 Bruce Schneier wrote an article published in The Guardian entitled “Passwords are not broken, but how we choose them sure is.”
https://www.theguardian.com/technology/2008/nov/13/internet-passwords
In that article, he explains that the most common password used to be “password”, but now that many websites are requiring at least one number in your password, the most common password was then “password1”. This was joined by other gems like “123456” and “qwerty”. In 2016, it was reported that the most common passwords were “123456”, “password”, and “12345678”. Of particular note was that “123456” was the top password for the fifth year in a row.
When I go to a website, I am amazed at the lack of standardization for password selection. It seems that each developer, operating as an amateur information security professional, has chosen what they believe might make the most successful password policy. Users, unable to remember passwords, end up picking poor passwords and not picking unique passwords for every website. This, of course, is fundamentally impossible without some form of a password database to work from.
This system is guaranteed to produce continued failures. I’m glad we don’t allow cars, airplanes, electronics, or buildings to be produced like this. Imagine if each engineer got to experiment with what they thought made the best fire suppression system, or the right thickness for a seatbelt. Until we change how our industry operates, it really isn’t that surprising that we will continue to have problems.
The Evils of MD5
I have a new cause. I didn’t expect to have one, but we don’t always get to choose. Sometimes, the issues choose us. In February 2017, the cryptographic hashing algorithm SHA-1 was broken in practice. A practical collision was found, and published on the following website: https://shattered.io We have known for some time that SHA-1 is at the end of useful life and have begin moving to more secure algorithms. This got me to thinking about another hashing algorithm, MD5.
I first started using SHA-1 when I began in the industry around 1994. I was doing cryptographic software development and building early Public Key Infrastructure components. As I was doing work for the U.S. Federal Government, SHA-1 was the hash algorithm of choice. The competing hash algorithm at the time was MD5, invented in 1991, that was gaining popularity outside of the Government space. By 1996, the first weaknesses in MD5 were being discovered, and it was no longer recommended for use. Cryptographers were recommending shifting any usage to other algorithms, including SHA-1.
While reading the information on Shattered.io regarding the collision for SHA-1, I asked myself “how long until I stop seeing SHA-1 used in production systems”. Well, one way to learn is to look at what has happened in the past. MD5 has been discouraged since 1996. In 2017, we still routinely see products implementing MD5. Are you serious? A cryptographic algorithm that has been effectively compromised for 21 years is still in modern products?
So, after 21 years our industry has been incapable of ending our addiction to MD5. For what seems like no rational reason at this point, we continue to use and include this antiquated, broken algorithm in our cipher suites. The typical reason given for including it is to support “legacy” web browsers and clients. Let me ask one simple question: What version of Chrome, Firefox, Safari, or Edge should a computer user be running? The answer is: The latest one. There is no rational reason why production users should be running out of date web browsers in 2017. There are too many security vulnerabilities being patched on a regular basis to justify running out of date software.
Our industry needs to stop leaning on MD5 to provide what we believe is security. The writing has been on the wall since 1996. I really hope 21 years from now we are not dealing with insecurities caused by the usage of SHA-1.