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

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

Tag Archives: sap

Hashdays 2011

I wasn’t lucky enough to make it to last years Hashdays conference, so I was both humbled and ecstatic to be selected to speak at the second edition taking place this past weekend. As this was my first time presenting at a “big time” security conference, it was both exciting and scary at the same time. Luckily enough I had a good group of friends supporting me and giving me encouragement. In the end I think it went well… I’d done my homework, i’d spent more time than I should have on the slides, and I even had a suit so the SAP types would listen up 😉

I’m not sure at the moment when the videos from the conference will be made available, but until then i’ve uploaded my slides to Slideshare (with a few minor import issues). If you were at the presentation, please let me know what you thought of it. There’s always room for improvement, and I want to know where I can change for the better. I’ve already had some great feedback on some minor changes to clear up some confusions… so the SecZone version of the talk will be even better I’m sure!

SAP (in)security: Scrubbing SAP clean with SOAP

SAP OSExecute… not the buffer overflow you’re looking for!

So, it’s been a busy day already… and just as I’m about to get things under control a friend links me to a post on SecurityFocus discussing this new vulnerability in SAP Management Console. Imagine my surprise when I read about this new OSExecute exploit! So, before the proverbial sh*t hits the fan, here’s a few details they might have got mixed up a little.

Note: It’s simple to mix-up the details of this exploit, as it uses features of Metasploit outside of the linked module. Without knowing the underlying functions of Metasploit you’d be hard pressed to figure out it wasn’t sending shellcode as part of the exploit.

tldr: It’s abuse of functionality, not an exploit. No shellcode is deployed, no DoS if anything fails… oh and you need a valid username/password

– Info –

Remote Code Execution

Yes and No…

Remote, yes. It’s a service that listens on a TCP port, so by definition it must be remote.

Code Execution, yes and no. If you class Code Exec as “I can run a command” then yes… shellcode, no! If you add to that the fact that you need to have a valid administrative username/password, then your exploit turns from a bug into a feature. At least that’s what SAP PSRT indicated when I spoke to them about this bug (and provided a POC) around 5 months back (final communication May 26th 2011).

… OSExecute provides just another, platform-independent access path to submit OS commands for the authenticatedadm user. Using this access path, this user cannot do anything more than it couldn’t do at operating system level directly using direct shell access.

– SAP PSRT (Product Security Response Team)

Aside from the issue of bypassing possible application logging and local access restrictions (where a user with OSExecute permissions is, for example, blocked from SSH or RDP access) this issue is not the end of the world!

Failure to Handle Exceptional Conditions

Nope… it does exactly what it says on the tin. You send a well-formed and authenticated request and it performs the action… nothing exceptional here!

– Discussion –

“Attackers can exploit this issue to execute arbitrary code within the context of the affected application. Successful exploits will compromise the affected application and possibly the underlying computer. Failed exploit attempts will result in a denial-of-service condition”

Context of the application… no. Context of the user who’s password you’ve provided. Failed exploits will not cause a denial-of-service. Unless you can cause a DoS condition by running echo commands on a remote machine to form together the required portions of the Metasploit Payload. If you can, please let me (and Microsoft) know.

– Solution –

Currently, we are not aware of any vendor supplied patches.

This is partly true. SAP offered up a patch for the general SAP Management Console issue (mostly information exposure), however the patch resolves the issue by putting the information behind a username/password. As this exploit requires a valid username/password the patch they offered will not add any additional protections. Then again… remember this issue wasn’t considered a bug. Abuse of functionality is the phrase here I believe 😉

Last communication was that a possible restriction of the commands that could be run through OSExecute might be possible, but I’m sure this isn’t something that can/would be implemented quickly on a complex system like SAP.

– References –

… well, now you can add this blog post. Telling it like it is 😀

Oh and thanks for spelling my name right… you’d be surprised how often that gets screwed up!


  • Securityfocus BID 50348 –> HERE (may have already been edited to reflect changes)
  • Metasploit SAP Management Console Exploit –> HERE

Upcoming presentation: Hashdays

Time flies when you’re knee-deep in SAP internals it seems… after almost a year of really ripping into SAP Management Console Web Services I’m finally giving a presentation on the topic at the upcoming Hashdays conference in Lucerne, Switzerland.

The talk, entitled “SAP (in)security: Scrubbing SAP clean with SOAP” will cover some of my research on SAP Management Console to date, as well as releasing some new Metasploit modules and information on where my research is headed next year.

Believe it or not this will be my first time talking at a major security conference, so I hope the level of preparation I’ve put in will result in a passible talk… Somebody much smarter than me said “Crazy is a relative term in my family!”… which makes no sense in this context other than to prove that you never know what you’ll end up with when I’m involved!

The talk is currently planned for 11:20 13:10 on 29th October… just before after lunch. I look forward to seeing you there! come armed with questions, a thirst for knowledge, things to throw when you get restless and an acceptance that it could have been much worse, at least it’s not Gregory Evans talking about Cyber Bullying 😛 (Sorry couldn’t help myself)

hashdays security & risk conference

October 26th – 29th 2011

{BruCON} Attacking SAP’s J2EE Engine

