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.

   

Topics

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

Wrap-Up

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.

TECHNOLOGY:

  • 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.

Technology:

  • 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.

Technology:

  • 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.

Technology:

  • Java
  • Android

Topic #5 – Smart Meter

Description:

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?

Technology:

  • 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.

Technology:

  • C++

Subresource Integrity HTML Attribute

Websites nowadays are mostly built with different resources from other origins. For example, many sites include scripts or stylesheets like jQuery or Bootstrap from a Content Delivery Network (CDN). This induces that the webmasters implicitly trust the linked external sources. But what if an attacker can force the user to load the content from an attacker controlled server instead of the genuine resource (e.g. by DNS poisoning, or by replacing files on a CDN)? A security-aware webmaster had no chance to protect his website against such an incident.

This is the point where Subresource Integrity kicks in. Subresource Integrity ensures the integrity of external resources with an additional attribute for the two HTML tags <link> and <script>. The integrity attribute contains a cryptographic hash of the external resource which should be integrated in the site. The browser then checks if the hash of the fetched resource and the hash in the HTML attribute are identical.

Bootstrap example:

<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/css/bootstrap.min.css" integrity="sha384-1q8mTJOASx8j1Au+a5WDVnPi2lkFfwwEAa8hDDdjZlpLegxhjVME1fgjWPGmkzs8" crossorigin="anonymous">

In the example above, resource bootstrap.min.css is checked for its integrity with its Base64 encoded SHA-384 hash. If the integrity check is positive, the browser applies the stylesheet (or executes the script in the case of a <script> tag). If the check fails, the browser must refuse to apply the stylesheet or execute the script. The user is not informed if the check has failed and a resource therefore could not be loaded. The failed request can only be seen in the developer tools of the used browser. The following image shows the error message in the Chrome developer tools.

Console in browser does inform about subresource integrity check fail.

Console in browser does inform about subresource integrity check fail.

The crossorigin attribute in the example configures the CORS request. A value anonymous indicates, that requests for this element will not have set the credentials flag and therefore no cookies would be sent. A value of use-credentials would indicate, that the request will provide cookies to authenticate.

The subresource integrity attribute is currently being reviewed before becoming a W3C standard but is already supported by Chrome 45≤ , Firefox 43≤ and Opera 32≤.

Concluding, the subresource integrity attribute offers better possibilities for webmasters to ensure the integrity of external resources. However, this attribute is not supported by older browsers and needs to be adjusted at every resource change. In the end, a security aware webmaster will keep more control with less effort by keeping all resources hosted on his own servers.

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

Introduction

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);";
eval(
   "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);";
eval(
   "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>";
$("#message").html(
   txtAlertMsg +"<b>" + txtUserInput + "</b>"
);

Or in other words:

$("#message").html(
   "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>";
$("#message").html(
   txtAlertMsg +"<b><div id='userInput'></div></b>"
);
$("#userInput").text(
   txtUserInput
);

Or in other words:

$("#userInput").text(
   "test<script>alert(1)<\/script>"
);

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>
</b></div>

Therefore the user input is not executed:

Conclusion

  • 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().

Resources