McAfee Avert Labs Blog

PCI Requirement #6.6 has been in the news for quite some time, primarily because complying with it is not trivial. PCI Security Council published a press release on April 22, 2008, hoping to clarify some of the requirements and help merchants comply before the upcoming deadline of June 30, 2008. Some of the clarifications are confusing, since they seem to go against basic application security concepts, as well as the principle of compensating controls already laid out by the PCI standard.

Requirement #6.6 aims to secure web sites against attacks, by requiring either of the following for all web-facing applications:

1. Manual code review by experts
2. Application Layer Firewall

Now this press release effectively says that the intent of code review requirement is met by:

• Manual web application security vulnerability assessments
• Proper use of automated web application security vulnerability assessment (scanning) tools

The million dollar question is: Can a vulnerability assessment or penetration test really deliver the same findings that a code review does? Is it OK to think that a code review can be replaced by a vulnerability assessment or a penetration test?

I don’t think so. Code review is a white box exercise, where as vulnerability assessment is a black box exercise. Code review allows a security expert to look under the hood and see the guts of the application, where as a vulnerability assessment looks at the application from outside and can only see the few security flaws that have actually manifested themselves into full blown exploitable vulnerabilities. Therefore a vulnerability assessment will leave out many other complex, subtle, yet serious flaws that only a code review could have discovered.

So I wonder why the council thinks that it meets the intent of the code review requirement.

Now here’s some background before you read about the next confusion.

The PCI standard clearly states that a compensating control must be in addition to controls required in the PCI DSS. Sounds complicated but it’s really simple. Let me explain with an example: Let’s take Requirement #3.3 which requires the PAN to be masked when displayed. If this requirement cannot be met then the merchant will have to propose a compensating control. However a compensating control which says that “this data is only accessible to a limited set of employees who need to work with this data” will not be acceptable, because this control is already covered under PCI Requirement #7 which says that data should be accessible only to those employees which have a business need.

Going by this logic, Requirement #11.2 and 11.3 already cover manual web application security vulnerability assessment as well as automated web application security vulnerability assessment (scanning) tools. So how can these be considered acceptable as a compensating control for Requirement #6.6?

I am surprised that such a proposal is made by none other than the Council, which is the champion of the PCI standard. I really hope the Council corrects this mistake.

- Vivek

Note: Vulnerability assessments and penetration tests can be interpreted differently by different audiences. So I should clarify that I am interpreting them as per PCI guidelines, which closely match how Foundstone interprets these services too.

We have been in contact with one of the German’s Crime Investigating Authorities (LKA). This is a case when a malicious program running on mobile phones was making unauthorised calls. All these calls were connecting to one and the same SMS number which is used to top-up the amount of virtual money for one of the online games. A scheme to top-up in-game cash via SMS messages is frequently used by online game vendors.

This is a really interesting twist because in the past malware writers simply programmed malware (either on a desktop or on a mobile device) to call a premium phone number (one where the cost of a call is high). Of course, with this old method it is easier to trace the destination of funds because for each such call real money is transferred from a phone company to the owner of the premium number. So the principle “follow the money” to track the perpetrators usually works.

This new and indirect way of laundering money through an online game makes it significantly more difficult to track the destination - several in-game assets’ transfers can be made before the money is taken out of the game through real-money trading (RMT - it is a bannable offence in most online games but some games allow that - for example, Second Life).

Our advice is not to use programs for mobile phones that come from untrusted sources (like game forums, Internet newsgroups, Emails, P2P networks, blogs, etc.)

Avertlabs would kindly ask all mobile phone users to be vigilant and submit suspicious programs for our analysis - the easiest way is to use our online Webimmune service www.webimmune.net.

…and from the Crowne plaza hotel - home of the 2nd CARO workshop on “Packers, Decryptors and Obfuscators”.

As you may know, nowadays malware mostly comes in a packed form, in order to thwart Anti-Malware and security products. For this reason it is of great importance to be able to develop technologies that are able to “see through” these executable wrappers and detect the underlying malware in a smart way.

Easy to say - less easy to do. And this is the reason for which this workshop is really interesting

After attending this morning’s part of the workshop I have to say that the presented content has been really excellent - and technical too. Starting from the keynote speech through all the others thus far I’ve been struck by the depth of the information shared. I found Kurt Natvig’s presentation especially interesting as it covered the difficulties emulators face when dealing with modern malware - good job, Kurt!

Hopefully the presentation will be made available online too so I definetely advise anyone interested to monitor the CARO workshop website!

I need to go now as the afternoon’s presentations are starting! Talk to you later!

A recent report by the OECD (Organisation for Economic Co-operation and Development) indicated that counterfeit and pirated goods in 2005 could have had a value of up to 200 billion U.S. dollars.

