Back

TechnologySep 18, 2012

Stripe’s Capture the Flag 2.0 – Level 4

Josh Hamit

This article is part 5 of a 10 series blog detailing the approaches and solutions to hacking through Stripe’s 2012 CTF 2.0. To continue from the parent article, or see more hacks, please click here.

This blog entry details the approach used by Josh Hamit in attacking the Stripe CTF 2.0 Challenge Level 4.

***

Level 4 was a web application with a unique service offering called Karma Trader. It enabled people to reward others for good deeds. Users could transfer Karma Credits to each other. However, users were warned to only share Karma with trustworthy people, because your password would be displayed to whomever you transferred Karma. In addition, there was a user with infinite Karma Credits, named Karma Fountain, whose account password was also the password to Level 5.

Red flags for XSS/CSRF (Cross Site Scripting/Cross Site Request Forgery) should be raised anytime a user can directly insert content that will display on another authenticated user’s page. However, by this time it was getting pretty late and certain alarms just were not going off as clearly as they do in the morning.

But, we weren’t about to give up just because we had already worked a full day serving our clients, had already beaten thousands of others through the first 3 levels of the Stripe CTF competition, and had early mornings ahead of us. No, Crederians deliver. Crederians solve problems. And most importantly, Crederians like to compete! All of us wanted to be the first to solve the hardest level we had yet encountered.

Thus, we continued to scour the source code searching for any hint of a vulnerability. And eventually, we found a very unexpected one, even for Stripe!

This exploit was the result of several observations that we slowly pieced together after a couple hours of frustration, re-reading the same lines of code. These observations were:

  1. The application server was initialized with an in-memory database on startup

  2. The in-memory database was populated by the karma.db file on the web server

  3. The application server could be reset with the click of a button (originally included in case you got the web application into an unusable state)

  4. If you hit the site before the application server started, the web server would expose the file tree

Armed with these observations, we all furiously and repeatedly reset the application servers, switched windows, and refreshed the site page. Eventually, most of us were able to get the timing down after several different hot key configurations and pull down the karma.db. From this file we retrieved the password in a plain text format.

The next day Andre Azzolini, one of our team members, recounted an IRC conversation he had had with a Stripe employee. Evidently, we had discovered an unintentional exploit (which the Stripe team quickly patched) and the real exploit was much more common. So we revisited the problem with a fresh perspective, and the vulnerability quickly became apparent, especially after recognizing a hint Stripe had left us in the code. Namely, the fact that Karma Fountain logged in every few minutes to use the site.

The “normal” XSS solution first required that you create a user with a password that was actually a JavaScript injection attack. Then log in and donate some Karma Credits to a Karma Fountain. Then wait a few minutes. The next time Karma Fountain would log in, their browser would try to display your password, which would in turn execute your JavaScript. From this point it was easy to write a script, especially with jQuery, that would donate Karma to your account on Karma Fountain’s behalf. This way, the next time you logged into your account, Karma Fountain’s password was displayed.

Either way you slice it, we had made it to Level 5!

***

These solutions are presented as a unique approach to a recent CTF hacking contest as an outreach of the Credera Security Team. All ‘hacking’ was performed in an ethical manner in accordance with Credera’s Core Values. For further information on Credera’s offerings in ethical hacking, security, compliance, and OWASP preparedness please contact us at securityteam@credera.com

Have a Question?

Please complete the Captcha