Bangladesh Bank Fraud: Came, Conquered, Got Human

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:

1. The malware was deployed in the environment
2. 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

Threat Modelling Web Applications_Part_1: Introduction

The introduction would generally explain what threat modeling is. However, it takes more than a few lines to do that. In fact one may start understanding in parts by  the end of numerous such exercises, how it works.

Let’s answer the question of ‘Why’ Threat modeling is required in the first place.

Today a sizable number of testers perform vulnerability assessments and penetration testing for a wide variety of web applications. As it is, the benefits of a good Penetration test are guaranteed:

• ·         Dynamic but comprehensive assessment of application
• ·         Precise findings
• ·         Tells the likelihood of system 0wnage
• ·         Accurate fixes[since we have tools to tell us the exact interface and parameter affected]
• ·         Ability to test and retest quickly

Now let’s look carefully at each point above. A threat modeling or thorough design review can give us all the benefits from above plus the ones below:

• ·         Great reduction in cost! The cost of fixing issues after development is considerable
• ·         Avoids any confusion from standalone fixes or recurrence of issues
• ·         Makes the application robust by design
• ·         Finds any security issues first hand- yes long before they are born

Application end to end

A design review takes into consideration every single entity that interacts, provides for or is connected to the application. This way it completes all the circles and is the real end to end assessment. It treats the application like a system with its own ecology and then finds what could go wrong. It is not limited to what’s visible to the user from front end but explores possibility of issues from back-end, components, channels, etc…

Accurate findings

What makes a finding ‘concrete’ is evidence. A threat should also be accompanied by its own set of ‘soft evidence’. Except for few cases one can often cite the client to show what has indicated existence of a threat. Like how two decently secure systems being put together in a certain way can uncover a potential flaw leading to insecurity.

Note: You may generally notice this for existing designs

Likelihood of system 0wnage

The likelihood of exploiting any threats to an application can be rightly judged, when one has a bird’s eye view of the design, components and channels. This often leads to different severities for the same issues in different scenarios.

Use of Use-Cases

A use case is a visual representation of the workflow/functional scenario and involves the concerned components and actors. It helps to understand the context better and enhances the chance of quick threat identification for the same.

In ideal cases, we recommend referring to use cases. However, in a practical scenario, with time constraints for review, an experienced security engineer may skip use cases. This is normally the case for a complex design changes that needs to be deployed quickly. In such a scenario it is essential to prioritize some cases/workflows over others, in the given context.

Still before we start discussing the elements of design review[Threat Modelling] in the following posts, a short definition below with respect to web application review:

‘Threat modeling is an art of finding security flaws in and around a web application given its environment, purpose and context leading to direct or indirect compromise or loss to business.’

Note: 

The reader is expected to possess basic understanding of how web applications work and offensive attack techniques that could be used to subvert the same.

 In the future posts, I shall touch upon many aspects of Threat modeling and design review. The reader should keep in mind that these just list some checkpoints in the context of threat modeling web applications and are not exhaustive in any way.