Month: September 2022

When you get the chance to take a look at the IT systems of financial institutions, telcos, and other big companies, where availability has been a key business concern for decades, you’ll find, that some critical operations run through some obscure systems, in many cases accessed via nostalgic green-on-black terminals, the intricacies of which only a few people inside the company truly know. These systems might be IBM i’s – or as many senior folks know, “AS/400” or “iSeries” – that served through the stormy times of IT since the 1980s!

Recognizing, that these systems are here to stay, and that information critical to understanding their security architecture is scarce and sometimes inaccurate, we decided to create our own IBM i lab, that allowed us to familiarize ourselves with these systems, create new methodologies and tools to assess their security, and even to identify previously unknown vulnerabilities in them.

This blog post is the first step of publishing our findings to the security community, where I would like to share a walkthrough of the penetration testing result of an IBM i system.  The presented techniques stem from misconfigurations common on this platform – this post only covers one privilege escalation path, but the comprehensive configuration audit of the same system uncovered several local and even remote vulnerabilities.

For the penetration testing the Client provided network access to the machine in the internal network, one low-level user account with special authority *NONE and limit capabilities value set to *PARTIAL. The user had an initial program configured after logging in on TLS wrapped TN5250, so direct CL command execution was not possible.

Initial Program Breakout

Native programs of IBM i are commonly accessed remotely on a telnet-like protocol, called TN5250. However, instead of providing raw shell access, TN5250 usually displays menu-based user interfaces (the “green screen”). While the default menu allows access to the Command Language (CL) prompt (the “shell”), this can be replaced by configuring custom initial programs for users, that provide only limited features, such as executing predefined database queries.

The first task was trying to break out of the initial program limitation. After enumerating all the application menus, it became apparent, that there is no potential to run CL commands. Fortunately, the 5250 terminals and thus the TN5250 protocol supports an extended keyboard layout, allowing to trigger special menus by sending special key events, even when they are not available from the user interface of the initial program:

The attention interrupt key (ATTN) allows the authenticated user to interrupt/end a process and display a menu with additional functions:

This new menu has multiple options, including CL command execution, but one can just simply press F9 to bring up the command line:

From this point, the test user is no longer restricted to the functions of the initial program but can execute arbitrary commands (with its own privileges) on the operating system. The administrators can override the default behavior of the ATTN key by modifying the User Profile.

Privilege Escalation by Profile Swapping

Information gathering about the accessible user profiles (WRKUSRPRF) exposes, that one of the profiles has the following special authority:

User Profiles are objects that represent users of the system. Special Authorities are system-wide roles that can be assigned to user profiles. The *ALLOBJ Special Authority “essentially gives a user access to all functions on the system”. Throughout the available documentation the word “authority” is used to describe several different concepts, like roles granted for users, object access permissions or access control entries – in this post we try to resolve ambiguity by providing more expressive synonyms.

The “WRKOBJ M<REDACTED> *USRPRF” command shows, that the target User Profile authority is *USE to *PUBLIC.

On IBM i all objects – including User Profiles – have an associated list of access controls entries. In the above example, the *USE authority (permission) is provided for the *PUBLIC subject – this special entry serves as a fallback when the accessing user doesn’t match any other access control entry. The *USE authority allows impersonation of the User Profile, in this case for all authenticated users of the system.

This means, that because of weak object configuration we can impersonate this user and run CL commands with *ALLOBJ authority. The current system security level is 40 in this case we can do at least two things:

Submit a new Job – The SBMJOB command allows specifying a User Profile with which a new Job (a command scheduled for execution) should be submitted. This will succeed if the submitting user has *USE authority over the specified User Profile, just like in our case. Use the IBM i API from a program to associate a new User Profile to our session – We can use the Get Profile Handle API to obtain a handle to a usable (as in *USE permission) User Profile, then invoke the Set Profile Handle API with the handle to make the current thread execute under the new User Profile.

The SBMJOB command is not ideal, because it is not interactive enough, therefore we invoke the IBM i API from a CL script similar to the following to escalate the privileges:

PGM PARM(&U)
DCL VAR(&U) TYPE(*CHAR) LEN(10)
DCL VAR(&E) TYPE(*CHAR) LEN(4)
DCL VAR(&H) TYPE(*CHAR) LEN(10)
CHGVAR VAR(%BIN(&E)) VALUE(0)
CALL PGM(QSYGETPH) PARM(&U)
CHGVAR VAR(%BIN(&E)) VALUE(0)
CALL PGM(QWTSETP)
ENDPGM
** The script is intentionally wrong **

Compilation is done by the STRPDM (Start the Programming Development Manager – the built-in development environment of IBM i) command and the resulting PGM (program object) expects a parameter, the name of the User Profile to impersonate:

CALL PENTEST/PRIVESC M<REDACTED>

