10 Dec Microsoft Updates December 2013 - Patching Critical 0day Exploited in the Wild Kurt Baumgartner
26 Sep The Icefog APT: A Tale of Cloak and Three Daggers GReAT
11 Mar Miniduke: web based infection vector Igor Soumenkov
12 Feb Adobe Flash Player 0-day and HackingTeam's Remote Control System Sergey Golovanov
27 Sep Virus Bulletin 2012: From Privacy Issues to Exploit Sales Fabio Assolini
28 Aug The Current Web-Delivered Java 0day Kurt Baumgartner
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.
Eight Microsoft Security Bulletins are being pushed out this month, MS13-096 through MS13-106. Five of them are rated "Critical" and another six are rated "Important". The top priorities to roll out this month are the critical GDI+ (MS13-096), Internet Explorer (MS13-097), and Scripting Runtime (MS13-099) updates.
Several of the vulnerabilities have been actively exploited as a part of targeted attacks around the world, and one of them is known to be ItW for at least six months or so.
The GDI+ update patches memory corruption vulnerability CVE-2013-3906, which we have been detecting as Exploit.Win32.CVE-2013-3906.a. We have seen a low number of ITW variations on exploitation of this vulnerability as a malformed TIFF file, all dropping backdoors like Citadel, the BlackEnergy bot, PlugX, Taidoor, Janicab, Solar, and Hannover. The target profile and toolset distribution related to these exploit attempts suggest a broad array of likely threat actors that got their hands on it since this July, and a wide reaching distribution chain that provided the exploit around the world. Considering the variety of uses and sources, this one may replace cve-2012-0158 as a part of targeted attacks in terms of overall volume.
The Internet Explorer Bulletin fixes seven different elevation of privilege and memory corruption vulnerabilities, any one of which effects Internet Explorer 6 on Windows XP SP 3 through Internet Explorer 11 on Windows Server 2012 R2 and Windows RT 8.1. We expect to see exploits for some of these vulnerabilities included in commodity exploit packs.
Finally, another critical vulnerability exists in the Windows Scripting Engine as yet another "use after free", which unfortunately enables remote code execution across every version of Windows out there and can be attacked via any of the common web browsers. Patch!
This post will likely be updated later today, but in the meantime, more about this month's patches can be found at the Microsoft site.
The world of Advanced Persistent Threats (APTs) is well known. Skilled adversaries compromising high-profile victims and stealthily exfiltrating valuable data over the course of many years. Such teams sometimes count tens or even hundreds of people, going through terabytes or even petabytes of exfiltrated data.
Although there has been an increasing focus on attribution and pinpointing the sources of these attacks, not much is known about a new emerging trend: the smaller hit-and-run gangs that are going after the supply chain and compromising targets with surgical precision.
Since 2011 we have been tracking a series of attacks that we link to a threat actor called ĎIcefogí. We believe this is a relatively small group of attackers that are going after the supply chain -- targeting government institutions, military contractors, maritime and ship-building groups, telecom operators, satellite operators, industrial and high technology companies and mass media, mainly in South Korea and Japan.
Together with our partner CrySyS Lab, we've discovered two new, previously-unknown infection mechanisms for Miniduke. These new infection vectors rely on Java and IE vulnerabilities to infect the victim's PC.
While inspecting one of the C&C servers of Miniduke, we have found files that were not related to the C&C code, but seemed to be prepared for infecting visitors using web-based vulnerabilities.
The page hxxp://[c2_hostname]/groups/business-principles.html is used as an starting point for the attack. It consists of two frames, one for loading the decoy web page from a legitimate website (copied from http://www.albannagroup.com/business-principles.html), and another for performing malicious activities (hxxp://[c2_hostname]/groups/sidebar.html)
Source code of business-principles.html
Decoy webpage loaded
Last week, Adobe released a patch for a vulnerability in Flash Player that was being exploited in targeted attacks.
Before reading any further, we recommend you to take a moment make sure you apply this patch. Adobe offers this nifty tool to check that you have the latest version of Flash Player.
If you are running Google Chrome, make sure you have version -24.0.1312.57 m- or later.
Now back to CVE-2013-0633, the critical vulnerability that was discovered and reported to Adobe by Kaspersky Lab researchers Sergey Golovanov and Alexander Polyakov. The exploits for CVE-2013-0633 have been observed while monitoring the so-called -legal- surveillance malware created by the Italian company HackingTeam. In this blog, we will describe some of the attacks and the usage of this 0-day to deploy malware from -HackingTeam- marketed as Remote Control System.
Greetings from Dallas, Texas, where the anti-malware industry is meeting for the 22nd edition of Virus Bulletin.
The Java 0day activity that we have been monitoring and preventing for almost the past week has been irresponsibly reported on other blogs, with early posts publicly linking to known sites serving the 0day. In itself, the race to publish on this 0day that will be assigned CVE-2012-4681 (a problem with processing access control within "protection domains"), has been irresponsible. Would you encourage folks to walk down a mugger's dark alley with no protection or would you work to communicate the muggers' whereabouts to the right folks and work on lighting the alley or giving better directions? Would you provide muggers with some new weapons that they haven't considered? The efforts this time around seem misplaced.
Anyway, initial sites hosting the exploit were unique and spreading known APT related toolset components, including a Poison Ivy variant. Here is a somewhat unexpected heat map of early, related PIvy detections.
All the related malware that I have seen to this point targeted Windows systems. The exploits are effective against Java 7 and since the initial targeted attacks, news and the samples spread throughout the broader security community and the exploits made their way to metasploit developers, who added PoC to the open source framework. In turn, the Blackhole authors added the exploit to their COTS. So the attacks are widespread at this point. The first victim regions to be hit with the Blackhole stuff were the US, the Russian Federation, Belarus, Germany, the Ukraine and Moldova. But, in relation to the other exploits included in the pack, victims are getting hit only a fair number of times with the 0day. Internet Explorer users are being hit the most, followed by Firefox, Chrome, and Opera, and then a variety of other applications that handle URLs within their documents and eventually pass the malicious .jar on to a Java client, like Adobe Reader.
We are using a variety of detections and techniques to identify the malicious sites, the web pages involved, the exploit code, and the backdoor payloads delivered by these sites. Even though this particular Java 0day is getting hyped, other older exploits in the Blackhole exploit pack continue to get hit on victim systems with higher volume. So our community is protected from the Blackhole sites themselves, the Blackhole webpages serving the Blackhole Java 0day, compromised sites redirecting to the Blackhole sites, the more prevalent older Blackhole exploits and their delivery pages, and the trojans being delivered by these Blackhole sites. In addition to all that, Kaspersky "Advanced Exploit Prevention" adds another runtime/behavioral layer of protection against the 0day itself with with "Exploit.Java.Generic". This addition is the most interesting to myself - exploit pack authors have been focused on improving their Java exploit server-side polymorphism, and this AEP feature defeats those efforts. So, our user community will see access denied altogether for current Blackhole sites, individual Blackhole web pages detected with variations on "Trojan-Downloader.JS.Agent", the backdoors detected with "Trojan.Win32.Generic" and others (i.e., 61A3CE517FD8736AA32CAF9081F808B4, DEC9676E97AE998C75A58A02F33A66EA, 175EFFD7546CBC156E59DC42B7B9F969, 0C72DF76E96FA3C2A227F3FE4A9579F3), and the 0day Java exploit code detected with "HEUR:Exploit.Java.Agent.gen" (i.e. E441CF993D0242187898C192B207DC25, 70C555D2C6A09D208F52ACCC4787A4E2, E646B73C29310C01A097AA0330E24E7B, 353FD052F2211168DDC4586CB3A93D9F, 32A80AAE1E134AFB3D5C651948DCCC7D) among others, along with the runtime AEP prevention. So while you may see a few links to Virustotal with the inevitable complaining that a scanner is missing a specific chunk of altered code along with innaccurate claims that "AV is dead!" or "AV can't detect it", you should take them for the grain of salt that they are. The real story about client side mass exploitation is more complex than those claims. Some researchers call the various points in a delivery vector a kill chain, and Kaspersky products are killing it.
At the same time, Oracle needs to step it up and deliver an OOB patch, which historically they have failed to do. Maybe this event will provide even more pressure to step up their security update delivery process. They have been snapping up some good security research talent and beginning to reach out, which is a start. A very late start.
UPDATE (2012.08.30): Oracle patches CVE-2012-4681 and two other client side RCE vulnerabilities. It is probably a better idea for Windows users to go to their control panel, find the Java applet, and use the Java update software to manually get the latest JRE 7 and 6 releases - the default delay for the Java Update package to check is currently one week for the Java 7 installer.
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 spoofingThe 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.
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.*
“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">
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.
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
In this webcast, Kurt Baumgartner talks about the rise of exploits against vulnerabilities in Oracle’s Java software. The discussion centers around the exploitation of Java vulnerabilities in exploit kits and the poor state of patching on the Windows platform.
Over the past few weeks, we have been busy researching the Command and Control infrastructure used by Duqu.
It is now a well-known fact that the original Duqu samples were using a C&C server in India, located at an ISP called Webwerks. Since then, another Duqu C&C server has been discovered which was hosted on a server at Combell Group Nv, in Belgium.
At Kaspersky Lab we have currently cataloged and identified over 12 different Duqu variants. These connect to the C&C server in India, to the one in Belgium, but also to other C&C servers, notably two servers in Vietnam and one in the Netherlands. Besides these, many other servers were used as part of the infrastructure, some of them used as main C&C proxies while others were used by the attackers to jump around the world and make tracing more difficult. Overall, we estimate there have been more than a dozen Duqu command and control servers active during the past three years.
Before going any further, let us say that we still do not know who is behind Duqu and Stuxnet. Although we have analyzed some of the servers, the attackers have covered their tracks quite effectively. On 20 October 2011 a major cleanup operation of the Duqu network was initiated. The attackers wiped every single server they had used as far back as 2009 – in India, Vietnam, Germany, the UK and so on. Nevertheless, despite the massive cleanup, we can shed some light on how the C&C network worked.