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.


Practical Advice for Becoming a Software Developer

Back in early 2011, I dropped out of college with the intention of becoming a professional software developer. I wasn’t sure what it was going to look like, but I knew it was what I wanted to do. I ended up hearing about and attending an introduction to Ruby on Rails class hosted by Avi Flombaum. I had already started learning Ruby on my own, and I remember shyly bringing my very novice self to raise my hand and ask questions during his class. The result is that he noticed me, we talked after class, and he suggested we grab coffee. That turned into him making an offer for me to join his team at Designer Pages (which he was a co-founder of at the time) as an intern. That launched me on the fast track into becoming a well-rounded software developer, and he continued to mentor me until I landed my first job.

Not everybody is fortunate enough to find a mentor. For those people, starting out can seem much more intimidating and unreachable. What I’d like to detail is a few chosen bits of practical advice in response to questions about starting out that I get asked often. (more…)

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).