Due to the complexity of IBM i privilege management, similar misconfigurations are common, especially on systems with a high number of users. While discovering an exploitable path was sufficient to progress towards project goals, it is important to uncover similar vulnerabilities in the system via configuration review. For this, we developed a tool that can – among other things – assist experts in identifying misconfigurations, that could allow profile swapping to higher privileges for all User Profiles (running in our lab on the screenshots):

Automated assistance to identify extensive object authorities
Finding as part of a comprehensive audit report

At this point, the test user has obtained *ALLOBJ Special Authority, but we still can not modify our User Profile to persist our new privileges, because even with *ALLOBJ Special Authority one “cannot directly perform operations that require another special authority”, and for User Profile modification *SECADM Special Authority is required.

Becoming Security Administrator

At this point, our user already has high privileges thanks to the *ALLOBJ Special Authority, so we don’t cross security boundaries here. However, further escalation steps like this are sometimes necessary to bypass controls – similarly to how UAC bypass is sometimes necessary in Windows environments.

As there were more than 2000 users in the system we used SQL to find candidates for further privilege escalation.

The following CL command queries the system users for basic information:

DSPUSRPRF USRPRF(*ALL) TYPE(*BASIC) OUTPUT(*OUTFILE) OUTFILE(PENTEST/USERDB)

A simple SQL query in the STRSQL command reveals the potential candidates:

And the result:

With the already obtained *ALLOBJ privilege, we can execute the privilege escalation script again (“CALL PENTEST/PRIVESC USERWITHSECADM“) to grant our test user *SECADM authority. The goal has been reached.

Beyond the Green Screen

One of the challenges of securing IBM i systems is that the high integration of features provides access to the same attack surface through different interfaces, all of which need individual protections.

During this project, the remote services which are typically used to run CL commands were protected by exit programs (and in the case of the green screen, an initial program) that denied access with the test user. The administrators were probably not aware that the DDM service was also reachable on the system, and that it also allows command execution.

Distributed Data Management (DDM) is a service of IBM i that allows transparent access to data stored across multiple different systems.

Exit programs are special programs that can be registered to “hook” the built-in authentication process to provide additional security controls.

Our IBM i audit/pentest framework helps to run CL commands over multiple remotely accessible services. The following screenshot demonstrates command execution over DDM in our test environment:

Running the WRKOBJ USERB1/TESTCMD command over TN5250 confirms the successful execution of the command sent over DDM:

Being able to remotely execute commands over a variety of protocols allows bypassing security checks, and automation, which would be cumbersome over TN5250. In this case, we could become Security Administrator even if the green screen wasn’t available or the initial program breakout wasn’t possible.

Summary

This little case study shows, that while approaching IBM i systems requires learning the unusual ways of the platform, these systems are affected by really similar misconfigurations as our more common targets – in the end, all systems are programmed and configured by humans, usually under pressure to “just make it work”. In an environment where security visibility is severely limited, we believe it’s especially important to support the identification of mistakes, by proper guidance and tooling. Stay tuned for our next publications on IBM i!

A couple weeks ago we talked about in-app browsers, and the potential privacy issues when opening content in them. This week Microsoft reveals the other side of that security coin — JavaScript on a visited website may be able to interact with the JS embedded in the app browser. The vulnerability chain starts with a link handler published to Android, where any https://m.tiktok[.]com/redirect links automatically open in the TikTok app. The problem here is that this does trigger a redirect, and app-internal deeplinks aren’t filtered out. One of these internal schemes has the effect of loading an arbitrary page in the app webview, and while there is a filter that should prevent loading untrusted hosts, it can be bypassed with a pair of arguments included in the URI call.

Once an arbitrary page is loaded, the biggest problem shows up. The JavaScript that runs in the app browser exposes 70+ methods to JS running on the page. If this is untrusted code, it gives away the figurative keys to the kingdom, as an auth token can be accessed for the current user. Account modification, private video access, and video upload are all accessible. Thankfully the problem was fixed back in March, less than a month after private disclosure. Still, a one-click account hijack is nothing to sneeze at. Thankfully this one didn’t escape from the lab before it was fixed.

UPnP Strikes Again

It’s not an exaggeration to say that Universal Plug and Play (UPnP) may have been the most dangerous feature to be included in routers with the possible exception of open-by-default WiFi. QNAP has issued yet another advisory of ransomware targeting their devices, and once again UPnP is the culprit. Photo Station is the vulnerable app, and it has to be exposed to the internet to get pwned. And what does UPnP do? Exposes apps to the internet without user interaction. And QNAP, in their efforts to make their NAS products more usable, included UPnP support, maybe by default on some models. If you have a QNAP device (or even if you don’t), make sure UPnP is disabled on your router, turn off all port forwarding unless you’re absolutely sure you know what you’re doing, and use Wireguard for remote access.

