Two-factor authentication. New challenges
Instead of a prologue: this article deals with the theft of money from accounts of users of payment systems, various client-banks, etc.
It is not a secret that payment and other financial services place high demands on security. In this regard, comprehensive measures are being taken to protect both the system and user accounts. In order to prevent the possibility of hacking and disabling the system, various means are used such as:
From the point of view of protecting the user's account and its operations, both ordinary password protection and other means are used:
')
And of course, two-factor authentication tools, EDS (Electronic Digital Signature) and contactless tokens - OTP (One-Time Password) generators.
I have always believed that two-factor authentication is a panacea, almost from all possible vulnerabilities in the process of user authentication. Following the latest security trends, as we thought at that time, we recommended our users to authenticate with our payment system using hardware tokens (TOTP, it is called a “time-token”) of leading global suppliers or software Authenticator from Google. To confirm the payment transactions (transactions), the tokens mentioned above were used, and for those who did not have them, we required to enter a one-time password from the SMS. Such protection seemed to us absolutely reliable, but if it were really so, then this article would not be ...
I will not be around for about a long time, get down to business. One day, a request came from a furious user to the caliper that his account was “reset”, in other words, all the funds were withdrawn. After the initial investigation, we saw from the history of operations that all funds in a regular mode for several transactions were withdrawn to different accounts by the user. Prior to this, there was no connection (operation) between the user and these accounts. After a more detailed review and analysis of all data, it turned out that this user was the victim of “Avtozaliv” and “Replacer”.
A bit of theory gathered on the Internet:
Avtozaliv - an inject with an administrative panel that performs automated and coordinated actions in the victim's account based on the position / situation in the account. This malware collects account data, looks at what accounts are in the account and sends data to the administrative panel. In the panel there is a table of drops and their status, notes, account data where to transfer funds, and to what extent, to bypass the limits and not cause suspicion. The panel on the basis of automatic rules or through manual coordination selects the drop and produces an injection. Further a few alternative options:
option 1) the injection displays the user a window with a text like “Wait for data checking”, and he secretly performs actions leading to the flooding of money by clicking on the necessary links inside the account and filling out the forms requested by the system. In case the TAN / OTP / PIN code and so on is requested to complete the transfer, avtozaliv issues a fake page to the holder requesting that code, but under its pretext (divorce). The holder enters the data in the fake, avtozaliv uses this data to continue / end the gulf.
option 2) inject waits for the user to want to perform a legal transaction for which the TAN / OTP / PIN code will be requested, but with this code an illegal transaction will be confirmed - a deposit of money for a drop.
After that, the holder is allowed into the account on which the replayer is already activated.
Replacer - software code aimed at hiding the translation data made avtozalivom. In other words, balance substitution is the concealment of a transfer from the transfer history and other manipulations aimed at preventing the holder from noticing the transfer. In our case, the holder sees the fake balance and fake legal transaction.
Our system has various means of multi-level checks, for example, reconciliation of the balance and the amount of user transactions, as well as reconciliation of balances in our system and external ones, and a number of others. All this did not help in this case, because the transaction did not come “out of thin air” and looked like quite ordinary.
Of course, we heard about various types of attacks and in practice we often encounter various kinds of frauds, but we were surprised to say the least. Although the funds were “drained” from the user's account, in order to avoid reputational consequences, the company’s management compensated part of the losses to the victim. This was also due to the fact that he was a bona fide client with good turnover, and most importantly, he had all the means of protection available at that time from our arsenal installed.
After some searches, we found that this two-factor authentication bypass is already well known, and many advanced providers offer similar solutions to deal with this vulnerability, they are called differently (data signature, CWYS (Confirm What You See), but have a similar implementation.) the point is that a one-time password is generated not only on the basis of a secret key, time, or counter, but using all the key transaction data, such as amount, currency, recipient, even if the attacker is Amum password to use for their malicious needs him he can not. Here everything is described in detail. In order to implement these features, we contacted several providers, and have made their choice.
So, while we sighed with relief ... We are waiting for new challenges.
It is not a secret that payment and other financial services place high demands on security. In this regard, comprehensive measures are being taken to protect both the system and user accounts. In order to prevent the possibility of hacking and disabling the system, various means are used such as:
- all kinds of firewalls, now WAF (Web Application Firewall) is very popular,
- duplication of key elements of the system,
- data replication; tokenization of various stages of the system,
- hardware encryption using HSM (Hardware Security Modules).
From the point of view of protecting the user's account and its operations, both ordinary password protection and other means are used:
')
- restriction of access by IP address
- code cards, payment passwords, PINs,
- biometrics,
- check the user's environment.
And of course, two-factor authentication tools, EDS (Electronic Digital Signature) and contactless tokens - OTP (One-Time Password) generators.
I have always believed that two-factor authentication is a panacea, almost from all possible vulnerabilities in the process of user authentication. Following the latest security trends, as we thought at that time, we recommended our users to authenticate with our payment system using hardware tokens (TOTP, it is called a “time-token”) of leading global suppliers or software Authenticator from Google. To confirm the payment transactions (transactions), the tokens mentioned above were used, and for those who did not have them, we required to enter a one-time password from the SMS. Such protection seemed to us absolutely reliable, but if it were really so, then this article would not be ...
I will not be around for about a long time, get down to business. One day, a request came from a furious user to the caliper that his account was “reset”, in other words, all the funds were withdrawn. After the initial investigation, we saw from the history of operations that all funds in a regular mode for several transactions were withdrawn to different accounts by the user. Prior to this, there was no connection (operation) between the user and these accounts. After a more detailed review and analysis of all data, it turned out that this user was the victim of “Avtozaliv” and “Replacer”.
A bit of theory gathered on the Internet:
Avtozaliv - an inject with an administrative panel that performs automated and coordinated actions in the victim's account based on the position / situation in the account. This malware collects account data, looks at what accounts are in the account and sends data to the administrative panel. In the panel there is a table of drops and their status, notes, account data where to transfer funds, and to what extent, to bypass the limits and not cause suspicion. The panel on the basis of automatic rules or through manual coordination selects the drop and produces an injection. Further a few alternative options:
option 1) the injection displays the user a window with a text like “Wait for data checking”, and he secretly performs actions leading to the flooding of money by clicking on the necessary links inside the account and filling out the forms requested by the system. In case the TAN / OTP / PIN code and so on is requested to complete the transfer, avtozaliv issues a fake page to the holder requesting that code, but under its pretext (divorce). The holder enters the data in the fake, avtozaliv uses this data to continue / end the gulf.
option 2) inject waits for the user to want to perform a legal transaction for which the TAN / OTP / PIN code will be requested, but with this code an illegal transaction will be confirmed - a deposit of money for a drop.
After that, the holder is allowed into the account on which the replayer is already activated.
Replacer - software code aimed at hiding the translation data made avtozalivom. In other words, balance substitution is the concealment of a transfer from the transfer history and other manipulations aimed at preventing the holder from noticing the transfer. In our case, the holder sees the fake balance and fake legal transaction.
Our system has various means of multi-level checks, for example, reconciliation of the balance and the amount of user transactions, as well as reconciliation of balances in our system and external ones, and a number of others. All this did not help in this case, because the transaction did not come “out of thin air” and looked like quite ordinary.
Of course, we heard about various types of attacks and in practice we often encounter various kinds of frauds, but we were surprised to say the least. Although the funds were “drained” from the user's account, in order to avoid reputational consequences, the company’s management compensated part of the losses to the victim. This was also due to the fact that he was a bona fide client with good turnover, and most importantly, he had all the means of protection available at that time from our arsenal installed.
After some searches, we found that this two-factor authentication bypass is already well known, and many advanced providers offer similar solutions to deal with this vulnerability, they are called differently (data signature, CWYS (Confirm What You See), but have a similar implementation.) the point is that a one-time password is generated not only on the basis of a secret key, time, or counter, but using all the key transaction data, such as amount, currency, recipient, even if the attacker is Amum password to use for their malicious needs him he can not. Here everything is described in detail. In order to implement these features, we contacted several providers, and have made their choice.
So, while we sighed with relief ... We are waiting for new challenges.
Source: https://habr.com/ru/post/264287/
All Articles