How I Hacked My College - Part 2

In the first part, I shared how a weak SSH configuration gave me access to the college server. This part is about something even more serious: SQL Injection.

This story was not just about finding vulnerabilities. It started with a challenge.

One day, a senior member from the system department told me, “You can’t really do anything. You just sit in college and do small things.” I didn’t argue or try to prove anything at that moment. Instead, I went back and continued my research.

My intention was never to embarrass anyone. I genuinely wanted the administration to understand the importance of cybersecurity. Many times, I had already informed them about insecure systems and weak configurations, but the issues were often ignored or postponed. So I decided to demonstrate the real impact in a controlled and authorized manner.

SQL Injection - The Challenge Begins

I started specifically looking for SQL Injection vulnerabilities because I knew how dangerous they could be if left unpatched. A successful SQL Injection attack could expose highly sensitive information from backend databases.

For hours, I tested multiple applications but found nothing significant. Eventually, I discovered a vulnerable functionality on one of the college websites related to a book search feature. For security reasons, I will refer to the domain as redacted.com.

While testing the search parameters, I noticed one particular field behaving differently from the others. Most inputs returned normal responses, but this specific parameter generated inconsistent behavior and blank responses during testing.

That immediately caught my attention.

I intercepted the requests using Burp Suite and began manually testing different payloads. The application still did not show any visible database errors, but the unusual behavior strongly suggested the presence of a Blind SQL Injection vulnerability.

To confirm the issue, I used SQLMap for further testing.

For those unfamiliar, SQLMap is an open-source penetration testing tool that automates the detection and exploitation of SQL Injection vulnerabilities.

After several hours of testing, the tool finally confirmed that the parameter was vulnerable.

From there, I was able to demonstrate the severity of the issue by accessing sensitive records stored within the database. The exposed information included user records, student-related data, employee information, hostel details, payment-related records, and several other critical datasets.

Responsible Disclosure

After documenting everything properly, I reported the findings to the system department. A meeting was arranged shortly after, where I explained the vulnerabilities, their impact, and the necessary remediation steps.

The issues were eventually fixed and the vulnerable systems were secured.

For me, the real success was not the exploitation itself; it was making people understand why cybersecurity should never be ignored.

The final part will cover the Remote Code Execution (RCE) vulnerability that ultimately led to complete system compromise.

Disclaimer: This testing was conducted with proper authorization for security assessment purposes. No sensitive information, credentials, or exploitable details have been disclosed in this article.

LinkedIn: https://www.linkedin.com/in/ashketchumwashere/

Instagram: https://www.instagram.com/ashketchumwashere/

X: https://x.com/ashketchum_16

Hope this helps you somewhere in your journey.

Thanks for Reading !!

./Keep_Hacking