Hackers Looking Into Injecting Card Stealing Code on Routers, Rather Than Websites (zdnet.com) 25
Security researchers at IBM have found evidence that hackers have been working on creating malicious scripts they can deploy on commercial-grade "Layer 7" routers to steal payment card details. From a report: This discovery is a game-changer in what researchers call Magecart attacks, also known as web skimming. These are attacks where hackers plant malicious code on an online store that records and steals payment card details. Until now, Magecart-specific code was only delivered at the website level, hidden inside JavaScript or PHP files. However, this new discovery is an escalation of Magecart attacks to a new level, where the malicious code is injected at the router level, rather than being added by hackers on outdated websites.
Layer 7, or L7, routers are a type of commercial, heavy-duty router that's usually installed on large networks, such as hotels, malls, airports, casinos, government networks, public spaces, and others. They work like any other router, except with the added benefit of being able to manipulate traffic at the seventh layer (application level) of the OSI networking model -- meaning they can react to traffic based on more than just IP addresses, such as cookies, domain names, browser types, and more. In a report published today, researchers with the IBM X-Force Incident Response and Intelligence Services (IRIS) team said they found evidence that a well-known hacker group has been testing Magecart scripts to deploy on L7 routers.
Layer 7, or L7, routers are a type of commercial, heavy-duty router that's usually installed on large networks, such as hotels, malls, airports, casinos, government networks, public spaces, and others. They work like any other router, except with the added benefit of being able to manipulate traffic at the seventh layer (application level) of the OSI networking model -- meaning they can react to traffic based on more than just IP addresses, such as cookies, domain names, browser types, and more. In a report published today, researchers with the IBM X-Force Incident Response and Intelligence Services (IRIS) team said they found evidence that a well-known hacker group has been testing Magecart scripts to deploy on L7 routers.
Even works with TLS (Score:5, Insightful)
Proper deep inspection firewalls will conveniently break TLS. It is common for many organizations to force installation of a company root certificate on all devices. The firewalls use that certificate to do man-in-the-middle on all TLS in order to do antivirus and dataleak prevention and such.
What could possibly go wrong?
Re: (Score:3)
Security Theater is the name of the game.
The very act of protecting yourself in certain ways becomes a vulnerability.
But do remember.. Deep Packet inspection is also being used to spy on internal activity, not just external.
It is also a sign that TLS as a protocol is fundamentally broken as well. It should be constructed so that only the 2 endpoints communicate in a way that any MITM attack compromise results in a failure to communicate.
Re: (Score:3)
It should be constructed so that only the 2 endpoints communicate in a way that any MITM attack compromise results in a failure to communicate.
One of the endpoints in this scenario is consenting to the compromise. How do you propose designing TLS in a way that neither endpoint can do that?
Banks do it (Score:2)
by using a physical device to do the decryption and signing.
bank actually do that with their 2FA
(eg PhotoTan)
but it boils down to just replacing de compromised endpoint (computer with employer's MITM friendmy certificate) with a different one (the bank's 2FA device).
Re: (Score:3)
Why would an employer be silly enough to allow a non-compromised endpoint onto the network?
Do note evil ? (Score:1)
Why would an employer be silly enough to allow a non-compromised endpoint onto the network?
Because they still have a human soul ?
Re: (Score:1)
TLS 1.3 does address __some__ of the MITM concerns. Out of band decryption where if you have the private key is not possible because TLS 1.3 uses the Diffie Hellman key exchange to implement perfect forward secrecy.
You can still do a MITM by generating a local cert that is trusted by the internal clients but the proxy is more limited in what it can see and do with the TLS 1.3 conversation. It can't see the certificate (because it is encrypted) so it can't decide to whitelist certain sites. It is an all or n
Re: (Score:2)
Servers should require client certificates and blacklist client certs that are seen coming from multiple sessions, hosts, etc. simultaneously, and block any that are signed under some other common cert or by some "trusted" authority. Self-signed certs only.
Oh, what's that? You'll have to actually securely establish trust and exchange cert info in the real world? GOOD!!!
Re: (Score:2)
In other words, the company has to create a cert for every machine on his network, stuff those certs into the transparent proxy that cracks open the encryption and MITMs the traffic, and business continues as it did before.
Re: (Score:2)
Security Theater is the name of the game.
That's why you make damned sure you understand where your bank stands viz. fraud and theft, have insurance if possible, and check your transactions regularly. Then it becomes the bank's problem, not yours. If they choose to do nothing about it well that's on them. Eventually though they will get fed up and bring consequences for the fraudsters and real security to bear.
Re: (Score:3)
This is why I always RDP into my home computer when on a corporate network with such setups.
Re: (Score:2)
I suspect RDP encryption is just as easy to break although. Maybe you should use a SSH tunnel, taking care of verifying the host key presented or a VPN to your home on top of that.
Re: (Score:2)
Yea but the data is much harder to parse. Parsing HTTP is trivial since it's all text. You'd be able to catch credit card number strings with a simple regular expression. RDP does present a host key as well.
Re: (Score:2)
Proper deep inspection firewalls will conveniently break TLS. It is common for many organizations to force installation of a company root certificate on all devices. The firewalls use that certificate to do man-in-the-middle on all TLS in order to do antivirus and dataleak prevention and such.
What could possibly go wrong?
Well, typical layer 7 routers include load balancers and reverse-proxies and they don't always break encryption, at least at the https level since https now support Server Name Indication (SNI) to allow hosting multiple TLS web sites on a single IP. When using SNI, the host name is always sent in plain text.
Granted although, you would need to decrypt to inject or read other content than the host name, like load balancing cookies or http session id so the next request goes to the same server.
As well, it is
Re: (Score:2)
even so if you are doing business over the web you're dealing with such stuff, they have the site certificates & keys too. They route, load balance, have application firewalls (to block naughty query strings and such)
take one of those babies over and it's $$$$$$$
Re: (Score:2)
>> They work like any other router, except with the added benefit of being able to manipulate traffic at the seventh layer (application level) of the OSI networking model -- meaning they can react to traffic based on more than just IP addresses, such as cookies, domain names, browser types, and more.
"They work like any other router" - thanks, Karen.
Re: (Score:2)
"Routing" can mean just about anything these days. It's even commonly a term used inside web services to describe how certain URLs get sent to certain chunks of handler code.
Moreover, almost all "routers" sold in the networking space these days can do a a bare minimum of layer 4 policy based routing, so you pretty much cannot buy a "router" by your definition. You haven't been able to buy a "router" in decades if you consider layer 4 ACLs out of scope.
Re: (Score:2)
Re: (Score:2)
The safest way to do this would be to use something already well-researched. EMV. A combination of a chip reader and the WebUSB API would make quick work of that - the OTP comes from the chip on your card. But right now Chrome and Opera are the only ones with support.
If you want to go for an isolated, battery powered device for the same, it looks like something already exists - CAP: https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
Re: (Score:2)
Either the payments are automated or there is manual intervention. It can't be both.
Those sites should be storing the authorization with their merchant service provider, not the card data - unless they want to be held to an extreme level of PCI compliance rules. The most that malware could do is charge money to the card and the money goes to the site owner. The web site is like a trusted computer in 2FA. You use the second factor once, and the trust relationship is set, but only for that one stored auth
Re: (Score:2)
Re: (Score:1)