How I Hacked DePauw University Using Hidden Inputs

And how not to handle reported vulnerabilities

For the past month I have been in a conflict with my undergrad university, DePauw, over a vulnerability I found involving university provided student mailboxes. I have been threatened while also being told that they are grateful for what I’ve done.

Over this article I will explain the technicals of the vulnerability, the response from the university and the chain of events that made this the situation it is now, as well as my opinion on the whole thing.

In late August, I discovered a form with hidden inputs in DePauw University’s student E-Services site. The link was used to direct students to a webpage containing their university mailbox number and combination.

Note: If you are not interested in the technicals of the hack, please skip below to “University Reaction.”

This link was different from all the other links, because it was not an <a> tag ( usually used for HTML link objects), but a <form> tag with inputs that were set to be hidden. Additionally, the form had a type field set to sqlform (research on this returned nothing which may suggest it was used by the original developer as documentation into how the form worked). However, the hidden input here had an interesting name: Student ID.

Exploiting Hidden Forms

Hidden inputs are sometimes used with the assumption that no one will open up an inspector and submit data other than the data in the formatted webpage. The Mozilla page (also linked above) for hidden inputs even adds that a use case would be security data, such as a token that would invalidate the form if it was changed. Because of this assumption, input sanitization may be looked over or completely forgotten.

That is exactly the case with the form I found. The Student ID field, which can be edited using the Chrome Web Inspector, was not sanitized.

I asked a friend for their Student ID to test this potential vulnerability. Sure enough, submitting the form with the modified data was enough for the system to spit out the correlating mailbox number and combination.

This was scary. This hole may have existed and exploited for years without anyone knowing. The HTML 2.0 (1995) specification includes hidden inputs, but it’s unlikely that this webpage has existed for 22 years. That being said, it is still a possibility.

Logs exist that can trace exploitation retroactively, but searching them takes an extremely long time and effort that is put to better use by patching the hole (fix the leak) and changing the combinations (clean up the mess).

I submitted a report to the HelpDesk (University IT department) as well as some upper level management detailing the vulnerability with steps to reproduce.

However, I suspected that the problem was worse than I had initially found. If the input data is not sanitized, as well as the fact that the form is of type sqlform , could it be vulnerable to an SQL-injection?

There are a number of SQL-injections that can have devastating, irreversible effects on a system, so in choosing my injection I needed to be careful. Instead of trying to execute a DROP TABLE attack, which may delete the database forever, one could insert OR 1=1 . I was working with the assumption that submitting the form would execute:

SELECT (mailbox, combination) FROM s_mailboxes WHERE student_id = {input};

Where, if the input is the student ID from the form, evaluates to:

SELECT (mailbox, combination) FROM s_mailboxes WHERE student_id = 510984 or 1=1;

Because 1=1 is always true, this statement evaluates TRUE for every row in the table. Subsequently, every single mailbox number and correlating combination were returned, viewable from Chrome.

I promptly submitted this issue, hoping to show the university that their problem is much worse than my initial email suggests. The problem was promptly fixed before the end of the day.

The University’s Reaction

All university faculty names and position titles have been censored for their protection.

For finding a vulnerability that leaked thousands of personal information, I was expecting to be met with complete gratitude. I was prepared to ask permission to write an article about what had happened, which was the only reward I wanted at the time.

A meeting was set for Monday, August 28, with one of the system administrators so that they could make sure to get all the technical details from me. Since the vulnerability was fixed, I asked if I could publish an article about the leak online. I was told that the system administrator did not have the authority and that I would have to wait until my next meeting, where a higher-up would detail exactly what was going to happen.

My meeting with the higher-up was set for Wednesday, August 30, to discuss and hopefully wrap up the discussion about what was going to happen. I faced a series of questions including why I did it as well as what my intentions were. I was also notified that every single mailbox combination would need to be changed because of the vulnerability, and it was suggested that this was a direct consequence of my actions, a statement which would later be explicitly expressed. Upon asking if I could publish an article detailing the leak, I was told that they would prefer I did not release any information, but that they could not stop me since they were not the police.

The third meeting, which was set up via text message via the higher-up’s secretary a few hours before the requested meeting time, took place Thursday, August 31. I was met with another line of questions similar to the previous meeting, but for another university representative that would like to get the information from me first-hand. I was then told that the university is not going to reveal my identity and asked that I not reveal myself for any of the following reasons:

Future employers may see this and not be interested in hiring me because I might “poke around” their system. An angry board member may ask to have me punished for my actions. Students may be angry with me and act vindictively. Publicizing details about this will make DePauw, my alma matter, look bad. Why would I want to do that? I broke the Student Code of Conduct by misusing university information systems, but they were not going to pursue any action. However if I were to publish a blog post/article detailing what happened, then “we may need to look into that.”

I was then reminded of the consequences of my actions (all of the mailboxes were going to be changed the next week) and was asked what I thought about that.

It was at this point that I told them that it is not my fault that the changes have to happen but the fact that their system was vulnerable in the first place and that this may have been exploited any number of times, and mail may have been stolen in the past as a result. This moment was significant because this was the first time, in all of my meetings, where I chose to interject my opinion into the conversation, and it would not be the last.

I was then told that the university may have a responsibility to report me to the police because the information I accessed was sensitive enough that I may have broken the law.

Afterwards, my father contacted a lawyer because my alma matter was suggesting they may turn me into law enforcement.

Going Public

An email went out at 7:23am on September 4, detailing to the student body what had occurred: