Hacking all the things on Telkom University (Graduation Edition)
Web Exploitation · Published November 24, 2025 · 12 minute read
As my journey ends, I'll leave my hat on Telyu.
Blog 5 — cover.jpeg
Introduction
As I sit here in my final semester moment, I've spent so many time in Telkom University to make memories, meet some friends, and compete to win some competitions. I'd never regret to choose Tel\-U to forge my bachelor's degree. It's a honor to become a part of this university, better than my previous academic history which is fucking sucks in every aspects. So before I leave these halls that have shaped me for years, there's something important that i need to share as a return.
Blog 5 — sso\-flow.png
Over the past three years, I've conducted security research across all academic digital services that we all use every day such as checking grades on iGracias, accessing library resources on Open Library, managing transcript and certificate (ijazah) on Basila, or make attendance in MyTel\-U. For example, an SQL Injection on the iGracias wasn’t just a bug in one website, it could be used to trigger another bug on different web app since those apps are connected via SSO. Once those credentials are breached, an attacker can log in to every application that supports SSO login method like SiPeta, Basila, Open Library, Tel\-U Connect, and many more.
I'm not writing this as an expert standing above everyone else, but as a student who is also a part of this university. My hope is that by the time you finish reading this, you'll not only understand the risks but feel empowered to take action for the future, even after graduation. The finding I share are real weaknesses that could affect your personal & sensitive data, academic records, your privacy, and even all of your family history.
Brief Overview
All of the vulnerabilities i found have been reported to PuTI, and I'm grateful that they've taken action to close and remediate all my findings. You might wonder why I'm only sharing this now in my final moments as a student. It's because the system behavior itself. Some findings like Insecure Direct Object References (IDOR) require at least two different user roles to identify and verify the security flaw. As a student, I could only see the system from one perspective. But once my role transitioned from Student to Alumni, I gained a different POV that allowed me to observe how the system behaves across different roles and permissions.
Blog 5 — findings.png
There are more than 10 issues found across all Telkom University services as you can see in the image above (\please turn the dark mode on). Im sure that there could be several more, but i just want to share the most destructive and impactful risk among those findings. Most of them are oftenly used by students, lecturer, and staff for their academic activity. These span across Basila, SiPeta, MyTel\-U, iGracias, and Open Library. The rest of the findings has a similar vulnerability like those apps, so i just want to share the unique one. My goal isn't to make you paranoid about using these systems. Instead, I want to share knowledge to help you understand the risks, and to encourage you to be more mindful about privacy & security.
Impact & Findings
1. Unauthorized File Access in Basila
Basila is used by the final semester students to download their transcripts and certificates (ijazah). The system requiring students to input their SSO username and password before being allowed to download these sensitive documents. This seems like a reasonable security measure to ensure that only the rightful owner can access their own files. However during my testing, I discovered about how Basila actually processes these download requests.
Blog 5 — basila1.png
While the application does ask for your username and password, it turns out that these credentials aren't actually being used to verify which files you're authorized to access. Instead, the system relies on a student ID number (NIM) that's sent in the background when you make a download request. This means that even though I would log in with my own username & password before downloading those documents, I can modify the NIM parameter to someone else's student ID. The system would still accepting my request and send me that other student's documents. The user/pass verification check was essentially just for show, but it didn't actually protect anything.
Blog 5 — basila2.png
Anyone with a valid SSO account could download transcripts and certificates belonging to any student in the university. All they need is just a student's NIM, which isn't exactly secret information since it can be accessed publicly via PDDikti. Imagine if someone wanted to impersonate you for a job application, or if a malicious actor wanted to steal the identities of hundreds or thousands of students. It can be a gateway to identity theft, fraud, and a serious breach of privacy for every student who has ever graduated or is about to graduate from the university.
2. Broken Access Control on SiPeta
SiPeta is a platform where Students can upload their thesis progress, view grades, submit administrative documents, and check their thesis defense status. Lecturers can also use it to input grades and review thesis drafts. To access these features, students must have a valid certificate called "SK TA" (Surat Keterangan Tugas Akhir). This certificate acts as your permission slip which confirm that you're officially registered for thesis work. Without it, the system is designed to restrict your access and only showing you a "Data Tugas Akhir" menu on its sidebar.
Blog 5 — sipeta.png
But, while the system correctly restrict access to some features/menu that require a valid SK TA in the frontend side, it fails to actually block access to those features at the backend level. In my testing, even with an expired SK TA status, I could bypass the restriction by typing the direct URL of any SiPeta menu into my browser. The application would accept my request and grant me full access to that feature as if I had a valid certificate. The system was essentially relying on "security through obscurity" assuming that if students couldn't see the menu buttons, they wouldn't know how to access the features. Actually i've guessed this behavior long time before i discovered this finding. That's why i saved all valid links when my SK TA is valid, and test all those links when my SK TA has been expired to confirm this finding is really exist.
The vulnerability also means that the entire permission system built around SK TA certificates becomes meaningless. If access controls can be bypassed with such a simple method, what's the point of requiring certificates in the first place? It undermines the integrity of the entire thesis management process and the administrative controls that are supposed to govern who can do, what, and when within the system.
3. Insecure Data Storage in MyTel-U
The next issue I found was related about how MyTel\-U mobile handled data storage. Mobile apps often save small pieces of information locally on the device so that users don’t have to log in repeatedly. On Flutter, this is commonly done using something called Shared Preferences, which is essentially like a local storage cookies in a web browser.
Blog 5 — mytelu1.png
When a user logged into the application, the backend would return user info such as name, grade, or role which the app then stores those info in local storage. Every time the application launched back, it would read the role value from this local storage and use it to render the appropriate UI components and enable specific features. But in this finding, because there was no secondary validation with the server to verify those user datas matched the actual data in the database, the app trusted whatever value was present in the local storage. For example, we can modify our user role in the local storage from "Mahasiswa" to become "Dosen" user role, and the app will grant us as a lecturer.
Blog 5 — mytelu2.png
Local storage in Flutter is designed to store non\-sensitive information like news, notifications, name, faculty, or grades. It was never intended to store sensitive such as role, password, or even auth token. Because these values were not encrypted, Attackers could read and modify these data easily. In a good practice, Sensitive information like tokens or passwords should always be stored using secure mechanisms, such as Flutter Secure Storage.
4. SQL Injection in Open Library
Behind the scenes, Open Library communicates with a database to retrieve information about available resources, student borrowing history, and catalog details. It's a system that students and staff interact with regularly for research and academic purposes. When you search for a book or access any feature, your input is sent to the database as a query command. Normally, the system should treat your input as plain text and safely search for matching results. However, I discovered that Open Library wasn't properly filtering user input before passing it to the database.
Blog 5 — oplib1.png
The finding happens when user input is directly inserted into a database query without proper validation or sanitization. Instead of treating my input as a simple search term, the system was processing it as part of the actual database command. Actually this finding was similar to the one i found in iGracias, but the injection points on Openlib was a bit hard to find since it uses old code base. You can read the detailed explanation about the similar finding in this blog. The main thing is, by crafting special characters and SQL syntax into my search input, I could manipulate the query to do things it was never supposed to do. This wasn't just about accessing library data anymore. I was able to break out of the intended query and execute my own database commands, giving me the ability to read and potentially modify data that should have been off\-limits.
Blog 5 — oplib2.png
One of the most sensitive databases I could access was called Masterdata, which stores almost all academic and administrative information across the university. There are so many sensitive data inside Masterdata DB such as PII informations, student academic records, administrative data, enrollment details, and countless other sensitive datasets that power various university systems. This means a single SQL Injection point in Open Library could potentially compromise the entire university's digital infrastructure. It's like finding one weak door that leads to every room in the entire building. The impact of this vulnerability threatened the confidentiality of everyone's data across the entire institution.
5. Insecure Direct Object Reference on iGracias
One of the services within iGracias is called TAK (Transcript of Student Activities), which records all your extracurricular activities, organizational involvement, competitions, and other achievements during the study. The system works through a structured approval process where students can add new TAK records or update existing ones in their account. Once submitted, these records must be reviewed and approved by the LAK administration team. If approved, the TAK points get added to your academic record. Otherwise, you'll need to make revisions based on the LAK team's feedback. This process exists to ensure that only legitimate achievements are recognized in your academic transcript.
Blog 5 — idor1.png
However, I discovered a critical flaw in how iGracias handles TAK record modifications. This finding occurs when the system doesn't properly verify whether a user has the right to access or modify a specific piece of data. In this case, when you submit or update a TAK record, the system uses an identifier to reference which record is being modified. But it never checks whether that identifier actually belongs to you. By manipulating this identifier in my request, I could target another student's TAK record and modify it as if it were my own. Even worse, I discovered that I could craft a payload that also bypassed the entire approval workflow altogether.
This means an attacker could insert some fake activity records into any student's account, cheating to increase their TAK points, and directly mark those records as "approved" without any involvement from the LAK admin team. They could give themselves credit for competitions they never participated in, organizational roles they never held, or achievements they never earned. Since TAK points play a significant role in determining academic recognitions, scholarships, and even serve as a requirement for graduation, this vulnerability creates an unfair advantage.
Blog 5 — idor2.jpg
The severity of this issue is at least on the same level as SQL Injection. While SQL Injection threatens data breaches, its impact can still be reduced by changing password or enabling multi\-factor authentication on the victim's side. Even if credentials were leaked, MFA would act as an additional barrier against the attackers that trying to log in with breached password from SQLi finding. But on the other hand, this IDOR finding could bypasses authentication entirely. No matter how strong a user’s password is, or even if they rotate it daily and enabling MFA, the attacker could still modify the victim’s data by just using the data IDs of the victim. This data IDs wont never changed since it has already defined randomly by the system. Unfortunately, anyone can view this ID based on student's NIM, while the NIM itself can be accessed publicly via PDDikti. This makes IDOR highly damaging because it undermines the integrity of academic records without needing to compromise any account at all.
Conclusion
Over the past 3 years as a student, i was spending time to test the security of campus services. When students can access each other's data, modify TAK records without approval, or when an attacker can easily have access to our privacy, the integrity of our institution becomes questionable. Imagine if your data could be altered by anyone who discovered this finding, or if your personal information such as home address, UKT payment, phone number, KTP, and even plaintext password was abused by anyone for their personal gain. These scenarios will affect our life even if we have graduated.
As a part of the student within this university, we all share the same digital infrastructure and face the same risks. Writing this blog serves as a way to translate my findings into understandable information to raise your awareness.
When students understand how their data can be breached, they become more aware about data privacy & security. Protecting data means protecting people, and building awareness is the path to ensuring trust and fairness in this university. Carrying this awareness forward is one of the most meaningful legacies to leave behind before my graduation.
This is why education are important. For beginners, cyber attacks may seem like spells casted from nowhere. But once you understand how to trick the system, you no longer see it as magic, you see it as a weakness that can be fixed. Some people see this like a sorcery tricks where the hacker modifying a system as they want, or breaking something for fun. But the truth is, there’s no magic. It's just a Wizard crafting spells to conquer the world.
\- Wzrd.