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.
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.
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.
The victim will receive in the OTP device details about the transaction, but will hardly notice the change of the Iban code, so finally the victim is convinced to validate your transaction. OTP will also provide the code necessary to validate the fraudulent transaction.
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 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.
Written by Giorgio Fedon and Giuseppe Bonfà
References:
