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

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!

Links:

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