Wrap-up: Hack-Lab 2017#1

What is a Hack-Lab?

Compass Security provides a monthly playful occasion for the security analysts to get-together and try to hack new devices, dive into current technologies and share their skills with their fellows.

This also includes the improvement of internal tools, the research of newly identified publicly known attacks, and security analysis of hardware and software we consider useful for our future engagements.



The following topics, tools and technology has been discussed during this Hack-Lab:

  1. SharePoint Security
  2. Bypassing Android 7.0 HTTPS Apps Certificates Restriction
  3. JWT4B
  4. CodeInspect
  5. Smart Meter
  6. DNS Tunnel Debugging


Topic #1 – SharePoint Security Lab and Knowledge Sharing

SharePoint is a very popular browser-based collaboration and content management platform. Due to its high complexity, proprietary technology and confusing terminology it is often perceived as a black-box that IT and security professionals do not feel very comfortable with.

In a combination of talks and hands-on workshop sessions, Thomas Röthlisberger shared his research work with colleagues. They challenged his findings and shared their thoughts on pros & cons of security relevant settings. The outcome of this Hack-Lab session will be shared in a series of blog posts within the next couple of weeks.

The research in our very own hands-on SharePoint lab allows us to gain an in-depth understanding of any type of SharePoint environment, be it a purely internal collaboration web application, a platform to share information with external partners or a publishing site hosting the company website. To build or assess a secure SharePoint environment one needs to understand the importance of governance, logical and physical architecture, network topology, active directory considerations, authentication and authorization, segregation of classified data, hardening and most importantly web security relevant settings to make sure the built-in protection measures are effective. Like other modern Microsoft products, an out-of-the-box SharePoint installation can be considered secure. However, there are so many weirdly named settings which heavily depend on each other that misconfiguration is likely to happen, leaving the door wide open for unauthorized access by adversaries with SharePoint skills.


  • SharePoint Server 2010 & 2013
  • Web Applications, Site Collections, (Sub-)Sites, (Custom) Lists, Document Libraries, Web Part Pages, Web Parts, Apps
  • Web Security, Cross-site Scripting (XSS), Cross-site Request Forgery (CSRF)
  • Navigation Links
  • Web Sensitive Files, permission to Add & Customize Pages and Scriptable Web Parts, e.g. Content Editor and Script Editor (“SafeAgainstScript=False”)
  • Browser File Handling
  • Web Page Security Validation (aka Anti-CSRF token)
  • Lockdown Mode Feature
  • Remote Interfaces SOAP, CSOM, WCF Service, REST Interface
  • Server-Side Controls
  • .NET Sandboxing, Sandboxed Solutions and Apps
  • Self-Service Site Creation
  • Developer Dashboard
  • Audit Logs
  • People Picker

Topic #2 – Bypassing Android 7.0 HTTPS Apps Certificates Restriction

With Android 7.0, apps do not trust user imported certificates anymore.  Intercepting app network traffic with a proxy has become more complicated.

The goal is to find or create a custom application which is explicitly developed for Android 7.0. Then to configure the app with the network_security_config.xml file, which is used to bypass this restriction,  and therefore enables user defined certificates.


  • Android Studio
  • Android 7.0
  • Apktool

Topic #3 – JWT4B

Create a Burp plugin which helps the analyst when testing an app that uses JSON Web Tokens (JWT.IO).

Frist step is to create a prototype which enables Burp to visualize the tokens. On further hacklabs it should be possible to automatically perform JWT attacks.


  • Java
  • JJWT (library)
  • JWT

Topic #4 – CodeInspect

Evaluation of CodeInspect’s features.

Determine if CodeInspect could be used to make future  Android app analysis assessments more efficient.


  • Java
  • Android

Topic #5 – Smart Meter


An Energy Monitoring System was provided for testing. It is used to measure the current consumption and provides various interfaces. Web browser (TCP/IP) and Modbus are the main ones.

Assess the security of the interfaces. What can an attacker exploit if given network access to the device?


  • TCP/IP
  • Modbus
  • HTTP Web Application

Topic #6 – DNS Tunnel Debugging

Compass Security has its own trojan toolkit which we use for responsible phishing attacks in mandate for our customers, and also demos and proof of concepts. The trojan also implements DNS tunneling.

Analyze the source code and perform debugging to identify and fix some reliability issues while performing DNS tunneling with multiple clients.


  • C++

Security Advisories for SAP BusinessObjects Explorer and neuroML

