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!

Using Burp Suite, the author was looking for authorization issues within the application. They noticed that a particular plugin did not require a session cookie or API key to be used.

One of the functionalities of this plugin was a file upload. Using this, an arbitrary tar file could be uploaded to the server, which was then un-archieved in process. In a non-shocking turn of events, the tar library did NOT filter out directory traversal attempts!

With the directory traversal and lack of authorization together, an arbitrary file could be loaded to an arbitrary location! Using this, it is possible to get RCE on both Windows and Linux by overriding either a .jar file or by adding an ssh key.

Differences between parsers have been causing security issues since the dawn of the computer such as HTTP smuggling. This article is about how two different JSON parses can be different to cause security issues.

The first issue discussed is inconsistent duplicate key precedence. The specification says that any preference in keys can be used, which seems crazy. The example shows a verifier and a user which differ in the precedence.

The second issue is the difference with truncation's and comments. Using the differences with nullbytes, unicode encodes, invalid strings and other things differs between implementations. Using this, two libraries may show different results.

The third issue is differences in serialization. Different operators in different implementations will use different values. For instance, using obj["test"] may use the first key but the obj.toString() may use the second.

The fourth issue a difference in numerical encoding can be used. Decoding a large number, or floating point numbers, may decode to 0 in some libraries or to the largest possible number in others. The example is a library for a shop validating with the large number but only charging with the decoded 0.

At the end of the article is a list of 49 different JSON parser libraries from a variety of languages. This could be a valuable resource for referencing in the future!

This is an excel spreadsheet made from a group of people at P0 that includes a list of people impactful exploits used in the wild. Having a large arsenal of exploits grouped together can be useful for vulnerability hunting in the future.

Maddie Stone of P0 recently did a talk on how 1/4 of all impactful 0days are not patched properly. While hunting for new bugs is fun, you will have a much higher success rate hunting for mistakes on patches.

The bug is a kernel type confusion between an ipc_port pointer and a host_notify_entry pointer due to failure to account for the semantics of IKOT_HOST_NOTIFY ports in turnstile code.

The kdata field is a large union with 6 different potential fields. In this case, the kernel did not catch that a situation that the port type could be changed from a special_reply_port to a host_notify by doing specific actions when interfacing with this code.

When the special_reply_port code gets used and it actually has a type confusion since it has been changed to a host_notify value. Using this, the author claims that an arbitrary read/write primitive would be possible.

Unions are incredibly dangerous! The author claims that there has been another type confusion in this exact area before. In general, unions are a good place for bugs, as type confusions lead to many dangerous findings.

In a previous blog post, the author found an vulnerability that led for the ability to compromise the kernel. While doing this research, they also found a bonus bug!

The bug stems from the usage of a union in older code between for the values ReplyHandle and RegIndex. When the ReplyHandle is used as an 8 byte kernel pointer, then the RegIndex is only uses the first half of the value.

This is because ReplayHandle is a kernel pointer and the RegIndex is a 4 byte ULONG. When the code was originally created on a 32-bit system, the pointer also would have been 4 bytes. When the move was made to 64-bit, the bug was created!

This article has a bunch of background information on WET on Windows too. But, I just wrote up the vulnerability above.

Multi-factor authentication is when multi-means of authentication must be used in order to login: the three categories are something you know (like a password), something you have (2FA code) or something you are (biometrics). Usually, this is a password then something else.

A common form of MFA is to have a code that is 4-6 digits long submitted from either a text message or a different app on the phone. If you could bypass one of these, then you are bypassing authentication entirely.

Because of the sensitive nature of the verification API of the 4-6 digit code, this should have brute force protections on it. Otherwise, you can guess the code with enough tries. So, what if you could bypass the brute force protections?

In this write up, the author used the X-Forwarded-For header in order to change the IP address being used for the brute force protections. So, if one IP gets blocked, you can just switch to the next with the X-Forwarded-For header. This is an interesting bypass that is probably built into frameworks without people even realizing it.

The syncing contacts feature is common on major applications; it allows you to find other users on with your contacts. Although this is a cool feature, this needs to be restricted in order to prevent abuse. If this feature was abused, an attacker could steal phone numbers, emails and other information associated with a TikTok account.

TikTok attempted to restrict access to this API by signing the messages and have a limit on the amount of daily contacts syncs. But, by using Frida to hook the message signing functionality, it would be possible to resign the requests.

Setting this up in an Android emulator made the process for signing with a large amount of devices makes this even easier. Because the restrictions were not great enough, this process could be used in order to completely automate the process to steal contacts from TikTok.

To me, the moral of the story is to check the rate limiting restrictions even if they are there. They may not be sufficient for the test.

With its focus on developer-friendly tools and configurations, Spring Boot accelerates the development process. However, the dev tools within SpringBoot provide an interesting attack surface.

The Spring Boot Actuator has a set of built in HTTP endpoints that allows a developer to easily monitor and manage an application. Using the /actuator/env endpoint, environmental variables of the application can be set.

By using the previous functionality of setting ENV variables, you can set the spring.datasource.hikari.connection-test-query to run arbitrary queries once this functionality is triggered. In the worst case, this can be used to run Java in the H2 Database Engine. In the best case, arbitrary queries can be executed.

When using Springboot in production, do not expose these development endpoints on production. This can lead to major compromise.

Drama... a popular programming book author (Zed Shaw) called out the Soatok in a mean and crud way. So, Soatok fought back by finding a collection of 0-days in his software. Just be nice to people and life is better!

Secure Remote Password (SRP) is an early Password-Authenticated Key Exchange algorithm often integrated with TLS (to form TLS-SRP).

Using this algorithm requires a few things:

• A secure random number generator
• The usage of a Sophie-Germain prime and N be its corresponding Safe Prime.
• Validate the numbers being sent in.

The implementation of the library uses TrueRand, which is known to not be cryptographically secure. This is bad because salts and private keys become more predictable.

Additionally, the implementation uses the wrong set of primes. This compromises some aspects of the math for a ring, resulting in less security crypto. As a result, this could leak the client password.

Finally, the verification steps do not happen as they should. This allows for trivial impersonation of the server by a different client.

At the end, the author writes "Salts and private keys are predictable, the hard-coded parameters allow passwords to leak, and you can impersonate clients through active attacks.". Sounds like this is a problem.

TinyCheck is a portable network analyzer. Nicely, the source code for the device is on Github.

The first bug is one seen on IoT devices everywhere: default credentials. The device had the default username and password tinycheck/tinycheck. This opens up the attack surface significantly. Although this could be changed, nobody forces a change here.

With the ability to hit the backend (on the public network), the author found an SSRF in a YAML configuration file. This bug is important because another server runs on localhost, which is the main target in this attack.

The localhost server had no reason to have authentication or expect anything malicious. Once you compromise the perimeter the bugs usually fall right out. By using the SSRF, a trivial command injection was found in a Python script.

Chaining all three bugs together (assuming the password has not changed), the device can be completely taken over.