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 …

Samba Exploit Development Presentation

As penetration testers, our main goal is to identify as many vulnerabilities as possible. This allows our customers to more objectifly assess their security level and to shut as many doors as possible which an intruder could use to break in. This process needs to be based in respect of cost-benefit, depending on risk probabily and impact. Exploitation is only a secondary objective, mostly used to facility the first one. Also – the fix for most software vulnerabilities is the same: Always update all your software everywhere as soon as possible.

In my spare time, I like to get low-level and study the art of exploitation. From time to time I try to shed some light on the dark art of exploitation, by giving a little presentation to my work colleagues about my findings.

In my presentation I talk about CVE-2012-1182 (“root” credential remote code execution in Samba). First I show a small analysis of the vulnerability itself. After that I outline the inner workings of the Samba heap allocator. Based on this knowledge, I describe how to develop a working exploit which circumvents typical anti-exploitation securiy features like NX, ASLR and PIE.

 I close the presentation with a short analysis of the randomness of libc function addresses of common linux distributions. To summarize, ASLR/PIE implementations in 32 bit Linux distributions do not provide adequate randomness against brute forcing of ret2libc function addresses, as they provide less than 12 bit of entropy. OpenBSD-32bit provides 16 bit, and 64 bit linux distributions more than 20 bit of entropy, which considerably slows brute-force exploiting attempts.

Here are the results of my short evaluation. I generated around 1 million processes, each printing the address of system(), collected them in a file and did some analysis. In the following table, the second row shows the number of unique addresses collected. The third row shows how many times the most common address is being used, in respect to the least common.

It is not really a problem to brute force around <2000 addresses in a suitable timeframe, so the 32 Bit Linux distributions receive a FAIL rating. OpenBSD does a much better job on randomizing LIBC function addresses (as expected). 64 Bit operating systems are the hardest to brute force.

More details in my presentation: sambaexploit_v1.0.pdf

Exploit credentials stored in Windows Group Policy Preferences

Group Policy preferences are a new feature set available since Windows Server 2008, which shouldn’t be confused with the well known Group Policy objects (GPOs) dating back to Windows NT. The main idea behind the creation of Group Policy preferences is the ability to push so-called “unmanaged” settings. Compared to “managed” GPOs, group policy preferences can be altered by the end user and aren’t enforced on a regular basis.

Before the release of the Group Policy feature, administrators could already set user preferences via scripts or .reg files. This lead to complex login scripts potentially containing sensitive information. Using Group Policy features, you can now manage this kind of settings centrally and in a convenient way.

While this addition was released with Windows 2008 Server, you can install the client-side extensions on client computers running on Vista, Windows XP SP2 or Windows 2003 SP1 for backward compatibility with all your workstations.

Let’s see an example on how we can define a local user on some workstations. It starts with the creation and edition of a group policy object:

In the Group Policy Management Editor, we still see our well-known Policies folder, but also a new hierarchy for these unmanaged preferences. Creating a local administrator on the machines targeted by the GPO “GPO_local_accounts” is only a matter of clicks:

Where is this setting stored and how secure is it? Group Policy Preferences are stored, as all other GPOs, within the SYSVOL folder on the domain controllers (%LOGONSERVER%\SYSVOL) but within xml files.

The above created policy gets translated into the following groups.xml file:

