[HN Gopher] South Korea's online security dead end
___________________________________________________________________
South Korea's online security dead end
Author : dirkf
Score : 112 points
Date : 2023-01-03 14:01 UTC (8 hours ago)
(HTM) web link (palant.info)
(TXT) w3m dump (palant.info)
| Roark66 wrote:
| Oh boy...
|
| 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?
| prottog wrote:
| This always bothered the hell out of me when interacting with
| Korean websites, especially online banking. I believe in addition
| to the factors that the article listed, there are several laws in
| place that mandate this chicanery, at least for banking.
| richbell wrote:
| This reminds me of krebsonsecurity's experience attempting to
| contact the FSB.
|
| 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-...
| wmf wrote:
| The problems aren't with cryptography though; they're basic
| software engineering failures.
| richbell wrote:
| They're problems with cryptography insofar as they are
| problems that can be traced back to a distrust of Western
| cryptography and a desire to create domestic security
| products.
| [deleted]
| black7375 wrote:
| One of the reasons for maintaining is to transfer consumers to
| security responsibility.
| michael1999 wrote:
| This is the world the Clipper-chip minds offer us. I'm happy we
| dodged that bullet.
| [deleted]
| filoleg wrote:
| Overall an interesting post, thanks for sharing.
|
| 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.
| [deleted]
| physicles wrote:
| This mirrors the situation in China, likely for similar reasons.
|
| 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...
| [deleted]
| ThePowerOfFuet wrote:
| > 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.
|
| Straight-up government malware right there.
| bob1029 wrote:
| > This prompted South Korea to develop their own cryptographic
| solutions.
|
| 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.
| black7375 wrote:
| In 1999, the adoption of its own 128bit algorithm was
| reasonable.
|
| - https://en.wikipedia.org/wiki/SEED -
| https://en.wikipedia.org/wiki/ARIA_(cipher)
|
| Of course, it's close to technology debt now.
| gred wrote:
| Very interesting read. I'm looking forward to the details in the
| followups (1/9, 1/23, 3/6). However, I'm surprised that there are
| no KR banks who build their reputation on their technical acuity
| and who have eliminated (or avoided) reliance on these types of
| applications. The markets I'm familiar with tend to have a few
| banks who have a reputation for good websites, good apps, etc. Or
| perhaps that bit of context was omitted, and these types of banks
| _do_ exist in KR?
|
| Note for the author: small typo at "requires outmost care".
| palant wrote:
| _Disclaimer_ : I am the author of this article.
|
| 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. :-)
| 0xCMP wrote:
| aside: I think the year on the dates is wrong :)
| palant wrote:
| Ah, yes. Fixed. :-/
| acchow wrote:
| Thanks for the writeup.
|
| 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.
| palant wrote:
| That's in fact what I suggest in my blog post. But I am
| pretty certain that it is far from simple. I'm told that
| the previous Korean government already tried to tackle this
| issue and failed. It's a huge and complicated mess.
| csydas wrote:
| My information here may be outdated, but when I was in
| Seoul for awhile, it wasn't limited to just banking apps,
| many services had similar requirements for specific
| plugins, even requiring Internet Explorer 11 and a bunch
| of plugins for that.
|
| I remember trying to get tickets for an event, and it was
| not possible within MacOS at the time due to the various
| Windows only requirements. I remember even having to re-
| download another version of Windows 7 as Tiny7 had
| various Windows Services removed that for some reason the
| plugins/apps relied on.
|
| My cynical guess is that the plugins/apps include user
| data/telemetry that the companies get a cut for, but of
| course this is just supposition. It's entirely possible
| it's just some liability thing that has become entrenched
| in Korean IT, who knows.
|
| But the practice was everywhere.
| yongjik wrote:
| > Supposedly, there was a court ruling that held a bank
| liable for a customer's losses due to lack of security
| precautions.
|
| 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.
| wmf wrote:
| Are there any US banks that are actually secure? AFAIK they're
| all using SMS 2FA or worse.
| second_brekkie wrote:
| I live in Korea. In my experience pretty much everyone I know
| uses banking apps which you can do everything through, not online
| banking through a browser.
|
| 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.
| r2vcap wrote:
| Disclaimer. I am Korean and currently live in Korea. Online
| banking in Korea is very poor, so even though I code on Linux and
| macOS, I use Windows for internet banking.
|
| 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(jeonjaseomyeongbeob), a
| content that allows only digital certificates in the form of
| files called authorized certificates(gongininjeungseo) 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 injeung) issued by the
| National Intelligence Service(guggajeongboweon). 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.
| xwolfi wrote:
| I work in Hong Kong, in the securities industry. We interact a
| lot with Korean laws, and all of APAC, and Korea is special in
| that they enjoy nonsensical rules that provide no protection to
| anyone except the politicians who came up with them and can
| argue they did do "something".
|
| 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.
| nokya wrote:
| I see two candidate alternatives to your "Getting out of the dead
| end":
|
| 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)
| lfodofod wrote:
| > What you seem to have discovered are client-side
| vulnerabilities that would require direct network access to the
| client machines to be exploited
|
| It's so weird how many people (developers!) actually seem to
| believe this.
|
| Websites can send bad stuff to local ports!
| g_p wrote:
| Indeed - this was my first concern. How many of these local
| web servers are properly implementing CSP and the myriad of
| other protections you need to (securely) run a local web
| server that isn't vulnerable to CSRF from other origins etc?
|
| 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...
| palant wrote:
| _Note_ : I am the author of this article.
|
| 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.
| giaour wrote:
| > What you seem to have discovered are client-side
| vulnerabilities that would require direct network access to the
| client machines to be exploited
|
| 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.
___________________________________________________________________
(page generated 2023-01-03 23:00 UTC)