He hit the trinity of why companies fear bug bounty programs in one post:
Their development cycle wasn’t fast enough for the researcher. Is six months a “more than reasonable time frame”? On the surface sure but unless you go to their planning games, know their regulatory commitments, roadmap and backlog you can not say that for sure.Most companies have enough internal and contractual pressure on their development cycles to have a researcher who is “helping” add another source.
The researcher involved the press:Companies do not want to be in the press for having poor security. So sure when he contacted the press they fixed the issue but it didn’t win him or security researchers any friends at United.Companies do not want to manage a bug bounty program as a fire fighting exercise. They want to intake the bugs into their regular development cycle and work them in their normal process.
The researcher went “rogue”: He wasn’t going to get compensated for his work since it was a duplicate so the only kind of compensation he could still get was to go public. Companies cant pay for every duplicate bug found and it only takes one researchers to go rogue to sour a bug bounty program for a company.
While I do not fault Randy for his blog post or thought process a company gives up a lot of legal cover by running a bug bounty program. If they do not perform to a researchers expectation and they get called out in this manner is a reason for them to think twice about their program and if it is worth it.
I have been using censys.io a lot lately to do network reconnaissance and noticed they just released a new API that didnt have a CLI frontend so I spent sometime writing a python based one. You can grab a copy here.
The project is in a limited beta so I decided that a good test would be to install one of their certificates on to a Nessus scanner I host in AWS.
The install wasn’t complicated and only took about 15 minutes and 9 commands: cd ~
git clone https://github.com/letsencrypt/letsencrypt
./letsencrypt-auto --agree-dev-preview --server https://acme-v01.api.letsencrypt.org/directory auth
sudo service nessusd stop
sudo cp -i /etc/letsencrypt/live/scan.jerrygamblin.com/fullchain.pem /opt/nessus/com/nessus/CA/servercert.pem
sudo cp -i /etc/letsencrypt/live/scan.jerrygamblin.com/privkey.pem /opt/nessus/var/nessus/CA/serverkey.pem
sudo cp -i /etc/letsencrypt/live/scan.jerrygamblin.com/chain.pem /opt/nessus/com/nessus/CA/cacert.pem
sudo service nessusd start
I wrote nocommonsssids to quickly remove the top ssids (from wigle.net) from the preferred network list in OSX so that it does not auto connect to them.
Running this will help stop you from being caught by an EvilAP attack along the line of the Mana Common demo I put together earlier this month. You should also run a VPN anytime you connect to a public wireless network.
I wanted to use this opportunity to make a bold statement since I knew there would be influential people in the audience who wanted to listen Nicole talk about her new cyber security auditing initiative.
My project used in conjunction with a Ralink 5370 Chipset USB Wireless Card broadcasts 7 of the most popular SSID’s according to wigle.net. Protip: It is easily modified to target smaller audiences who may have saved corporate SSIDs on their devices.
Here is a demo of the terminal output:
Here is a screenshot of my iPhone picking up the networks:
If you have any questions please reach out to me on twitter @jgamblin.