Aftermath of the Netgear Advisory Disclosure

Update – 13.10.2015: Netgear published a new firmware (version which fixes the reported authentication bypass.

My most recently appointed colleague, Daniel Haake, described in the previous blog article “Authentication Bypass in Netgear WNR1000v4 Router” how he found an authentication bypass in commonly used Netgear firmwares. Due to the rediscovery of the issue and its public disclosure, we decided to go public despite the fact Netgear did not yet release a fix for the identified security hole.

Shortly after the release of the Compass advisory on public mailing list Bugtraq, we were contacted by Joe Giron, who experienced troubles with his Internet connection around September 27th. On September 28th, Joe noticed that his Netgear router’s primary DNS server had been set to point to a non-standard DNS server. This timeframe means that attackers were active before the release of Shellshock Lab’s blog article (which is detailing the same vulnerability). Joe mentioned that the remote administration interface of his Netgear router was accessible via the Internet, but protected by a strong password. He therefore had high suspicions that he fell victim of an attack against an unpatched vulnerability in his router. The release of our advisory was the confirmation and technical explanation of it.

The IP of the rogue DNS server set in his router did not only expose a DNS service, but also a web server. This web server served various PHP scripts, log files and text files. The logs contained over 17’000 entries of presumably hacked routers, including their IP address, username and password of their administration interfaces. A further analysis of this list would identify more than 11’000 unique routers.


As we discovered that this authentication bypass was being exploited in the wild and that over 10’000 users were affected, we contacted Switzerland’s CERT for further help. GovCERT was very helpful and took over the case by

  • Attempting to contact Netgear again to urge them to release the patch
  • Analyzing the logs of the web server and identifying the victims
  • Taking down the command and control server to avoid further infections
  • Liaising with GovCERT’s partners worldwide to notify the Internet service providers of the victims

In the meantime, the media got interested in the advisory and Threatpost published yesterday evening an article about the flaw and its follow-up. A second person reached out to us after the publication of this article, describing the same infection vector as well as the same IP address for the DNS and C&C server. We are currently in contact with other media outlets and will update this section when further articles are released.

The debate between responsible- and full disclosure is endless and both approaches have their pro- and cons. At Compass Security, we attempt to get the best balance between these two approaches. We are confident that our approach of leaving some time for the vendor to patch the vulnerability before publicly disclosing the issue in case of no adequate response was the best. Public information has proven to work and helped identifying ongoing attacks. Coordination with the relevant authorities allowed coordinated action against the attackers and will hopefully help the victims of this hack.

Media Update, 11.10.2015:

Media Update, 12.10.2015:

Microsoft Security Bulletin MS13-067 – Critical

As part of today’s monthly patch day, Microsoft fixed an issue I reported in September 2012 around (ASP).NET and SharePoint.

The vulnerability opens a new type of attack surface on ASP.NET if a given precondition regarding the Viewstate field is met. The impact is at least a breach of data integrity on the server side resulting typically in a denial of service. Leveraging the flaw to achieve remote code execution cannot be excluded though. The default configuration settings of ASP.NET are safe and do not allow an exploitation of the flaw.

But before uncovering more technical details about the issue, we want to ensure everyone had enough time to patch their servers adequately. For this reason, we will withhold further details during a grace period agreed with Microsoft’s Security Response Center to ensure all involved parties have enough time to react. In the meantime, we encourage you to patch the relevant servers and ensure your web applications at least enforce the default protection of the Viewstate field.

Secure XML Parser Configuration

Most XML parsers are vulnerable for XML external entitiy attacks (XXE) by default. So what’s your mitigation?

The easiest way to prevent XXE is to disallow the Doctype declaration completely:

import org.jdom.Document;
import org.jdom.JDOMException;
import org.jdom.input.SAXBuilder;

public class XEE_Disallow_Doctype_Decl {
	public static void main(String[] args) {
		String element= null;
		SAXBuilder objBuilder = null;
		Document objDocXML = null;
			objBuilder = new SAXBuilder("org.apache.xerces.parsers.SAXParser");
			objBuilder.setFeature("", true);
			objDocXML = File("data\\test.xml"));
			element= objDocXML.getRootElement().getChild("TestElement").getText();
			System.out.println("Element: " + element);
		} catch(Exception e) {

If this is not possible, because the Doctype declaration is required in your application, you can disallow external entities:

import javax.xml.parsers.SAXParser;
import javax.xml.parsers.SAXParserFactory;

public class XEE_Disallow_External_Entities {

	public static void main(String[] args) {
		String xmlFile = "data\\test.xml";
		MyHandler handler = new MyHandler();
		try {
			SAXParserFactory factory = SAXParserFactory.newInstance();
			factory.setFeature("", false);
			factory.setFeature("", false);
			SAXParser parser = factory.newSAXParser();
			parser.parse(xmlFile, handler);
		} catch (Exception e) {

To ensure if your configuration is secure, you should always verify the parser manually!

Want to learn more about XML external entity attacks and application security? Join our web application security trainings in Rapperswil/Jona next week:


AntiSamy to face XSS and XXE

The community hosts a neat little project called AntiSamy[1] which lends its name from the well known MySpace worm[2] and which comes in handy when trying to mitigate Cross-site Scripting[3] attacks. Whereby XSS is sometimes hard to mitigate when business is asking for HTML formatting in user supplied inputs. At that point, AntiSamy might become handy since it focuses to strip down user supplied input to a predefined set of allowed formatting (HTML tags and attributes).

The basic steps when working with AntiSamy are

  • Define a policy file (XML)
  • Sanitize user input according to policy 

The Java API code is pretty straight forward. Note, AntiSamy is to some extent also available for .NET

    AntiSamy a = new AntiSamy();
    CleanResults r = a.scan(userInput, policyPath);

    Thus, it all boils down to configure a strict policy. Samples are shipped with the AntiSamy framework. The file I copied snippets from is named antisamy-slashdot.xml[4] . AntiSamy policy files consist of the following major sections:


    A) Directives

    Directives describe the fundamental behavior of the framework and may also help to prevent XML External Entity Attacks XXE[5] with XML message based services. 

    <directive name="omitXmlDeclaration" value="true"/>
    <directive name="omitDoctypeDeclaration" value="true"/>
    <directive name="maxInputSize" value="5000"/>
    <directive name="useXHTML" value="true"/>
    <directive name="formatOutput" value="true"/>
    <directive name="embedStyleSheets" value="false"/>

    Hint: AntiSamy would prevent XXE when configuring omitDoctypeDeclaration ‘true’. However, I do not consider AntiSamy an appropriate variant to filter doctype declarations in a large-scale XML service environments. An application level firewall would probably better fit enterprise grade infrastructure needs. Note, the full list of directives is documented in the AntiSamy developer guide[6] and the source code.


    B) Common Regular Expressions

    This section lists expressions that describe contents of tags and attributes. It basically serves as a variable declaration.

    <regexp name="htmlTitle" value="[\p{L}\p{N}\s-',:[]!./\()&amp;]*"/>
    <regexp name="onsiteURL" value="([\p{L}\p{N}\/.\?=#&amp;;-~]+|#(\w)+)"/>
    <regexp name="offsiteURL" value="(\s)((ht|f)tp(s?)://|mailto:)[\p{L}\p{N}]+[~\p{L}\p{N}\p{Zs}-_.@#\$%&amp;;:,\?=/+!()](\s)*"/>

    Confused? It is indeed pretty difficult to write properly matching expressions. Take care not to weaken your policy in a way that would allow an adversary to pass malicious inputs. You have been warned.


    D) Attribute definitions

    These definitions declare potentially allowed HTML attributes and also define what values an attribute might take. Note, the value could also be any of the named regular expressions above. Note, by listing an attribute within this section does not automatically allow that attribute to be used in user input. See tags and global attributes section instead.

    <attribute name="align" description="...">
    		<literal value="center"/>
    		<literal value="left"/>
    		<literal value="right"/>
    		<literal value="justify"/>
    		<literal value="char"/>


    E) Tag rules

    The section specifies HTML tags and explicit actions to be taken by the framework when approaching a tag. A tag definition may also reference attributes declared in the attributes section. Tags that should be allowed in user input must be flagged with action=”validate”. Unspecified tags will be deleted whereby the tag itself is removed and the content between the opening and closing tag will remain. This action can be explicitly specified as ‘filter’. The truncate action will keep the tag but remove all attributes from the tag.

    <tag name="script" action="remove"/>
    <tag name="iframe" action="remove"/>
    <tag name="style" action="remove"/>
    <tag name="p" action="validate">
    	<attribute name="align"/>
    <tag name="br" action="truncate"/>


    F) Tags to encode

    The section lists tags that will not be removed by default but its contents are being HTML encoded.



    G) Global attributes

    Lists attributes that are globally valid for all tags without explicit declaration within the tags section.

    	<attribute name="title"/>
    	<attribute name="lang"/>



    Getting a strict policy is not an easy task. However, the developers guide[6] and the project sample files give a quick start at the framework and also give advice and provide examples of how large platforms approach HTML formatting of user input.

    Got more appetite on application security? Join us for the upcoming web application security trainings (held in Jona in German language).



    [1] OWASP AntiSamy
    [2] Samy is my hero
    [3] Cross-site Scripting (and XSS Shell)
    [4] antisamy-slashdot.xml example
    [5] XML External Entity Attacks
    [6] AntiSamy Developer Guide