English
The Internet threat alert status is currently normal. At present, no major epidemics or other serious incidents have been recorded by Kaspersky Lab’s monitoring service. Internet threat level: 1
Latest posting
By rating
By popularity

Join our blog

You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings.

Events|New MacOS X backdoor variant used in APT attacks

Costin Raiu
Kaspersky Lab Expert
Posted June 29, 12:02  GMT
Tags: Apple MacOS, Apple
0.6
 

Two days ago we intercepted a new APT campaign using a new MacOS X backdoor variant targeted at Uyghur activists.


But before we go into details, let’s start with a quiz:

- The Dalai Lama walks into an Apple Store. Why?

Follow me on Twitter A possible answer is, “to buy one of the new MacBook Pro’s with the Retina display!” (speaking of which, I would very much like to buy one of those as well, but it’s kind of difficult to justify the hit to the family budget)

Joke aside, actually Dalai Lama is a well known Mac user. Here’s a photo of him using a Mac during a conf call:


0.3
 

Deep inside one of Stuxnet’s configuration blocks, a certain 8 bytes variable holds a number which, if read as a date, points to June 24th, 2012. This is actually the date when Stuxnet’s LNK replication sub-routines stop working and the worm stops infecting USB memory sticks.

Opinions|Traveling in an interesting time

Dmitry Bestuzhev
Kaspersky Lab Expert
Posted June 25, 05:15  GMT
Tags: Data leaks
0.1
 

When you arrive to a foreign country you may encounter an unexpected situation when the local authorities request your passwords. If you refuse, your entry to the country may be denied. That is a really bad situation. So, what should you do and what shouldn’t you do in order to not to lose your sensitive information and at the same time be granted entry to the country?

  • Have a bulk email with a unique password. This email address must be simple but a real one with no sensitive information stored in it. Please remember that the password you have for it shouldn’t be the same as for any other resource. The same is for the secret question you may have for the password recovery.
  • Don’t bring your main computer on trips! Have a travel one; use it only for when you travel abroad. Since it would be only for travel, you may encrypt only a part of the hard drive of this computer and not the entire disk. It will help you avoid more questions.
  • If you bring USB devices, make sure not to have anything sensitive on them.
  • Work only under your own VPN connections; make sure to use OpenVPN since it works even under very restrictive Firewalls and Proxies.
  • Make sure to use security software capable to detect malware and also network layer attacks.
comments      Link

Virus Watch|Android Security Suite Premium = New ZitMo

Denis
Kaspersky Lab Expert
Posted June 18, 12:30  GMT
Tags: Mobile Malware, ZeuS, Google Android
0.3
 

On the 4th of June 2012 we found 3 APK files of ~207 kb in size each heuristically detected by our engine as HEUR:Trojan-Spy.AndroidOS.Zitmo.a. All these applications are malicious and were created to steal incoming SMS messages from infected devices. SMS messages will be uploaded to a remote server whose URL is encrypted and stored inside the body of the Trojan. We found 3 more APK files with exactly the same functionality on 8th, 13th and 14th of June. So there are at least 6 files which pretend to be ‘Android Security Suite Premium’ but in fact were created only for stealing incoming SMS messages.

After the infection there is a blue shield icon in the menu with the name ‘Android Security Suite Premium’:

If the application is launched it will show a generated ‘activation code’:

0.2
 

Recently, we came by an interesting targeted attack which was evading most antivirus products. This is a recent spearphish targeting various Tibetan and human rights activists. It demonstrates the level of effort put into infiltrating their groups with some unique characteristics, relative to the many other exploits targeting CVE-2012-0158. Here’s how such e-mails appear:

Spam Test|Spam: Euro 2012 vs Summer Olympics

Maria
Expert
Posted June 14, 07:35  GMT
Tags: Spam Letters
0.1
 

