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!

A great overall description of heap memory corruption!

The main memory corruptions:

1. Freeing pointer that from malloc
2. Double free (freeing a pointer twice)
3. Use After Free
4. Heap Overflow

Interesting notes about malloc... If the MALLOC_CHECK_ is turned on then it will detect all double free errors. Additionally, malloc cannot detect trivial use-after-free and out-of-bounds bugs.

The reason for the name electric fence is that this is a tool to held find memory corruption bugs. This tool works by replacing malloc, free and related functions with special debugging versions of them.

Besides this tool, there is also Valgrind, DynamoRIO and Pin.

A Dangling Pointer is a pointer that a selected pointer has either been deallocated or is invalid altogether.

This article dives into what a dangling pointer is and how to exploit it in multiple scenarios.

Across several subdomains a single authorization token is used. So, the team tried finding an XSS bug within one of the subdomains that did not have the HTTPOnly protections turned on.

The XSS bug is a reflected XSS bug within the JavaScript in the page. Because of this, 'this kind of XSS would not be blocked by any XSS Auditor because it resides in the JavaScript itself and not consist of scripts or events'. I thought this was super interesting! What is actually blocked from the XSS auditor?

The mobile application had many debugging and reversing protections. Using Frida, among other things, did not work. It was discovered that the app actually spawned a process that had Frida already attached to it, making is impossible to add another process to it. To bypass the SSL pinning, they had to overload SSLContext and hook a different trust manager.

After getting the MCK (metadata-key) token from the XSS the login process can be hijacked by replacing the MCK in the login request with the stolen one.

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!