For as long as I can remember, I’ve heard that “users are the weakest link in the chain,” or even worse, “you can’t stop stupid.” This long-held view is not terribly productive to advancing information security, and it certainly doesn’t endear the security professional to the general public. Sure, humans are susceptible to things machines aren’t, and yes, it is human nature to trust. So when an email is delivered to a busy person’s inbox and appears to be sent from one’s boss, most people are going to click on it. And while security awareness programs do help, they won’t eliminate phishing attacks, especially as attackers’ methods become wilier and more true-to-life.

During a recent talk at ShmooCon, Praesidio CTO Sean Cassidy demonstrated how an attacker could perpetrate a phishing attack against LastPass users, made possible, in part, because the company itself is being extra security conscious following a very public breach last spring. A browser extension for LastPass prompts the user for login credentials when the user’s session is about to expire. The notification displays as an in-browser pop-up, and the user has already been alerted in an email from LastPass to expect these pop-ups. In this case, the company trained the user what to expect and, by following the prompts, the user was complying with security instructions provided by the vendor. The problem with this vendor-provided security guidance is that it can lead to stolen data.

A browser viewport is easily spoofed; any moderately technical hacker could pull off this type of attack by simply right-clicking on the webpage and copying the source code, changing it ever so slightly to redirect the user to a malicious Web page. Making matters worse, an infected browser could also steal the authentication token when the user enters his/her username and password if two-factor authentication is employed. Two-factor authentication is even better than a single factor, we tell our users – use it! Well, this attack uses it too.

This code used in this particular attack was so convincing that even the security-aware could have been easily tricked. The spoofed page looks entirely the same as the real page LastPass legitimately created.

 

Screenshot from https://www.seancassidy.me/lostpass.html

What should this say to security professionals? To one, namely the guy who discovered the exploit, it says,The real solution is designing software to be Phishing resistant. Just like we have anti-exploitation techniques, we need anti-Phishing techniques built into more software. Software security evaluations should also include how easy it is to Phish said software.Cassidy furthers his claim by stating that “the security industry's view of Phishing is naive at best, negligent at worst.” All of the best efforts to stop phishing—don’t click on links from unknown sources, don’t provide sensitive information via email or online, look for typos and misspellings—don’t apply when the code is so craftily created that only someone specifically looking for an exploit would notice one.

This example furthers the case for more secure development, because users can only be trained to an extent. We cannot reasonably expect every Internet user to dig into Web source code. Cross-site request forgery and cross-site scripting are too often found, and Web browser attacks are some of the easiest and least expensive attack techniques. They will continue to be used alongside very effective phishing campaigns, so the best we can do is find ways to plug up the holes.

Software companies and the operating systems (OS) themselves have to demand a more rigorous secure development process before code is released. Quality assurance (QA) professionals need to be held to a higher standard. Test environments could be opened up to more—trusted—researchers so errors can be fixed before they’re in production.

While Cassidy is quick to point out that he doesn’t identify himself as a researcher, there are many in the industry who claim that moniker for themselves, testing for bugs and vulnerabilities when it’s ethically OK to do so. Software vendors also need to step up, even the best of the best; when a vulnerability is disclosed during QA or by a security researcher to the company in a responsible way, vendors need to react quickly and worry less about the perception of their software than the possibility of exploit. In today’s digitally connected world, flaws are going to be written and weaknesses found. Target and Home Depot and many others have found that the public is quick to forgive; they were also some of the first adopters of new technologies that can help mitigate data theft.

As James Jardine of Jardine Software points out, “Recently, more focus has been put on the developers to create more secure applications. This focus is too narrow. The focus should be on everyone involved with the application development process, from business analysts to application owners and company executives. Everyone plays a part in application security. Doing a better job of embedding security into the development lifecycle will help lead to more secure applications.” The common end user, however, isn’t part of that process. Securing applications or browsers or software isn’t his or her job; it’s security’s responsibility to educate users once security has collaborated with development teams to produce more secure software and applications. Jardine adds, “Using development and testing resources makes it easier to build better software without the need to find a large number of additional resources.”

Building more secure software is definitely the name of the game, and infosec has the talent, with a little-added focus, to get there. Shifting the blame from the end user to creating a culture of secure development will empower the security industry to move ahead and build new technologies that rise to the challenge of today’s threats. Holding the user responsible isn’t working, but technology innovation—and collaboration—will.