How I hacked into one of India's largest travel website

In today's world, anything to everything that we need is available online, all within a few clicks. The e-commerce industry is now moving from your local kiryana (grocery) shops to a website that delivers everything you need directly to your doorstep. From buying groceries to purchasing your first mobile to buying tickets for your next world tour, everything is now available to you within the confines of your laptop or mobile phones right from the comfort of your couch.

A general person (like you or me) in today's date, has accounts on such sites with their sensitive information like credit cards, addresses, etc., linked to their accounts for ease of use. We permit these companies to store this all this information for us because implicitly we trust them. They have all these fancy security words like SSL Encryption, 256-bit encryption, yadda, yadda, yadda, to lure us to save this information with them. Yes, all these fancy words are high security standards that actually safeguard this information from prying eyes of hackers, who are continuously looking for exploits/leakages in systems to extract user's PII (Personally Identifiable Information). But no system is fully secure, there's always that one loophole to make it vulnerable.

This week I happened to find a major vulnerability in one of India's Largest e-com company (name not disclosed due to obvious reasons). Since I'll be referring to this organisation quite a lot throughout the post, let's name it "CompanyX" for readability. This post is meant for highlighting the vulnerability discovered and providing countermeasures to prevent this from happening to your organisation.

The technique I used is called "Github Hacking". Large profile organisations generally have a Github account with public repositories. These repositories contain code, property/config files and much more. People accidentally publish their code to github with usernames, passwords, access keys, etc. Such mistakes can result in havoc if misused. Also one amazing but less known feature on github is its powerful search, which can search for keywords in code files. Give it the right term and it will list all occurrences of that term in all repositories, which can be used to find keywords like "password", "username", "gmail". This is what happened with CompanyX.

So our CompanyX happens to have a huge github account with quite a lot of repositories open to public for accessing. Looking at the repositories I saw one project which looked quite interesting and had a lot of internal usernames and passwords. I started using the awesome search provided by github to look for keywords like username, password, etc. One keyword I searched for was gmail, and bingo, it brought to my notice a file with the corporate email ID and password (image below) of a person in the organisation.

The company happened to be using gmail services for their official emails so I quickly opened gmail and punched in the username and password. And Voila! I was into the email account of that person.

I used censys.io to quickly find out the type of services being used by CompanyX. Seems like they rely heavily on AWS (Amazon Web Services) to host their servers (image below).

That was my key to search in the mail account. AWS servers allow you to SSH (login) into them using a Private Key file, a.k.a. PEM file. I started hunting around for PEM keys in the person's mailbox. In this case the search was PEM has:attachments and immediately popped up mails with PEM key files as attachments. The one I was looking for was a PEM key with a corresponding public server IP and I found one somewhere in those search results. I downloaded the PEM file and quickly SSH'd into the remote server, and yes it worked. I was into their server, in their local subnet... I was in their system. Similar to the username and password for gmail found on their github page, I found Server IP, Username and Password for a MySQL server. Using those I logged into that MySQL server (which surprisingly also worked, boom 3 in a row). Sifting through those tables I got to know it was not a production environment, but probably a QA/Staging environment.

My goal was to reach production systems, thus began the hunt for more PEM keys and server IPs (and now that I was in their subnet, even local IP subnets like 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 would suffice). After hours of going through emails finding many more PEM keys and logging into multiple servers, finally came the golden moment when I found access to one of their production servers which had direct access to their production MySQL database. I scanned the code on that server to find MySQL credentials and yes there they were. Using that I logged into the production MySQL server using the credentials and bingo I was in!

Just to verify I ran a simple SELECT query on the users table to find my record. I saw a recently updated entry with the login time to be just few seconds before, which was when I had logged in (image below) (table and column names changed for ethical reasons).

Yes, I was in their production systems! Running a simple count query on the users table resulted in more than 1 crore user records. Damn!

I searched multiple tables for more juicy information. One of the scariest discoveries was plain text passwords to their accounts on multiple payment gateways lying there in the database. If misused, those credentials can be used to render huge business loss to a company.

That concluded my hunt for information inside CompanyX's systems. I was shocked to find the amount of information lying open to access, which seems quite concerning to me and makes me think how it can be avoided. Therefore, I list some countermeasures to issues I found in CompanyX's systems below:

1. Yes first and foremost, never ever publish critical information like usernames and passwords to Github. Always do a sanity of code being committed to make sure no such thing goes public.
2. Never leave internal IPs and passwords on Github. Today no one might have access to your systems,  but tomorrow if your systems gets compromised, these IPs and passwords can be used then.
3. Private Key Files or PEM files are like a key to a lock. It is a requirement in organisations to share these keys with peers. Make sure you copy the PEM key to your local computer and delete the mail. Also if possible do not use mails to share these keys, use either local windows/unix file shares.
4. Deny SSH from anywhere to your AWS servers. This can help prevent access to servers even if PEM keys get compromised. This is a simple step, using your AWS console white-list a set of IPs which can SSH into servers.
5. This is quite a challenge without appropriate systems, but do not store plain text passwords to any system in the database. Use property files and encrypt passwords using algorithms like AES-256 to store passwords. Also if possible use 3rd party appliances which offer hashing to store passwords and retrieve them.

Given this boom of e-commerce hundreds of sites coming up online, there always remains a slim chance of such incidents happening time and again. Its our priority as an organisation to safeguard all user information. Even a small mistake could cost us big!

Any feedback, suggestion or even a countermeasure is more than welcome. Let me know your thoughts on this in the comment section below!

P.S. - If you're a customer of CompanyX, don't be worried, your data was not stolen. This incident was responsibly disclosed to CompanyX to fix.