How I Discovered 74,000 Exposed Profiles: Inside the Mood Indigo Security Disaster

TLDR: The Mood Indigo website had critical security flaws, including unsecured user profile updates, client-side OTP verification, token misuse granting access with just an email, and an exposed database of 74k+ users accessible via a public link. Despite reporting these issues multiple times, the team did not respond, and the server remained vulnerable until it was eventually taken down. This highlights the importance of prioritizing security in web development and being cautious with personal data online.

Disclaimer: I am not targeting any individual, group or organisation, all the data shared below is for archival and educational purposes. Also, no attempt has been made to share the data of affected individuals, the backend server is down as I write this, and has been down for more than 48 hours, hence no URL is accessible.

Last year, I attended Mood Indigo to watch Shreyas’s concert, and this year, they raised the bar by organizing Raftaar Bhai’s performance. Eager to attend, I visited their website and registered myself. While exploring the site, I noticed that although the UI loaded instantly, the data took a considerable amount of time to load. Curiosity sparked within me, and I began to wonder about the reasons behind this delay. Little did I know, this would mark the beginning of my journey into uncovering one of the most insecure websites I have ever come across.

Please note that I have reported the vulnerabilities to the concerned people and the server is down now, so you won’t be able to access the data if you visit these links. Also, I have not HACKED or got UNAUTHORIZED ACCESS to anything, all the mentioned methods were public, just hidden behind client side JavaScript.

Let’s start with simple things, every request which modifies the data should be generally only done via tokens, which are long randomly generated strings used to identify a user on the server side. This ensures that bad actors cannot mess with any of the database fields because tokens are almost impossible to guess or brute force, so with every request, we send a token which works as a mode of authentication. And then the request is processed, but the mood indigo website does not follow the norms.

To make any request related to profile details changes, interaction with point systems, threads or any other such features of the website, you just need the user id of the user and you can do whatever you wish to. Want to change social handles of some user on the mood indigo website? Just send a request to https://ashish.moodi.org/users/update_user_profile with the user id and your request will be processed.

The above image shows the parameters that you need to send to the request uri in order to make the changes, this is from the client side javascript. Again, I would like to put emphasis on the fact that there is no hacking or unauthorised access involved. The whole application and database was basically open to all.

The login process, to log in into the website, you are required to enter your email, password and an OTP is sent to your email which you need to enter, that is verified and then you are granted the permission to use the website. This is the common flow across all the websites, so what is wrong here?

Generally and very logically, the OTPs that are generated and sent on the email are kept on the server itself, you enter the OTP into the website, a request is sent to the server, and the server checks if the OTP that was sent to you on email and the OTP that you entered matches or not. And according to that you are granted access to the website. So here, there is very little that you can do to figure out the OTP. You can brute force it, but that will rate limit you and the IP will be blocked.

In the mood indigo website, the OTPs were being checked on the client side, yes, when you make a request to get an OTP, the OTP is generated and sent to your email, but also to your browser, which is then checked by the browser itself. So, if you haven’t guessed this by now, this beats the whole purpose of OTPs, you can just enter any email address and get the OTP for that email address. Basically, free login into any account. But this was working with accounts that were made with Google Auth, and not custom email-password accounts.

And this OTP verification vulnerability was also found last year in IITB websites by Aryan Bharti. He also exposed such security failures in the Techfest and Mood Indigo websites, he got no reply from the authorities, and nor did I. I recommend you to check his blog post on this.

The above is the response for a OTP request for login on my.moodi.org website. The request was being sent on https://ashish.moodi.org/email/sendOtp and it will return the OTP as it is, you can just take it from the network tab, paste it in the input and done. We are logged in to the account that we want.

Moving forward, an argument can be made that this compromises only the google auth enabled accounts which were around 74.65% percent accounts present on the website. At least rest of the accounts are secured. That’s exactly where this gets even better. Because, you don’t even need to do all this OTP thing to login to any user account.

We talked about tokens and how they are used for authentication, well mood indigo has tokens and they use it at certain places, but this makes the matter even worse for them. In the general development world, tokens are generated and sent back to the user only if they provide the proper set of email, password and/or OTP. But in the mood indigo website, you only need the email to get the user token, yes, just the email, and you are granted access to the website.

Just send the email in a post request to https://ashish.moodi.org/users/getUser and you are logged in, how convenient!

But then you might say, how will we figure out the emails of the user, now, here comes the best part which I had reserved for the end. You don’t have to do all the things that I have mentioned above. Because you can get the whole database of users with all the user data, every single field. You just have to paste https://ashish.moodi.org/ccp/oal in the browser, any browser. And you will receive a massive ~70 MB JSON object which has data of more than 74798 users, this number was the last time I checked, it must have grown as mood indigo was happening.

What all fields of data are there you may ask? It consists everything that you gave to the website. Below is an example of one of the 74k+ unfortunate users.

Now this data is mine, because I also signed up into the website, but you will find at least 74k+ such objects like this. Which has

• Name

• Email

• Phone Number

• Date of birth

• Stream, Year of Study

• Instagram

• Facebook

• Twitter

• Linkedin

of the users, and only the social media handles were optional, else everything mentioned here was mandatory to be filled as far as I remember. Let me give you some stats from the last data that was accessible to me.

This was the amount of data that was present on the database.

And funnier thing is, how did I find it? All this 70MB worth of personal data of users was being sent on each page visit to render the leaderboard of points which had just 10 spots. Yes, just to show top 10 people who have the most ccpPoints, the whole database was being called and dumped to the user.

Ideally, only 10 records should have been called with only the userName and ccpPoints of the user. Sorted in a descending order based on the ccpPoints but I think that just stays the ideal case. The reality is far from ideal and here we are.

Now apart from these, basically the whole website was unsecured and everything was just a post request away but I did not dive into it as it was too much to explore. I just focused on the major problems and I emailed them to the authorities, let’s talk about it now.

I wrote an email with the title ‘Bug report on SEVERE security vulnerabilities in Mood Indigo Website’, and sent it to moodi@iitb.ac.in and two other email ids of the mood indigo team. This email was sent on 23 December 2024 at 15:56. And I also informed on of the top management of the mood indigo team that I have sent the email, he was the one who gave me the email ids. They clearly knew that I have reported these problems with their website.

I sent another follow up email on 23 December 2024 at 20:32 to ask about the update and asking for a formal acknowledgement of the issue in the form of email. But no success.

I sent another email on 24 December 2024 at 16:57, more than 24 hours after the first email, telling them that I am going to contact the IITB officials about it as the moo indigo team is not responding. Yet no response.

After that I wrote one final email to prooffice@iitb.ac.in, director@iitb.ac.in, dean.sa@iitb.ac.in with the title ‘URGENT: Data of 72k students is at stake’ on 25 Dec 2024, 14:22. Informing about the leak and had attached the screenshots of all the conversations. No response yet.

Please note that the servers were up and running while I wrote the emails and the server was last online on 2024-12-26 17:31:01 as per my uptime kuma tracker. And it has been down since then.

I have informed the developer of the website about this blog post and have asked him to make sure the server is down, on whatsapp, no response yet.

And I am not the only one who they haven’t responded to, Aryan Bharti also got the same treatment when he reported similar issues with their websites last year.

So this is what I discovered this week, and I just hope someone else haven’t found this but that’s nearly impossible, bots and bad actors across the web might have found the data and it might be already up for sale somewhere on the internet.

Please think twice before entering your data on any website on the internet! There is a lot of learning in this case for the users, and the developers. Never take security lightly, it’s not an option, it’s a necessity.