Summer 2012 will be packed with sporting events. This week sees the Euro 2012 football championship kick off in Poland and Ukraine. The tournament will bring together 16 of Europe’s best teams, and football fans from all over the continent will be watching closely regardless of whether their country qualified for the finals or not. Official ticket sales for Euro 2012 were launched on 12 December 2011, but spammers – rather unusually for them – were in no hurry to exploit the event. The first mailing offering tickets to Euro 2012 was only detected at the beginning of January. Since Ukraine is one of the host countries for Euro 2012, there were lots of messages in Russian and Ukrainian. The afore-mentioned message offering tickets was just one of them.

0.3
 

Microsoft released a set of seven bulletins, patching 26 total software vulnerabilities. Multiple remote code execution holes are being patched, but the two most urgent are the Internet Explorer and Remote Desktop Protocol updates. Almost half of the 26 vulnerabilities being patched this month are maintained in versions 6, 7, 8, and 9 of Internet Explorer code, all patched with Security Bulletin MS12-037.

RDP is not enabled by default on Windows systems, but exposure to this month's remote code execution vulnerability is a problem for many businesses around the world, as the recent activity from the Morto worm demonstrated. Many businesses need to use Remote Desktop functionality and enable it, but don't understand how to or just don't bother hiding the port behind a firewall and limiting access or requiring VPN access only. Past pre-authentication vulnerabilities in RDP should have improvded the situation by now, and folks need to understand that this service should be better isolated. We'll see if this one is taken advantage of in coming weeks. Updating systems with MS12-036 is a priority - including Windows 2003 installs and up to the Server Core installation of Windows Server 2008 R2 for x64-based Systems Service Pack 1. It's rated critical, and most versions of Windows server OS are vulnerable not only to DoS attacks, but remote code execution.

For most folks, properly licensed Windows systems with Windows Updates enabled will update the software automatically over the next day or so. People can also find "Windows Updates" in their start menu and open it, then click on "Check for Updates".

Comment      Link
0.4
 

Two weeks ago, when we announced the discovery of the Flame malware we said that we saw no strong similarity between its code and programming style with that of the Tilded platform which Stuxnet and Duqu are based on.

Flame and Tilded are completely different projects based on different architectures and each with their own distinct characteristics. For instance, Flame never uses system drivers, while Stuxnet and Duqu’s main method of loading modules for execution is via a kernel driver.

But it turns out we were wrong. Wrong, in that we believed Flame and Stuxnet were two unrelated projects.

Our research unearthed some previously unknown facts that completely transform the current view of how Stuxnet was created and its link with Flame.

The Flame inside Stuxnet

First of all, let’s recap the Stuxnet story. We managed to recover just three different variants of the worm, created in June 2009, and in March and April 2010.

The March 2010 variant was responsible for the greatest number of infections and was detected in June 2010 by specialists from the company VirusBlokAda in Belarus. This particular version was subjected to the most detailed analysis by anti-malware companies.

Shortly afterwards, when news of Stuxnet had already become widespread, files related to its June 2009 incarnation were detected. This version, the so-called Stuxnet.A (1.0), differed considerably from the 2010 variants.

The main differences were:

  • The 2009 variant didn’t use the MS10-046 LNK file vulnerability
  • In 2009, Stuxnet only had one driver file; in 2010 there were two (the second was added specifically to work with the LNK vulnerability)
  • In 2009, Stuxnet used a special trick with the “autorun.inf” file to infect USB drives.
All the other differences involve minor modifications to Stuxnet’s internal structure – some modules were deleted and their functions transferred to other modules.

The most significant of those changes involved “resource 207”.

Resource “207” is 520,192 bytes in size and can be found in the 2009 version of Stuxnet. It was later dropped altogether in the 2010 version, its code merged into other modules.

List of resources in the March 2010 variant of Stuxnet

List of resources in the 2009 variant of Stuxnet

Despite the fact that Stuxnet has been the subject of in-depth analysis by numerous companies and experts and lots has been written about its structure, for some reason, the mysterious “resource 207” from 2009 has gone largely unnoticed. But it turns out that this is the missing link between Flame and Stuxnet, two seemingly completely unrelated projects.

