Managing OpenSSH Patch Levels on Ubuntu


Vulnerability Remediation

Managing OpenSSH Patch Levels on Ubuntu

Many vulnerability scanners will raise false positives regarding outdated installations of OpenSSH on Ubuntu; notably issues similar to:

  • OpenSSH < 7.0 Multiple Vulnerabilities
  • OpenSSH < 6.6 Multiple Vulnerabilities

A thorough penetration test should weed out false positives of these issues, however they are a common occurrence in assessments relying on automated tools. In this example we will look at a fully patched Ubuntu 14.04 server with OpenSSH installed and show how to properly validate this issue. To start let’s grab the banner of the host in question:

$ nc 22
SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3

This banner reveals a number of configuration details about the server, but we’re only concerned right now with the very last flag on this example. The ‘2.3’ on the right is the internal Ubuntu patch level, which we can use to verify what vulnerabilities have been patched. First we should find out what the latest patch level is; to do this we can reference the following URL:


This will lead us to the following URL where we can look at the changelog:


Which then brings us to the changelog for the latest Ubuntu openssh-server patch:

openssh (1:6.6p1-2ubuntu2.3) trusty-security; urgency=medium

  * SECURITY REGRESSION: random auth failures because of uninitialized
    struct field (LP: #1485719)
    - debian/patches/CVE-2015-5600-2.patch:

 -- Marc Deslauriers   Mon, 17 Aug 2015 21:52:52 -0400

openssh (1:6.6p1-2ubuntu2.2) trusty-security; urgency=medium


  * SECURITY UPDATE: X connections access restriction bypass
    - debian/patches/CVE-2015-5352.patch: refuse ForwardX11Trusted=no
      connections attempted after ForwardX11Timeout expires in channels.c,
      channels.h, clientloop.c.
    - CVE-2015-5352

Here we have verification that the 2.3 patch includes an improved fix for vulnerability CVE-2015-5600 and that the 2.2 patch included updates for CVE-2015-5352 as well. This is a critical comparison that should be made to vulnerabilities raised by automated scanners. If no verification can be obtained from this method, the comparison should default to the OpenSSH version (6.6 in this case) and CVE details.

If the OpenSSH server is found to be out of date it can be easily upgraded with Ubuntu’s package management system.

$ sudo apt-get update
$ sudo apt-get upgrade

Understanding XSS Auditor



Understanding XSS Auditor

We see a lot of confusion regarding the X-XSS-Protection header and thought it might be worthwhile to go over exactly what this header is and what it isn’t.

What is XSS Auditor?

XSS Auditor is a built-in function of Chrome and Safari designed to mitigate Cross-site Scripting (XSS) attacks. It aims to identify if query parameters contain malicious JavaScript and block the response if it believes the payloads were injected into the server response. XSS Auditor is enabled by default, but can be configured or disabled with the X-XSS-Protection HTTP header. X-XSS-Protection is a non-standard header, meaning there is no official W3C or IETF specification. Despite this, the common configurations can be seen below.

Valid Configurations

  1. Disable XSS auditor
    X-XSS-Protection: 0
  2. Run in rewrite mode (default if header is not set).
    X-XSS-Protection: 1
  3. Run in “block” mode. Once the auditor is triggered the response is blocked and a blank page is shown to the user.
    X-XSS-Protection: 1; mode=block
  4. Run with reporting. This is a Chromium function utilizing CSP violation reports to send details to a URI of your choice.
    X-XSS-Protection: 1; report=

So what isn’t X-XSS-Protection?

XSS Auditor isn’t a solution to XSS attacks. As Justin Schuh of Google mentions, “XSS auditor is a defense-in-depth mechanism to protect our users against some common XSS vulnerabilities in web sites. We know for a fact it can’t catch all possible XSS variants, and those it does catch still need to be fixed on the affected site. So, the auditor is really an additional safety-net for our users, but not intended as a strong security mechanism.” Because of this, XSS Auditor bypasses are rated as ‘SecSeverity-None’ and, if you we’re wondering, are not eligible for bug bounty payments.

How does the XSS Auditor Work?

XSS Auditor takes a black list approach to identify dangerous characters and tags supplied in request parameters. It also attempts to match query parameters with content to identify injection points. If the query parameter can’t be matched to content in the response, the auditor will not be triggered. Because the browser will never have insight to server-side code, an application that mangles an XSS payload will always render the XSS auditor useless in preventing attacks.
To take a quick look at the code behind Chrome’s XSS auditor, we can get an idea of the inner workings of the detection mechanisms:


Just by looking through the function names we can see that the auditor searches for script tags, valid HTML attributes, and other XSS injection vectors. Before rendering the response in the Document Object Model presented to the user, XSS auditor searches for instances of (malicious) parameters sent in the original request. If a detection is positive, the auditor is triggered and the response is “rewritten” to a non-executable state in the browser DOM. Chrome’s ‘view-source’ has a builtin component to highlight sections on code in red that caused the XSS auditor to fire.


Bypassing XSS Auditor

A bypass of XSS auditor should not be considered a vulnerability. While the Chromium team does actively improve the auditor, there are likely to always be number of bypasses for the auditor. We will not go in depth about specific bypasses as they do change with time and are likely to be outdated fast. At the time of this writing two examples that are functional in the latest version of chrome can be found here and here.

How to Enable Network Level Access for Windows RDP


How to:

Enable Network Level Access for Windows RDP

Chances are you may have arrived here after a vulnerability scan returns a finding called “Terminal Services Doesn’t Use Network Level Authentication (NLA)”. The default configuration of Windows 7, 2008, and 2012 allows remote users to connect over the network and initiate a full RDP session without providing any credentials. This allows an untrusted user to land on the system login page as shown below:

Windows 2008 Login Screen

Several risks are associated with this functionality; an attacker is now able to:

  • Accurately fingerprint the version of Windows
  • Potentially identify user accounts on the system
  • Leverage the RDP service to consume excessive system resources

The default configuration of RDP is similar to letting anyone into the lobby of your building; while they may not have keys to apartments, we generally don’t want strangers milling around the lobby to gather information if it can be avoided.


To enable network level access on Windows 2008 R2 we can do the following:

  1. Open the Group Policy Editor by typing ‘gpedit’

    Group Policy Editor

  2. Navigate to the following:
    • Computer Configuration
    • – Administrative Templates
    • — Windows Components
    • — Remote Desktop Services
    • —- Remote Desktop Session Host
    • —– Security
  3. Doubleclick on “Require user authentication for remote connections by using Network Level Authentication”
  4. Check ‘Enabled’. Apply. Save.

NLA Enabled

Changes are immediate, no reboot is required. Network Level Access should now be enabled.


One of the quickest and easiest ways to verify if NLA is to use the ‘rdesktop’ tool packaged with Kali Linux. When NLA is properly enabled, you will get the following error:

root@kali:~# rdesktop 
Autoselected keyboard map en-us
ERROR: CredSSP: Initialize failed, do you have correct kerberos tgt initialized ?
Failed to connect, CredSSP required by server.

For long term solutions to this issue, organizations may wish to make this change part of a hardened standard image used to provision new servers.

Proactive Measures in Healthcare Application Security


Health IT:

The Growing Need for Proactive Healthcare Application Security

Web application security is a far more complex issue than many other areas of security. There is a high potential for applications to allow users to extract sensitive data, bypass authorization, and even execute commands on the system. But even applications that prevent these types of attacks are often found vulnerable to other “less direct” attacks. As we see time and time again, criminal hackers will go to extreme lengths of effort to profit in any way possible.

As many know, healthcare is an industry which has (understandably) lagged in security. It has had an extreme need for technology development, and has never been an attractive target like banks were to criminals. Unfortunately, the rising black market value of medical records is changing this, and with it bringing more sophisticated attacks. And to see what is coming, we don’t need to look far. We can take a lesson from the financial industry, which has been the target of cutting edge attacks for the last two decades.

As application security improves and attackers find themselves unable to gain direct access to systems, they will look to the next best thing: getting users to do the dirty work. These types of issues are heavily exploited in the financial world, an industry which has poured millions into ensuring applications are not susceptible to such attacks. These are most commonly known as a “confused deputy problem”, where a malicious actor persuades a victim into performing an action against their knowledge or will. Before we look at these attacks individually, it’s important to understand that all of these issues require several prerequisites in order to pose actual risk:

  1. An application performing a sensitive operation.
  2. An attacker with some prior knowledge of the application.
  3. A user currently logged into the application.

Cross-site Request Forgery (CSRF)

Chances are at some point you’ve seen a URL that looks like this:


It performs a specific sensitive function, and takes predictable parameters. While this probably doesn’t seem like a big problem to most people, an attacker may exploit this to force a user to delete records within an application.

CSRF Illustrated

Let’s take a detailed look at the steps:

  1. The attacker sends an email or message to the victim, convincing them to click a link to a website controlled by the attacker.
  2. The user clicks the link, visiting the malicious website.
  3. The attacker takes the URL that will perform a sensitive operation and embeds that link on the malicious site.
  4. When the victim’s browser loads the content of the malicious site, it attempts to fetch the content embedded on the page. This causes the victim’s browser to make a request for this URL – because the user is already authenticated to the application, the operation is performed successfully without any knowledge of the user.

You may be thinking “How is this a vulnerability? This is the way the web works” and you’re exactly right. For a long time this was just how applications were designed; and that was that. The ultimate weakness here is in the HTTP protocol itself, it was simply not designed for the fact that we would be using it for the most sensitive and life dependent operations that we do today. But in order to face reality, we must build applications that compensate for the weaknesses of all components, even the HTTP protocol itself.

ClickJacking (UI Redress Attack)

Similarly to CSRF, clickjacking also persuades a user into performing an action against their will. In this scenario, the attacker creates a web page that embeds the target application within a frame. The attacker then creates a CSS overlay to mask the encapsulated application. The mask may include a JavaScript game which encourages the victim to click on areas of the screen, or enter data into form fields. What the victim doesn’t know is they are actually clicking and typing into an application they are already logged into.

Clickjacking Illustrated

It’s important to note that the risk of CSRF and Clickjacking can vary wildly, and there are several factors which may increase or decrease the risk:

  • Sensitivity of operations – An attacker must be able to benefit from a user performing certain actions. Can the application transfer money? Send a medical record?
  • Ability to target users – An attacker must be able to persuade users to visiting a website. A broad user base of an application will increase risk.
  • Inside knowledge – An attacker must have some inside knowledge of the application. Open source and widely distributed products have a significantly elevated risk because of this.

The expanding health IT ecosystem drives all three of these factors higher in risk. As patient facing applications become more powerful, the more likely users will face these types of attacks. The good news is that both of these issues have well documented fixes which have been adopted into most development frameworks and web servers. Next week we will publish part 2 detailing mitigation strategies.

Defeating Android Emulator Detection



Defeating Android Emulator Detection

At some point while performing vulnerability assessments on android applications you will encounter apps that don’t want to be run within an emulator. We can’t blame application owners for wanting to ensure that the user interaction they see comes from genuine devices, but it doesn’t help us do any security testing on it.

There are several ways to detect an emulator; however this example is only relevant to the most common way we see. In this application, a check is performed for an IMEI value of ‘000000000000000’ which is the value used by the emulator that ships with the Android SDK.

The code segment below checks for this value and exits if true. While we could easily patch the value from within the application, it may be more efficient in the long run to simply change the IMEI value of our emulator. This way we don’t have to patch the next application that does this.

android emulator check

The IMEI is stored as a text string, so we will search for a ‘text string’ accordingly. Open the binary with hexeditor, hit ^W, and search for the fifteen zeroes. Note that the binary we wish to open is not the “emulator” binary, but the “emulator-arm” binary. If you are using a different architecture you may be using the mips or x86 binary.

cp emulator-arm emulator-arm.bak
hexeditor emulator-arm

hexedit search

Note once again this is an ascii string, so the zeroes are 0x30.


In this case, we just replace four characters with 1234 by updating 0x31, 0x32, 0x33, and 0x34. Do not change the length of data in this segment or overwrite bytes outside this segment or you will corrupt the binary.


Just save and exit. Now our emulator will be using our new custom value.

 Page 1 of 5  1  2  3  4  5 »