Compass Security employees identify and report on a regular basis security vulnerabilities as part of their daily assessments (or just out curiosity).

Stefan Horlacher identified and reported back in June 2013 several flaws in SAP BusinessObjects Explorer. We’re happy to publish today the details as the flaws have been patched and a reasonable grace period given for their deployment:

Note that both the port scan as well as the XML External Entity (XXE) attack can be conducted anonymously without prior insider knowledge.

Philipp Promeuschel on his part identified multiple vulnerabilities in neuroML version 1.8.1 in May this year. The related advisory covers a wide range of vulnerabilities allowing a full compromise of the application:

XSS – The never ending story

Cross-Site Scripting (XSS) has lost one rank in the newly released OWASP Top Ten 2013 candidate. Compared to the 2010 version, it’s now on rank three, overtaken by “Broken Authentication and Session Management”. Has XSS become less common then? No, I don’t think so.

Compass Security has always been strong in web application security testing and not surprisingly, has a huge experience in identifying all kinds of web app related weaknesses, including Cross-Site Scripting. To wrap up quickly, here’s OWASP’s pretty decent definition:

“XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.”

Just in the last two months, I’ve been releasing three advisories, all related to XSS:

So why is XSS still so wide-spread? Here’s my personal top three:

  1. Developers tend to care more about features than security. This might be driven by marketing or sales, time constraints or other well-founded reasons – but at the end, it doesn’t matter. Sloppy coding, not being well trained and cheap outsourcing complete this picture.
  2. People suffer from the NIH syndrome (Not-Invented-Here). Instead of building their product on a well-tested code base, e.g. some common framework, they re-invent software in an insecure matter, also due to point 1.
  3. People underestimate the effort of maintaining software, which is always dynamic per se. This often leads to unpatched Content-Management-Systems being used in the wild: set up once, forgotten forever.

So, what’s the solution?

Software development should always be embedded in a Secure Development Lifecycle, in order to ensure its quality in development, improvements and operation. Besides, professional software companies and communities need to treat security incidents seriously. A positive example of the three above has been the Drupal community, which has shown it’s a professional approach from day one I contacted them.

Cross-Site Scripting is so easy to fix but so powerful to exploit. However, XSS is either not treated as a concrete threat or its impact is underestimated. We can just hope that someday all web developers understand its impacts and care more about their software – and customers.

Meanwhile, we’ll stay calm and continue testing …

Risks of DOM Based XSS due to “unsafe” JavaScript functions


Several native JavaScript functions or properties like .eval() and .innerHTML as well as several jQuery functions like .html() and .append() are considered as “unsafe”, but why? The reason is that they allow DOM manipulation using strings containing HTML code (e.g.”<b>This text is bold</b>“), which can lead to DOM Based Cross-Site Scripting vulnerabilities. To be more specific: The usage of such functions is not a problem as long as no user input is directly embedded in an “unsafe” way. jQuery can help us to safely manipulate the DOM without executing XSS in user defined inputs. But do not by mistake assume jQuery is safe per se, it only provides us some helper function to manipulate the DOM more safely.

The subsequent sections show the difference between safe and unsafe usage of JavaScript and jQuery functions in the following scenarios:

Unsafe DOM manipulation using eval():

var txtField = "field1";
var txtUserInput = "'test@csnc.ch';alert(1);";
   "document.forms[0]." + txtField + ".value =" + txtUserInput

The last double quote causes the user input to be treated as JavaScript. This results in the following JavaScript code being executed by eval():

document.forms[0].field1.value = 'test@csnc.ch';alert(1);

Therefore the user input is executed:

Safe DOM manipulation using eval():

var txtField = "field1";
var txtUserInput = "'test@csnc.ch';alert(1);";
   "document.forms[0]." + txtField + ".value = txtUserInput"

The double quote at the end causes the user input NOT to be treated as JavaScript. This results in the following JavaScript code being executed by eval():

document.forms[0].field1.value = txtUserInput

Or in other words:

document.forms[0].field1.value = "'test@csnc.ch';alert(1);"

This results in the following HTML code:

<input type='text' id='field1' name='field1'
       value="'test@csnc.ch';alert(1);" />

Therefore the user input is not executed:

However, this snippet shows again how small the difference is between safe and unsafe usage of eval():

"document.forms[0]." + txtField + ".value =" + txtUserInput
"document.forms[0]." + txtField + ".value = txtUserInput"

