Update (2023-01-16): This article is now available in Korean.

I wrote about South Korea’s mandatory so-called security applications a week ago. My journey here started with TouchEn nxKey by RaonSecure which got my attention because the corresponding browser extension has more than 10 million users – the highest number Chrome Web Store will display. The real number of users is likely considerably higher, the software being installed on pretty much any computer in South Korea.

That’s not because people like it so much: they outright hate it, resulting in an average rating of 1,3 out of 5 stars and lots of calls to abolish it. Yet using it is required if you want to do things like online banking in South Korea.

The banks pushing for the software to be installed claim that it improves security. People call it “malware” and a “keylogger.” I spent some time analyzing the inner workings of the product and determined the latter to be far closer to the truth. The application indeed contains key logging functionality by design, and it fails to sufficiently restrict access to it. In addition, various bugs range from simple denial of service to facilitating remote code execution. Altogether I reported seven security vulnerabilities in the product.

Edit (2023-01-04): A Korean translation of this article is now available here, thanks to Woojin Kim. Edit (2023-01-07): Scheduled one more disclosure for February.

Last September I started investigating a South Korean application with unusually high user numbers. It took me a while to even figure out what it really did, there being close to zero documentation. I eventually realized that the application is riddled with security issues and, despite being advertised as a security application, makes the issue it is supposed to address far, far worse.

That’s how my journey to the South Korea’s very special security application landscape started. Since then I investigated several other applications and realized that the first one wasn’t an outlier. All of them caused severe security and privacy issues. Yet they were also installed on almost every computer in South Korea, being a prerequisite for using online banking or government websites in the country.

Before I start publishing articles on the individual applications’ shortcomings I wanted to post a summary of how (in my limited understanding) this situation came about and what exactly went wrong. From what I can tell, South Korea is in a really bad spot security-wise right now, and it needs to find a way out ASAP.

LastPass has been breached, data has been stolen. I already pointed out that their official statement is misleading. I also explained that decrypting passwords in the stolen data is possible which doesn’t mean however that everybody is at risk now. For assessing whether you are at risk, a fairly hidden setting turned out critical: password iterations.

LastPass provides an instruction to check this setting. One would expect it to be 100,100 (the LastPass default) for almost everyone. But plenty of people report having 5,000 configured there, some 500 and occasionally it’s even 1 (in words: one) iteration.

Let’s say this up front: this isn’t the account holders’ fault. It rather is a massive failure by LastPass. They have been warned, yet they failed to act. And even now they are failing to warn the users who they know are at risk.

Right before the holiday season, LastPass published an update on their breach. As people have speculated, this timing was likely not coincidental but rather intentional to keep the news coverage low. Security professionals weren’t amused, this holiday season became a very busy time for them. LastPass likely could have prevented this if they were more concerned about keeping their users secure than about saving their face.

Their statement is also full of omissions, half-truths and outright lies. As I know that not everyone can see through all of it, I thought that I would pick out a bunch of sentences from this statement and give some context that LastPass didn’t want to mention.

A few days ago LastPass admitted that unknown attackers copied their “vault data.” It certainly doesn’t help that LastPass failed to clarify which parts of the vaults are encrypted and which are not. LastPass support adds to the confusion by stating that password notes aren’t encrypted which I’m quite certain is wrong.

In fact, it’s pretty easy to view your own LastPass data. And it shows that barely anything changed since I wrote about their “encrypted vault” myth four years go. Passwords, account and user names, as well as password notes are encrypted. Everything else: not so much. Page addresses are merely hex-encoded and various metadata fields are just plain text.

If you have a LastPass account you should have received an email updating you on the state of affairs concerning a recent LastPass breach. While this email and the corresponding blog post try to appear transparent, they don’t give you a full picture. In particular, they are rather misleading concerning a very important question: should you change all your passwords now?

The following statement from the blog post is a straight-out lie:

If you use the default settings above, it would take millions of years to guess your master password using generally-available password-cracking technology.

