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!

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.

This resource has a list of 30 articles organized around Windows exploitation.

All of the articles are written by the same author, with nice examples and screenshots to walk through the techniques.

Overall, looks like an amazing resource for learning Windows Exploitation!

People new to the area do not realize that testing is not just hacking. There are many other steps to this.

To start with, there is Pre Engagement stuff. Although this is really boring, determining the scope of the engagement, the testing environment and etc. This is so that when you start the test that you can actually do the test.

Secondly, is the recon phase. This is understanding what your testing, where the resources live at and etc. I would argue without a proper recon phase, you will not know enough about the service to test it.

The next stage is where the hacking beings at. Now that we understand what we are testing, it is time to find the vulnerabilities!

Items 4 and 5 are not included in a lot of engagements but are probably the funnest part! This is exploitation (4) and post exploitation (5).

In stage 6, we report what we found on to the service. Although this can be boring, this is really what the clients pay for! Convey what you found, how you found it, what this actually means for security and how to fix it.

The last stage is fixing the bugs. Typically, the penetration testers are not intimately involved with this part of the process.

Goes over some basic techniques for NFC and RFID with easily accessible tools. In general, just trying to say that hacking on these devices is available to everyone!