SWIFT is an instruction protocol tied to a network that SWIFT Alliance Access (mentioned in article) gives access to, SWIFTNet.
Without going into details of failings of SWIFT authentication, which are few, this appears to be simple phishing:
The use of malware, suggested here, seems simple:
* There are a lot of manual steps in fund transfers that are either initiated manually (submitting a paper-based payment request, or even change to a company's authorised signature list) or requiring various manifests such as letter or credit clearing.
* Malware means the typical system of checking inputs are indeed true and correct (an inputter of the paper form, and a checker to verify it is true and correct) can be disrupted by replacing the scanned file between scanning and input (based on scan) or direct system access changing key numbers of codes.
* This comment is not a slight on Bangladesh. It is a general comment on developing economies I've interacted with in banking operations across Asia: Staff are often under-trained at a branch level and expected to perform a multitude of tasks under under-trained management. Local actors, for example local banks, often have completely insecure systems compared to international banks despite acting as correspondent bank in many transactions (added to the security-failure tool-chain). This is in contrast with outsourced operations in similar countries that run large service centers and most-often do an excellent job.
This appears to be fully not an error of SWIFT, but of using (the power of) SWIFT in combination with discrete and serious errors in injecting false records in non-audited/un-auditable systems that interact with SWIFT instructions and SWIFTNet.
I'm assuming the Bangladesh bank did not write their own software so these vulnerabilities must also exist at other banks on the SWIFT network. SWIFT is just a protocol but any bank who signs on to SWIFT must also have software which implements SWIFT and therefore is potentially vulnerable to similar attacks. I'm sure this prospect terrifies the banking industry but it cannot be explained away. These risks exist even for Western banks.
However, that malware is indicated suggests this could be to lax local lock-down of PCs. Pretty common. International banks should be pretty locked-down, but no reason to be complacent. I imagine various regional and country heads of compliance are aware of this right now, or have been already.
What is likely worrying local bank security managers is just how many VBA-type programs they're running as quick-fixes to operational problems that are vulnerable, the weak links. The number of hacked-together-at-the-weekend-bought-in-services in banking is astounding, especially in emerging markets.
Yes, these hack/programs exist in established international corporate banks.
From the description this sounds like a highly targeted attack on proprietary software the bank uses to manage payments. (Most large banks don't use SWIFT Alliance Access directly - instead they have numerous internal systems that will ultimately use SWIFT as the final step for certain payments.) I would be very surprised to learn this was not a result of somebody who worked at the bank.
Your comment is mostly accurate. However, I'd imagine anyone hearing a message was sent through SWIFT would assume a protocol got it to SWIFTnet followed by their own systems processing it. The two are inseparable. We used to call this sort of thing a "system of systems."
Anyway, it's accurate to think of protocol + SWIFT's mgmt systems as "the SWIFT system" given they work collectively to hanndle a SWIFT transaction.
Amazing to me that for credit cards, we have PCI DSS[1] which is incredibly invasive in it's requirements, ins't there something equivalent for SWIFT-connected locations?
The malware looks for processes with with a specific DLL loaded in it and then will replace two specific bytes with other instructions, which essentially trick the process into thinking an important check has been done.
No, they we're already running code on the box with high enough permissions, so they're allowed to inspect processrs and do whatever is necessary. No C-like memory protection stuff matters at that point.
What would have prevented it was not letting them have root in the first place. Perhaps by running with Software Restriction Policies so only a whitelist of binaries can run in the first place.
Stuff like this is why machines like Burroughs should've dominated in critical applications like banking. Those machines marked code and data as different in memory where CPU wouldnt even execute data words. Also bounds checked pointers and protected stack.
Interesting enough, the successor to Burroughs is being made partly by BAE Systems. See crash-safe.org publication list.
Just goes to show, if your highly illegal target is roughly 100 Million, be sure to reach for like ten times that amount and try to grab an absurd 1 Billion.
Maybe they withdrew some of it in cash. I don't see why some foreign bank should be on the hook once the funds have cleared and been withdrawn by the thieves.
Here in the West, we elect our criminals, who use corrupt procurement, bribery, and other frictions to suck many trillions from our GDP. Not to worry, though: the debt payments on this kind of policy will shortly eclipse the thefts and legitimate spending.
> Computer disks and USB sticks were dropped in parking lots of government buildings and private contractors, and 60% of the people who picked them up plugged the devices into office computers. And if the drive or CD had an official logo on it, 90% were installed.
It sounds more like someone left usb sticks with logos on them in the parking lot.
I can think of a few people/organizations that "deserve" to have their coffers emptied. Not Bangladesh, but there do exist people that deserve it. I'm sure you can think of some, too, if you put some thought into it.
SWIFT is not a system.
SWIFT is an instruction protocol tied to a network that SWIFT Alliance Access (mentioned in article) gives access to, SWIFTNet.
Without going into details of failings of SWIFT authentication, which are few, this appears to be simple phishing:
The use of malware, suggested here, seems simple:
* There are a lot of manual steps in fund transfers that are either initiated manually (submitting a paper-based payment request, or even change to a company's authorised signature list) or requiring various manifests such as letter or credit clearing.
* Malware means the typical system of checking inputs are indeed true and correct (an inputter of the paper form, and a checker to verify it is true and correct) can be disrupted by replacing the scanned file between scanning and input (based on scan) or direct system access changing key numbers of codes.
* This comment is not a slight on Bangladesh. It is a general comment on developing economies I've interacted with in banking operations across Asia: Staff are often under-trained at a branch level and expected to perform a multitude of tasks under under-trained management. Local actors, for example local banks, often have completely insecure systems compared to international banks despite acting as correspondent bank in many transactions (added to the security-failure tool-chain). This is in contrast with outsourced operations in similar countries that run large service centers and most-often do an excellent job.
This appears to be fully not an error of SWIFT, but of using (the power of) SWIFT in combination with discrete and serious errors in injecting false records in non-audited/un-auditable systems that interact with SWIFT instructions and SWIFTNet.