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>](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a) tag ( usually used for HTML link objects), but a [<form>](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/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:

1. Future employers may see this and not be interested in hiring me because I might “poke around” their system.
2. An angry board member may ask to have me punished for my actions.
3. Students may be angry with me and act vindictively.
4. Publicizing details about this will make DePauw, my alma matter, look bad. Why would I want to do that?
5. 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:

A week later, The DePauw, the student run newspaper at DePauw University, was tipped off about my role in the mailboxes. I was notified that I had an opportunity to sit down and interview, as well as reveal my role in the mailboxes. After contemplation, I agreed to a short sit down interview.

The DePauw Article on the situation can be read here. I strongly suggest you read the article before continuing.

After the article was published on September 12, I was approached multiple times by faculty and students saying that what the university was doing was unbelievably wrong and that I was in the right. Some faculty even approached me saying that they were willing to do whatever they can to make this right, including writing letters and emails to the administration.

Additional Vulnerabilities

With the student body and faculty now backing me, I was comfortable finding more vulnerabilities in the system. My naive belief was that the university would admit to their mistakes and accept my help.

Two vulnerabilities were obtained using the same method as above, but for two different sources:

1. A schedule of all of the spring classes which has not been officially released.
2. A portal to edit my current Fall schedule, which should have been closed weeks ago and should cost an additional fee to use.

I submitted these and they were patched within a day.

Follow-Up Meeting

A week later, on September 22, I had my final meeting with the second higher-up as a wrap-up of the whole situation, as well as find out if the university would be pursing action against me.

I was first told that no action would be taken against me (phew!). I was also told that the university was surprised that I reported being ‘off-put’ by their actions and that they believed they were acting according to their responsibilities. We then proceeded to talk through the following letter:

In response, one of the main points I tried to make is how authentication on a server works and permissions of data on a system. I was authenticated to access data at a student level, and data (mailbox combinations) were accidentally treated as accessible by students, which is how I was able to access the data. This was not accepted and I was told that I accessed unauthorized data by tampering and/or “poking around” university information systems.

In addition to everything in the letter, I was told that the university is hiring “outside people to come and fix the system,” which may mean a full security audit, something that should have been done and announced at the first report. I was also told that because of these paid professionals, my work would no longer be welcome and will be met with punishment.

Conclusion

I have attempted to tell a linear story of the events that occurred while leaving my opinion out so that you, the reader, has the opportunity to form your own opinion on the subject. That being said, I do have opinions about everything that has happened that I feel need to be heard.

First, the reaction of changing the codes took over 12 days after the vulnerability was found. This means that any of the following may be true:

• The university knows exactly how many times this vulnerability was used in all of the time that the system has existed because they do not flush logs and searched through all of them.
• The university did not consider that this data may have already been used maliciously and they should be changing the locks as soon as possible.
• The university assumed I am the only attacker and that I would not be using it maliciously.

I think that the university was given an opportunity to encourage students to make their own information more secure. It is worth noting that all this happened in the same month that Equifax was hacked, leaking 143 million records of personal information and a white-hat hacker found a vulnerability that affects too many companies for him to consult them all. By responding the way they have, they are discouraging future students from notifying them of their security lapses, as well as discouraging activities that are generally welcomed by the tech industry. It is the twenty-first century, and the era of information has a new set of rules that can benefit everyone, but only if you allow it.

The biggest problem I see with what happened is that the university was so focused on keeping me quiet that they threatened legal action, while citing reasons such as “for my protection,” and that it would damage the same alma matter that was threatening me in the first place. Transparency in situations where information has been leaked is so important, and when the email reads “a limited amount of information was accessed” and not “all of the information has been leaked,” I think that there is something that must be done to notify those impacted.

There are five reasons above that the university cited for me to keep quiet. I’d like to address all five here:

1. Negative image for future employers: I have been contacted by several different companies regarding employment opportunities since the article in The DePauw was released. Also, most companies reward this behavior.
2. Angry board member: This problem is an indicator of more problems that exist at DePauw University that I will not go into here.
3. Vindictive students: Not a single student has approached me with a negative opinion, and I have only heard of one student who defends the university’s decisions.
4. My alma matter’s image: I’m fairly sure that the image of the university is currently worse than if the university decided to award one of the students that used knowledge gained at DePauw to help them build a more secure system. Now it looks like an institution that frowns upon using one’s knowledge for the benefit of the university.
5. Publicizing information may get me in trouble: Is it ever okay to use censorship to ensure a certain narrative is the narrative believed by the population?

This whole process has been enlightening yet disappointing for me. At one point I realized that I was able to outsmart a university engineer, which was personally validating of my own skills. The consequences of which were that the university tried to cover it up and keep me quiet, disappointed me in how forward thinking I think this university is.