Operator Jail breakout

In 2018, I gave a presentation at the CS3STHLM conference together with Frank Lycops on Operator Jail breakouts.

Operator Jails are meant to prevent process operators from having access to the underlying operating system (OS), so all access to the OS not required for the daily task is shielded from them … or at least that is the intent. Most operator applications almost always run in full screen mode. Examples of such applications are ATM systems, HMI systems, kiosk pc’s …

Despite all the efforts to prevent that kind of access, there are still possibilities left and right that allow you to break out of these operator jails and thus accessing the operating system.

Why does this matter? Why would I care?

During (long) night shifts, operators might (or better do) get bored you know … and would like to play games, watch movies or start to explore the environment for what they might be able to mischief … as in performing unauthorized system changes to ease their life.

Jumping out of these applications thus results in having OS access with the account the application is running with. If the system itself is vulnerable to privilege escalation issues because vulnerable applications are installed as well, you can obtain administrative level rights on the system.
However, in a lot of occasions, operator applications tend to be started with a privileged account, which means you can virtually do anything you want now on the system.
Should this have been a domain account, you would have a leg inside an Active Directory of which the system is a member of.
Should this have been a domain administrator account, you would have had access to the crown jewels of that environment.

Why is this even possible?

All too often, one or a combination of the following problems exist on these systems, making it possible to perform such breakouts:

• Apps (often) running with admin levels
• Stored clear text credentials
• Access to config files
• Access to internal network
• Access to confidential information
• No / outdated antivirus
• No whitelisting used
• Not having patches installed to prevent local privilege escapes, only patches for remote network issues are installed for example.

How can I perform such operator jail breakouts?

Well, just do whatever you were told to be wrong or not to be done with that system.

• So “test the mouse” by clicking on every possible link, button, image…
• “test the keyboard” by pressing all key combinations you can image, pay special attention to special keys on the keyboard, windows-key combinations, ctrl+ combinations ……
• “provide incorrect input” to all input fields you can find …
• “find (pre-) installed software” what you can use
• “find the (windows) help…” and you are launched to start cmd.exe, notepad.exe, explorer.exe
• Use the windows printing functionality – recent windows systems have printing to xps files installed by default
• Reboot the system and try to interrupt the (windows) boot sequence … sometimes you are lucky and the intended operator application is only launched after some seconds waiting time …

Once you have a foothold to the operating system, use your imagination to (ab)use the jail broken system further.

Can we do something to prevent this from happening?

Yes, by performing a combination of the following actions, operator jail breakouts should not be possible or should have only very limited impact on your environment. Do realize that some escape will most likely always be possible but that the goal is to minimize what can be done with that escape.

• System hardening
• Vendor fix
• Block key combo’s
• Disable right-mouse click
• Implement custom print solutions
• Don’t open additional soft within kiosk mode
• No notification popups …
• Restrict access to the network – restrictive firewall rules
• Use Windows Applocker features

The recorded session at CS3STHLM is located here

The presentation in PDF format can be found here