How A Bad Implementation Can Allow Anyone To Hijack Every My Campus Days Account

And also because one of my friends noticed it recently and insisted me on writing this article.

The Story

So, how I got the idea in the first place? … Simply put, I’m a forgetful person.

But first, let me tell you what My Campus Days is, it’s kind of a service which is, umm … wait, let me use their words to explain you all, it’s actually a “Student Centric University Operations Platform”. Cool, eh?

Basically they handle some of the hostel (in which we stay in, duh) stuff, so, whenever you want your room cleaned, or you have any problem, you need to login to your My Campus Days account, submit a request and boom! (not that fast obviously)

Now I guess you can see how it links with forgetfulness. Yeah, I forgot the password on my first day at college, then, like any normal person I tried to reset the password and it successfully did reset my password.

But, there was a catch. It did something so peculiar that caught my eye. Before telling you the catch, you should know that,

Most college portals are broken by default

My Campus Days (generally, most, okay, all college portals) have this policy that in the very beginning of the college they assign students username and password to login to an online portal that has their data, like their name, registration numbers, parent’s name, their phone numbers, etc.

The problem is the username that is assigned to them is their college registration number and the password is the same (or maybe date of birth, but something along these lines) and most of the time these students don’t change their login credentials at all, once they get them from their college at the time of their registration.

This can allow somebody like me to quickly understand the HTTP request prototype then using Curl or any other HTTP library to launch a dictionary attack as My Campus Days is lazy and doesn’t blocks/timeouts me after <Industry standard for maximum attempts> (maybe 5, or 3 ?) or so attempts.

But, this is not considered a cool attack in our community and it’s borderline “idiotic”, I mean, I agree, it’s not their mistake wholly, students are lazy too, they should change their passwords, who cares about the fact that it’s moral duty of companies to deliver secure by default products.

The Catch

The password reset functionality in My Campus Days sends “newly” generated credentials to the registered e-mail.

There are two common approaches of building a secure password reset feature:

1. Generate a new password on the server and email it.
2. Email a unique URL which will facilitate a reset process.

Despite plenty of guidance to the contrary, the first point is really not where we want to be. The problem with doing this is that it means a persistent password — one you can go back with and use any time — has now been sent over an insecure channel and resides in your inbox.

In other terms, an attacker might be able to sniff the password if the e-mail service is not using SSL.

Okay Piyush, it’s a bad practice, we get it, so what ? … and also, My Campus Days runs over HTTPS!

Oh, it was not related to the bug, I just wanted to share widely used mechanism for building a good reset password feature, read Troy Hunt’s blog I linked above :)

Drum rolls for the worst reset password implementation in human history

The reset button takes the user to a reset page where it asks for either of the two fields, Admission ID or the Username as you can see below —

After hitting the submit button, it responds with a success page where it says, “New password is successfully sent on your personal e-mail id, which is registered with your College/University”. So, naturally we check our inbox for new emails & few moments later, Aha!

So, it changes both, the username and password to the Admission ID. hurrah!

Conclusion

Now, anyone can parse the list of Admission ID, write a script that clicks two buttons and fills one input, loops over the parsed list and Voila!
She now owns every My Campus Days account. And heck, they (all colleges) upload cool PDFs containing Admission IDs to their websites so anyone anywhere from the Internet can now do the same. Enjoy.

Moral of the Story

1. On the forgot password page, ask the email/user id and a NEW password from the user.
2. Email a link to the stored email for that account with an activation link.
3. When the user clicks on that link, enable the new password.

If he doesn’t click the link within 24 hours or so, disable the link (so that it does not change the password anymore).

Never change the password without the user consent. It means do not email a new password just because someone clicked on the forgot password link and figured out the account name.

Originally published on Medium.