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:

news.kbs.co.kr/news/view.do?nc…
news.kbs.co.kr/news/view.do?nc…

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…

[집중취재]② 은행 보안프로그램 허점

⊙앵커: 개인고객들은 반드시 보안프로그램을 설치해 실행해야 최소한의 안전을 보장받을 수 있습니다. 은...

^{유석조 (KBS뉴스)}

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…

palant.info/2023/01/09/touchen…

TouchEn nxKey: The keylogging anti-keylogger solution

TouchEn nxKey is supposed to combat keyloggers. Instead, this application made writing a keylogger extremely simple, allowed attacking banking websites and more.

^{Almost Secure}

Note that despite this article being already very long I’ve still left out a lot. Like a Citibank Korea page citibank.co.kr/CrdOsvcSecu9002… 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.

enewstoday.co.kr/news/articleV…

‘취약점’ 저격 당한 국내 보안업계 “국내 환경 이해 부족”

[이뉴스투데이 김영욱 기자] 세계 점유율 1위 광고차단 프로그램 ‘애드블록 플러스(Adblock Plus)’ 개발자 블라디미르 팔란트(Wladimir Palant)가 국산 보안 프로그램 취약점을 공개하며 국산 보안 솔루션 문제점이 화제다. C언어를 사용하는 등 과거에 머물러 해커들로부터 공격받기 쉽다는 것. 그러나 국내 보안업계는 한국 보안 시장에 대한 이해 부족에서 비롯한 잘못된 지적이라는 반응이다.

^{이뉴스투데이}

The article on TouchEn nxKey is now also translated to Korean, thanks to @alanthedev: github.com/alanleedev/KoreaSec…. 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.

KoreaSecurityApps/01_touchen_nxkey.md at main · alanleedev/KoreaSecurityApps

Contribute to alanleedev/KoreaSecurityApps development by creating an account on GitHub.

^GitHub

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.

palant.info/2023/01/25/ipinsid…

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.

IPinside: Korea’s mandatory spyware

Banking websites in South Korea can only be used with IPinside installed. This application collects lots of data about the user, and it makes that data accessible to each and every website. The protection is inadequate.

^{Almost Secure}

Continuing this series with a more basic flaw, which appears to be common practice for South Korean “security” applications: palant.info/2023/02/06/weakeni…

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.

Weakening TLS protection, South Korean style

TLS protocol is fundamental to internet security. All South Korean security applications add their own “trusted” Certificate Authorities however, weakening this protocol severely.

^{Almost Secure}

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.

Published one more high-level overview before I move on to the next (very long) disclosure in two weeks: palant.info/2023/02/20/south-k…

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.

South Korea’s banking security: Intermediate conclusions

South Korea’s online banking relies on a number of “security” applications. Here I am looking into whether these applications can potentially make things more secure.

^{Almost Secure}

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: palant.info/2023/03/06/verapor…

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.

Veraport: Inside Korea’s dysfunctional application management

While Wizvera Veraport is supposed to manage security applications easily, it suffers from a number of design flaws. In the worst case, these can lead to arbitrary websites installing malicious applications without the user noticing.

^{Almost Secure}