Reading people discuss my article, they are way more knowledgeable about the back story than I am. One commenter on a Korean website posted some news links explaining it:

https://news.kbs.co.kr/news/view.do?ncd=735696
https://news.kbs.co.kr/news/view.do?ncd=735697

So apparently there was an important story back in May 2005, the Korea Exchange Bank hacking incident. A person’s online banking was compromised by what I understand to be a remote access trojan. The installation of that trojan happened automatically when visiting a malicious website (no mention of a specific vulnerability here, presumably it was Internet Explorer?).

There was a public outrage because the victim didn’t do anything wrong – they didn’t give away their password, didn’t lose their security card. Rather than blaming Microsoft, they decided to blame the banks and their security precautions.

In particular, the second article states that installing security applications shouldn’t be optional. And the bank says that they deliver some “anti-hacking” application and make its use mandatory.

This indeed seems to be how this whole mess happened. What a sad story…

Time for the first disclosure. I present you TouchEn nxKey, an anti-keylogger solution with a very nice concept – in theory.

In practice, this concept requires TouchEn nxKey to implement keylogging functionality itself. And it exposes this functionality to arbitrary websites and unprivileged applications on the users’ computers.

This application also misimplements its communication with websites, facilitating XSS attacks on banking websites using it. Plus various memory safety issues, including one that appears exploitable for RCE. And a honorary mention for OpenSSL 1.0.2c anno 2015.

I usually try to avoid publishing zero-day vulnerabilities, but this vendor didn’t use the time. Not even the most trivial issues have been resolved. Instead, they managed to post exploit links publicly, resulting in them being indexed by Google two months ago already.

In general, I’m not convinced that TouchEn nxKey can be salvaged. Even if implemented properly, it is only useful against generic keyloggers. Any malware targeted specifically at South Korea will easily circumvent its protection.

This is by far the longest article I’ve ever published, sorry about that. There is just so much here…

https://palant.info/2023/01/09/touchen-nxkey-the-keylogging-anti-keylogger-solution/

Note that despite this article being already very long I’ve still left out a lot. Like a Citibank Korea page https://www.citibank.co.kr/CrdOsvcSecu9002_en.act linking to TouchEn nxKey 1.0.0.5 download (a version from 2015, current one being 1.0.0.78). At least the page Citibank usually directs customers to distributes version 1.0.0.75 which is “merely” two years old.

Or the custom-built installer that is a UPX-packed binary dropping most files into the \Windows\System32 directory. Reminds me of the good ol’ Windows 9x days when all installers were doing that.

And the application doesn’t quite trust its files to stay there. So once per session it will run its CKSetup32.exe (still in \Windows\System32), making it replace the existing files by “fresh” copies from the installer. So first time you visit a banking website you get an elevation prompt.

It’s really bad programming all the way down.

You know, I saw South Korean banks offering Linux/Mac application packages for download, and I never bothered checking them out. I just assumed that Linux and Mac were somehow supported. But the Korean commenters said that they aren’t.

I now unpacked one such Linux package and noticed that it was built in 2014 (!). It’s an NPAPI plugin. Of course it doesn’t work. 🤦‍♂️

Interesting to watch how the vendors of South Korean “security” software react to disclosures. With me they won’t communicate at all. Now when Korean press comes asking, then they respond. But they respond with claims that don’t seem very defendable.

RaonSecure for example tells the press that they’ve already fixed all the issues, and the delays are now due to their customers (meaning: banks) having to distribute new builds. Yet RaonSecure has their own download server for their application, and that download server still offers the version from October last year. Also, their browser extension hasn’t been updated in Chrome Web Store. If they developed a fix, they keep it a closely guarded secret.

And the company due for disclosure on January 23rd? They told a reporter that they only received one of my reports in January. So they cannot possibly meet the deadline.

But that’s not what my server logs show. I see them accessing my proof of concept pages (all of them) starting November last year. They’ve been studying them for one week and then – nothing.

But after I announced my disclosures and it blew up in Korea I suddenly see new requests to these files. I’m not saying that this is what happened here, but this looks almost like they weren’t actually planning on fixing this stuff and only got scared when they realized that the disclosure won’t go by unnoticed.

Reading Korean news. Out of all the issues I pointed out, RaonSecure only felt the need to defend their use of the C programming language. “Keyboard security is a special situation that requires privileges such as compatibility or system level access, so there is a reason to use the C language” (automated translation).

