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

MongoDB Authori(s|z)ation

Introduction Having answered numerous questions on the new and old authori(s|z)ation within MongoDB, I thought I'd write a short blog post explaining how things work as there seems to be some confusion. What's New Prior to version 2.4 , there was a very basic sense of "Role Based Access Controls" (RBAC) within MongoDB as there were only two roles - read readWrite which is quite limited. For example, if the user has "readWrite", that user is essentially "root" and the user can add/remove users as well as inserting data into the database, i.e. there is no role segregation. Version 2.4 added in the following 3 core roles - userAdmin dbAdmin clusterAdmin with a notable extension such that there are now 4 roles that apply across all databases - readAnyDatabase readWriteAnyDatabase userAdminAnyDatabase dbAdminAnyDatabase This increased RBAC is a significant improvement from a security perspective in MongoDB. It is imp

Eurotash GSE

So I'd the pleasure of talking with Chris John Riley, from Eurotrash , on the night of Sunday, July 1st (yes, Chris isn't a football fan so I good-heartedly missed the half-time discussion of Spain's titi-taka brillance). Chris wanted to chat with me about my experience sitting the GIAC GSE exam and lab earlier this year. As always, I thoroughly enjoyed chatting with Chris and I hope it's not too painful listening to me on the podcast . I don't know much but what I would say is stay hydrated, eat as well as you can, prepare Source: http://matchphrases.com/images/large/legends3.jpg properly and have fun!! There's a reason that the GSE has a low pass rate, so going in relaxed makes a huge difference. Enjoy the podcast and if you've any questions on the GSE, just shout :)

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