<?xml version="1.0" encoding="utf-8"?>
  <Groups clsid="{3125E937-EB16-4b4c-9934-544FC6D24D26}">
    <User clsid="{DF5F1855-51E5-4d24-8B1A-D9BDE98BA1D1}"
     name="ladmin_gpo" image="0" changed="2012-02-03 07:10:48"
     uid="{FE47E73C-7525-46CD-B2E0-F68D3022EDCE}">
      <Properties action="C" fullName="Local admin created by GPO"
       description=""
       cpassword="9QHhFTUdm6rDgu30J7ShZfqt07T6vOUGkyAFG3G7M+5AotJjkOva7E9KSAcamdrruTgly0O/uVTB/UUdLNU4775b5381hyuUzkd4lJW+llcNNNrQlYu7zqH3/i+8jfjhUq9lqPn8VjCtb9iaEqWbKQ"
       changeLogon="0" noChange="0" neverExpires="0"
       acctDisabled="0" userName="ladmin_gpo"/>
    </User>
    <Group clsid="{6D4A79E4-529C-4481-ABD0-F5BD7EA93BA7}"
     name="Administrators (built-in)" image="2"
     changed="2012-02-06 10:45:50"
     uid="{4D0CE71D-D2E4-42B1-9BF3-147C910A15F1}">
      <Properties action="U" newName="" description=""
       deleteAllUsers="0" userAction="ADD" deleteAllGroups="0"
       removeAccounts="0" groupSid="S-1-5-32-544"
       groupName="Administrators (built-in)">
        <Members>
          <Member name="ladmin_gpo" action="ADD" sid=""/>
        </Members>
      </Properties>
    </Group>
  </Groups>

So how secure is my password, stored within the cpassword attribute? According to the documentation, it’s using AES-256 – so pretty secure, isn’t it?

Well, not exactly, as the key is public and documented in the MSDN. All you need to do is open CrypTool, add some padding to the value to be base64 compliant, and perform a base64 decoding:

Choose then the AES decryption option (Analysis – Symmetric Encryption (modern) – Rijndael (AES) and paste the public key:

That’s it, the password is decrypted without any brute-force attack:

As conclusion, while Group Policy preferences are a great tool to distribute unmanaged settings, it should not be used to push down features containing credentials such as:

  • User preferences
  • Database connections strings
  • Scheduled tasks
  • Mapped drives settings
  • Service preferences

References

 

Reversing in God Mode

Fridays, I was approaching a win32 reversing challenge. So I transferred the binary into my Windows XP virtual box and fired-up OllyDbg. The goal was to bypass the username and password prompt that occurred on application startup. Hilariously, I was just providing a dummy name and password to the app…. “asdf” “asdf” as probably most penetration testers have done so, over and over to test logon prompt behavior.

BANG… the app is telling me: “Correct, le clef est Le saucisson vaudois ca rapicole.!”

The force was with me and actually, only Chuck Norris could have topped that :) . Was I in god mode? Probably not. Later analysis just revealed that the application required the password to be equal to the username and had some minimal restrictions on the credentials length.

All in all, a 30 seconds exercise.

Lessons learned:
– Implement strong password policies
– Give it a try before you hurry to launch Olly.

BeanShell puts Java Application Servers at Risk

Developers increasingly integrate BeanShell support into web applications to provide end users and administrators with a simple extension framework. But be warned! BeanShell support without appropriate access control will put the hosting web server at severe risk. An attacker could easily execute operating system calls and without appropriate system hardening such an attack will immediately result in full system compromise.

The BeanShell[1] is an environment that provides execution of Java code snippets in the web application context. The shell supports full Java language syntax and some loose structures for convenience. Be aware, to run code within an Java Virtual Machine (JVM) means to run code on the server. The following screenshot shows BeanShell enabled web application that just run a hello world command.

However, to be able to do some meaningful attacks one must first overcome and understand some limitations of the Java Runtime.getRuntime().exec() method. Simply putting a whole command into the exec method will not run properly since Java will internally tokenize the String and redirect IO streams. The first argument will be taken as executable. All remaining tokens will be passed as parameters to the executable. Thus, the below statement will not work as intended because the “-c” parameter awaits a single argument.

Runtime.getRuntime().exec("/bin/sh -c /bin/echo pwned > /tmp/poc"};

Following that, command injection in Java is a difficult thing to do since the attacker mostly just gains control over the parameters. However, in BeanShell we are pretty free to choose from the whole arsenal of Java API classes and methods. Finally, a correct call would look like:

String[] cmd = {"/bin/sh", "-c", "/bin/echo pwned > /tmp/poc"};
Runtime.getRuntime().exec(cmd);

