Raising The White Flag

:: Bypassing Application White Listing

– Curt Shaffer and Chris Cuevas

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

Methodology

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

Results

McAfee

Most things worked, except Windows File Protection and Iexpress.

Bit9

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

What Worked

JavaScript

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

Powershell code injection into any 32bit or 64 bit

Powershell syringe

Man-in-theMiddle

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.

Links:

• Talk abstract –> HERE

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.

Enter RAWJAR

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.

Links:

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

SANS Germany 2012
SANS Germany 2012 is coming up soon on 5-10 March at the Arcotel Camino in Stuttgart. This will be the first SANS training conference in the country since 2008. SANS is bringing some of its biggest classes back to Europe by popular demand.

SEC504: Hacker Techniques, Exploits and Incident Handling
MGT512: SANS Security Leadership Essentials for Managers with Knowledge Compression
DEV522: Defending Web Applications Security Essentials

So if you’re thinking of attending, the discount code “SANS5DE12” should be good for 5% off the cost of the course. Enjoy!

Links:

• SANS Germany 2012

As I said in my previous blogpost, SecZone was a great experience. I took the feedback I got from my Hashdays talk on the same subject and improved on some of the aspects of my talk. Although the changes are minor and no new research content was added, I’ve uploaded the slides to slideshare for those interested.

Thanks to the #DirtySec crew for the feedback! Always room for improvement!

SAP (in)security: Scrubbing SAP clean with SOAP

As usual if you have any feedback or questions… please get in touch!

I was sceptical on many levels when I boarded the plane to fly out. I was worried about possible security issues (no, I’m not talking buffer overflows here), and I was worried that the hype might not match with the reality at all. What I found once we arrived though was friendly faces, helpful people and a conference that, even if not the largest in the world, certainly had a special feeling and a real uniqueness to it all! It was unlike any security conference I’ve attended, and certainly a memory I’ll have with me for years to come.

It’s hard to tie down specifics, and taking a weeks worth of experiences in putting them into a single blogpost would never do it justice. There’s just no way to describe things…

How do you describe David Marcus convincing the army bomb disposal representative into demonstrating the bomb disposal robot. Yes, Dave got it to press enter on his keyboard. Pity he couldn’t get it on stage to automate his slides

How do you describe the whirlwind drive through the Colombian mountains culminating at a childs petting zoo in the middle of nowhere (those who were there will know why this was a worthy of a mention ;)

How do you describe the hilarity of Chris Nickerson’s and Ian Amit’s “Red Team Testing” class being live translated by a group of Colombian school girls (for the benefit of the non-English speakers who attended)

These are just things you need to live through… what better way to end the #DirtySec 2011 tour!

Videos of the event are in the process of being edited and should be released with English/Spanish. As this is only my 2nd “big” conference talk I’m looking forward to seeing how bad my presentation really was. There’s always room for improvement!

Some Stats from SecZone 2011:

Attendees: 454 people (Colombia, UK, USA, Venezuela, Brazil, Argentina, and Mexico)

Live Video: 2403 people (Colombia, USA, Canada, UK, Chile, Ecuador, Spain, Peru, Switzerland, Germany, Belgium, Venezuela, Estonia, Argentina, Greece, Guatemala, France, Mexico, South Africa, Romania, Panama, Hungary, Portugal, Ireland, India, Brazil, Egypt)

Training attendees: 92 people (4 training classes)

SecZone 2012?

Planning for next year is already underway… bigger… better… and Cali knows what to expect next year.

Looks like #DirtySec 2012 tour will include SecZone for a while to come!

Well it’s been a few days since Deepsec 2011 finished, and I thought it was about time I wrote something about the actual conference.

Day 1

The first day started off with the usual 6am start to get to Vienna in time for registration. I arrived a few minutes late for the keynote, but quickly got into the swing of things. The keynote (How Terrorists Encrypt) was a discussion of how terrorist organisations (mostly Al Qaeda and connected cells) use encryption to communicate. Although you’d expect terrorists to have the basics of OPSEC down to a fine art by now, the presentation read more like a catalogue of failures and basic lack of skills/information. Instances such as the BA IT Expert, Rajib Karim and his refusal to use the Mujahideen Secrets tool (front-end for PGP/GPG?) in favour of a simple alphabetic replacement cipher.

