Day 1: Thoughts and Recon

It was a Friday evening and Flir was in his dorm, sitting at his computer. He set the computer to plan a random collection of Trance music and began to think about how he could gain social security numbers. The dormitory desk guards had a "resident roster" of students, listing social security numbers, name, sex, and birthdays for the students who actually lived on campus. Flir wasn't that fast a talker - he didn't think he could convince the desk guards to give him the list. Besides, only 20% of Pacific Tech's students lived on campus - Flir wanted more than that. He thought about the doors on campus that opened only with a student ID. He might be able to intercept the communications from the door readers to the authorization computer. Since the door's card readers simply sent out the student ID number (social security number), he could intercept these easily, though this would get him far fewer IDs than raiding the dorm's resident roster. Then he remembered where he'd seen his student ID number most recently: the computer, when he was viewing his class schedule and his transcript.

Pacific Tech had recently begun allowing students to use the Web to sign up for classes, view their class schedule, apply for graduation, upgrade their meal plan, change their address, pay their tuition, and even view their transcripts. As in many universities and government institutions, this was provided by a custom-built web application on a middleman server. This server functioned primarily as a client to the old mainframes, which still kept the data. Pacific Tech had transitioned much, but not all, of its data from the mainframes to a SQL database, so the web application there actually talked to both the mainframes and a newer UNIXUNIX machine running an SQL server.

What Flir had noticed the very first time he used the system was that the Web server used a self-signed certificate.

Dialogue in his Mozilla Browser

He clicked the Examine Certificate... button to see the details of the certificate.

Details of Certificate

Someone in Computing Resources was trying to save money in a stupid way. They'd created their own web certificate instead of buying one from a known certificate authority. They, like many people, didn't understand how SSL, the technology behind the misnamed "secure [web]servers," worked.

Flir was so exasperated by the bad decision that he had to tell someone about it. He got up from his computer and promptly tripped and fell over a Japanese auto disk-brake assembly. His girlfriend, an equally intelligent 19-year old with a thin frame and short black hair hopped over to him. "Jordan," he fumed, "why do you have to work on your car in here?" The parts of a Toyota Prius lay strewn about the room. She had disassembled the car down to small subsystems with some friends and carried it inside.

"I'm sorry, but I wanted to mod the car and it's too cold to work outside, much too cold. It's really freezing! Your room has much more floor space," Jordan explained at high speed. She, like so many other smart people at Pacific Tech, seemed to always talk fast, as if she was impatient with how fast her mouth could convey her brain's thoughts.

He couldn't pursue the argument. "That's only because you keep so much junk in yours," he grumbled, as she helped him back up. "I was thinking about the fact that the myPtech site uses a self-signed certificate."

"A what," she asked? Jordan knew her way around a computer, even knew UNIXUNIX, but she was a mechanical engineer and didn't delve much into networking issues.

"A self-signed certificate. Let me explain.

Self-signed Certificates - Certifying the Man in the Middle

"To prevent an eavesdropper on the network from intercepting, and possibly modifying, a communication between a web browser and a Web server, the browser and server would have to encrypt all of their communications. Normal encryption, called symmetric encryption, involves both parties knowing a shared secret and using it as a "key" in a known algorithm that turns meaningful message into gobbledygook and then gobbledygook back into meaningful message. Getting a unique shared key for a communication to each party before beginning the communication is logistically difficult. The only way around this is to generate a key at the start of the communication. But that solution creates a pair of problems. First, how do you get that secret key to each party to the communication without eavesdroppers reading it? Second, how does each party know they're sending their communications to the right party?

"The popular solution now involves a second kind of encryption, using "private-public keypairs." In essence, through some wonderfully simple mathematics, the "key" used to encrypt the communications comes in two pieces: a public key and a private key. A client who wants to send a communication to the Web server encrypts it with a widely-circulated "public" key. This public key can't be used to decrypt the communication - this requires the never-circulated "private" key. The server uses its private key to decrypt the communication. The entire communication isn't done this way for several reasons, not the least of which is that this "asymmetric" encryption is too slow.

