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 Google Project Zero day team does amazing stuff! There are three parts to this article: The vulnerability, defeating ASLR and exploitation.

The bug is an issue in the parser for NSKeyedUnarchiver. This allows for references to other objects within the same object. This can be abused by creating a circular reference where one item being referenced is referenced within another, while the first item is still in the unarchive process.

The start of bypassing ASLR is to use heap spraying to get a usable pointer in a known location. This is essentially just spamming as much data as possible. Then, there is a good chance that the pointer (that we guessed) points to the large amount of data we entered. Creating a large heap spray is an interesting aspect of the exploitation itself.

The second part is discovering the address of the code pages, as the heap is not executable. The system libraries are are prelinked in one giant blob. The reason this is relevant is because all the exact location of these libraries is only randomized once per boot (making it not position independent code). Once the base address of this library is known, this makes for an infinite amount of ROP gadgets!

The way that ASLR is broken is absolute genius! It uses a quirk of the iMessage interface: the showing of a delivered message. If a crash is triggered then no delivery receipt will be sent. Otherwise, one will be sent. They call this a crash oracle. The math on this takes a fair amount of time to go into, but it pretty amazing. By sending a maximum of 20 messages, we can break ASLR without ever leaking anything directly!

With how many different pointers a function has in ObjC, achieving RCE can be done with ROP using the NSSTRING path. However, newer versions of iPhones have what is known as PAC (Pointer authentication). So, exploitation is more difficult on these devices.

After this, I did not understand what was going on... So, the rest of this will be read by me later when I understand more. Overall, this was an amazing read though!

A few things really stick out to me:

1. A deep understanding of EVERYTHING is needed in order to exploit these types of vulnerabilities.
2. They break ASLR without ever leaking anything... That is freaking amazing!
3. They use IDAPython in order to find scripts that can find ROP gadgets. Good thing to know!
4. Bugs are everywhere...We commonly talk about web security because it is so easily accessible. Getting something working, with a very difficult setup, will usually work out in the long run with lots of vulns! :)

You think Paypal would know better... This is a fascinating bug though!

First, there was some CSRF and session tokens inside a JavaScript file. JavaScript files are not subject to the Same Origin Policy (SOP). So, a malicious site could make a request, cross origin, and retrieve the script! Meaning that this set of session and CSRF tokens was retrievable. This is known as cross-site script inclusion (XSSI).

After digging where these tokens were actually used at, he discovered that they were not used for normal operations... The only item these were used for was the security challenge for reCAPTCHA.

The response to the reCAPTCHA challenge is meant to reintroduce the authentication flow. Because of this, the response has the users plaintext email and password! This was also found to be possible to steal credit card information on Paypal too.

The flow for exploitation is not a typical CSRF bug though. The victim has to have the malicious site open while logging into Paypal for this to be possible. Interesting to see the large payout for a weird way to reproduce the bug.

The author uses a logout CSRF in order to make this attack possible (logout CSRF is traditionally not considered much of a security issue. So, this is everywhere). More information on the actual PoC can be found on reddit comments from the original author.

Contact info for this amazing researcher (at the bottom of the article). Email: alex@ethicalhack.ro

This article has an interesting mix of web and mobile vulns that help each other out!

Most web APIs are being smarter about what is being sent client side because it is easier to see. This goes to show that reversing and effort into difficult targets will pay off! Simply tampering a parameter made it possible to send a text message to any user as TikTok.

My main takeaway was the intent hijacking via the custom TikTok URI. By sending a link, to a user with the custom URI, they could direct users to different intents on the mobile device (even going to the browser!). This could then be used as a CSRF vulnerability. Super interesting CSRF bug!

Finally, there was a Same Origin Policy (SOP) policy bypass that was really interesting. The SOP enforces that website A cannot return data from website B, even though the cookies are automatically sent with the request. However, for some reason, JSONP and does not follow the SOP. By abusing the JSONP requests, it was possible to bypass SOP altogether.

Essentially, by using a bunch of awesome math, only two specific values are needed in order to break the random function in PHP.

Security people always say "use a secure random number generator" with very little to back it up. It is nice to see a working PoC for breaking rand.

With a black list of characters of '`;|$&{} ', this looks restrictive enough! But, by adding semicolons or tabs, we can execute arbitrary commands. A very clever idea :)

Additionally, there is a typo (in the source code) that ends up allowing for arbitrary content to be added to the timeout parameter.

Additionally, the regex [a-zA-Z0–9$_\-\.\+!*’(),] is too permissive for a URL, allowing for arbitrary code to be executed.

Vulns come in packages of the same type! Once one is found, keep looking for similar things.

This article demonstrates that exploitation can be tricky and messy, at times. But, being creative around what is available is really important for good exploitation.

It is very rare that an entirely new avenue of exploitation is found! This explains this new technique!

PHP have URL style wrappers, such as zlib, php and so on. The issue relies on being used for exploitation is phar://.

phar contains metadata in a serialized format.

If a phar object is passed into the unserialized function, it can potentially be exploited by abusing class destructors, constructors or wakeups.

The steps for exploitation:

1. Craft a phar file onto the server. But, this can be done in a JPG too.
2. This can be trigged within any file operation, including file_exists, filesize or other operations.
3. Using the constructor, destructor or wakeup call, do some operation.

I love the people at ISE! This is a list of vulns found on this NAS.

There are several cases of XSS within the application from not properly sanitized input. Josh found both reflected and stored xss.

Several command injection issues within inputs that require system level interactions.

The most interesting issue was the session fixation. If the PHPSESSID is set as a cookie prior to going to the site, then this cookie is used for the user.

All session tokens are stored within /tmp... Because any user can view folder, this all session tokens can be stolen by other users!

The file upload does not restrict the location of the path being uploaded to.

Finally, there are some unauthenticated SQLi injections and unauthenticated SQLi injections, additionally with a CSRF bug.

This blog post has an immense amount of findings in it, along with several POC's. Really good thing to read!

This was found in the XNU operating system, which runs on macOS and iOS.

The out-of-bounds write was thought to happen within a m_copydata function. However, it was a few lines of code later... It is interesting to me that Ian Beer (from Google Project Zero) messaged Kevin about this!

An error message having an unusually long header causes buffer overflow here.

The bug was found by using CodeQL, which is a variant analysis tool.

Word documents can have embedded Youtube videos.

By changing the content of the document.xml file within the Word document embedded HTML can be added!

Word documents are essentially just zip files if they are unpacked. So, altering Word documents actually is not that hard.

Interesting how the guys traces through code with IDA. He practically only uses the string command and looks through the import window in order to find the issues.

I just found the reversing process in this article fascinating. It's a really good walkthrough for Windows vuln hunting.