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 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.

The LFI (local file inclusion) allowed for any file to be easily included from the OS. This was trivially identified by a parameter which had a file name in it.

LFI's leading to RCE are quite common. So, always try to upgrade this!

Common ways to LFI listed are listed in the article... Here are a few:

1. Using file upload forms/functions
2. Using the PHP wrapper expect://command, php://file or php://filter
3. Using input from log files, mail or other controllable input.

However, none of these worked!

He realized that the session_id and user were being added to the sessions file for PHP (yes, sessions are held in a file called /var/lib/php5/session_[PHPSESSID]. Now, by calling this session file with a particular username lead to RCE!

Know how stuff works. pwn. profit.

Browsers can use custom URI schemes in order to call different apps. A good example is the common mailto: which will open a mail client.

The URI scheme for the WScript.exe passes user tainted input that is not escaped properly.

Using this, in combination with a directory traversal makes it possible to call any file on the OS :)

One thing that is really awesome is that the author explains and tags in other articles that helped them on their way. The article was looking for WSH injection into a VBS script. Eventually, a single script appeared to be vulnerable to this!

This vuln was a simple page being loaded within Microsoft Edge. Then, a custom URI allowed for RCE!

From a defensive standpoint: input validation is killer for attack vectors. Edge did not sanitize for single quotes, which made this attack possible. By making the input as tight to the needed characters as possible, this attack would have failed early on in the process.

AEM is a content management system from Adobe that is written in Java. This is made from blood, sweat and Java lol.

The AEM consists of three tiers: author, publish and dispatch. This different tiers have different filters that are unimportant (read the article to learn more).

For this vuln, the Publish tier admin resources should not be accessible via the Dispatch tier. However, the filter for 'glob' can be bypassed on the URL by adding HTTP query parameters in the URL! For example, files that end in .css should be accessible to the outside world. While https://Dispatch.example.org/system/console should not be accessible, this filter can be bypassed by adding a .css to the end of it, such as https://Dispatch.example.org/system/console?.css.

The Microsoft signout.live.com used the Adobe AEM on the back-end... This meant that the vulnerability above made stuff much more possible. At this point, an authentication page came up. What is the most obvious thing that you can try? Well, let's try admin : admin! This freaking worked!

By uploading an extension to this page, a very "lame" and easy RCE had been created.