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!

Some web server configurations will serve content based upon a regex matched URL, not necessarily the entire URL that was entered. For example, https://example.com/content.php and https://example.com/content.php/type.css may still return the content.php page.

Additionally, caching is used on lots of files in order to speed up the process of returning files to users. In particular, static files, such as css, JavaScript and other things gets cached.

The combination of point 1 and 2 can cause an issue: what happens if the URL is accepted with a static file at the end and this is cached? Because the caching server relies on the the file ending and not the content type, this may be cached!

So, what does this actually mean? The attack scenario looks like this...

1. Convince an authenticated user to visit https://example.com/content.php/styles.css for some important site on a page that has sensitive information.
2. Request the page yourself. Now, because the page requested was a .css file, it is cached on the server with the personal content of the user.

When is this attack possible? Several conditions have to be met:

• Cache files based upon their extension for static extensions regardless of caching headers.
• Web page will return the content of content.php even with the other values in the URL.
• Page needs to be on an authenticated part of the website.

Overall, this is an amazing attack that abuses novel features within two aspects of a website that have no security issues otherwise.

As a final note, it appears that several people have started looking into issues of different technologies working together (this and HTTP Request Smuggling). So, if you are looking for a research topic, diving into something similar may be a good path!

A 'Zero Day' references a previously unknown vulnerability. The term 'Zero Day' typically references to something in a really popular product such as Nginx, Chrome or the iPhone.

This talk goes into the process and expectations when attempting to hunt for Zero Days in the wild. They squash many misconceptions and give lots of helpful tips. I will list what stood out to me below...

Fuzzing - Shoot for about 60% code coverage. The real vulnerabilities come out of those last few percentage points of coverage. If you found a bug in 5 minutes, it is likely that someone else found it in 4.

Source code analysis - Can find much deeper bugs with added complexity, as opposed to fuzzing. However, this requires a very deep understanding of the code base as a whole.

Choose a section of the code base to attack. If something has 3 million lines of code this can feel overwhelming. By thinking about what sections are hard to implement and previously have had bugs you will find a good target. Depth vs breadth.

Find where the user input goes. This is what you control; this will likely lead you to the vulnerable sections.

Setup dynamic analysis. This will give you the ability to easily debug what is happening and figure out where the bug actually is. If you do not understand something, hook it up to a dynamic debugger to see how it works in action.

How to get into this? CTF's can be helpful but can be focused on very esoteric pieces of knowledge. So, the second speaker recommends diving into exploits on the same platform that you are attacking. Walk through them, write them yourself and do as much recon as possible.

Success hides behind "what is the dumbest thing that could possibly work?" Do not over complicate things.

Statically linked executables are executables that are a stand-alone executable, with everything being self-contained within this file.

The PLT/GOT tables are used in order to make it possible to dynamically generate references to libraries. However, these are essentially function pointers that have to be resolved. Hence, these functions pointers can be overwritten for malicious purposes.

Because of the above issue, a mitigation was put in place: Relocation Read-Only (RELRO). This resolves the PLT/GOT table entries at startup in order to make the section read only.

This is where things gets weird... One would think that a statically linked executable would not use GOT/PLT tables, right? Well, they do. The tables are still used for optimization purposes.

Does RELRO still apply to statically linked executables? This is the best part about the article: no. The Read Only setting is turned on by the dynamic linker, which is not used with a static executable. Hence, a statically linked executable does not have RELRO protections.

Fact: RELRO also protects items such as .init_array/.fini_array, .jcr and the dynamic section. In a statically liked executable, the .init_array/.fini_array sections no longer work (removing this as an attacker surface).

From the ASLR standpoint, there are also issues with statically linked executables. ASLR is incompatible with statically linked executables.

The author of this article creates two new tools for statically linked executables: RelroS and static_to_dym. The first tool alters the executables to make the PLT/GOT section read only by doing some ELF black magic. The second mitigation is to turn an executable into a dynamic executable, but only for the purpose of ASLR to work.

There were two implementations of randomizing the code segment: PIE and RANDEXEC, where PIE won the battle.

Overall, this was a fantastic article that dove into the nitty-gritty of exploit mitigations.

Address Space Layout Randomization (ASLR) is a defense-in-defense security mechanism that randomizes the location of memory for the stack, heap and other data fields (not the code itself though). This was built into the kernel for most OS's in order to make the barrier for exploitation higher. If a memory leak cannot be found, then exploitation is almost impossible (unless your Google).

Although ASLR has mitigated a ton of remote attacks, it appears that locally it has been an issue.