That way, Java will pass “/bin/echo pwned > /tmp/poc” correctly. Unfortunately, there is another limitation on the IO streams. Thus, to read and process the output of a command the InputStream classes will be needed. The following snippet is a working example with the Unix list directory (ls) command.

import java.io.*;
try {
Process ls_proc = Runtime.getRuntime().exec("/bin/ls -lah");
DataInputStream ls_in = new DataInputStream(ls_proc.getInputStream());
String ls_str;
while ((ls_str = ls_in.readLine()) != null)
print(ls_str + " ");
} catch (IOException e) {
}

So, you might be asking yourself how this ex-course on the Runtime class’s exec method is related to BeanShell support in web applications?

I have published an advisory[3] on insufficient access control of an integrated BeanShell in an Enterprise Java (J2EE) based document management system software (OpenKM). An attacker could prepare en evil e-mail or website that runs a malicious command on the server if the OpenKM administrator clicks on the link or visits the prepared website.

For example, an attacker would simply embed the below JavaScript exploit code into a web page to cause writing a proof of concept file into the /tmp folder.

img = new Image();
img.src="http://example.com/OpenKM/admin/scripting.jsp?script=String%5B%5D+cmd+%3D+%7B%22%2Fbin%2Fsh%22%2C+%22-c%22%2C+%22%2Fbin%2Fecho+pwned+%3E+%2Ftmp%2Fpoc%22%7D%3B%0D%0ARuntime.getRuntime%28%29.exec%28cmd%29%3B"

Related vulnerabilities are often seen in administrative interfaces of web apps. The attack scheme is also known as Cross-site Request Forgery or XSRF[4]. There are several ways to approach the issue. Either ensure proper access controls[5] or lock down the JVM using Java security policies and the Security Manager[6]. In the end, system hardening may help limiting collateral damage in case of successful attacks.

References
[1] http://www.beanshell.org/
[2] http://www.ensta-paristech.fr/~diam/java/online/io/javazine.html
[3] http://www.csnc.ch/misc/files/advisories/COMPASS-2012-002_openkm_xsrf_os_command_execution.txt
[4] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29
[5] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
[6] http://docs.oracle.com/javase/7/docs/api/java/lang/RuntimePermission.html

Retrospective about cache snooping

As it is known since at least 2006, a website is able to identify the domains a user previously visited, with some simple CSS hacks. This had great privacy implications, and browsers took steps to eliminate this problem. But in December 2011, lcamtuf presented a new proof of concept based on cache timings, which basically does the same thing. This new technique uses JavaScript and the caching behavior of previously loaded resources to identify visited domains.

This vulnerability is not something a penetration test will identify, as it is purely a client side problem. Nevertheless it is a interesting topic as it exposes fundamental flaws in browser technology concerning privacy and which can’t be patched easily. It is similar to side-channel attacks in crypto systems, and the fix inherently reduces performance.

The attached presentation “CSS -visited – or now Browser Cache Timing” gives an overview of the history around this issue and how the proof of concept of 2006, respectively December 2011 work.

Simulated Industrial Espionage with the Pwnie Express Device

The Pwnie Express is a device that is designed for remote security testing of corporate and federal facilities and can be used as an “All-In-One” hacking drop box, aiding the pentesters at Compass Security, to conduct “real world” industrial espionage simulations.

null
http://pwnieexpress.com/

The typical penetration testing scenario is:
1) A Compass analyst manages to “social-engineer” his way into the premises of the customer, who ordered the penetration test.
2) As soon as the analyst finds an unprotected network plug, printer, WiFi network or unprotected computer, he connects the Pwnie Express device to it.
3) The preconfigured Pwn Plug uses extremely aggressive reverse tunneling mechanisms to establish a reverse connection (SSH, SSL, HTTP, ICMP, DNS, 3G) back to the compass C&C (command and control) server.
4) From this server the analyst at Compass is able to penetrate the internal network of the customer, as if he is on site.

All in all a very useful little tool that shows possible impacts of missing user awareness or inadequately secured premises to our customers.