How I hacked into Linways AMS

this bug was reported on May 15, and was fixed by Linways in some amount of time. Follow up emails regarding transparency were ignored.

I was in my first year of college, and we had a platform to view our attendance percentages, marks, timetable, and more—essentially an Academic Management System. It was quite helpful for checking our percentages and planning class absences. Naturally, my curious mind wanted to explore this platform further. While fiddling around with it one day, I noticed a disabled section: the profile editing page.

Of course my curious mind wanted to explore this platform, and I was fiddling around with it one day and I noticed a disabled section/page, the profile editing page.

Clicking on that button would trigger a request to the server, to check if the user was allowed to modify(change their profile picture, nothing fancy).
I quickly fired up BurpSuite and intercepted the request, and swapped its response to true from false, and it opened up a Modal to upload/change my profile picture.

Interesting, Right? Yeah. I also noticed a few other requests that went through BurpSuite to this unique endpoint `https://kec.linways.com/common/api/v1/s3/get-s3-conf` and it caught my eye.

{
"success": true,
"data": {
"serverProtocol": "https",
"s3Folder": "course_materials",
"sizeLimit": "524288000",
"bucketName": "amsfilestore",
"accessKey": "AKIAX2B3ZDTX7AFQ5ENC",
"secretKey": "THQynUL7L+GbS/+u3s5SIL0LhdQC/CENSORED",
"region": "ap-south-1",
"collegeCode": "KEC"
}
}

Woah woah, what is that?
The response contained bucketName, accessKey, secretKey, region of the S3 bucket which the profile pics are being uploaded to.

Wow, I hit a jackpot. I tried the credentials and of course it worked, and funny enough it was a centralized bucket for all colleges, it had a lot of other college codenames(like KEC) and seemed to contain upload data(probably sensitive documents)

This got me hooked, I was damn sure this platform was vulnerable in 100 other ways because who the fuck sends the secretKey to the client and trusts the browser to upload the files.

I started digging around, and I figured out that I can update anyone’s profile picture with just their studentId(not random, just incremented by 1 for each student).

Gameplan is, you upload a picture to the S3 bucket, then send this payload to this URL.

POST https://kec.linways.com/student/student_details/ajax/ajax_student_list.php
Data:
fileInfo[name]=favi.png
fileInfo[key]=/2025/xyz.png
fileInfo[bucket]=amsfilestore
studentId=9154 ##modify this for each request and you can update anyone's picture
action=UPLOAD_STUDENT_PROFILE_IMG

And additionally, there’s no sanitization on fileInfo[key], which possibly leads to stored XSS.

Then I tried a few random urls, like https://kec.linways.com/academics/api/v1/student/get-student-basic-details?studentId=9170 and boom, I was able to get anyone’s data in my college(Name, Dept, Email and Batch ID)

A few more URLs were affected too, ones involving attendance.

At that point, I was pretty sure that the server was trusting the client blindly. Classic IDOR.

Extremely funny, but I went ahead and sent a report to security@linways.com, and I was declined a bounty just because I reported as an Individual.
Their exact words were, “we are currently adopting a team-based recognition approach rather than individual bounties.“

Reflecting on this experience, it's clear that curiosity and a keen eye for detail can uncover significant vulnerabilities in digital platforms. While the journey began with a simple exploration of an academic management system, it quickly escalated into discovering critical security flaws that could have had far-reaching implications. This incident underscores the importance of robust security measures and the need for organizations to be transparent and responsive when vulnerabilities are reported. Although the response from Linways was not as rewarding as expected, the offer of a paid internship indicates a recognition of the skills demonstrated. This experience serves as a reminder of the ethical responsibilities that come with hacking and the potential for positive outcomes when vulnerabilities are responsibly disclosed.

Public transparency log:

Initial report sent via email on May 15, 2025
Report acknowledged by team on May 16, 2025
I acknowledge the reply on May 16, 2025
Follow up email regarding the bounty on May 22, 2025
Bounty rejected and Paid Internship offered on May 23, 2025
I ask permission to publish my blog/transparency report on Jun 8, 2025
Team replies requesting some more time as they handle a few internal cases on Jun 13, 2025
Follow up on Jul 16, 2025
Follow up on Aug 20, 2025
No replies were received, and it looks the bugs were fixed, hence I’ve published it on September 9