Skip to main content

Being the Bug in Bug Bounty :: Fail & Tell

Late in December 2015, I sent the email below to all of "Engineering" across Riot Games. I want to share this externally because it's core to the security culture that we want to build in Riot, i.e. one of accountability and responsibility, where we aren't afraid to talk about our screw-ups.

############################################################
Hey Folks,

So as most of you know, I'm a bit of a perfectionist with high standards :)

Well recently, I screwed up and didn't come close to meeting my own expectations.

What did I do?

Well, when testing (locally) Netflix's Security Monkey in 2014, I copied over some aws-related scripts I was using and found useful to a local directory on  my work laptop, where my Github repo was stored. I also mistakenly copied over a flask configuration file (config-deploy.py) from the local version of Security Monkey that I was testing at the time.

To compound this mistake, prior to committing files and pushing to my Github repo, I performed a "git add" on the sub-directory (aws), not the specific files I'd added. As a result, config_deploy.py was added to the changes to the repo and consequently, committed and pushed up to my personal Github.

What Happened Next?

Nothing for a year until I got a random late-night text from a colleague, nothing unusual there :)
  • Bug Bounty Ticket - xxxx
  • Internal Vulnerability Ticket - xxxx
However, this text was advised me to check our Bug Bounty system. The shear panic and "shit, shit, shit" went around in my head :-/ So unsurprisingly, I immediately logged on to  read the bug report.

What was the impact? 

Fortunately, close to nothing:
  • the file was a test file with no production credentials of any sort
  • we have publicly committed to the Security Monkey repo
  • we have publicly spoke about using Security Monkey
  • sheer embarrassment and annoyance on my behalf
What's the point of this email?
  • I'd like to apologise to you guys for screwing up.
  • To let you know that I've removed the personal repo and modified the controls on any public github repo that's been cloned to my system
  • This researcher was actually very cool (despite initially claiming it was an awesome vulnerability and significant information disclosure).
    • Validation is important on all (vulnerability/bug) reports coming in through our Bug Bounty or any other medium.
  • I feel like I got lucky
  • Run "git status" before "git push origin master"
  • .gitignore doesn't always save you :(
  • I got great support from the InfoSec team on this, which meant a lot and reminded me that we're a team at all times (success & failures).
  • Hopefully others will realise that it's not the end of the world to make mistakes and it's important that we don't try to hide them but share them and learn from them.
If you've any questions or feedback for me, please let me know.
############################################################

This episode was a huge learning experience for me and I believe I can only improve from it (whilst, yeah, I was lucky). It was ultimately a very humbling experience, a nice reminder that we in #InfoSec make mistakes, that we should not be advocating for security from the our perches up high, feeling perfect.

We have a "no asshole" rule and I believe this is one reason (of many) why I had a pretty awesome and very supportive response from many across Riot, a nice reminder that it's often better to talk about your failures than your successes.

Comments

  1. Totally true, every time I review code or search for a vulnerability, I am demanding, nonetheless when I found something, I always add "I could have done it, at least now it will be fixed.".

    ReplyDelete

Post a Comment

Popular posts from this blog

Being a Support Engineer @ 10gen - Part 1

There's a mis-conception around the role of a "Support Engineer".  As a clue, it's not what Urban Dictionary   says   - A person whose job is to answer calls from customers of a small- to large-sized company...... They are teathered to a their desk all day via phone headset........ phone jockeys usually hate their jobs.......they are are paid well enough..........until they completely burn out, and hate everyone.   and doesn't always involve this - Image Source: http://half-bakedbaker.blogspot.ie/2009/11/cannoli-and-broken-computer.html As you can see  here , there's lots of open roles in  10gen  and more specifically with 10gen, in  Dublin . I thought I'd write this quick blog to explain what Support Engineers actually do and why I joined 10gen as a "Support Engineer". I could be wrong but didn't Google come up with term " Site Reliability Engineer " to do away with the stigma associated with being a

What's the point of (InfoSec) Certifications?

Quite recently, my GSE was up for renewal. I'm currently in the middle of transporting my family to another continent and I've slightly more responsibilities work-wise in 2016 versus 2012. However, given the effort and study that it took to get the cert the first time (and to a lesser degree the expense), I figured it was a no-brainer to renew. For me, I've always been a huge fan of the GSE and considered it the epitome of InfoSec certifications, much like the CCIE for (Cisco) networking. Personally, I learn better by "doing" and consider it as the evidence that someone knows their stuff so the "2-day lab" element in the GSE was a both a huge goal and challenge that I was excited about. I talked about the value of "doing" when trying to learn about yourself previously here with the infamous Security Ninja and here on my own blog so there's no point in repeating myself. When I did the GSE, I absolutely loved the hands-on lab mo

Start-Up Security

After many years in Security @ Riot Games and eventually putting the "s' out there, I recently decided to jump out of my comfort circle for a new challenge and joined a   start-up   (yes, I left a comfortable, stable job in a pandemic, lunacy lol). Now that I've been here almost 6 months, I wanted to share some findings because security at a start-up is significantly different.  When you join a start-up, there's going to be so much that you can do and it will be incredibly easy to "boil the ocean", and try to fix everything. At best, this guarantees failure for the Security team, at worst, alienation from the engineering and product teams. There are some obvious quick wins that a Security team can make without slowing down iteration and innovation speed, while also reducing risk: Auth  Partner with Engineering/IT/CTO such that there's alignment on Security owning all things "auth(n|z)".  As part of this ownership, you need to be prepared to resp