Note: This article is also available in Korean.
Normally, when you navigate to your bank’s website you have little reason to worry about impersonations. The browser takes care of verifying that you are really connected to the right server, and that your connection is safely encrypted. It will indicate this by showing a lock icon in the address bar.
So even if you are connected to a network you don’t trust (such as open WiFi), nothing can go wrong. If somebody tries to impersonate your bank, your browser will notice. And it will refuse connecting.
This is achieved by means of a protocol called Transport Layer Security (TLS). It relies on a number of trusted Certification Authorities (CAs) to issue certificates to websites. These certificates allow websites to prove their identity.
When investigating South Korea’s so-called security applications I noticed that all of them add their own certification authorities that browsers have to trust. This weakens the protection provided by TLS considerably, as misusing these CAs allows impersonating any website towards a large chunk of South Korean population. This puts among other things the same banking transactions at risk that these applications are supposed to protect.
Contents
Which certification authorities are added?
After doing online banking on your computer in South Korea, it’s worth taking a look at the trusted certification authorities of your computer. Most likely you will see names that have no business being there. Names like iniLINE, Interezen or Wizvera.
None of these are normally trusted. They have rather been added to the operating system’s storage by the respective applications. These applications also add their certification authorities to Firefox which, unlike Google Chrome or Microsoft Edge, won’t use operating system’s settings.
So far I found the following certification authorities being installed by South Korean applications:
| Name | Installing application(s) | Validity | Serial number |
|---|---|---|---|
| ASTxRoot2 | AhnLab Safe Transaction | 2015-06-18 to 2038-06-12 | 009c786262fd7479bd |
| iniLINE CrossEX RootCA2 | TouchEn nxKey | 2018-10-10 to 2099-12-31 | 01 |
| INTEREZEN CA | Interezen IPInside Agent | 2021-06-09 to 2041-06-04 | 00d5412a38cb0e4a01 |
| LumenSoft CA | KeySharp CertRelay | 2012-08-08 to 2052-07-29 | 00e9fdfd6ee2ef74fc |
| WIZVERA-CA-SHA1 | Wizvera Veraport | 2019-10-23 to 2040-05-05 | 74b7009ee43bc78fce69 73ade1da8b18c5e8725a |
| WIZVERA-CA-SHA2 | Wizvera Veraport, Wizvera Delfino | 2019-10-23 to 2040-05-05 | 20bbeb748527aeaa25fb 381926de8dc207102b71 |
And these certification authorities will stay there until removed manually. The applications’ uninstallers won’t remove them.
They are also enabled for all purposes. So one of these authorities being compromised will not merely affect web server identities but also application or email signatures for example.
Update (2023-02-19): Someone compiled a more comprehensive list of these certificates.
Will a few more certification authorities really hurt?
If you look at the list of trusted certification authorities, there are more than 50 entries on it anyways. What’s the problem if a few more are added?
Running a Certificate Authority is a huge responsibility. Anyone with access to the private key of a trusted certification authority will be able to impersonate any website. Criminals and governments around the world would absolutely love to have this power. The former need it to impersonate your bank for example, the latter to spy on you undetected.
That’s why there are strict rules for certification authorities, making sure the access to the CA’s private key is restricted and properly secured. Running a certification authority also requires regular external audits to ensure that all the security parameters are still met.
Now with these South Korean applications installing their own Certificate Authorities on so many computers in South Korea, they become a huge target for hackers and governments alike. If a private key for one of these Certificate Authorities is compromised, TLS will provide very little protection in South Korea.
How do AhnLab, RaonSecure, Interezen, Wizvera deal with this responsibility? Do they store the private keys in a Hardware Security Module (HSM)? Are these in a secure location? Who has access? What certificates have been issued already? We have no answer to these questions. There are no external audits, no security practices that they have to comply with.
So people are supposed to simply trust these companies to keep the private key secure. As we’ve already seen from my previous articles however, they have little expertise in keeping things secure.
How could this issue be solved?
The reason for all these certificate authorities seems to be: the applications need to enable TLS on their local web server. Yet no real certificate authority will issue a certificate for 127.0.0.1, so they have to add their own.
If a certificate for 127.0.0.1 is all they need, there is a simple solution. Instead of adding the same CA on all computers, it should be a different CA for each computer.
So the applications should do the following during the installation:
- Generate a new (random) certificate authority and the corresponding private key.
- Import this CA into the list of trusted certification authorities on the computer.
- Generate a certificate for 127.0.0.1 and sign it with this CA. Application can now use it for its local web server.
- Destroy the private key of the CA.
In fact, Initech CrossWeb Ex V3 seems to do exactly that. You can easily recognize it because the displayed validity starts at the date of the installation. While it also installs its certificate authority, this one is valid for one computer only and thus unproblematic.
Oh, and one more thing to be taken care of: any CAs added should be removed when the application is uninstalled. Currently none of the applications seem to do it.
Comments
Installing a root ca certificate is a long-standing practice in Korean Internet security. It's a legacy from the days of ActiveX that didn't need to talk to localhost.
After reading this article, I found out that e-Page SAFER(document security solution), Document SAFER(DRM) from MarkAny also installs its own root CA cert on user's computer when installing their "security" program. So we can say that installing their own makeshift root CA cert is a well-known practice in korean internet security companies.
I don’t see these products being offered for download, I guess that one needs to buy them? User numbers probably aren’t all too high then, making this less of an issue. But: yes, this appears to be a common practice.
both e-Page SAFER and Document SAFER is only related to exporting documents, so install is only requested when required. banks are (like Woori) offering those software in 'legacy optional' downloads.
https://bugzilla.mozilla.org/show_bug.cgi?id=335197 https://bugzilla.mozilla.org/show_bug.cgi?id=1226100 Your mention of root certificates reminded me of these old Mozilla issues. Do you know them?
I don’t, but these went through a proper review, so I assume that they are reasonably safe.
I always curious about those bank program's uninstalling process. Not only CA remains after the application Uninstall, but also the registry and other crops. some even can see on the task manager. how could it happen? Is it complicated to make a proper uninstaller function?
Uninstall is fairly straightforward when using a proper installer. However, the applications I’ve seen often don’t. There are self-extracting executable archives, there are really weird custom-made solutions, all kinds of things. There are even applications dropping parts into the Windows system directory like it was common in the Windows 9x era. And then uninstall of course has to be implemented and kept in sync with the installation manually. That it doesn’t always work isn’t surprising.
Thanks for the articles on this topic Wladimir, and raising awareness! Your research is really appreciated.
These malpractices, that some Korean banks are forcing onto their customers is really concerning. In order to access their bank accounts, the clients must install several applications (of questionable backgrounds).
Basically, they are undermining the security of the device, as well invading and violating privacy of the users. Installing certificates, forcing users to use legacy Internet Explorer, installing keyloggers, IP sniffers, opening ports, deploying fake antivirus and whatnot.
All of those apps that you listed above appear to be concerning. I do hope that law enforcement and independent/international auditing companies will eventually investigate this.
I wonder what is the purpose of encrypting the loopback traffic in the first place. Most browsers treat the
localhostas a secure origin, e.g., they can open a WebSocket tows://localhostfrom an HTTPS site without mixed content warning. Any malware that can intercept the loopback traffic could do more damage than that.Yes, in most cases this shouldn’t be necessary. Maybe there is some compatibility requirement making it necessary to use HTTPS on localhost, e.g. supporting Internet Explorer 7. But I suspect that this might be simply a hack implemented a decade ago and never revisited.
One of the things korean security programs are known to do is perform MITM attacks with these installed Root CA certificates. When user tries to connect to website using TLS, local security program will sign a TLS certificate using the installed root ca certificate's key, and decrypt the tls traffic for analysis.
Now this is a big problem on multiple different levels, but the main one in my opinion is the fact that in order for the security software to sign a bogus TLS certificate real time, it needs the private key in local memory. This means potential attackers can steal private keys to generate browser-accepted TLS certificate for fake websites they host.
If you have time, would you look into the potential exploits targeting these fake tls certificates signed by security program root CAs? I think this may be real big
That would be a considerably bigger issue, as the private key is no longer a secret then – anyone could extract it from the application. But the applications I’ve looked into so far didn’t have the private key.
Do you have a particular application in mind that is known to decrypt TLS traffic?
Meanwhile in korea (on 2017): https://crt.sh/?id=169761218
They really did wildcard on SLD. Well, revoked however.
Alternatively, the way we tend to limit the scope of these 'unsafe' CAs is by using the x509v3 Name Constraint extension. This defines to which domains the CA can issue certificates, and also tells browsers to throw a warning/block access (like the one in your screenshot) when a certificate is presented for an unlisted domain. Handy little extension for intranet TLS.
Source: https://www.openssl.org/docs/man1.1.1/man5/x509v3_config.html
Inspired by your post, I've compiled a list of such CAs in https://fake-root.github.io/.
Nice, thank you!
As a Korean, I very much agree with your argument and rationale. Korea's internet security system really sucks. But even though there have been numerous personal information leaks following these bad practices, the Korean government just fines companies for poor personal information management and shrugs it off.
Damn, You know more about the internet in Korea than most of korean do. Why the hell they need a 127.0.0.1 loopback certificate?
Most parts of these systems were designed around 2007 and only minimally updated since then. Whatever worked was never touched. So I assume nobody realized that connecting to 127.0.0.1 no longer produces mixed content warnings – or they realized but didn’t want to change a working system, just in case.