The Tocy story

In October 2010, our automatic system received a sample from the wild. It analyzed the file thoroughly and classified it as a new Stuxnet variant, Worm.Win32.Stuxnet.s.

With Stuxnet being such a big thing, we looked at the sample to see what it was! Sadly, it didn’t look like Stuxnet at all, it was quite different. So we decided to rename it to Tocy.a and thought “silly automatic systems!”.

When Flame was discovered in 2012, we started looking for older samples that we might have received. Between samples that looked almost identical to Flame, we found Tocy.a.

Going through the sample processing system logs, we noticed it was originally classified as Stuxnet. We thought, how was it possible? Why did the system think that this Flame sample was related to Stuxnet? Checking the logs, we discovered that the Tocy.a, an early module of Flame, was actually similar to “resource 207” from Stuxnet. It was actually so similar, that it made our automatic system classify it as Stuxnet. Practically, Tocy.a was similar to Stuxnet alone and to no other sample from our collection.

Going back to the story, this is how we discovered the incredible link between Flame and Stuxnet.

0.6
 

The Flame malware uses several methods to replicate itself. The most interesting one is the use of the Microsoft Windows Update service. This is implemented in Flame’s “SNACK”, “MUNCH” and “GADGET” modules. Being parts of Flame, these modules are easily reconfigurable. The behavior of these modules is controlled by Flame’s global registry, the database that contains thousands of configuration options.

SNACK: NBNS spoofing

The SNACK module creates a RAW network socket for either all or pre-set network interfaces and begins receiving all network packets. It looks for NBNS packets of other machines looking for local network names. When such a packet is received, it is written to an encrypted log file (“%windir%\temp\~DEB93D.tmp”) and passed on for further processing.

When a name in the NBNS request matches the expression “wpad*” or “MSHOME-F3BE293C”, it responds with its own IP address. If “SNACK.USE_ATTACK_LIST” variable is set to “True”, it also checks whether packets originate from IP addresses specified in its “SNACK.ATTACK_LIST” and responds to machines with these addresses.

“Wpad” is a name used for automatic proxy detection. By responding to “wpad” name requests with its own IP address, the SNACK module announces the infected machine as a proxy server for its local network.

SNACK and MUNCH also communicate with the GADGET unit that provides facilities for handling different events that come from other modules. The Flame’s registry contains LUA modules for processing events like “MUNCH_ATTACKED”, “SNACK_ENTITY.ATTACK_NOW”.

MUNCH: Spoofing proxy detection and Windows Update request

“MUNCH” is the name of the HTTP server module in Flame. It is started only if “MUNCH.SHOULD_RUN” variable is set to “True” and there are no running programs that can alert the victim. These programs (anti-virus, firewalls, network sniffers etc.) are defined in the Flame’s registry in a list called “SECURITY.BAD_PROGRAMS”

When MUNCH is started, it reads a buffer from the “MUNCH.WPAD_DATA” variable, replaces the pattern “%%DEFAULT%%” with the IP address of its best suitable network interface and waits for HTTP requests.

Contents of the “MUNCH.WPAD_DATA” variable

The “MUNCH.WPAD_DATA” buffer is actually a WPAD file that is requested by network clients that implement automatic proxy server detection. The code in the WPAD file matches the MD5 hash of the hostname that the client is connecting to against its own list, and if found, offers itself as a HTTP proxy. We were able to identify the hashes:

download.windowsupdate.com
download.microsoft.com
update.microsoft.com
www.update.microsoft.com
v5.windowsupdate.microsoft.com
windowsupdate.microsoft.com
www.download.windowsupdate.com
v5stats.windowsupdate.microsoft.com
v4stats.windowsupdate.microsoft.com
v9stats.windowsupdate.microsoft.com
v5.windowsupdate.com
v7stats.windowsupdate.microsoft.com
v6stats.windowsupdate.microsoft.com
v8stats.windowsupdate.microsoft.com
v5.download.windowsupdate.com

