My name is Justin Kennedy, I generally go by jstnkndy or juken. I’m located on Boston, MA. I’ve been hacking since the early 2000’s. I started getting interested in “hacking” probably in middle school when I got my own computer; though what I was doing at the time wasn’t really any form of actual hacking, but really just trying to get friends to open up things like sub7 or netbus (wait… which one do I run to actually control their computer now? server.exe or client.exe? Eh, I’ll just run ‘em both ;)). This was around the same time I started learning about networking so that I could have LAN parties with friends.
A typical day for me starts at 6:30AM, waking up and spending 30 minutes or so checking twitter, slack, reddit, etc… pretty much everything security related.
After making coffee I sit down to work for the day as an Penetration Testing & Red Team lead; that usually involves working on active pentest or red team projects, writing reports, doing presales, etc…
Throughout the day I spend time on twitter, slack, and reddit keeping up with anything interesting going on in the security world. Once work is finished up for the day I’ll spend a couple hours looking at bounties (more if I’m really onto something).
When my wife gets home from work I’ll go afk (though I’ll keep my phone on my and peruse the aforementioned social media channels every so often); It’s really important to get away from the computer and spend time with the important people in your life.
You can probably gather from my answer that bounties are a hobby for me, not a job :)
I probably spend 20 hours a week on bounties on average. As I’ve mentioned several times in other places, I’m attempting to submit 365 bugs in 2017; thus far I’m ahead of schedule with about 30 - 40 bugs a month. Some programs you work on you just keep finding bugs, others take a bit more time, so the numbers are bound to change.
As I had previous experience with application testing, my first bounty came pretty quick. I think it took me an hour or so to find that Account A could modify data on Account B’s profile, resulting in $500.
My favorite bug was from a private flex program that was run CTF style. There were 3 tenant environments, each with a flag.txt in / on the servers worth $5k. I actually didn’t start this private program until the last few days of the program but figured I’d poke around a bit anyway as it seemed that no one had captured any flags yet.
The researchers started from one machine inside of one of the environments (not one with a flag.txt, obviously); nmap’ing the environment showed several hosts with SSH open on them, one of which allowed my researcher credentials to login.
After logging into that host I was looking through the filesystem for anything interesting when I came across a configuration file that contained the IP address, username, and rest API key for an instance of CliQr (some application cloud management software).
I setup some SSH tunnels so that I could hit the REST API via burp and found that the API keys were valid for that instance. Reading through the API documentation I found I was able to extract the AWS Access Key and AWS Secret Key from the CliQr instance.
The AWS credentials were valid and allowed me to clone the existing servers and spin up new ones with my own SSH keys, then login to them to get the flags.
One of the reasons this was one of my favorite hacks was that I had no experience with AWS prior to this really, so it was a lot of documentation reading for me. I ended up writing up a full pentest style report for this bug and was awarded $13k ($2k was given to someone else who had submitted a good writeup prior to mine but that person didn’t get any flags; it was a weird situation but I was happy with the outcome).
I always knew that I wanted a career in computers; then when I started messing around with “hacking” as mentioned previously, I knew that it’s what I wanted to do for a living full time. My dream job has always been penetration testing, so I worked my way up the ladder from: IT intern -> help desk -> SOC -> Network Defense -> Junior Pentester -> Pentester -> Principal Pentester -> Director (where I am now).
I spend a lot of time on twitter, slack, and reddit… Probably more than I should, but it seems to be working out thus far :)
I haven’t done a lot of collaborative hunting in the bounty world. I’ve helped other folks out here and there, but we haven’t done a lot collaboratively. I do chat with a lot of hunters online constantly though :)
In my day job I work with my awesome team (unofficially called FoxGlove Security) Steve Breen, Brandon Edmunds, and Brandon Perry.
I’m going to try to actually walk through my methodology here (at least parts of it), which a lot of people have asked me for recently… It may be a bit scatter brained because hacking is a balance between a science and an art, so I may go off on some tangents. There is no one single methodology that can be written for hacking because you as the hacker need to be able to adapt and depending on the way an application responds you may try one thing or another thing. Not to mention a lot of things I try tend to be based on experience and tribal knowledge.
My initial recon will depend on the scope of a program. Programs that have *.domain.com I’ll do the following to get an idea of live targets:
Subrute to identify subdomains and IP space
Scans.io (DNS and SSL) to identify subdomains and IP space
Github (one of the most overlooked recon vectors out there) for any information such as credentials (often P1’s), hostnames, API example, etc… Don’t forget about that commit history either!
Once I have an idea of the subdomains and IP space I’ll start running port scans (I do quick port scans first for common web ports, then I’ll feed those results to httpscreenshot, then I’ll do full port scans and feed those results into httpscreenshot).
The results of httpscreenshot will often visually show me easy targets (websites that look like they were created in 1995); but of course this will depend on the scope of the program. I may also see off the shelf software here which I’ll go Google default credentials for (easy P1).
When I get to a point where I’m actually starting to assess an application, I make sure that I have burp on one monitor, firefox on another monitor, and I walk through the application. I make sure that burp is configured to only show my in-scope items (usually I’ll do the *.domain.com and anything Amazon related so see those s3 buckets). If I do see S3 buckets, I check to see if I can read them (with or without existing AWS creds) or write to them (https://www.youtube.com/watch?v=_x5VKuFjvrk).
If the program has multiple roles and allows me to created new user accounts, I’ll create two accounts per role to check for horizontal and vertical authorization issues. This can be done manually pretty easily, but some people may also want to use something like the burp plugin AuthMatrix (if you don’t want to use AuthMatrix, I still recommend understanding how it works, what it’s doing, and why, that way you can test those things manually). Things I check for across multiple accounts are:
What are the functions than $role can perform? Can I perform these functions as a non-$role user (send the request as the $role to repeater, change the cookies to that of a non-$role user, replay the request)?
Can I view or modify data on another user’s account? Is that user an administrator or a standard user? Should I be able to view or modify that data?
The entire time I’m walking through the application I’m watching the requests in burp history to see how the application works. I have several payloads for different vulnerability classes such as XSS, XXE, SQLi, etc… but I try to balance checking for these things myself and letting burp check them (speed is a factor in the bounty game, so you need to be as efficient as possible out of the gate). For example (this section ended up turning into a bullet list of common checks I do, so I’m just running with it that way):
I can easily throw <svg onload=prompt($random_number)> into any field I see and see if it’s reflected or stored (and if it’s stored, it might fire somewhere else in the application, hence the $random_number which I can then use burp’s search functionality to find the request with that payload) myself without too much time lost
In contact forms, if they are in scope, I’ll throw xsshunter payloads in them to see if I get any hits.
If I see any XML, I’m immediately checking for XXE with <?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE foo [ <!ELEMENT foo ANY ><!ENTITY xxe SYSTEM "http://xxe.dns.domain.com/?xxe" >]><foo>&xxe;</foo> (side note here, if you haven’t already, go setup out of band DNS checking capabilities for yourself, it makes things so much easier. If you need help doing this, ping me, or I’ll put it on github or something).
If I see POST/PUT/PATCH etc… requests, I’ll attempt XXE using the same payload above, but I may need to change the content type to application/xml, text/xml, etc… (https://blog.netspi.com/playing-content-type-xxe-json-endpoints/)
Check for SQL injection is places where I know a backend database is going to be checked (does this username exist during account creation? Does the application need to lookup this ID in the database to return the proper content to the user? Is this password reset token valid?) etc…
I had success recently with Server Side Template Injection, so I check this by following James Kettle’s writeup here: blog.portswigger.net/2015/08/server-side-template-injection.html.
What I’m trying to say here is let the scanner do the things that it’s good at while I focus on the things a scanner is not good at, like finding logic bugs. (Side-note on this, don’t just right click the application in the target pane and actively scan (if you do this, you don’t deserve to be on the program because you can really cause a lot of noise and headache for the program owners)). If you’re going to active scan, send the request you want to fuzz to intruder (right click -> send to intruder), select the values you want to actively scan, right click on them, and “actively scan defined insertion points).
Exploring the application’s functionality is extremely important; I can’t know what might be possible with the application if I don’t explore the functionality. This is the part where it’s not possible to have a "one size fits all” methodology. (consulting side rant here: if the way you scope an application is asking how many static and dynamic pages there are, you’re doing it wrong).
If at any point in time the application looks like it’s reaching out to a URL at all (perhaps checking the XML file for an RSS feed), I check for SSRF. Point it at a server I control and check to see if I see the DNS request and the HTTP(s) request. If the application doesn’t want to accept parameters/other ports in the URL I provide, I setup a redirect to a URL with parameters/other ports and see if it follows that.
After I’ve walked through the application, looked at the functionality available to me, and made sure I’ve tested the parameters, I’ll start looking to discover more content. Burp is generally pretty good at putting files and directories in the Site Map, even if you didn’t hit those pages directly but they may exist, so I’ll look to see if there is anything I didn’t see. I’ll also look through minified javascript files (jsbeautifier ftw) to find other endpoints that Burp may have missed. I’ll also use wfuzz or burp to discover new content based on the raft wordlists (choose your wordlist based on case sensitivity to save yourself some time).
When it comes to mobile application, I have both a test Android device and an iPad, rooted and jailbroken. For each of them I have them setup to bypass SSL pinning. One of the first things I’ll do is grab the APK, decompile it to source, and look for any hardcoded credentials that are easy wins. Lately I’ve even had success downloading archived APKs of the application and finding validate credentials. Looking through the source gives me an idea of what API endpoints I can attempt to work with. I don’t tend to look for local vulnerabilities themselves (insecure storage of sensitive data) though I probably should. I also haven’t done much in the way of insecure broadcast activities, just because I don’t have as much as experience with it.
That’s about it off the top of my head, really. I’ll check back on older programs after some time to see if they’ve introduced any new functionality.
No, using Bugcrowd’s VRT, I’ll only look for P1’s, P2’s, and P3’s. Sometimes a program might consider a vulnerability I’ve submitted a P4, but going into it I considered it either P1, P2, or P3. It happens.
I use whatever tool is going to make sense for the task at hand, that may be wfuzz, sqlmap, binwalk, metasploit, etc… The burp extensions that I use are: J2EEScan, SAML Raider, Content Type Converter, Backslash Powered Scanner, Active Scan++, UUID Issues, and I’ve just started using Auth Matrix a bit.
A combination of manual and scanner checks as mentioned above. Computers are great at finding things like SQLi quickly. RCE isn’t a vulnerability class in itself, scanners will easily find command injection and object injection quickly whereas I’ll find SSTI, file uploads, imagetragick, deserialization, etc… I check for SSRF manually when I come across any functionality that looks like it’s going to reach out to a resource (either local or remote).
All of the time. I recently submitted 21 bugs to a program over a year after it started. Stats on those bugs:
18 Valid
Two Duplicates and one N/A (I actually double submitted a double on accident after a long day of bug hunting, whoops!)
Yes, absolutely. I think starting out in any of what I consider the core areas (networking, systems administrations, or programming) with a focus on security is the best way to do it.
Bounties are getting to the point where it’s not only web apps, so getting your feet wet in any of those areas above should be beneficial.
Foo Fighters are easily my favorite band. I generally like anything except for country music. Though I hack in silence.
I don’t understand the question.
Kidding. My wife and I travel on vacation a bit to various places, either relaxing vacation (somewhere tropical, Hawaii in a couple weeks actually), or on active vacations (last year we did a 5 day trek to Machu Picchu). I also play in a skeeball league, play squash, play D&D, etc…
They’ve allowed me to continue sharpening my hacking skills, making some money on the side, and meeting some really awesome people.
Not with my bounty career necessarily, but when I first started getting into application testing: “Learn burp”
Binary exploitation. It’s something I’ve picked up and put down so many times. It’s one of those things that if you aren’t doing it consistently enough, it’s easy to forget the intermediate knowledge.
I don’t think this question was for me, but I’ll answer it anyway. Peanut butter and banana slices.
While I’ve had some disappointing exchanges with several programs, nothing has really been that bad.
Mongo from the congo.
The only two platforms I’ve worked on have been BC and H1, so for each of them:
BC - I’d love to be able to make reports public H1 - I’d like the reputation system to be more aligned with BC’s VRT