The bad news is that one misbehaving entity is enough for lowering the security of the network. Attacker could choose the only bank in the country that has very weak controls, since the goal is to receive banking transfers from other people.
Let's assume that the bank where Mallory has his account will accept bank transfers if the the recipient is wrong and the amount transferred is lower than 5k. We could have a situation like the following one:
What If your bank will receive the correct account number with a wrong name on it? Well, the correct Beneficiary Name is not mandatory for issuing a bank transfer, but your bank (the receiving party) could accept it or not.
Usually the attacker has still 3 additional days to phone the receiving bank and try to persuade one employee to finalize the transaction before the transfer gets blocked.
We did some tests about sending money in our country to correct IBAN account numbers, but to wrong recipients.
- For amounts lower to 100 euros: 2 out of 7 banks confirmed and accepted the transfer.
- For and amount of 3000 euros: 1 out of 3 banks confirmed and accepted the transfer after a phone call.
Attackers may take advantage of these issues to perform social-engineering attacks directly on antimalware devices.
Effective attack strategy could be once again luring the user into confirming the wrong transaction, by preserving those fields that are actually remembered by the user. So which fields can be easily remembered?
- Amount? easily
- Recipient? easily
- Country? easily
- IBAN? Not easily. Personally I would just check for the name in the recipient field if it is available on the screen.
The main challenge in designing Antimalware solutions is to “Authenticate the Transactions to the user”. The most common way to meet this requirement is to provide an out of band channel that displays the transaction details in a secure manner. In this way the user can spot if “something” between him and the bank has interfered within the transmission.
Typical attacks against banking security solutions are impersonation attacks that need a malware already installed on the user system. The following is an example of a very common MITM (Man in the Middle Attack) performed on the local user machine:
Amount of Transaction: 300
If an attacker using a malware capable of “Local Man in the Middle Attack” changes some of the details, the external devices will prompt for confirmation. At this point the transaction will look very different from the original one:
Amount of Transaction: 10000
The IBAN: WL053510393501200000003523491
This fraud attempt is easy to spot, even if the attacker is using a mule in the same country as the victim: Transaction Amount and Recipient Details are very different from the original ones.
But if the attacker uses the social engineering attack mentioned at the beginning he could succeed by simply modifying the IBAN details (instead of the Amount and the Name of the Recipient):
The main reason is that additional details, such as the Recipient are considered trusted by the user and can have influence upon his choices. The details provided to the user should be the lowest as possible; any further detail which is not completely trusted by the bank itself may lead to confusion and leading to considerably increase the attack surface.
For banking network security reasons, be sure to threat correctly banking transfers with incongruent details, on both online banking and phone banking operators' side.
Are you sure you are doing it correctly? Please check it, for the health of next generation security solutions.