A few weeks ago I gave a guest lecturer at the Windesheim University of Applied Sciences in The Netherlands. I graduated there and over the years I kept in contact with some of my teachers since then. One of the teachers told me recently that a lot of students wanted to learn more about IT security and hacking and asked me to give a lecture about it. Of course! And to keep it a bit juicy, I built in a hacking demonstration in my lecture.
When I started the demonstration, I thought it would be fun to ask the students to name a company of which I would subsequently review the security. What I found out next was really astonishing and I had to change the direction of the demonstration in order to protect the company’s security.
One of the students mentioned he did an internship at Unilever, a well known company in The Netherlands, so I thought that would be cool to review that company; within the restrictions of the law of course. I started analyzing the HTTP headers of the Unilever website and eventually I fired up Shodan .
Searching Shodan for Unilever results
Shodan is a great search engine for hackers. It scans a large part of the internet and creates a digital map of all devices and services which are connected to it. I typed in ‘unilever’ and got several results. The first search result immediately got my attention:
Apparently there is an unprotected database attached to the internet that has quite a lot of data in it (13.2 GB!). And somewhere in all that data the word ‘unilever’ popped up. Oh my god! This hacking demonstration is really getting somewhere! I had never expected to end up with this information! What exact content did Shodan index from that database?
I clicked on the details button and Shodan showed me some more information:
It seems that this MongoDB database server contains at least two databases in it which are named unilever and unilever_test . I felt this could be really dicey and decided to cut off the Unilever hacking demonstration. Never teach your students too much! 😉
Aftermatch: should I report the security hole?
It is now two weeks later and somehow it didn’t feel right to just leave this database unprotected while attached to the internet. Unilever is probably not even aware their complete database server has no password configured. I should actually help them to fix this security loophole so I started digging into it to asses the situation.
Connecting to the database
The database server runs on MongoDB and to validate Shodan’s findings I needed to get software that could connect to a MongoDB server. I hadn’t installed a MongoDB client so I googled on ‘ mongodb client ‘. The fourth result lead me to a client called MongoVue
which I installed and opened. I pressed the
and filled in the IP address that Shodan gave to me:
Then I hit the save button. On the next screen I just hit the connect button to see what would happen:
It looked as if I had now unrestricted access to 37 databases within this server!
It appeared Unilever wasn’t the only company affected by this security loophole. This was much bigger! I needed to find out who to contact exactly to get this matter solved, so I clicked around in the database tables to find out more. The database had no username and password configured to protect it, so I assumed it was a public database with data for everyone to see 😉
Within the databases I found personal details like names, e-mail addresses and also private chat logs. Haven’t counted how much data was leaking. This information shouldn’t be unprotected and on the internet! It appeared the database server has something to do with multiple conference presentations. Unfortunately at first glance I couldn’t find more clues to whom this database belonged to.
Side note: in above screenshot you can see that MongoDB version 2.6.7 is installed. This is an outdated version and contains a medium denial-of-service security risk .
Back to Shodan
Unilever isn’t the company to report this issue to, they’re merely a victim. So I got back to Shodan to see if there was more information available about the vulnerable server:
Quick look at the MySQL server
It appeared another database sever (MySQL) was publicly accessible from the internet. Don’t know if it had a password configured, but nonetheless it’s bad security practice that a database server is directly accessible via the internet.
Looking at the MySQL version number (5.6.21), it contained various security vulnerabilities:
One of the vulnerabilities even got a CVSS rating of 7.5! That means it’s a high security risk and one that should be patched immediately. I didn’t do more research into the MySQL server, as I was looking for the server owner.
Visiting the accompanying server website
I left that database server and just visited the website the server broadcasts (on TCP port 80):
It appeared that highly technical data about the status of the (proxy) server is publicly available. From a security standpoint this sort of confidential information should never be published.
Retrieving domain name ownership information
I saw the domain name [removed].is-savvy.nl
in above results and thought that might be a good starting point to find the owner information for that domain name (via
Above information didn’t get me much further. As it goes with domain names that end with .nl , further detailed information can only be requested by visiting the SIDN website. They maintain the administration of .nl domain names. Their record about is-savvy.nl :
Ah, now we’re getting somewhere! The owner is Savvy Congress.
Visiting the Savvy Congress website
I visited their website and immediately noticed they develop software that can be used during a congress, to chat with the audience for example:
That makes sense. I saw chat logs and pointers to congresses, so I’m fairly sure their software uses MongoDB as their database server.
Searching Shodan for more vulnerable database servers
I was curious to see if Savvy Congress had more vulnerable MongoDB servers and searched Shodan for
. From the results I extracted the following information:
None of these 13 databases (156.6 GB total) had a password configured and were freely accessible to anyone. 11 databases were within the same IP range ( x.x.238.* ) and had an incremental IP address.
Firing up Nmap
I didn’t know if Shodan is extensive in their effort in indexing services on the internet, so I performed a quick port scan myself via Nmap to see if I could find more MongoDB servers in the IP range that had 11 vulnerable servers:
Luckily I couldn’t find more servers, so Shodan did a pretty good job indexing them 🙂
Contacting Savvy Congress
Now that I know which database servers are unprotected and what the impact is, it’s time to contact the owner to communicate the gathered intelligence. On April 15th, 2016 I called Savvy Congress two times, but was ‘firewalled’ by the reception on both occasions. So I mailed them my findings.
The next day I got a friendly reply and they stated that these servers were open but that they were part of an old development cluster.
If these servers were indeed development machines, then the production data I saw was probably copied into development databases. Not a smart move as these environments are almost always less secure than production systems.
The last two IP addresses ( x.x.148.216 and x.x.43.136 ) which hosted insecure MongoDB databases were not theirs.
Finding the other owners
I found out that the 6.6 GB database at x.x.43.136 belongs to Droisys. According to LinkedIn they have between 246 and 500 employees and they work in the financial sector. The database does something with transactions and prices. Not really sure what it does, but I found several Droisys e-mail addresses in the database and decided to mail them that their database was exposed on the internet. Haven’t received any reply from them. I didn’t got e-mail bouncers, so the e-mail addresses I mailed to should still exist. They ignored me?
Companies that don’t scan their internet infrastructure for security vulnerabilities will never know how vulnerable it can be. What I’ve seen over the years, is that if you’ve never performed such an operation as a company, that you’re probably very vulnerable. And hopefully you’ll meet a friendly hacker who invests time and notifies you of your vulnerabilities before a cyber criminal comes by.
Also, if you use MongoDB databases, please put a strong password on it and put it behind a firewall 😉 Thanks!
Timeline of notable events
|March 30, 2016||Gave college lecture at Windesheim|
|April 15, 2016||Disclosed security vulnerabilities to Savvy Congress.|
|April 16, 2016||Savvy Congress acknowledges my findings.|
|April 25, 2016||Validated that Savvy Congress secured their MongoDB servers and notified Droisys of their vulnerable database.|
|Mei 13, 2016||This article is published.|
Sites linking to this article: