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!

This was found in the XNU operating system, which runs on macOS and iOS.

The out-of-bounds write was thought to happen within a m_copydata function. However, it was a few lines of code later... It is interesting to me that Ian Beer (from Google Project Zero) messaged Kevin about this!

An error message having an unusually long header causes buffer overflow here.

The bug was found by using CodeQL, which is a variant analysis tool.

Word documents can have embedded Youtube videos.

By changing the content of the document.xml file within the Word document embedded HTML can be added!

Word documents are essentially just zip files if they are unpacked. So, altering Word documents actually is not that hard.

Interesting how the guys traces through code with IDA. He practically only uses the string command and looks through the import window in order to find the issues.

I just found the reversing process in this article fascinating. It's a really good walkthrough for Windows vuln hunting.

A double free vulnerability is when the same pointer is freed twice. Then, the memory is reallocated twice, creating two pointers to the same memory.

The Windows heap manager has built in support for ensuring that this cannot happen. However, the mitigation can be bypassed by exploiting a race condition in the allocation process.

The consistency of this exploit was the most difficult part... in order to make the race condition possible, the author allocated more and more style tags (more time).

Side note: Windows heap internals are super interesting! At this point, Windows has a non-deterministic heap allocation, which prevents easy exploitation.

The concept of ‘spraying’ is very interesting! Sending a ton of requests simply hoping the right thing eventually happens.

The people at Google Project Zero Day do black magic work!

The thought process is spoken out very well.

Identifying an attack surface is Extremely important! Why to attack what we attacked?

If you do not understand how something works, then let it run and monitor it! Dynamic debugging can be really useful!

Interested how everything was stored locally on the phone, allowing ANYONE to alter the information. The trust level here is really interesting!

In order to alter the database (which stored the locally), he combed through the source code in order to find the password for the db.

Never store information you do not want tampered with locally... After altering the UserWallets table, the amount being used for the Vending machine changed! :)

XML is a markup language that can be used in order to transfer data. It can have special section called Document Type Definitions (DTD). By referencing a malicious DTD remotely, we can inject some code into XML document with eXternal XML entity. This article has a really good explanation on the XXE vulnerability.

The author was going after a standard XXE vulnerability in several file parsers, but had no luck.

Eventually, he saw a field, that appeared to be taking some parameters and injecting it into an XML document. By creating a DTD inside of this, he was in business!

He tested this by setting up a Burp Collaborator session. Once a ping came back to the session, he knew that there was an XXE vulnerability.

Actual exploitation can be difficult when the vuln is out-of-band. But, the author uses a pretty standard exploitation mechanism for this.

Atom is an Electron based text editor by Github. Electron is a JavaScript based Desktop application creator. One downside (upside for a hacker) of Electron is that XSS essentially creates an RCE!

In order to prevent XSS, there is filtering going on for different elements. Additionally, there is a CSP (content security policy) that prevents inline JavaScript from running but allowed for text from other pages to run inside of it.

Two key observations: the action attributes were not well filtered and Atom runs under the file URI. Although, the action attributes (onclick or something along those lines) were not filtered properly, JS in this would still be caught by the CSP. Instead, let us embed on iFrame from a local file, which triggered XSS!

The local file being ran was not enough though... So, the author found an Atom bundled JS file that took input directly into an Eval in JS, allowing for XSS. As stated before, this XSS turned into an easy RCE with some Atom JS black magic.

Finally, to make this even worse...This could be done remotely! The settings for Atom also allowed for markdown. By viewing the description of a malicious package remote code execution could be achieved.

Obviously, this article is pretty badass. I particularly enjoy the ability to take a single small bug (that allowed for self XSS with a file) into an RCE. Going down the rabbit hole is worth it!

Error messages are really fruitful! Finding an error message is essentially a pot of gold :)

Essentially, a URL parameter could be injected into the Google Cloud Shell, allowing for a reflected (please click on my link) command injection.

The flow is TLS is complicated to understand. However, this article walks through each step with an easier to understand diagram.

To me, the best part is the image that is used! Every time I need a quick refresher on how TLS works, I visit this image.

Img Link.