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 pointer is created; but, only when going down certain paths. But, the value is still used later on! So, it is possible to send a request that goes around the switch statements creation of the pointer. From here, the out of bounds write can be turned into an RCE.

The other two vulns are created because no bounds check is done while writing data.

Additional article with a subtle vuln: off by one. This is not the most exploitable thing but could be the entry point into deeper memory corruption bugs.

What is an iFrame Buster: "iFrame Busters are HTML files hosted on publisher sites which allow ad creatives to extend outside of their standard boundaries".

Essentially, ads are creating XSS vulns in sites. These iFrames Busters used regex's to validate that only a proper domain was allowed. But, these regex's could be abused.

The XSS is created by allowing any site to load scripts.

Most of the vulnerabilities come from a bad whitelist regex function.

The last vulnerability in here described is pretty clever! He double encodes the URL to escape the check for periods, how to access files. Further, he uses the # sign at the end to negate the rest of the payload. Clever!

Hardware security is almost an impossible thing to do. In principle, the problem is trying to keep someone who has the physical device from doing stuff on it... This is such a hard problem!

This pdf is one of the very few pieces of research done on the Apple Secure Enclave :). Understanding hardware security is fascinating!

Opening line of the article: "Recon plays a big part in the bug bounty world. ". This is probably the most important step!

Using deeplinks on the Facebook mobile application (fb://) allowed for arbitrary URL redirection.

This was found by decompiling the app then using an automated script to find all parameters within these URLs. Good use of time!

This article has a ton of statistics about Rapid 7 Penetration Tests. This report also has some fun stories :)

A synopsis is not reasonable for this article; just go read it yourself!

Understanding the default encoding of a project can help out quite a bit when pentesting something! Sometimes, adding a simply poop emjoi may cause the request to be handled funny.

Also, sending non-sensical values to something will cause weird issues…So, do not be afraid to fuzz! This SSRF was only possible with a zero-length body on a request.

The questions to ask:

1. How is the information being altered?
2. How can I exploit the alteration of this information?

Recommended using https://www.npmjs.com/package/safe-url-assembler to prevent these sorts of attacks. Sort of like a parameterized query.

Upon page load the address bar could be changed via JavaScript. When requesting a page to an non-existent port (of a URL) the address for this would be loaded, but then the current page would still stay there!

This results in a completely spoofable address bar :)

When messaging the guy on twitter, I asked him 'How he figured out the race condition'. His response: 'I had noticed a delay with requesting a resource from a non existing port. That was sufficient to conclude address bar spoofing'.

This was a great discovery :)

There is a really interesting logic bypass here! When creating an email, it was not possible to create an email with google.com. But, by creating an email (that is unverified) then changing the email, this check can be completely bypassed! Really awesome logic bug :)

Another interesting logic issue: staring an issue (on Google Bug Tracker) would allow them to see insider information on the bug!

Finally, an API call added permissions while it was being called... This is HORRIBLE! This was on the unsubscribe feature haha. You never know where you are going to find a bug!

Some workplaces require employees to sign up with their @company e-mail address. This guy figured out how to use service emails in order to login to internal only Slack chats!

For instance,GitLab offers a feature to create issues by e-mail by sending them to a unique Gitlab email. Buy using this email, the user was able to join the internal slack channel of Gitlab!

Another common place that this was found was with Support Desk features. By manipulating how emails were being sent across different platforms for support, magic links were clickable in order to sign up for the slack room.

By abusing the above flaw, all emails being sent to support@ can be read, giving us the ability to use password reset links for things like twitter and so on for other companies. This is because software, like Zendesk, create tickets automatically for a given email!

Lessons learned (from the article)... Once inside, most company’s security is significantly weaker. Internal impact assessments showed employees pasted passwords, company secrets and customer information in channels everyone in the team had access to...

Lessons learned (from the article)... We need to keep looking for security issues in all possible places. This vulnerability existed for years in hundreds of websites screened by security professionals, but as far as I know, nobody found it... To me, this is really hard to find because it took several pieces of software being abused, at the same time, in order to find this!

Overall, amazing article (this took me a while to understand). But, this is up in the clouds as one of my favorite articles ever! :)

Although using security controls on the client-side is a really bad idea, reversing minified JavaScript is not fun at all! I thought this was a really funny comment :)

The application had an overlay, over the main content. After erasing this DOM element and changing another element from hide to shoe the movie content started to display!

At this point though, the content would play for a second then stop playing.

In order to complete this exploit, a piece of JavaScript was added to the console to just 'click' the play button continually!

This vulnerability was hilarious and had a funny ending! :)