OSCP Certified

On December 1st, I took the Offensive Security Certified Professional (OSCP) exam and successfully earned my certification. For those unfamiliar with OSCP, it is a hands-on training course and certification offered by Offensive Security. The content it focuses on is immense; Everything from SQL injection to writing your own remote buffer overflow exploits is covered by the course e-book and videos. There is also lengthy coverage of how to properly enumerate hosts and take inventory of an entire network.


Client-Side Redis Attack Proof of Concept

Note: This issue is being discussed about a year late, as it was sitting forgotten in my blog post queue for some time. However, I have decided to post it now as it is still very much relevant. The attack explained below appears to still work on version 3.2.1 of Redis (tested on OS X and installed via brew). If the PoC fails and your inputrc file isn’t written to, it’s likely a directory permissions issue. Perhaps Redis is running as its own user, as it should?

The moral of the story is that even services on your own laptop that only listen on the loopback interface still need to be locked down. (more…)

Pokemon Go and Google OAuth

Recently, some Pokemon fans logged into their Google account and became very upset when they saw this:


Holy “principle of least privilege” issues, batman! An iPhone game has access to peoples Google accounts! And not just access, but full access.

Google is pretty clear on what full access means:

When you grant full account access, the application can see and modify nearly all information in your Google Account (but it can’t change your password, delete your account, or pay with Google Wallet on your behalf).

Certain Google applications may be listed under full account access. For example, you might see that the Google Maps application you downloaded for your iPhone has full account access.

This “Full account access” privilege should only be granted to applications you fully trust, and which are installed on your personal computer, phone, or tablet.

If you’ve granted full account access to an app you don’t trust or recognize, we recommend that you revoke this permission by clicking the Revoke access button.

Why would anybody ever give a video game this kind of access to their life?

Well as it turns out, iPhone users playing Pokemon Go didn’t exactly know they were giving Niantic this level of access to their data. That’s because when a user signs up for Pokemon Go, this is the OAuth flow they experience.


Cross-Site Scripting via DOM-Based Open Redirects

Consider the following JavaScript application which clearly contains a DOM-based open redirect vulnerability:

As if this weren’t bad enough, this application is less obviously vulnerable to cross-site scripting. Consider what would happen if the window’s location were set to javascript:alert().


This is effectively the same thing as typing javascript:alert() into the navigation bar in your browser and hitting enter. This behavior is unexpected to me, because it’s something I wouldn’t think modern browsers would allow. And it’s Yet the latest versions of Google Chrome (50.0.2661.102) and Firefox (46.0.1) both do. I cannot think of a legitimate reason for window.location= to execute code.

In conclusion: Don’t forget to submit your DOM-based open redirect bugs as XSS bugs from now on. They tend to pay out more in bug bounty programs.

Parameter Tampering Attack on Twitter Web Intents

Twitter’s Web Intents allow visitors of a website to interact with content on Twitter without having to leave the website. This is done by means of a twitter.com popup for desktop users, and native app handlers for iOS and Android users. This is the same platform powering the “tweet” and “follow” buttons you may see on webpages across the Internet.

I identified a parameter tampering vulnerability that in total affected all four web intent types. These vulnerabilities allowed an attacker to stage a Web Intent dialog with tampered parameters, which could then lead to a visitor following a Twitter user they didn’t intend to follow.

All four intent types were vulnerable: Following a user, liking a tweet, retweeting, and tweeting or replying to a tweet.


Regex Security Issues in Ruby

I see this kind of problem everywhere in the Ruby ecosystem, despite it being an old one.

Consider the regular expression /^https?:\/\/[\S]+$/:

So far so good. However, consider this:

This matches our regex because /^ matches the beginning of a line and $/ matches the end of one. This poses a very common misunderstanding of how Ruby regexes work. The impact of this varies from annoying unexpected input to cross-site scripting to remote code execution; it all depends on what is done with the input.

To properly match the beginning and end of a string, \A and \z should be used respectively.

Feature Flags with Rollout

Role-based authorization is a common requirement in modern web applications. In the Rails ecosystem, there are several great open source libraries that provide this (see devise’s roles, cancan, and rolify).

Feature flagging is a little bit different than roles. Features can be flipped on and off regardless of a users’ state. This means that if we want to test a feature for 50% of users, we shouldn’t need to move those users into a different role. We should just be able to declare that this feature is now flipped on for 50% of all users. The difference is subtle but important.

When BitLove approached this problem several years ago, there weren’t any good open source solutions for this. As a result we decided to roll our own and called it rollout. James Golick pioneered this project before I had joined the team, and it has since gained a large amount of popularity. It has even been ported into other languages (see proclaim, PHP rollout, and shoutout).