One path to fake goods is via spam, which frequently offers counterfeit medicines and replica watches. A recent post from the French CERT-LEXSI blog caught my attention regarding fake luxury mobile phones selling for absolutely unbeatable prices.

These phones are normally manufactured by Vertu, a British subsidiary of Nokia, and are sold in luxury shops in Monte Carlo, Cannes, or Beverly Hills. On their official top-quality site (www.vertu.com), prices are not mentioned, but by visiting some authorised retailer Web sites I found exorbitant figures. Some mobiles, bedecked in gold and diamonds, exceed $90,000. Really too expensive for me!

Using Google, it’s really easy to find fake sites offering these counterfeit marvels. In fact it is easier to find the fake sites than the authorized ones!

And the prices–assuming you need one of these–are attractive: less than $1,000 for a copy of an original that sells for $97,300.

Regular spam campaigns promote such Vertu “replica” sites. Be vigilant, however, because appearances can be deceiving. Sites are numerous and their common feature is their high-quality, professional look–with black backgrounds that imitate the official site.

These sites are hosted at various providers in various countries (USA, Germany, and Hong Kong). Some of them seem clean; others are known for bulletproof hosting services and their relationship with the Russian Business Network, an alleged cybercrime organization. The registrars are also diverse (Estonia, Russia, and Korea) but more questionable. It is surprising that these do not require any name verification before accepting registrations. But once you know that a lot of spam and malware-related Web sites come from them, their permissiveness is easier to understand. Registrant addresses and e-mails give us an inkling regarding the nationality of their owners: China and Russia.

For the potential buyer, the key issue concerns the risk. The Swiss Watch Industry clearly points out that the buyer is the first victim, because purchasing counterfeits is:

• Agreeing that piracy is OK; the counterfeiter seeks to appropriate somebody else’s hard work and investment.
• Supporting and financing organized crime; links between counterfeiting activities and criminal networks have been established in many cases.
• Accepting underground and child labor.
• Endangering your own health and safety; the risk is real with medicines, aircraft and auto spare parts, medical supplies, and cosmetics.
• Reducing employment and stifling growth; this form of criminality contributes to the reduction of employment, which is estimated to cost more than 200,000 jobs worldwide per year.
• Being liable to criminal sanctions; the buyer may face criminal and financial sanctions. The mere possession of counterfeits is illegal in many countries. Furthermore, penalties could be claimed by legitimate intellectual property rights’ owners. Customs also can seize and destroy illegal items and assess fines.

And if these considerations don’t stop you, remember you run the risk of not receiving the goods you pay for; instead you might have your banking details stolen and reused in future malevolent activities. None of the sites I visited yesterday offered a secure Internet payment system; one of them housed a hidden Iframe linked to a known password-stealing Trojan.

There’s been considerable stink lately about the Race to Zero contest that is to be held at Defcon. I, for one, am a bit perplexed by this. This article from ZDNet Australia is what finally made my eyes cross in confusion/aggravation.

I don’t know at what point the collective “wisdom” became that signature-based AV was ever intended to be about defending against every threat ever devised, before it was ever devised. Signature-based scanners are intended to detect and clean known threats. If you modify a known threat, it’s not really “known” anymore, is it? Now it’s a variant of a known threat.

It’s certainly desirable to have protection against all threats, known and not-yet-known. This is what things like firewalls, Intrusion Prevention Systems, Data Leakage Prevention and all those other wonderful security products are intended to do, in concert with AV. Most AV software now also includes proactive static detection like Generic and Heuristic detection, along with more dynamic detection like emulation or behavioral detection. Many AV programs now also include broader security functionality like a firewall or IPS.

Generic and Heuristic detection is certainly better at picking up unknown threats than simple signature-based scanning, but there are three things that limit it. For one, it’s still reactive, basing detection on known bad techniques. Secondly, it’s static - obfuscation can still muck up the detection, if it causes the file to deviate from the known bad technique. Finally, there’s still a need for these detections not to be false-prone. Heuristics and generics essentially cover known “really, really bad” techniques. The threshold of badness must be quite high to make it into AV products. Consider how many commercial products and widely used administration tools blur those lines, and you may come to appreciate what a very fine line it is.

It’s not clear from what I’ve seen whether the contest’s judges intend to use the most paranoid settings available within the various products, but their description does seem to indicate they’ll only use the static detection, rather than running it real-time through the products. This does not accomplish a full testing of the products capability, it only tests one component. The results they get will not be what an average user will get.

The contest organizers and participants are playing with fire in order to prove what we already know: Signature-based scanners are meant to protect against known threats. That doesn’t mean that AV is dead, or that it’s useless. The industry is evolving, and its products with it. AV is intended to be one tool in a complete security arsenal. Defense in depth is where it’s at, if you’re really looking to protect your network.

