Recon-ng + Google Dorks + Burp = ...

The other day I asked on Twitter, what tools Blue Teams or Red Teams wished they had. I’ll admit, it was selfish on my part because I really want to be able to build and sell a usable product. Anyway, @ethicalhack3r said he wanted a way to search for Google Dorks and get them into Burp to find interesting content. So I decided I’d take up the challenge.

Sometimes, I like to reinvent the wheel because I feel like I can make a better wheel but I knew Recon-ng already had Google Dork searches built in and had a method for dealing with Google’s CAPTCHAs. And, as much as I’d like to think I could make a better wheel than Recon-ng, I know I can’t. So I figured the next best thing would be to build a report module that could take the URLs found using Google Dorks and send them to Burp, so that’s exactly what I did.

When the recon/domains-vulnerabilities/ghdb module is run it uses a large number of Google Dorks from the Google Hacking Database to search a site for interesting content. When it finds matching URLs they are placed in the vulnerbilities database with the category ‘Google Dorks’. Recon-ng can run direct queries on the database so I was able to search for all of the URLs where the category matched ‘Google Dorks’. Once that was done, I used the request method to get each URL. The trick to getting these URLs into Burp is to set the global PROXY value before running the report and then unset it after running the report.

To use the new reporting module:

  1. Run the recon/domains-vulnerabilities/ghdb module and gather the dorks you want.
  2. Set the global proxy:

    • Use the back command to leave the module context and enter the global context.
    • Use the set PROXY http://<your_proxy_here> command to set the global proxy
  3. Enter the proxifier reporting module using the command use reporting/proxifier.
  4. By default the module will find the vulnerability URLs with a category of ‘Google Dorks’ but any query that yields a list of URLs can be used. If you would like to use a different query that yields URLs then you can use the set SOURCE query command.
  5. Run the module with the run command.
  6. Unset the global proxy:

    • Use the back command to leave the reporting module.
    • Use the unset PROXY command to unset the global proxy.

Thanks to @ethicalhack3r for the idea and to @LaNMast3r for recon-ng and help writing the module.

A Blessing From The Lord

This is not my typical post but it’s something that needs to be said.

It is not an exaggeration to say that I wouldn’t be the man I am today if it were not for my wife. For 16 years my wife has patiently and lovingly knocked off my rough edges. Sometimes, all it took was a gentle elbow to the ribs and other times it took a constant knock to the backside of my head (sometimes literally.) When she met me, I was a lonesome and lonely person who didn’t like people. I was generally to busy to be bothered by others, was impatient with other people’s mistakes, and was constantly putting my foot in my mouth. Over the years, she has helped me to become much kinder, more patient, and gentler with my words. I still don’t like people, but there are a number of persons I like because she has pushed me to make friends and to be sympathetic to others.

Why am I telling you all this? Because I love my wife and I want everyone to know it, especially her. My blog and Twitter are the largest public platform I have so I’m going to use them to shout, “GAIL, I LOVE YOU MORE THAN YOU KNOW.” I don’t deserve a wife who is so patient, loving, faithful, and kind but that is what I have and she truly is a blessing from the Lord. I can honestly say that I know what Love is because of her.

I love you Gail and I hope that I can always be the man you believe I am.

Interview With A Senior Penetration Tester

I am currently a Senior Penetration Tester for AppSec Consulting and I was recently asked to conduct initial phone interviews for a new Senior Penetration Tester position we are trying to fill. It’s been a while since I’ve done interviews so I wasn’t thrilled about it but I took some time to think through a few interview questions and began the process. The more I thought about the interview process the more I thought it would be helpful to share the questions I ask and the answers I would expect to receive from a Senior Penetration Tester.

Do you have any publicly available resources that I can review to better understand your skill set?

I want you to say yes and then provide me with a list of those resources. Got a blog, Twitter/Github/Bugcrowd/Hacker1 account, any CVEs? I’m looking for anything that will show me that you are passionate about Information Security and giving back to the community. If you don’t have any bugs under your belt, I’m not really worried about that. I want to see that you are doing some type of research, tool writing, teaching, etc.

Why am I looking for this? Often on a penetration test it is necessary to take a working proof-of-concept and turn it into a useful tool/exploit. In addition, it will often be necessary to supervise Junior testers and guide them down the path they need to take, blogs are a good way for me to determine if you have the communication skills necessary to do this.

Give me an overview of how you would conduct a blackbox external network test or a greybox web application assessment.

I want to hear a detailed list of steps you would take to perform these tests. I don’t care if you pause, say umm, whatever but I don’t want to hear, I guess I would do this or that. If you do not know your test plan off the top of your head or can not articulate it to me then you are not ready to be a Senior Penetration Tester. I realize that every test is different and that some steps will change depending on what you run into but there are certain actions you will always perform and you should be able to express those clearly.

If you are looking at these questions and wondering where all the technical questions are, there are none. I don’t care if you have all of the Nmap flags memorized or know all of the Metasploit modules by heart. What I need to know is if you can size up the situation you are in an make a plan of attack. Reading your blog, looking at your code, or reviewing bugs you have researched will tell me all I need to know on that front.

