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!

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! :)

One issue with infecting a computer is that other computers have tend to have a lot of malware.

In order to combat this, the ransomware would set other ransomware to go into an infinite loop.

It’s a clever way to ensure that the other program doesn’t run anymore…

When looking at the raspberry pi camera API, this person found an RCE via input being sent during a command.

When looking through PHP applications, simply just grepping for malicious functions can net some serious vulnerabilities! In this case, the system function caused a major vulnerability.

The date binary can be used for priv esc :)

This application also had a directory traversal vulnerability that allowed for arbitrary file reading.

Penetration testing is soo hard! We always read about when the stars aligned and the person gets the shell... This article is about the person not getting the shell.

Diving into the shell... Map out the shells capabilities and see what is going on. Are these custom, out-of-date or standard binaries? What flags are allowed to be used with the command?

Interesting how they figured what shell was being ran...By seeing an error message for a particular option.

Just watching the progression of all the thoughts and ideas for the penetration test (even the mistakes) was really interesting!