So, when a machine configured with automatic proxy detection tries to access one of the Windows Update hosts, it receives an IP address of the infected machine from SNACK, and then receives the IP address of the same machine as a proxy server from “wpad.dat” provided by MUNCH. From then, requests to the Windows Update service are passed through the MUNCH server.

When a network client connects to the MUNCH server and requests an URI other than “/wpad.dat” and “/ view.php”, the server :

1) Runs “MUNCH.SHOULD_ATTACK_SCRIPT” – Lua script that checks if the User-Agent header matches at least one of the patterns specified in “MUNCH.USER_AGENTS.CAB_PATTERN_*”. The Flame registry files that we have contained the following patterns:

MUNCH.USER_AGENTS.CAB_PATTERN_4 : WinHttp%-Autoproxy%-Service.*
MUNCH.USER_AGENTS.CAB_PATTERN_3 : Windows%-Update%-Agent.*
MUNCH.USER_AGENTS.CAB_PATTERN_2 : Industry Update.*
MUNCH.USER_AGENTS.CAB_PATTERN_1 : Microsoft SUS.*

2) Checks if the requested URI matches any pattern specified in the list of strings called “MUNCH.GENERIC_BUFFERS.*.data.PATTERN”. If one of the expressions match, it then gets the buffer specified in the corresponding “MUNCH.GENERIC_BUFFERS.*.data.FILE_DATA” value, reads the payload value called “MUNCH.GENERIC_BUFFERS_CONTENT.value_of_FILE_DATA” and sends it to the client.

All the payloads are listed in the Flame’s registry with names starting with “MUNCH.GENERIC_BUFFERS_CONTENT.payload_name”, and are encoded with a fixed 104-byte RC4 key.

0.7
 

In our FAQ on Flame posted on May 28, 2012, we postulated there might be a still undiscovered zero-day vulnerability in Flame:

“At the moment, we haven’t seen use of any 0-days; however, the worm is known to have infected fully-patched Windows 7 systems through the network, which might indicate the presence of a high risk 0-day.”

Our suspicion was heightened because fully patched Windows 7 machines were being infected over the network in a very suspicious manner.

We can now confirm this is the main purpose of a special module of Flame called “Gadget” together with another module called “Munch”.

(NOTE: It’s important to understand that the initial Flame infection could still be happening through zero-day vulnerabilities. The “Gadget” module is simply used to spread within a network from a machine that is already infected with the malware).

The “Gadget” and “Munch” modules implement an interesting man-in-the-middle attack against other computers in a network.

When a machine tries to connect to Microsoft’s Windows Update, it redirects the connection through an infected machine and it sends a fake, malicious Windows Update to the client.

The fake update claims to be the following:

“update description="Allows you to display gadgets on your desktop."
displayName="Desktop Gadget Platform" name="WindowsGadgetPlatform">

In the process of infecting a client, 8 CAB files are used. One of them contains a specifically built program called WuSetupV.exe:

This program (also detected as Worm.Win32.Flame.a), which is 28KB in size, has been signed by a fake Microsoft certificate:

This allows it to run in the victim’s machine without any warnings.

The Flame “Gadget” downloader was compiled on December 27th, 2010. It was signed on December 28 and it was finally put into the CAB archive on Jan 11, 2011.

The following is exactly how the process occurs: the infected machine sets up a fake server by the name “MSHOME-F3BE293C”, which hosts a script that serves a full body of the Flame malware to victim machines. This is done by the module called “Munch”.

When a victim updates itself via Windows Update, the query is intercepted and the fake update is pushed. The fake update proceeds to download the main body and infect the computer.

Gadget plugin downloads the main body of the malware

The interception of the query to the official Windows Update (the man-in-the-middle attack) is done by announcing the infected machine as a proxy for the domain. This is done via WPAD. To get infected, the machines do need however to have their System Proxy settings configured to “Auto”.

