Thursday, May 21, 2009

Discretionary controls may lead to social engineering attacks against banking dongles

New social engineering attack strategies will deal with the fact that some details entered in banking transactions are checked discretionally by the receiving institute. Any bank has a different database for user details and a different policy: that’s good because user details are kept very confidentially. However any single institute has very proprietary controls; some do well, some do not.

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.

Some results:
  • 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.
Phone call was made to the Office that handled the incorrect transfers. We just said that we meant to perform a banking transaction to another recipient, but we entered the wrong details. The operator said that she was expecting another bank operator, and not a customer but she said that was just fine.

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.
External device screens may look similar to the one below. Details include also IBAN, Account number, and any other detail is directly displayed on the external 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:


By giving a clarifying example, let’s assume that the user (Bob) is doing a banking transfer to his friend (Alice). The details displayed out of band on the external devices will be:

Amount of Transaction: 300
Recipient: Alice
Country: Wonderland
IBAN: WL04292039280100000000918292

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
Recipient: Mallory
Country: Wonderland
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):
Can you spot the difference? Maybe yes (the IBAN visibly changed), but many details are unchanged from the original transaction. This fact will probably fool many users.

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.

9 comments :

  1. Nice Article.

    Did you have observed any fraud attempt trying to force you so called recipient bank "discretionary controls"?

    ReplyDelete
  2. As mentioned in the article the described social engineering attack could be very practical for luring the user of "banking dongles" into confirming the transaction. Anti-Malware devices are still not very common, so attacks like the one mentioned are more likely to be encountered in the near future.

    ReplyDelete
  3. I had some security thoughts reading the article. I think that is a pretty known issue, but you give new implications connecting it to Antimalware solutions.

    You did not mention the transfer details. They need to be changed?

    ReplyDelete
  4. You are correct mentioning "Transfer Details". "Transfer Details" may give more room for social engineering attacks if they are not displayed on the external device.

    Since the operator of the receiving institute make his decision upon the information contained in the data transfer, an attacker may forge particular subjects to push the operator in the wrong direction.

    E.g. Inserting some information related to the attacker e.g. Surname, name, etc.. (real owner of destination account)

    ReplyDelete
  5. Really the social engineering attack could be very practical for luring the user of banking dongles. A surge is expected in such cases.

    ReplyDelete
  6. Hi Giorgio, very nice post. You mentioned "Transfer Details", as it could be bad if they are not displayed on the external device.

    However I think thay displaying on a small LCD the transfer details could open social engineering attacks by abusing this field.

    E.g. Tranfer Detail: Name: Alice, Amount 100
    Could be very misleading

    Good post indeed. Travis Lee

    ReplyDelete
  7. @Jimmy: Thank you

    @Travis: You are right. I think that separators and special characters should be filtered via Input Validation. In addition I would suggest to use some chroma, or a different font type (style and size) to better discriminate from the field and its properties.

    ReplyDelete
  8. Where can I get anti malware device? And how much?

    ReplyDelete
  9. Good work! Bests to Minded Security Team.

    MGX

    ReplyDelete