A few weeks ago I gave a guest lecture at the Windesheim University of Applied Sciences in The Netherlands. Being a Windesheim graduate myself I’ve always kept in touch with my former teachers. One of them told me recently that a lot of students want to learn more about IT security & hacking and invited me to give a guest lecture. Of course! And to keep it a bit juicy, I added a hacking demonstration to 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 quite astonishing and I had to change the direction of the demonstration in order to protect the company’s security.



Hacking Unilever?

One of the students mentioned Unilever, a well known company in The Netherlands, so I thought it would be cool to review this particular 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 connected to it. I typed in ‘unilever’ and got several results. The first search result immediately got my attention:

Apparently there was an unprotected database attached to the internet with 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 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 seemed this MongoDB database server contained at least two databases which were 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! ;-)

Aftermath: should I report the security hole?

It is two weeks later now and somehow it didn’t feel right to just leave this database unprotected while attached to the internet. Unilever is probably not even aware of the fact that 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 assess 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 connect button:

Then I filled in the IP address that Shodan gave to me:

And 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!

Holy shit!

It looked as if 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 user name and password configured to protect it so I assumed it was a public database ;-)

Within the databases I found personal details like names, e-mail addresses and also private chat logs. I didn’t count how much data was leaking exactly. But this information shouldn’t be unprotected and on the internet at all! It appeared the database server had something to do with multiple conference presentations. Unfortunately at first glance I couldn’t find more clues as 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 since 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 looked as if another database server (MySQL) was publicly accessible from the internet. It was unclear if it had a password configured. Nonetheless, it’s bad security practice to have a database server directly accessible via the internet.

When giving the MySQL version number (5.6.21) a closer look I noted that it contained various security vulnerabilities:

One of the vulnerabilities even got a CVSS rating of 7.5! This means it’s a high security risk that should be patched immediately. I didn’t extend my research into the MySQL server as I was looking for the server owner.

Visiting the accompanying server website

I left that particular database server and visited the attached website (which the server broadcasts on TCP port 80):

Apparently 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 this would be a good starting point for finding the owner information for that domain name (via whois):

Above information didn’t get me much further. Since for domain names that end with .nl, further detailed information can only be requested by visiting the SIDN website. SIDN maintains the administration of .nl domain names. And this is 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 noticed chat logs and pointers to congresses so I was fairly sure their software used MongoDB as a 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 savvy. From the results I extracted the following information:

IP address Size Databases x.x.238.161 13.1 GB 36 x.x.238.162 11.1 GB 33 x.x.238.163 23.1 GB 35 x.x.238.164 13.1 GB 36 x.x.238.165 13.2 GB 37 x.x.238.166 13.2 GB 37 x.x.238.167 13.1 GB 36 x.x.238.168 13.1 GB 36 x.x.238.169 13.1 GB 36 x.x.238.170 13.1 GB 36 x.x.238.171 11.1 GB 33 x.x.148.216 9.8 MB 2 x.x.43.136 6.6 GB 10

None of these 13 databases (156.6 GB total) had a password configured and were freely accessible. 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 was extensive in their effort in indexing services on the internet so I performed a quick port scan 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 any more servers so Shodan must have done a pretty good job indexing them :-)

Contacting Savvy Congress

Since I now knew which database servers were unprotected and also what the security impact was – it was time to contact the owner to communicate the gathered intelligence. On April 15th, 2016 I called Savvy Congress twice but unfortunately was ‘firewalled’ by the reception on both occasions. So I mailed them my findings.

The next day I got a friendly reply in which they stated that these servers were indeed open but that they were part of an old development cluster. They also sent me a nice t-shirt to show me their appreciation of the responsible disclosure:

If the vulnerable 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.

Finally, the last two IP addresses (x.x.148.216 and x.x.43.136) which hosted insecure MongoDB databases did not belong to Savvy Congress.

Finding the other owners

I found out that the 6.6 GB database at x.x.43.136 belonged to Droisys. According to LinkedIn they have between 246 and 500 employees and operate in the financial sector. The database is probably used for transactions and prices. Not really sure what it does exactly. I had found several Droisys e-mail addresses in the database and decided to use these to notify them that their database was exposed on the internet. Unfortunately I haven’t received any reply from them yet. Since I didn’t get e-mail bouncers the e-mail addresses I mailed to should still exist. Did Droisys ignore me?

Final words

Companies which don’t scan their internet infrastructure for security vulnerabilities don’t realize how vulnerable they can be. As I unfortunately notice too often in my work.

You can only hope for them to be contacted by a friendly hacker who invests time and effort in their security situation and notifies them of their vulnerabilities before a cyber criminal comes by.

Also, if you use MongoDB databases, please use a strong password 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. May 13, 2016 This article is published.

Sites linking to this article:

This article has been manually translated into Japanese by IT news site POSTD.cc.