The talk was definitely eye-opening on how badly the terrorists seem to be using encryption in general. However it does raise the question, are we only catching the stupid ones? Perhaps the better prepared are using encryption and simply staying below the radar!

I wrote a number of blog posts on the other talks from Day 1 :

• DEEPSEC: Reassemble or GTFO!
• DEEPSEC: Intelligent Bluetooth fuzzing – Why bother?
• DEEPSEC: Windows Pwn 7 OEM – Owned Every Mobile?
• DEEPSEC: SMS Fuzzing – SIM Toolkit Attack
• DEEPSEC: Extending Scapy by a GSM Air Interface

Day 1 ended with a discussion by Morgan on the changing face of the infocalypse. Definitely worth catching on video once it’s released.

Day 2

The second day of the conference started off with a presentation on Identity X.0, OAuth, OpenID and general security issues surrounding user-centric Identity technologies. An interesting overview of implementation issues.

As with day 1 I wrote a number of blog posts for talks on day 2 :

• DEEPSEC: How To Rob An Online Bank (and get away with it)
• DEEPSEC: Ground BeEF: Cutting, devouring and digesting the legs off a browser
• DEEPSEC: Your crown jewels online: Further Attacks to SAP Web Applications

After lunch I took some time to watch Kizz MyAnthia’s presentation on Bond Tech and had a long chat with him about Mobile Phone hacking and some issues he had getting his “toys” through UK Border Security.

Unfortunately the second SAP talk of the conference (Rootkits and Trojans on your SAP landscape) met with a slight issue as the presenters laptop fell on the floor as the talk began. Although he managed to complete the talk the demos weren’t possible due to data corruption. This was a pity as the content of the presentation itself was almost 100% the same as a presentation he gave in 2010. The demos would have been the saving grace here I think. Still, that’s life!

The final presentation of the conference was by Tom Mackenzie discussing some of the issues surround vulnerability research and coordination with vendors. The presentation touched on some interesting points and posed some open-ended questions, as well as showing some interesting examples of when things work and when they don’t!

Day 2 finished off with a late night party at Metalab… good music, club mate and good company. Oh and I once again lost to Kyrah at table football! One day I will prevail, oh yes, I will

Conclusion

Overall I’d give Deepsec a 7/10 for a solid conference, with friendly people and good presentations. It will definitely be on my recommended list once I get around to writing one

The Good

Nice mix of presentations

Great location / organisation

The Bad

No way to leave feedback for individual speakers

No lightning talks

The Ugly

At least 1 talk based on 12 month old research / vulnerabilities

Mariano Nunez Di Croce

Introduction to SAP

Largest provider of business management solutions in the world

• 140,000 implementations
• > 90,000 customers
• 120 countries

What SAP Security used to be

The different SAP Web Application Servers

Not uncommon to find multiple internet technologies in use. SAP systems are nowadays often found on the internet

SAP Internet Transaction Server (ITS)

Released in 1996. SAPs first approach to enable internet access to SAP systems

SAP Internet Communication Manager (ICM)

No more middleware == direct access from the internet

ICM Web Server requests are handled by the ICF

SAP Enterprise Portal

Latest technology from SAP

Provide a unique access point to the organizations SAP and non-SAP systems through the Web

Attackers Dream

External attackers are less likely to be caught, but lack the required access to systems.

By putting SAP systems on the internet you’re offering the best of both worlds.

Access to SAP infrastructure from a remote location

Identification

through server banners

Hard if it’s running through a reverse proxy

Otherwise various information visible to users through the server headers

through error messages

Attacks to the ICM

Dangerous ICF Services

The Info Service

An explosive combination

SOAP RFC Service

Attacks to secured enterprise portals

SAPPortalShell

Further Attacks

Links :

• Your crown jewels online: Further Attacks to SAP Web Applications –> Overview
• Attacks to SAP Web Applications (Blackhat DC 2011 Slides) –> PDF
• SAP REMOTE_USER info –> Link

Michele Orru

So who thinks XSS attacks are lame?

Real-Life XSS Pwning :

• 2005: Samy Worm
• 2006: Yamanner worm
• 2008 XSS in Obama Website
• 2010: Apache pwned through XSS in Jira
• 2010: Stored XSS in YouTube
• 2011: Multiple XSS on Google,com