As we continue our investigation of Flame, more and more details appear which indicate our initial statement: this is one of the most interesting and complex malicious programs we have ever seen.

Important information: One June 4th, 2012, Microsoft released a number of blog posts and an Update for Windows which is blocking three fraudulent certificates used by Flame. We recommend that Windows users apply this update immediately.

Microsoft SRD blog:http://blogs.technet.com/b/srd/archive/2012/06/03/microsoft-certification-authority-signing-certificates-added-to-the-untrusted-certificate-store.aspx

Microsoft security advisory 2718704:http://technet.microsoft.com/en-us/security/advisory/2718704

MSRC blog:http://blogs.technet.com/b/msrc/archive/2012/06/03/microsoft-releases-security-advisory-2718704.aspx

comments      Link
0.9
 

On Sunday, May 27 2012, the Iranian MAHER CERT posted a note announcing the discovery of a new targeted attack dubbed “Flamer”. On Monday 28 May 2012 aat 9am EST, after an investigation prompted and supported by the International Telecommunication Union, Kaspersky Lab and CrySyS Lab from Hungary announced the discovery of Flame (aka Skywiper), a sophisticated cyber-espionage toolkit primarily targeting Windows computers in the Middle East.

Several hours later, around 4PM GMT, the Flame command-and-control infrastructure, which had been operating for years, went dark.

For the past weeks, Kaspersky Lab has been closely monitoring the C&C infrastructure of Flame. In collaboration with GoDaddy and OpenDNS, we succeeded in sinkholing most of the malicious domains used by Flame for C&C and gain a unique perspective into the operation.

Before going further, Kaspersky Lab would like to thank the “GoDaddy Network Abuse Department” and to William MacArthur for their fast reaction and exceptional support of this investigation. The OpenDNS security research team also offered invaluable assistance during the course of this investigation.

Our findings from analysing the infrastructure can be found below.

Introduction

Since both Flame and Duqu appear to be targeting similar geographical regions and have been created with similar goals in mind, we will provide an analysis from the point of view of comparing the Flame C&C infrastructure with the Duqu infrastructure.

In the past, Kaspersky Lab analyzed the Duqu C&C infrastructure and found several important details, such as the attackers’ preference for CentOS, the use of SharpSSH to control the proxy servers and the huge number of hacked proxies used to hide the true identity of the attackers.

In the case of Flame, we performed a similar analysis. First of all, it’s interesting to point out a big difference from Duqu: while all the Duqu C&C proxies were CentOS Linux hosts, all of the known Flame C&C are running Ubuntu.

Additionally, while Duqu used the super stealthy way of hiding the true IP of the mothership using SSH port forwarding, Flame’s scripts are simply running on the respective servers. The reason is simple — on Monday May 28, all control scripts started returning 403/404 errors. In the case of Duqu, the real malware scripts were on a remote server and were never found.

From this point of view, we can state that the Duqu attackers were a lot more careful about hiding their activities compared to the Flame operators.

Here’s a comparison of the Duqu and Flame C&C infrastructure:

Duqu Flame
Server OS CentOS Linux Ubuntu Linux
Control scripts Running on remote server, shielded through SSH port forwarding Running on servers
Number of victims per server 2-3 50+
Encryption of connections to server SSL + proprietary AES-based encryption SSL
Compression of connections No Yes, Zlib and modified PPMD
Number of known C&C’s domains n/a 80+
Number of known C&C IPs 5 15+
Number of proxies used to hide identity 10+ Unknown
Time zone of C&C operator GMT+2 / GMT+3 Unknown
Infrastructure programming .NET Unknown
Locations of servers India, Vietnam, Belgium, UK, Netherlands, Switzerland, Korea, etc... Germany, Netherlands, UK, Switzerland, Hong Kong, Turkey, etc...
Number of built-in C&C IPs/domain in malware 1 5, can update list
SSL certificate self-signed self-signed
Servers status Most likely hacked Most likely bought
SSH connections no yes