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!

In glibc 2.34, the hooks used for debugging malloc were completely removed from the run time configurations. Since these were commonly used for getting code execution, the author of the post wanted to find a new way to hijack the control flow. The man also runs the how2heap repo as well.

The FILE data structure is used by programmers. Within glibc, there is a vtable added to the structure _IO_FILE_plus. In glibc 2.24, a restriction was added to the vtable pointers by ensuring that the pointers were within a very special section of libc called __libc_IO_vtables. Additionally, some pointers are encrypted (key stored in thread local storage) to prevent modification.

A bypass for this was found though. First, the _IO_str_overflow pointers use tables outside of the vtable. So, the same attack could be used from before. Additionally, the vtable could be misaligned to invoke the wrong functions. Again, this was patched in 2.28 by removing the function pointers. So, where are we now?

While manually auditing, the author found 81 unique function pointers within the special section. They checked all of them and their corresponding to calls to try to find any missing checks. Sadly, all of them are either validated via special vtables or encrypted.

The encryption aspect is interesting - modifications can still be made IF we know the key. So, can we overwrite the key or leak the key stored in thread local storage? The goal is to use the misalignments to eventually do this.

The file structure is very complicated. Instead of manually auditing, the author decided to use the symbolic execution tool angr. Since this is a bounded model checking problem, angr is the perfect tool for this. They configured Angr to run and let it go to town!

The script found 10+ techniques - one of them which is known as the House of Emma. The tool had found a list of calls to the function tables, all which were validated, that would give control over RIP eventually.

It turns out that a list of function pointers in _wide_vtable was not being validated by the vtable checker. Three of these techniques were known as the House of Apple. However, the others discovered were brand new. Overall, a good article with fun memes in it!

Three major hacks took place in a single day, resulting in millions of dollars being stolen.

The first vulnerability was in Rabby Swap. The contracts router function had the function functionCallWithValue with arbitrary parameters passed to it. This allowed for a user to pass in an arbitrary set of arguments and an arbitrary function as the router.

Using this vulnerability, they were able to call swap from the context of the router contract. Using this, previous approvals from other users could be abused to steal all of the money from their wallets. Apparently an audit took place but completely missed this issue.

The Template DAO hack was really simple. The function migrateStake had no access controls. Additionally, the previous function did not verify the source address or stake value of the old address. As a result, an attacker could call the contract with a fake old address and stake value, mint their tokens and drain the entire contract.

Finally, the Mango Market was hacked, which is just a trading platform. A flash loan was used to inflate the price oracle of the Mango token from 30 cents to 91 cents.

Since this increased the value of the attackers collateral, they could borrow even more funds from the protocol. Why is this increase in price so bad? By taking out a massive loan, with the inflated collateral, they could drop the price of the token bad down, they just abandoned the collateral and took the loan

For Mango Markets, the crazy part is that the hacker came out and said they would keep some of the funds as a bug bounty payment but he was using the protocol as expected. Even though this is obviously not true, how do you define expected vs. unexpected functionality with a finance market? The guy kept $45 million and the person is public knowledge.

Overall, three interesting hacks that led to $100 million being stolen. Super interesting!

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.