This makes it sound like decrypting the passwords you stored with LastPass is impossible. It also prepares the ground for blaming you, should the passwords be decrypted after all: you clearly didn’t follow the recommendations. Fact is however: decrypting passwords is expensive but it is well within reach. And you need to be concerned.

I’ll delve into the technical details below. But the executive summary is: it very much depends on who you are. If you are someone who might be targeted by state-level actors: danger is imminent and you should change all your passwords ASAP. You should also consider whether you still want them uploaded to LastPass servers.

If you are a regular “nobody”: access to your accounts is probably not worth the effort. Should you hold the keys to your company’s assets however (network infrastructure, HR systems, hot legal information), it should be a good idea to replace these keys now.

Unless LastPass underestimated the scope of the breach that is. If their web application has been compromised nobody will be safe. Happy holidays, everyone!

Edit (2022-12-27): As it turned out, even for a “nobody” there are certain risk factors. You should especially check your password iterations setting. LastPass failed to upgrade some accounts from 5,000 to 100,100 iterations. If it’s the former for you, your account has a considerably higher risk of being targeted.

Also, when LastPass introduced their new password complexity requirements in 2018 they failed to enforce them for existing accounts. So if your master password is shorter than twelve characters you should be more concerned about your passwords being decrypted.

Let me say it up front: breaking up end-to-end-encrypted HTTPS connections is bad. No matter why you think that you need to inspect and/or modify the contents of an HTTPS connection, please consider not doing it. And if you still think that you absolutely need it, please sit down and consider again just not doing it.

Unfortunately, I know that way too often this advice won’t be followed. And I don’t mean tools like the Burp Suite which only break up end-to-end-encryption of HTTPS connections temporarily to aid developers or security researchers. No, it’s rather the antivirus applications which do it because they want to scan all your traffic for potential threats. Or companies which do it because they want to see everything happening on their network.

Usually this results in privacy and/or security issues of varying severity. A while ago I already discussed the shortcomings of Kaspersky’s approach. I later found a catastrophic issue with Bitdefender’s approach. And altogether I’ve seen a fair share of typical issues in this area which are really hard to avoid. Let me explain.

I recently noticed Scirge advertising itself to corporations, promising to “solve” data leaks. Reason enough to take a look into how they do it. Turns out: by pushing a browser extension to all company employees which could be misused as spyware. Worse yet, it obfuscates data streams, making sure that employees cannot see what data is being collected. But of course we know that no employer would ever abuse functionality like that, right?

Edit (2022-12-07): Turns out, Scirge always logs all the relevant decisions. So opening Developer Console on the extension’s background page is sufficient to see what is being collected and sent to the server, despite the transmitted data being obfuscated.

In the article discussing the attack surface of extension pages I said:

Websites, malicious or not, cannot usually access extension pages directly however.

And then I proceeded talking about extension pages as if this security mechanism were always in place. But that isn’t the case of course, and extensions will quite often disable it at least partially.

The impact of extension pages being exposed to the web is severe and warrants a thorough discussion in a separate article. So here it comes.

Note: This article is part of a series on the basics of browser extension security. It’s meant to provide you with some understanding of the field and serve as a reference for my more specific articles. You can browse the extension-security-basics category to see other published articles in this series.

In the previous article we discussed extension privileges. And as we know from another article, extension pages are the extension context with full access to these privileges. So if someone were to attack a browser extension, attempting Remote Code Execution (RCE) in an extension page would be the obvious thing to do.

In this article we’ll make some changes to the example extension to make such an attack against it feasible. But don’t be mistaken: rendering our extension vulnerable requires actual work, thanks to the security measures implemented by the browsers.

This doesn’t mean that such attacks are never feasible against real-world extensions. Sometimes even these highly efficient mechanisms fail to prevent a catastrophic vulnerability. And then there are of course extensions explicitly disabling security mechanisms, with similarly catastrophic results. Ironically, both of these examples are supposed security products created by big antivirus vendors.

Note: This article is part of a series on the basics of browser extension security. It’s meant to provide you with some understanding of the field and serve as a reference for my more specific articles. You can browse the extension-security-basics category to see other published articles in this series.