 Ladies and gentlemen, and gentlemen, John Adorto. You couldn't hear that. Ladies and gentlemen, John Adorto. I am not John Adorto, and we're not talking about extra-sensory perception today. We're talking about educational software packages. Right, but we would like to use the plan words to have a little fun so hopefully you'll play along. The views and opinions expressed in this presentation are solely those of the speakers and do not necessarily reflect opinions of their employers that come through the era, residents of Las Vegas, residents of Nevada, anywhere in the United States, or on the front of Earth. Nothing we're saying should be construed as legal advice. Don't rely on anything we say. Do your own research. You got a tough crowd today. Yeah. In an effort to be even more ethical than I'm already being, and not to get sued, we're not going to release the names of the educational software packages that we researched. We will tell you that they're very prevalent, and the one or two that we're going to show you are used a lot. They're very prevalent out there. Now, this is only a 20-minute presentation, so we will be taking questions in Q&A Track 4, which is Room 105 down the hall. So if you could hold your questions, we'd appreciate it. All right, let's start with who we're not. We're not the psychic hackers underground knowledge-based developers group, or the military operatives of roaming Earth, a psychically-hacking US citizen's data. Who we are. Today, I'm playing the role of Joe Cicero, a network specialist instructor for a technical college in Wisconsin. I've had positions ranging from director of information technology down to help desk support, but my passion is teaching. That's what I love to do. I love tinkering with technology, which is where this presentation came from. And today, I will be playing the role of Michael Vue. I, too, come from a large background of technology, done networking support over to programming, and, of course, now into security. I, too, do instructing and teaching on the side as well. All right. Why look here? We knew you were going to ask that. Because everyone in the room either went to an educational institution or is going to an educational institution. Well, unless you're a homeschooled. Well, that's true. By their nature, educational institutions must keep your personal, confidential information. Otherwise, how would you prove you went to a particular college, university, or school? Well, it's true. Because if you go to another college or university, or if you go get a job, they're going to want proof that you have the education you say you have, right? So the question is, are they secure? Yeah, that's the question. We wanted to look at whether or not they were secure. This presentation started when a former student came to me and said, hey, I'm being forced to use this educational software package, and it forces me to log in insecurely. I really don't like it. So we took the research and we ran with it. All right, let's get started. Somebody in the back row, tell me what's wrong with this page. Blurry. How about now? It's not blurry anymore. All right, Joe, but just because we're using HTTP, doesn't mean anything about the submission is not secure, right? Yeah, that's exactly what I told the student. I said, this doesn't mean anything. Let's take a wire shark capture and see what's going on when you actually log into this page. So here's a wire shark capture. And if you notice, it has user ID equals, and I use the username, this is my username, and password equals nothing. All right, but that doesn't make any sense. Yeah, I mean, that's exactly what I said. It doesn't make any sense. There's no password coming through. Let's take a closer look. So we took a closer look at this particular educational software package, and we noticed it was using JavaScript in the login page. All right, but if anyone here knows anything about browser security, which I'm guessing we do, you're going to disable JavaScript, right? God, are you psychic? That's exactly what I was thinking. So anyone who's got JavaScript disabled, what will happen? So we went ahead and we ran the test. We turned JavaScript off. We ran the same test, and you'll notice on this ESP, if you're going to this college using this ESP, the user ID comes through in clear text. This is the username, and the password comes through in clear text. This is the password. Okay, so if we actually attempt to increase our security by disabling JavaScript on our web browsers, it actually gets worse. That's exactly right. You're trying to be secure, and they're making you not. Wonderful. Yeah. All right. So what about if JavaScript is turned on? Most users aren't going to turn their JavaScript off. They're going to be running their JavaScript on. So what really happens there? We wanted to take a closer look at that. And when we did, of course, we know that we're not going to see the username and the password. We did another test, and what we saw was this encoded PW, which, you know, it doesn't take a psychic to know that probably means password, and then we had this string of characters. All right. So what's the JavaScript doing with this funky string of characters? Let's take a closer look at the JavaScript. So here's the JavaScript, and you'll notice that what they're doing here is using base 64 encoding to encode the password, not encrypt the password. So the question is how easy is it to decode base 64? Exactly. All right. How easy is it? Not very hard. There are tons of programs out on the web to decode base 64. We went out to this website, punched in the string of characters instantaneously, we got back our password. Now, hang on a second, Joe. I thought we were going to talk about a large ESP that's used all over the planet. I mean, this has got to be some small shop because nobody programs this way. Yeah. Nobody would make this many mistakes you would think. So what we did is we ran out to Google, and we went ahead and did a Google search that was specific to this educational software package used in an insecure manner. We wanted to see if we looked for this, what are we going to find? How many we get? 34,000, 34,100 to be exact. But I'm guessing everyone here is familiar with Google, right? We know there's going to be false positives in that. I would guess there's false positives, too. But even if it's 50% of this, that's 16,000 sites that allow us to just sniff the network traffic and have username and passwords or automatically see what somebody is by decoding it. Okay, so what do we know now? All right, let's go through what we know now. We know that if somebody is attempting to, with this educational software, secure themselves, we're going to be able to capture their username and password in clear text. We also know that if they're not, if they're doing things typically, they're running JavaScript, we will be able to decode their password, get their username, and be able to log in as them. Now, we can do this on a network with hubs, a network with switches where we're doing our poisoning, or a wireless network. Now, it's not too big of a stretch to say, okay, I've got the username and password now. All I have to be able to do is jump on Tor or jump on a proxy or use somebody's open wireless access point to instantaneously log in as them and not be caught. Now, that's very true, and I'll give you that. It's very easy to do. But the problem is, is if you do that, there's going to be a log in a record somewhere and someone's going to know you weren't the person that you were logging in as, because if you used Tor, the individual's going to know they weren't in China that day. So how can we do this stillfully? All right, so what we decided to do is let's take a look and see if there's any way to sidejack this. We knew from last year's DEF CON, the Google Gmail vulnerability was based upon a cookie. Let's see if there's... We knew we saw a cookie flying by when we did the wire shark capture. Let's see if there's any similar type vulnerability here. So we took a look at the PC, but we weren't able to find the cookie. Now, we know we saw it flying by in the wire shark capture, but it wasn't in and up on the PC. Further check showed that what was happening was they were expiring the cookie on January 1st, 1970. Now, I'm no expert in the field of cookies, but I'm going to take a shot in the dark and say, if you expire a cookie in January 1970, it's never going to get written to your drive. That's exactly right, but what this did is it pointed us to something else. This session ID, as we were looking at the traffic, we noticed, hey, what's this session ID and this string right after it? All right, so it looks kind of important. What does it do? All right, let me show you. Here I'm logged in as Bob. Now, I've stolen Bob's credentials, I actually am Bob, and I'm logging into this ESP. I went ahead and did a Peros proxy capture, and what you'll see, Peros is capturing the session ID. Now, below it is another session ID that I've either captured, well, yeah, that I've captured. I've got the session ID that I've captured, and the idea here is, as Bob, we're going to take the session ID we captured from the other user, for which we don't have credentials, and we're just going to paste it in where Bob's session ID is. Now, this is important. We didn't change anything else. Peros proxy, Wireshark, capture a session ID, grab the session ID, stick it into Peros proxy, and guess what happens? We become Jan. Now, this is scary, because for a couple of reasons. Number one, we're now piggybacking on Jan's connection, so we're logged in while Jan is logged in, and while there may be logging going on, it's certainly going to be a little more difficult to say who did what. Also, if Jan closes her browser, she doesn't log out, she closes her browser, we'll stay logged in. And the reverse of that is true. If we log out instead of closing our browser, Jan will have a denial of service. So some pretty interesting things about that session ID. Okay, so that's all fun, but the big question is, is when do we get the session ID? Yeah, we get the session ID before we log on. Before we give a username, password, we get that session ID. Now, why is this dangerous? Because now you can sit down to a kiosk machine in the school, go to the site, grab the session ID, walk to another computer, wait for somebody to sit down at that computer, log into that ESP, and you can automatically become them. Other problems with this are if you wanted to develop a local exploit that would grab that session ID and email it off to you, now you have a remote exploit where you can be sitting at home or somewhere else and be getting these session IDs sent off to you. Okay, so are we done yet? Is this enough holes for everybody? Everybody done? You know, we have enough holes? No, we didn't stop there. We decided let's take a look at what else this ESP does and see if there are any other vulnerabilities. So obviously we want to look at cross-site scripting. This particular educational software package has the ability to have this little note pad issue here. So we can have this little note. So we went into this little notes area and we went ahead and put in some script, see if we can run the script, we're cross-site scripting vulnerable. Voila. Yeah, ouch. Nice. Now, that might not, you know, so what? You know, you made a pop-up window that said cross-site scripting vulnerable. Well, with this cross-site scripting hole, now if we are able to piggyback on to this particular user, we can put this into this notes area and every time they log in, they'll send us their, if we use the cross-site scripting in a cookie grab, we can get their session ID. Worse than that, if this vulnerability exists here, it probably exists in global areas where this ESP has multiple people logging in and we'll be able to grab everybody's session ID. So, pretty scary. Okay, so we have enough vulnerabilities, but because we are who we are, we certainly didn't stop there. We wanted to see what else we could do. Yeah, all right. So next we wanted to see how the ESP worked and what we could do. So this particular ESP has these little widgets. Let me previous that. It has these little widgets and you check the boxes and you can personalize your little educational experience. So what we decided is let's check those boxes and take a look at what that does through Peril's proxy. Now as you can see, when you check a box, you get a number. Now what we did is we looked through all the numbers for all the boxes checked to see is any one of them not there and what we found was 131 wasn't listed. So what's a good hacker to do? Let's add 131. So we went back, we deselected some things, we checked the box, changed 129 to 131 to see what we would get and wouldn't you know we got a widget that the administrator didn't want us to have. Now this isn't a very sexy widget. All right, they didn't want us to know what movies were going on. But we didn't try all the numbers and we didn't try changing the module name. Instead of add module, something to the effect of add admin module. That'd be fun and it's on our list of things to do. All right, so just to recap real quick, Joe you've done all this great testing and stuff but the problem I have with all this is today you're pretending to be an instructor from an educational institution. That's right, Paul. So you would have insider information, the rest of us just wouldn't have. Right? So two options. We could all go get new jobs. I don't think they're going to hire me and the second one is we could all take a class out of college just to test this vulnerability. That's not realistic. So how else can we do this? All right, well let's take a look at that. Let's see if those are problems that are going to stop you. All right, brute force or take a class Y. This particular educational institution tells you what their username, password, combination is. So now all you have to do is grab some metadata off the web, go out to MySpace, Facebook, or LinkedIn, grab the information you need and go ahead and create a database to go ahead and log in. But wait, that's too much work. So what are we going to do? Hey, this particular ESP allows you to click a create button. All you want, you want to log into the site, just click the create button, add yourself as an account, do all the testing you want. Too much work for you? Don't stop there. Just click the preview button. What's one of the rules that we have when we set up systems? Hey, get rid of the guest account. They're actually adding a guest account. With all of these different vulnerabilities, you are bound to get into this ESP. You're bound to grab some information and imagine that other people, nobody in this room, shares passwords between accounts. Well, that would be a poor practice. And you know, speaking of poor practices, since we've identified an ESP with all kinds of vulnerabilities, you know what else we thought would be fun is if we could find out what other applications or services this particular college offers. Do they have wireless? Do they have password syncing and all that other kind of fun stuff? Yeah, but how are we going to do this? We found a potential 34,000 sites out there. If we break that down to 50% false positives, that's 16,000 sites. My God, can you imagine going to 100 places and just trying to walk around or ask them or show up or research their websites to find out, well, what other applications do they run and are they running wireless? What do you expect us to do? You just going to ask that question? Yeah, actually, I did. That's exactly what we did. All we did was send them an email. We said, hey, listen, we just want some information. What kind of wireless access do you have? Do you offer online classes? Do you have password syncing technology? Just some very basic general questions. What's really important to know, though, is we did not lie and we did not falsify any information. All we did was ask questions. Of course, we have to have statistics on the asking questions, right? So we sent out about 100 different emails. We got approximately 50 back. Of course, all 50 are using our targeted software, but of course, we knew that. That's why they got the email. And all 50 were using online classes, which is a product of this ESP. So we kind of knew that already, too. The two really cool facts to point out is 47 out of the 50 offer wireless access. And the majority of those actually came back and said they offer wireless into their outside areas. So you can go sit out on the lawn and be on wireless network when you walk from room to room. That's great, really great for us because we don't physically need to go into the building. And the other interesting fact is 28 out of the 50, and that's more than a 50% ratio, actually have password syncing technology. They're actually encouraging me to use the same password and username set for multiple applications. The insecure one and... Right. So we've got this beautifully unsecure application that nobody cares about because it's got no sense of data in it. But we can share the password so therefore my banking information, my college information, my student loans, they use the same password. Ooh, goodie. Yeah, but how often do these things happen? You know, you'd be surprised. Legal advice sought on data leaks. Bates College student newspaper uncovers data leaks. Boston College reveals alumni data breach. A&M posted 3,000 people's personal data. Government agency exposes daycare data. Japan military school rated over ages data leak. 15-year-old student breaks into school computer system. The biggest data disaster ever. What are these? These are all headlines that we found in newspapers online. So it's safe to say, and I don't think many people can argue with me, that this has happened before and it's certainly going to happen again. So a couple other quick boring numbers for you. The Symantec report came out April 2008, which subsequently was after we published our white paper for DEF CON. What the two things I'd like to point out very interesting is educational institutions were actually responsible for 24% of data breaches in the United States. And looking at the chart, the U.S. government was only responsible for 20%. And I think we all know how backwards the government is. All right, so what do we think is the cause? Educational institutions are fighting for your dollars. If one educational institution has to have online classes, then all the other educational institutions want to have online classes. If one's going to have student email, then they're all going to have student email. If one is going to have instructor websites, then they're all going to have instructor websites. And what happens is, they start putting these systems together with no thought into how do we do this and how do we secure it. Their belief is, I've got a system here, it really doesn't have any critical data on it. I don't have to bother securing it. Right, but the problem is, they don't think like we think, right? We all know the advantage of getting our virtual foot in the door. Even if it's through one of these seamlessly insecure meaningless applications, because once we get into this insecure application that has no data in it we don't care about, with the password-syncing technology, we're going to be able to get into all the other applications on their systems and get the information that we're truly after. Our personal recommendation is maybe some of the IT staff should take the classes they teach on security? Yeah. All right, we have some things to quick send out. We have other researchers, but I want to specifically mention Ben Dyer, Samantha Lee, Tom Burke, and ArcNet Dipswitch. They were researchers that helped us out with the product or with the project. If you want to contact us, you have a question or you want to go to the Q&A room track four. We're going to be in Q&A track room or Q&A room for track four. If you don't have time to go to the Q&A room, I've got some business cards up here. Also, if you want, you can email us at hacking.esp at gmail.com. We want to wish everybody a great DEF CON. We appreciate you coming out to the talk. It's great to see the room is filled up. Hey, have a great DEF CON, everybody. Thanks, everybody.