Not sure whether this choice of topic was theirs or the journalist’s who asked them. I suspect that it’s the former and they felt this to be the most defendable point? Yes, nothing wrong with having multiple megabytes of binary code written in C just because you need system level access in a tiny part of it. Totally not because you never reviewed your coding practices in the past two decades. /sarcasm

For reference: I did not actually criticize them for their choice of programming language. I criticized them for taking a C JSON parser with various memory safety issues and failing to update it since 2014.

To be honest: I spent so much time on these applications exactly because they are so primitive. My binary reverse engineering skills aren’t good enough for modern code, I learned it in the 90ies. So this is my chance to get better at it without being completely overwhelmed.

It seems that this article was also what spooked AhnLab who emailed me asking about my vulnerability reports to them. No, it’s perfectly fine that AhnLab didn’t receive them because I never sent any. It’s the journalists who, after multiple rounds of copying speculations from one article to another, are now trading their list of my future disclosures almost as a fact.

http://www.enewstoday.co.kr/news/articleView.html?idxno=1630290

The article on TouchEn nxKey is now also translated to Korean, thanks to @alanthedev: https://github.com/alanleedev/KoreaSecurityApps/blob/main/01_touchen_nxkey.md. I hope this will help Korean news discuss the concerns raised there rather than some straw man arguments.

And unfortunately I realized that I should have checked the Korean holidays when making this schedule. I did make sure to start this disclosure series after the US/European holidays, but I didn’t realize that South Korea is celebrating Lunar New Year early next week.

So next disclosure has been moved to January 25th. Sucks to do that when the disclosure date has already been widely publicized, but the alternative is worse IMHO.

Next disclosure is about IPinside LWS Agent, an application required by pretty much every banking website in South Korea. The conclusion here: this application collects way more information about the user’s system than merely IP addresses. And it fails to protect this information, any website can get it.

https://palant.info/2023/01/25/ipinside-koreas-mandatory-spyware/

Highlights of this article:

· A 320 bit RSA key. Yes, really. Took me two hours to factorize on a laptop CPU.
· OpenSSL 1.0.1j anno 2014. There is a recurring pattern here.
· Enumeration of processes running on your system.
· Various stack buffer overflows – I wasn’t actively looking for them, I merely couldn’t fail noticing.

Continuing this series with a more basic flaw, which appears to be common practice for South Korean “security” applications: https://palant.info/2023/02/06/weakening-tls-protection-south-korean-style/

All these applications install their own Certification Authority (CA), only to be able to use HTTPS on 127.0.0.1. As a result, they put the integrity of HTTPS in danger for users in South Korea. Ironically, HTTPS contributes way more to banking security than their half-hearted at improving security do.

I found exactly one application using the right approach for this: generating a CA on installation, used only to sign 127.0.0.1 certificate for the one particular computer. All the other applications install the same CA on each computer. So the respective vendors must have the corresponding private key stored somewhere. Whether/how they protect it is unclear.

KrCERT is working hard on becoming my least favorite security contact (lots of competition but…). Today they sent out an email notifying me and 739 other security researchers about a bug bounty program. No, I’m not complaining about spam that I didn’t sign up for. But dealing with a government agency that’s supposed to handle vulnerability reports, shouldn’t one at least assume that they won’t list all recipients in the To field of the email?

Looking forward to the first one doing Reply All. 🤪

Edit: KrCERT sent around an email (in Korean) apologizing for the issue. Apparently, they sent two emails, so 1490 email addresses were affected in total. They promise to improve their processes and avoid such issues in future. Supposedly, they recognized the issue themselves (I notified them but didn’t receive a direct response).

One of the suggested personal measures is sending a personal information infringement report to 🥁🥁🥁 KISA which KrCERT belongs to.

These applications rely on tons of open source libraries. Yet whenever I recognize one and check the version used, the result is invariably something released between 2010 and 2014. No, it isn’t only OpenSSL. It’s JSON parsers, image processors, all kinds of libraries processing data received from arbitrary web pages. What could possibly go wrong?

Published one more high-level overview before I move on to the next (very long) disclosure in two weeks: https://palant.info/2023/02/20/south-koreas-banking-security-intermediate-conclusions/

Most important conclusion: the South Korean “security” applications are typically attempting to “secure” a compromised environment. That’s a lost cause. You either prevent a compromise, or you rely on 2FA with an uncompromised device (ideally both).

The one where I’m a little unsure are certificate-based logins. I *think* that they offer no advantage in the banking scenario compared to passwords (at least when not backed by specialized hardware), there are plenty of disadvantages however. But maybe I missed something.