Attacking SAP’s J2EE Engine

Alexander Polyakov and Dmitriy Chastuhin

Nowadays SAP NetWeaver platform is the most widespread platform for developing enterprise business applications. It’s becoming popular security topic but still not covered well.

This talk will be focused on one of the black holes called SAP J2EE engine. Some of the critical SAP products like SAP Portal, SAP Mobile, SAP XI and many other applications lay on J2EE engine which is apart from ABAP engine is less discussed but also critical.

  • SAP J2EE Architecture
  • Simple Attacks
  • Searching for EPIC hole round 1
  • Searching for EPIC hole round 2
  • Searching for EPIC hole round 3 – Crushing blow
  • Defense
  • Tool Demo
74% of the Forbes 500 companies run SAP. More than 120,000 customers

ABAP Engine:

  • Used for automation of business processes like ERP, PLM, CRM, SRM

J2EE engine: 

  • Integration, collaboration, and management
    • SAP Portal
    • SAP PI
    • SAP XI
    • SAP Mobile Infrastructure
    • SAP Solutions Manager

Too much concentration in ABAP security, while J2EE engine issues give as much if not more access and business impact.

J2EE Architecture

Access to J2EE using HTTP or the P4 protocol

Remote Control of SAP Systems

  • Visual Admin (Client/Server tool) –> http://server:port/useradmin
  • NWA (Web-based console)
  • J2EE Telnet (limited)
  • Declarative authentication
    • WEB-XML Based
  • Programmatic authentication
    • Directly against the User Management Engine (UME)

The issues covered will be based on declarative authentication.

WEB.XML is located in the WEB-INF directory of the application root

Access methods are based on permitted methods and locations of the application logic

User accounts can be stored in a number of places including Databases, LDAP or ABAP

By default most SAP protocols are unencrypted (meaning username:passwords can be sniffed)

Hacking Netweaver J2EE

P4 Protocol:

  • Used by Visual Administrator tool (port 50104)
  • Communication unencrypted
  • Password encrypted on logon
  • Tool available for decryption (from DSecRG)
Password is only masking and not a hash… changes with the length of the password
The key is static and potentially stored on the server. Value of encrypted password depends on the previous symbol
Code analysis shows that the mask value is predefined and is not much harder than a Caesar cipher.
When reported to SAP… they said just use SSL! To late to patch it…

Information disclosure bugs

Throw various direct URL access calls it’s possible to view version information, internal server details, and more.
By calling the BufferOverview JSP it’s possible to port scan internally and external systems through the SAP system.
/meSync/SatFileReceiver –> Username and Version disclosure (Mobile Engine 2.1)

Cross-Site Scripting

Variety of XSS flaws… not interesting… so many patched, so many not patched yet!

SMBRelay on SAP

A Windows vulnerability, but how can you use it in the context of SAP!


  • You can get shell with administrator rights
  • Server OS updates on SAP are rare
  • You can relay to another node of the cluster
  • You can relay from DEV to TST (usually the same password)
Patches from Microsoft are only affective for reflective attacks. By using another node you can bypass this protection.

CSRF + SMBrelay = CSSR

CSRF can be used to bypass protections that are now in place on MMR from SAP

CSRF Protection

SAP incorporates 2 methods of protection.

Find a place that doesn’t use session handling like an API or SOAP interface!

SPML is a good example. With the correct permissions you can add users, create/modify objects.

Attacking SPML

  • Create HTML that will perform an xmlhttprequest to SPML
  • Find an XSS in SAP
  • Wait for admin to click it
Can’t be made public… but SAP documents tell you how to do it! –> SAP Identity Manager

Invoker Servlet auth bypass

Published by SAP in their security recommendations

Restricted through the WEB.XML auth-constraints

However by using the invoker you can use a direct call

/servlet/com.sap.admin.Critical.Action –> Doesn’t match the /admin auth-constraint!

Verb Tampering

A pretty old vulnerability!

Security controls to prevent verb tampering are in place… but WEB.XML is too specific

Protections are implemented on the GET method alone, so just use HEAD! No restrictions

Depends on the backend code… if HEAD is accepted as a GET then everything will work fine. Any request where you don’t need to see the response (i.e. create user) will work.

Application dependent –> Example: SAP 6.40 has about 40 vulnerable applications included!

Searching for EPIC hole round 1

Possible to overwrite any file in the OS with trash values


Searching for EPIC hole round 2

Same vulnerability, but using the SMBRelay attack

Searching for EPIC hole round 3

Unauthorised group assignment

Secret interface for managing J2EE

  • No Documentation
  • Available from the internet
  • Most commands need username:password
By using this interface it’s possible to add any user to the system and then logon to the SAP Portal using the new credentials.
Second a second request adding this new user to the administrators group.
This vulnerability is now patched, but no exploit-code is available currently (3 month waiting period for patching)
This isn’t a single vulnerability but a whole class that could have a wide-reaching effect.
DSecRG have released WEB.XML checker to check for these possible vulnerabilities in SAP and custom applications
Checks for a variety of possible bugs including the verb tampering and invoker vulnerabilities

Links :