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!

The session cookie turned out to be deterministic. Essentially, a deterministic userID was put into the value and a random value. However, the random value was not checked...

This led to easy account takeovers by brute forcing a list of userIDs.

This article goes into the process in which this hacker found multiple SSRF's on Facebook instances.

The interesting part was not the bugs themselves, but how they were exploited. Using the SSRF, it was possible to do the following:

• Make requests to internal EC2 instances to steal creds
• Internal path to the logs folder
• Port scan
• Internal system queries that use to fetch data

All of these have actual impact. He was awarded 30K for findings this SSRF bug.

The URL shortner was interesting! Because it was used by internal Facebook people and the outside world, he was able to leak sensitive data (such as internal links, sessions tokens and so on). He simply just brute forced a bunch of links with intruder until he found sensitive information.

Zomato has a login with Facebook feature. These feature was not implemented properly.

By changing the Facebook Id on the request, it bypassed the login for the user entirely!

Note: This hacker has found several very bad authentication bugs in third party apps and in mobile logins. I feel that mobile logins are not well scrutinized; there are probably quite a bit of things to look at here.

Popular platforms for products such as Apple, Facebook, Google and others have features called login with 'x'. This can be used to login with your 'x' account on another site.

Sign In with Apple uses JSON Web tokens or JWT's for short. They are used for stateless authentication. Essentially, a token (with authorization levels of the user) is digitally signed by the server. The signature prevents tampering of the token.

When going through the process, a user can choose to either share or not share their email. Upon this, Apple will generate an email for you.

The hacker found a signing oracle. By setting the emailID of another user in the request, it was possible to get back a JWT (signed) from Apple!

This allowed for a complete account takeover on any Sign In with Apple Account.

Even the most simple bugs exist in the most tested applications. When testing, even the simple issues should still be tested.

First, the author wanted to do some reconnaissance on how the Google Cloud Deployment process worked. I really appreciate how he goes through all of his attempts, not just the successful ones.

The Cloud Deployment had a two main versions: beta and betav2. Besides these two documented methods were two undocumented methods, alpha and dogfood. The dogfood version had some added functionality.

After gaining control over one of these internal fields, he tried several requests. Eventually, he was able to get authorization headers from some internal services.

Another interesting point that is he had plenty of communication with several Google employees during this process, allowing him to have a better idea of how things worked.

Through internal employees he learned the following: "If service A makes a request with service B on behalf of user C, the authorization of user C is checked. If there are no credentials for C, then the authorization of A is checked instead.".

Because of the previous note, he removed the credentials from the request to use the authorization from cloud-dm-staging@prod.google.com.

Interesting takeaway:

• Recon is very, very helpful! With an incredibly large and interconnected system (such as Google), there is an even larger attack surface.
• Having internals buddies can be helpful for understanding the ecosystem.
• Undocumented versions tend to have added functionality. Always look for this!

Essentially, the Google Voice number '444-555-4455 <img src=x onerror=alert(1)>' had a DOM based XSS. This is very basic XSS that the bug finder actually found by a very basic payload.

The rest of the article goes into the client-side JavaScript that actually caused this issue. It essentially came down to a developer removing the bad characters from a string, putting this into a different variable, then using the wrong variable. Sometimes, security mistakes are that simple.

GLPI users with maintenance privileges can perform SQL/XML dumps. This functionality was vulnerable to CSRF. This can also come in a zip format.

This feature can be used in order to write the file to any location, including with other URI's, such as FTP! For code execution (which is always the end goal) there is something else we need though: the location of the webroot. This webroot is actually a hash...

The webroot could be leaked by a cookie that was by set from the server. The cookie could be calculated by the following: "glpi_".md5(realpath(GLPI_ROOT)). Although this is an MD5 hash, by using Hashcat to brute force this hash, the path could be recovered!

This is where things get REAL crazy. Can a zip file be turned into a webshell via valid PHP? That is the question that the research asked.

After learning a ton about gzip and doing a bunch of brute forcing on dumped SQL and XML, a positive gzip file was identified that was somehow valid PHP to pop a shell!

This was incredible research that required a ton of amazing innovation. I highly recommend reading this article in full.

OAuth is a third-party authorization delegation service. Essentially, if you do not want to hold the usernames and passwords yourselves, then have someone else do it!

The bulk of this list of OAuth test cases that should be done in order to see if the implementation is secure or not. Great article for what to do on a Penetration test!

Fuzzing is an automated technique that provides semi invalid or bad inputs to a program to attempt to find bad program states, such as crashes, hangs or other weird behavior.

Fuzzing is much more than simply throwing random inputs and moving on with your day though. Fuzzing is actually quite involved and takes a lot of work!

This article dives into the details an entire fuzzing job. I'll mention what stood out to me...

The first part of the article is about picking the target. The main questions that we should ask are:

• Is the source code readily available? This is important in order to instrument the binary.
• Are there code examples of how to use the code base?
• Are unique and interesting test cases available?

Having high quality test cases is a very important part of the process. What exactly makes a high quality test case?

• All inputs hit unique codes paths
• The test case is as efficient as possible

Both of the statements above are very important; this leads to fast fuzzing and good coverage fuzzing. A good tool for helping with this is AFL tmin. This tool altering the input until it is the smallest test case possible that still hits the wanted path.

Time to run the damn fuzzers! Start multiple instances of the fuzzer, inside a bash loop, and let them go for a while. Make sure to check in periodically in order to validate the fuzzer is working as expected.

Stopping and pruning: this is the section that the author claims to be most important part of the fuzzing. After the fuzzer has ran for a while (AFL finished first cycle), a large amount of test cases have been created. These should now be interesting code paths that hopefully have bugs lurking inside them. At this point, restart the fuzzer with several of these test cases as seeds.

Once you have found some crashes, it is time to start triaging. Finding the actual bug that causes the program to crash is terribly annoying. Tools such as GDB (debugger), CrashWalk (determines if crash is exploitable), Valgrind (memory analyzer) and others make this process less bad at least.

Samsung has some added support for other image formats. In particular, they have support for a very odd image format called Qmage. Parsing anything is hard to do securely...

In order to fuzz this library, a custom loader was created in order to test this. The first part changed the default version of Malloc to essentially crash with any type of memory corruption. The second was adding extra crash information on a SIGSEGV.

The other version of Malloc was Libdislocator. This had a few differences... Libdislocator only has a 1 GB heap limit, does not align allocations (will return exactly 17 bytes for a request) and it fills newly allocated memory with 0xCC in order to catch potential use-of-uninitialized memory. Knowing the differences is important!

After fuzzing a whopping 5218 unique crashes were found! Both deduplication and severity scale was automated. Essentially, viewing the crash dumps made this possible to do.

From an exploitability standpoint, Android processes images in an interactionless manner. So, if a malicious image is sent to a user, there is nothing they can do about it.

The FAQ's also have some interesting information. To start with, the bug takes up to 300 minutes to perform. Why? This is because ASLR has to be defeated. This is done by somesort of a binary search via text messages being sent and the messages app not crashing. Interesting process to defeat ASLR!

Another interesting part of the exploit is that the messages can be sent in a particular way that no notifications are sent to the user! Hence, doing this attack at 3am would actually be a feasible option(even if it can takes several hours).

Main takeaways: Older/weirder functionality tends to have bugs and fuzzing with extra loaders can be really useful for bug hunting.