I was engaged to perform a mainframe penetration test recently. What is a mainframe? Mainframes are high-performance computers with large memory (RAM) and processors that process billions of simple calculations and transactions in real-time.
I had been led to believe that mainframes were out of date machines. However, that is not the case, IBM just announced details about the latest z15 microprocessor utilized by IBM Z mainframes. Mainframes are still utilized by 70%+ of the Fortune 500 companies to perform core business functions with a 99.999% up time.
For this specific test I was teamed up with Chad Rikansrud (Big Endian Smalls). Chad handled the z/OS and I worked focused on the network side of things.
Referring back to the title of this post “0-Day In A Multi-Million Dollar Machine” – A zero-day (also known as 0-day) vulnerability is a computer-software vulnerability that is unknown to, or unaddressed by, those who should be interested in mitigating the vulnerability. This is the first time I have discovered something I believe to be a true 0-day in a piece of equipment that is utilized by so many people.
During this test we were able to gain access to a mainframe user ID and password that granted us access to the IBM z/OS Management Facility web application. (See below)
Utilizing my knowledge of performing web application tests, I started a deep dive into the application. I began by mapping out the application functionality utilizing Portswigger’s Burp Suite. As I was walking through the application, I highlighted specific functionality that looked interesting.
I discovered an area within the application that allowed viewing the “Topology by Sysplex”. The created photo had an export functionality. This functionality made a POST request of the image content to the server then performed a GET request to download the image.
Here are some screenshots of that process occurring –
HTTP POST request: (Containing the image content):
HTTP Response: (Containing the filename of the image to download):
HTTP GET request: (Downloading the image file):
HTTP response: (File downloaded):
At first, I was trying to utilize the initial HTTP POST request to save files on the system then moved to the file download process. Utilizing our intercepting proxy, Burp Suite, I was able to modify the HTTP GET request to change directories and point to a file on the local z/OS filesystem. (Having access to the local filesystem we determined that the image files were being saved in /tmp. This only required us to go back one directory before specifying the full file path. The z/OS would error out if more than one set of “../” was utilized.)
Modified HTTP GET request: (Attempting to retrieve a cacerts file):
HTTP response containing the file contents:
Now depending on the user account that was utilized to start the z/OS Management Facility there is the possibility of being able to retrieve sensitive files from user directories (if you know the exact path / name of the file) to other system log files. However, in this specific instance the user account was lower privileged.
After the discovery of the Local File Inclusion, I wanted to see if this exploit could be performed without authentication. Turns out an attacker can perform this request to the z/OS Management Facility without authentication.
HTTP GET request: (No authentication performed – attempting to retrieve a cacerts file):
HTTP response containing the file contents:
(Bare minimum needed to perform the request)
GET /zosmf/IzuUICommon/filesave/../usr/lpp/java/J8.0_64/lib/security/cacerts HTTP/1.1
Host: <IP-ADDRESS>:10443
Referer: https://<IP-ADDRESS>:10443/zosmf
The issue was immediately disclosed to IBM as seen from the timeline below:
Disclosed to IBM: 9/16/19
Verified valid vulnerability by IBM: 9/17/19
Patch Issued: 11/26/19
Issue remediation verified: 12/5/19
The best route currently for applying the patch would be to reach out directly to IBM to coordinate installation to ensure effectiveness in remediating this issue.