We’re just nearing the end of Q1, and this year has already been a big one for security! There were many significant findings in the news and new vulnerabilities are rolling in daily. Here’s an overview of some recent developments:
The Lock Won’t Save Us All
A big issue that hasn’t quite gotten the attention it deserves is the onset of more advanced phishing techniques, like the recent Gmail phishing scheme.
Phishing schemes are increasingly fooling even the most tech-savvy users, and they’re getting some unintended help from certificate authorities. Cyber criminals have been using certificate authorities, like Let’s Encrypt, to issue certificates for many spoofed sites. They create subdomains under legitimate domains, point them to servers under their control, then obtain valid SSL certificates. The only requirement Let’s Encrypt has for obtaining these certificates is that the applicant was able to publish on the target domain at one point in time. Major targets include PayPal, Amazon, Apple, Google, and banks. One example was a spoofed site “paypal.com.webapps-mpp-accounts.com”.
The attackers can then obtain valid SSL certificates that provide the green lock and the “Secure” wording in the address bar. So, not only does the site look identical to the original, but it has additional precautions that are generally used to verify a site is okay.
Unfortunately, Let’s Encrypt and other certificate authorities argue that policing phishing sites is not their problem. Let’s Encrypt does check with the SafeBrowsing service to see if the domain has been marked as malicious, but even this they are saying should not be the responsibility of a CA. So, if you can’t rely on the certificate authority to tell you which certificates and web addresses are valid and safe, who can you trust?
Many CAs are saying that responsibility should rest with the browser. But as stated in this article from Eric Claw, browsers often “over promise the safety of sites by using terms like Secure in the UI—while the browser can know whether a given HTTPS connection is present and free of errors, it has no knowledge of the security of a destination site or CDN, nor its business practices.”
As it exists right now, browser security technology is just not advanced enough to accurately inform users if the site they are on is safe or not. According to Eric Claw, browsers can only really provide security information that will undoubtedly be an annoyance to users, “This download was not reported as not safe.”
The best thing we can do until security technology improves is be as informed and observant as we can. Don’t trust the “Secure” wording or the lock on the address bar. They can’t reliably tell you if a site is secure or not. Look carefully at the web address. Never enter credentials or sensitive information into a site communicating over HTTP. That information can be read in clear text and stolen. Bookmark important sites and return to their location that way.
First-Ever SHA-1 Collision
In case you haven’t heard yet, Google discovered the bug in Cloudflare, nicknamed “Cloudbleed”. They found several unpatched Microsoft exploits, and they discovered the first-ever SHA-1 collision.
The SHA-1 collision Google found essentially breaks SHA-1 for use as a secure hash function. Many researchers have been warning about SHA-1’s deficiencies for years. They have aptly named the attack ‘SHAttered’.
For some background, SHA-1(Secure Hash Algorithm) is a widely used cryptographic hashing function that was designed in 1995 by the NSA. A hash function is a form of cryptography that converts a message into what is called a digest, something like 0f01ed56a1e32a05e5ef96e4d779f34784af9a96.
Hash functions are one-way, meaning once a message has been converted into the hashed value, the original text cannot be retrieved. SHA-1 has some more secure successors you may be familiar with, like SHA-256 and SHA-512.
Hashes have a few different purposes. The most common is to check the identity of files. (Ever verify the checksum of something you downloaded off the internet?) Another purpose of hashes is for storing passwords. When you enter in your password on a website, instead of checking what you entered matches a password stored in a database, the value is hashed and compared against the stored hash of your password. So when hackers obtain access to systems, they can only grab the hashes of passwords and not the passwords themselves. That’s why it is so important to have a random and long password. There are numerous brute-force tools that compare hashes to pre-made wordlists. Something like ‘puppies’ or ‘chocolate’ will be cracked within seconds. A more obscure password will take much longer to crack, if it can be cracked at all.
An important part of what makes hash functions secure enough to store passwords is protection from collisions. A collision is when two of the hashes that have been generated are identical. Two different files stored with the same hash leads to problems. Intentionally trying to break the hash algorithm so different files are stored with the same hashes causes even more security woes and is called a collision attack. This is exactly what Google was able to accomplish.
With what Google is calling “one of the largest computations ever completed”, and using a massive infrastructure in their cloud, Google was able to complete the attack requiring 9,223,372,036,854,775,808 SHA-1 computations, something which should have taken 6,500 years of CPU computations. From this, they were able to generate two PDF files with different contents that have the same SHA-1 hash value.
They plan to release the proof-of-concept code so that others will be able to recreate it. Dubbing SHA-1 officially insecure, they are recommending an update to SHA-256 as soon as possible. For more details and to view the PDFs that were generated, check out this page.
Next Hacking Target: Dishwashers?
A German researcher, Jens Regel, found a flaw in a washer-disinfector appliance that could allow an attacker to access information on its network. The appliance affected was a Miele Professional PG 8528, an IoT (Internet of Things) device. Regel was able to exploit the dishwasher’s embedded webserver through a directory traversal attack.
A directory traversal, or path traversal, is an attack that allows access to directories and files stored outside the web root folder, typically critical system files that you wouldn’t want anyone else to see. Usually when systems are vulnerable to this type of attack, the file the attacker grabs is /etc/passwd, which despite the name, doesn’t actually display passwords, but you still don’t want displayed to the world as it shows valuable user account information and who can login to your system. However, in this instance, the exploit command that was executed was:
GET /../../../../../../../../../../../../etc/shadow HTTP/1.1
This displays the /etc/shadow file, which is arguably the most sensitive file on a Linux system as it stores encrypted passwords. This attack could also grab any other file stored on the system. Full disclosure here.
———
Like this post? Let us know on Twitter, and check out these other articles you might like:
