[Full-Disclosure] SECURITY.NNOV: Sambar security quest
From: 3APA3A (3APA3A_at_SECURITY.NNOV.RU)
Date: 04/30/04
- Previous message: OpenPKG: "[Full-Disclosure] [OpenPKG-SA-2004.018] OpenPKG Security Advisory (proftpd)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: full-disclosure@lists.netsys.com, bugtraq@securityfocus.com Date: Fri, 30 Apr 2004 16:36:20 +0400
This advisory is old (originally discovered in January, 2003 published
by iDefense[1] and fixed by Vendor[2] in September, 2003) but probably
is generally unknown, at least there is no CVE entries. It can interest
you, if you tired of endless crossite scriptings, buffer overflows and
SQL injections and would like to play with "logic bombs".
Intro:
Probably you heard about different "security games". Usually it's a set
of tasks you have to complete to win. I would like to offer you a same
security quest with only difference - it's from real life. Aim of this
quest is to get full control under host with Sambar Server 5.x (I
played with 5.2 but 5.3 should be fine. You can download it from [3]).
Sambar is HTTP Web and proxy server. If you think Sambar is yet another
lame one day living "web server" with directory traversals and buffer
overflows you're wrong. This application is developed by Tod Sambar for
long time, multiple problems were fixed and now it's widely used and
secure enough to get some pleasure playing with it. Length of HTTP
request and all HTTP headers are limited in size. Content-Length is
checked and limited. URL must contain only configurable set of
characters - otherwise request is ignored. Directory traversal is
checked before any web file is accessed. Type of the file is checked,
and there is no special DOS device access problem. All operations have
timeouts. HTTP proxy and multiple scripts in cgi-bin are only available
from 127.0.0.1. cgi-bin is stored aside of documents root. Passwords
are stored encrypted.
Quest:
Get remote control on Sambar server 5.x in default configuration with
random administrator's password under following conditions:
1. We should not debug or desassembly code (violation of copyright
laws)
2. We should not code any exploits ("no more public exploits"
initiative)
3. We should not use any information on security vulnerabilities,
because it's illegal in France. I known, it sounds strange, but
any of features described below are usually classified with "LOW" or
"NO" security risk.
Steps are:
1. Get access to proxy server.
2. Hide real IP from Web server using 1
3. Obtain passwords list from Web server using 2
4. Obtain administrator password using 3
5. Upload executable file as web document using 4
6. Execute file uploaded at step 5
Now, if you want to try this quest by yourself you should download
Sambar and stop reading this article. Of cause, there can be more than
one valid solutions.
Solution:
Step 1.
You can access proxy server.
Explanation: In default configuration proxy server is only accessible
from 127.0.0.1 address, but web server is available from Internet.
Both proxy and web requests are processed by the same engine on the
same port (TCP/80). We can use http keep-alive connections to bypass
Proxy server limitation:
TCP connection established
-> GET / HTTP/1.1
Connection: keep-alive
this is valid web server
request. It's granted.
<- Sambar default web page
because connection is
keep-alive it's not broken
after page is sent.
-> GET http://someexternalsite.org HTTP/1.1
this is valid proxy
requests. This time source
IP is not validated, because
connection was established
before
<- Web page from external site
Sambar proxies our request
Step 2.
We can access Web server on 127.0.0.1 address via proxy server.
Explanation: We can use proxy to access Web server on loopback
interface. Because in this case proxy server requests web page, web
server thinks peer address is 127.0.0.1.
Step 3.
User accessing Web server from 127.0.0.1 can download any (small)
file.
Explanation: there is formmail script called mailit.pl. This script
can send e-mail to given address with given subject, body and
attached file. Script is only available from localhost because of
this check:
$host_test = $ENV{'REMOTE_ADDR'};
if (!($host_test eq '127.0.0.1'))
{
print "Only localhost is allowed to use this script!\n";
exit(1);
}
We know, how to bypass it. It also checks all fields:
if (($server =~ /[;><&\*'\|]/ ) ||
($from =~ /[;><&\*'\|]/ ) ||
($subject =~ /[;><&\*'\|]/ ) ||
($attach =~ /[;><&\*'\|]/ ) ||
($to =~ /[;><&\*'\|]/ ))
{
print "<HTML><TITLE>Invalid fields</TITLE><BODY>\n";
print "One or more the following fields have invalid characters:<BR>\n";
print "<I>server</I> <I>from</I> <I>to</I> <I>subject</I> <I>attach</I>\n";
print "</BODY></HTML>\n";
exit(1);
}
if ($attach =~ /([^\.]+)\//)
{
print "<HTML><TITLE>Invalid attachment path</TITLE><BODY>\n";
print "An invalid attachment path was specified.<BR>\n";
print "</BODY></HTML>\n";
exit(1);
}
Later all arguments are used to construct command line executed with
system() call.
Attachment must be located within doc (Web documents) directory.
Directory traversal and pipes can not be used... In fact they can.
First, we can use absolute path because neither ':' nor '/' nor '\'
are filtered. Installation path can be discovered using information
leakage bug rediscovered by Gregory Le Bras... Well, it's not
interesting, we can find another way.
You should remember bright RFP's Phrack article, there must be
something he missed. He did. First, he missed "poisoned \n
character". Imagine echo hello\necho world... It's not our case.
Because it works for *nix, and we are under Windows. That's
_mmmmmain_ thing missed by nearly everyone who wrights about perl
security. Under Windows shell characters and shell itself is
different. In this case '%' character is not filtered, we can use
%QUERY_STRING% as a file name and send any name we want via URL like
mailit.pl?/path/to/file in a POST request.
Step 4.
Admin's password can be recovered from config\passwd file.
Explanation: Access to administration interface is limited to
127.0.0.1 (we know how to bypass this limitation) and default
admin's password is empty. Of cause, documentation recommends to set
strong password for admin account. Passwords are stored in
config\passwd file encrypted:
admin:root:2111DF241FF52D16:/docs/:2:0:System Administrator
sacrypt.exe is used to get crypted password. Block cypher with
statically compiled key is used for encryption. It means password can
be restored. By viewing sacrypt.exe in text viewer we can see
cm_twowayencrypt function imported from sambarcm.dll. After password
is encrypted, it's converted to hex with cm_bin2hex. Of cause, we can
debug Sambar, to find out that encryption is Blowfish and discover
key used, but it's not what we're going to do. Function for block
encryption and decryption are usually use same arguments. We can
change 2 bytes in sacrypt.exe (namely change cm_twowayencrypt to
cm_twowaydecrypt in import table) to make sacrypt.exe decoding
passwords instead of encoding. FAR has good editor, it doesn't
corrupt binary files. Now
1. Convert encoded password from hex to bin
2. decrypt it with modified sacrypt.exe
3. Convert decoded password from hex to bin
You can use notepad.exe and calc.exe
Step 5.
Administrator can upload files to Web document directory
In default configuration Administrator is allowed to use HTTP PUT
method to upload files to Web documents (\doc) directory from
127.0.0.1 address. Basic HTTP authentication can be used. (Hint: you
can use your favorite mail agent to construct base64-encoded HTTP
Authorization: field).
Step 6.
You can run executable file located in document root directory.
Explanation: Sambar supports template files with .stm extension.
<RCC> tag of Sambar allows to include result of external program
execution into web page. By default, program is executed from cgi-bin
directory, but we can specify something like <RCC../docs/myprog.exe>
to execute file located in Web documents directory. Myprog.exe is
executed upon request to stm file.
That's all.
Bonus:
One more funny bug.
If you have physical access to Sambar host you can compromise server
without loging in. Sounds exciting.
Explanation: Sambar always check a type of file to eliminate special
device access. But for perl scripts it uses external perl interpreter
(IndigoPerl 5.6) which doesn't. If you request
http://sambar/cgi-bin/com1.pl IndigoPerl reads Perl script from COM1:
port. If you have physical access to host and you can connect your
device to COM1 you can execute PERL script with permissions of SAMBAR
server (usually LocalSystem). This is a case "Special DOS device
access" bug leads to privilege escalation rather than to DoS.
References:
[1] Sambar Server Multiple Vulnerabilities
http://www.idefense.com/application/poi/display?id=103&type=vulnerabilities
[2] Sambar Server Security Alert
http://www.sambar.com/security.htm
[3] Sambar Server 5.3 download
http://www.rcrnet.net/sambar/sambar53p.exe
[4] Multiple bugs in Sambar
http://www.security.nnov.ru/dbadmin/edit.asp?binderid=3165
[5] Sambar Server all versions password decoding
http://www.security.nnov.ru/search/news.asp?binid=1361
-- http://www.security.nnov.ru /\_/\ { , . } |\ +--oQQo->{ ^ }<-----+ \ | ZARAZA U 3APA3A } You know my name - look up my number (The Beatles) +-------------o66o--+ / |/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
- Previous message: OpenPKG: "[Full-Disclosure] [OpenPKG-SA-2004.018] OpenPKG Security Advisory (proftpd)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
