On a recent news, a group of attackers gained access to the Bangladesh's Central Bank’s (BB) SWIFT payment system. Few weeks of investigations have revealed that this might in fact be the work of a custom malware (outlined well by BAE systems here) that infected the SWIFT agent for the bank.
However, this is not a lone incident. There are numerous incidents these days that follow a similar pattern of attack and amount anywhere from lot of money to loss of reputation. It should be noted that in most of the cases these do not exploit a major flaw in the software itself. This is a classic case of weakness in the Human link of security. The only plausible explanation of how the 'custom malware' was deployed into the bank's local environment, is the human side. Ironically, this is also the side that brought an end to the fraud when a spelling mistake was discovered in the transaction request email and the support team called the bank for verification.
Although its no coincidence that this malware was has been found at this time, it is yet to be confirmed if this was indeed the one used for the attack. The malware linked to the incident is indeed sophisticated for the fact that it works by replacing the conditional Jump instruction || 0x75 0x04 ||liboradb.dll(dll from the Swift suite responsible for database transactions and authorization) with NOP instructions 0x90 0x90 to always succeed any authorization checks. Additionally, the logic for detecting forge transactions created and deleting the same from the database uses a pattern of swift codes which one familiar with such a system can devise. All along it also keeps signalling the command and control center a sort of audit log.
Any malware is a piece of code that is designed to program as per a pre-defined logic. A custom works as per the environment it is in. This is what adds flexibility and intelligence to the code. The more reliance we continue having on machine and code, the more necessary human intervention would be to protect it.And this is what is lacking in today's automated self run systems such as these. I will explain how.
Security by its very nature has to be in Layers. Assuming, the above scenario really occurred via a malware designed for Swift, two major events happened that compromised all controls in the case above:
However, this is not a lone incident. There are numerous incidents these days that follow a similar pattern of attack and amount anywhere from lot of money to loss of reputation. It should be noted that in most of the cases these do not exploit a major flaw in the software itself. This is a classic case of weakness in the Human link of security. The only plausible explanation of how the 'custom malware' was deployed into the bank's local environment, is the human side. Ironically, this is also the side that brought an end to the fraud when a spelling mistake was discovered in the transaction request email and the support team called the bank for verification.
Although its no coincidence that this malware was has been found at this time, it is yet to be confirmed if this was indeed the one used for the attack. The malware linked to the incident is indeed sophisticated for the fact that it works by replacing the conditional Jump instruction || 0x75 0x04 ||liboradb.dll(dll from the Swift suite responsible for database transactions and authorization) with NOP instructions 0x90 0x90 to always succeed any authorization checks. Additionally, the logic for detecting forge transactions created and deleting the same from the database uses a pattern of swift codes which one familiar with such a system can devise. All along it also keeps signalling the command and control center a sort of audit log.
Any malware is a piece of code that is designed to program as per a pre-defined logic. A custom works as per the environment it is in. This is what adds flexibility and intelligence to the code. The more reliance we continue having on machine and code, the more necessary human intervention would be to protect it.And this is what is lacking in today's automated self run systems such as these. I will explain how.
Security by its very nature has to be in Layers. Assuming, the above scenario really occurred via a malware designed for Swift, two major events happened that compromised all controls in the case above:
- The malware was deployed in the environment
- Authorization logic was changed
For both the above to work, they need to function isolated environments i.e. the SWIFT based systems and the crucial .dlls , to avoid them from being tampered.
It seems evident that the malware was deployed through human error either by using Social Engineering techniques or by a malicious insider, but a human element is a must. Whereas in the second case(of the authorization logic), there seems to be a need for an additional element to security. For transactions bigger than a threshold, a second factor of authorization, mostly human, should be involved and mandatory.
It is interesting and what followed reiterates the fact the attack was well planned. Post the transaction the money was laundered into various accounts, which has still not been recovered or traced. I believe operational controls play an important role especially in bank frauds and this is no different. For amounts beyond a threshold is debited or credited from an account these should be controlled and allowed only after verification. This not only adds security and control but also makes for more business sense since such customers are generally premier for any bank (and as they say their safety should be a priority). And this might sound a little far fetched but our anti money laundering systems are yet to get smarter to be able to prevent and trace such incidents.
Although, there may be combination other controls that are required depending on the system being protected, the right human intervention will be necessary when impact is huge. All malware are designed to subvert technology, while some to subvert humans. Only unlike technology all humans are different.
References:
http://www.databreachtoday.com/swift-confirms-repeat-hack-attacks-a-9067
http://baesystemsai.blogspot.in/2016/04/two-bytes-to-951m.html
