Zomato got hacked.
Through a process that began in November 2015, the hacker was able to download data containing five points of information of the restaurant search and discovery service’s 17 million users: names, emails, numeric user IDs, usernames, and password hashes.
That’s really scary.
Although the password hashes leak was a little more contained, impacting only 6,6 million users (the rest logged in with their Facebook/Google account), things escalated when the information was then listed on a dark web marketplace.
But it’s not all bad news.
Since the hack, Zomato has been keeping everyone up to date with what went down. Zomato founder and CEO Deepinder Goyal wrote a blog post explaining just what happened after the information was taken:
We were lucky we could get in touch with the person (hacker) in good time. As it turned out, the hacker was a security researcher (ethical hacker) who had put up the data for sale to get our attention (and/or to teach us a lesson). He/she only wanted us to launch a good bug bounty program on Hackerone, as he/she wanted to make sure that security researchers were rewarded well for their work. The hacker also shared the database with us and took the sales link down once we promised to launch the bug bounty program. He/she also agreed to destroy the data at their end immediately.
So how did the hack happen exactly? In that same blog post, Goyal explained how the “ethical” hacker gained access:
It all started in November 2015, when 000webhost’s user database was leaked online (with plain text passwords). One of our developers had his personal hosting account with the service. As a result of 000webhost’s user account data breach, his email address and password also became available publicly.
Unfortunately, the developer was using the same email and password combination on Github. Back then, when 000webhost passwords leaked, we were not using 2 factor authentication on Github (we have been using two-factor authentication on Github since the last few months). With the login credentials for the developer, the hacker was able to use the developer’s password to get into his Github account and review one of our code repositories to which the developer had access (this happened some time last year, but for some reason the hacker only exploited the code very recently).
Getting access to a part of the code didn’t give the hacker direct access to the database. Our systems are only accessible for a specific set of IP addresses. But the hacker was able to scan through the code, and he ended up exploiting a vulnerability in the code to access the database (via remote code execution). The piece of code which was vulnerable was a part of a deprecated system, and hadn’t been modified for a few years now.
Yes, someone has some of our code, and that’s a risk. But we have taken every step conceivable to us to make sure that the code cannot be exploited in any way possible to breach Zomato’s infrastructure. Also, one more thought that gives us comfort – with every passing day, the leaked code is getting more and more out-of-date.
How beautiful is that transparency?
And get this: although the company was advised to take action against the developer responsible, they have decided not to make an example of them because, well, the company is to blame, too.
Read Goyal’s full blog post here for a little lesson on crisis management, as well as how to prevent hackers gaining access to your own site.
If that’s too much effort, though, just give NEWORDER a call.
