This week Polish internet is buzzing about break-in to online banking website. This case seems to be extremely interesting and quite different from most of bank hacking news as the attack vector was not client-side malware but rather exploitnig vulnerabilities in internet banking application. All news coverage is in Polish so I decided to write a short summary for my English speaking friends.
Disclaimer: This article is based on public sources, mostly - local IT security blogs. Attacker has contacted security journalists and provided them details of his actions (probably to raise the stakes in blackmailing the bank).

Case description

Medium-size Polish bank (about 500 million USD in assets) was hit earlier this year by a single attacker who managed to takeover the internet banking frontend server, steal money and maintain control over it through next few weeks. Now the attacker blackmails the bank and requests a ransom.
According to the major Polish IT Security blog - Z3S (http://zaufanatrzeciastrona.pl/post/powazne-wlamanie-do-polskiego-banku-skradzione-dane-i-hasla-klientow/]] - in Polish) - the attacker claims that he took control over the main bank's server, probably through RCE vulnerability in obsolete software. He was able to modify internet banking application and insert server-side webinjects to steal users' credentials. Moreover, thanks to an authorization mechanism vulnerability in adding trusted recipients he stole about 1 million PLN (about 250 000 USD). Bank has confirmed the breach but without any details.
Probably after the breach was detected and the bank cut attacker's access, he started to monetize previously stolen data - credit cards with CVV numbers and other financial data - by blackmailing the bank with a ransom request (200,000 PLN / about 50 000 USD). To prove he possess sensitive data about 80 thousand customers, he presented transaction history of one prominent businessman related to the bank management and few other database fragments like credit card numbers. Moreover - on Tuesday, for a short time bank's corporate web page was redirected to another company page (probably attacker was able to change DNS records). The case is pending, as the ransom deadline ends today. Bank switched off his corporate web page "due to maintenance" (internet banking page is working).

Update (2015-06-16)

The story is still unfolding. Updates from last few days:
  • Bank of course didn't pay the ransom so attacker released first 500 records of corporate users' data (personal data, account balances, account history) and (alleged) image of bank's server. Attacker publishes information on paid Tor forum.
  • Attacker changed his demands. Still he want the bank to pay 200,000 PLN but... to charity. If no, then he threatens that each weekend he will release next batches of bank customers' data.
  • Bank confirmed the breach but claimed that this is "old story" and they have "thwarted attack at very beginning" and "all clients' money are safe". Attack was also confirmed by The Polish Bank Association.

Vulnerabilities exploited by attacker

Out of date software components

According to attacker, he was able to takeover internet banking server in January 2015 by exploiting "undisclosed bug which was a result of lack of regular software updates". It is not clear if it was server component (which in my opinion is unlikely) or rather application component (framework, library, etc.) - which is more likely as this is often "no man's land" and there are some well known RCE bugs in popular,, frameworks,,.

Business logic flaw in "trusted recipients" functionality

Normally, in case of this internet banking, it is necessary to confirm transfers with a SMS code (OTP send by SMS), however it is also possible to add a trusted recipient so that later it's not needed to confirm payments to this account. According to the attacker, he was able to bypass this additional transaction authorization, by adding mule's account as a "trusted recipient" to any account and in result this recipient was treated like "trusted" for all users.
This is typical case of business logic security defect. What is interesting is that this also affects functionality so probably it should be detected by QA test cases.

Transaction authorization bypass

Attacker has determined that modifying one of parameters send by internet banking application allowed him to bypass requirement to authorize the transaction using SMS code. For the attack he chose rarely used accounts with big balance but the bank detected frauds and blocked the accounts.
Further details are not available but, again, it is probably a logic flaw (e.g. parameter sent form browser side which controls which authorization mechanism is used) or some leftover from development phase.

Wrong implementation of masked password

This internet banking application uses "masked password" for users' authentication. A proper implementation of this mechanism should ask for the same mask after failed login attempt, while in this case, the application was asking for other character set on each authentication page reload. So that the attacker was able to sniff only one user authentication (using injected javascript) and then try to reload authentication form as long as application asks for sniffed character set.

Comment

It's worth noting that this is not the information that "someone hacked the bank" distressing but rather how easily it was possible. From other similar sensations about the break-in or leak which feeds the media, this case differs in several facts:
  1. The case doesn't look like a criminal organized group as in the case of major,, financial,, malware,, campaigns but rather "one man show". If it was a criminal group probably the scale could be much higher.
  2. The attacker didn't use malware or web-inject on the client-side but changed the application code after taking control of the server.
  3. The attacker did rather not use any "advanced" weapon like 0-day. From the description provided, it could have been an RCE on an unpatched application component (framework or library, e.g. old version of Struts'' or other framework). This is unfortunately often "no man's land". .
  4. A further attack was possible by the gross errors in the code of their own application (logic error in the implementation of a trusted recipient, the ability to bypass authorization of transactions by adding the parameter).
  5. Probably the bank wasn't able to quickly detect changes introduced by the attacker in the application.
I wonder why these vulnerabilities haven't been detected and removed before. They all look like the "low hanging fruit". Vulnerabilities in the environment / components should probably be detected by most of vulnerability scanning tools. Also the application vulnerabilities do not look like "rocket science" which a experienced pentester would not have noticed.

Additional materials

My presentation from AppSec EU 2015 about transaction authorization vulnerabilities in online banking: http://www.slideshare.net/wojdwo/ebanking-transaction-authorization-appsec-eu-2015-amsterdam.
This time it was not the malware, but would an antimalware solution save this bank from attack? My colleagues - Jakub Kałużny and Mateusz Olejarka presented a research on anti-malware solutions at BlackHat Asia 2015 and CONFidence: http://www.slideshare.net/wojdwo/bypassing-malware-detection-mechanisms-in-online-banking-confidence