Threats

Using the command line terminal is a core skill for many IT professionals; terminal applications are often used for low-level system access, remote access, software configuration, package management, and more. Terminals provide access to the command shell which can often perform tasks that GUI applications aren't designed to. But while there are some obvious advantages gained from the flexibility and capability of the terminal, there are also some unique risks. 

For example, in Linux and Unix systems (including macOS), deleting a file via using the `rm` (remove) command does not place the file into the "Trash" folder. Instead, the file is permanently deleted leaving the user with no easy means for recovering it. Adversaries such as ransomware gangs also like the terminal because of its powerful and diverse capabilities. Cyber criminals use the terminal to execute built-in operating system (OS) tools in Living Off the Land (LoTL) attacks. By using built in OS features instead of custom malware hackers can more effectively avoid detection by security software.

If you have ever accidentally printed an encrypted or other binary file to the screen using a command such as `cat`, you may have noticed that strange things can happen such as files with strange names could appear. But wait a minute, if simply printing the contents of a file to the screen can trigger the creation of arbitrary files - what else can it do? In fact, many methods that use the terminal for privilege escalation are already well known such as Pwnkit for Linux and even the sudo command was found to be vulnerable.

Whether you love or hate using the terminal, cyber defenders need to understand the risks. A talk at DEFCON 31 (and the associated PDF presentation) titled Weaponizing Plain Text ANSI Escape Sequences as a Forensic Nightmare by STÖK introduces a fascinating in-depth analysis of persistent vulnerabilities present in many common terminal applications. Furthermore, while the full risks associated with terminal bugs are yet to be fully understood this is certainly a challenge to the cybersecurity community. Let's dive into the details. 

What Are ANSI Escape Sequences?

ANSI (American National Standards Institute) escape sequences are special combinations of characters (two or more bytes) that are used to define specific control functions and execute them within the terminal application. These can be used for customizing the format, color, and other features on text-based terminals. ANSI escape characters can also be used to send requests to printers to automatically print documents and depending on the terminal application, can be used for more advanced features, including to execute operating system commands (OSC). Here lies their powerful potential for abuse.

The control sequences standard refers to the set of rules and specifications that define how sequences of characters, particularly escape sequences, are used to control text formatting, cursor positioning, and other terminal behaviors in text-based interfaces. This standard is commonly associated with the ANSI X3.64 specification, also known as the ANSI escape codes standard.

An ANSI escape sequence typically starts with an escape character (represented as `\x1b` or `ESC`) followed by a bracket (`[`), and then specific control codes or parameters. The specific escape character is different for each terminal application since some use Hexidecimal (Python shell), Octal (Bash), Unicode (Java, JavaScript), ASCII, Decimal (PowerShell), or potentially other character encoding standards. The general format is:

ESC[<parameters><command>

Weaponizing ANSI Control Sequences to Poison Log Files

Here is a fast-forward to the part of STÖK's presentation where he begins to discuss how ANSI escape sequences may be weaponized. STÖK's goal was to weaponize ANSI control sequences to inject malicious code into log files. This attack against log files is tracked by OWASP as Log Injection. The software weakness is categorized as CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences. STÖK showed that under certain circumstances, Denial of Service (DoS) and Remote Code Execution (RCE) via a victim's terminal is possible.

'OSC' stands for Operating System Command, a category of ANSI escape sequences used in terminal applications that can be used to introduce an operating system command. This allows interaction with control terminal features beyond standard text output, such as setting the window title or modifying colors.

Here are some core insight provided by STÖK at DEFCON 31:

• The nslookup tool on Windows systems does not escape ANSI escape sequences if they are placed into DNS records and queried

• OSC8 supports hyperlinks such as http:// and https:// in the terminal. OSC8 also supports file:// schema specifiers and inline image embedding in PowerShell terminals. If the escape sequence is not properly terminated, it can cause the entire terminal output to become a single clickable hyperlink. This could allow clickbaiting attacks

• OSC52 enables tracking of mouse movements on the underlying system

• Character Injection Multiplication: An ANSI character multiplier code can print billions of characters into a terminal. This can be leveraged for Denial of Service (DoS) by overwhelming storage or processing capacity, resulting in a system crash. This technique was exploited via DNS records and other data commonly parsed in a terminal including when injected into a system log that gets printed to the screen. 

• OSC5113: Supports direct file transfer within the Kitty terminal. This feature could be abused to introduce malicious files into a system without explicit user interaction.

Whose Responsibility Are Exploitable Terminal Flaws?

As noted by the presenter STÖK, the responsibility for these vulnerabilities are passed between the maintainers of the terminal applications, and the developers of applications that interact with the terminal. Terminal app developers maintain that all programs should escape ANSI control sequences if they are untrusted user input since untrusted user input always presents a potential risk.

For example, as mentioned above, the nslookup tool for Windows was shown to not escape ANSI escape sequences placed in DNS records. From the perspective of terminal app developers either the nslookup tool or DNS providers should sanitize their user supplied data before outputting it. On the other hand, the developers of applications claim that the functionality provided by ANSI escape characters has grown to become egregious and unnecessarily risky. Sure, having different colors is useful, but more advanced features present higher risk. 

Other Terminal Hacking Research

Here are some other resources for those looking to expand their offensive security understanding of terminal-based attacks:

• HD Moore (2003): Digital Defense Incorporated - TERMINAL EMULATOR SECURITY ISSUES 

• Giovanni "evilaliv3" Pellerano (2010): Nginx, Varnish, Cherokee, httpd, mini-httpd, WEBrick, Orion, AOLserver, Yaws and Boa log escape sequence injection 

• Eviatar Gerzi (2022) Don’t Trust This Title: Abusing Terminal Emulators with ANSI Escape Characters 

• David Leadbeater (BlueHat 2023): Houdini of the terminal David's GitHub repository

• CVE-2022-45872 (CVSS 9.8 Critical): iTerm2 before 3.4.18 mishandles a DECRQSS response.

Conclusion

The DEFCON 31 talk, Weaponizing Plain Text ANSI Escape Sequences by STÖK, highlights a history of vulnerabilities in terminal applications due to improper handling of ANSI escape sequences. These sequences can be exploited to display clickable links, file manipulation, and denial-of-service attacks. The presentation shows the potential for weaponizing these bugs and challenges the cybersecurity community to uncover more risks in terminal environments.