Brute-forcing Enterprise with Python, Selenium and PhantomJS
Before you proceed: we will be exercising all possible worst scenarios put together in this post, if you are looking for sophisticated attacks you will not find them here, but you will be surprised how common examples I bring up here are.
I have been thinking lately about little security aspects in distributed enterprise applications. As we know enterprise applications (distributed or not) are designed to satisfy, first of all, business needs and not the needs of an individual end user and one of the main properties or characteristics of the enterprise application is persistent data! Most (if not all) enterprise applications are designed to aggregate, store, analyze and report vast amounts of data and we will try to access it!
Very few companies make large investments into architechturing and building their well-designed business applications from scratch. And it does make sense, the reasons for that are potential competitors and fights for the revenue and customers. If we will spend our time engineering and not actually delivering and catering for the customers we are screwed. Over-engineering as a topic topic deserves it’s own post, since almost all of us (somewhat) experienced developers love spending hours and days making clairvoyantly brilliant (as we like to think) overly engineered decisions; we love playing psychics and making predictions in the fields we are so far away from.
Anyways. Considering all that, the most common practice is to build something really quick that does what it supposed to and adjust and patch along the way, or buy a ready to use, somewhat customizable third party solution and customize along the way. As time passes and business grows, the amount of data and amount of business users who work with this data grows, we always build a little patches, extensions and not really legal entry points to satisfy data manipulation and management requirements. These illegal entry points is what we will be targeting in this post.
Lets create an example of the such illegal entry point to our datastore. Lets say, Anna, a very creative individual from the distribution center discovered that if she could add a property to some of the warehouse items, she would be able to generate very helpful reports that would help her making critical business decisions. She comes to the software engineer Joe, and asks him if he can make it happen. Always busy and always willing Joe says “No problem” and, since they use hardly customizable legacy, lets say IBM, software, he creates a small web application that skips all legal IBM application routes and talks directly to database, allowing Anna to search for items and add, edit, delete their properties. I think pretty common scenario… No?
This small application is open to general public, and protected with a password. Lets pretend Joe didn’t care about username since Anna is the only active user and and she is the only one who knows the URL to this application.
For the demonstration purposes lets create a small Python application that will be protected with the password and lets be completely careless and have string “abba” (“Dancing Queen, You can dance, you can jive, having the time of your life” hahaha) as our password:
If you run this script you will see our form in action:
Time passes. Anna is happy, everyone is happy but not for long. Now let me into the picture: Rinat Ussenov, an amazing person with warm heart and evil mind, a long time fan of the company and it’s products and he happens to be an engineer and decides to automate some of his business relationships with the company and when he was using Google reports he discovered that application that Joe created did not escape Google crawler and has been indexed. Bam! Anna is no longer the only one person who knows the URL.
So Rinat decides to take it further and crack that pass. Oh yeah! very first thing that comes to mind is a blunt brute force. Because why not? It is obvious that the application is custom and no username? The very first google search gives me this link and solution on StackOverflow, the answer by Rob Volgman:
So lets test it! What this script does is string permutations for the given length with given characters.
For the demonstration purposes lets make a glass-box test first. We will be using only lower case 26 letters of the English alphabet.
And a little mathematics for the statistics, for the password length of 4 and using only 26 letters the amount of possible passwords is 26⁴ which is 456976
If you run this script you will see the result:
0.06 seconds! All it takes to generate all possible passwords with the length of 4 using 26 letters of the english alphabet.
Now when we have all possible passwords lets bluntly try them all! Of course we will not be trying it manually and entering by hand all 456976 possible combinations. Thats what Selenium is for :)
After ~10 min of coding I created this simple script that is using Selenium and PhantomJS to try all passwords:
Now lets run it.
Looks like its working. I can see that our small Python server app with web form is getting requests from selenium, now its time to take a short walk to the kitchen, pour myself a glass of wine and smoke a cigarette while our small script is trying its best with the resources of my MacBook Pro to break into application that Joe created.
Done! Script was successfully able to break into the the application when it was done it reported the password it found as well as it took the screenshot as a break-in proof.
It took 48.76 seconds to find our “abba” password. That’s it. We are in. And if we were truly evil we would mess around with the data and complicate everyones life in that company significantly. But we are not, so all what we will do is report the vulnerability we found.
What did we learn.
As a company:
Do not rush important decisions. Make sure all creative Annas in your company follow standard routes for the feature requests.
Try to identify and eliminate existing illegal data entry points and avoid creating new ones.
Work with Joes, make sure they follow existing conventions, learn and have in-depth knowledge of the existing architecture and application features. Fully understand basic security principals, never rush and take full responsibly for the code they produce.
As white-hat “hackers”:
Selenium probably not the best tool for brute-forcing. Not the worst but certainly not the best. I’m sure there is a way to speed-up our implementation.
Also if there was a username in our brute-force equation and real, more complex password we would grow old and die before our script finished execution. In this case using brute-force is as stupid as Python is powerful.
