On Friday, a hacker group known as The Shadow Brokers publicly released a large number of functional exploit tools. Several of these tools make use of zero-day vulnerabilities, most of which are in Microsoft Windows. Exploiting these vulnerabilities in many cases leads to remote code execution and full system access.
Both end-of-support and current Windows versions are impacted, including Windows 2003, XP, Vista, 7, 2008, 8, and 2012. Microsoft has released patches for each vulnerability across all supported platforms, but will not be releasing patches for end-of-support versions of Windows. It is highly recommended that any end-of-support Windows systems be replaced or isolated, as these systems will often be impacted by new vulnerabilities, without the availability of a patch.
For zero-day vulnerabilities in Operating Systems, you can use your existing asset inventory information from Qualys AssetView, and search for any OS to determine how many vulnerable assets are deployed. This can be done without additional scanning if the data is relatively fresh.
Days ago, a mysterious online group called Shadow Brokers claims to have stolen US “cyber weapons” from a hacking team called Equation Group. These “cyber weapons” contain about a dozen vulnerabilities which are believed to be exploits used by the National Security Agency (NSA). In this blog, I will analyze the shellcode from the Cisco exploit and show its behind-the-scenes behavior.
A few days ago, SpiderLabs researcher Osaf Orpani disclosed an important vulnerability targeting Joomla, one of the most popular Content Management Systems (CMS). By exploiting this vulnerability, researchers were able to remotely gain full administrative access to the CMS.
Joomla versions 3.2 to 3.4.4 are affected by this major security issue. Since the vulnerability targets the core of the CMS, all websites based on Joomla are vulnerable, whatever the modules used.
Update: A bit less than a week that Adobe released a fix for a 0-day in Flash and now the attack has migrated into at least two commonly available exploit kits – Magnitude (as of June 27) and Angler (June 29). The security researcher @kafeinedocumented in his blog both findings. I hope you are patched already because the exploit is now mainstream.
Original: Adobe came out today with an out-of-band patch (APSB15-14) for their Flash Player, the fifth time that Flash has required an out-of-band fix for a 0-day. FireEye had notified them of a critical vulnerability (CVE-2015-3113) that they discovered in use in Asia. They believeit was developed by the group called APT3 and used in targeted attacks against a number of industries. The vulnerability lies in the video decoding part of Flash and the exploit shows some signs of sophistication by introducing new techniques in their use of ROP.
Update: Adobe has published a new version of the Flash player (184.108.40.2066) that addresses CVE-2015-0311). At the moment only users of the automated Adobe Update service are getting the update. You can go into your control panel and perform a manual update to see the version and trigger a manual update if necessary:
So that means that at the moment my Safari browser is the tool of choice to use. Google Chrome and Internet Explorer use their own update mechanism, which is normally an advantage as they tend to be fast and convenient have not gotten their automated updates yet.You can check on the version of your Flash plugin here at the official Adobe page. A downloadable standalone update (APSB15-03) suitable for enterprise patch management systems is expected next week. If you decide not to update manually take appropriate care when using Flash
Update: Adobe published advisory APSA15-01 acknowledging that a separate 0-day vulnerability exists (CVE-2015-0311) and indicates that it will be addressed next week with another update. @Kafeine updated his blog: The exploit now works against Windows 8.1 as well, so only Chrome continues to be excluded from the attack. EMET detects the attack and shuts down Internet Explorer. Please note that this represents only a quick test on limited configurations on his part. TrendMicro has some telemetry in their blog post that looks at a different Angler site than @Kafeine’s post. Their analysis also points out that this exploit does use some of the tell-tale windows API calls that are often monitored by AV solutions such as CreateProcess and WriteFIle – instead it simply runs in memory, leaving persistence to a subsequently loaded malware.
Update: Adobe released APSB15-02 to address the vulnerability CVE-2015-0310. Adobe credits Yang Dingning, Timo Hirvonen and @Kafeine. Apply as quick as possible. Microsoft has updated advisory KB2755801 to show that Internet Explorer uses will get the new version automatically. In addition there seems to be some evidence that another exploit for a yet undisclosed vulnerability in Flash (even the latest version 220.127.116.117) is out in the wild. ZScaler’s research team blogs that this 0-day is also in use within the Angler Exploit Kit. Stay tuned for further updates.
Original: Security researcher Kafeine (https://twitter.com/kafeine) has apparently found a new exploit against the latest Adobe Flash (APSB15-01). The exploit is part of the Angler Exploit Kit and could have quite widespread impact. In his testing the following systems were exploited successfully:
Windows XP, IE8, latest Flash 18.104.22.1687
Windows 7, IE9, latest Flash 22.214.171.1247
Windows 8, IE10, latest Flash 126.96.36.1997
The exploit does not seem to work against Flash in Google Chrome or against Windows 8.1.
At the moment there is not much you can do about the threat, except reach out to your anti-malware provider to see if they block the exploit. Kafine mentions Malwarebytes Anti Exploit as preventing the exploit from running. Stay tuned for more updates.
Cross-Site Request Forgery (CSRF) is an attack that tricks the victim’s browser into executing malicious requests designed by the attacker. A successful CSRF attack can force the victim’s browser to perform state-changing requests like transferring funds or changing his email address. Clearly these are attacks that need to be prevented.
In case you have not yet patched your Java installation to the latest version, Java 7u21 from last Tuesday April 16, here are three reasons to do so rather quickly:
On April 17, POC code for one of the vulnerabilities(CVE-2012-2423) in 7u17 was published by Jeroen Frijters, who discovered the vulnerability originally and was credited by Oracle in their release announcement
On April 20, a Metasploit module was released that the POC code CVE-2012-2423 and allows penetration testers to attack Java 7u17 and to take control of the targeted machine
On April 21, F-secure published a blog post saying that they are detecting attacks in the wild against that same vulnerabilty using code that has some similar named code structures as the original POC code and the Metasploit module.
If you need Java, you should patch now. If this is not possible, disconnect Java from the browser as the attack code is using the browser attack vector.
This exploit is unrelated to a new vulnerability discovered in Java 7u21, the latest available version, that Adam Gowdiak from Security Exploration submitted to the Oracle Security Team on April 22. The information on the vulnerability is kept private and no known exploits are available.
The popular Ruby on Rails (Rails) web application framework has a vulnerability (CVE-2013-0156) in the parsing of XML parameters that allows an attacker to reach code execution on the webserver that runs the Ruby on Rails framework. Attackers are able to bypass authentication, inject and execute SQL or programming code, and can extract data and or gain control over the web application. All Rails applications in general are susceptible to the attack as XML parameter parsing is on by default. There is risk for the businesses running on Rails and more generically the potential for widespread, automated infections.
Exploits are publicly available and are already been integrated into vulnerability testing frameworks such as Metasploit. It underscores the fact that this vulnerability is easy to attack and should be treated as an high priority threat.
If an organization runs an application under the Rails framework, there are two primary risks:
data loss: the attacker can access and extract all data the application has access to, which can lead to privacy violations through the loss of customer data and revenue impacts through the loss of business data, intellectual property, etc
webserver control loss: the attacker takes administrative control of the webserver, which allows him/her to monitor ongoing transactions and harvest user credentials or use the machine in outbound attacks, for example see the recent attacks on US banking sites that had a strong server component (see here for a example in the NY Times)
Organizations should not only check on internal applications but also on third party applications that they run and see if they are developed in Rails and if a patch is available. Because Rails is such a popular framework it is quite possible that external applications (think SaaS as for example) are also impacted.
Organizations that have vulnerable installations have a number of choices. The primary option is to upgrade to the latest version of Rails 3.2.11 which addresses this vulnerability. However, there have been some reports of application problems (JSON arrays in particular) introduced by the new version, so one needs to make sure that all aspects of the application continue to function as expected. Application owners that cannot upgrade directly because they run on an older version of Rails (i.e. V2.3, v3.0, V3.1) can apply a patch that has been made available by the Rails team. If the application owner can neither upgrade or patch, the application itself can be hardened to prohibit XML parameters at all, or at least prohibit the parameter conversions that have caused the particular problem (YAML and Symbol), Instruction on how to configure the application are available in the Rails advisory for the vulnerability.
Even organizations that patch their infrastructure might evaluate to implement the hardening of the application in any case. Parsing of XML is notoriously difficult (see the recent MS12-002 for example) and if the application can safely function without that capability it is a good defensive measure to eliminate it.
Qualys detects the vulnerability as QID 12639 – Ruby on Rails Action Pack Multiple Vulnerabilities. We suggest that you scan your entire external perimeter and internal webservers to pinpoint your vulnerable assets.
In the October 2011 Patch Tuesday, Microsoft released update MS11-077 to fix a null pointer de-reference vulnerability (CVE-2011-1985). In this paper, we will reverse engineer the patch for MS11-077 (CVE-2011-1985) to get a better understanding of the vulnerability fixed by this patch.
Using binary diff, we can see the changes that were made to the vulnerable file win32k.sys. Figure 1 below shows the TurboDiff results.
Figure 1: TurboDiff Results
As you can see in Figure 1 above, while most of the functions are identical, there are a couple of functions that look ‘suspicious’ and some others that are ‘changed’. The large number of changes is not a surprise because Microsoft has fixed four different vulnerabilities with this patch.
Taking a closer look at all the functions that were changed, you will see that the changes made to functions ‘NtUserfnINLBOXSTRING’, ‘NtUserfnSENTDDEMSG’ and ‘NtUserfnINCBOXSTRING’ are all the same. Figure 2, below shows the changes made.
Figure 2: Binary Diff for function NtUserfnINLBOXSTRING(x,x,x,x,x).
Looking at the binary difference, it is clear that the patch is checking that the arg_0 (first argument passed to the function) is 0xFFFFFFFF and if it is 0xFFFFFFFF, call _UserSetLastError() with 0x578 and return from the function.
This gives us two pointers to exploit the vulnerability. The first is that the arg_0 has to be 0xFFFFFFFF. The second pointer is that the patched function bails out setting system error code to 0x578. This is the system error code for ERROR_INVALID_WINDOW_HANDLE, thus hinting us that the argument is of type HWND.
Everything until now is pretty simple and it looks easy to exploit this vulnerability. However, the really challenge here is finding a user mode function that will call the vulnerable function. It turns out this isn’t very straightforward, and we will need to understand the Windows GUI subsystem.
Win32 GDI Subsystem:
Figure 3: Win32 interfaces and their relation to the kernel components
The GDI (Graphics Device Interface) APIs are implemented in the GDI32.DLL and include all the low-level graphics services such as drawing lines, displaying BMPs etc. The GDI APIs make system calls into the WIN32k.sys to implement most APIs. The User APIs are implemented in USER32.DLL module and include all higher-level GUI-related services such as window management, menus, dialog boxes, user controls etc. USER heavily relies on GDI to do its work.
One of the most important means of communication in Windows is Messages. Windows-based applications are event-driven and act upon messages sent to them. The way you program in Windows is by responding to events. These events are called Messages. Messages can signal many events, caused by the user, the operating system, or another program. Each window, owned by a thread, has a window procedure (function) for processing input messages and dispatching them to the operating system. If a thread accesses any of the user interface or GDI system calls (handled by win32k.sys), the kernel creates a THREADINFO structure which holds three message queues used to process input. These are the input queue, the post queue, and the send queue. The input queue is primarily used for mouse and keyboard messages, while the send and post queues are used for synchronous (send) and asynchronous (post) window messages respectively.
Asynchronous messages are used in one-way communication between window threads and are typically used to notify a window to perform a specific task. Asynchronous messages are handled by the PostMessage APIs and are sent to the post queue of the receiving thread. The sender does not wait for the processing to complete in the receiving thread and thus returns immediately.
Synchronous messages differ from asynchronous messages as the sender typically waits for a response to be provided or a timeout to occur before continuing execution. Thus, they require mechanisms to ensure that the threads are properly synchronized and in the expected state. Synchronous messages use the SendMessage APIs which in turn directs execution to the NtUserMessageCall system call in win32k.sys.
This information is enough for us to take our analysis further.
Hitting the vulnerable function:
As described above, the message mechanism plays an integral role in the user interface component of the Windows operating system. There are many different types of message codes and those less than 0x400 are reserved by operating system. Depending upon the type of message code, NtUserMessageCall() calls a particular function to handle the message. Let’s take a closer look at how NtUserMessageCall, calls the appropriate functions to handle different message types.
Figure 4: Assembly code for NtUserMessageCall()
As seen in the above figure, the function first checks if the Msg code is less than 0x400(EAX has the Msg code) to check if it’s a system message code. Each Message code denotes an index in the win32k!MessageTable byte array. This byte value is than logically AND to 0x3F, since the last 6bits of the byte obtained from win32k!MessageTable determines the function that will handle the Message code. _gapfnMessageCall is a function table that stores address of all the functions that can handle different messages. See Figures below to see how _gapfnMessageCall table looks.
Figure 5: _gapfnMessageCall function table
Thus if we can get the index of our vulnerable function in _gapfnMessageCall, we can easily compute how we can call the vulnerable function. The index of our vulnerable functions are 29(0x1D), 27(0x27) and 43(0x2B) for NtUserfnINLBOXSTRING(),NtUserfnINCBOXSTRING() and NtUserfnSENTDDEMSG() respectively.
Following is the pseudo code to compute Msg codes for hitting the vulnerable function:
for i in range[0x00 to 0x400] if MessageTable[i] & 0x3F == 0x1D //NtUserfnINLBOXSTRING() Hit! if MessageTable[i] & 0x3F == 0x1B //NtUserfnINCBOXSTRING() Hit! if MessageTable[i] & 0x3F == 0x2B //NtUserfnSENTDDEMSG() Hit!
Proof of Concept:
Other Possible Msg codes for hitting vulnerable functions are: