Monday, June 22, 2015

Bypassing Microsoft EMET 5.2 - a neverending story?

The experts of the SEC Consult Vulnerability Lab managed to adapt the EMET 5.0 / 5.1 bypasses to additionally work against the latest Microsoft EMET version which is 5.2. Results of the research were already presented this year at NorthSec 2015 in Montreal.

Since EMET 5.2 didn't fix any of the identified bypass techniques developed by the SEC Consult experts, migration of the bypasses was quite trivial.

With the introduction of EMET 5.1 Microsoft tried to break the "scan-down" approach (used to retrieve the image base of EMET.dll) by forcing a hole between the code section and the PE header. To circumvent this the new bypass techniques searched for the start of the code section instead of the PE header. This was done by using the hardcoded byte sequence from the start of the EMET 5.1 code section. Because the start of the code section changed with EMET 5.2, this pattern had to be updated to make the exploit work again. This was the only required modification to adapt the bypasses from EMET 5.1 to EMET 5.2.

The approach of hardcoding patterns from the code section is not recommended because it requires a modification of the exploit as soon as a new version of EMET gets released. Therefore SEC Consult later developed a more reliable technique to identify the start of the code section without using hardcoded patterns.

Tuesday, May 19, 2015

KCodes NetUSB: How a Small Taiwanese Software Company Can Impact the Security of Millions of Devices Worldwide

Today the SEC Consult Vulnerability Lab released an advisory regarding a vulnerability in a software component called NetUSB. This post intends to give some background information about this vulnerability.

NetUSB is a proprietary technology developed by the Taiwanese company KCodes, intended to provide “USB over IP” functionality. USB devices (e.g. printers, external hard drives, flash drives) plugged into a Linux-based embedded system (e.g. a router, an access point or a dedicated “USB over IP” box) are made available via the network using a Linux kernel driver that launches a server (TCP port 20005). The client side is implemented in software that is available for Windows and OS X. It connects to the server and simulates the devices that are plugged into the embedded system locally. The user experience is like that of a USB device physically plugged into a client system. It’s worth noting, that the NetUSB feature was enabled on all devices that we checked and the server was still running even when no USB devices were plugged in!

We initially found the NetUSB kernel driver on a TP-LINK device and decided to spend some time on it. To establish a server-connection, a simple mutual authentication check needs to be passed. The authentication is entirely useless as the AES keys are static and can be found in the kernel driver as well as in the client software for Windows and OS X. As part of the connection initiation, the client sends his computer name. This is where it gets interesting: The client can specify the length of the computer name. By specifying a name longer than 64 characters, the stack buffer overflows when the computer name is received from the socket. Easy as a pie, the ‘90s are calling and want their vulns back, stack buffer overflow. All the server code runs in kernel mode, so this is a “rare” remote kernel stack buffer overflow.

It turns out, that not only TP-LINK uses NetUSB in their products. We found references to 26 vendors in the file “NetUSB.inf”, which is part of the client driver setup for Windows. It is likely, that these vendors have licensed the NetUSB technology and are using it in some of their products. Our advisory contains a list of affected devices, where SEC Consult has verified the vulnerability within the firmware. Unless otherwise stated, the list is incomplete regarding other affected vendors.

To get an idea how many products are affected, we downloaded a bunch of firmware images from D-Link, NETGEAR, TP-LINK, Trendnet and ZyXEL (actually, we downloaded all of them). Then we checked if those firmware images contain the NetUSB kernel driver (NetUSB.ko). We found 92 products out of the analysed firmware images that contain the NetUSB code. A list of affected products can be found in our advisory. We did not check the firmware of the remaining 21 vendors. Many affected products are high-end devices and were released very recently (yes, even the ones that look like spaceships!).

Each vendor uses different terminology when referring to the NetUSB feature. NETGEAR calls it ReadySHARE, other vendors simply call it “print sharing” or “USB share port”. Here are a few examples:

Figure 1: TRENDNET NetUSB feature

Figure 2: TRENDNET NetUSB feature - "USB Share Port"

Figure 3: TP-LINK NetUSB feature


While NetUSB was not accessible from the internet on the devices we own, there is some indication that a few devices expose TCP port 20005 to the internet. We don’t know if this is due to user misconfiguration or the default setting within a specific device. Exposing NetUSB to the internet enables attackers to get access to USB devices of potential victims and this would actually count as another vulnerability.

We tried to get in contact with KCodes back in February 2015 and provided them with a detailed vulnerability analysis including proof of concept exploit code. They sent a few nonsensical responses and then further ignored us. Afterwards, we informed TP-LINK and NETGEAR directly about the vulnerability. The other vendors were informed by CERT/CC and other CERTs - thanks very much for the coordination!