Therefore it is recommended to completely ban this function from your JavaScript code.

Unsafe DOM manipulation using jQuery html():

var txtAlertMsg = "This is bold: ";
var txtUserInput = "test<script>alert(1)<\/script>";
   txtAlertMsg +"<b>" + txtUserInput + "</b>"

Or in other words:

   "This is bold: <b>test<script>alert(1)<\/script></b>"

This results in the following HTML code:

<div id='message'><b>test<script>alert(1)</script></b></div>

Therefore the user input is executed:

Safe DOM manipulation using jQuery html() and text():

var txtAlertMsg = "This is bold: ";
var txtUserInput = "test<script>alert(1)<\/script>";
   txtAlertMsg +"<b><div id='userInput'></div></b>"

Or in other words:


This results in the following HTML code:

<div id='message'>This is bold: <b>
   <div id='userInput'>test&lt;script&gt;alert(1)&lt;/script&gt;</div>

Therefore the user input is not executed:


  • eval() is evil
  • jQuery does not solve all your problems
  • When using JavaScript or jQuery functions to manipulate your DOM you always need to know if your content may contain user input. If yes you must only use functions which encode HTML / JavaScript strings like jQuery text().


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 https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project
    [2] Samy is my hero http://en.wikipedia.org/wiki/Samy_(computer_worm)
    [3] Cross-site Scripting (and XSS Shell) http://www.csnc.ch/misc/files/publications/compass_event08_xssshell_krm_v1.0.pdf
    [4] antisamy-slashdot.xml example http://owaspantisamy.googlecode.com/files/antisamy-slashdot-1.4.4.xml
    [5] XML External Entity Attacks http://www.csnc.ch/misc/files/publications/2010_w-jax_xml_theory_and_attacks_XXE.pdf
    [6] AntiSamy Developer Guide http://owaspantisamy.googlecode.com/files/Developer%20Guide.pdf

    nevisProxy Advisory Release

    Today, Compass Security published a public advisory regarding nevisProxy, a product from AdNovum, used by several Swiss financial institutions.

    nevisProxy is a secure reverse proxy with an integrated web application firewall (WAF). It acts as a central upstream entry point for web traffic to integrated online applications. nevisProxy controls user access and protects sensitive data, applications, services, and systems from internal and external threats. nevisProxy is a component of AdNovum’s security framework Nevis (source).

    Instead of focusing this post on the issue itself, I would like to take the opportunity to show how well the vendor AdNovum handled the vulnerability we identified. In less than a few hours after the disclosure, our initial mail was acknowledged and their team was already working towards a resolution. On the following morning, the vendor informed all its customers by releasing a security bulletin and a blog entry (AdNovum Security Bulletin 2012-03 – only accessible via their customer portal), containing a mitigation proposal. A concrete date for a patch release (March 14, 2012) was communicated at this occasion as well. Only two working days later, AdNovum has sent an email reminder about this issue, ensuring all customers were aware of the issue and could take adequate steps to safeguard themselves.

    We often hear and read rants about vendors giving bad examples on how to (not) handle security issues. Hopefully this example of AdNovum will show that some vendors know how to manage security issues quickly and professionally, in the best interest of their customers – and their own reputation.

    Our advisory can be found on http://www.csnc.ch/misc/files/advisories/CSNC-2012-004_Nevis_XSS_within_302_Redirections_publicVersion.txt

    New Security Enhancing HTTP Headers

    In the past few years, several new HTTP Headers have been proposed to increase the security of web applications. This is being done by providing additional instructions and information about the served application to the browser. Those can mitigate and avert various common web attacks, even if the underlying application contains vulnerabilities, therefore adding another layer of defense.
    As time passes, more and more people do use a browser which support those measures. Compass Security has long been testing for these security enhancing features, and is actively advocate their implementation. Therefore we release an presentation which we used to educate employees and customers alike about this topic.


    The presentation “New HTTP headers – and living in a POST-XSS world” aims to give quick overview, and answers to all of the questions below:
    • What are the new HTTP headers you can use to protect your web application?
    • Why should I force mode=block for the X-XSS-Protection header?
    • How tightly can I configure a X-Content-Security-Policy?
    • What is the purpose of the Strict-Transport-Security header?
    • How does Stefano Di Paola’s Firefox SeecurityHeaders extension look like?
    • Let’s dream of a world where browsers are smart enough to prevent execution of arbitrary JavaScript code via XSS – what options would be left?