What is BeEF

Browser Exploitation Framework

Created in 2005 by Wade Alcorn. Rewritten recently to Ruby.

Powerful platform for client-side pwnage, XSS Post Exploitation and generally victim browser security context abuse.

Framework for penetration testers to select specific real-time attacks on browsers to demonstrate vulnerabilities and impact

Example: Using the browser behind a corporate firewall to access internal resources

• Ping sweeps
• DNS enumeration
• Port Scanning
• Network Fingerprinting

Exploiting Internal Services

Achieving persistence

Module Autorun

Tunneling Proxy

XSSRAYS

100% JavaScript based XSS scanner

Works cross-domain

Integrated into BeEF to scan for href based XSS in a browsers session. If a possible XSS injection point is found then the XSS is set to the BeEF hook.

Future DEV and Ideas

Links :

• Ground BeEF: Cutting, devouring and digesting the legs off a browser –> Overview
• Ground BeEF slides –> PDF
• BeEF Project Homepage
• BeEF Twitter Account –> @beefproject 

Mitja Kolsek 

Evolution of online banking attacks

For as long as online banking has been in effect, attackers have been trying to directly attack users. Phishing and client.side attacks are the past, present and future. More of these attacks are becoming focused on business customers.

Goal: Identity Theft

Attacks against personal users are interesting, but corporations are a much more lucrative target. It’s not unusual to see a corporation sending millions of dollars in transfers, and as such it’s easier to make money. However with corporate banking you need to be more targeted to find who in an organisation is responsible, and who should be targeted.

Digital certificates is a common method to locate the responsible party. These certificates are assigned to users for online corporate banking, and are often listed in online repositories. The data on these certificates often includes name, email and enough details to target a corporation.

Goal: Exploitation of Application Flaws

The attacker usually has no knowledge of the flaws in the remote system. This gives the bank a window of opportunity to detect the attacker as he probes systems. The bank is a perfect target, as it’s where all the money is, and there’s no messy social engineering required.

Direct Resource Access

Online banking is mostly web-based, even if there is a thick client or mobile application, in the backend communications you often see HTTP(S).

https://bank.com/banking?id=11223344

Yes, these things are seen in the wild… see Citi bank as an example.

Seen in the wild:

• ID’s and Account numbers in the URL
• Base64 encoded IDs and Account numbers
• Encrypted strings in the URL
• Brute-Force the key to find the ID or Account Number

Depending at what phase the server-side validation takes place, this can bypass protections. If the bank only checks the details server-side at the first phase, and you alter the data in the validation phase taking place afterwards, you can bypass systems.

Negative Numbers

Surprisingly often overlooked. Simple code validation can fail. If it’s checking the balance is more than the transfer, then a negative amount will also pass this check.

Creating money out of thin air

Instead of transferring a minus amount to another user, how about transferring it to another account we own. If we use a savings account that cannot go into negative, then what happens in the background. If there is a logic failure then the negative transfer will create money in the initial account.

Bypassing Limit Checks

Code is written by people, and people make errors. If an attacker can transfer between 2 accounts, creating a massive minus in 1 account and a huge profit in another, the attacker can cash out one account and never repay the debt on the other.

HTTP Parameter Pollution

Example:

POST /transfer

source=1&dest=2&amount=100

Checks are then performed on this to validate the source is owned by the user and the amount is within limits.

HPP Example:

POST /transfer

source=1&dest=2&amount=100&source=42

If the backend is susceptible to HTTP Parameter Pollution then the second phase of the transfer may take the second provided source (dependent on the backend code)

SQL Injection

Banks almost always say SQL Injection won’t be possible on their systems… however they’re often found.

Forging Bank’s Digital Signatures

Banks are very enthusiastic about digital signatures for various reasons, including the legal validation of digitally signed transactions and agreements.

In a transaction the user signs an agreement and returns it to the bank server for them to counter sign. However, what if the contents on the agreement is altered at the client side (either textually or the values).

Server-Side Code Execution

Not a specific banking vulnerability. However just as effective.

Examples include:

• JAVA Code Execution (JBoss bug in 2010)
• PHP Code Injection
• Shell Argument Injection

Getting rich without breaking the law

Rounding and currency exchange

