Show 5: The Notorious Hacker - Lock Me Down

DZone 's Guide to

Show 5: The Notorious Hacker - Lock Me Down

You know all those computer laws we now have? Well we might have a black-hat hacker to thank. Read on to find out how hackers have influenced computer security.

· Performance Zone ·
Free Resource

In everything we do, despite how creative, the level of ingenuity or how cutting edge, there is always a historical flavoring, that is ever present, that comes from the pioneers that came before us. I am talking about the trailblazers 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 trailblazers, 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 were even computer laws on the books. Through his numerous hacking escapades against phone companies, mobile phone manufacturers 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.


Wired – Selling Zero-day ExploitsCNET – Ham Operator to Fugitive to ConsultantTime Magazine – Technology: Drop the PhoneL.A. Times – CollectionBreak-inCNN – The Trials of Kevin MitnickDigital Trends – Q&A: The notorious Kevin Mitnick on hacking, ethics, and the future of techThomas Jerry Scott: Kevin Mitnick Book: Ghost in the Wires: My Adventures as the World’s Most Wanted HackerWikipedia – Kevin Mitnick


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


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?


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: 

  1. A large portion of security mitigations is about not revealing information that an attacker might be able to use to make his job easier.
  2. 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 it's 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:

  1. Upon submitting their email address, a message is provided on screen that instructions have been sent to that email
  2. 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
  3. 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 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 tradeoff 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 supposed to be providing customers with an enhanced shopping experience through its proprietary 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 obfuscating 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.

    Their 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?


    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

    Computer World – Dell Danger

    Lenovo “Superfish” controversy – what you need to know

    hacker ,book review ,security flaw

    Published at DZone with permission of

    Opinions expressed by DZone contributors are their own.

    {{ parent.title || parent.header.title}}

    {{ parent.tldr }}

    {{ parent.urlSource.name }}