Lucene search

K
securityvulnsSecurityvulnsSECURITYVULNS:DOC:6145
HistoryApr 30, 2004 - 12:00 a.m.

Sambar security quest

2004-04-3000:00:00
vulners.com
64

This issue is old (originally discovered in January, 2003 published by
iDefense[1] and fixed by Vendor[2] in September, 2003) but still
interesting if you tired of endless crossite scriptings, buffer
overflows and SQL injections and would like to play security game.

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 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
    with any step of our quest we will not exploit security bug.

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 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&#39;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{&#39;REMOTE_ADDR&#39;};
    if &#40;!&#40;$host_test eq &#39;127.0.0.1&#39;&#41;&#41;
    {
            print &quot;Only localhost is allowed to use this script!&#92;n&quot;;
            exit&#40;1&#41;;
    }

We know, how to bypass it. It also checks all fields:

    if &#40;&#40;$server =~ /[;&gt;&lt;&&#92;*&#39;&#92;|]/ &#41; ||
        &#40;$from =~ /[;&gt;&lt;&&#92;*&#39;&#92;|]/ &#41; ||
        &#40;$subject =~ /[;&gt;&lt;&&#92;*&#39;&#92;|]/ &#41; ||
        &#40;$attach =~ /[;&gt;&lt;&&#92;*&#39;&#92;|]/ &#41; ||
        &#40;$to =~ /[;&gt;&lt;&&#92;*&#39;&#92;|]/ &#41;&#41;
    {
            print &quot;&lt;HTML&gt;&lt;TITLE&gt;Invalid fields&lt;/TITLE&gt;&lt;BODY&gt;&#92;n&quot;;
            print &quot;One or more the following fields have invalid characters:&lt;BR&gt;&#92;n&quot;;
            print &quot;&lt;I&gt;server&lt;/I&gt; &lt;I&gt;from&lt;/I&gt; &lt;I&gt;to&lt;/I&gt; &lt;I&gt;subject&lt;/I&gt; &lt;I&gt;attach&lt;/I&gt;&#92;n&quot;;
            print &quot;&lt;/BODY&gt;&lt;/HTML&gt;&#92;n&quot;;
            exit&#40;1&#41;;
    }

    if &#40;$attach =~ /&#40;[^&#92;.]+&#41;&#92;//&#41;
    {
            print &quot;&lt;HTML&gt;&lt;TITLE&gt;Invalid attachment path&lt;/TITLE&gt;&lt;BODY&gt;&#92;n&quot;;
            print &quot;An invalid attachment path was specified.&lt;BR&gt;&#92;n&quot;;
            print &quot;&lt;/BODY&gt;&lt;/HTML&gt;&#92;n&quot;;
            exit&#40;1&#41;;
    }

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. 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).

[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


http://www.security.nnov.ru
/\_/\
{ , . } |\
±-oQQo->{ ^ }<-----+ \
| ZARAZA U 3APA3A } You know my name - look up my number (The Beatles)
±------------o66o–+ /
|/