Over the past week, Mailbot.f (a.k.a “Kraken”) was thoroughly studied and reverse engineered by various security researchers. As mentioned in my previous blog, we focused mainly towards the network behavior of the bot and observed a few interesting things.

After the bot installs on a victim machine, it attempts to contact mx.google.com via TCP destination port 25 (SMTP) 3 times. This looks to be a network connectivity test by the bot. If this test fails, the bot does not send out any spam at a later stage. (Note that the bot does not use mx.google.com to spam). Next, the bot downloads the front page of 3 different popular web sites (mostly news sites), such as nytimes.com, cbsnews.com, news.com, cnn.com, reuters.com, msn.com, google.com, etc. We have not observed the use of these web pages in the spam sent out by this bot, however.

The bot then tries to find its peers and communicates with them. If it is an older version of the bot, it uses UDP destination port 447 to communicate with the peers, sending information such as the bot version, outgoing smtp connectivity status and other machine specific information such as hostname, operating system, uptime, language, CPU specs, memory information etc. It also communicates the current modules and their versions. The older version of the bot then downloads an update from its peers by connecting on TCP destination port 447. We have observed that this update is around 100 to 200 kbytes. The bot then updates itself.

The new version of the bot (or updated bot from the previous step) contacts its peers using UDP on random destination ports and sends similar information as in the previous step. It then connects to one of the peers to update its modules using TCP destination port 80. If the peer is available on port 80, the bot communicates using HTTP POST messages and receives the updates from its peers.

In the case when the peer is not available on TCP port 80, the bot communicates on TCP destination port 443 to download the module updates. Though it communicates using TCP port 443, the data is not SSL.

The bot then downloads other modules from its peers, such as spam template, spam payload, and mx server addresses, etc. With this information it starts sending out spam email. After sending out a batch of spam, it downloads further updates and sends out spam again.

We made the above observations after looking at a number of Mailbot.f samples. Most of these samples were either v315 or v316 (as derived from the bot client registration packet). All of the command & control (c&c) communication is encrypted and we were able to decode some of the c&c communication using the wireshark plugin referenced by mnin security blog. Since the bot can be updated, at will by the bot author, some of these observations may/can be changed at any time.

Given that the bot uses

• encrypted data
• random UDP destination ports with random size packet payloads
• legitimate HTTP protocol on TCP destination port 80
• communication on TCP destination port 443

its c&c communication is very stealthy and difficult to detect. Although the bot is currently being used to send spam email, the stealthy c&c communication and the update infrastructure already in-place can pose a greater threat if used for more devastating purposes.

There have been a couple of threads lately, one on LifeHacker, one on Ask Metafilter, about whether it’s necessary to use anti-virus software. The comments in both are a very clear indication on how far we have to go in educating users on the real danger of malware. It would appear the average user is operating under assumptions that might have been true 8 years ago. Now, it’s just a recipe for disaster.

The erroneous assumptions are that:

1) Viruses are noisy/easily visible and
2) Viruses are caused by actively bad behavior

To quote What the Geek from the LifeHacker thread,

I have a business client whose website was giving people a trojan for a while because it got hacked - and guess what? if you didn’t have an AV running, you’d never know that it happened. It would just sit on your computer sending your data off to who knows where silently. Just because it doesn’t give you a big skull and crossbones on the screen doesn’t mean it isn’t there.

This really sums up the situation for me - an innocent user was hacked, and might never have known it, as it was silent. It’s like the difference between the demos we give of an “average scary virus” now versus the ones we gave 10 years ago. Back then, the demos were all skulls and message-boxes and file corruption and deletion. Very spooky, very visual and very loud. Now the scary demos are effectively silent. The malware can come in without any user interaction, and you’d never know it was there without specific tools to show you what changes it’s making behind-the-scenes. Off goes your credit card number and your private documents, without you being the wiser.

And this is not something that just happens in the “bad parts” of the internet. Think of the most innocuous content on the internet. Pictures of cute and fluffy animals would certainly qualify, right? At the end of last year, CuteOverload fell victim to a hacking that delivered trojans to its unsuspecting readers. And major sites are supposed to be safe, right? How about the Superbowl website hack from the beginning of last year?

One point that I think needs bringing up specifically is the question of whether to use “on-access” scanning, or if “on-demand” is enough. As Dwroth succinctly put it in the LifeHacker thread:

All time (active protection) = good for the public, but overkill for the geek.

Turning off on-access scanning has never been a great idea, but now it could be a catastrophically bad idea. We’ve already discussed how one’s level of geekiness does not figure into one’s susceptibility to viruses which don’t require human interaction. Personally, if there’s a virus trying to get onto my computer, I’d really rather find out immediately before any changes could be made to my system rather than some time tomorrow or later this week.

