Can Db2 for z/OS be hacked?

Introduction

Can Db2 be hacked? Yes, sure it can. This answer could conclude the article, but as always, there is more. Yes, Db2 can be hacked, but if not properly secured!

Let's explore some easy opportunities, or lowest hanging fruits, that the hackers can use to break into your system. Learning these techniques will help you to make your system more secure.

Let's start with a definition of what I mean by hacking Db2. I am considering the following cases:

1. Escalate privileges of a user to higher privileges. This can then imply other actions.
   
   
2. Obtain access to data that a user normally cannot access. This can be read only (SELECT) or even other DML (INSERT, UPDATE, DELETE). In these cases the data access can be via Db2 itself or even outside of it. I also consider remote access that can be hacked.
   
   
3. Break or otherwise harm the entire Db2 subsystem, such as bring it down.

Examples of hacks

Escalate the privileges

Assume you are a regular user with a limited access, for example let's assume you just have a SELECT privilege on certain tables. What if you were able to escalate your privileges to let's say SYSADM? That would really give you a great super power! Is there any way to achieve this? Sure, there is. One of the easiest way has two requirements:

1. You have at least an UPDATE access to any APF authorized library.
2. You know your existing installation SYSADM user name (and you don't need to know the password).

Assumption 1 should be a no-go in all sites, but unfortunately is not always true. If a hacker is able to find a single unprotected APF authorized library, your system is basically doomed. Admins and sysprogs usually know this fact, but not always know what can happen. Also, do not feel safe if all your APF authorized libraries are safe, there are some ways around as well. Will elaborate on that a bit later. For now, let's assume you have at least one unprotected APF authorized library.

The second assumption is usually not a problem. People in your organization know who your installation SYSADM is. Or you can check the zParms. There are tools for that, or perhaps you will even find the compile job for zParms.

The rest is straightforward if you have hacking skills, understand a bit of assembly programming, and know how Db2 attachment facilities work. With this knowledge, you can write a JCL with the following steps:

1. Compile and link a program into the updatable APF library that does the following:
   • switches to supervisor mode with key zero
   • modifies the address space authorization ID from your user ID to the installation SYSADM user ID.
   • switches back to normal
2. Execute DSNTIAD with a single GRANT SYSADM TO your-user-id

You are ready to go with SYSADM privilege. What has just happened? After we modified the user ID of the address space (and we need APF authorization for that), the job runs under the identity of the installation SYSADM user ID. In the second step this user ID grants the SYSADM access to the user of choice. It uses the fact, that DSNTIAD uses TSO Attachment Facility under the hood, which uses the address space user ID as the default authorization ID.

With SYSADM authorization, you can really do many things from accessing or modifying the data, to harming the system. Sure, if your site uses an external security to manage Db2, the situation is a bit different, but still the hacker can grant himself a special privilege and grant any access he needs. Don't feel safer just because you have external security.

Accessing data outside of Db2

Hackers do not need to connect to Db2 if they want to steal sensitive data. Db2 data reside in data sets in a form of table spaces, index spaces, or Db2 logs. If these data sets are not protected, they can be subject to a data breach. However, even if you have them all secured and the access is granted only via Db2 DML, data sets can still be exposed.

This example works with the same assumption as the prior one - having an update access to an APF authorized library. Again, if a hacker finds such a library, he or she can write a short program that modifies certain system control block, which allow him/her to access the Db2 data sets even without explicit privileges. The hacker can then use DSN1PRNT, DSN1COPY, DSN1LOGP, or just IDCAMS or ADRDSSU to extract or copy the data.

Remote attacks

These days, remote attacks might be more common. Moreover, there are certain types of attacks that work cross-platform, so the hacker does not even need to care that the underlying database management system is Db2 for z/OS. One such example is SQL injection.

Imagine you have a COBOL application that constructs a dynamic SQL based on the user inputs from the ISPF application. Now this application can be opened to REST API and if it does not perform proper sanity checking that may have been done in the past on the ISPF site, the SQL may expose more data than intended.

Example:

This SQL is supposed to list all the employees that have the user specified first name. Now, if the attacker sends the following string as the first name: "Emil' OR ''='" then the WHERE clause will be constructed as WHERE FIRSTNME = 'Emil' OR ''=''. If you think about it, it is basically always true, which means the query will list ALL employees!

In order to prevent such attacks, you may rather use host variables, and always do proper sanity checks to validate the proper inputs. There are tools even for COBOL applications.

Don't forget about securing your DDF, that would be a big topic on its own!

APF authorization and other attack vectors

In my first two examples, I used an unprotected APF authorized library as the major attack vector. Please keep in mind that APF is essentially an extension of the operating system and that an authorized program can do virtually anything. Learn more here.

Hence, unprotected APF is the simplest attack vector and easy to use. Unfortunately, it is not the only vector that attackers may use. I mentioned DDF for the remote attacks, but there are some more vectors even for local attacks:

• Magic SVC - these are usually homegrown or vendor SVCs that can authorize non-authorized users without proper checking. If a hacker discovers anything like that on your system, he can use the examples 1 and 2 even without having access to an APF authorized library
• if a user does not have access to an APF authorized library, maybe he has a privilege (SURROGAT) to submit a job on behalf of a different user that has the update access. In such a case, the hacker can use the very same technique, just submitting on behalf of a different user (USER= in the JOB card)
• FTP is still commonly used to transfer data back and forth to the mainframe. Are you using secure FTP or everything is still in a clear text? This question applies to other network protocols as well.
• USS. Often overlooked, but with many possibilities. For instance, the APF authorization. It works a bit differently on USS, but if not secured, the bad user can act as with unprotected APF authorized data sets.

This is definitely not a full list, there are many other possibilities. The link provided in the next section, should provide you with some hints.

Prevention

The prevention is simple in words, but challenging to implement. Basically, you need to have your system secured. From the APF authorized libraries to DDF, from local to remote. You should also audit access to Db2, regularly check for authorized users, and if they still need the privileges.

Db2 13 CIS benchmark is a great start where to look. I would highlight the following items from the report:

• Protect Db2 system datasets
• physical table spaces, logs, BSDS, SDSNLOAD, SDSNEXIT
• Protect the subsystem access
• Recommended zParms setting
• AUTHEXIT_CACHEREFRESH = ALL
• AUTH = YES
• EXTSEC = NO
• SEPARATE_SECURITY=YES
• TCPALVER = SERVER_ENCRYPT
• Secure remote connections
• Use SSL, MFA,
• Restrict access to catalog tables

If you go through the recommendations, you can be sure that your installation is very secure.

Conclusion and other references

I did not provide the assembler samples to escalate the privileges on purpose, as they would need more deep explanation anyway. However, if you are interested, please let me know (only if you have good intents) or look at my session I presented at IDUG EMEA 2023 in Prague.

I am also referring to other IDUG sessions that I found useful in my research:

• NA22B14 - In the world of Ransomware Protecting your Db2 for z/OS Assets is Vital, Bob Tilkes, IBM
• NA22B13 - Secure your Db2 for z/OS access with Multi-factor Authentication, Gayathiri (Gaya) Chandran, Derek Tempongko, IBM
• NA22G16 - Db2 Security Best Practices, David Beulke, Dave Beulke and Associates
• EU22G01 - Db2 for z/OS Security – An Introduction, Gayathiri (Gaya) Chandran, IBM
• EU22E10 - SQL Injection and Db2 Pathology and Prevention, Petr Plavjaník, Broadcom
• EU22B17 - Security and Compliance With Db2 13 for z/OS, Gayathiri (Gaya) Chandran, IBM
• EU21G07 - Are you security aware?, Jan Marek, Broadcom

I hope that this article gave you some thoughts and starting points about making your Db2 secured. Stay tuned for the next article that will provide you with more guidance.