A Delivery Chain Breach: A UK bank opened the back door to China(markalanrichards.com)
markalanrichards.com
A Delivery Chain Breach: A UK bank opened the back door to China
https://markalanrichards.com/posts/2024-04-21-chinese-backdoor-to-uk-bank/
2 comments
From the linked article
> Metro Bank's web pages downloaded and ran software direct from Chinese systems on customer devices.
I'm not a web developer.
I don't understand how content pulled from another system (by a web page) is not supply side. Does it really make a difference that it is pulled in before the page is delivered or as it is rendered?
> Metro Bank's web pages downloaded and ran software direct from Chinese systems on customer devices.
I'm not a web developer.
I don't understand how content pulled from another system (by a web page) is not supply side. Does it really make a difference that it is pulled in before the page is delivered or as it is rendered?
It's different because it's worse.
In a supply chain attack against a system that produces some artefact (a container image, an executable, a VM image, whatever) an attacker can't modify what was injected after the fact (without building in some kind of remote update/attack persistence into the injection). This means that it could be audited and found later, for example the various projects designed to scan for the xz backdoor in executables.
But with this not only could the "attacker" (the CDN owner) change what is injected at any future time, there's no record of what was done as the author points out. A clever attacker could even selectively adjust what is sent based on the requester. They could distribute the unmodified code 99.99% of the time, but distribute malware 0.01% of the time — making it extremely hard to detect with simple 'spot checks'. They could exclude IPs known to be associated with the bank or CI systems from the malware distribution, so in-house malware checks would never see it.
Combined with other forms of intelligence, you could even build a system to target specific users with malware for very targeted attacks.
In a supply chain attack against a system that produces some artefact (a container image, an executable, a VM image, whatever) an attacker can't modify what was injected after the fact (without building in some kind of remote update/attack persistence into the injection). This means that it could be audited and found later, for example the various projects designed to scan for the xz backdoor in executables.
But with this not only could the "attacker" (the CDN owner) change what is injected at any future time, there's no record of what was done as the author points out. A clever attacker could even selectively adjust what is sent based on the requester. They could distribute the unmodified code 99.99% of the time, but distribute malware 0.01% of the time — making it extremely hard to detect with simple 'spot checks'. They could exclude IPs known to be associated with the bank or CI systems from the malware distribution, so in-house malware checks would never see it.
Combined with other forms of intelligence, you could even build a system to target specific users with malware for very targeted attacks.
From the customer's perspective everything has been supplied to them.
However, from the bank's perspective, of their supply chain, the component shown to a customer has not been handled by them: they never received it, to supply it.
At best they can order a copy of it for quality assurance purposes and hope it is identical to what the customer will receive.
Instead, their web page sends an order to the third party for delivery (script src tag refers to a foreign location) and crosses their finger that all will be good.
There are mechanisms to reduce delivery chain risks, such as SRI, but they were not used.
However, from the bank's perspective, of their supply chain, the component shown to a customer has not been handled by them: they never received it, to supply it.
At best they can order a copy of it for quality assurance purposes and hope it is identical to what the customer will receive.
Instead, their web page sends an order to the third party for delivery (script src tag refers to a foreign location) and crosses their finger that all will be good.
There are mechanisms to reduce delivery chain risks, such as SRI, but they were not used.
I guess it's harder to notice because only the victim gets the malware based on IP or time or whatever. Typical supply chain attacks leave malware specimens in everyone's hands and leaves the system operator the power to delete it.
Super depressing as a happy Metro bank customer, although I only use their mobile app. Which isn’t amazing. All I can say now is how quickly can I switch accounts?
Even if you do switch accounts, which bank do you choose, as most have this nature of vulnerability; hopefully with delivery providers that may be more trusted, but ultimately the bank has no control of the security and cannot distinguish their actions from customers: https://news.ycombinator.com/item?id=40112545
Well, Barclays are my main and Starling my secondary and only ever accessed via apps, so I could start by testing them both. Thanks for all this work.
But, when our code runs client side and depends on software artefacts being pulled from elsewhere by the client device, I feel like a supply chain paints a picture of a flow of control for that artefact that doesn't really exist.
Therefore, I phrased this post in the context of a "delivery chain" breach instead of a "supply chain" breach and I am curious to see what discussion flows.
Of course, I'm also trying to raise awareness to this particular breach and the odd events around it.