Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Tag Archives: Shmoocon

ShmooCon 2012: Raising The White Flag

Raising The White Flag

:: Bypassing Application White Listing

– Curt Shaffer and Chris Cuevas

NOTE: The video of this talk has now been made available over at the ShmooCon website.

More and more people are seeing application whitelisting in their environments. Despite what marketing people say, these solutions don’t stop APT and other advanced threats. This talk is designed to shine a light on the issues with whitelisting.

Whitelisting is often touted as a replacement for AV. Despite the fact that something better than AV is needed, application whitelisting isn’t the solution. Their purpose seems good, for the execution is lacking. Things are headed in the right direction, but using simple bypass techniques it’s possible to bypass these whitelisting protections.

The following application whitelisting tools were tested.

  • Bit9 Parity 6.0.0
  • McAfee Application Protection
  • Microsoft Applocker


  • Windows File Protection
  • File Naming Fun
  • Iexpress packagng
  • Java Exploits/Malware
  • Flash Exploits/Malware
  • Adobe Exploits/Malware
  • JavaScript
  • VBA
  • Raw Shellcode
  • Powershell
Some other things were excluded due to time constraints (including HTML5, CD-ROM ISO masquerading, Digitally Signed Malware).

Bypassing Techniques Attempted

  • ActiveX
  • PDF attacks
    • Spawning shell
  • Office documents
    • VBscript Macros
  • Shellcodexec
    • Inject shellcode into memory
  • JAVA
    • Applet
    • Exploit
  • JavaScript
    • BeEF hook
    • Firefox Extension
  • Powershell
    • Run script by piping into powershell.exe
    • DLL Injection
    • Shellcode injection
    • Chrome Extension
  • Man-in-the-Middle
    • Sniff, modify, replay
This is all know. We’ve been pissing on AV for a long time. Time to piss on whitelisting as well.



Most things worked, except Windows File Protection and Iexpress.


Inconsistent results with Windows File Protection, and again Iexpress failed. However everything else works.

What Worked


Injecting BeEF into a browser process

Windows Help Files

Compiled HTML, but needs a degree of social engineering to get people to click

Can run cmd.exe and game over

Office Documents

Lots of work in this area by Didier Stevens


Powershell code injection into any 32bit or 64 bit

Powershell syringe


Get between the client and server

ARP spoof, iptables redirect

It’s HTTPS, but it doesn’t check the cert

Enables you to drop level from enforce blocks to only alert

Self protection

Abilty to inject code into the actual whitelisting exe (in this case parity.exe of Bit9)

Bit9 deny this is an issue.

[ demo of shellcode exection within the Bit9 Notifier process ]

Metasploit module for this will be released to demo this.

Stopping this attack

To protect this on Bit9, go to the admin control panel and add memory rules to protect the notifier.exe process. The memory protection menu is only available in versions above 6.0.1.


  • Talk abstract –> HERE
  • (NEW) Further Information from the talk –> HERE
  • (NEW) Video of the talk –> HERE

ShmooCon 2012: Java backdoors and Cross Framework Abuse

Java backdoors and Cross Framework Abuse

– Nicholas (aricon) Berthaume

Adding backdoor(s)

Java has a number of different archive formats. This talk covers the J2SE / J2EE type archives. The goal here is to show how simple it is to add potentially malicious software to three of the most common format.

JAR – Java ARchive

Typical run in Java Virtual Machines on client system

ZIP files with manifests, metadata and Java byte-code

Can be digitally signed

WARs – Web application Archives

Typical run on Java application servers such as Tomcat

Run as the remote server user.

Can be digitally signed

EAR – Enterprise application ARchive

Very similar to WAR, but with extended enterprise features.

All three file formats when allowed to run can create sockets, interact with the filesystem outside of the respective virtual machines and execute commands there. This makes then perfectly suited for exploitation.

Run typical with full permissions of the user and display very few warnings. At most you receive a “run or don’t run” style prompt. Signing, even with a self-signed certificate, reduces these warnings.

