Wednesday, January 27, 2016

Bypassing MiniUPnP Stack Smashing Protection

This post was authored by Aleksandar Nikolic, Warren Mercer, and Jaeson Schultz


MiniUPnP is commonly used to allow two devices which are behind NAT firewalls to communicate with each other by opening connections in each of the firewalls, commonly known as “hole punching”. Various software implementations of this technique enable various peer-to-peer software applications, such as Tor and cryptocurrency miners and wallets, to operate on the network.

In 2015 Talos identified and reported a buffer overflow vulnerability in client side code of the popular MiniUPnP library. The vulnerability was promptly fixed by the vendor and was assigned TALOS-CAN-0035 as well as CVE 2015-6031. Martin Zeiser and Aleksandar Nikolic subsequently gave a talk at PacSec 2015 ("Universal Pwn n Play") about the client side attack surface of UPnP and this vulnerability was part of it.

Talos has developed a working exploit against Bitcoin-qt wallet which utilizes this library. The exploit developed by Talos includes a Stack Smashing Protection (SSP) bypass, the details of which we will discuss here.

The Vulnerability 

The vulnerability lies in the XML parser code of the MiniUPnP library in the IGDstartelt function:
Vulnerable XML parser code of the MiniUPnP library
IGDdatas struct definition

Thursday, January 14, 2016

Research Spotlight: Needles in a Haystack

This post was authored by Mariano Graziano.

Malware sandboxes are automated dynamic analysis systems that execute programs in a controlled environment. Within the large volumes of samples submitted daily to these services, some submissions appear to be different from others and show interesting characteristics. At USENIX Security 2015 I presented a paper in which we proposed a method to automatically discover malware developments from samples submitted to online dynamic analysis systems. The research was conducted by dissecting the Anubis sandbox dataset which consisted of over 30M samples collected in six years. The methodology we proposed was effective and we were able to detect many interesting cases in which the malware authors directly interacted with the sandbox during the development phase of the threats.

Another interesting result that came from the research concerns the samples attributed to Advanced Persistent Threat (APT) campaigns. Surprisingly, some of the malware samples used in these sophisticated attacks had been submitted to the Anubis sandbox months -- sometimes even years -- before the attack had been attributed to the proper APT campaign by a security vendor. To be perfectly clear, we are not saying that it took security vendors months or years to detect a threat. Most times, we are able to detect the  threats in no more than a few hours. It is just that the malware samples were mislabeled and not properly associated with APT campaigns. In general, the same goes for non-APT malware campaigns. In this blog post, we tried to see if the same applied to the Cisco dataset. Specifically, we chose ten APT campaigns, -- some of which were already covered in the Usenix paper. We decided to inspect two different datasets: our incoming sample feeds / malware zoo, and the telemetry associated with our Advanced Malware Protection (AMP) solutions. Talos receives samples from over 100 external feeds ranging from anti-malware companies to research centers, while the AMP dataset contains telemetry from the Cisco AMP user-base. 

The remaining part of this post is organized as follows. First, we show the APT campaigns we investigated. Second, we summarize the results of the analysis of the Talos dataset. Third, we show the results from the AMP dataset.  Finally, we summarize our findings.

Tuesday, January 12, 2016

Microsoft Patch Tuesday - January 2016

The first Patch Tuesday of 2016 has arrived. Today, Microsoft has released their monthly set of security bulletins designed to address security vulnerabilities within their products. This month’s release is relatively light with nine bulletins addressing 25 vulnerabilities. Six bulletins are rated critical and address vulnerabilities in Edge, Internet Explorer, JScript/VBScript, Office, Silverlight, and Windows. The remaining three bulletins are rated important and address vulnerabilities in Exchange and several parts of Windows.

Bulletins Rated Critical

Microsoft bulletins MS16-001 through MS16-0006 are rated as critical in this month's release.

MS16-001 and MS16-002 are this month's Internet Explorer and Edge security bulletin respectively. In total, four vulnerabilities were addressed and unlike in previous bulletins there are no vulnerabilities that IE and Edge have in common.
  • MS16-001 is the IE bulletin for IE versions 7 through 11. Two vulnerabilities are addressed with those being CVE-2016-0002, a use-after-free flaw and CVE-2016-0005, a privilege escalation flaw. Note that CVE-2016-0002 is a VBScript engine vulnerability that is addressed in this bulletin for systems with IE 8 through 11 installed. Those who use IE7 and earlier or who do not have IE install will need to install MS16-003 to patch this vulnerability.
  • MS16-002 is the Edge bulletin addressing two vulnerabilities as well. Both CVE-2016-0003 and CVE-2016-0024 are memory corruption vulnerabilities that could result remote code execution if exploited.
One special note regarding this month's IE advisory: In August 2014, Microsoft announced the end-of-life for Internet Explorer versions older than IE 11 that would take effect today. As a result, this month's bulletin will be the final one for affected versions. After today, "only the most recent version of Internet Explorer available for a supported operating system will receive technical support and security updates." As such, there are exceptions to the end-of-life announcement with those being Windows Vista SP2 (IE9), Windows Server 2008 SP2 (IE9), and Windows Server 2012(IE 10). For more information on the IE end-of-life, please refer to Microsoft's documentation here:

Thursday, January 7, 2016

Rigging compromise - RIG Exploit Kit

This post was authored by Nick Biasini with contributions by Joel Esler.

Exploit Kits are one of the biggest threats that affects users, both inside and outside the enterprise, as it indiscriminately compromises simply by visiting a web site, delivering a malicious payload. One of the challenges with exploit kits is at any given time there are numerous kits active on the Internet. RIG is one of these exploit kits that is always around delivering malicious payloads to unsuspecting users. RIG first appeared in our telemetry back in November of 2013, back then we referred to it as Goon, today it's known as RIG.

We started focusing on RIG and found some interesting data similar to what we found while analyzing Angler. This post will discuss RIG, findings in the data, and what actions were taken as a result.

The Exploit Kit Overview

RIG compromises users like any exploit kit. It starts with a user being redirected to a landing page. This is done via malicious iframes or malvertising and looks similar the following:

It begins with an initial link to a javascript: