Computer Security
[EN] securityvulns.ru
no-pyccku

  

Related information

  Multiple bugs in Sambar

From:3APA3A <3APA3A_(at)_security.nnov.ru>
Date:30.04.2004
Subject:Sambar security quest


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

About | Terms of use | Privacy Policy
© SecurityVulns, 3APA3A, Vladimir Dubrovin
Nizhny Novgorod

 
 



Rating@Mail.ru