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.

I was required to create a mechanism for users to reset their passwords using their email ids. Generally while doing this, we generate a random string and store in the database as a token for password reset, which we will verify while performing the reset.

But here I was required to generate password reset links without modifying the schema of the database. Which made me come up with a rather unconventional solution, although non-standard, but this method is 100% secure and reliable to use in production. Let’s see how it works.

When a user submits a password reset request using their username or email, we need to fetch the user’s details on the server side. If the user with the provided username or email exists, we proceed further or we return an error.

If the user exists, we get their current password, it does not matter if the password is hashed or not. We will use this current password string as one of the parameters to create a JWT or a Javascript Web Token.

So, if you are not aware of it, a JWT or a Javascript Web Token is a token which can be used for authentication and authorization. The contents of this token can be read by anyone who has access to it, but it can be verified / checked only by the creator of the token, because the creator holds to secret key for the token.

So basically, we need a secret-key to create it which we will use while verifying the token. Normally, we have a secret-key in our .env file which is used to create all the tokens which are spit out by our backend.

You might be wondering why do we have to use the CURRENTPASSWORD + SECRETKEY combination to generate the token instead of just the secret key. And the real cleverness of this approach stays in this simple thing.

If we generate the token just using the secret key, we will be able to use it infinitely till it’s expiry date. Which is harmful for us as it will be a loophole to abuse the reset password system and poses a huge security threat. By using the combination of current password and secret key, we are making it a one time use token. Because once the password is updated in the database, we can no longer verify the token, because it was generated with the old password. Even if the user set’s the same password again, it won’t be verifiable until and unless we are not hashing the passwords, which is not recommended at all.

The jwt tokens also have an expiry time which we set at the time of generation, after which the token does not get verified. So we don’t have to implement that separately.

I am writing some pseudo code in javascript on it’s implementation

const generateToken = (username) => {
    const user = db.getUserByUsername(username);
    const claims = {
        "username": user.username
    }
    const secret = `${user.password}${process.env.SECRETKEY}`;
    const token = jwt.(claims, secret);
    return token.compact();
}

const verifyToken = (token) => {
    let verified = true;
    const tokenBody = jwt.getBody(token);
    const user = db.getUserByUsername(tokenBody.username);
    const seceret = `${user.password}${process.env.SECRETKEY}`;
    try{
        jwt.verify(token, secret);
    }catch(e){
        verified = false;
    }
    return verified;
}

Please note that the above code is pseudo code and the actual implementation may have different syntax.

I am personally using the njwt library in nextjs for this. Different languages can have different libraries, but the logic stays the same!

Thank you for reading.

I will not go through the installation steps of Next project, we will start by installing next-auth library

npm i next-auth

Once this is done, we have to create a .env.local file in the project root to store our variables

NEXTAUTH_SECRET=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
NEXTAUTH_URL="http://localhost:3000"

GITHUB_ID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
GITHUB_SECRET=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

GOOGLE_CLIENT_ID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
GOOGLE_CLIENT_SECRET=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Here, the NEXTAUTH_SECRET can be anything, it is used for encryption, the NEXTAUTH_URL is used to redirect the user after the user is signed in. The GITHUB_ID, GITHUB_SECRET, GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET are the credentials that are to be obtained from those particular websites.

Note: While setting the credentials in Github, Google and other such auth providers, we have to set the callback url to http://localhost:3000/api/auth/callback/google, here the http://localhost:3000 is to be replaced with your domain and the callback/google is to be replaced with your provider name such as github, twitter, etc.

After this, we have to make a file with the path /lib/authOptions.ts, it will be used to export the auth options that we are using in the app

import { NextAuthOptions } from "next-auth";
import GithubProvider from "next-auth/providers/github";
import GoogleProvider from "next-auth/providers/google";

export const authOptions : NextAuthOptions = {
    providers: [
      GithubProvider({
        clientId: process.env.GITHUB_ID as string,
        clientSecret: process.env.GITHUB_SECRET as string,
      }),
      GoogleProvider({
        clientId: process.env.GOOGLE_CLIENT_ID as string,
        clientSecret: process.env.GOOGLE_CLIENT_SECRET as string,
      }),
    ],
  }

Here, we are importing the values from our .env.local file that we made earlier.

Moving forward, we need to make one more such file in the path /src/app/api/auth/[…nextauth]/route.ts which will be used for our client side authentication

import NextAuth from "next-auth";
import { authOptions } from "../../../../../lib/authOptions";
const handler = NextAuth(authOptions);
export { handler as GET, handler as POST };

In this file, we are importing the authOptions that we exported.

Moving forward, we need to make a SessionWrapper component which will be used to as a provider in our frontend, due to this component we can use the hooks provided by NextAuth anywhere in our application.

This is the component that I created in the path, /components/SessionWrapper.tsx, the path does not matter, but it should be a tsx or jsx component.

"use client";

import { SessionProvider } from 'next-auth/react';
import React from 'react'

