As in many other countries, banking in Korea is a state-regulated industry. However, Korea's regulatory system rule downs to the smallest detail.
For example, in the Digital Signature Act(전자서명법), a content that allows only digital certificates in the form of files called authorized certificates(공인인증서) to be used for certification was added in 1999. (The contents were revised only in 2020.) As a result, most banking was accessible only using IE and Active-X. Now that Active-X cannot be used, various software is installed using separate installation files.
Korea's financial regulators are strict, but Korean politicians and media are paternalistic, so if there's a problem with finance, most of them try to side with financial consumers. For example, the issue of password leakage due to a keylogger installed on a user's PC is considered to be a bank problem, not a user problem. For this reason, banking websites require all kinds of security software, such as keylogger checking programs and firewalls. (This problem is gradually being mitigated.)
The problem with Korean security software is that the buyer of the security software (in this case, the bank) only requires that it meet the requirements of laws and regulatory authorities, so there is little room for improvement. Security software can be delivered only after CC certification (CC 인증) issued by the National Intelligence Service(국가정보원). By the way, the NIS is interested in which encryption algorithm is used (whether Korean algorithms such as SEED, ARIA, LEA, etc.), but it is not interested in whether Visual Studio Runtime is 2008 or 2019.
Also, financial institutions do not take cybersecurity issues seriously. For example, when I was in the security industry, a financial company asked for security software for ATMs running Windows XP SP2. Even at that time, Windows XP was EOL, and our security software was only supporting Windows XP SP3 or later. Significantly, the company suffered a cyber attack a few years ago that paralyzed its entire financial services for several days.
Most of the things I mentioned here refer to Korean-language materials, so giving references is somewhat limited.
you cannot solve problems by giving authority to people who are motivated to solve them, but do not understand what the problem is, so that they can tell the people who do understand the problem what to do
anyone who has dealt with pci-dss presumably knows this but that is a much smaller group than all south koreans
think of that the next time someone contrasts bitcoin with the heavily regulated conventional banking system
If the regulations said banks had to be secure by ‘taking all due care’ and follow ‘best practices’ and such, this wouldn’t be such an issue. That gives room for improvements and for problematic standards to be weeded out over time.
It sounds like the government instead said banks had to be secure by using (for example) SSL 1.0 with a 64-bit key. Because the specified the exact how, that’s what banks did. And when that how was broken the law wasn’t changed, so banks still do the old thing.
And when the old thing (Active-X) stopped working they invented new ways to do the old thing with local proxies. Because the law says they must and are safe if they do.
This is the danger of legislating an exact how. It may be the right thing sometimes, but it can also go sideways.
PCI-DSS is not a government body, nor is legally mandated by the government. It's not the government.
Just watching the largest fraud trial in history unfold over at FTX.
Bitcoin deals with any and all questions of fraud by dumping them on the victim. No help and no recourse. Very libertarian, but of course routinely results in people losing life changing amounts of money.
Of all these solutions, the numbers card gives me the most peace of mind: even if my machine is fully compromised and all my passwords and certificates stolen, the attacker would likely need very long-term access (or access to the bank's server) to get all 35 numbers from the card. (If the attacker compromises the card by attacking the bank, I trust attackers will reveal themselves going after larger accounts). As long as I keep this piece of laminated plastic private and visit a bank branch to replace it every 17 to 35 transactions, I can have some peace of mind, at least regarding my bank account.
[1] There have since been efforts to streamline mobile payments, which I avoid because it leaves the phone as a single point for compromise.
I think you're overestimating how much security this provides and missing a very simple workaround: the attacker can simply wait until you preform a transfer, and then replace the intended recipient detail with theirs. For instance, if alice was sending funds to bob, and the attacker controls the machine, they can simply replace the recipient to malory, while still displaying bob to the user.
Some banks solve the transfer authorization issue using an external bit of hardware that you type the transaction details into and it gives you a signature OTP.
If it continues growing (~40% y/y) at this kind of rate then it will soon outstrip any profits from retail banking (which is pretty low margin as it is compared to banks investment and commercial arms).
I wouldn't be surprised if we see UK banks exiting retail banking because of this.
It's, I think, even worse than China's philosophy, because China is young and pretentious in capitalism, while Korea seems more dishonest and cowardly.
Isn't this also the case in the US? You're generally not liable for fraudulent transactions, as long as you took "reasonable" measures to prevent the fraud from happening. Given the technical ineptitude of the average person, banks/regulators will rarely blame the consumer.
You mentioned about PC environments, What's up with mobile? Specifically with Android & iOS; Do you have to install rootkits there too for online financial transaction?
In other words, they're authoritarians at heart. They want complete control over the environment and don't want users to have any personal responsibility.
I wonder if the author should extend the 90-day disclosure window to account for this red tape.
I've had an opportunity to interact directly with Korean security culture in my time working for Samsung.
I am sure there exists more secure examples out there, but I saw some extremely bad practices like trivially-reversible password shuffling used throughout the entire org. Anyone with access to a certain manufacturing database and knowledge of a particular stored procedure could immediately reverse all passwords and typically use them to go sideways into other engineering/facility systems.
They always seemed substantially more interested in the theatrical aspects of security than focusing on any first principles. Lots of time was spent talking about reactionary crap like a fleet of hardware ARP sniffers installed throughout the network. Not a lot of time was spent talking about PBKDFs, system boundaries and determinism.
- https://en.wikipedia.org/wiki/SEED - https://en.wikipedia.org/wiki/ARIA_(cipher)
Of course, it's close to technology debt now.
CNet back in 2007:
https://www.cnet.com/tech/tech-industry/about-south-koreas-d...
https://it.slashdot.org/story/07/01/26/1455224/why-south-kor...
Some quick observations:
- That page intentionally disables right-click! Just by putting `oncontextmenu="return false"` on the <body> tag. This gives me flashbacks to the late 90s when this technique was used to make it harder for users to copy images or inspect HTML source. Browsers all have built in developer tools so pretty silly seeing it now.
- The JS included on that page is a mix of heavily obfuscated code[0] and completely unminified code with all the internal comments left in[1].
- I was impressed that the required software seems to support Fedora and Ubuntu/Debian as well as macOS and Windows.
- One of the installations is checked by making a JSON-P call (another old tech flashback!) to `https://lx.astxsvc.com:55921/ASTX2/hello?...`. This works because lx.astxsvc.com resolves to 127.0.0.1 so you're just hitting your localhost. Presumably the installed software checks the referer header to ensure only citibank is making these requests.
[0] https://www.citibank.co.kr/aB-IFIZu8Pd7Zd1yjboonwGx/uYfEz6Dp...
[1] https://www.citibank.co.kr/3rdParty/wizvera/veraport/install...
Did you notice the plain HTTP (no SSL) download URLs for the “security software”? If not, you are missing out!
btw, love your article! Such an interesting obscure little corner of the world of technology. Hope to read more.
Note for the author: small typo at "requires outmost care".
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. :-)
You already wrote as much in the article, but (AFAIK) the reality is even worse: there were court rulings that exonerated banks, as long as they followed the standard "security practices." Some hacker from China could access the bank's website from a suspicious IP, drain all the money from a poor guy's account, but the bank has zero obligation to do anything as long as it mandated that all users install half a dozen security plugins all the time.
Do you think getting out of this mess could be as simple as government regulationL: banking (and government and other necessary websites) are not allowed to require installation of plugins or other software to log in.
SMS 2FA is pretty robust, as biometrics on the phones reduce the number of SMSes sent.
You would hope that these would be somewhat more secure as this may have required a 're-write' as the article suggested.
Though even with mobile apps you sometimes have to install some 3rd party 'anti-virus' software that probably amounts to spyware. But hey you can either lump it or leave it.
They do at least try to make you feel like it's secure. To set up mobile banking you need at least 3 different passwords and need to perform 2fa 3 times as well.
They have 'front end' security too, such as each time you enter a pass code the keyboard is in a different arrangement.
https://privsec.dev/posts/android/banking-applications-compa...
Does it mean none are usable on a modern clean Android? Or is there a total Samsung monoculture? Something else?
https://www.fireeye.com/content/dam/fireeye-www/global/en/bl...
I just looked up CVEs for it. I only see 2 in 2017. This is not a good thing, a complex word processor, even if it was rewritten in a memory safe language would have at least some low level non-memory vulns in 6 years!
To this day, I can only do online banking with Internet Explorer 11. When logging in, of course the password field doesn't permit pasting. I have a couple ActiveX controls and certs installed, but I've forgotten which ones so I'll just have to keep that old laptop around. The one bright spot is that large transactions do require a USB dongle.
At least one other website I've used (perhaps Alipay?) required you to install a browser plugin simply to be able to "securely" enter your PIN.
Rewinding back to 2014, the brand new government website for buying train tickets[0] didn't have an SSL cert signed by any of the trusted authorities. If you wanted to buy tickets securely, you needed to download a zip file (over http) that contained 1) a self-signed root cert, and 2) a Microsoft Word document explaining how to add this to your OS's trusted root cert store and how this is totally legit and secure.
[0] https://www.techinasia.com/chinas-official-train-ticket-site...
Hmm the app for my bank is 2/5 stars and somehow 360MB. I'll avoid it unless I absolutely need it.
Straight-up government malware right there.
Absolute steaming garbage.
Its "anti keylogging" functionality could be bypassed trivially, as could its various screen hijacking tricks designed to defeat some methods used by the banking trojans that were common at the time.
I see that snake oil industry lives on in Korea :/
Very excited to see the results of OP's work (the disclosures).
Once I saw this: >This starts with a simple fact: some of these applications are written in the C programming language, not even C++.
I had to stop reading and come here to see if anyone else got annoyed by it. Seriously? "not even c++" are we still in 1990s?
As the author notes, they're not just being snobby about languages, the main issue with C from a security POV is the total lack of memory safety and the consequent vulnerability to buffer overflows.
I wouldn't be surprised if a lot of this was written in the 90s or early 00s originally, and then "minimally maintained" only when required.
Are there any stats comparing levels of banking-related cybercrime in South Korea with other jurisdictions?
Note this is written by Norman Feske, who later went on to develop Genode[1], and continues to be its main developer today.
Note to self: never move to Korea. Or at least never use Korean bank (can you survive on cash and Bitcoin?)
https://krebsonsecurity.com/2021/06/adventures-in-contacting...
A lot of countries seemingly did not have access to American encryption technologies or did not trust them — arguably for good reasons[0] — which has lead to this hodge-podge of homegrown security.
[0] https://www.washingtonpost.com/graphics/2020/world/national-...
> KrebsOnSecurity recently had occasion to contact the Russian Federal Security Service (FSB), the Russian equivalent of the U.S. Federal Bureau of Investigation (FBI).
The FSB is not equivalent to the FBI, it's the successor to the KGB. If it's equivalent to any other country's org, look to the Gestapo.
Nitpick for OP (@palant): on mobile Safari (haven't checked any desktop browsers), the images embedded into the post appear stretched out vertically (i.e., too "slim"). It is still technically readable, but very noticeable and jarring. This only applies to the images when embedded, opening direct image URLs in a dedicated browser tab renders them properly without any stretching. I suggest checking CSS, but that's just my first guess and could be entirely wrong.
I think just keeping the same horizontal size of images, but reducing the vertical size, would make it much more aesthetically pleasing + readable.
1. Give SK a few months/years until it realizes it is losing billions revenue nationally due to hacking by foreign entities and it will naturally invest in its application security landscape.
2. Reconsider your position on SK's current situation by factoring actual risk in the equation (likelihood of threat, in particular). What you seem to have discovered are client-side vulnerabilities that would require direct network access to the client machines to be exploited (i.e., no firewall, no NAT, no etc.). First, these limitations greatly reduce the attack surface and second, they may actually cost the attacker more to exploit than simply sending a well-crafted message with an attachment to click on.
I would be much more convinced by your conclusions if you added elements that would support the hypothesis that the situation is similar (or worse) server-side.
(edit: removed ugly formatting)
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.
It’s so weird how many people (developers!) actually seem to believe this.
Websites can send bad stuff to local ports!
Zoom fell foul of almost exactly this before it became popular during the pandemic. https://www.theregister.com/2019/07/11/apple_removes_zooms_d...
We don't know what a user has installed on their local machine, so a bank mandating that users install an application with known vulnerabilities has reduced its security posture to whatever client-side chicanery is happening on a given computer. This may shift liability (i.e., it's not the bank's fault if malware intercepts traffic sent to a localhost web server) but does not improve security.
As a user, you might be able to use software with known client-side vulnerabilities safely by constructing isolated sandbox environments for each permutation of required client-side "security" software, but it's unrealistic to expect everyday users to do so.
