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!

A recent vulnerability in PHP seemed like a good test for variant analysis in other systems. The vulnerability is an integer truncation and sign conversion bug that via an implicitly converts the value. They found a few bugs from this but found an interesting one within SQLite.

The unsigned long (2*ZSTR_LEN(unquoted) + 3) is passed to sqlite3_snprintf as the first parameter, which expects a signed integer. The line of code in question is shown below:

sqlite3_snprintf(2*ZSTR_LEN(unquoted) + 3,
quoted, 
"'%q'", 
ZSTR_VAL(unquoted));

Why is this bad? The truncation and conversion has an interesting effect - the meaning of the number can be changed! For instance, a large unsigned number could turn into a negative signed number if not handled correctly. While writing up a quick proof of concept for this bug, they quick ran into an ASAN crash with MySQL in an entirely different location.

SQLite has custom format strings, such as %q. While trying to execute the code above, they had ran into an implementation issue on one of the format string handlers. This vulnerability was a linear stack based buffer overflow resulting from an integer overflow. This overflow comes from a really simple addition (+3) being done on a variable without checking to see if this could somehow overflow.

With this wildcopy type of crash, they wanted to find a way to write only the necessary bytes while making the overflow still happen. By adding a single quote (') and not finishing out the string, an inner loop could run that would input a ton of data but only output a limited amount. This allows for the overflowed size to be controllable AND the amount of bytes being output to also be controllable. Pretty neat trick! This allows for an overwrite of the RIP of the stack but we would need an information leak to leak the stack canary for this to work, sadly.

SQLite has 100% branch test coverage and has fuzzing setup on it. How was this missed!? There is an internal memory limit of 1GB for SQLite itself. However, external programs, such as calling from the C API, don't have this limitation. By providing astronomically large values, it was possible to hit this. Additionally, 100% branch coverage means every line of code was hit but NOT how hard or how many times. I really appreciated this insight from Trail of Bits here.

Overall, awesome and thorough post on the vulnerability and how they found it.

The authors of this post spent a bunch of time trying to find vulnerabilities in popular PDF readers. This post is an out of bounds read in Adobe Acrobat but there should be more articles to come. For some background, Adobe XFA (XML Form Architecture) provides the functionality for dynamic form manipulation using the JavaScript APIs and their XML specification. They targeted this section because it has been historically bad for bugs.

They setup a fuzzing harness to test the XFA functionality. Unfortunately, they don't talk about the fuzzing setup or anything else besides the bug triaging. What's crazy, is that the bug is ONLY triggered upon a mouseUp event or when the user clicks on the form.

The only input is a single XFA XDP packet. While reviewing the crash the reason appears to be an out of bounds read with the register rcx having a extremely large value that is defined in a <float> tag. The buffer is being treated as an ANSI string. However, this is where the mistake occurs: the text encoding of the form is set to UTF-16 but the code path taken is ANSI.

So, in essence, we have a type confusion vulnerability. The buffer is being treated as ANSI even though it should be treated as UTF-16. Since the data is differently sized between the two, this leads to an out of bounds read issue.

Simply changing the string size in the <float> field allows for differently sized buffers to be created. The author chose 0x58 for the size because this size is not commonly allocated/freed in the background, making the exploit much more reliable.

To groom for this size on Windows, they allocated a bunch of strings of the 0x58 size via JavaScript then triggered the garage collection by calling more JavaScript. Because the Windows heap has some randomization in place, the authors decided to add multiple <float> tags. This way, one of them is likely to succeed and get the information leak.

Overall, an interesting vulnerability! I wish they would have included more background and information on the fuzzing setup though.

Supply chain attacks are very common within package managers, such as node package manager (npm). Malware commonly uses the npm scripts, such as postinstall, preinstall and other methods. In order to protect yourself, npm has a flag called --ignore-scripts. This article goes into bypassing this protection.

An npm package can export executable files which can easily be ran. Then, the path for this execution is added to the global $PATH variable when executing npm scripts. This is used through environments like typescript, webpack and other things.

So, this begs the question: "what if an attacker attached their own binary to export node or npm?" It turns out, that this is completely possible! This bypasses the --ignore-scripts on installation since the binary has nothing to do with the install scripts.

The package.json file simply has the field bin set to npm and node with a bash script to run the custom code. npm promptly fixed this vulnerability but the author claims that there are likely other variants of this out there. Additionally, it doesn't look like any package was using this in a malicious way at the moment,

Overall, it's a really good post with a simple bug. If you're looking to find yourself a CVE, this seems ripe for the picking.

The author of this post noticed a new piece of functionality in Github: LaTeX support. This support was given in Markdown through the library MathJax. Since the combining of many different libraries is very complicated to do, the author decided to take a look around at it.

A valid macro looks like $$macro{}$$. First, they noticed that the tag $$\<u>HELLO</u>{}$$ went through. But, this ONLY happens with a leading slash after the $$ for the math operator being declared. Although, this didn't allow for any crazy tags besides <style> tags. This led to them being able to add many different style expressions such as changing the background of the page.

Unfortunately, this was closed as a duplicate almost immediately. Within the math expressions though, there was still a lack of input validation. Simply putting $$<div>Test</div>{}$$ would render a div. Similar payloads could be used for input forms as well. Using a payload in here could AGAIN be used to change the CSS on the page to do malicious things. But, the author had jumped the gun as the fixing of the first issue fixed this issue as well.

Third times the charm, as they say. The original payload of putting the tags after the slash (\) wasn't working anymore; anything put in there was simply filtered out. However, now tags within the curly braces were being rendered ONLY when the ones with the backslash were being filtered out. $$\<script>{&lt;renderTag&gt;}$$ is a working payload demonstrating this. This appears like some code was exiting earlier than it should have.

Only some of the tags were rendering though. Eventually, they went with the payload containing an input tag for a fake login screen to send the credentials to the user. Still, no XSS from this but still quite a bit of impact. Github accepted this as a medium severity finding and paid out 10K for the issue. Overall, good post on methodology of XSS hunting and target finding.

Each instance of Jira Align (some Atlassian product) is deployed within an AWS EC2 environment. The endpoint ManageJiraConnectors has a parameter called txtAPIURL to which the URL pointed to a Jira API location.

Jira Align automatically adds /rest/api/2/ to this endpoint. However, this appending can be bypassed by adding a URL fragment (#) to the end of the URL. As a result, the attacker is in fully control of the URL being used. Now, we control the URL and path of the request being made, making this a major SSRF bug.

To exploit this in an AWS environment, the AWS metadata endpoint could be specified. The Jira API URL would return the full body in the Jira Change log. Since we requested the AWS metadata endpoint, this leaks the credentials for the EC2 instance. From there, further privilege escalation could be attempted.

An additional bug was discovered on the application as well. The people role permission (which is very low level) could change any user's role. This includes themselves! So, they could become a Super Admin just by changing the roles themselves. Overall, a good and short writeup explaining the vulnerabilities.

Hancom Office is an alternative version of Office used in South Korea. Docx files are mostly just XML documents.

Instead of sharing the bug then the crash, the authors show the crash with the malicious file. When the application crashes, after subtracting 4 from a pointer and dereferencing this, the code crashes.

After finding the crash, they noticed this came from parsing the </w:> XML tag. This was caused by not including a starting <w:> tag to denote the start of a paragraph. The parsing code appears to make the assumption that if the ending tag is there then the starting one is there as well.

The deferencing is making an indirect call for a virtual function table. This means, that with proper heap feng shui an attacker could control the pointer being dereferenced and execute code. Overall, pretty straight forward bug with a simple write up!

The online version of Microsoft Office is used to view various Microsoft type documents.

The GET request to /op/view.aspx had a Server-Side Request Forgery (SSRF) vulnerability. They learned this from using Burp Collaborator.

While doing this, they noticed that the Office Online server was using its own authentication in order to access things. As a result, it could be coerced into arbitrary authenticated requests.

Some thoughts on exploitation includes relaying this through LDAP to create shadow credentials or recover the client certificate for PKINT authentication. Using the tool ntlmrelayx tool and relaying this to Active Directory Certificate Services (ADCS), we can generate a certificate. Additionally, using this certificate allows for a TGT to be gained to become a local admin on the online server host.

Microsoft closed this as a won't fix because the SSRF with auth is intended. There advice was to "lock down ports and any accounts on that farm to have least privilege" which is really disappointing. Overall, good find!

Sophos Firewall is a network security solution that can be deployed essentially anywhere. The application exposes a web admin console on port 4444 and a user portal on port 443.

The application uses Jetty as a web server, sits behind Apache and is written in Java. There is an additional local server that does a fair amount of the work downstream. When this service validates JSON, it is done via a Perl script.

Each field name is associated with a JSON object describing the mapping between field values and object names in Perl. In order to do this, in some cases, the eval() function is used to turn the JSON data into Perl objects.

Overall, the bug is a fun code injection attack with a weird flow. The article is incredibly verbose, explaining the inter-working of JSON and HTTP along the way. Additionally, the path for attack in the code is described in excruciating detail without much context. I wish the report was less verbose as it makes it hard to find the code stuff.

Secure boot is an important part of ensuring that a running device is not modified. While reading a reference manual for the NNXP i.MX 6/7/8M Application Processors (AP) , they noticed a weird quote that "The DCD based SoC initialization mechanism should not be used once the boot process exits the ROM". In the UBoot Github report, this change had been added but reverted later - this is the beginning of the research.

This chip is provides High Assurance Boot (HAB) functionality to protect the integrity and authenticity of the first boot loader stage retrieved from non-volatile storage. The HAB exports several API functions that allow further boot stages for ROM-based authentication.

For information on how several commands are executed, Device Configuration Data (DCD) and Command Sequence File File (CSF). These sections perform device configuration and image authentication.

However, there is a vulnerability: the DCD and CSF sections validation occurs after some use. As a result, this allows for the reading, polling and writing to configuration register spaces prior to authenticating them.

What result does this have on the system? An attacker can use the unverified DCD section to modify further stages in the boot process. For instance, U-Boot's authenticate_image function can be patched to always succeed. It appears they can even modify the currently loaded boot step to hijack control flow entirely.

The major issue is that the DCD Execution allows for execution outside of the ROM Context. The DCD code is attempts to sandbox specific regions but it just wasn't enough. This same vulnerability existed in the CSF functionality as well but the usage of deprecated functions being called.

The author concludes with why the study of old vulnerabilities is important. This design issue, of allowing ROM-resident code to be shared between boot stages, gave us an potential access problem. Overall, this was a solid post on the secure boot process and design level vulnerability discovery.

Optimism is a L2 sidechain of Ethereum. There are several bridges that allow for the taking of assets from L1 to L2 by creating a wrapped variant of the asset. One of these bridges is BitBTC.

When going from L2 to L1, a user can specify the token in which they would like unwrap. Part of the unwrapping is finding the proper L1 token to use when going back to the other chain, Ethereum.

The L1 bridge completely ignores the L2 token and simply mints the L1 token! This means that an attacker can create an arbitrary token on Optimism (which anybody can do) with all of the supply and set the L1Tokens address to be the L1 address. Using this, they could steal all of the tokens from BitBTC.

Luckily, this bug would take 7 days to exploit... where somebody would likely notice. The author posted this on Twitter, hoping that the BitBTC team would respond. Eventually, they did and fixed the bug.

It's amazing how bad the security of many of these platforms is. You think that handling this much money would require a deep look into the implications of the code written.