function SessionWrapper({children} : {children: React.ReactNode}) {
  return (
    <SessionProvider>
        {children}
    </SessionProvider>
  )
}

export default SessionWrapper

Now we have to use this wrapper in our layout.tsx file in /src/app/layout.tsx

...
 return (
    <SessionWrapper>
      <html lang="en">
        <body className={inter.className}>{children}</body>
      </html>
    </SessionWrapper>
  );
...

Now, we are good to use the authentication anywhere in our app, let us see how it is done.

We are provided with a useSession() hook by next-auth which can be used to get a session variable

const {data: session} = useSession();

This variable returns false if the user is not signed in, and it contains the user data if the user is logged in.

So we can use this information to build an interface

if (session) {
    return (
      <>
        <p>You are logged in as</p>
        <p>{session.user?.name}</p>
        <p>{session.user?.email}</p>
      </>
    );
  }
  return (
    <>
      <p> You are not logged in please, login</p>
    </>
  );

But, you may ask how do I sign-in and sign-out? NextAuth provides very simple functions for that as well, we just have to import them and use in our app

import { signIn } from 'next-auth/react';
...
return(
<>
    <p>You are not logged in please, login</p?>
    <br />
    <p onClick={() => signIn("github")}>Github</p>
    <br />
    <p onClick={() => signIn("google")}>Google</p>
</>
);

The signOut method is also provided which can be used directly.

Now, we are done with the basics of frontend auth, now for the backend side authentication.

This is an example of an api route which returns the user information.

import { getServerSession } from "next-auth";
import { NextRequest, NextResponse } from "next/server";
import { authOptions } from "../../../../lib/authOptions";

const GET = async (request: NextRequest) => {
    const session = await getServerSession(authOptions);

    if(!session){
        return NextResponse.json({
            "failed": "No session found"
        })
    }

    return NextResponse.json(session);
}

export {GET};

The response is something like this:

{
  "user": {
    "name": "Yash",
    "email": "hi@yassh.in",
    "image": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.url.com"
  }
}

This is enough to get you started with authentication in NextJS 14 using NextAuth library.

I always wondered how cool it would be if I can download the torrents on a remote machine first and then transfer it to my device in high speeds. Basically, all the waiting, searching and downloading happens on a remote machine / server and then once the files are downloaded, those are downloaded in our main machine. This saves a lot of time on your main machine and also it gives less headache.

No more keeping the computer on all night for GTA V to download. Let's look at how we will approach this.

Setting up the VPS

I am using a VPS from Hetzner as it is the most affordable option that is available, it is easily disposable and it is transparent. The service provider is not really important, we just need a machine which will be publicly accessible and can run Ubuntu.

With our Ubuntu instance in hand, we will first make sure our dependencies and our OS is up to date.

sudo apt update
sudo apt upgrade

Once we are updated, we will install our bittorent client Deluge, we will use the web-ui variant as we are on a remote server.

sudo apt-get install deluged deluge-web deluge-console

These commands will install and run the deluge-web and our bittorent client is now accessible at ip:8112. In my case it is http://135.181.200.11:8112

The default password is 'deluge'.

We will be prompted with a screen which will ask us to select a daemon to connect with, we shall select the one that we see on the screen.

Once done, we are now ready to download our favourite torrents on the server. Fore this tutorial we will be downloading Ubuntu from the official ubuntu website. I copied the .torrent file link from the Ubuntu website.

Now we shall click on the Add button to start a new download

From the prompt that is opened, we will select URL as we did not download the .torrent file or else we can select the File option.

Once the URL is submitted, our download will start. Not only it is hassle free but the download speeds are also insane on the server.

But we are not aiming for download speeds, as we will be bottlenecked to the maximum download speed that our VPS provides to us, we are focused on remote downloading which does not require our computer to be active for days and hours.

Once our download is finished, we can pause it, so it does not keep seeding. And then the second part our task arrives.

Downloading the files on the computer

If we click on preferences, we can see that our files are saved in /var/lib/deluged/Downloads

If we ls into that directory we can see our downloaded file

Now, we just have to download this file on our local computer. There are several methods to achieve this. We will make a http server and download our file from the browser. To do it we have to install apache

sudo apt install apache2

Once apache is installed, if we visit our IP address, we shall see the default apache page

The files for apache server are stored under /var/www/html/. We will have to move our file there, to do it we will do

mv /var/lib/deluged/Downloads/<filename> /var/www/html/<filename>

In my case, it is mv /var/lib/deluged/Downloads/ubuntu-24.04-desktop-amd64.iso /var/www/html/ubuntu-24.04-desktop-amd64.iso. Now our file is also moved we now can download our file from. ip/filename, in my case it is http://135.181.200.11/ubuntu-24.04-desktop-amd64.iso

We will be greeted with a '403 Forbidden' error as soon as we open this page

This is because the Apache does not have enough permissions of this file, we can solve this with one simple command

chmod -R 777 /var/www/html

Once again hit the URL and our download shall start instantly!

That's how you torrent a file using VPS!