As I write this post, I realize that the primary difference between a Junior Penetration Tester and a Senior Penetration Tester can be boiled down to autonomy and ownership. For example in my role as a Senior Penetration Tester, I’m typically given a Scope of Work and the client Points of Contact. It is my job to contact the client and verify the scope, make sure they understand the testing I’m doing, and make sure that testing is what they expect. There are times when the Scope of Work and the client expectations don’t match or times when expectations will need to be adjusted mid project. I am responsible for helping the client understand why their expectations need to be adjusted and what their expectations should be.

In addition, when I submit a report, I’m expected to take ownership of that report, I am essentially saying, I performed this test to the best of my abilities and I stand behind the findings, or lack of findings. When a client pushes back on the severity of a finding or asks for justification for my finding, I have to be ready with an answer and I have own that answer.

Am I saying that technical prowess doesn’t play a role in whether a candidate is a Junior or a Senior, absolutely not but technical prowess comes with time and exposure to various networks and systems. I am saying that no matter how much technical prowess you have, if you can not be autonomous and take ownership of your work, you can not be a Senior Penetration Tester in my book.

Sometimes You Need A Lot of Proxies

After building and testing my Facebook Phone Enumeration script, I realized that if I want to run the script at scale I’m going to need a lot of proxy servers so that Facebook doesn’t kill my enumeration. So I modified my script to build out a number of proxy servers, create the appropriate SSH connections for a SOCKS proxy, and then build a proxychains.conf file. I’ve tested the script on Kali Linux running as root. If you decide to run it on a different setup let me know how it goes. You can find the script here.

To setup your proxies run the script with the create command: create 10 ids.txt

This will create 10 droplets and store the droplet ids in the ids.txt file so they can be cleaned up later. Be patient because creating droplets takes time. After creating the 10 droplets, it will create an SSH -D connection to each server. Once all of the SSH connections are created, the /etc/proxychains.conf file is written to use one random proxy server per request.

Once you are finished with the proxy servers you can destroy all of the droplets using the script: delete ids.txt

This will read each droplet id stored in the file and destroy the droplet. This will also delete the /etc/proxychains.conf file. To clean up the SSH connections you can use the following bash one-liner:

ps -ef | grep [S]trictHostKeyChecking | awk '{ print $2 }' | xargs kill

Facebook Private Phone Number Enumeration

I started playing around with the Facebook bug bounty a few weeks ago and submitted a few issues that I considered bugs but wasn’t sure if Facebook would. I wanted to get an idea about what they considered a security/privacy issue and what they did not. Based on Facebook’s bug bounty details, vulnerabilities that reveal public information are not eligible for the bug bounty program. Public information includes your profile picture, username, ID, name, current cover photo, gender, and anything you’ve shared publicly.

While playing around with the account recovery feature of Facebook I noted that you could enter either an email address or a phone number and it would return a list of users that are related to the information provided. This allows you to choose your account and continue the account recovery process. I decided to try a little experiment with my account created specifically for bug hunting. This account had no data associated with me except my email address. I entered my email address in the account recovery form and immediately found my account. This email address is my primary contact information so I can’t make it non-public.

Next, I decided to add my mobile phone number and I set it to Only Me, which implies the phone number is not public. Based on my email interchange with Facebook, they disagree. Anyway, I returned back to the account recovery page and entered what I thought was my private phone number. Facebook immediately brought up my account using the phone number. I then deleted the phone number from my account and tried again. Facebook still associated my private phone number with my account.

At this point I realized that anyone who added a phone number to Facebook expecting it to be private (Only Me) would have that private number associated with their account. If you could enumerate a large number of accounts using the phone number then you could associate users with phone numbers they haven’t made public. I submitted a report to Facebook to inform them that I could enumerate private information and they said,

I’m sorry, but we will not reward this submission. Information about recovering an account (ex: discovering another user’s recovery question or viewing some of their friends to recover an account) isn’t a security vulnerability on its own, as Facebook doesn’t guarantee the privacy of this information and it’s not considered sensitive.

Also, there are protections for account recovery information. For example, before showing security questions or friends to unlock an account, we check if the request seems legitimate. Legitimacy is determined by a number of factors like IP and information about the computer being used to log in. There are also protections which would stop any larger-scale abuse of this feature.

I think they missed the point. I don’t care that I can view friends, recovery questions, etc. I care that a “private” phone number I gave to Facebook is publicly associated with my account. I then asked,

If I can show that your protections against large scale abuse of enumeration are not effective would that make a difference?

Their response was,

Thank you for the proof-of-concept code! One of the reasons we don’t consider this as qualifying under our bug bounty program is that we have rate limiting in place which would kick in once you submitted enough requests. The code may work for a small amount of phone numbers, but you wouldn’t be able to enumerate a large batch.

As mentioned by Samuel, we also only show certain recovery options based on numerous factors including whether you’ve logged in on a specific machine before, or on the same network.

Facebook has the final say in all bug bounty submissions and even though I was frustrated, I dropped it and asked for permission to disclose. Since Facebook does not consider this a security or privacy issue they granted permission.

If you’d like to test this out yourself, add a phone number to your account and set the permissions to Only Me. You should then be able to logout and attempt an account recovery using the phone number you provided. If you’d like to try this at a larger scale you can use the proof of concept code on GitHub.

Here’s some sample output from the script:

$ python
Heather AndLuis Rojas -

4233103103 - None

Kenneth Walker -

Suzanne Churlik -

Happy Hunting.