Black Hat Spend much time working in a command-line terminal and you’re likely to have at least a passing familiarity with ANSI escape sequences. Those are the codes that can add color and other highlights to text, among performing other tasks, making your screen a little more easily readable.
Unbeknownst to some, these sequences, if ingested into logs, can corrupt those files as well as exploit buggy software accessing or processing that information, potentially. Here’s why you should clean those codes out of input data before logging it.
ANSI escape sequences have been used widely for decades, and can be used to do things like change text and background color, style, or even build whole GUIs in a CLI environment.
As security researcher and TRUESEC creative director Fredrik “Stök” Alexandersson is due to demonstrate at Black Hat today, ANSI escape sequences are also a security risk, and one that’s been long neglected.
“Somebody is going to break stuff with this,” Stök told The Register, and log files would be one thing to stuff up.
You can design and inject a whole UI with escape sequences – the sky’s the limit
Some of us older vultures can recall being warned back in the day about cat‘ing log files and other sources with potentially user-submitted data, in case whatever was processing and displaying the information – such as a filter and terminal emulator – had a bug that could be exploited by that input. But hey, that was years ago, and now is a good time as any to remind people about cleaning user input before handling it.
“Log files are a very, very important thing when it comes to creating a timeline of a breach,” Stök said. When it comes to examining an incident or strange system behavior, Stök said, lots of people tend to start by running their logs through cat, grep, awk, and/or one of several apps that can display the contents of a log file.
As Stök told us, some tool along that chain may accept and follow any ANSI escape sequences included in that input stream, so if an attacker can manage to get some carefully crafted codes embedded in a log file – such as in a profile name or some submitted feedback – you could end up with a mangled or manipulated view of your IT situation. We can imagine some buffer overflow-style bugs could be exploited, too, if present.
“You can design and inject a whole UI with escape sequences – the sky’s the limit,” Stök said.
Fun with OSCs
There’s a long history of ANSI escape sequence attacks to look at for inspiration, and Stök went all the way back to a 2003 attack developed by infosec guru and Metasploit project founder H D Moore for inspiration.
Moore’s technique, which involved changing the title of terminal windows using ANSI escape sequences, has long been addressed, Stök said, as have other vulnerabilities discovered by security researchers including Giovanni Pellerano and Eviatar Gerzi.
Proprietary or special escape codes implemented by developers of various terminal apps were also looked at as an attack vector before Stök said he finally asked himself the question: “Is there anything that’s been widely adapted, trusted and used by most terminal users that could be weaponized?”
That answer was found in the form of operating system commands, or OSCs, which Stök said he was able to abuse to accomplish his goal.
OSC8, for example, is used to include links in text. Microsoft has since added the ability to link to files using OSC8. You probably don’t want people including click-able malicious links in your log files. OSC52, which adds clipboard support to the terminal, can also be abused to inject malicious content into the clipboard buffer.
A ubiquitous issue
“Every 10 years or so someone tries to do something like this,” Stök told us. “And every time the terminal makers tell developers to sanitize their input, while developers tell terminal makers to stop using escape sequences.”
The end result is a security mess. “Input still needs to be sanitized, and output still needs to be escaped. If you don’t do that there are consequences,” Stök said.
Such as: denial of service thanks to someone dumping a huge number of emojis into a log file that crashes some programs that try to open it, or ransomware gangs manipulating log files so they look empty or normal whenever anyone tries to view them.
- INTERPOL shutters ’16shop’ phishing-as-a-service outfit
- Cyber-extortionists pillage Colorado education dept
- UK voter data within reach of miscreants who hacked Electoral Commission
- Stalkerware slinger LetMeSpy shuts down for good after database robbery
“The worst part is that this seems to be everywhere,” Stök told us. He didn’t go into details, but said he’s tested an exploit in several places, and in most instances it succeeded without an issue. If you want to find out if your terminal is vulnerable, Stök developed an online tool that anyone can try – just curl evil.terminalinjection.com and see what happens. Use at your own risk; it was informative when we tried.
For those dead set on defending against such techniques, Stök said bare-bones terminals like Xterm are the safest. “The more people get used to using customized terminals the more things someone can misuse,” Stök pointed out.
But at the end of the day it all comes down to whether log files can be trusted, and Stök said his attack techniques prove these files can’t necessarily be relied on in all cases – a problem that needs addressing, and there’s no simple answer because of how old, well-established and unmonitored ANSI escape sequences are.
“If you need to spend a couple days sanitizing your logs each time you have a security incident, you’re going to spend a lot of money,” Stök pointed out. “Ransomware actors would be glad to cause this kind of chaos.” ®