A few minutes is plenty of time for malware to transmit my most sensitive data, why give it hours?

Clear protocols such as FTP or SMTP are unsafe. Anyone on the subnet can easily collect login usernames and passwords just by sniffing the network traffic. Even switched networks can be easily attacked to redirect traffic and gather credentials as simply as on a HUB based network. However, FTP is still widely used and often the only protocol provided by hosting providers and it’s for this reason we weren’t so surprised to come across PWS-FerTP – a piece of malware that takes advantage of this situation, collecting FTP credentials and infecting FTP repositories.

To slow down analysis, PWS-FerTP includes some (very simple) anti-debugging tricks and VMWare detection functionality shown below. Not very stealthy though, utilizing some well known VMWare internal mechanisms used mainly by VMware tools to communicate with the host system.

PWS-FerTP bypasses the Windows Firewall (by modifying the registry) and starts to look for three widely used client applications providing FTP support (FAR Manager, CuteFTP and Total Commander). Indeed, these applications unfortunately use weak encryption to save FTP passwords, while other details such as logins and IP addresses are stored in the clear.

In an attempt to gather more FTP credentials, PWS-FerTP switches the first network adapter found on the system to promiscuous mode via the ioctlsocket API call, allowing for a disabling of MAC filtering and thus sniffing all FTP account details passing by the current subnet.

PWS-FerTP sends all gathered credentials within specially crafted HTTP requests to a remote web server.

But PWS-FerTP is more than a password stealer – a quick string search reveals some interesting blocks of obfuscated Javascript as well:

Once decoded, the aim of this script becomes much clearer, redirecting user’s browser via an IFRAME HTML tag pointing to a malicious website.

In fact, PWS-FerTP connects to each previously gathered FTP account and looks for files whose names belong to this list:
- index.htm
- main.htm
- default.htm
- index.php
- main.php
- default.php

When such a file is found, PWS-FerTP retrieves it locally, injects the Javascript code shown above, and put the file back to the FTP repository.

Another good reason to follow well-known best practices: avoid using clear-text protocols and use applications providing strong encryption, like keepass, to store your credentials.

So, on a bright Friday morning here in Brazil, I was analyzing an interesting piece of malware. Well, this piece of malware was sending encoded data to gooqle-analytics.com…hmmmm maybe trying to get infection statistics?

We have seen this before…but something wasn’t quite clear… it seemed that this was all that the malware was doing… hmmmm ok… checking a little closer, I could see the traffic generated… it was encoded traffic… not common for Google Analytics…

A little more research revealed that there was a dll injected in the svchost process, and analyzing this packed dll revealed that its purpose was to steal information and send to gooqle-analytics… but what the heck? Is Google stealing my info? NOT!!! As some of you noticed reading this blog, I did not misspell the name… it was sending the info to gooqle-analytics.com, and not google-analytics.com…

This gooqle thing domain is hosted on a IP in Italy…yea…bad,bad gooQle…!

I was not at all surprised when I first saw the Trojan named anticnn.exe, because I’ve followed recent events between China and the Western media. I am not going to offer any political comments on the conflict between these parties; however, the appearance of this malware well illustrates how information warfare works and further proves that this kind of nonmilitary, nongovernmental battle has become an increasingly common phenomenon.

The Chinese “hacktivists” obviously have no intention of hiding their origins. The file has the flag of the People’s Republic of China as its icon. Upon execution, the red flag is displayed in the lower-right corner of the desktop. After a user clicks the flag, a window with a picture of Mao Zedong pops up with the message “It is a red flag action: using rational action to express your patriotism. That attack target is www.cnn.com.”

The file connects with www.cnn.com and keeps sending HTTP GET requests. The Chinese “hacktivists” seem to believe that as long as there are sufficient participants they will be able to succeed in their attack.

McAfee has detected this malware. I remain concerned, however, that anti-virus detection can prevent only those users who are unaware of the situation from getting involved in this event. Eventually this Trojan could be widely distributed via spam, malicious or hacked Web pages, Internet Relay Chat (IRC), peer-to-peer networks, etc. This attack looks like it will be hard to stop if many “infected” users intend to get this tool and run it intentionally.

Just one day later, we came across another tool designed for the same purpose. The difference with this tool is that it does not have a hard-coded target address. Instead, it allows users to manually input a target’s IP address or DNS name, and TCP port. Obviously, the organizers do not wish to name their target too early. In the setup program’s readme file, it says the attacker will inform the target a half-hour before the attack will be launched. Another interesting point: The tool developer states in the readme file that the tool has no backdoor inside. That makes me ask, Should the average user trust the developer’s claims?