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 good starting point is noticing the usage of an insecure (and now deprecated) function in PHP: create_function. This function performs an eval on the code being ran. The code would normally turn into something like this: create_function('$a', "return str_replace('\\quote', 'quote', \$a);");

The developers thought this might be a security issue. So, they were converting all single quotes (') into \' (escaping it). But, the clever man realized that they were not escaping the escape sequence! So, the "\' would be transformed into "\\'". Therefore, the string would be escaped!

Now, how to actually exploit this? Some PHP trickery was used in order to make the payload work. Here's the following payload: ).passthru("id").die();}//\

A few of these bypasses are interesting. Most of them are just trying to close about parts of the function, in order to make the code run properly.

• The first ')' is terminating the str_replace function.
• The '//' is a comment to stop all code after this from running (preventing a seg fault).
• The '}' is required in order to keep the create_function from breaking.
• The backslash, at the very end, escapes the quote being used.

Overall, the bug was a very subtle bug and the exploitation required a lot of toying around in order to get everything to work just right!

First, what do we look for in a target for privilege escalation? This blogger explains that looking for SUID binaries is a good place to start. In addition, third-party vendors tend to implement binary helper programs (with SUID) that do not take the proper security precautions.

To trace the execution of other files, dtrace (like strace in Linux) was used and filtered out with the execve syscall. By doing this, it was discovered that VMware Fusion was trying to load in several non-existent files, which looked like a good path for an LPE!

The parsing of how these files are called is interesting and the author reverse engineered this use IDA. The parsing attempts to find files by complicated parsing measuring and ensuring that links are valid.

By setting a hardlink on a file (that should exists but the program cannot find) to a location where we can compile the payload, it tricks the program into keeping the setuid binary of the file!

Unlike Linux, macOS allows unprivileged users to create hard links to SUID executables. This is the main reason that this exploit was possible.

The vulnerability is quite interesting! The server itself only runs locally. But, with some tricks (email bouncing) the exploitable code can triggered locally.

The vulnerability stems from a parsing issue when sending commands. By abusing a subtle parsing bug, the email envelope can be altering by each newlines (or new commands). The injected lines, into the envelope completely alter the packet being processed by the mail server.

By altering the envelope, this gives us the ability to trick the code to run other things entirely. Hence, this later allows us to arbitrary shell commands.

The above only works on the client side code. With the server-side code, several issues have to be overcome. One stands above the rest though: the previous request (before the envelope was altered) has been cached on the server. So, how do we remove this cache? Let's crash the server! By crashing the server (with the previous vulnerability again) it will forget the cached value and run the injected command.

Overall, the creativity to get this exploit working server-side was pretty awesome. Real world bug hunting is much more complicated in that of a CTF.

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.