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!

First off, just an amazingly descriptive report with great diagrams and explanations. This is what a report should look like.

HTTP smuggling is when two servers disagree on how to interpret requests. One server would use the Content-Length header while the other may use the Transfer-Encoding header. Because the two servers interpret the requests differently, this results in potential request altering!

Even though the bug is everywhere, it is not a trivial bug to exploit currently. This report is an awesome example on how to exploit it though.

The exploitation is done by forcing a redirect (because a GET request is made) to the backend server. This redirect can then be poisoned with the attackers choice of URL. Because these requests are redirected (with the cookies), the cookies can be stolen. Hence, this leads to an account takeover vulnerability.

Twinkly is an IoT Christmas light product. Overall, this is a cool reverse engineering process.

The lights work with RESTful HTTP API endpoints over port 80. The Android app is also pretty trivial to reverse by analyzing the traffic.

'To program an ESP8266, you pull GPIO0 Low and reset the device via the RST pin which causes the device to enter its ROM based serial bootloader. This allows the device to be programmed over UART (TXD/RXD) but can also be used to read the SPI flash. This explains the test pads on the device and thus it is likely that these pads would allow for us to pull the firmware off the device or update it, but as we will see this was not required.'

In the end, it was discovered that Home assistants were using the a protocol known as 'Message Queuing Telemetry Transport' (MQTT). It connects to a central broker using a hardcoded password in the application.

Because any user can post to any topic, it is possible to change the lights on any of the lights! Talk about broken access control!

Looking at professional reports gives you a good idea of what the real pentesting looks like and the bugs to look for.

This report has lots of standard bugs, such as reflected and stored XSS, broken access control and HTML injection.

Two reports stood out to me: XSS via postMessage and host header poisoning.

The postMessage feature is one way different origins communicate with each other. In particular, this is used when communicating between iFrames.

However, the iFrame listeners, if not properly checking the origin of the postMessage request, can take receive requests from other websites. This acts as a CSRF in some ways.

Finally, the request being sent via postMessage from injecting HTML directly into the page. This, then results in a CSRF XSS via the postMessage functionality.

The other bug was a host header injection attack. The password reset link would use the Host header in the request sent. However, this can be spoofed by an attacker, creating the ability to reroute the password reset tokens from anyone's account!

This was a bug bounty program on a CTF platform. Some interesting bugs were discovered!

The bug that I really enjoyed the Race Condition in Flag Submission. By sending the a flag multiple times (in the multithreaded application) there was no lock put onto this per user. So, a single flag could be sent 10+ times to get all of the points.

This was exploited using a tool known as Race the Web. This tool just makes a ton of requests at the same time to test the race condition.

There is also a race condition in the amount of players that can join a team too.

When should we look for these types of bugs? To me, when a non-reversible action takes place or an action verifies to see if the action has been performed previously (time of check versus time of use).

This article dives into the Spotify Local server that is running. Additionally, it runs into a very weird widget local server that is running.

What are the dangers of localhost servers running? Well, several weird attack vectors!

In the case of Spotify, we can send a request to the local Spotify server that is running on someones computer. Then, this would alter the state of what is running on the local machine (for example, changing songs)

Using a WiFi pinapple also yields interesting results: some DNS requests have Spotify OAuth tokens in them.

In the case of the Übersicht widget, there is a page called runShellCommand. Seriously... I wonder what this does. Well, it runs a freaking shell command!

By making a request to this, we can pop a calculator or do whatever we want.

Popping the calc did have a certain trick though; the content-type of the request had to be one that did not URL encode data (such asenctype="text/plain"). Keep this in mind when trying to run shell commands from the browser.

Just a really fun CTF challenge! By only using wildcards (*,?) and other characters, it was possible to print the flag!

LiveOverflow goes through the entire thought process of discovering the bug and exploitation.

The host header being set to 127.0.0.1 bypasses all authentication!

The unwritten API is quite cool too! Because the APIs just check for all functions in a file, without an underscore (private function) then all of the IMPORTS will also work as API endpoints. So genius!

Finding exploits just take a long time! A lot of recon and testing.

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.