Nowadays banking
authentication systems are getting more and more sophisticated in
order to counterattack the increasing number of hack attempts, but
unfortunately attackers follow the same trend by forging new and more
refined attack systems, we can define this as a classical never
ending battle between good and evil forces.
In this blog post we
will talk about the threats posed by the lack application of the
proper standard (ISO
15022, 8583) which regulates controls on
banking transaction details.
We can summarize
this lack of standard with the following statement: “Banking
transactions details are checked discretionally by the receiving
institute”.
An in depth view of
Discretionary Controls could be checked here [1].
The immediate effect
of this behavior is that an attacker could choose a bank with weak
controls to commit fraudulent transactions.
In this post we describe a scenario where an attacker takes advantage of a bank accepting incoming wire transfers omitting the surname of the recipients. Too many financial institutes allow incoming wire-transfers to "Giorgio" instead to "Giorgio Rossi" as a recipient.
In this post we describe a scenario where an attacker takes advantage of a bank accepting incoming wire transfers omitting the surname of the recipients. Too many financial institutes allow incoming wire-transfers to "Giorgio" instead to "Giorgio Rossi" as a recipient.
The immediate effect
of this behavior is that an attacker could choose a bank with weak
controls to commit fraudulent transactions.
Another very
important consequence of a weak control on transaction details is
that it could disrupt the effectiveness of authentication mechanisms
especially transaction detail verification ones because is possible
to accomplish Social Engineering attacks, for example on the
recipient Name.
More details will be given in a specific paragraph that will clarify how discretionary controls could be abused. To clarify the whole attack process let's clarify what is an OOB authentication system.
More details will be given in a specific paragraph that will clarify how discretionary controls could be abused. To clarify the whole attack process let's clarify what is an OOB authentication system.
Overview of OOB Transaction Detail Verification devices
The OOB
(Out-Of-Band) Transaction Detail Verification authentication system
sends to the banking customer a set of details about the transaction
that he should approve. Those details could be for example Iban,
Amount, Recipient, Country, if the requested transaction matches the
expectation of the customer (seems legitimate) he will validate the
transfer by generating an OTP code.
Follows an example
of a typical transaction detail verification hardware device:
If the transaction is correct, the user will validate it by generating an OTP code to finalize the operation.
Let’s see how an attacker could abuse the weaknesses in deriving from discretionary controls in realtime thanks to the technology offered by the most modern banking malware.
The first step is to clarify what is a realtime-deception attack and how is accomplished.
ATS and Realtime Deception Attacks
Most modern malware
banking implements a webinjection technology called ATS [2] which
stands for Automatic Transfer System. Thanks to the ATS system
attackers could automatically commit fraudulent transactions or
modify and substitute in realtime sensitive details like Iban and
Recipient of a legit transaction requested by the victim with
malicious detail one.
A realtime-deception
attack creates a condition, in which the victim is convinced to
authorize a legitimate transaction, when in fact will be validating
the fraudulent transaction desired by the attacker.
Realtime-Deception applied to Discretionary Controls
The following
picture summarizes the attack process:
It’s clear that a realtime-deception attack could be a serious threat if applied to a bank that implements weak discretionary controls.
- First step involves in the infection of the victim with a banking malware which supports MiTB (Man in The Middle) and makes use of ATS technology.
- When the victim fills details to commit a legitimate transaction, the webinjection will substitute the proper Iban and other details, with a malicious ones owned by the attacker. The attacker automatically chooses thanks to ATS the proper money-mule to adopt, in the case of the example Giorgio “Mule”. Attackers needs a mule with the same name (not surname) of the intended recipient chosen by the user.
Realtime-Deception attacks are suitably constructed according to the device and transaction details exposed to the victim.
However it’s possible to provide a categorization of the possible combinations of detail alteration and relative weak discretionary control that could lead to a successful attack. This combination involves the security design of the OOB device screen:
- Substitution of Recipient, Iban and Amount – This substitution could be used for example against phone call authentication which does not reveal transaction details.
- Substitution of Recipient and Iban – This substitution could work for example against devices that does not show the Name between transaction details.
- Substitution of Recipient’s Name and deletion of the Surname – This substitution could work for example against devices that only show only the Recipient Name.
Let’s suppose for
example that we are in the third case, the hardware device shows only
Amount and Name and let’s also suppose that the banking transaction
detail controls does not care about the recipient Surname.
An attacker could
exploit this flaw to substitute for example
The ATS automatically chooses the best fitting money-mule, in this case the mule has the same name of the legitimate recipient, the Surname difference is rendered useless due to the nature of this specific control weakness: example Giorgio (Real) -> Giorgio (Mule).
Where “Giorgio Mule” is a money-mule owned by the attacker.
From a victim point of view would be impossible to distinguish Giorgio “Real” from “Mule”, this behavior will finally lead the customer to validate the fraudulent transaction.
The ATS automatically chooses the best fitting money-mule, in this case the mule has the same name of the legitimate recipient, the Surname difference is rendered useless due to the nature of this specific control weakness: example Giorgio (Real) -> Giorgio (Mule).
Where “Giorgio Mule” is a money-mule owned by the attacker.
From a victim point of view would be impossible to distinguish Giorgio “Real” from “Mule”, this behavior will finally lead the customer to validate the fraudulent transaction.
The scope of this
simple attack scenario is to show that it’s possible to meet a
specific banking institute which has poor controls, for example by
allowing transactions that contains a wrong beneficiary name. For an
attacker will be an easy task to change Iban code and leave the same
recipient name.
Each kind of
substitution/modification typology strictly depends on the weak
discretionary control applied by the specific bank.
It’s interesting to put in evidence the fact that a correct mix of Social Engineering, webinjection capabilities and knowledge of the details validation flaws could pose a serious threat for the vast majority (hardware and software) of OOB transaction detail verification authentication systems.
From a defense point of view became clear that adopting the proper transaction detail verification standards [3] [4] represents a significant increase in terms of security.
It’s interesting to put in evidence the fact that a correct mix of Social Engineering, webinjection capabilities and knowledge of the details validation flaws could pose a serious threat for the vast majority (hardware and software) of OOB transaction detail verification authentication systems.
From a defense point of view became clear that adopting the proper transaction detail verification standards [3] [4] represents a significant increase in terms of security.
Written by Giorgio Fedon and Giuseppe Bonfà
References:
No comments :
Post a Comment