 Now, see, this is the part of the presentation when I usually photograph the audience, but I want to issue you with a warning. What we're going to review here is how to audit, how to legally audit or search for vulnerabilities in web applications that you have written permission to do those kind of things. So make sure you do get permission in writing. Maybe some of you are familiar with Randall Schwartz. Nice guys. Finished last and with three counts of felony. So check out the link in his legal case years ago working for a small company called Intel. And he got in trouble for doing some cis admin stuff on boxes that technically weren't his. So you've been warned because you don't want to go to jail. Hello, sir, please. I can't go to prison. They'll be in a cup and throw it on you. I saw it in a movie. All right. All right. The following presentation is based on actual case studies, actual vulnerability assessments that I've done over the last whatever number of years since early 96. So these are true stories. They're not fiction. You want answers? I take out the title. You want... All right. Last sound effect for quite some time so you can relax. So we're going to about to see the point of pointing out that the real is that if these folks made these problems, maybe your corporation could be having the same problems. And we're talking the big boys. I've been fortunate enough to be in the right place at the right time to do some assessments for I refer to one of them as Big Bank under NDA. I can't say who it is, but very large banks, global banking, business to business banking, online reservation systems, 401K programs. You've named it. I've seen it. So I've taken some of the vulnerabilities that I've discovered and I've sort of put them in here, changed it around so you can't tell who it is. And make it more interesting. All right. So why are we here? We're going to talk about various web-based vulnerabilities, web application vulnerabilities, and the tools and methods needed in order to locate them and identify them. What we're not going to talk about is comprehensive methodology. I believe I'm speaking at Use Next Tuesday on a full day on this. So come on down and check that out. But otherwise, we're just going to skim through it real quick and hit the high points and show you some examples. We're not going to cover all tools. My apologies in advance if you were tooled it and make it in the presentation. And you think the ones I'm demoing are not as cool, sorry. And we're not going to talk about solutions, although part of the solution to any problem is to know you have a problem, right? That's always the first step. So that's as far as we're going to cover it as awareness. A little bit about me. Any Penn Staters? Woo! I'm the only one. Okay. Alrighty then. I started my illustrious career at a little-known company known as Bellcore. Perhaps some of you know them because you're on their networks years ago as a phone freaker, Bell Communications Research. And now I'm working for Maven. And that's me on the right. Wow! That's a great story. I'd love to hear the end of it sometime. Bye-bye. All right. Here's the agenda. We're going to very, very briefly define the problem. I think we know what the problem is. And then we'll get into a tool set, kind of build up a set of tools that cover the key functionality required to look at the security of a web-based application. And then very quickly, we'll try to move through that. There's a lot of reference material, stuff I'm not going to cover in detail. But it'll serve as a good reference later when you download these slides off of the DEFCON site or off of our site. Once we have our tool set, we're going to take a look at some various points of attack, points of weakness within a web-based application. And then we'll start pulling out the tools and going to town and doing some demos. And then finally, after I point out all the various problems, we'll give a list of resources of where you can go and download best practices, you know, how to code, how to filter user input, all that good stuff, how to secure your web-based applications. So I won't leave you hanging. I'll give you some resources for further research. All right. What is the problem? Can't we just all get along? No. No, we can't. Websites are getting hacked for all various different reasons, perhaps some sort of genetic deficiency or not deficiency enhancement, sorry. But regardless of the reason, you know, the bottom line is sites are getting hacked and there's lots of great sites out there that show you the defacements like Zone H. And we're not just talking about web sites being scribbled on. In a lot of cases, we're talking about applications that have been exploited. And in fact, I have here captured some of the latest headlines under Security Tracker because they have a category for applications. And so you can zoom in here and take a look at all these web-based applications. Most of them are web-based. They show you how, you know, various things can be exploited right through the comfort of your own browser. And here's a nice one here, further down, where you can do command injection. But just by modifying the URL, we're going to see some attacks like that. Only we won't be able to put it into the URL, we'll have to do it through a cookie. And again, real examples. All right. So the bottom line is somebody is going to be flipping burgers because the website got hacked. That's the problem. Web apps are getting hacked. Very big problem. And it's only going to get worse as everything's being web-ified. Old database or mainframe apps are now web-ified. The military, I've seen articles of the military talking about web-ified weapon systems. Yeah, we're going to need you to not do that. Yeah, especially when you see the examples that I do have. So that's probably the biggest thing that worries me. Here are the essential techniques that we need for our toolkit. We need to be able to intercept and manipulate raw hypertext transfer protocol. That's the stuff going between the browser and the server. And we also would like the ability to mirror a website. And I'll cover that briefly, but I don't have any demos for that. Also, we want to automate fake browser requests, brute forcing. Not just authentication either. Brute forcing, various elements. Some folks call it fuzzing. And I'll show you some stuff for that. And then finally in your toolkit, one of the more important things is to be able to decompile Java applets. And so that's what we're going to very quickly build a toolkit and then move on to see it in action. The first and foremost thing is to be able to intercept and manipulate your traffic. Why do you want to do this? Well, you can bypass all sorts of client-side restrictions way back in the day. People thought you could filter user input by using client-side JavaScript. It doesn't really work when the person owns the system, the client-side system. And they can bypass all that. Want to be able to maybe violate the HTTP protocol by adding in headers that are too large and things like that. Maybe insert alternate choices in the pull-down menu or pretty much just change any portion of the traffic. And we'll see several examples of that today. And also, not to be forgotten, it's very important if you're intercepting your traffic, you want to record it. Later on, you'll be able to search through it for various things like hidden comments within the HTML. All right, so let's cover a little bit of history. This is old news, but Achilles was the world's first publicly released general purpose web application security assessment tool. Anybody heard of it? Yeah, OK. So that was a little idea I came up with a couple of years back. I was actually using something similar, only less stable. And if you can imagine anything being less stable than Achilles, there you go. And so I got with my friend Roberto. And he just coded it up real fast and threw it out on the net. And my apologies. So it was released in October 2000. Shortly after this was released, Rainforest Public came out with something. And then the folks at that state came out with something. And I know a couple other people. Now there's a whole bunch, and they're all vastly superior. I include it in here for historical purposes. So what was it? And what are the others like as well? It's like a matrix style web proxy. You can freeze frame your traffic and be able to manipulate it and then send it on its way. And the really nice thing about Achilles is that you can modify traffic in either direction. And so you can also modify SSL traffic. Doesn't matter. Encryption does not protect your website. I know the vendors like to say it's secure HTTP. No, it's private HTTP in transit, but it doesn't really secure your website from buffer overflows and all sorts of manipulation. And again, apologies Achilles only runs under Windows. But you can force it to run it under UNX with wine. But it's basically a big clue and just like notepad with an attitude. And this is kind of what it looks like. You can intercept your traffic and modify it. And I'll give you a little demo of that later on. But here we see a request actually reply coming back from a web server. And they're trying to set a cookie for us. And this is our opportunity to modify the cookie once and for all before it gets into our memory. Most other tools that are in this category will let you modify it on the way out. So you have to modify it every time. This is a nice way to modify once and for all without having to repeat it over and over. So this is how it works with SSL. You have a web browser talking to Achilles. Achilles acts like a web browser when it talks to the server. But when the web browser, it's when the real web browser talks to Achilles, it acts like a server, web server. So when it comes to breaking SSL, it creates two SSL sessions. And so now your browser will warn you, hey, the digital certificate from Yahoo is signed by somebody named Dasquid. And it's not Verisign. Dasquid is Rob's old Navy nickname. So it has a little certificate and everything. And so it does man in the middle, but it obviously doesn't break crypto. If it broke SSL, it would have made more headlines. So no. But for auditing purposes, it does the job. I see everything. So just a real quick demo then. And then I promise we will move on to vastly superior tools. But is there any work being done on Achilles? No. There might be if you request it nicely, but he doesn't seem interested. I tried to explain to him how important this really was when it came out because it was the first. Will he give out the source? Probably not. But I know a couple of people that came up to me and said they reversed it. And the code is really poorly written. And I was like, where do you work? And they're like, oh, crank call, crank call. And they walk away. I think he was working for IBM, actually. So no, I don't have the source either. And that's the problem with coming up with a great idea and then having someone else code it. Is they control the source. They can do whatever they want. So I'll put a request. And I think it's time for a new version, maybe something that doesn't crash every five minutes. And so I'll give you a quick demo. So you just configure your browser real quick to use a proxy. Many of you probably use a proxy at work to get out. Well, you just change it to this proxy, which is you can run it on local hosts. You can run it on another box and connect. And once it's running, you can intercept your traffic. And here it is. And so you can go ahead. Let me zoom in real quick before it crashes. You can see what I'm about to send and send it on its way. Now, the interesting part comes in when you go to modify traffic. Let me go ahead and modify something real quick. You can turn off the point and click. You can just have it flow through uninterrupted for a while if you're tired of always going over and clicking it. So let me go ahead and show you this. So we zoom in here. And I can go ahead and bypass any client side restrictions and add a whole bunch of 4,000 digits for the pen. Achilles will go ahead and take the content length and rewrite it for you to the proper amount, which at the time it came out was a big relief for me because back in my day, we were sitting there having to do that manually. And so nothing terrible happens. But we'll get back to this application called Buggy Bank later with some more sophisticated tools that will automatically go in and manipulate things for us. But I'm going to go ahead and turn off Achilles so I don't accidentally surf through it later. And it's like the Model T. It's nice in a museum, but I wouldn't want to go off-roading in it. It modifies traffic in both directions. So when you tell your buddy, hey, we've got a new web proxy for the company. So you've got to surf through this. And when they're surfing the website, you can change things on the inbound. So now new tapes emerge on US Hunt. Hunt's dark tangent. So you could modify it and modify things on the way in and stupid party tricks. I'm not sure what good that is for security. Although, social engineering. All right, so what are some of the better tools out there? My vote goes to web proxy by at stake. Version one was free. It's still online somewhere. If you look hard enough, it's Java based. It'll run on anything that runs Java. Version two is commercial. I don't know the functionality difference. And then if you're really hardcore, you want to use the spike proxy. Just some more references for you when you download the slides. There's lots of good tools out there that are like Achilles, only stable. And finally, there are some tools that are more like browser replacements and or extensions to the browser. And we'll see some of these. They put functionality in your browser. So now like it's extremely easy to manipulate hidden form elements. And just to also want to mention these other tool kits are out there. These are more all purpose. They don't just simply intercept and let you modify something. They do more than that. They'll maybe crawl the website for you. They'll automatically modify things for you. Very powerful. And so check those out as well. So a little bit more, let's take a little closer look at web proxy by at stake. What happens is once you start it up and it's your browser's configured to use it, all you have to do then is surf to a special, actually I already have it open. You just surf to the special keyword web proxy and the interface pops up. I kind of like that. Some people don't, but you can go in here and you can create intercepts. And what an intercept is, you tell it, look, whenever you see this string, and it's four I's, I just picked I because it reminds me of the word intercept. Four I's, when you see that going out, I want you to freeze the traffic matrix style and let me change it. And that'll come in very handy when we wanna start manipulating our cookies and things like that. And we'll talk about that when we get to the actual attacking portion. But for now, this is just a toolbox. One of the more powerful features is the fuzz feature. It allows you to go in and say for example, let's go to this and let's, let's, I created an intercept of four I's. So when it sees my pin was equal to f, f, f, f, it pops up this interface. It says, hey, what do you wanna change? And I zoomed in here and I say, well, oh look, there's a hidden form element called transaction. Why don't we go ahead and automatically kind of hack through a whole bunch of choices for that? And it has a list, user definable list of things it'll try. It'll try various SQL injection, cross-site scripting, whatever you want, you can put into a text file. It will try the text file that it comes with, known as fuzz strings. It's kind of limited. So you wanna add some of your own. I'll tell you where to get some. One of them you can, is from there's a Nessus plugin that actually does some fuzzing as well. You could just look at the source and you could see the various things are trying. So we're done. Here's what it did. It actually went through and it sort of brute-forced that one form element and it tried all of these things. It tried a zero. It tried a minus one. It tried some special characters. It tried some file name stuff. And it apparently was successful or found something down here and it turns out that that's cross-site scripting. If you would go in here and look and analyze it a little bit, you would see that it's cross-site scripting. But we won't do that right now. Just wanted to show you that it has the ability to automatically go through and hack. Now there's some vendors who sell tools that do this for lots of money. This one's free. Or the commercial version of AdStake, it's only like $995. There you go, you buy two, right? That's cheap compared to the other tools that are out there. And some of those other vendors use phrases like robo-hacking technology. It's a for loop, man. It's just going and it's just repeating through and or artificial intelligence. Say listen, if a vendor ever tells you their product has artificial intelligence, they're referring to their sales and marketing force, okay? Yeah, right, okay. Another nice feature about the AdStake tool is it has a console and you can see all the stuff flying by. And so this is your opportunity to see the headers and to notice when certain cookies come into play, things like that. And we've already seen that. How many folks have seen the FAQ that's, how many folks have seen the web proxy tool? You ever, did you read the FAQ? It says, are there any undocumented features? Yes. And then it just moves on and it doesn't. Does anyone know what those undocumented features are? Anybody? We'll see here. Okay, one guy. All right. If this is not the one you know about, we gotta talk. So this is worth the price of admission right here. Let me tell you about one of the features it has. Never mind how I know this. Crank call, okay. It can be a transparent proxy. And what that allows you to do is if you're forced to absolutely go through a proxy because the application insists on it, well then what you need is a proxy in the middle between you and the official proxy that's invisible transparent. And that's what a transparent proxy will allow you to do. The official proxy won't know that you're using yet another proxy. So how you do it is you would just add that line into the config file when you start it up. And I hope nobody's mad that I revealed that. But hey, they're the ones with the FAQ teasing you, practically begging you to investigate further. So there you go. How or why that would be useful in real auditing situations is left as an exercise to the viewer, but it is useful. And then finally, IE booster. This has gotta be this ridiculously easy to use. My grandmother can now start like manipulating hidden form elements and come to think of it, she really did get a good deal on that. Plasma TV, right? Shopping online and we see there's two form elements that's asking for our account name and it's asking for a password. But we just right click. I'm sorry, this is only for IE. So folks out there with Mozilla, send me the URL if you know there's an extension like this. I'm sure there is. There's new extensions added to your right click menu to your context menu. And one of them is show all the forms and the applets. And so that's kind of nice, because then you click in, click on that, and it shows you there's a hidden form element. And oh look, it's in a little text box in case you want to modify it. Nice. And so we go in and we can modify that and just send it on its way. Look mom, no skill, right? That's pretty scary. That's one you show to your boss to get their attention when they say, oh, well, you know, it's all complicated or something. Just show them that one. They'll even be able to use it probably. Another technique within our toolkit is a brute force, specifically brute forcing authentication. And Brutus is one of my, used to be one of my favorites. It's gooey based on Windows and it will brute force web based authentication. It does. What kind of music do you usually have here? Oh, we got both kinds. We got country and western. It does both kinds. It does basic authentication and form based. And so it also does a lot of other protocols. Pretty much any text based protocol. Brutus, you can write a script in Brutus very easily with a gooey click and drag type thing to build a script to brute force, any kind of custom clear text protocol that you want to brute force. So it's nice in that respect. It's great for the command line challenged and one of the really nice features is it has this. When it comes time to brute forcing a password, you can load in a dictionary file or you can let it build a word list on the fly. So no longer do you have to sit around with a text file of all possible six digit numbers. You can just build it on the fly, save yourself some disk space. Less forensics evidence too. I mean, all right, so what? It also has a permutator built in as well. It'll turn your password dictionary file into elite speaker, whatever, by making the fives. S's into fives and all that good stuff. Very handy tool, but the one I'm gonna demo is dub, dub, dub hack later on. But a point of interest, these are other authentication brute forcing tools, is Screaming Cobra was interesting, historical, historically speaking, because it would crawl your website, find all the forms with form elements, hidden or otherwise, and would automatically fuzz them. So, but it's not being updated, it doesn't support SSL, but it's a Perl script I believe, so it's open source. And you can go ahead and change that. And also Nessus has a plugin that'll brute force CGI parameters. There's a nice little list of things to try or things to add to your other fuzz programs. And finally some more references where to get word lists and tools that'll build variations. That is the per me take the word to make the zero, O's into zeros and things like that. I think the last thing in our toolkit, oh no, next to last is we wanna decompile applets. Java's compiled into byte code, but that can be decompiled. Where are you gonna get an applet from? Some applications use client side code. They send you an applet. If you've ever used IBM's host on demand, oh man, that thing's a mess. It sends you all these applets and it's like a web front end to old mainframe applications. Yeah, that's what we wanna do. We wanna webify our mainframes. We wanna put roller blades on a dinosaur. Yeah, somebody's gonna get hurt. All right, this thing was not meant to have that many concurrent users and all that good stuff. So anyway, that's where I stand on that. And so you have client side code. You can also maybe steal the applets from the server because of server side weaknesses, the web server's misconfigured and you can retrieve any file. So what file are you gonna pull? Pull their source code, decompile it and there you go. And then of course, a lot of applications like web proxy are being distributed as Java. So you could, within the bounds of the law, decompile them and start doing all sorts of stuff and reverse engineer them. Not that I'm saying you should. And so they may contain sensitive information. Why would you wanna do that? Well, we have seen, during audits, applets which have hardwired credentials because they think, well, it's compiled even though the applets on the client side, it's hardwired in and it's using encryption so nobody will be able to see it and it's compiled so nobody will be able to see it but you can actually pull it out and or secret URLs and or undocumented features and things like that. And there's some tools for decompiling Java. Finally, last tool you probably want in your toolkit is something that'll crawl and mirror a website. The theory behind this is you could go out through a whole bunch of websites, pull down the HTML that they're willing to serve to you and then search through them for inappropriate things like hidden comments, the meta generator tag. It'll tell you if they're using front page or not and or you also wanna try to find a Miriam package that will record the HTTP headers. My preferred method when doing assessments is to fire up one of these proxies and put it into recording mode and just let it dump everything to a file then pull out a command line with grep, search tool and then just go to town. And so that's probably the preferred way. I don't know that I would let some automated thing go through my web app and start pounding away but their entire products based on that theory so I have to be careful. And here's some headers we've seen. The Xbender header, care to contribute to the anti-mugging you fund? Bender as in Futurama. Who knows where these headers are coming from? This is the slash dot. If you go to slash dot, dot org, website use one of these proxies and take a look at the traffic. They throw in the Bender headers for whatever reason and then occasionally the Xfry header as well. And there's some tools for you. We're not gonna do any demos for that. So now we have our little toolkit. Let's get busy. And these are the main points of attack we wanna look at today. This by no means is all of it but this covers really some of the core essential problems with web-based applications that are worth investigating. So first up is authentication. No surprise here you can brute force stuff so I'll give a real quick demo only because I wanna make sure everyone's aware that there are tools. Yeah, sure you can phone home. So this tool is ET is phoning home and trying to contact like a porn ad server. So I'm not sure you might consider that a feature or I'm not sure but anyway, since I'm not on any network that I'm aware of it should be safe. I wanna make sure you realize that these tools are now dirt simple. So let me see if I can find a login for it to brute force. Here's one. We'll go here, go to the login page. Bring up the tool. It does, it brute forces various protocols but the one we're interested in is HTTP form-based. So we'll click on that. And automatically out of memory it knows that I have a browser open with this URL. So it's just like, hey, is that the URL you wanna brute force? It's very friendly. Now, let's go back, let me go back here. Let's right click this with and take a look at the underlying structure with. Wow, what a mess. This has got a lot of hidden form elements. This script will discern through artificial intelligence how to brute force this particular form. It will know through a simple search. I'm sure that the form element called username is probably the username. And the one called password is probably the password. So they have real simple obvious names. So when you click the auto magic artificial robo button. All right, now I'll be mean. Boom, it fills in username, field is username and password field is password. And it has a little database of pin or P-A-S-S for password or P-W-D or things like that. And then all the rest, it just kind of shoves on the command line or on the URL. So that's all it takes for this tool to learn and be able to brute force any generic form. Sweet. You give it a string that is always found when authentication fails. Very subtle but useful feature. You teach it what a failure is. Because we all can find out what the failure is. You just go to a website. If you're doing a blind pen test where they won't give you test accounts, you fail the login. Anybody can fail a login. It's easy. And it returns a string like return to calendar. So if we continue to brute force and we no longer see that string maybe, just maybe we got in. Now I've lost my tool here. Where is it? Okay, now I broke it. There we go. So we tell it to look for the string return to calendar. We got that and you just hit go and it does what it's gotta do. And it keeps sending that particular request over and over until finally it says the username is Al Gore and the password is lockbox. Is that true really? Did it work? Sure, let's find out. I'm gonna go ahead and close this tool down at which point it yet again tries to phone home. All right. And we'll type in Al Gore lockbox. And what do you know? I didn't kidding. It really worked. Whoop dee doo. Whoop dee friggin' doo. You say, well that's, we can just lock our accounts temporarily. Lock them to slow that tool down. Make it grind to a halt. Does that protect us? Sometimes. So this next one is kind of interesting. This was found in some online banking in Europe. I call it pin harvesting because what you could do is lock an account and keep on brute forcing until eventually you could get the password even though the account was locked. So first let me tell you what username harvesting is. That's where you go to an app and you go to log in and based on a failed login attempt you can figure out what is valid and what is not valid. So if we type in gibberish it says hey, that's not a valid, that's not a valid. There's no user by that name. But if you type in Al Gore it says bad password. So we have the ability to collect user names, harvest user names. That is not terribly significant unless the username is a private credential like in some banks do this, your bank card number, your 16 digit bank card number. And if you give error messages like that you've now supplied an online bank card validator. Probably, I would be very useful to some people but not to your customers. So that's username harvesting. Then what I discovered was password harvesting where I'm doing this assessment and it's big bank, right? And I was doing their assessment in the US and then a couple months later in Europe and then finally in Asia. Asia was the worst, had the worst security. I'll show you that later. We could run commands on it. This one we could, in Europe, we could only basically get people's pin numbers. When you lock your account you get a message. And in German that says roughly unfortunately this pin is wrong. That's when you try the wrong pin on a locked account. Eventually your account's locked, you get the right pin, the error message changed. That's just plain wrong. So I don't speak German but I know how to see two text strings change. And so I'm all about of the chair doing my little dance and then I realized the bank auditors right there next to me and I was like, oh, sir, you have a problem. You know. Very interesting procedure. The bank always had somebody there right next to me. And I figured it out later. They said, oh, it will help facilitate. If you need something, the web server's not responding. It was so that if I decided to retire early I'd have to split the money. That's what it was. And all right, so finally the last thing I think I'll put here for authentication is maybe you don't need to authenticate at all. So for example, this calendar software that we have here, let's just back up to a public web public site here. We notice the name of the calendars embedded as a form element calendar equals vapor external. So what if we were to go to March, 2002 and change that name? I'm gonna go ahead and change that calendar name to the word private. Oh no. We could brute force this with any of those point and click tools and lo and behold, things start popping up because now we don't have to authenticate as long as you know the calendar name. And I'm sure many of you've seen applications like that where you can suddenly get in just because of a URL problem. We don't need no stinking password. All right. Authentication might not affect your application because you don't have authentication. Maybe it's an online shop. As long as you have a valid credit card number or someone's valid credit card number and a shipping address they'll send you stuff. You don't need to authenticate. Well then what would affect you and pretty much every other application is session tracking. This is where you don't have a constant TCP connection to the web server. You make a little connection. You request something. You make a request. They send you the reply and you disconnect. And then the question is from click to click from submission to submission, how do they know you're the same you? How do they know you're the same person? They can't go by IP address because they're not unique. People use proxies and people are natted and stuff. And so you have lots of people appearing as a single IP address. And so what you need to do is something, you need a unique identifier embedded in the traffic called a session identifier or session ID. That is either usually in the cookie, it's a more popular way of doing it or embedded in the URL. So the next time you're at Amazon, notice that every single URL on the page has the same big serial number on it. And so that session tracking, if I can figure out what your session tracking, what your session ID is, I can become you. It's a small window of opportunity. It's just while you're logged into the application, but still it's viable attack method, especially since there are ways to get the session ID in real time from other users. So let's take a look at some of those attacks. You could predict it and that's pretty easy. What you do is you just figure out when and where this application first gives you a session ID and you would use a proxy tool and look for suddenly the URLs change and there's numbers in them or there's a cookie. When, let's for instance say it's a cookie, figure out where you get that cookie and then take that URL and then just request it over and over again with, I'll show you a nice little gooey tool again. Or of course, if you're on the command line, you could just use curl. I'll show you that later. Collect a whole bunch and then do a highly sophisticated mathematical analysis known as subtraction and then look for a pattern. So let's take a look at this. This is a nice little tool by iDefense. You guys here, iDefense? Okay. All right, so nice little gooey tool and very easy to use and let's take a look at this. So what we can do is just use it to collect cookies. I happen to know for a fact that Buggy Bank issues a cookie right here. So I take that URL and I can just go ahead and collect them. And then I, I think I see a pattern. 136, 137, that's the UNIX timestamp, the number of seconds since January 1st, 1970. So yeah, not a terribly sophisticated session ID for this particular application. And but that's just a fake example. Let me show you some real stuff. These are mock-up examples of past assessments. This is some credit union software. The numbers were much bigger and more random than this, but this was just a quick example I put together. And I'm looking at it and I say, well, as time goes by, time is increasing downward, the session ID is always getting bigger. Hmm, that's not random. So let me do some highly sophisticated mathematics here. I'll take one cell and I minus out the one before it and I get the delta and I say, okay, there's a delta between one cell and the other. It's 10,293. What about the next delta? Oh man, it's different. Oh, I guess I'm done, I'll just stop here. But wait, maybe I should just kind of keep going just in case. Uh-oh. Loser, yes, true story. Is Alfredo in the audience? I caught a coworker years ago, we were working on this together and I called him up and said, hey, log in and view cookies and tell me when you're logged in. And he logged in, he goes, okay, I'm looking at it. I said, dude, is your session ID 729473-287-9404-296? How'd you know? I know Kung Fu. Until I told him and then he was like, shh, you know. But even still, even if it's a little bit more complicated, this is a reasonable simulation of a recent assessment I did for us, recreational facilities, online reservation system, you go online, make ski reservations and stuff like that. And that looks thoroughly, that looks better, right? That looks more random, some numbers are getting bigger and some are getting smaller, sometimes it gets smaller. And you can really start getting freaky with this analysis. I told my wife, I said, you know, I made her watch A Beautiful Mind. I said, look, those are the signs to look for. If you see me in front of my computer, ooh, and the patterns are starting to pop out. No, I'm serious. I look back at some of the reports I've written and I spent just a little too much time analyzing, but I was successful in attacking systems like this. And when I say attacking, I mean auditing with permission. I do, I do, I get paid good money. So look, suddenly it's not so random. The delta starts to smooth out. So it's not totally unpredictable. So there was an application like this recently and I was able to figure it out and basically there were groups of digits and some of the digits were very predictable other ones and eventually was able to pick up other people's session IDs. So maybe you don't have to predict it. Maybe you could just brute force through the total space of possible IP of possible session IDs. And so the eye defense tool will allow you to brute force a session ID if it's in a URL. It claims to do the cookie as well, but there's a little coding flaw and it doesn't work. So you'll have to wait for version two or you could just use curl. I think I'll show you that later. And so you can brute force a URL. This again, this part does not work. If you wanna know why, put a sniffer on the line and you'll see why. It's using the wrong headers. So what I can do is, whoop, what the, you know, we'll look at that in a moment. So for example, we take a look at Buggy Bank. Let's log in as Fred and I'll view my account balance. And something I notice is my, there's something embedded in the URL. In every URL, after I authenticate, I see something called SID123. Now you might think this is a far-fetched example. This is probably one of the first assessments I ever did way back in the day. And they were using like a three or four-digit session ID. I'll give them some credit. All these parameters were encrypted. It was just a matter of finding the old CGI script. They had the old version still on the server that would decrypt it for me. It's really convenient, you know. So, and then once I saw that it was three digits and they were issued sequentially, yeah. I was able to work them backwards and pull out everybody's completed credit card application. And that's when one of my bosses was like, hey, could you like sort through those and find single women with like good credit ratings? It's like, with no dependence? It's like, no, I cannot. And so, to brute force that, you can go ahead and I just already worked out the syntax here. You would take that URL and put it into the brute force tool here. And it has a syntax where you tell it what digits start on and what type of digit range to use. And the number one means zero through nine. And that's all explained in a little info button here. Won't bore you with that. So bottom line is we wanna go ahead and brute force that URL, changing that number, looking for the occurrence of the phrase, your account balance, or account balances are. So that's the shoring we wanna look for. If we, because if we just randomly guess a number, we're probably gonna get an error message, right. So then we'll just let this brute force and it seems to stop at 133. And sure enough, you go in and you back up and you type in that number and it's, and it goes from Fred Bucket to, oh, it's my account. In a very healthy account it is. All right. Okay, so now, I don't want you to think I'm Mr. Gooey tool or something, right. So I have to put in some little command line kung fu here, if you haven't, if you're doing any kind of work with web applications and you haven't tried curl, you need to try it today, all right. Don't delay. So here's an example of a command. You can embed your own cookies, you can embed your own post data, and then finally the URL you wanna attack. I mean, this is basically a command line browser, sort of, it only does a single request and you get the response back. But because it's on the command line, you just wrap it in a pearl minus E, little script, right on the command line, and you can start getting busy. So here's an example of where this would go out and grab our account balance, not a big deal. However, if you iterate over the session value or at least the last three digits of the session value, you can go back through and start finding other people's session IDs. And so, and so that's left as an exercise to the reader. And so never underestimate the power of pearl and curl. Two great tastes that tastes great together. All right. Finally, maybe you can't brute force it. Maybe you can't predict it. What else is there to do? Steal it, right? And so, or as they say in London, you can pinch it, right, and so probably the easiest way to do that is through cross-site scripting. This is where you either trick someone into clicking a URL that URL contains JavaScript. They send that JavaScript off to a website that reflects it back, and that person ends up hacking themselves, or you embed it into a website. So imagine this little piece of JavaScript down here, embedded in a website in like a forum or a news group, and then someone, some poor unfortunate soul surfs to it, and suddenly what it will do is it'll pop open a window and contact evil site on port 888 and embed all their cookies. So for example, suppose this JavaScript was embedded in a news forum for Vaporware, the Vaporware Corporation. Anybody viewing that calendar entry that had this would send all their Vaporware cookies, which include the session tracking in many cases. So let's take a look at what that looks like. I'm gonna go ahead and use my little cheat sheet here to bring up my command line, and I'm gonna go ahead and start up everybody's favorite, Netcat. Some people make a good living talking about nothing but Netcat. Hey, Ed. All right, so there we go, we're our evil hacker who apparently has a very sunny disposition because it's a white background. Our evil hacker is listening on port 888 for some poor unsuspecting victim, and who would that victim be? Well, let's go ahead back to our bank and log in. Now we know there's a user on here called Al Gore. So of course there's a user called George W. And how do you spell strategic? Okay, good, all right. So then we'll, we've got a real, you know what I'm already logged in on this other, well, it's supposed to be. It's already logged in, no. So we'll go to a private calendar just for the company where other employees are posting things. So go there, I'll view that calendar, switch to where I know the booby trap is, March, 2002. And I see a little thing says, hi, George. And so that looks enticing. I think I'll click on that. And watch carefully, what was that? I don't know, probably just ignore that. Nothing to see here. What happened was a pop-up appeared, spoke to evil sight, sending our cookies. Evil sight was nice enough to send a little piece of JavaScript that said, dear Mr. Pop-Up window, you can close. You can close and hide all evidence of your existence. Now when I did that recently for customer, I went the extra step and I did a pop-under window. So they didn't see anything. And I was able to show them in a controlled fashion that I was able to take over other accounts. Here's our little happy hacker site. And we see that somebody connected with a browser request, apparently George W is using IE, that makes sense. And look, they sent their cookie. That's their session tracking mechanism for that user. So real time, grab the cookie. So cross-site scripting is most dangerous when it can be embedded into a website. Because all the victims are already authenticated. And in real time, they're live, active, useful session IDs. That's the most dangerous. And then second would be someone being able to reflect it off your site, being of a slightly lesser concern. Okay, wrapping up here with the last two sections. There's unexpected user input. We've all seen this. You can get SQL injection errors and various things like that. I wanna show you one from Big Bank where they were using a cookie to encrypt account numbers. You would type in your account number. They would PGP encrypt it, give you back the cookie. You could store it. When you go back to the website to log in, rather than typing in your very large account number, you would send them automatically the cookie upon surfing there. They would dynamically decrypt it and put the last four digits in the HTML and give you a nice little dropdown box of all your cookies. Of all your account numbers. So if you had like five accounts, you could choose which one of those accounts you wanna log into, just select it, type in your four digit pen and go. Very convenient. There's only a problem though. That data was being passed to PGP. The data that was on your system and being sent to them. Now, you manipulate the cookie and you get an error message about PGP. So for example, if we go to Buggy Bank, here and do a funds transfer. Whoops, I guess I'm not logged in as a legitimate user. It's been tampering. And I define an intercept with web proxy, freeze it, go in here to my cookie. This cookie here and add some garbage like a semicolon. I end up getting a very cryptic little message. Almost, you could almost overlook it, it's so small. PGP, hmm, so you start thinking about it. How are they getting my cookie data to PGP? Well, PGP is an encryption tool that works on a command line and of course, they're probably running it as root, right? It's run everything as root and it always works. And so PGP cookie data, but if I control this, then I control the command line, don't I? Couldn't I put some junk in the cookie and then a semicolon followed by commands? No, that couldn't possibly work and yeah. This was another one where I jumped up out of the chair and was dancing around and then I turned around to the guy and said, sir, you have a problem. Did my little hacker dance, netstat space minus NA. I prefer netstat as my command injection of choice because it runs on both kinds, country and Western. UNIXN, Windows, same syntax. So now I'm running commands on one of the world's largest banks on their application server and you haven't retired yet? No, so. I'm fed up. Yeah, so that was bad news for them. And finally, one last thing I wanna cover real quick is an application flaw, application logic. This is where you try to do a transaction and there's certain steps required, but you do them in the wrong order. Think about this, you wanna transfer money from account A to account B. First, are you authorized to take money out of the account? Always an essential question. Are you authorized to put money into the other account because maybe it's not yours or maybe it's a money market account and you're not allowed to put money into it but only so many times per year. Finally, last, once those first two are answered correctly, you say, do you have enough money? But this credit union software, so this affected lots of credit unions, was doing step C first. So the way that played out was, the way that played out is you could, let me go back here, log in, super secret pin, and do a funds transfer and go ahead and do $5 and intercept it. Ooh, I'm out of time. That's okay. And I'm gonna go ahead and change the from account to someone else's and I'll try to steal $5. And it catches me, you know, your pathetic attempt has been detected. Please assume the fetal position. The Mafia boy maneuver. So whoever that kid was that dropped to the ground when they busted in his door, I'm sure I would have done the same. But now you think about it, what if they're checking the balance first? So instead of $5, I'm gonna do $5 million. And what comes back now is an error message. What's the error message you give someone when they exceed their balance? Why you give them the balance? So I now have the ability to collect balances on any account number. And correct me if I'm wrong, that was for a credit union software, right? Or was that for one bank? I don't, yeah, credit union software, cold state, that's where it started. Okay, yeah, okay, my ex-co-workers are in the back. So yeah, this was a nice little feature. Let me just, let's view this form. Let me grab my cookie. I'm gonna grab my session ID because then what I wanna do is do some more. I wrote a little script just for you guys. That would go through and it would go ahead and just take my current session ID. Notice we're not gonna, yeah, nice. We're not gonna brute force session IDs or anything like this. We're gonna take our session ID and as us, as, yeah, I know, all right. It goes through and iterates through lots and lots of different account numbers, collecting balances along the way. Oh, but don't worry, the website's using SSL so it's protected. I'm hacking in privacy. Thanks, Verisign. All right, so in conclusion, brains and clues are not included. You have to know what you're looking for. Beware of robo-hacking devices. They're only going to crash your backend databases. I assure you of that. And no one tool does it all yet. You're eventually, if you really wanna do the job right, you're gonna have to show me. You're gonna have to show me your Kung Fu with various things I recommend, Pearl and Curl. And then by all means download WebMave and AKA Buggy Bank and go hack yourself, okay? It's a fake app. It allows you to practice legally and safely in the comfort of your own home. And Veris Other Resources are listed. I encourage you to check out the presentation slides by downloading them. One more question and I'm beating the shit out of you. I'm sorry, were there any questions? No time for questions. We had a download. Where's the download? The slides? Defconn.org, right? All the media's there. You're gonna, or our website. One more question and I'm beating the shit out of you. All right, no more questions. And since you asked the question, you can have the speakers. That's the quickest way I can figure out how to do this. So yeah, feel free to visit our website in a passive non-hostile fashion and download the slides from there. Thank you.