
Election Day: Discoveries and Realizations
In my school, elections are held once per session, and the IT department often boasts about the robustness of their voting system. Initially, I was skeptical, suspecting it was just an exaggeration. Curiosity got the better of me, and I decided to investigate how the system worked to see if their claims held any truth.
The morning of the election, I woke up around 3 a.m.—not exactly 3 a.m., but sometime close. I booted up my PC, logged into the voting portal, and was greeted by a countdown timer indicating when the election would begin. Intrigued, I began casually testing the system for vulnerabilities, starting with basic checks for XSS exploits. To my surprise, the system seemed solid.
Next, I performed a basic Nmap scan on the domain and attempted a miniature DDoS attack by flooding the server with packets. My idea was simple: if the server could be overwhelmed, it might crash, revealing potential weaknesses. Typically, servers have rate limiters that block an IP address sending abnormal amounts of requests, but in this case, my IP wasn’t flagged. For 45 minutes, I overloaded the server with packets until I got bored and logged off.
By afternoon, rumors were circulating that the voting portal had been “hacked.” Initially, I felt a pang of guilt, wondering if my actions earlier in the day had caused the issue. However, the reported problem didn’t entirely align with what I had done. Apparently, the portal wasn’t fetching data for some candidates correctly, leading to lag and missing information. The school’s IT department took the blame, and the election was rescheduled. While I felt relieved, I couldn’t shake the suspicion that my earlier actions may have contributed to the incident—perhaps the server was already overstressed, and the additional user traffic tipped it over the edge. Oh well.
That evening, curiosity led me back to the election portal. My goal was to explore the system further and possibly create a mockup version for personal learning. While exploring, I wanted to see what the candidates looked like. Attempting to view their profile images in a new tab failed, so I inspected the page source and opened the image URL directly. That’s when I made a breakthrough.
The URL for fetching candidate images looked something like this:
get_image.php?file=profile&user=poco.clown
This confirmed my earlier suspicion: the system was running on PHP and MySQL. This discovery was significant for two reasons:
Ease of Brute-Force Testing:
Each candidate’s image URL contained their username. With a list of usernames readily available, I could create a password list or use public credential leaks to attempt brute-force login attacks.Understanding the System Architecture:
The election portal appeared to fetch candidates from the same database that housed general student information. It was likely that a new table (e.g., election_candidates) was created, with fields like user_id and position_contested. By associating these IDs with existing student data, the system could dynamically fetch all related information.
For the first time, I had tangible proof that the school’s systems were built on PHP and MySQL, rather than relying solely on theory. It was surprising that such a critical system had loose ends like this, all of which I uncovered due to a bout of insomnia.
Powered by Froala Editor
Subscribe to our Newsletter
Subscribe to receive news, offers, and updates directly in your inbox.
0 Comment(s)