Focus on: SAP MaxDB remote code execution

A very interesting vulnerability appeared a while ago on our marketplace and it's now time to give it the visibility it deserves.

Today we are in fact going to focus on a remote command execution vulnerability in SAP MaxDB (you can bid on it here).

The vulnerability has been triggered on Linux machines running SAP MaxDB version 7.6.00.37 (that's the lastest version) and 7.4.3.32, and on Windows machines running SAP MaxDB 7.6.00.37. Other versions may also be affected.

This vulnerability is also pretty easy to exploit: just send a specially crafted request, containining an arbitrary command, to the listening port of the vulnerable MaxDB service and that command will be executed with the credentials of the user running the process (usually 'sdb' on Linux).

Yes, you can figure that a database service is rarely open on the Internet, but in a LAN it's not-so-rare to find so this vulnerability is pefect in a variety of corporate pentesting scenarios.

As you know, SAP AG products run on the majority of intranets of the biggest companies all around the globe and all the products developed by SAP AG are focused on Enterprise Resource Planning (ERP).

Of course, every SAP applications that requires a Database service will use MaxDB RDBMS.

The situation can be really alarming if you sum all of the factors described above: easiness of exploitation + remote access + spread of the product + confidentiality of the data contained into the database. The result can be scary.

Once you can execute commands on a machine running MaxDB, with the credentials of the MaxDB user, it's very easy to dump the content of the whole database.

Together with the vuln you will also buy a fully working and reliable PoC.

Hopefully this post will be able to help both the companies running this vulnerable SAP product by rising their awarness and the security companies looking for better tools.

WabiSabiLabi Walkthrough

Hello folks, since we received a lot of questions about the whole marketplace procedure we'd like to point out some of our policies.

First thing, the researcher needs to sign up to our website: from this point on he can start submitting his work to the lab.

Please note that before selling anything, he'll be asked to fax or email his ID card details and a landline phone number, that we'll use to verify his identity.

We usually need full details about a vulnerability, so we might start a direct correspondence with the researcher, if necessary. Every communication is encrypted with PGP/GPG (here's our public key).

Once we get all the required details we can start testing the vulnerability.
Even if we are doing our best to speed up this part of the process it still requires some days: you can help us by sending as much information as you have about the vulnerability, i.e. debugger output, commented proof of concepts and step-by-step methods to trigger the vulnerability, in case it's a complicated vulnerability to exploit.

Despite our dedicated entry in our F.A.Q. page we are often asked which vulnerabilities we will accept or reject:

- all vulnerabilities related to network services, network clients, standalone clients, web applications and network devices are accepted and tested.

- we DO NOT accept vulnerabilities in specific websites, like for example eBay, Gmail, Hotmail, online casinos etc.

Once the vulnerability has been tested and accepted, we decide a starting price and a selling strategy together with the researcher, who will then receive our NDA. This must be returned signed, via fax or mail.

At this point we are ready to publish the vulnerability.

When the vulnerability is sold we will pay the researcher via paypal to his verified account or via wire transfer to his bank account.

If you want to be a bidder all you have to do is subscribe to our portal and provide the papers required to check and verify your identity. Please note that we only accept payments coming from a verified bank account in your name.

That's all.

Our purpose is raising awareness and reducing risk and contributing to the research of new vulnerabilities by both helping and protecting researchers and giving them appropriate compensation for their amazing work.

Quicktime zeroday vulnerability still zeroday

This morning we opened our favourite RSS reader and we found out a post about one of the vulnerabilities in our marketplace, the Quicktime client-side vulnerability.

As reported by Errata Security Blog, during the last few days some exploit codes for a Quicktime vulnerability have been posted.

What they say about one of the POC is:

"An interesting note is the most robust of the exploits makes a derogatory mention of WabiSabiLabi Labs, the exploit auction site. WabiSabiLabi has a QuickTime exploit for sale now that lists QuickTime 7.2 and Windows XP as the targets. You have to wonder if this is another case of a researcher using vague details to find the same vulnerability."

We just want to specify that the vulnerability shown on those POCs IS NOT the one present in our marketplace.

So, if you are interested in receiving some more details about the vulnerability we proposed don't hesitate to contact us and if you are interested in buying it, make a bid!