AV engines rarely do effective heuristic analysis on known malicious code when it’s inserted into a Java Archive format.

JAR backdoor payloads

File droppers that execute arbitrary code.

WAR backdoor payloads

Completely malicious additions to existing WAR files content, JavaScript and so on.

All of the same features of JAR files, but run on the remote server.

EAR backdoor payloads

Similar abuse to WAR, but also allow for greater reuse of classes and scaling across multiple servers and additional security roles.

Adding content to WAR files is often as simple as editing the manifest and adding the required backdoor code. EAR is however a little more complex due to the additional features. However it’s possible to set the security context used to run your backdoor code.

JAR is more complex however. The process involves extracting a JAR to use as the host, add files into the correct paths and edit the MANIFEST as required.


Tool designed to automate this functionality. Written in Python.

When combined with the JDK, this tools will give you the ability to add arbitrary Java to existing files.

Currently tested with EAR, WAR, JAR files using the JAVA meterpreter as the standard backdoor. However other can be used with minor modifications.

Due to the way code is run, closing the browser after infection leaves the code active on the system.

Cross-framework Injection

In additions to pure Java there are a number of extension APIs that are either included or installable.

Java Native Access (JNA)

Open-source utility for calling native and managed libraries/assemblies on nearly every platform that the JVM runs on.

.NET from the JNA

By using assembled code in .NET (using jython) it was possible to implement simple calls outside the framework without needing to recompile the classes due to the reasonable support found in the JNA.

From here the goal is to inject processes, hopefully using standard injection techniques to inject into .NET or inject a DLL into memory.


  • Talk abstract –> HERE
  • RAWJAR project –> HERE

Shmoocon round-up

It’s been a whirlwind since I got back from DC… With work, private stuff and the odd SAP presentation. Still, Shmoocon remains fresh in my mind.

After a shaky start (whoops, my planes been cancelled), I finally got to DC with a short detour through New York and the usual run around from Delta airlines. Their staff are so nice, it’s almost like they’re family. You know, the ones you hate and fight with all the time… that kind of family 😛

Anyway, I managed to knock out a few blogposts from Shmoocon that might be interesting. I also finally got around to donating some money to Hackers for Charity, which I’ve had in my mind for a while now. It was good to say hi to Johnny even if he was distracted and rather rushed. Still, he’s doing good things, and after his presentation I’m more behind him and his cause than ever.

I have to say a special thanks to the InGuardians crew for including me in their big company night out. I’ve never been so well treated before, and it’s an experience I’ll hold with me for a long while to come. I hope to repay the favour if and when they visit Europe!

If you didn’t see the previous blogposts, here’s a short breakdown of the talks I covered :

There was a big focus on mobile vulnerabilities this year. Along with a few printer talks, which took me by surprise to be honest. Printer vulns have been talked about a lot before, and I wasn’t expecting a resurgence. Still, some interesting information for penetration testers if you care to look 😉

Despite the issues I’ve had getting to and from Shmoocon in 2010 and this year, I’ll be there next year… I just can’t drag myself away that easily 😉

Shmoocon 2011: URL Enlargement: Is it for you?

URL Enlargement: Is it for You?

Daniel Crowley

What’s behind short URLs?

  • Are short URLs really being used for bad things?
  • Do URLs contain sensitive information
    • Can you get short URLs removed
  • What are the possible solutions

Underlying issues

  • Easily guessable URLs
  • Storage of sensitive data in URLs
  • Authentication based on knowledge of the URL

URL Shorteners: The why, where and how!

Many exist (see urlshortener.org for a full list)

Very easy to make (lots of plugins available)


Specialized shorteners

  • go.usa.gov
    • For .gov and .mil restricted
      • Must have valid .gov/mil email address to setup
      • Restricted to .gov/mil sites
  • bieber.ly
    • Puts Biebers face on every page shortener
  • vb.ly
    • Sex shortener… it’s for PORN!
  • doz.me
    • Embeds landing site in an iFrame and launches a DoS attack against another site

