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!

Just a big list of open source intelligent (OSINT) resources. I picked this one because there is a description on most of the resources, giving me an idea of what the tool is.

First, they needed to figure out how the UUID's for the cameras were generated. From simply just evaluating the numbers, they discovered that the account UUID is simply incremental. This allows for easy user enumeration for later.

To make matters worse, this request to view a users data included their email and password. At this point, their account is completely taken over.

After taking over the account, the stream can be shared and other malicious things can be done.

From there, one of the binary functions has a out of bounds write that can be accessed remotely. The article claims that RCE is possible because of this, but does not make any mention of ever trying.

Finally, the remote update command passing input directly to tar. This leads to an easy command injection on the device. However, to make things more complicated, the payload has to be an actual URL.

Reversing the Pokemon Go Plus (wrist watch kind of thing) in order to clone the device.

A large part of the article reversing the encryption algorithm used for transferring data.

Eventually, he recreated his own PGP!

With the whole Covid-19 epidemic, learning online has became more popular than ever. So, Checkpoint decided to look into several Wordpress plugins that do just that.

Learnpress had two vulnerabilities: the ability to escalate from a student to a teacher (via a function, with no authentication, called learn_press_accept_become_a_teacher). Literally, just dead code that was found to be callable. The other vulnerability was a timing based SQLi. Very rarely do you see that the SQLi has to be timing based But, because only a single SQLi existed in the code base, this was the only way to extract data.

LearnDash was found to have an unauthenticated second-order SQLi. I have always found second-order SQLi interesting to spot because the input is not directly controllable. Checkpoint appears to just find the lack of prepared statements. Then, they followed the inputs until something that could be used to escape the query was found.

LifterLMS had a very unorthodox arbitrary file write vulnerability in it. There is a function called export_admin_table which exports the administrative table. This function takes in a file name but does not validate the file name!

Now, we can control the location of a file (and the file type) but not the content. By trial and error, it was discovered that a user can register for a course with PHP code inside of the username. Because this, we almost have code execution.

The final trick is that WordPress input filter mechanism does not allow for an opening and closing angle bracket. So, a trick had to be used in order to execute PHP code (which usually starts with < and ends with >). PHP is a very forgiving language; simply ending with a /* (beginning of a multi-line comment) would allow the PHP code to run. So, code execution :)

Overall, I love the Checkpoint Research articles. They have lots of details on the bug, the discovery of the bug and the grinding they have to do in order to exploit the bug.

The client itself runs as System, making it a prime target for exploitation. The service runs a server on localhost, that appeared to be used for updates.

The article goes into reversing the binary protocol used for the service, including verification of the commands (signing and such). He found out that the protocol used an HMAC (RSA with SHA-256) with a hardcoded RSA private key.

By signing the bytes properly (with the wanted command) it was possible to get the web server to execute arbitrary commands as system! With this, you essentially own the computer, simply because of a client service not being smart about permissions.

Morals of the story: attack things that run as high privileges, secrets are still secrets (even inside the binary) and reverse engineering can get you a long ways :)

Deserializing is a dangerous game to play! In particular, if you allow user controlled data to be made into an arbitrary object, then there is a good chance for a remote code execution gadget to be found.

This article goes into how Sharepoint deserializes WebParts. Additionally, it dives into the discovery process of these types of bugs.

The main takeaway to findings these types of bugs is finding a gadget object that leads to RCE. If the deserialization does not deny this type, then you likely have a really good find!

The vulnerability is in the Linux V2 Hardware Emulation software. The vulnerability was found via using custom modifications to syzkaller. Additionally, KernelAddressSanitizer (KASAN) detected a UAF on some linked list manipulations.

Essentially, an assumed to be locked thread could be accessed via other methods. This creates a race condition that can turn into a UAF.

The exploitation is difficult, particularly because it is a race condition. So, in order to hit the race condition to get the UAF, a heap spray was used. This is simply just spraying a ton of attempts until one of them eventually works.

To hijack execution, a painful amount of reversing had to be done. Eventually, it was found that one of the objects subobjects (that could be overwritten) had a function pointer. But, there were some issues with this. Hijacking the control was possible but the pointers (of the fake objects) needed to be in Kernel space.

To get the objects in Kernel space (which took a while to figure out). First, the Kernel logs (viewable in userspace) were leaking addresses in the Kernel. Because of this, it was possible to predict the next location of the address. Additionally, in order to keep data in Kernel space, a trick was used: put the payload in the Kernel stack and call the userfaultfd to keep it there.

After this, it explains the mechanics in which the race conditions were happening. Essentially, it is creating the leak, waiting, spraying, waiting and, finally, trigger the final payload.

Uses a stack pivot, in order to get RSP in a better place (overwrite RSP with a controllable value in RDI). Then, jumps to run_cmd within the Linux source code. At this point, we have passed this function a shell script (which runs in Kernel land) to run whatever we want!

The final trick was to stop the thread at this point. Otherwise, the Kernel crashes, resulting in an obvious 'something bad happened' to the user.

Overall, this is a wonderful exploit! It really goes into the details on how to make a race condition consistent.

Ever done a blackbox test that had a insecure file upload vulnerability but been stuck on how to get RCE? Yeah, me too!

This link has a list web shells in different languages. If you have no idea what the back end is using to execute code, just use this list. Hopefully one of them will work!

The Auth0 API ensures that the none JWT signature is not used (in order to ensure that an actual signature is used).

However, a case sensitivity issue was discovered! Using something like nonE would bypass the check.

This just makes me wonder: how many validations are out there using insure casing checks? Something to consider!

One of the greatest hacking articles I have ever read! This is true hacking to me. Just toying with Safari, understanding its perks and using these perks against itself.

There is no super major bug in this article. There are 8+ several subtle things. These subtle bugs chained together lead to an interesting compromise.

How was this research done? "Here's how I expect something to work... and Here's how it actually works. Ryan just plays with the parsing and generally how Safari works continually.

By exploiting very subtle bugs in parsing and Safari quirks (and having a great understanding of what was happening), he was able to make this possible.