Yes, that was their first iteration. If you think that this went any better than communicating via a local web server, well… https://palant.info/2023/01/09/touchen-nxkey-the-keylogging-...
525 karma · joined November 7, 2016
Authorities can issue certificates for IP addresses. They merely cannot issue certificates for non-public IP addresses.
And: yes, maybe certificates for 127.0.0.1 should be disallowed altogether. But this creates a backwards compatibility issue, and I’m not sure browser vendors are willing to do it.
It’s not like I haven’t written about that before. Here is a particularly disastrous implementation: https://palant.info/2019/08/19/kaspersky-in-the-middle--what...
Yes, they successfully moved away from ActiveX. Not sure about SEED, I think I still saw it in one of the applications.
But there seems to be another contributing factor, the Korea Exchange Bank hacking incident in 2005. I explained it here: https://palant.info/2023/01/09/touchen-nxkey-the-keylogging-...
The news coverage is mixed. Some articles are positive about this and are asking about how to improve this sad state of affairs. Others are parroting statements from the affected companies: not actually bad, difficult to exploit, misunderstanding of the domestic market.
And as to politics, it’s too early to tell I think. This definitely generated much attention. Whether all this attention will actually lead somewhere is impossible to tell at this point.
And what if somebody else gets hold of their private key and uses it to MITM? I mean, it’s only South Korea, it’s not like they have a neighbor country which would be willing to abuse this kind of thing in targeted attacks…
In fact, the article does explain this. The CAs that are on this list by default have to comply with strict criteria making sure they cannot be abused. Anything that has been added externally, avoiding the usual processes of Microsoft/Mozilla/Apple, is suspect.
There are semi-legitimate use cases. One is intranets where you might want to have HTTPS on non-public resources. More commonly the company installs their own root CA however so that they can monitor all outgoing traffic. The other use case are antivirus applications – same reasoning here, they want to monitor all traffic.
And: yes, adding this certificate should normally be a user-initiated action. There is no way of preventing applications from automating it however. E.g. Firefox doesn’t have an API to install root CAs, so these applications package up NSS Tools in their installer, search for Firefox profiles during installation and add their root CA to any certificate database they can find.
Yes, that’s what I also assume. I didn’t bother verifying however that mixed content warnings are generally not an issue with localhost in any browser that South Korea cares about (e.g. Internet cough Explorer). Keep in mind that they have some rather adventurous ways to access the local web server, such as JSONP or communicating by posting to a frame.
First of all, thank you very much for informing about this issue. I still remember reading the article you wrote back in 2007, and it really helped me navigate this situation.
I doubt that people in South Korea care so little about it however. Otherwise articles citing an unnamed “famous hacker” about how all of this isn’t really bad and how I misunderstand the domestic security market wouldn’t have been necessary. It seems that lots of uncomfortable questions are being asked right now.
Whether this will be sufficient to produce some real change for the better is a different question of course. I sincerely hope that it will.
Yes, developing such an application would be fairly easy. From what I understand however, South Korea has laws against reverse engineering. So openly distributing this application would probably be risky, asking for lawsuits. Which doesn’t mean of course that no cybercrime gang (particularly those specializing in banking fraud) has such an application.
Quite a few people living in South Korea say exactly that: they keep an old laptop around only for online banking. And they try to avoid whatever else requires IPinside and similar applications.
This solves the issue at least partially on the individual level. But most people will in fact not do this.
As it says in the article, the application doesn’t check at all which website connects to it. It seems that they rely on their obfuscation, hoping that only eligible websites will be able to decrypt the data. Which, quite frankly, is a stretch.
Not really the same thing from what I can tell. Nitpicker is merely about isolating processes from each other, making sure keyboard input is only received by the currently focused process. Windows already does that, and so does Wayland in my understanding.
The goal here seems to be rather stopping applications with sufficient privileges to install a system-wide keylogger. Which Nitpicker likely solves implicitly – by providing an OS that isn’t exactly flexible in what it can do, meaning that security was bought by sacrificing usability.
Yes, default Content Security Policy of add-ons doesn’t allow eval(), and they likely couldn’t figure out how to change it. So it might be that they never even realized the security impact of these changes, which makes it even worse.
All applications I’ve looked into so far were communicating via a local web server. It wasn’t always WebSockets, one would also see JSONP or even submitting data to a frame.
They typically run the server on a fixed port. Port conflicts are rare in practice, so these applications don’t really care. In one case I’ve seen port probing however: if one port fails, websites will try to connect with subsequent ports.
As to best practices: I wouldn’t consider websites communicating with local applications best practice at all, by whatever means. It’s generally something to avoid.
I wrote this sentence three months ago. Since then people already pointed out that mobile banking is being used as escape hatch. The question is still: how many people do this? Everyone younger than 30? Or only 80% of them? Or only people who are moderately tech-savvy?
Are there any reliable statistics on that?
Not really. With C++, you don’t have to use manual memory management. In the typical scenario, C++ objects take care of memory without the developer having to think about it. And you have all kinds of smart pointers for the more complicated scenarios.
That doesn’t mean of course that there are no buffer overflows in C++, or use-after-free bugs. There is still plenty of room for mistakes. But C++ code following best practices tends to have far fewer vulnerabilities than comparable C code.
Did you notice the plain HTTP (no SSL) download URLs for the “security software”? If not, you are missing out!
I think that this issue is really universal across all banks in Korea. I was told (but couldn’t confirm) that this is a liability question. Supposedly, there was a court ruling that held a bank liable for a customer’s losses due to lack of security precautions. So now all of them implement “security precautions” to avoid liability.
Thank you for the hint, I fixed the typo. Not being a native speaker, I had to ask a search engine what I did wrong in this sentence. :-)
Where did you get the idea that direct network access is required? To quote the article: “large applications interacting with websites in complicated ways.”
Most attacks can be launched by an arbitrary website. And given the number of people affected, this is way worse than any individual server being vulnerable. Besides, I’m definitely not going to look for server-side vulnerabilities without permission.
Yes. The number of iterations is presumably stored in the same customers database that they stole. Even if not: the number of iterations can be queried via a public API, anyone can do it if they know the email address.