Why shorten?


  • Sharing links on the internet
  • Share link orally


  • Obfuscation
  • Filter bypass (hiding direct IP links)
  • Social Engineering
  • Parasitic data storage

URL Shortening algorithms


  • Hash each URL to produce shortened version
  • Only 1 shortened domain per URL
  • Risk of collisions


  • Generate shortened URLs sequentially
  • One URL can be stored multiple times
  • No collisions

Interesting attack possibilities


  • URL poisoning through collisions
    • Figure out hashing algorithm
    • Shorten URL containing lots of junk padding
    • Depending on the shortener, the new URL may replace existing one shortened


  • Date tracking
    • Create URL every 24 hours
    • Determine when target URLs were shortened
    • Extract URLs for time period

Character Set

  • Base62
  • Very easy to guess

Security Shortcomings

  • Cannot predict Referer header
  • Cannot predict the accessing IP address
  • URLs are predictable
    • Small keyspace
    • Some services let you choose your own URL

The Attack: URL Harvesting

Determine character set and URI length for targeted shortener

Determine case sensitivity by modifying an existing URL

All tested shorteners tested use location header redirects (HEAD requests)

Create URLs to harvest



Photobucket –> Security based on knowing the link

Google Docs –> Knowing the shared link gives access to the shared data

Protocol Handlers

URL shorteners don’t just shorten website addresses

  • mailto:
  • ftp:
  • file:
  • Ed2k:
  • Magnet:
  • Javascript:
  • Webcal:
  • Irc:
  • iOS app IPC
    • Many iPhone apps define there own handlers

Parasitic Storage

  • Base64 encode your file
  • Split it into chunks
  • Optionally, encrypt each chunk
  • “shorten” each chunk as a URL
  • Retrieve it later in chunk form
  • Decrypt, combine

Each chunk can be 256Kb or larger

Tools like TinyDisk offer automated way to achieve this.

In-URL Authentication

  • http://user:pass@example.com
  • Session Identifiers in the URL
  • Auth in GET variables
  • Authentication through knowledge of URL
    • Scribd
    • Facebook
    • Imageshack
    • Photobucket
    • Google Docs

Lonely people sometimes talk to URL shorteners

People type the strangest things into the “short this” box!


Everyone seems to like putting XSS attacks in tinyurls

CSRF seems pretty popular too

  • Qaboss.com was recently hacked
  • Somewhere in Tinyurl theres still an XSS/CSRF attack…

Find 0-Day vulns

  • Search through your gathered list of URLs for SQL statements, File Includes, …


  • The biggest use of shorteners appears to be spam
  • Multiple TinyUrls pointing to the same spam site
    • Helps disguise things
    • Original TinyUrl address appears in the referrer header

Multiple Shortenings

Shortening a TinyUrl with TinyUrl?

Clearly not the length of the URL that people are worried about here

Attempts to use multiple redirections to frustrate analysis

Interesting target for analysis?

So what can we do?

Can I have my URL taken down?

  • Not easily
    • Unless it’s malicious, defamatory, or breaks the ToS
  • URL shorteners want to keep links intact

How can shorteners be more secure?

  • URL Harvesting
    • Password protected URLs (Trick.ly!)
    • Throttling
    • Temporary lockout on brute-force attempts
      • Especially for non-existant URLs
  • Parasitic Storage
    • No good answer
  • Multiple Shortenings
    • Disallow known shortened links
  • Attacks
    • Filter out common XSS artifacts
    • Compare URLs to list of known badware (some already do)

How can we protect ourselves?

  • Stop shortening sensitive URLs
  • Stop putting sensitive data into URLs
  • Check shortened URLs before accessing them (longurlplease)

Fun Facts

Your chance of finding X behind a short URL

  • Rick Astley: 1 in 12342
  • Goatse: 1 in 10872
  • An EXE file: 1 in 454
  • Audio file: 1 in 290
  • Images: 1 in 47

Most shortened domains

  • Twitter.com
  • Runner-up: YouTube.com