by Amir Khashayar Mohammadi
Nearly every web browser comes equipped with a built-in password manager. Combined with all its other inherent vulnerabilities, this makes the local browser an even more attractive target for automated attacks. The bad guys would love to gain access to the container that keeps track of the keys to your online bank. Given the browser’s weak security underpinnings, how hard could it be?
Not too hard. This was confirmed, once again, by news that broke earlier this week. A new piece of malware, dubbed "Olympic Destroyer" by security firm Talos, does just that. Its purpose was to target a network of non-critical systems at this year’s Winter Olympics in PyeongChang, South Korea.
Cybersecurity researchers pointed out that Olympic Destroyer was designed to take computers offline by erasing critical system files. But that was not the whole story. Olympic Destroyer also features two critical methods of stealing credentials.
One technique targets those credentials stored in the local browser, while the other approach takes advantage of LSASS (Local Security Authority Subsystem Service), using a procedure reminiscent of the popular memory assessment tool Mimikatz.
Malware that self-propagates throughout the local network is nothing new. The WannaCry ransomware for example, which leverages the EternalBlue SMB exploit, impacted thousands of companies worldwide in 2018. How did Olympic Destroyer unfold its destructive potential?
Olympic Destroyer has local browsers in its crosshairs
Olympic Destroyer is taking advantage of computers that still have local browsers installed. During the second stage of its execution, it begins to steal credentials stored locally on the system. It specifically targets browsers that have credentials stored inside them.
Source: Talos Blog
Let’s examine Olympic Destroyer’s browser credential stealing method. According to the Talos researchers, "the stealer supports: Internet Explorer, Firefox and Chrome." Many modern browsers like Chrome tend to store settings, history, bookmarks and even logins all in one folder. This folder is located here on the user’s machine (for Chrome):
The data is stored in various SQLite-formatted databases. One SQLite database in particular, named “Login Data”, holds a ton of valuable information. This includes the websites for logging in, usernames, name of password fields, and of course the password itself (in an encrypted format using the DES algorithm).
So how does Olympic Destroyer manage to get the goods? The malware accomplishes the task in three steps:
First, it takes the user’s registry, parses it (takes the data out of its obfuscated format), and then queries for that specific SQLite file, to retrieve all the stolen credentials within it. (The image above shows the embedded SQLite data table stored within one of the samples obtained by Talos).
Once all the locally stored login data has been bagged, Olympic Destroyer generates a new set of binaries that contain the freshly harvested credentials.
In the third step, the program searches the network for local hosts and begins using all the credentials found to break into new computers.
Only after accomplishing its password-stealing mission Olympic Destroyer begins to efficiently destroy the machine on which it resides. by deleting critical files.
As the malware spreads throughout the network, it obtains new credentials found on each system using the same tactics. At the end of this process, Olympic Destroyer sits in a pile of credentials and dead machines.
Had the IT staff at the Olympic games stored their credentials differently, the attack vector expressed by the malware could not have been targeted so successfully. As of mid-February, the initial spreading vector and origins of Olympic Destroyer remain unknown.
But wait, there’s more.
Was this an isolated incident, caused by a particularly efficient malware? Far from it. The security weakness of local browsers leaves them vulnerable to password manager exploits of all sorts.
This is highlighted again by a recent report from Princeton University, where researchers examined how third-party scripts can take advantage of the way browsers react to auto-filling login forms.
This ultimately leads to the wrong people (or machine) receiving your login combos. From the exploit kits we’ve previously seen here, this could be very devastating. Here’s how this loophole works:
Source: Freedom to Tinker
In this case, the technique used to get to user credentials works quite simple. When a user enters login information on a website, the browser will ask to save what has been entered in the form, and the user clicks yes.
Next, the user will be presented with a page without a login option. Instead, it contains an invisible login form. In the background, the credentials are auto-filled again, this time into forms that are invisible to the user’s eye, but readable by the third-party servers that have this type of script present on the primary site.
These tactics are borrowed from online advertising. Ad networks use them to display targeted advertisements by figuring out what sites the user likes to visit.
Data that’s often collected by ad companies include language, screen resolution, user agent string, OS and CPU information, data that browsers hand over without questioning such requests.
The Princeton researchers examined two scripts supplied by AdThink and OnAudience. Both companies sell ad revenue services that collect a lot of the data previously mentioned. OnAudience collects hashed email addresses (using the weak MD5 algorithm) which are then attached to all the other data gathered to track the user’s browsing habits.
Companies that have such scripts embedded in their websites and services include news media and entertainment networks, online retailers, job boards, and so on. Want to know how it looks? A snippet of the data collecting code can be found here. The same method can be used used to harvest credentials.
Freedom to Tinker
The Princetown team released a demo site to illustrate the risk potential. Anyone can test and see if they are vulnerable to this type of attack.
The demo explores only how Chrome handles that operation. Nevertheless, according to the site, Safari, Edge, Internet Explorer, and Firefox have all been experimented on.
Keep in mind – the site that presents the initial form would not be collecting your data, but a third party that siphons away these variables.
The demo illustrates how easy it is for a third party to launch their own malicious scripts for email:pass combinations.
The very last lines of code are what causes the browser to decide whether it should proceed to use autofill on the invisible login forms. This type of attack doesn’t seem to work on stand-alone password managers like KeePassX.
What’s the reason for this automated exploit affecting only common browser-based password managers? They automatically respond to login forms. External password managers are less vulnerable because they still require manual interaction to begin the autofill process.
Why would you trust a local browser with your passwords?
Of the most effective ways to steal someone’s credentials online, most seem to go through the browser. There are many methods to trick browser-based password managers into handing over what they are supposed to protect. This post can only cover two of them – did you get an idea how easy it is?
My take is that we’ll see more of (automated) attacks against browser-based password managers in the coming years. Entrusting passwords to your regular browser strikes me as the equivalent of storing money underneath a pillow rather than relying on a bank.
The takeaway? I don’t advocate getting rid of password managers in general. By any measure, they’re much more efficient than users at managing secure passwords. Just not where they are part of a traditional browser, even if that browser is labeled “secure”.
Amir Khashayar Mohammadi is a Computer Science and Engineering major who focuses on malware analysis, cryptanalysis, web exploitation, and other cyber attack vectors.
This is a Security Bloggers Network syndicated blog post authored by Guest Contributor. Read the original post at: Authentic8 Blog