With Bugcrowd’s roots in Australia, it’s always a great time to work with the security community from down under. Australia has some of the best infosec talent around, and this week’s Spotlight is on one of their bug bounty hunters: Justin Steven.
Justin is an early Bugcrowd community members, earning a top spot in our all-time total payout list and #31 on our global leaderboard of researchers. His journey has brought him modding the original Xbox to a full-time appsec role in a well-respected tech company.
Find Justin on Bugcrowd & follow him on Twitter @JustinSteven.
How did you get started in security research? How long have you been doing bug bounty work?
I’m not sure that I’m actually a “researcher”. I look up to those who I think of as researchers, the ones doing novel and original work, writing papers in LaTeX. I hope to do the same one day. For now, I’m just a do-er and a breaker, bashing out largely the same bugs in different places, and I try to be the best at it that I can 🙂
As for how I got started in security and appsec, I (mis?)spent my youth poring over textfiles and zines, admiring the phreaks of years gone by, falling in love with the culture and the community and the sense of curiosity that drove it. The first paper that I actually grokked was about softmodding the original Xbox, hot-swapping its IDE drive to drop font files (which weren’t covered by code signing) that would exploit the system dash on each boot. It was a feeling of “I couldn’t have found this attack chain myself, but it’s not voodoo magic. Get the Xbox to unlock its own HDD, drop files that aren’t covered by code signing, exploit a buffer overflow on boot because the font reports something lengthy in itself as being of 0 length or something and it confuses the system somehow. I kind of get this. Maybe one day I could be doing my own breaking.”
I jogged off to get my Bachelor’s degree, paid my helpdesk dues, and after some time landed an internal Incident Response gig. I got started in bug bounties around the time of Bugcrowd’s launch. Since then, I’ve moved in to a full-time appsec role and I’m loving it. I’m pretty sure if it weren’t for what I learnt from the bounty trenches, and if not for the portfolio it helped me to build, I probably wouldn’t be working in the role and capacity I am now.
Do you have a specific focus or specialty that you tend to spend your time on?
My absolute favourite class of bug is TOCTOU race conditions. It’s not often that you come across it, but when you do it can be devastating, especially in financial systems.
Functional/logic bugs, Insecure Direct Object Refs (simple but tragic) and OSINT tickle me.
I’m a fan of blind and not so blind Persistent XSS that comes from strange places or crosses unexpected boundaries – the hostname of an agent phoning home getting plonked on a dashboard, the name of a blog that you can invite another user of the system to collaborate with you on (“Justin invites you to join ‘My Blog<script src=…”), or a malicious security question popping up unescaped on a helpdesk analyst’s WebUI when you call up for support.
What motivates you to do what you do? What keeps you going?
I love the community. Some of my best friends have come out of chatting in the Bugcrowd IRC channel, sinking beers at cons, CTF’ing together (greetz to rand0ml0l2) and breaking things as a team.
I try to always be learning, and I look up to those who are breaking way harder than I am. Seeing what the real experts in the field can achieve makes me want to try new things and develop my skills across as many areas as possible.
Finally, the thrill of the chase. Finding your own squirrelly corner of an app to dig in to, thinking there’s got to be something there, and that rush when you hit pay dirt will hopefully never get old >:)
Any tips or suggestions that you would give to other bounty hunters?
Especially for the newbies – stick to the scope. It can be frustrating to think “but the client is massively exposed over there” or “a bug is a bug and the bad guys don’t have a scope” but you should still stick to the scope. If you’re thinking “but if I go out of scope I’m more likely to find stuff where no one else is looking” then you’re a bit of a jerk. The opportunity has been extended to you to look at certain things, be it because that’s where testing expenditure has been approved or because the risk of testing elsewhere is too much for the client to handle right now. The disappointment of an out-of-scope rejection, and the frustration you’ll cause the client for poking at what they didn’t want poked, isn’t worth it.
Have a good crack at the client’s focus-area if any. A happy client is usually a well-paying client. If you get the feeling that their focus-area was also focused on by the devs and just isn’t that chewy, give it a go then move on and give ’em hell elsewhere.
Always Be Closing. Clients will often realise the full impact of a bug or will take it through to (and pay based on) a logical conclusion that you didn’t or couldn’t dig through to, but in case they squash the bug without considering its full impact, make it known. Write a bit of JavaScript that bypasses CSRF or leaks sensitive data from the DOM so they don’t get comfortable with “Well our cookies are HttpOnly so XSS got nothing on us”. Find a way to bypass their CSP. Write a script that enumerates an IDOR if (and only if) you’re in a testing sandbox and won’t be touching sensitive customer data.
Once you’ve fleshed the bug out, write a great report – don’t let your awesome bug be let down by a two-minute “it’ll do” submission. Make it shine. A good bug reported poorly is a poor submission. Punch out a report that’ll be shown to management as justification for the program’s expenditure.
Digging deep and reporting well is fun, you’ll be happier with your own work, and you’ll often be better rewarded for it.
Finally, network! A lot of us mostly don’t suck. Learn from others, teach others, blog, mouth off on Twitter, know your tools, always be learning, develop your methodologies, stay sharp, and have fun!
What do you think of the future of bug bounties? Where do you see them going, where would you like to see them go?
Part of me believes that bug bounties have a bright future. Computers are hard, developers have a lot more than just security on their minds, and pressure from customers and PM’s has them doing the best they can with what they’ve got. The crowd is a fantastic and flexible QA resource that can come through to pick up the pieces that hit the floor. Given the state of things, and the effectiveness of the crowd, I don’t think it’s in much jeopardy.
Having said that, I do hope that as software engineering continues to mature technically (e.g. in terms of frameworks and exploit mitigations), and as companies realise the benefits of a good SDLC and proactive and thorough software engineering, there’s less of a need for after-the-fact security QA. Maybe the crowd will stay in business but will see less bugs as time goes on (and somewhat of an increase in per-bug rewards to compensate). [Editor’s Note: This will create new and interesting opportunities for the crowd!]
The selfish bounty hunter in me doesn’t want much to change, but if we’re still farming XSS in 5 or 10 years time as we are today, something’s wrong. We need to work on proactive security engineering just as much as we need to continue our reactive securing of engineering.
[Discuss this Spotlight on the Bugcrowd Forums]
