How to OWN your college 101

All the findings mentioned below were discovered and responsibly disclosed months ago. Everything has been patched now. I would say I was busy and that's why I didn't write this earlier… but realistically, I was just procrastinating.

It all started with a simple attendance application developed by my college. Like every student, the first thing I noticed wasn't the features. It was how to break it. The app allowed attendance marking based on location verification, but the implementation was… questionable. You could literally spoof your location and mark attendance while comfortably sitting in your hostel room pretending to be physically present in class or just share OTPs with your mates.

Now, for most people, free attendance is where the story ends. For me, that was just reconnaissance. So naturally, I opened up the network traffic and started inspecting the requests being made by the application.

One domain immediately stood out: *.iitism.ac.in , almost every request related to attendance fetching and marking was hitting this domain.. Still in the exploring phase I went on the domain and was welcomed with this login page.

Used my student creds to login but nothing useful ahead. Nothing. Dead end. Or so I thought. While exploring the application further, I noticed two very interesting things:

• Debug mode was enabled
• The backend was running on Laravel Using this information, I generated a custom wordlist targeting common Laravel endpoints and started fuzzing. A few seconds later: BOOM.

Multiple endpoints returning 200 OK.

After manual inspection of every endpoint the most critical ones were .env and storage/logs/laravel.log

Two pure goldmines ! .env exposed db creds, mail server configs,app secrets and the log file leaked the attendance logs for the day(pwds and userids)

Without wasting any time, I connected to the DB and this was the moment when I felt like I owned the college, EVERY piece of information of EVERYONE associated with college, whether professor,student,management…everything was there. Their personal information, bank account details, personal access tokens, and a few passwords(most were encrypted so good) BUT this was not enough(again) so I opened the logs and…..PLAINTEXT PASSWORDS , is there anything still left to be exploited now ?

Now was the time to pivot to different subdomains, I fired up nmap and began enumerating subdomains and associated hosts across the infrastructure. The idea was simple: If one service was misconfigured this badly, chances were high others were too. Turns out… I was right. Same thing everywhere .env exposed, emails, dbs, and even whole git directories !

At this point the attack surface felt less like infrastructure and more like a public CTF challenge. Except this was production.

Eventually, I stopped digging. Not because there wasn't more to find. Mostly because I had already seen enough to realize how severe the situation was. So I did what every security researcher should do. I documented everything properly , presented it to the Computer Center and just like every great bug bounty story… No bounty Just a polite: "Thank you, we'll fix it."

Final Thoughts

None of these vulnerabilities were particularly sophisticated. There were no advanced exploits. No zero-days. No complex chains. Just basic security misconfigurations. But that's exactly the scary part. Tiny mistakes. Forgotten configurations. Exposed files that "nobody will find." And suddenly someone has access to the entire organization.

This was a perfect reminder that in security, catastrophic breaches often don't happen because of complex hacking. They happen because someone forgot to disable debug mode. Or accidentally exposed a .env file. Or, apparently…decided logging plaintext passwords was a good idea. (Please don't do that.)

Thanks for reading