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

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

Tag Archives: deepsec

DEEPSEC: Your crown jewels online: Further Attacks to SAP Web Applications

Your crown jewels online: Further Attacks to SAP Web Applications

Mariano Nunez Di Croce

Introduction to SAP

Largest provider of business management solutions in the world

  • 140,000 implementations
  • > 90,000 customers
  • 120 countries
SAP runs the most critical business process of many companies –> Hence the crown jewels of a company
This talk covers threats to the core and standard SAP applications and doesn’t attempt to cover issues in custom designed applications.

What SAP Security used to be

Traditionally SAP security has come down to segregation of duties. This however offers a false sense of security. SoD are necessary, but are not nearly enough to secure systems of this complexity.
For somebody to exploit segregation of duties the attacker needs access to your SAP system, and a valid account. There are however many issues lower in the stack that could result in non-users exploiting SAP systems.
In 2011 so far, there have been around 700 SAP Security Notes released

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

ITS is prone to very helpful error messages. If you request a resource that doesn’t exist it responds with a lot of useful information.
ICM also exposes the SAP SID information and system numbers
Enterprise Portal provides HTML comments with useful information

Attacks to the ICM

Dangerous ICF Services

There are over 1500 standard ICF services on a typical SAP ECC install
When requesting a service the SAP system will check if it’s public or private.
Private services require authentication (this is the case for most services)

The Info Service

Public ICF service
/sap/public/info
Provides an XML SOAP response with lots of useful info

An explosive combination

Most services need authentication.
After authentication the SAP system checks for authorization to run the service
Issues:
  • As most services are not setup with an authorization value, these checks are not made
  • Standard SAP users are therefore a serious issue for SAP systems
  • Attacker can control the mandant remotely
Result:
  • The attacker has fair chances of accessing sensitive business functionality through the ICM server

SOAP RFC Service

The RFC protocol is used to call an ABAP function module
As RFC is blocked at the firewall this can’t be done directly.
The SOAP RFC Service offers the ability to perform this same call through an SOAP interface, bypassing the RFC block on the firewall
< LIVE DEMO >
Multiple function calls can be made include logging off all active users, spamming messages to all users, through to shell on the remote server…
Shell access involved injection commands into an RFC request.

Attacks to secured enterprise portals

Authentication is handled by the Java engine
Many organisation have Web Access Management solutions in place (such as SSO) to improve security or make it easier for corporate users.
There are various vendors offering the ability to integrate their solutions
This integration uses the Header Variables Login module
What happens in an attacker can connect directly to the portal? Can he pretend to the be the authentication proxy?
Attack:
  • Attacker removes the cookies from a request with no username/password
  • Adds a header called REMOTE_USER: Administrator (or any other desired user)
  • It just lets him in!
< LIVE DEMO >
Found and noted in 2006 on the SAP forums… not fixed!

SAPPortalShell

Enables post exploitation for SAP Portal (much like PHP, JSP, etc…)
In order to use it, he needs to gain admin access to the portal and deploy the shell in the same way you would with JMX, etc…

Further Attacks

  • Verb tampering attacks –> Work on SAP!
  • Invoker Servlet Detour attacks
  • Lots more unpatched things

Conclusions

  • Lots of SAP systems are online, even if owners think they’re not
  • Attackers chance of being caught are reduced a lot when the system is online
  • Many different kinds of web tech
  • Security of SAP getting better, slowly
  • Always use a reverse proxy in front of your SAP system if it HAS to be on the internet

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
Advertisements

DEEPSEC: Ground BeEF: Cutting, devouring and digesting the legs off a browser

Ground BeEF: Cutting, devouring and digesting the legs off a browser

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

– Exploits/JbossJmxUploadExploit
Takes advantage of the verb tampering issue in JMX console versions to send a HEAD request and perform unauthenticated actions on the remote JMX console.
Using the client system owned with BeEF through an XSS to perform this attack on internal systems. Use them as a pivot point.
Video of the attack –> YouTube

Achieving persistence

Once a user browsers away we lose the JavaScript injection!
2 ways to avoid this :
  • Create a 100% iFrame containing the real page
    • Second module also allows key logging in the iFrame
    • Frame Busting breaks this
  • Man in the Browser
    • CORS abuse (HTML5)
      • history.push
      • window.open

Module Autorun

Ported into the new version from the older PHP version
Add autorun: true in the command module config.yaml to autorun modules on hooking
Imagine autorun with Metasploit autopwn!

Tunneling Proxy

Once you’ve hooked a browser, you can use the tunneling proxy function to route requests through the hooked browser.
  • Receive requests as a proxy on BeEF
  • Translate these requests to XHRs (in-domain) and execute them in the hooked browser
  • Parse XHRs responses and send the data back through the proxy
Works like a charm on same-domain… needs to be extended further (plans are to port malaRIA to BeEF for cross-domain resources using Flash liberal cross-domain policies)
To activate the proxy, right-click a hooked host and select proxy through
< DEMO OF BeEF HOOKING THROUGH REFLECTIVE XSS >
Video of the Tunneling proxy –> YouTube

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

  • Optimisation for performance
  • Obfuscation, polymorphism and URL randomization
  • Improve XSSRAYS
  • Improve BeEF console
We want YOU! If you want to help develop BeEF get in touch!

Links :

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

DEEPSEC: How To Rob An Online Bank (and get away with it)

How To Rob An Online Bank (and Get Away With It)

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
How can this be used to transfer money from somebody else’s account…
Edited request –> https://bank.com/transfer?src=3&dst=2&amount=100

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

DEEPSEC: Extending Scapy by a GSM Air Interface

Extending Scapy by a GSM Air Interface and Validating the Implementation Using Novel Attacks

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

After testing messages using Scapy GSM-um and Wireshark, it was time to make 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