Financial Cyber-Threat Briefing

“Planning for Attack-Resilient Web Applications”

The next 11th July 2014 in London Minded Security, the Software Security Company, will present an overview of the most common and latest attack vectors affecting online banking and other financial online services, strategies and methodologies for addressing growing risks in this domain and demonstrate some of latest untraceable exploits as well as solutions to stop them.

The agenda

14.30 to 15:00 Registration and welcome

15.00 to 16:15 Keynote Presentation

16:15 to 16:30 Networking Break 

16:30 to 17:15 Live Demos 

17:15 to 18.00 Networking Drinks Reception

Speakers and presentations

"Emerging Cyber-Threats Targeting Financial Institutions"

This presentation will share research carried out on the root causes of security incidents caused by attacks from emerging threats such as malware banking. The session will provide practical examples of instances of compromises causes by various threat agents and provide an in depth analysis of methods and attacks vectors employed against online banking applications. The scope of this analysis will be to analyse the threats, simulate attacks and identify flaws in application architecture that can be prioritised for remediation. To simulate the attack, modelling techniques such as the attack kill chain and attack trees will be shown. The goal of this session is to provide information security officer’s examples of processes, methodologies and risk frameworks that can be used to identify countermeasures to mitigate emerging threats.

Speaker: Marco Morana, SVP Technology Risks & Controls, Citi

"Overview of Online Banking Malware & Countermeasures"

This session will present how attackers currently identify and exploit web vulnerabilities on financial institution websites to stealing credentials. Giorgio will also demonstrate how compromised customer PC’s can compromise online transaction platforms an overview of the technology being used for prevention. Finally Giorgio will present a new technology “AMT Banking Malware Detector” that allows banks to identify users infected with malware before they become victims of fraud.

Speaker: Giorgio Fedon, COO, Minded Security & OWASP Lead.

"Preventing In-Browser Malicious Code Execution"

DOM Based XSS (or as it is called in some texts, “type-0 XSS”) is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. Certain vulnerabilities in JavaScript code cannot be tracked by standard IDS or perimeter security measures, which leads to a huge potential vulnerability, the code can be abused to steal data or bypass authentication mechanisms in web interfaces. This presentation will demonstrate vulnerabilities and also present Minded Security’s latest countermeasure DOMinatorPro.

Speaker: Stefano Di Paola. CTO, Minded Security & OWASP Project Lead

Info & Registration

For more information and registration, please visit the following web page:

http://www.liquid-nexxus.com/en/schedule/next/financial-cyber-threat-briefing

Discretionary Controls and Realtime Deception Attacks

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.

1. 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.
2. 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:

1. Substitution of Recipient, Iban and Amount – This substitution could be used for example against phone call authentication which does not reveal transaction details.
2. Substitution of Recipient and Iban – This substitution could work for example against devices that does not show the Name between transaction details.
3. 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:

[1] http://blog.mindedsecurity.com/2009/05/discretionary-controls-may-lead-to.html
[2] http://blog.mindedsecurity.com/2012/09/zeus-gameover-overview.html
[3] http://en.wikipedia.org/wiki/ISO_15022
[4] http://en.wikipedia.org/wiki/ISO_8583

Unbelievable hacks: Money Transferring with Caller Id Spoofing

Everyone in the security industry easily remembers Kevin Mitnick during his Art of Deception tour, where he showed how to call somebody else displaying a fake incoming phone-number on the receiver’s phone. In that case the phone number of the president of the United States. This is "Caller Id Spoofing" (Kevin Mitnick at CNBC).

Presented by Kevin as a strong weapon in Social Engineering attacks, we discuss it here as a way to bypass authentication checks during money transfer. People usually laugh of nice tricks, but not when the subject is their money.

Phone Call authentication is an emerging way of authenticating money transfers or other types of disposal operations. This particular authentication method has the great advantage of posing zero costs for the organization and for the individuals. In fact as soon as the call is received by the bank, the call is dropped without charging the calling card.

When a customer call the dynamic phone number for authentication too often the only information that is checked is the Caller Id. The standard incoming caller identifier is the information that is displayed on the mobile phone of the phone call receiver.

This set of information can be dangerously used to identify the user that is authenticating a particular transaction. I say dangerously, because the caller id is very prone to tampering as showed several years ago in the workshop “Phreaking in the age of Voice Over Ip”:

Before we start the questions we need to answer are:

1) Is caller ID Spoofing still alive?
2) Does it work in our country? (ex. Italy for us)
3) Is it enough for performing an Identity Spoofing attempt and to breaking authorization security?

Is caller ID Spoofing still alive? To answer the first question, we can say that phone operators are very based on legacy systems. SS7 standard is still adopted and valid, as the calling rules are pretty much the same that were in use at the time that “Lucky 225” was presenting. So yes, Caller Id spoofing is still a valid attack.

Does it work in our country? Unbelievably Yes. Phone operators use to blacklist malicious operators that were known to perform Caller Id Spoofing attacks. This means that it’s possible for an attacker to find a valid voip provider that is not blacklisted to put into place a successful Caller Id Spoofing attack.

Is it enough for breaking authorization security? It Depends. The bank should badly rely only on Caller Id verification which is not a best practice. Caller Id as demonstrated below can be arbitrarily modified, so more information should be requested to correctly identify the customer.

How many banks rely only on Caller ID for the security of their Phone Back authentication system? We do not have precise statistics for Europe, but we tested it against 2 banks and both were vulnerable to this attack.

How the attack works

Imagine that at the time of authorizing your wire transfer your online bank will print the following information on your screen:

At this time if the attacker knows the phone number associated to the customer bank account can place a phone call with a spoofed caller id.

Voip Services offer the possibility to setup your Asterisk voip central and to route call defining your custom caller id.

Normally an attacker should:

1) Have his own virtual server, possibly in the country where the VOIP service is rented
2) Rent a VOIP service that permits to specify an arbitrary caller ID which is not blacklisted by your country Phone operator

However Google helps in finding ready setups as a “pay per go” service.

The following is an example of the service which permits to spoof phone Cal Ids also in Europe and Italy.

To be honest, this search took some time, because a very limited number of “Phone Spoofing” services permit to place phone calls across Europe. Whereas in the United States Caller Id spoofing is somehow tolerated, in Europe is completely illegal.

This service can also be made totally anonymous using Skype and calling directly the Service Phone Number:

A Female voice will ask to enter your user ID, the Number to Call and The Fake User ID


Conclusion

Phone Back authentication systems should be tested against Caller Id Spoofing, because this attack is going to be easier and easier in the future. Caller Id authentication is not secure, other information should be used for securing the transaction, unless a secure handshake is put into place.

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.