Podcast: Play in new window | Download
Subscribe: Apple Podcasts | RSS
In everything we do, despite how creative, the level of ingenuity or how cutting edge, there is always an historical flavoring, that is ever present, that comes from the pioneers that came before us. I am talking about the trail blazers that have helped allow us to get where we are, or helped shaped the vision of new ideas we try to bring to fruition. In this episode I briefly look at one of those trail blazers, a now reformed black-hat hacker who helped indirectly write many of the computer laws we now have, greatly influence corporations approach to security on multiple levels and all-around shape of what we have come to think of in the term “hacker”.
Kevin Mitnick is an individual who’s actions heavily shaped terms we use to describe methods of intrusion such as “hacking” and “social engineering” during his exploits in the 70’s and 80’s before these terms were even known or there was even computer laws on the books. Through his numerous hacking escapades against phone companies, mobile phone manufactures and OS vendors early in his career, or instructional books, training and speeches as a reformed black-hat hacker, Kevin has provided corporations and everyday developers alike with a wealth of information to help be better prepared.
Listen to this episode to get a snapshot of Kevin’s story and his influence on the computer world we live in.
Sources:
[table align=”center” striped=”yes”]
Recommendations:
If you liked the story, you will definitely like the autobiography of Kevin Mitnick “Ghost in the Wires: My Adventures as the World’s Most Wanted Hacker”. You can get your free audio book through Audible in no time. It’s both entertaining and funny and for technical listeners, will provide insight to allot of familiar concepts, security issues and computer related areas that you have worked with and come to know.
The Burning Question
Question:
[quote color=””]During the user’s password reset process, if a user provides an invalid email address that doesn’t exist in the system, should that be revealed in the message returned to the user? In other words, should you tell them that email address doesn’t exist? Or would that be viewed as a security issue by leaking user information?[/quote]
Answer:
This is one of those answers that developers can fall on different sides of the fence. But I’ll come back to that in a minute. The short answer is “No”, we should reveal the status of that email explicitly in the response when someone requests a password reset.
There a two main benefits of not explicitly revealing whether a submitted email address for a password reset was in the system:
- A large portion of security mitigations is about not revealing information that an attacker might be able to use to make his job easier.
- The other dominant reason is privacy. There are many reputable sites out there that people would rather it not be public knowledge that they are associated. It doesn’t have to be a risqué type of site, maybe its a mental or physical health related site that anonymity is important.
Therefore, the most secure approach is going to be a set of actions that implicitly convey to the requester that “I neither can deny nor confirm that information” by providing information and steps that the system has taken, and the steps the user should take to complete their request. Those steps would look something like:
- Upon submitting their email address, a message is provided on screen that instructions have been sent to that email
- Despite whether the email address is a valid address, you would always send an email to the address provided notifying of the request and the results
- So in the case where the email address is invalid, it would say as much and inform the recipient that someone had provided their email address for a password reset request.
- This would allow someone who might have legitimately been attempting to reset their password, but has multiple email addresses and submitted the wrong one (who doesn’t have multiple email addresses these days).
- It could also tip off a user, that someone was attempting to tamper with their account if they they weren’t the requestor.
- If it was a legitimate address, the email would retain the link and instructions for initiating a password reset.
- In addition a Captcha can be used to thwart your password reset service being spammed with requests.
- Be aware that it has been proven that Captcha’s can be undermined with intelligent impersonation. Projects such as Google’s re-Captcha helps to make this better.
However, there is always a “depends” and in this case the trade off is some frustrated users who don’t get the immediate feedback, especially when they are users with good motives and have provided an incorrect email (e.g. typo’s, forgotten email address, etc.). However, this is the trade-off, but I believe that the majority of users have become acquainted with this more secure process.It would also be worth mentioning, that we haven’t even talked about what that password reset process would look like after initiated from the link in the email sent to the user.
This is also a fairly lengthy and detailed discussion and can have varying levels of security based on the data being protected. Implementing secret questions and answers as part of that account ownership validation is definitely a plus, some would argue a must. For those interested in knowing what that might look like, this article as well as this article can provide some additional information.
Fabulous Failure
Back in Feb. 2015, Lenovo was found to be guilty of circumventing the security of many of their laptop customers. The problem was through a third party software that came preloaded with specific laptops. The software called Superfish was suppose to be providing customers with an enhanced shopping experience through its propriatery product image analysis.
The Superfish software could identify product images on a website page you visited, and subsequently find alternative pricing and/or products to the product image on the page. However, the problem came with how the software went about updating the page you were visiting. Imagine you connect to a website through a secure connection (HTTPS). You expect that your communications are confidential, encrypted and untampered. However, Superfish is injecting modifications to the page to display these alternative products and additional product pricing. But how?
You have to understand how certificates work on computers as well as for browsers. In this episode I dive a bit more than under the covers one how certificates are utilized by the browser to validate your communications over HTTPS. In short, the Superfish software was dynamically generating a certificate and its relative private/public key, in order decrypt and re-encrypt your inbound communications with the site. By doing so, they could locally decrypt, augment and re-encrypt the data without most browsers throwing an error.
Where do you begin with the privacy and security issues that this posed. Setting aside the fact that they have access to your most personal information, in order to perform both this action, they require the private key of the certificate being used for encrypting the data which would generally reside on the server receiving your communication. Unfortunately, for them to do that, they turned to obfiscating the key within the software. As Robert Grahman of Errata Security showed, it wasn’t overly difficult in extracting and decrypting the key from the Superfish software.
You would think that due to the public backlash against Lenovo, other companies would take note to avoid committing the same mistake. Unfortunately, that expectation was lost on Dell who only 7 months later committed the same crime. Known as eDellRoot due to the name of the installed certificate, specific Dell Laptops shipped with a root certificate installed that essentially put the user and computer at risk of the same security vulnerabilities that the Superfish software did.
There excuse was that they were attempting to make it easier for customers of their laptops to gain support. However, as with Superfish, this certificate did not have any restrictions on its usage (e.g. code-signing), it was self-signed and contains the private key. There have been sites setup to successfully demonstrate a proof-of-concept of a malicious site that could be trusted by any laptop with the installed certificate.
Originally, Dell tried to spin the vulnerability to distance itself from the Lenovo Superfish debacle, but eventually apologized and provided instructions for removing the certificate. However, was it too little too late?
Sources:
Naked Security – The Lenovo Superfish Controversy: What You Need To Know
Duo Security – Dude, You Got Dell’d; Publishing Your Privates
Arstechnica – Dell Does a Superfish
Facebook – Windows SSL Intercept Gone Wild
Lenovo “Superfish” controversy – what you need to know
Errata Security – Extracting the Superfish Certificate ~Robert Gram
Music
audionautix.com – Deep Space
audionautix.com – In A World