This article is partly a summary of, and partly an update to, my presentation titled "
How To Rob An Online Bank And Get Away With It," presented at
SOURCE Boston last month and previously at
DeepSec Vienna.
The subject of our dissection is an online bank robbery. Not the all-too-common attack against an online banking user, his computer and his identity, but an attack against the bank itself - or more precisely, against the bank's online banking application.
An online banking attack has four distinct phases:
- Vulnerability Finding Phase
- Vulnerability Exploitation Phase
- Buying Time Phase
- Extraction Phase
Let's look at each of these phases individually.
Phase 1: Vulnerability Finding
Online banking applications are typically custom-made or at least significantly customized for every individual bank, and one can not find their source code on the Internet. A motivated attacker could certainly try to obtain source code from the developers (finding out who they are should be simple enough) and search for vulnerabilities in the code without risking detection, but online banking application's code may not be enough for identifying actually
usable vulnerabilities: for instance, even if the code exhibits lack of input validation in a critical flow, there may still be some back-end validation in place that would stop attempted exploitation. Therefore, profit-driven attackers who don't care which bank they attack will more likely approach vulnerability finding in a
black box manner by trying a long list of usual tricks that work in online banking until one turns out to be working.
Since this phase is an interactive one, the attacker runs a risk of being detected while looking for vulnerabilities and verifying their exploitability. Furthermore, a typical online banking system only provides access to its functionalities - and consequently, vulnerabilities - to registered users; in order to become an online banking user, one must undergo a face-to-face interaction with the bank and provide proof of identity while being recorded by on-premise security cameras. The attacker does not particularly like such exposure as it could reveal his real identity during inevitable forensic investigation.
To avoid this risk, we expect the attackers will start using (or perhaps already are using?) a technique we call
User-in-the-Middle. In contrast to the well known
Man-in-the-Middle technique and its web application derivative,
Browser-in-the-Middle, where the attacker intercepts communication between a user and an online banking server in an attempt to steal user's funds while hiding the attack from the user, a
user-in-the-middle attack is an attack against the server (not the user), but utilizing user's computer as well as his identity to perform the attack. This allows the attacker to effectively hide behind the user and make it appear as if the user was actually the source of the attack (or, in this phase, the one looking for vulnerabilities in an online banking application). Even if forensic investigation subsequently discovers that it was not the said user who performed the malicious activities, the traces on his computer would be insufficient for tracking down a smart attacker.
Phase 2: Vulnerability Exploitation
Once the vulnerability finding phase has produced an exploitable vulnerability - typically a logical flaw such as acceptance of negative numbers, bypassing of overdraft limits, flawed authorization, etc. - the attacker will exploit it at a convenient time to avoid detection or delay bank's response time. This timing depends heavily on the functional periods of any particular online bank, as some functionalities may only be available during bank's operating hours (e.g., between 8:00AM and 3:00PM on working days) while some others may be available 24/7 (e.g., internal funds transfers). Regardless, the end goal of this phase is to generate a large sum of money on one or more attacker's accounts, which will then wait there for the last phase (extraction) or will - more likely - first be transferred to other banks in other countries to slow down subsequent investigative efforts.
Again, these "attacker's accounts" need not actually belong to the attacker or have any association with him. To avoid capture, the attacker can use the
user-in-the-middle technique here to use an unsuspecting online banking user's identity for storing stolen funds on his account (while this user may be on vacation).
Phase 3: Buying Time
Once the digital money has been stolen and is sitting on one or more attacker-controlled bank accounts, the attacker knows it is just a matter of time before the attack is detected and the hunt for the stolen money begins. He knows that if the hunters locate the money he stole, it will get "frozen" or simply taken away (it is nothing more than bytes in a database, after all). To delay the hunters, one of the most obvious and effective methods is for the attacker to transfer the funds to another country, and then to yet another country, and so on. These countries are not to be chosen aribtrarily, but such as to maximize the delay provided by the (lack of) cooperation between said countries' law enforcement agencies.
Since large funds transfers can quickly trigger fraud detection alerts (in many countries, every transaction above 10K dollars or euros is automatically flagged for money laundering inspection), attacker will likely use "borrowed" corporate accounts instead of personal ones, since large cross-border transactions are not unusual in the business world.
Predictably, the abovementioned foreign countries' accounts can again be "borrowed" from legitimate users to hide attacker's identity.
Phase 4: Extraction
The last phase of the attack is about converting the stolen digital money, which is highly traceable as long as it remains in the digital global banking system, into an untraceable form. By and large, the most convenient untraceable form of money is cash. And the safest cash extraction points for attackers are ATMs, as they make it possible to withdraw cash without being recorded by a camera (covering face with cap or hood) or seen by a bank employee.
Most of the currently known cases of ATM-based cash extraction seem to be involving so-called
money mules, i.e., gullible individuals who are duped into "little work, easy money" schemes without knowing they're helping criminals acquire stolen money. Criminals simply transfer stolen digital funds to mules' accounts and instruct them to withdraw cash, keep 10% and send the rest to another country via, say, Western Union. Criminals know that the police will likely catch some or all of the money mules but make sure that the trail stops cold at that point.
Interestingly, there is again a potential for
user-in-the-middle here. Instead of recruiting money mules who can potentially decide not to send the agreed-upon 90% to the attacker, and can inevitably provide useful information to law enforcement when caught, the attacker could hack into multiple online banking users' computers - again, not to steal their money, but to send stolen money through their accounts to remote Western Union extraction points.
How To Block These Attacks?
Clearly we stand a better chance for blocking attacks once we understand how the attackers operate. While the last two phases (
Buying Time and
Extraction) are not unique to attacks against online banking servers (we also see them in attacks against online banking clients/users), phases 1 and 2 are distinct, and provide some unique ways for detecting and blocking the attack.
- Vulnerability Finding Phase: Detecting activities typical for a vulnerability assessment could block the attack before any significant damage has been done. In case the attacker is using the user-in-the-middle technique to hide behind a legitimate online banking user, such early detection can provide law enforcement with more information about the attacker and possibly even allow them to covertly trace him back from the user's computer. Fortunately for defenders, there is a free OWASP AppSensor project focusing on such early attack detection, which can be utilized in online banking with relative ease. In addition, the vulnerability finding phase usually generates an increased amount of server-side errors (on web server, in application and/or in the database); a heightened number of errors associated with a single user account may be a sign of malicious activities and a reason to investigate the particular user.
- Vulnerability Exploitation Phase: A characteristic feature of this phase is the emergence of unusually large funds on accounts that may previously not have had much money or have just been opened recently. While existing fraud detection mechanisms can be useful for detecting suspect patterns, attackers using "borrowed" corporate accounts would have a higher chance of remaining undetected. A careful attacker would also likely distribute stolen funds among several unrelated accounts, making detection all the more difficult.
Conclusion
In over 12 years of legally breaking into online banks and following public and not-so-public cases of attacks against banking IT systems, we've accumulated quite some experience with the subject and found many interesting vulnerability types specific to banking operations. We've long ago anticipated the shift from attacks against personal online banking users to corporate ones (which we're seeing increasingly happen today), and we now anticipate an increase in attacks against online banking applications - attacks where hacked online banking user accounts will mainly be used for hiding attackers' identities. We believe it's time for banks to prepare for such attacks, and fortunately this need not be very expensive. Naturally, minimizing the number of vulnerabilities in online banking applications should still be priority, but the next step is to build capacity for detecting attackers' looking for vulnerabilities and exploiting them.
@mkolsek
@acrossecurity
Posts
