Sambar security quest

2004-04-30T00:00:00
ID SECURITYVULNS:DOC:6145
Type securityvulns
Reporter Securityvulns
Modified 2004-04-30T00:00:00

Description

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--+ / |/