This is extremely interesting and something new I learned today! Online banking here in Germany is much better and doesn’t require any separate devices; simply a separate TAN generator device that is effectively airgapped and unhackable and can be used with any client device and operating system. Banks push their apps but are required by law to support TAN generators.
South Korea has an interesting history here. They were hit by the US decision to embargo crypto and so were restricted to insecure cyphers in SSL from any US-based browser manufacturers (i.e. all of them). To work around this, they ended up creating an ActiveX control that did strong encryption (or, at least, claimed to - I’ve no idea what it actually did) and mandated that all banks use it for Internet banking. This locked non-Windows, non-IE browsers out of the market in South Korea for a long time.
Same experience with Postbank in Germany, really happy about that.
A bit off-topic, but I found the Czech Republic’s Fio Banka offering a familiar yet unsettling way to do authentication: Public / Secret Key authentication in place 2FA, which I opted for. Similar to SSH’ing into a server and putting your public key into ~/.ssh/autherized_keys, you generate your Private / Public Key pair and give your Public key to the bank teller via a USB stick, that they plug into their system to copy off your public key. My own USB stick connected to a foreign bank’s system is propably about as close as I will ever come to having a pen-testing job.
This is quite a shitshow and a fun read, esp the part about being able to crack the RSA encryption in 2 hours.
But this bit:
When a banking website in South Korea wants to learn more about you, it will make a JSONP request to localhost:21300.
I’ve never really been able to get my head around Web security, so I’m probably showing off ignorance here, but: how is it that a remote web page is allowed to make a request to localhost on a different port? That seems pretty dangerous, for the same reason that connecting to other hosts on the client’s LAN is dangerous. There are plenty of apps that run as localhost-only web servers you access via a browser; heck, I’ve written a couple.
In general, CORS restrictions would require the server to specifically allow the given origin and method to make the request, or else the browser would deny it. In this case, they’re using JSONP though; I guess that’s somewhat less dangerous because it’s only a GET request and presumably would only really do anything if the server responds with Javascript to said request.
Listening on localhost:21300 is a lot easier to pull off unseen than sneaking in Greasemonkey or opening the browser console. I don’t think Windows warns you if an application does this (I know OAuth clients often also listen on localhost). In other words, it’s an attractive vector for malware.
how is it that a remote web page is allowed to make a request to localhost on a different port?
In general, websites are allowed to make GET requests to any other site. There’s rules about authentication and cookies (so attacker.com can’t steal your money with GET bank.com/authtoken.php), but an unauthenticated GET is allowed and the server is expected to ensure its own safety.
When the server doesn’t ensure GET requests are safe – for example, if it allows a GET request to exfiltrate sensitive data or modify content – then things can go very bad very quickly. I’ve seen people (employed professional software engineers!) write servers that had GET endpoints for “execute provided code” or “send RPC with provided content”.
That seems pretty dangerous, […] There are plenty of apps that run as localhost-only web servers you access via a browser; heck, I’ve written a couple.
Running unauthenticated HTTP on localhost is both common and very dangerous if the server wasn’t carefully written for that use case.
You can make GET and POST requests, but you can’t see the responses and you can’t use very many headers. And (in all non-safari browsers) localhost is considered as a secure origin so it’s exempt from mixed-content blocking.
You can make GET and POST requests, but you can’t see the responses
As mentioned in the article, JSONP is a common way for servers to allow clients to read response data from cross-domain GET requests.
The unfortunate thing about JSONP (vs more modern CORS) is that the server can’t inform the user agent of which origins are allowed to read response data.
Ok, if you can’t see the responses that’s less dangerous. I was thinking that an XHR or fetch call could talk to localhost.
So obvs I can put an img with src=“localhost:///…” on my page, but sending a POST would require user intervention like clicking a button. Still easy to do.
I suppose the fix for my micro-server is to deny any request with an Origin header that isn’t from localhost?
esp the part about being able to crack the RSA encryption in 2 hours
The big question in my head after reading this is whether having access to this information would make it possible to create a dummy version of the program that responds with canned data and would allow legitimate users to connect to the banking sites without installing their malware.
Criminals are almost certainly already doing this, but why not allow everyone to benefit from this research?
Right, I realized I was getting confused between the RSA key that encrypted the body vs the TLS cert which was used for HTTPS on the localhost server. You only need to crack the RSA key if you want to construct your own data to send back, and I don’t think that’s really necessary.
This is extremely interesting and something new I learned today! Online banking here in Germany is much better and doesn’t require any separate devices; simply a separate TAN generator device that is effectively airgapped and unhackable and can be used with any client device and operating system. Banks push their apps but are required by law to support TAN generators.
South Korea has an interesting history here. They were hit by the US decision to embargo crypto and so were restricted to insecure cyphers in SSL from any US-based browser manufacturers (i.e. all of them). To work around this, they ended up creating an ActiveX control that did strong encryption (or, at least, claimed to - I’ve no idea what it actually did) and mandated that all banks use it for Internet banking. This locked non-Windows, non-IE browsers out of the market in South Korea for a long time.
Very interesting! Thanks for sharing!
That’s interesting. I miss TAN devices and AFAIK EU law is pushing banks to phase them out.
Many banks only offer SMS as 2FA. That’s not a second factor. Furthermore, SIM cloning is a very common issue.
Here in Germany SMS TAN has been phased out for years.
Same experience with Postbank in Germany, really happy about that.
A bit off-topic, but I found the Czech Republic’s Fio Banka offering a familiar yet unsettling way to do authentication: Public / Secret Key authentication in place 2FA, which I opted for. Similar to SSH’ing into a server and putting your public key into
~/.ssh/autherized_keys, you generate your Private / Public Key pair and give your Public key to the bank teller via a USB stick, that they plug into their system to copy off your public key. My own USB stick connected to a foreign bank’s system is propably about as close as I will ever come to having a pen-testing job.This is quite a shitshow and a fun read, esp the part about being able to crack the RSA encryption in 2 hours.
But this bit:
I’ve never really been able to get my head around Web security, so I’m probably showing off ignorance here, but: how is it that a remote web page is allowed to make a request to localhost on a different port? That seems pretty dangerous, for the same reason that connecting to other hosts on the client’s LAN is dangerous. There are plenty of apps that run as localhost-only web servers you access via a browser; heck, I’ve written a couple.
In general, CORS restrictions would require the server to specifically allow the given origin and method to make the request, or else the browser would deny it. In this case, they’re using JSONP though; I guess that’s somewhat less dangerous because it’s only a GET request and presumably would only really do anything if the server responds with Javascript to said request.
In other words: listen on localhost:21300 and you can execute arbitrary Javascript on any Korean banking site.
IMHO this is a bigger issue than the browser allowing a remote web page to do
<script src="http://localhost…(which is still very bad)Sure, but you could already use Greasemonkey or just open up the browser console and type in whatever arbitrary Javascript you want
Listening on localhost:21300 is a lot easier to pull off unseen than sneaking in Greasemonkey or opening the browser console. I don’t think Windows warns you if an application does this (I know OAuth clients often also listen on localhost). In other words, it’s an attractive vector for malware.
In general, websites are allowed to make GET requests to any other site. There’s rules about authentication and cookies (so
attacker.comcan’t steal your money withGET bank.com/authtoken.php), but an unauthenticated GET is allowed and the server is expected to ensure its own safety.When the server doesn’t ensure GET requests are safe – for example, if it allows a GET request to exfiltrate sensitive data or modify content – then things can go very bad very quickly. I’ve seen people (employed professional software engineers!) write servers that had GET endpoints for “execute provided code” or “send RPC with provided content”.
Running unauthenticated HTTP on localhost is both common and very dangerous if the server wasn’t carefully written for that use case.
A well-known example of this going wrong (discovered by Project Zero) is TrendMicro node.js HTTP server listening on localhost can execute commands.
You can make GET and POST requests, but you can’t see the responses and you can’t use very many headers. And (in all non-safari browsers) localhost is considered as a secure origin so it’s exempt from mixed-content blocking.
As mentioned in the article, JSONP is a common way for servers to allow clients to read response data from cross-domain GET requests.
The unfortunate thing about JSONP (vs more modern CORS) is that the server can’t inform the user agent of which origins are allowed to read response data.
You still can’t see the responses, you just observe side effects like function calls for js, style changes for CSS, and layout changes for images.
Ok, if you can’t see the responses that’s less dangerous. I was thinking that an XHR or fetch call could talk to localhost.
So obvs I can put an img with src=“localhost:///…” on my page, but sending a POST would require user intervention like clicking a button. Still easy to do.
I suppose the fix for my micro-server is to deny any request with an Origin header that isn’t from localhost?
The big question in my head after reading this is whether having access to this information would make it possible to create a dummy version of the program that responds with canned data and would allow legitimate users to connect to the banking sites without installing their malware.
Criminals are almost certainly already doing this, but why not allow everyone to benefit from this research?
Why not just serve from a library of replays? That’s much easier than actually worrying about writing a bunch of code.
Right, I realized I was getting confused between the RSA key that encrypted the body vs the TLS cert which was used for HTTPS on the localhost server. You only need to crack the RSA key if you want to construct your own data to send back, and I don’t think that’s really necessary.
Should be mentioned that this is in South Korea.
I assume it’s due to both calling themselves Korea. It is mentioned in the first sentence though.