To this day, only TP-LINK released fixes for the vulnerability and provided a release schedule for about 40 products. Sometimes NetUSB can be disabled via the web interface, but at least on NETGEAR devices this does not mitigate the vulnerability. NETGEAR told us, that there is no workaround available, the TCP port can't be firewalled nor is there a way to disable the service on their devices.

In the past, we’ve seen a few cases where vulnerabilities in code, which is shared by many embedded devices, have a huge security impact. Some of the vulnerabilities were based on protocol design issues (e.g. Wi-Fi Protected Setup, however, the (consumer) embedded systems industry is always keen on keeping development costs as low as possible and is therefore using vulnerability-ridden code provided by chipset manufacturers (e.g. Realtek CVE-2014-8361 - detailed summary by HP, Broadcom or outdated versions of included open-source software (e.g. libupnp, MiniUPnPd in their products.

Here we have another case that shows the sad state of embedded systems security. Because the same vendors are building the IoT devices of tomorrow, we will see a lot of this in the future.

Tuesday, November 18, 2014

Bypassing Microsoft EMET 5.1 - yet again

The experts of the SEC Consult Vulnerability Lab managed to adapt the EMET 5.0 bypasses to also work against the latest Microsoft EMET 5.1 and already presented the first analysis results at ZeroNights 2014 in Russia.

A first and quick analysis showed that the new release of EMET 5.1 only adds code to prevent a specific bypass method to disable all ROP protections. Because the exploit was developed by SEC Consult to be very flexible and configurable it's possible to change the exploit configuration to use other developed bypass methods or to bypass all protections separately. To ensure a maximum of reliability the default configuration is set to bypass all protections separately and therefore no changes were required to bypass the current EMET 5.1 protections.

In addition, EMET 5.1 introduced a technique which should break our method to identify the base address of EMET.dll. Our method works by following the hooking code of critical functions from EMET until a pointer to the .text section of EMET.dll is found. Then a scan-down approach is used where the page size is subtracted from the pointer until the PE header is found.

To fix this technique Microsoft forces a hole between the PE header and the .text section of EMET.dll. As soon as the scan-down code tries to access this hole a segmentation fault occurs because of accessing unmapped memory.

Bypassing this technique is quite easy, instead of searching for the PE header the start of the .text section can be retrieved. After that the page size must be subtracted twice (the hole has a fixed size of one page as well as the memory associated with the PE header) to reach the imagebase. It was possible to analyse this new protection and modify the code within just 40 minutes by adding 10 additional lines of code.

Further details will be presented at DeepSec 2014 in Vienna, Austria, on 20th November and at 31C3 in Hamburg, Germany, end of December!

Tuesday, October 28, 2014

Microsoft EMET - Armor against zero-days bypassed again | Conference Slides

New methods make it possible to circumvent protection mechanisms of Microsoft EMET 5.0

The EMET (Enhanced Mitigation Experience Toolkit) tool developed by Microsoft makes it possible for administrators and end users to retroactively equip applications with additional protection mechanisms. This enhanced protection is intended to prevent various attack techniques that are currently used by cyber attackers.

Security expert René Freingruber of the SEC Consult Vulnerability Lab has developed numerous methods to get around the basic protection mechanisms of EMET in all currently available versions. If a cyber-attacker were to use these new bypass methods, serious attacks could be carried out. A software product protected with EMET as a workaround affected by a critical zero-day vulnerability could, for example, fall under the control of attackers.

Microsoft was informed of this by SEC Consult and is working on an improvement to the protection methods.

The experts of the SEC Consult Vulnerability Lab advise you to not view EMET as an unbeatable protection measure, because the tool can definitely be bypassed with the help of newly discovered methods.

SEC Consult considers it as necessary for software manufacturers to make the development of applications more secure and to regularly test their software extensively for application security.

Demo video


Detailed slides from previous conferences, where the research has been presented by René Freingruber, are available here:

RuxCon, 11-12 October 2014

ToorCon, 25-26 October 2014

ZeroNights, 13-14 November, 2014

NorthSec 21-24 May, 2015

media ccc

Microsoft Blogpost

Thursday, June 26, 2014

Back To The Future: Unix Wildcards Gone Wild

On June, 25th 2014 DefenseCode released a whitepaper regarding a vulnerability
affecting all *nix derivatives:

Basically, this bug allows a user to affect shell commands issued by some other user
by creating files with special filenames. If the other user is a privileged user like
root this would theoretically lead to an elevation of privileges aka "local root" or
"local privilege elevation".

The paper contains some basic examples for different unix commands and their impact
if used in combination with wildcards.

At a first blush, the vulnerability does not seem to be very critical. It looks like
that it would only affect shell scripts badly coded and afterwards executed by some
higher privileged user.

But if you dig a little bit deeper and think about all the different *nix operating
systems, their boot- and shutdown-sequences and their local servers running with high
privileges, one will realize very fast, that this vulnerability has a huge security
impact on most unix like operating systems.

This bug affects Android, iOS, OS X and all the embedded solutions running on Linux.
In addition to this you have Oracle, RedHat and other commercial Linux based systems.

Many of these operating systems have different shell utilities and tools accepting
even more command line options.

A short check on Ubuntu gave us at least 5 commands, besides the ones mentioned in
the whitepaper, vulnerable to this specific problem.

In addition to this you have to imagine Cloud service- or web hosting providers
running cron jobs for backups and similar tasks of their users' data.

This bug has a very high potential when further analyzed.

Since this bug originates from a design problem it will be very interesting on how
operating system vendors address this problem. It is something you cannot fix with a
simple patch. The way on how the system interacts with files has to be completely

Credits for identifying those issues go to Leon Juranic <>

Wednesday, February 19, 2014

SECurity Message Service

Critical vulnerabilities completely compromise ‘Symantec Endpoint Protection’

The award-winning [1] and longtime leader of Gartner report league tables [2]; ‘Symantec Endpoint Protection’, developed by the US-based Symantec Corp. (Nasdaq: SYMC), was shipped without removing several critical security vulnerabilities [3]. The vulnerabilities were discovered in a routine ‘99er’ security crash test by experts of the SEC Consult Vulnerability Lab ( In a 99er security crash test, SEC Consult white-hat experts evaluate the product security for the maximum of 99 working hours to determine if this specific release of a product can be compromised by attackers.

The unremoved vulnerabilities enable state-sponsored or criminal hackers to take full control of the ‘Symantec Endpoint Protection Manager’ server. With the full control of the server the attackers could obliterate the endpoint protection provided by the Symantec solution as they would have full access to the protection features of the endpoints. SEC Consult experts recommend immediately installing the update released by the vendor to counter these vulnerabilities [4].

Since mid-2012 SEC Consult has identified several critical vulnerabilities in other Symantec products during routine security tests. A Support Backdoor was identified in Symantec Messaging Gateway [5] and for the Symantec Web Gateway [6]. The vulnerabilities found enabled attackers to run commands with the privileges of the ‘root’ operating system user and to perform surveillance activities.

SEC Consult strongly advises that customers of Symantec products should demand from the vendor exhaustive security tests by (European) security experts before the implementation of the respective software product.

SEC Consult generally recommends routine security crash tests for standard software products to prevent the procurement of ‘toxic’ (i.e. heavily insecure) software. Toxic Software contains severe security vulnerabilities and poses a severe and highly probable risk to the confidentiality, availability and integrity of its owner.

Further technical information can be found in the SEC Consult Security Advisory [3].

For further information please contact:
Johannes Greil
Head of SEC Consult Vulnerability Lab

Tuesday, September 17, 2013

Federal Office for Information Security (BSI) in Germany and SEC Consult give advice for the development and procurement of web applications

Federal Office for Information Security (BSI) in Germany and SEC Consult give advice for the development and procurement of web applications

Germany is known for its strict regulations regarding data protection and IT security especially in public sector. More and more sensitive data between citizens and public authorities is being transmitted over the internet and processed by web applications. Often this software is developed by third parties and contains severe security vulnerabilities.
The “Bundesamt für Sicherheit in der Informationstechnik” (abbr. BSI, engl. Federal Office for Information Security, is the national security agency in Germany with the goal to promote IT security. The BSI and SEC Consult have developed together new guidelines on how to securely develop software for German public authorities to ensure data protection and information security in general in software products. The guidelines have following aims:
  • Support for procurement of secure web applications for public authorities in Germany
  • Support for vendors and custom software providers to deliver secure web applications for public authorities in Germany
Despite the fact that the guidelines have been developed for German public authorities, they can be used for any other company or organization in and outside of Germany.
The guidelines consider different perspectives, but focus on the same goal – to improve the software security of web applications. 

  • The first guideline „Guideline for the development of secure web applications - recommendations and requirements for contractors“ (in German: „Leitfaden zur Entwicklung sicherer Webanwendungen - Empfehlungen und Anforderungen an die Auftragnehmer”)  gives advice for the software development process and the implementation for contractors developing software for the German government.
  • The second guideline „Guideline for the development of secure web applications - recommendations and requirements for contracting entities in government“ (in German: “Leitfaden zur Entwicklung sicherer Webanwendungen - Empfehlungen und Anforderungen an Auftraggeber aus der öffentlichen Verwaltung”) supports public authorities to check that the applications security requirements for secure web applications. 

The BSI guideline for the development and procurement of secure web applications can be downloaded free from the BSI website (only in German!):