Several exploits have been written that allow for the leaking of pointers and other sensitive pieces of information by viewing the process information. This article chronologically goes over these exploits.

Path traversal is a way to move up a directory by using the common ../. I usually think of this as a vulnerability associated with handling files.

This vulnerability occurs because of two REST API calls talking to eachother. The firsts request has parameter for some ID value. If this ID value is set to ../something then the next REST call will move up a directory in the URL before making the call!

Finally, to make this exploitable, the API handler for the second REST call allows for ?parameter=some_value. So, the directory traversal can be used to hit internal APIs (that should not be accessible) with parameters!

The example, in the post, can be used to promote any account to admin! The request some_api/(../users/?admin=true) where the ID should be the item in parenthesis gets translated to api/v4/users/?admin=true. This almost acts as an interesting SSRF attack.

There is a buffer overflow in Sudo! In order for this to occur, a the pwfeedback feature needs to be turned on.

The bug occurs because of bad parsing in certain situations where characters cannot be written back to the terminal. In order to exploit this, create a pty (pseudo terminal) and set this to READ ONLY.

The bad parsing occurs when a pointer (cp or current pointer) does not get reset back to its original value when the write error occurs.

The exploitation was actually really straight forward! The overflowed buffer existed in .bss. Because the overflow occurred in .bss there are no canaries. So, there is no way to detect if a bug has occurred or not at the binary level.

Quite a ways down into the .bss section is a variable called User Details. By overriding the uid field in this struct with 0's, we can execute a privilege execution to become root (uid 0).

Another fantastic write up for the exploit: iamalsaher

I thought of this while using Zoom... But, I then assumed that it was too simple to test... Just iterate through ID's and join meetings!

Sometimes, the simple things are what works! So, make sure to try even the simplest of things on a site!

The first two vulnerabilities (private link password bypass and HTML injection) seemed to occur because a single point was not being used for actions. If the link was viewed through a particular API, then the document could still be viewed (without a password)! Additionally, the HTML injection was only possible to inject into the username only when uploading with a CSV file.

The second to last bug is very interesting! Dropbox wants to loud the document 'byte for byte' while getting it secure for other users. Obviously, XSS could be devastating in this context. So, the domain dropboxusercontents.com is used in order to execute the XSS in a useless origin, protecting unsuspecting victims from potential compromise. Seems like a good thought, right?

Somebody found a crazy bypass to this with a little known browser feature called App Cache Manifest (ACM). The ACM is used in order to tell the browser which files to cache locally. Using the App Cache Manifest allowed for pages to be loaded within the normal Dropbox domain, making XSS very impactful. They abused a feature in the ACM with a fallback mechanic that allowed for pages to be loaded when something else failed.

I found Dropbox including the mitigations to be really interesting too. They have an insane amount of defense-in-depth in order to mitigate the impact of the vulnerabilities before they even happen. For instance, they have extensive jailing put in place that restrictions the length of connections and which syscalls can be used.

PHP has two operators for comparisons: == and ===. The triple equals sign is a strict operator, while the double equals sign is a loose operator. These loose operators have PHP juggling in the mix, which can cause major security issues.

This presentation goes over how integer type juggling can lead to weird logic, bypassing security constraints.

The Zero Day Initiative (ZDI) purchases bugs from security researchers and sells them back to the companies (Microsoft and so on). They give a year in review that has some interesting statistics about vulnerability hunting and exploitation. This will be a list things that I found interesting from the article.

Most of the Microsoft bugs being purchased in the past have been Browser related. This year, however, there was a large increase in bugs in the Windows OS itself.

Most common vulnerabilities:

1. Out of Bounds Read (205)
2. Use After Free (160)
3. All others (158)
4. Out of Bounds of Writes (95)
5. Stack Based Buffer Overflows (73)
6. Expression Language Injection
7. Untrusted Pointer Dereference (61)
8. Heap Based Buffer Overflows (36)

There are also a few other notable problems that are still prevalent but becoming less problematic:

• Integer Overflow or Underflow (17)
• Cleartext Storage of Sensitive Information (18)
• Double Free (7)

To me, it is really odd that that stack overflows are more common than heap overflows. Considering there are many more security mechanisms in place for the stack was reason this surprised me.

Additionally, UAF's are all the rage! It is crazy how dangerous these can be! In the same class as UAF's, double frees are not as common as I expected.

Finally, Expression Language Injection was extremely common (at #6). This is something that we should be looking for much more often in 2020!

Overall, it is awesome to see into the mind of the worlds best bug hunters to see how they are exploiting the worlds most popular software. Thanks for doing this ZDI!