Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

The vulnerability is a known issue that was originally processed over 10 years ago. However, it's such a common mistake that languages keep making the mistake again and again. When executing system commands via a subshell, it's important escape these characters. Otherwise, command injection can be used to control the system. Most languages have this feature and it works well.

In order to prevent command injection, the malicious inputs are commonly escaped. Additionally, the inputs can be processed with a unique argument context, preventing the meaningful bash metacharacters from doing anything on Linux and Mac. On Windows, the process is entirely different though.

When executing a .bat (batch) file on Windows, the OS will automatically do C:\Windows\System32\cmd.exe .\test.bat within CreateProcess. Most languages want to escape the input being used in order to prevent command injection. However is this escaping done? Using backslashes! However, unlike Linux, Windows doesn't process these as an escape - it uses ^. So, \" is insufficient.

This leads to shell metacharacters being able to break out of the escaping! For instance, using "&calc.exe as the input for a spawn in NodeJS will execute calc. This leads to command injection on Windows systems whenever a batch file is used and inputs can be provided to it.

The obvious way to fix this would be using a caret(^) instead of backslash. However, the command prompt will expand variables inline before other parsing. So, it's possible to use substring of ENV variables to add in your own quotes once again, which is bad. How do we actually fix this then?

As a developer, fixing this issue is super tricky because of the issue mentioned above. It involves disabling the automatic escaping then replacing a bunch of dangerous characters by hand. As a runtime maintainer, no extra info was added but was something that just needs to be fixed... weird.

Overall, a weird vulnerability in the interoperability of different systems. The bug has been around for a while! I enjoyed the debunking of the obvious fix in my mind as well.

Parser bugs can be real bad, given the wide spread use of them. The article has a few awards: most impactful, parser differential, hardest to fix and weirdest machine.

For most impactful, it was the webp bug. The huffman compression was absolutely everywhere. The runner up was a H.264 file format set of bugs.

For hardest to fix, it was binarly post. Since they deal with low level firmware, it's non-trivial to fix. It was a memory safety issue in image parsing (of course).

Personally, I found the BatBadBut cooler as a parsing command injection bug. Bash and C tokenize arguments for invoked programs the same way. However, Windows bat batch do something entirely different, which most languages, including Rust and Java, didn't account for. In Windows, backslashes are NOT an escape for quotes - the carat is. So, the normal escaping didn't work.

The winner for best parser diff was a Gitlab parsing issue related to YAML processing in Ruby vs Golang. The runner up was a request smuggling vulnerability in NodeJS and several other servers via differences in the interpretation of carriage return within optional whitespace.

The winner for weirdest machine was the NSO groups exploitation of a parser bug to create their own architecture in a PDF parser, as researched by P0. Probably the craziest blog post I've ever read.

I appreciate the author grouping these all together! I hadn't read all of these so it was good for me to get.

XML eXternal Entity (XXE) injection is a vulnerability in XML parsing that allows for the adding of entities for file reads, SSRF and other issues. Most of the time, XXE bugs are fairly simple but this one was a weird URL parsing issue.

Microsoft.SharePoint.WebControls.BaseXmlDataSource is a class in Microsoft Sharepoint for loading data source objects on a Sharepoint page. The DataSource URL can be controlled as an arbitrary URL. While reading the code with claimed XXE protections, they tried to include a DTD and it surprisingly worked! According to the author, code that properly blocks DTD inclusion in .NET is pretty rare.

So, what was going on? The resolver will try to handle the entities THEN will perform a prohibit check. So, an exception ends up being thrown but NOT before the request is actually made. When doing the check for DTD inclusion within XmlSecureResolver, it does a check to URL check to prevent arbitrary domains from being used. In particular, the domain being pulled from MUST be the same as the data being requested.

The end goal was to get a XmlSecureResolver policy that allows for the reading of local files and allows for HTTP requests. The goal is to trick the policy writer to give us an unrestricted policy yet still be able to request data. This is a classic situation where URL parsing differences really matter.

After tinkering around for a few hours, they came to file://localhost\c$/sites/mysite/test.xml. Since this is a file URI, it gets ignored. Next, it looks for the ending of the file path, which is a local file system path, which we can freely write to anyway.

With this, the XXE bug becomes exploitable. Here are the steps:

1. Upload the malicious XML file to sharepoint as part of a website. This requires a low privileged user to do.
2. Next, create a page with the datasource being the malformed URL above.
3. Step 2 will retrieve the malicious XML.
4. The XmlSecureResolver creates a policy based upon the URL without any restrictions.
5. The malicious XML trigger the XXE bug.

Even though an error is triggered on the XXE bug with a DTD exception, it is too late in the processing. The requests to retrieve arbitrary files, such as win.ini, are already done. I found the error being triggered after the processing so fun. It's a good reminder to always look for side effects on a request that are not directly returned in the response.

Overall, a really good write up! I enjoyed the images throughout, as it was a difficult bug to think about.

devfiles are a mechanism for describes Workspaces in Kubernetes environments for Gitlab. Workspaces are isolated environments. The parent field can be used as a base for a workspace, but was banned in the devfile for security reasons.

At this point, the author noticed that two parsers existed: Ruby for Gitlab and Go for the Workspaces. So, if the author found a difference between the two parsers where Ruby didn't see something but workspaces did, it would be possible to smuggle in the parent field.

Prior to this, they had found a difference between Python and Go with the !!binary option. This didn't work but something similar did - !binary. The Go parser will decode the binary data for the key but the Ruby parser doesn't not. So, it's possible to add a parent but ONLY within the Go parser.

The author needed another bug to make this worthwhile. The devfile tar.gz parsing had a directory traversal issue. They had told the Go linter to ignore the opening of an arbitrary file because it was cleared. However, with relative paths, filepath.Clean does NOT actually clean the path. So, this directory traversal allows for the writing outside of the intended area.

They add a few more notes... First, parser differentials are everywhere and should be looked for. Second, don't trust the comments. Third, you can't find all the bugs, as they missed a go-git vulnerability while auditing this that was reported afterwards. Overall, a good writeup on an interesting bug!

WinRAR is a Windows specific compression tool. It also has a terminal version as well. ANSI is the escapes sequences used in terminals to change the color, orientation and many other things about text.

If the ANSI escape sequences can be included into text printed out to the terminal then it can be weaponized to change the screen. When WINRAR outputs the data to the screen, a malicious file could rewrite the entire screen by adding the escape sequences to the comment of the file.

Because escape sequences can be used to rewrite the entire screen (like in VIM), the author of the post was able to use the comment of a file in WinRAR to rewrite everything. In particular, change the file name output to be something that's different than the original. This could be used to hide viruses or something like that.

Interesting bug with awesome context. Good write up!

CVE-2023-34992 was for FortiSIEM command injection vulnerability. The phMonitor takes in a server_ip variable. This was being used to execute a python script via os.system that led to a command injection.

The vulnerability was fixed by just validating the IP address being passed in, solving the immediate issue. Within the same request as the original command injection, there is another field called mount_point. This field is saved then used in another script when testing the mount.

With this, we have a second order command injection that we first make a request to save the data then another request to execute the exploit from the saved data. I enjoyed this aspect of the exploit, as second order bugs are commonly forgotten about. Overall, good bug report :)

A while ago, Jacob reported a bug named p2p storms that ICF deemed wasn't worth fixing. If the blocks are 20mb each and the mempool is full, then the chain liveness are severely impacted. The author claims that this affects all chains and can be done cheaply with lots of large MsgUpdateClient