"Instead, the client just sends a freshly-created shared key encrypted with the server's public key. The server uses its private key to decrypt the shared key, which serves as the key for this one session. The server's public key is used only once, just to get the client-created session key safely to the server. Now the problem with this, of course, is that the client's web browser has to either have a public key for every SSL'd Web server in existence, or instead, it needs a secure way to get that public key. The former is impossible - there are new servers going up every day. Instead, another feature of the public-private key encryption can be used: signing.

"Suppose you want to sign a message, to certify to the recipient that the message is authentic, you know, actually from you. You can compute the hash of the message (a kind of fingerprint) and then encrypt that fingerprint with your private key. If you attach that to a message, you've created a kind of signature. If the recipient wants to confirm that the message is both from you and has not been tampered with in transmission, he can decrypt the signature with your public key and check his own hash of the message against the one you encrypted. Since no other party has your private key, only you could have created that hash."

"So how does this apply to certificates?" Jordan asked.

"Well, public keys in SSL land are contained in certificates. Every web browser is populated with the public keys of a number of "certificate authorities," which are just companies who make and sign certificates. When you start up a communication with an SSL server, it sends you its public key, its certificate. To confirm that the certificate is authentic, the browser checks the signature using the public key of that appropriate certificate authority," Flir explained.

"It's a kludge of a system, but it works. Every Web server can give away its own certificate, so they don't have to be centrally stored. The web browsers only have to ship with 70 or 80 certificate authority public keys and they can just check Web server certificates against them."

"So what's so stupid about the myPtech website?" Jordan asked.

"Basically, they've created their own certificate, which isn't signed by any pre-populated certificate authority's key. So the students' browsers can't authenticate that certificate. And if they can't authenticate it, someone could man-in-the-middle it! Anybody could just put a computer between the users and the myPtech server, make a certificate that looks just like the one on the myPtech site, and run their own Web server or custom proxy. All they'd need was some way of redirecting the traffic to that computer, but that's not tough. Then everyone would send their passwords and data to that computer, not realizing it was the wrong server! I've got to whiteboard this..."

He had trailed off, but Jordan had gotten confused by Flir's last explanation. She wasn't sure how you'd redirect the traffic away from the real Web server or how the proxy would work. She was pretty sure this was another famous Pacific Tech prank in the making, like the time they'd moved someone's car into their dorm room by taking it apart and reassembling it there or the time some MIT students had temporarily changed the last three words of the marble inscription on the inside of the campus's main dome building so the inscription read Established for Advancement and Development of Science and its Application to Industry the Arts Entertainment and Hacking[i]"" The pranks took extreme planning and Mitch had started scribbling diagrams and sentences onto the whiteboard. She'd let him think it all out and help him with the resulting prank if it ever turned into that.

Jordan went back to reassembling the Toyota Prius from parts strewn about the room. Flir had purposefully trailed off, remembering that he wasn't allowed to tell anyone about what he was doing, even Jordan. He'd need to be more careful, especially since Jordan now knew that Flir had been thinking about how to attack the vulnerability. If the school realized what had happened and told students, Jordan would probably figure out that Flir had been involved. Then again, if Pacific Tech was like most organizations, the school would never reveal any major compromise to the students, even if the attacker had gotten their personal information. Still, Flir reminded himself to keep quieter about his plans.

As he looked around his room, he was annoyed at the mess, but he knew that Jordan needed that outlet for her energy. Anyway, he was already busy formulating his plan. He needed to sniff traffic from students to the web application without being detected. He didn't even think about setting up the sniffer in the dorm room, because he really didn't want it to be that easy to trace back to him if it was discovered. He could pick the lock on a dorm networking closet, but the dorms were the wrong place for this. He'd be changing the network flow patterns for the local network and bringing a whole lot of traffic through his one system. Given the huge amount of bandwidth being used by peer-to-peer music sharing, this could be dangerous. No, the computer lab would be a much better environment. There was virtually no peer-to-peer there, it would be hard to trace back to him, and he'd get to sniff traffic from a much larger group of students. Flir stepped over the car's tremendous rechargeable battery pack, nearly tripped onto a 3-foot solar panel, and kissed Jordan goodbye. He left the dorm room to begin his trek to the computer labs.