In its latest blogpost, Zomato also accounts for the lessons it learnt from the massive breach.

Zomato explains how 17 million users data was stolen from its database
Atom Cybersecurity Wednesday, May 24, 2017 - 15:42

Nearly a week after Zomato said that the data of 17 million users was stolen from its database, the company has provided an explanation for the massive breach in its latest blogpost.

Read more|17 million users' data stolen from Zomato, company says passwords and bank details safe

As earlier stated, the company noted that the stolen data had four details- names, emails, numeric user IDs, usernames of 10.4 million users. Another 6.6 million users’ password hashes were also compromised along with their names, emails, numeric user IDs and usernames.

Also read: Zomato hack: Security breach in its system not the first time user information was compromised

The company in its blog stated that the hacker accessed Zomato using one of its developer’s credentials which were leaked in a separate breach in 2015. That developer, however, continued to use the same email address and password combination for logging into Github.

What led to the breach

“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,” the company said.

000webhost is a website hosting company and Github is primarily a software/ website development platform.

“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 authentications 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),” the company added.

However, Zomato says the code itself did not allow the hacker to breach Zomato’s system as the code was only accessible through a select number of IP addresses. But the hacker could spot some vulnerability in the code to breach Zomato’s system.

“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,” Zomato said.

The company added, “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.”

Lessons learnt

The company concluded, “While this is a case of extraordinarily bad luck, we were fortunate enough to resolve this with minimal damage. This incident taught us a good lesson on the importance of security and how we have to be paranoid about it going forward.”

Additionally, the company listed out some practices which helped them to contain the breach.

It said having multiple ‘environments’ and compartmentalisation of databases ensured that all databases of Zomato were not accessed by the hacker.

 “Our use of multiple environments, each segregating and containing a part of business ensured that the data breach was limited to only one part of Zomato’s database; and the hacker did not gain access to all the various databases used by different businesses,” the company said.

Besides this, the company confirmed it has updated the code base and said that “good network restrictions” ensured that their payment processing systems were “never compromised”.

You can read the full blog here.

 

  

 

Show us some love and support our journalism by becoming a TNM Member - Click here.