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.
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.
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?
Regarding 1 - SK has apparently been doing this since the 1990s. If it was just a matter of time before they realize this is a bad idea, I think they've had enough time to figure it out.
> 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.
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)