And once again pointing out how delegating software distribution to banks was a huge mistake. Fun fact: I recently realized that one vulnerability I reported (scheduled for disclosure on March 6th) is already fixed. In fact, the fix was published back in 2021. The reason I didn’t realize that: no bank I looked at offered a version of the software with this fix! I incidentally found the software vendor’s unadvertised download server which likely isn’t even meant for external use. That’s how I realized that I investigated a software version several releases behind the latest state.

Interesting news: TouchEn nxKey 1.0.0.82 has been sighted in the wild. While the vendor’s download server is still distributing version 1.0.0.78, Citibank Korea apparently started offering the new one two weeks ago. I wonder what they actually managed to fix…

Next article in this series deals with Wizvera Veraport, the South Korean application management application which already made the news due to being abused by North Korean hackers: https://palant.info/2023/03/06/veraport-inside-koreas-dysfunctional-application-management/

The good news: unlike with the previous disclosures, here the company didn’t waste time and actually managed to fix most issues I reported. The bad news: from the look of it, it will take years for the updated version to reach the users. And some issues are of fundamental nature and cannot really be addressed.

A number of flaws allowed Veraport to be misused for drive-by downloads:

· HTTPS not enforced, and even when used server identity wasn’t validated.
· Only means of checking application integrity is code signature, and self-signed applications are being accepted here.
· Even for invalid/missing signatures, the user is asked whether they want to install regardless.
· Websites can tell the application to start the installation automatically, without additional user interaction.
· Websites setting a 1x1 pixel background image essentially renders the application window invisible.

Additional issues:

· As applications are installed from banking websites, all banking websites have their keys to sign installation policies.
· No mechanism to revoke a leaked signing key or a problematic/malicious installation policy.
· One of the root certificates for policy signing uses a 1024 bit key and MD5.
· Full list of local processes exposed to arbitrary websites, for security applications also the application’s version number.
· Vulnerabilities in the local web server allow Service Worker installation (essentially amounting to persistent XSS).
· The classic of outdated open-source libraries: OpenSSL 1.0.2j anno 2016. And there is also mongoose 5.5 anno 2014. But that’s nothing compared to CppJson 0.5.0 anno 2010.

But the fundamental issue here is really arbitrary websites distributing applications, which is a very bad idea. Just one example: I checked whether they are distributing the current Veraport version, one month after a security update. In my sample of ten websites, only three did. Another three still distributed the previous release, and the other four were lagging behind by years – in one extreme case by ten years.

This will be the last article in this series for a while, so now I can finally focus more on doing some research and less on writing.

Now that I’ve quoted from Veraport’s change log, it has been removed from the server. Good ol’ security by obscurity. 🙄

I think that I’ll conclude the disclosure series at this point. I could finish already started research on another application, I could also look at more “security” applications used in South Korea. However, I see little point in helping improve the security of these applications – they rather need to be abolished altogether. And whatever impact my disclosures could make towards that goal, whatever awareness of the issues I could raise – this is done. So now it’s up to the South Korean society to take action.

And now on South Korean news: North Korean hackers abused some vulnerability in INISAFE CrossWeb EX application required for online banking and installed on more than 10 million computers. Apparently, they managed to infect a few hundred computers with malware. This isn’t an application I covered, but it shares some code with TouchEn nxKey which was my starting point.

Supposedly, the attack happened end of last year, before I even started publishing my articles. And: surprise, there is trouble distributing the patch. Despite the patch being available for more than a month already, only 40% of the companies installed it.

Which probably means: these companies put the patched version on their websites, but users still have to go and install it manually. These applications, despite being widely distributed, never bothered with auto-update. And that’s probably why this is in the news now, months after the attack was discovered by Korean authorities – telling people to update.

What a mess…

News article (in Korean): https://www.ddaily.co.kr/news/article/?no=260579

One would think, the way out would be obvious: if South Korea doesn’t want to abandon their “security” applications, they have to make auto-update mandatory. So the applications would check with the vendor regularly, and if an update is available it would be installed.

Yes, that’s how the rest of the world does it. But that would have been too simple.

So: let’s keep banking websites as software distributors because they do such a GREAT job at it. Of course, they cannot be expected to publish the updates on their websites timely. But some of them certainly will! So if the user installed the software from website A and then visits website B which has a newer software version, let it update automatically. Problem solved! 🤦‍♂️​

Wait, who are they quoting? CEO of Interezen, the makers of that IPinside spyware? Sure, why would he want to invest into a secure infrastructure when he can have all the data at virtually no cost for themselves?

https://www.enewstoday.co.kr/news/articleView.html?idxno=1650678