Normally you end up loosing money when exchanging currency. However what happens if your transfer results in less than 0,01 cent. In these cases it will often be rounded up to 0,01 and you will make money… not much, but some.

Example:

Convert €100 into $136,40

Convert $0.01 into €0.01 until your $ are all exchanged

You then have €136,40

Banks will notice this… 1000′s of transactions will trigger flags and they won’t be happy with you.

Countermeasure –> Don’t let users exchange less than €1

Getting away with it

Why should we care, we’re not bank robbers… but when the customer says “You’d never get away with it” you need to have an answer.

Avoiding Detection

In detecting these vulnerabilities they will make noise and risk detection. In testing attacks they may trigger alarms

Solution –> User in the middle (hiding behind a user)

Breaking the money trail

Transferring money from bank to bank is still traceable. Attackers need to actually get the physical money out

Solution –> Money mules, BitCoins, WebMoney

Perfect Crime: Print new money, don’t let anybody know

Nobody lost anything, so nobody to complain

Possible through some of the attacks shown earlier. Create fake transaction history

New Functionalities

New technologies are a great thing for banks, but also for attackers.

Increase in automated loans and stock trading open up banks to new attacks.

Links :

• How To Rob An Online Bank And Get Away With It –> Overview

Laurent ‘kabel’ Weber

Motivation

Until now it’s been really hard for security researchers to dig into GSM security topics. This has been slowly changing because of tools like the USRP. However there is no other tool available to perform these kind of security tests. Hence the research.

Structure of a GSM network

Scapy

Scapy is a powerful interactive packet manipulation program, using the Python interpreter as a basis. Scapy allows for new protocols to be simply added.

• Generate Packets
• Manipulate Packets
• Network Scanning
• Network Discovery
• Packet Sniffing

Philosophy

• Create smallest valid messages possible (Optional values are excluded)
• Optional Information Elements (IE)
• Optional fields
• Every possible message can be created
• Add IE’s by setting in code
• Scapy GSM-um allow us to:
• Create Layer 3 messages on a command line
• Send Layer 3 messages from BTS to MS
• And from MS to BTS
• Limited SMS support

Sending the message

Normally Scapy is able to send data directly out on the wire. This is not so easy with GSM.

• We need a method to send raw bytes to a device
• Added different sockets to Scapy:
• UDP socket (i.e USRP)
• TCP socket (i.e nanoBTS)
• Unix Domain Socket (i.e osmocomBB)
• Offers most flexibility and easy to use with your chosen hardware

Example message from testing phase

Performing a call

>>> sendum ( setupMobileOriginated() )
>>> sendum ( connectAcknowledge() )

< LIVE CALL DEMO >

Classical Attacks

Well known and documented attacks.

De-registration Spoofing

IMSI DETACH INDICATION message

Most of the payload is already set in the specification, so there is no need (outside of fuzzing) to set these details. The only bytes needed are the mobile identity.

Sending this will result in the mobile being targeted being de-registered from the network. The mobile will still show as connected, but will not receive calls/texts and any active calls are disconnected.

Authentication reject attack

Disconnects the targeted mobile form the network. The user will receive a “SIM card registration failed” message and will need to restart to connect to a GSM network.

< LIVE AUTHENTICATION REJECT ATTACK DEMO >

Novel Attacks

Attacks never done before on the GSM network. Attacks may be known, but not specifically applied to GSM.

State-machines in GSM

Available in the specification (04.08 sect. 5.1 for MS side)

Test the correct behaviour of the implementation by sending the correct messages but in the incorrect order

Call Clearing (work in progress)

Used to signal that one party on the conversation has hung-up

Idea: Make the remote end believe that you’ve hung-up

Goal: Maintain a connection although the second party things the line is inactive (eavesdropping)

Test cases to achieve this were built from valid packets, but it was not possible to achieve the desired effect

There are more possible novel attacks that look promising

Source code

Now merged into Scapy

hg clone http://hg.secdev.org/scapy my-scap

Links :

• Extending Scapy by a GSM Air Interface –> Overview
• Scapy GSM-um how-to–> Link
• Extending Scapy by a GSM Air Interface Whitepaper –> PDF
• Extending Scapy by a GSM Air Interface Slides –> PDF
• Laurent ‘kabel’ Weber Twitter Feed –> Link