Before we go into this article I should note: YES, this is based on a true security assessment we did (and shows how simple it can be sometimes) and YES the vulnerabilities have since been patched. All identifiable company information has been altered.
It all started with a security assessment we were doing for a web development company which served a custom CMS to it’s clients (think like a WordPress) and they wanted to test if it was secure.
We did some SQL-injection attacks but quickly found that their custom IDS (Intrusion Detection System) system picked up our attempts and blocked us very quickly. We could swap IP’s to circumvent this but we would need too many IP’s and it would take too much time to find a valid SQL-injection flaw.
So we switched to another vector: Social Engineering
We start by looking up some of the clients of that web development agency and calling from their number, asking access to their database. But because “our Exchange server was experiencing issues” we asked to send the login info to employeename.companyname@gmail.com
The weakest link of a system, is the human one.
Because the access was readonly, they didn’t really care too much about this. (And no, having a readonly database is not an excuse to send login info to a random Gmail address)
We log in through MySQL Workbench and get a load of data with one table called admin_user_data. So we decide to dump the table to a local MySQL instance to do some research.
Two interesting fields showed up, which are, to no surprise, username and password.
We see a bunch of usernames, but a couple seemed to be quite interesting:
All the way up to 9. So we took a look at those accounts only.
SELECT username, password FROM admin_user_data WHERE username LIKE ‘waa_’
We quickly noticed that all these accounts had the same password hash: d9f588ccaefb4042a987bb140a2eb9f0
Since this is unsalted MD5 we figured it probably could be cracked pretty fast. Our first dictionary attack didn’t bring too many results, however, our next bruteforce attack cracked this hash in 3 seconds (including booting time of the cracker)
Our password (dhk!28 for those who are interested) turned out to be the admin (or developer account) that the web agency used to make adjustments to the CMS (custom to the client).
We decided to try it out on some of their other clients. BINGO! We’re in.
We then created a Google Dork to look for login pages of that specific CMS and look at the web agency’s portfolio where we could find 73 company websites.
With those developer accounts we could dump all their databases and from there also hack those companies (which is where our scope ended, so we didn’t do this). But technically one could now crack the passwords of normal users for each company (due to poor encryption) and then check if they used the same password for other service and use that as a new attack vector.
Learnings:
It’s noteworthy to see that even simple exploits like these can cause major damage to companies and their clients. Having spent quite some time in the sector, I have to admit that small mistakes like these are still VERY COMMON.
