Endpoint

5/10/2018
04:00 PM
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%

Phishing Attack Bypasses Two-Factor Authentication

Hacker Kevin Mitnick demonstrates a phishing attack designed to abuse multi-factor authentication and take over targets' accounts.

Businesses and consumers around the world are encouraged to adopt two-factor authentication as a means of strengthening login security. But 2FA isn't ironclad: attackers are finding ways to circumvent the common best practice. In this case, they use social engineering.

A new exploit, demonstrated by KnowBe4 chief hacking officer Kevin Mitnick, lets threat actors access target accounts with a phishing attack. The tool to do this was originally developed by white hat hacker Kuba Gretzky, who dubbed it evilginx and explains it in a technical blog post.

It starts with typosquatting, a practice in which hackers create malicious URLs designed to look similar to websites people know. Mitnick starts his demo by opening a fake email from LinkedIn and points out its origin is "llnked.com" - a misspelling people will likely overlook.

Those who fall for the trick and click the email's malicious link are redirected to a login page where they enter their username, password, and eventually an authentication code sent to their mobile device. Meanwhile, the attacker can see a separate window where the victim's username, password, and a different six-digit code are displayed.

"This is not the actual 6-digit code that was intercepted, because you can't use the 6-digit code again," Mitnick says in the demo. "What we were able to do was intercept the session cookie."

With the session cookie, an attacker doesn't need a username, password, or second-factor code to access your account. They can simply enter the session key into the browser and act as you. All they have to do is paste the stolen session cookie into Developer Tools and hit Refresh.

It's not the first time 2FA has been hacked, says Stu Sjouwerman, founder and CEO at KnowBe4. "There are at least ten different ways to bypass two-factor authentication," he explains in an interview with Dark Reading. "They've been known about but they aren't necessarily well-published … most of them are flying under the radar."

These types of exploits are usually presented as concepts at conferences like Black Hat. Mitnick's demo puts code into context so people can see how it works. This can be used for any website but an attacker will need to tweak the code depending on how they want to use it.

To show how the exploit can make any site malicious, Sjouwerman sent me an email tailored to look like it came from Kelly Jackson Higgins, reporting a typo in an article of mine:

When I clicked the link, I ultimately ended up on Dark Reading but was first redirected to a site owned by the "attacker" (Sjouwerman). In a real attack scenario, I could have ended up on a truly malicious webpage where the hacker could launch several different attacks and attempt to take over my machine. Sjouwerman sent a screenshot of what he saw while this happened:

Event types go from processed, to deferred, to delivered, to opened.

"You need to be a fairly well-versed hacker to do this - to get it set up and have the code actually working," he notes. This is a one-on-one attack and can't be scaled to hit a large group of people at the same time. However, once the code works, the attack is fairly simply to pull off.

"You need to have user education and training, that's a no-brainer, but you also have to conduct simulated phishing attacks," Mitnick says in his demo.

Sjouwerman emphasizes the importance of putting employees through "new school" security awareness training, as opposed to the "death by PowerPoint" that many employees associate with this type of education. Instead of putting them through presentations, he recommends sending them phishing attacks and conducting online training in the browser.

Related Content:

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance & Technology, where she covered financial ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
TextPower
100%
0%
TextPower,
User Rank: Strategist
5/12/2018 | 10:29:41 AM
Received SMS will always be problematic
FULL DISCLOSURE: My company holds two patents on an SMS-based 2FA that eliminates this problem so this is NOT an unbiased or objective opinion.

The real problem here, as it always is with SMS-based 2FA where a message is sent to the user, is excatly that: that the message is sent TO the user.  

Text messages sent to phones are, by definition, both unencrypted and easy to intercept, as Mr. Mitnick has amply demonstrated. The answer to this problem is to reverse the process and have the user authenticate their login or identity by sending a message FROM their phone.  

Here's why this works: the U.S. short code system eliminates spoofing of phone numbers thanks to the carriers.  Cloning/spoofing/duplicating SIMs and IMEIs is a problem for carriers for a simple reason: the lose money when someone doesn't pay for another line.  They solved this problem long ago by implementing a barrier that has yet to be successfully hacked.  

This more secure approach reverses the process by having the user send a text from their device into an independent third-party server.  The server then makes a secure handshake with the web page where the authentication is occurring.  This completely eliminates the type of attack Mr. Mitnick successfully used (man-in-the-middle or man-in-the-browser) and confirms that the inbound SMS has come from the right number, registered IMEI and contains the right code.  I welcome Mr. Mitnick to test the system.  I will be happy to provide him with complete information about it and give him a test account.

Nothing is unhackable (although ours has not yet been successfully hacked) but we are confident that SnapID is substanially LESS hackable than any other SMS-based 2FA method on the market.  
Want Your Daughter to Succeed in Cyber? Call Her John
John De Santis, CEO, HyTrust,  5/16/2018
New Mexico Man Sentenced on DDoS, Gun Charges
Dark Reading Staff 5/18/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Flash Poll
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
Enterprises are spending more of their IT budgets on cybersecurity technology. How do your organization's security plans and strategies compare to what others are doing? Here's an in-depth look.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-11354
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, the IEEE 1905.1a dissector could crash. This was addressed in epan/dissectors/packet-ieee1905.c by making a certain correction to string handling.
CVE-2018-11355
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, the RTCP dissector could crash. This was addressed in epan/dissectors/packet-rtcp.c by avoiding a buffer overflow for packet status chunks.
CVE-2018-11356
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, 2.4.0 to 2.4.6, and 2.2.0 to 2.2.14, the DNS dissector could crash. This was addressed in epan/dissectors/packet-dns.c by avoiding a NULL pointer dereference for an empty name in an SRV record.
CVE-2018-11357
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, 2.4.0 to 2.4.6, and 2.2.0 to 2.2.14, the LTP dissector and other dissectors could consume excessive memory. This was addressed in epan/tvbuff.c by rejecting negative lengths.
CVE-2018-11358
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, 2.4.0 to 2.4.6, and 2.2.0 to 2.2.14, the Q.931 dissector could crash. This was addressed in epan/dissectors/packet-q931.c by avoiding a use-after-free after a malformed packet prevented certain cleanup.