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++

Dangerous Sudoers Entries – PART 5: Recapitulation

The following article describes common security issues regarding misconfigured sudoers’ files. The article focuses on a single entry which contains several security issues:

hacker10 ALL= (root) /bin/less /var/log/*

The article is split into the following five chapters:

Define the allowed “sudo” commands carefully. Don’t allow commands to be run without knowing all the features it offers.

1. Disallow the execution of further commands by adding the “NOEXEC” flag:

hacker10 ALL= (root) NOEXEC: /bin/less /var/log/*

2. Check if the feature set of the command can be restricted. E.g. check for environment variables shown “LESSSECURE=1” for “less”:

#/etc/profile.d/lesssecure.sh
LESSSECURE=1
readonly LESSSECURE
export LESSSECURE
#/etc/sudoers
Defaults        env_reset, env_keep=LESSSECURE

3. Check the file permissions carefully as this might render all your efforts useless:


4. Only use wildcards when you know that a breakout will be impossible.

The first example shows how to access the “/etc/passwd” file directly:

The second example shows how to open an additional file which can later be accessed by typing “:n” in “less”:

By following these rules you might avoid a malicious user to gain further privileges on your system.

 

Dangerous Sudoers Entries – PART 4: Wildcards

The following article describes common security issues regarding misconfigured sudoers’ files. The article focuses on a single entry which contains several security issues:

hacker10 ALL= (root) /bin/less /var/log/*

The article is split into the following five chapters:

The last issue with our example “sudo” command is the wildcard (*).

Excerpt from the “sudoers” man page:

Wildcards

sudo allows shell-style wildcards (aka meta or glob characters)
to be used in hostnames, pathnames and command line arguments in
the sudoers file. Wildcard matching is done via the POSIX glob(3)
and fnmatch(3) routines.  Note that these are not regular
expressions.
*       Matches any set of zero or more characters.
?       Matches any single character.
[...]   Matches any character in the specified range.
[!...]  Matches any character not in the specified range.
\x      For any character "x", evaluates to "x". This is used to
        escape special characters such as: "*", "?", "[", and "}".
POSIX character classes may also be used if your system's glob(3)
and fnmatch(3) functions support them.  However, because the ':'
character has special meaning in sudoers, it must be escaped.
For example:
/bin/ls [[\:alpha\:]]*
Would match any filename beginning with a letter.
Note that a forward slash ('/') will not be matched by wildcards
used in the pathname. When matching the command line arguments,
however, a slash does get matched by wildcards. This is to make
a path like:
/usr/bin/*
match /usr/bin/who but not /usr/bin/X11/xterm.
Exceptions to wildcard rules
The following exceptions apply to the above rules:
""      If the empty string "" is the only command line argument
in the sudoers entry it means that command is not allowed to be
run with any arguments.

As the wildcard in our example is part of the arguments and not the path name, it allows us to break out. One way to do this is shown in the following example:

Another way to break out would be the following command:

When in less it is possible to use the “:n” command to switch to the next file in the file list:

Solution

Wildcards are extremely dangerous. Don’t use them if you are not 100% sure that a malicious user is able to abuse it.

The more secure solution to the issue would be to write a script which does input validation and is the only thing that is allowed to be called using “sudo”.

Dangerous Sudoers Entries – PART 3: Permissions

The following article describes common security issues regarding misconfigured sudoers’ files. The article focuses on a single entry which contains several security issues:

hacker10 ALL= (root) /bin/less /var/log/*

The article is split into the following five chapters:

Another pitfall of securing “sudo” commands are the file system permissions. If the permissions aren’t set correctly, an attacker might circumvent the restrictions we have implemented during the last two blog posts. For the next example the administrator changed the directory permissions for the directory “/var/log/” to “777”. Obviously, this is a bad idea for this directory and a almost unrealistic scenario. None the less, this situation might appear if we use an application specific directory which has been configured manually.

Because of the write permissions in this directory we are allowed to create arbitrary files in it. This allows us to create links to files residing in other directories. This will grant us access to the linked file once we use “less” as user root:

“less” shows us the following content when the previous command is executed:

Furthermore, ensure that the user has no write permissions on the executable.

Solution

The only solution to this issue is setting appropriate permissions on the file system!

Dangerous Sudoers Entries – PART 2: Insecure Functionality

The following article describes common security issues regarding misconfigured sudoers’ files. The article focuses on a single entry which contains several security issues:

hacker10 ALL= (root) /bin/less /var/log/*

The article is split into the following five chapters:

In this article we are going to focus on insecure functionality “less” offers. The example with “less” is just to illustrate that the functionality of each application we use with “sudo” has to be checked carefully to ensure that a malicious user won’t be able to abuse it.

“less” offers a command to read other files on the system. Again, the current permissions of “less” are used to read these files.

Excerpt from the man page:

:e [filename]

Examine a new file. If the filename is missing, the "current" file
(see the :n and :p commands below) from the list of files in the
command line is re-examined. A percent sign (%) in the filename
is replaced by the name of the current file. A pound sign (#) is
replaced by the name of the previously examined file. However, two
consecutive percent signs are simply replaced with a single percent
sign. This allows you to enter a filename that contains a percent
sign in the name. Similarly, two consecutive pound signs are
replaced with a single pound sign. The filename is inserted into
the command line list of files so that it can be seen by subsequent
:n and :p commands. If the filename consists of several files, they
are all inserted into the list of files and the first one is
examined. If the filename contains one or more spaces, the entire
filename should be enclosed in double quotes (also see the -"
option).

In the following example the /etc/shadow file has been read.

Solution

The environment variable “LESSSECURE” can be set to “1” to disable dangerous features of “less”.

Excerpt from the man pages:

When the environment variable LESSSECURE is set to 1, less
runs in a "secure" mode. This means these features are disabled:
!      the shell command
|      the pipe command
:e     the examine command.
v      the editing command
s -o  log files
-k     use of lesskey files
-t     use of tags files
metacharacters in filenames, such as *
filename completion (TAB, ^L)
Less can also be compiled to be permanently in "secure" mode.

There are now two steps we have to take to ensure that this works as expected. First, the current user must have the “LESSSECURE” environment variable set as read-only. Otherwise the user would be able to change its value. This can be achieved by adding the following line to a file in the path “/etc/profile.d/”. We use a new file called “/etc/profile.d/lesssecure.sh” and add the following content:

LESSSECURE=1
readonly LESSSECURE
export LESSSECURE

The second step is to tell “sudo” to keep the “LESSSECURE” variable from the user. This is achieved by adding the env_keep option in the sudoer’s file:

Defaults        env_reset, env_keep=LESSSECURE

The following message appears now if someone tries to use one of the insecure commands.

Dangerous Sudoers Entries – PART 1: Command Execution

The following article describes common security issues regarding misconfigured sudoers’ files. The article focuses on a single entry which contains several security issues:

hacker10 ALL= (root) /bin/less /var/log/*

The article is split into the following five chapters:

In this article we are going to focus on the command execution feature of “less” which may appear in other applications and scenarios as well. “less” allows a user to execute arbitrary commands by entering “!”.

Excerpt from the less man page:

! shell-command

Invokes a shell to run the shell-command given. A percent sign (%)
in the command is replaced by the name of the current file. A
pound sign (#) is replaced by the name of the previously examined
file. "!!" repeats the last shell command. "!" with no shell 
command simply invokes a shell. On Unix systems, the shell is
taken from the environment variable SHELL, or defaults to "sh".
On MS-DOS and OS/2 systems, the shell is the normal command
processor.

As an example, we run the command “whoami” within “less”:

This command is being executed with the same rights “less” is running. Therefore, whoever is allowed to read a file with less is allowed to execute commands with the same rights. In this case as the user “root”.

Another feature that falls in the category command execution is the possibility to start the default text editor as this is nothing else but the execution of another application. To start the default text editor the user has to press the “v” key.

Excerpt from the man page:

v      Invokes an editor to edit the current file being
viewed. The editor is taken from the environment variable VISUAL
if defined, or EDITOR if VISUAL is not defined, or defaults to
"vi" if neither VISUAL nor EDITOR is defined. See also the
discussion of LESSEDIT under the section on PROMPTS below.

In our case we start the editor “nano” from “less”:

Of course it is possible to prevent “less” from executing arbitrary commands. There are two possible ways to do this. The one described in this part of the blog post focuses on the general prevention of additional command execution and isn’t “less” specific. Therefore, it is possible to use this solution for other applications as well.

Solution

The execution of other binaries might be prevented by adding the NOEXEC tag in the sudoer’s file. This works only if “sudo” has been compiled with noexec support and if the underlaying OS supports this as well.

hacker10 ALL= (root) NOEXEC: /bin/less /var/log/*

The following two screenshots shows the results of the previously described methods to run an arbitrary command or default editor.

JBoss 7.1 Web Server Hardening

JBoss is a popular open-source Java application server which underwent a major rewrite of its code-base for its latest version 7.x. Of this new branch, only version 7.1.0.Final, released a week ago, is certified for the Java EE 6 Full Profile.

As part of the code rewrite, the configuration settings also got a global overhaul. The settings are now mostly regrouped per mode (standalone or domain) and profile (default, full, ha and full-ha – e.g. standalone/standalone-full.xml).

The default settings for the web server component look as follow:

<?xml version='1.0' encoding='UTF-8'?>
<server xmlns="urn:jboss:domain:1.1">
[CUT BY COMPASS]
  <profile>
  [CUT BY COMPASS]
    <subsystem xmlns="urn:jboss:domain:web:1.1"
     default-virtual-server="default-host" native="false">
    <connector name="http" protocol="HTTP/1.1" scheme="http"
     socket-binding="http" />
    <virtual-server name="default-host"
     enable-welcome-root="true">
      <alias name="localhost" />
      <alias name="example.com" />
    </virtual-server>
  </subsystem>
  [CUT BY COMPASS]

Several hardening steps can be performed, such as:

  • Enabling only HTTPS and disabling HTTP
  • Disabling the display of source fragment
  • Removing the x-powered-by http header
  • Disabling the default JBoss 7 welcome pages

The following hardened configuration is therefore a good start for the web server component:

<?xml version='1.0' encoding='UTF-8'?>
<server xmlns="urn:jboss:domain:1.1">
[CUT BY COMPASS]
  <profile>
  [CUT BY COMPASS]
    <subsystem xmlns="urn:jboss:domain:web:1.1"
     default-virtual-server="default-host" native="false">
    <connector name="http" protocol="HTTP/1.1" scheme="http" 
     socket-binding="http"
     enabled="false"/>
    <configuration>
      <jsp-configuration
       display-source-fragment="false"
       x-powered-by="false"/>
    </configuration>
    <connector
     name="https"
     protocol="HTTP/1.1"
     socket-binding="https"
     scheme="https"
     secure="true">
      <ssl
       name="ssl"
       protocol="TLSv1"
       password="[CUT BY COMPASS]"
       verify-client="false"
       cipher-suite="HIGH"
       certificate-key-file="${user.home}/.keystore"
       ca-certificate-file="${user.home}/.trustedstore"/>
    </connector>
    <virtual-server name="default-host"
     enable-welcome-root="false">
      <alias name="localhost" />
      <!-- COMMENT THIS SECTION TO DISABLE IT
      <alias name="example.com" />
      -->
    </virtual-server>
  </subsystem>
  [CUT BY COMPASS]

Documentation relating to these settings can either be found in the XML schema files located in docs/schema/*.xsd or in the online documentation (e.g. about the jsp-configuration element).