Retro Hacking — The IBM AS/400

Viola Levan, CC BY-SA 4.0 , via Wikimedia Commons

If you have a craving for some throwback hacking, then [pz] from Silent Signal has you covered. While you don’t see IBM AS/400 front-ends in stores as often as you used to, these venerable machines still run the back-end of plenty of businesses. The IBM AS/400 was the solution to IBM’s problem in the early 80s, of too many similar product lines. It replaced the System/36 and System/38 products, and was based on an effort to port System/36 software to system/38 hardware. The new solution used Technology Independent Machine Interface (TIMI) as an intermediary layer that compiled programs targeted. The actual OS did a run-time translation to the machine code of the physical processor, which is how IBM has managed to keep such old software running for so long. It’s similar to what Sun was trying to do with Java, though with very different modern-day results.

The researchers at Silent Signal see an untapped wealth of research in the IBM AS/400, now officially called IBM i. Lots of code running on these systems was written in the late 80s and 90s, with much of it getting Y2k fixes — and likely untouched since then. The state of computer security research was quite different then, so there are likely to be issues to find. To this end, they’ve set up a dedicated IBM i lab, and have some findings to share. In a penetration test against a live customer, they were given access to an emulated TN5250 terminal, and a limited-privilege account. TN5250 turned out to be the foot in the door, as the IBM-specific terminal protocol supports extended keys like Attn, which works as a system interrupt key. The menu that’s triggered has a nifty feature, opening a shell as the logged-in user. A subtle misconfiguration allows running commands as other users with additional privileges. This exact penetration test didn’t use vulnerabilities in IBM code, just system misconfiguration — but as the pool of system administrators that really understand this legacy tech shrinks, this is likely to become a common issue.

The 8,729 day old CVE

Speaking of legacy code-bases… It’s always a bit startling to see how old some of the code is in our modern machines. Curl had its 4.0 release in 1998, and before that it was called urlget. There’s code written back then that’s still around in the project, and it turns out at least one vulnerability  Sort of.

Cookies are little bits of data that web pages can store on you machine, and thanks to an well-intended-but-terrible law, something that bugs you for every new website you visit. The history of cookies is a bit convoluted, as it was always an ad-hoc solution without a formal design or specification. As a result, we see some odd behavior even today, like the fact that a subdomain can set a cookie for the parent domain, and that other subdomains will see that cookie. So http://www.hackaday.com can set a cookie with domain=hackaday.com. Then if you visit someothersubdomain.hackaday.com, that cookie gets sent with the request.

Web servers have been around just as long, but have been forced to ratchet down their security posture. One of those security enhancements is to reject any HTTP requests that contain control codes, like 0x07, the ASCII bell. Cookies have no inherent ban on these values. Put those together, and you get a denial of service vulnerability. A subdomain can set a cookie containing a control code, assigned to the target domain, and that cookie gets sent in any future requests. And those requests get dropped because of the trapped cookie. The cookie-handling code was added in late 1998, and this trick has worked ever since. Except, browsers added the control-code check in 2016. It must be a quantum effect, resulting in a bug that is nearly 24 years old, and merely 6 years old, both at the same time. Either way, 7.85.0 fixes the problem.

Rusty Tor

The Tor project has a shiny rusty new release — Arti, a Tor implementation in Rust. This started as a pet project by [Nick Mathewson], but within a few months he had a code-base that could actually connect to the Tor network, and soon after was actually sending properly anonymized traffic. And a week ago today, version 1.0.0 was released, marking the project ready for prime time.

There are a few things missing, like the censorship avoidance capability — the plugins that disguise Tor traffic as something else. On the other hand, Arti is being used as an opportunity to make some changes and updates to Tor, like the introduction of a proper API. It looks like the eventual plan is to deprecate the C implementation, but there’s quite a bit of work left on Arti before it reaches complete feature parity.

EFF Enters the Fog

The EFF is taking aim at Fog Data Science, a company that purchases “anonymized” location data from mobile app vendors, and then sells a service to law enforcement that allows searching for individuals among that data. Researchers at the EFF pulled off a brilliant bit of detective work, reverse engineering the Fog Reveal search engine, while never actually having access to the interface. The trick is to visit the Fog Reveal web app, and grabbing all the JavaScript libraries that load on site visit. The app requires an account to use, but all the code that runs in the browser is available without that login. EFF took on the non trivial task of reverse engineering the data expected by the front-end, but in the end it gave them a detailed look.

The results are impressive, and worrying. A subscriber can select an area, give a date and time, and get a list of devices that were in that area at the time. The data is anonymized — but you can then select a data stream and follow the user home. Not so anonymous when you can trivially find a home address. On one hand I’m sure this comes in very handy when trying to round up a list of suspects for a crime, but it seems precariously close to what one might consider an unreasonable search or seizure of data.