 This is Greater Than One and I'm Brendan. So, who am I? I'm just some random hacker from the Midwest. You probably haven't heard of me last year. I gave a talk at Black Hat about hacking Xerox, copiers, printers, multifunction devices. If you didn't see it, you don't know who I am. Why am I doing this? I'm doing this because the financial sector is obviously a very big, very important sector. And in the past, over the past year, they've done this tremendous shift in the way they're authenticating their users and nobody's talking about it. I don't know if no one noticed or if people noticed and just didn't look at it, but no one's talking about this and it's important. What is the goal of this presentation? The goal is, at the end of this, for every person in the audience to say, that's simple, I could have done that. That's my goal. This is simple stuff. We're going to talk about it and I hope you all have the same understanding that I do when we get out of this. And as a disclaimer, I am not targeting anyone. I'm not specifically targeting any sites, any banks or financial institutions or any technology vendors. It's my opinion that they all kind of suck. Some suck more than others, but I don't think anyone's doing it right. All right, so we're going to do some background information. I'm going to discuss control types. We're going to look in depth at three of the main technologies, device fingerprinting, one-time passwords, knowledge-based archives, get that code and demo in, conclusions, which is me just ranting. All right, so who here uses internet banking? Internet bill pay? Checks or pays? A car loan or mortgage? Retirement 401K? Any type of financial services? A lot of you. Obviously a lot of people in America do this. We're not quite up to the penetration rate that you're up or places like Korea and Japan are, but a lot of people use these services and have come to rely on these services. Hopefully you that do internet banking or internet financial transactions are going to recognize some of the things I'm talking about. So to understand why I'm talking about this, we need to understand what's driving the industry. And this is FFIEC, Federal Financial Institution Examination Council. It's a federal governing body that about a year and a half ago came out with a document called authentication in an internet banking environment. This is a regulation that applies to all financial institutions that the FFIEC governs. It's a pretty brief document. You can find it at FFIEC.gov or just Google it. I'm going to talk about one key paragraph, the thesis statement of this document. The agencies consider single factor authentication as the only mechanism to be inadequate for high risk transactions involving access to customer information or the movement of funds to other parties. Account fraud and identity theft are frequently the result of single factor authentication exploitation. That's the conclusion. This is a loaded paragraph. So there's a couple of key points. Number one, access to customer information or movement of funds. That's pretty much every screen in an internet banking application. Other than maybe the help screen, that's every screen that's in there. It's important to note this does not mandate to factor off. It only says single factor isn't good enough. That's where I get the title of my talk greater than one. So banks aren't deploying strict classical model, something you know, something you have, something you are. They're doing what I call one and a half factor. It's a little more than one, but it's not quite two. Why aren't they doing the other two factors? Simple, cost. Hardware tokens are expensive and they're easily lost, stolen or broken. They can go anywhere from 35 to 75 bucks a pop. You multiply that by 100,000 or a million retail users. That's a huge cost for a bank to bear and that's why they're not doing it. Biometrics for the end user, that's out of the question. If my mother got a retinal scanner in the mail and had to hook it up to her computer to log into her online banking, it wouldn't work. So right now biometrics are just out of the question. So these are the control types that you're seeing in the industry right now. You're seeing mutual authentication, device fingerprinting, out of band off, one time passwords and knowledge base archives. So mutual off. This is not what most security people would consider true mutual authentication. This is not device to device authentication. Like in the wireless world where we'd have 8021X with EAPTLS and the wireless client authenticates the server. The server re-authenticates the client. That's not what this is. This is site to user mutual authentication. The site itself is trying to prove to the user you're on the legitimate site. It's safe to enter your password and log in. Device fingerprinting. This is in a couple of ways. Persistent cookies. A cookie with a hash value in it that's stored on the user's PC with a long TTL. Something like 3, 6 or 12 months when the user logs in and they see that cookie. It looks up the hash value and compares it to the username. If it matches your trusted device I've seen you before. They're pulling information from HTTP headers from your browser and they do device interrogation, which we're going to talk about in-depth. Out-of-band auth, but as far as I'm concerned it's not true out-of-band auth. Only delivery of the authentication credential is out of band. Authentication itself still happens in-band. It's still through an HTTP session you're authenticating to a website. Generally it's email delivery, SMS text message to your cell phone or in some cases your phone rings and a little automated voice reads you a pin number. One-time passwords. The most common method is coupled with out-of-band authentication where they generate some sort of dynamic single-use password or pin and they email it to you or they send it to your cell phone. You may see a little bit of static pre-issued one-time pads. It's kind of old school and not a lot of banks are doing it and this is not to be confused with something that's algorithmic like an RSA secure ID token where the password changes every 60 seconds. That's not what we're talking about. Knowledge-based archives. Not very popular but there are a couple banks using them. These are questions based on information gleaned from public records databases. An example may be in 2002 did you buy Ahanda Accord, Toyota Camry, Ford Taurus, none of the above. The important thing to understand when we're talking about these control types is the difference between bolt-on versus built-in. These are not built-in to the application themselves by the application developers. These are third-party products that are somehow integrated or bolted to the front of an existing application and they try and get it to integrate to become a single authentication process. There's a couple of problems with this. You get increased attack surface by adding additional code that can be accessed unauthenticated. Standard authentication process has to be interrupted for this to work which we're going to illustrate and we can exploit the architectural weaknesses of trying to bolt one system onto another. Simple request response authentication if you're not familiar with this, you're in the wrong talk. We have the client, a web server and a database at its most simple. You post your username and password through a login form at its most basic, a select query against the database, select username and password to see if the username and password are accurate. Database response with a 1 or a 0, yes or no and if you fail, the web server gives you a generic error message invalid username or password. Now this is important because security people for years have been trying to beat it into the heads of developers. Don't just say invalid username or invalid password. Give a generic error message no matter what they fail. And we finally got that covered. They finally listened and now all these applications have generic error messages. Invalid username or password. So device fingerprinting, the most common deployment of this is a hybrid approach. It uses picture and passphrase based mutual auth where you have a security image and a security word or security phrase that the bank is going to display to you to prove that they are the real bank and it's safe to enter your password. One-time passwords or challenge questions are very common if you fail. If we do not recognize your device before I give you that picture to prove that you're on the real site and let you enter your password, I need to fingerprint or I'm sorry, I need you to answer some challenge questions or I'm going to send you a one-time password via email and you've got to type it in. So after this, persistent cookies are set so that we recognize your device again in the future and you can bypass the challenge questions or the OTP. So we're going to do some request analysis and you can see this in single server or multiple server deployments. What I mean by that is sometimes it's integrated as a single host name, login.xyzbank.com. In other cases, they actually have a different host name sub from the domain, maybe login.bank.com and newsecurity.bank.com. So this is what the authentication model now looks like. You can see our existing authentication infrastructure at the bottom and on top of it is the new system and this holds true whether it's different physical servers at different host names or just logically separated, this request flow is still accurate. So we have our standard enter the username and the first thing that the old system has to do is redirect you. It has to push off to the new system because we've bolted it onto the front. So now you're talking to the new system and it needs to know if you're a valid user. So it has to go look in the old database to make sure that you're a valid user of the existing system. This is important because it needs to know if you're valid to give you challenge questions and then if you've just registered it takes you through a one-time registration process to get registered on the new system. I'm not going to talk about that. I could give a whole talk on weaknesses in the registration system. If you're interested, see me after. Yes, he's a valid user. Now we've got to see if you match our authentication criteria. Do you have your persistent cookie? Do you match that device fingerprint? Now we've got to look in my new database that handles this. The database is going to respond and say no, you're not matching my authentication criteria. I need to prompt you for challenge questions or I need you to enter a one-time password. So now the user answers the challenge question. You enter the one-time password and looks up in the database. Is that the correct answer for that user? Is that the correct dynamic OTP that we generated? So if it responds success, now we go back to the original authentication process. Now at this point the user can actually enter their password and resume what used to be a very simple authentication process. And I do want to say I'm horrible at Visio and PowerPoint so this little slide here took me like 60 minutes so I hope you all appreciate it. So we resume authentication and the user is finally logged in. So quick overview. Post username and the cookie if a persistent cookie exists. We're going to analyze the device fingerprint. New authentication challenge. Answer the challenge. Go to the old login. So one question I want you guys to think about is in systems where they're actually using two separate servers with two separate host names, how are two different servers with different SSL sessions keeping state? Your client has a unique SSL tunnel and a unique SSL connection to server B and somehow these servers need to know what state they're in so you don't go straight to the password or you haven't entered or passed the authentication process so it's time for me to redirect you to server B in the new system. We're going to analyze the post body, see what they're trying to do and how they're doing it and dissect some parameters and values. I had to black all this out for two reasons. As I said I'm not targeting anyone in particular and I trust no one in this room who I bank with. I'm blacking out the header to see what site I'm actually looking at. Down here at the bottom, the second phase within the request body itself, that's some site specific stuff. Text user ID, that's my valid login name. These are my real credentials. I'm not giving them to you. The really interesting stuff that was down here at the bottom, do you see these parameters that start with FP? We have FP browser, FP screen, FP software, FP time zone, language and then this one really big parameter called PMFP. Notice that all these little FP ones, the five ones ahead of it are not populated but down here in this PMFP parameter we have a really, really long string. I'm going to show it to you bigger on another slide in a second. What they're doing is, instead of individually populating all these parameters they're just concatenating it into one big string and passing it all as one big long value to a single parameter. This is another bank that's using the same system and does it the other way. They're all doing the same thing, just variations on a theme. You can see at the bottom here they are individually populating their parameters, their FP browser, their FP screen, their FP software. Here it is bigger. You can see what it is that they're actually doing. This is the first bank that concatenated string with these individual parameters. FP UA, what do you think that stands for? That looks like a user agent to me. Looks like they're fingerprinting it. FPSC, and you've got these numbers, 1024, 768, 32. That's my screen size. FPSW, we see PDF, we see SWF, we see QT. What is that? The SW probably stands for software. This isn't hard. TZ minus 4. That's my time zone. Greenwich, meantime, minus 4. FPLN, lying equals ENUS. That probably stands for language. This is not hard stuff to figure out. Here's the second site where they're putting it into individual parameters. They're doing the exact same thing, app name, Microsoft Internet Explorer. Here they're using CPU class, X86, platform Win32, app version, again, user agent. I took out some of the UA stuff because you saw it on the last slide. And then down here they actually spell it out. Plugins, Adobe Acrobat plugin, Quicktime plugin, Windows Media Player plugin. They're using all these individual values to create a fingerprint that's supposed to be unique to my computer, to know what my user agent is, my platform, my CPU type, all the plugins that I have installed in my browser will support. We'll get to that. The application is trying to gather information specific to your device to form a fingerprint. Now when I say fingerprint, you should all be thinking unique. My physical fingerprints are different than his, different than his, different than his. Well, computers can have the same fingerprints. Two different systems can match the exact same fingerprint. So the basic premise of fingerprinting fails because they are not unique to a device. Multiple devices can have the same fingerprint. Furthermore, when we look at all the parameters that are in there, there's a whole lot of data and a whole lot of possible values. So objectively we have a mathematically large possible data set. But in all probability, when we look at it subjectively, we have a very small possible data set. Let me guess, you're running Windows XP, you're using Windows 4, your screen resolution is 1024 by 768 or 800 by 600. You have an x86 CPU. You don't have to be the great Carnac to figure out what most users are going to run. In addition, most users, they buy off the shelf hardware. They buy a Dell. They buy an IBM. They buy an HP. These come with OSes preloaded and software pre-configured. They're going to be a very small set of fingerprints that a very large set of computers are going to match just out of the box. So how are they gathering this device? How is this device information? How is their web server interrogating your device? It can't just reach through the tubes and feel around and figure out what your computer config is. They're using JavaScript. Client-side JavaScript is the preferred method of most security developers. Unfortunately, that's a joke, guys. Client-side JavaScript bad for security. Well, JavaScript comes down with the HTML in clear text. Reverse engineering isn't hard when the source code is sitting in front of you in clear text. This is JavaScript from a very, very large bank that comes down and they use for authentication. Complete with developer comments. This function captures the user agent string, fingerprint browser. I wonder what that does. This function captures the client's screen information, function fingerprint display. I wonder what that does. This isn't hard. They're telling you exactly what they're doing and exactly how they're doing it, and then they're commenting the code for you. So what happens if we fail? What happens if we fail device fingerprinting? We're coming from a different machine or we just got a new machine and it's been altered enough that our fingerprint doesn't match? Well, they may hit you with challenge questions or they may prompt you for a one-time password. Now, the one-time password is going to be delivered out of band, most likely via your cell phone, but the session ID is not enforced. I'm not going to say always because I haven't looked at every single bank in existence, but I'm going to say usually as a general rule, they don't enforce session ID. So the session ID of the client and their browser that requested the one-time password to be sent does not need to be the same as the session ID of the client or browser, even the same IP as the machine that actually completes the authentication process. These one-time passwords are being generated. They generally have long TTLs or they just persist until consumed. So you can generate a one-time password, close your browser, go to work the next day, enter it and complete the authentication process. They're not enforcing that it's from the same session ID or even the same IP. Successful authentication. When we succeed, we enter our one-time password or we answer our challenge question. We're going to get our picture and passphrase for mutual authentication and the persistent cookie is set. It's going to ask us there's usually a little radio button or using a private computer, public computer. If you select private, it's going to set that persistent cookie so they get a hash of your fingerprint and the next time they recognize you and you don't get the challenge question. So let's attack this. Hopefully you guys are already seeing big weaknesses in the system. We can fuzz the fingerprinting parameters. We can determine failure thresholds. Some banks, like the first one we looked at, they're concatenating everything into a single string and they want it to match exactly. Other ones, like the second set of requests that we looked at, they have a whole bunch of different parameters and there's a little bit of wiggle room. Maybe if you upgrade from IE6 to IE7, we'll let you in. Maybe if your time zone changes, you may be traveling, we'll let you in. This is site-specific IP address. In some cases, if your IP matches, you can always bypass. In other cases, they may heavily weight IP. If we haven't seen you coming from this provider again, this is very easy to figure out on a site-by-side basis just by using a few proxies, seeing how they're doing it. The challenge questions. This is important. There is a total lack of randomization in challenge questions. It's totally cyclical. Question one, question two, question three. One, two, three. And in fact, you're going to continue to be prompted for question one until it's been answered. So get challenge question one. Don't answer it. Come back in a year. It's going to prompt you for challenge and there is no randomization. Question one is your question until it's been answered. When you answer question three, it goes back to question one. Sorry, I had a point there at the bottom. This makes it trivial to enumerate valid usernames. Now some of the banks have actually recognized this piece since I submitted this talk. Some are still doing it. If you enter an invalid username, like no such user, you won't get a challenge question. You may just get a generic message. If you enter a valid username, you'll get a challenge question. So now it's trivial to enumerate who valid users of the system are and who they are. The banks that have started to fix it and say, well, you know what, we need some dummy challenge questions. So even if they guess the wrong username, we'll give them that. There's a very simple timing attack. I don't know if you guys heard the hacking my space talk or Haroon and Marco from sense post their timing attack talk. They're both good. Check them out. This is nothing else. If you remember that earlier slide where I had that arrow moving around everywhere, the first thing it does is determine if you're a valid user. If you're an invalid user, it's immediately going to give you some fake challenge questions. If you are a valid user, it's going to take longer. You don't even need a script to measure this. You can usually measure it just by watching. There is a noticeable difference. It is trivial to enumerate valid usernames on these systems. So multiple servers and redirects. We're talking about the multiple server session where we have two SSL tunnels to two different servers, server A and server B. They're keeping state through the client. You are the client. So if two different servers are keeping session state through my computer, do you think we can mess with session state? Probably. Systems that use a single session, it's still possible to cause out of state session errors or mess with the session state to achieve a desired effect such as forcing one-time passwords to be sent, maybe again and again and again and again, or even if the user's device fingerprint matches, force and challenge questions to show. So no matter what the system is, we have some wiggle room where we can play with session state and cause some undesired behavior within the application. Mutual authentication, once it's all said and done, you've answered your challenge questions, you've entered your OTP, I trust you now I'm going to let you enter your password. But before I do, I'm going to pass phrase which you have picked out to prove to you that on the real banking website it's now safe to enter your password, you're not on a phishing site. So they're using the picture as a security credential. The bank uses that picture as a credential to you, the user, to show you that you can trust us we're true, you're not on a phishing website. So they have to protect that somehow. It would be bad if my credentials just linked to slash images slash Brendan.jpg. I could statically link to that. So they're trying to obfuscate it. Two methods, dynamically generated GUIDs which are only valid within that session, or they're using a stream cipher to encrypt the request. So how can we defeat this? It's actually pretty simple. First, possible method, if cracking WPA has taught us anything, it's that given enough time and enough requests, we will find collisions and IV numbers and we can break systems that are using stream ciphers. But I don't like that. It takes way too long. We're not doing that. Man in the middle on the fly replacement. Yeah, that would work. We can just flat out man in the middle of them. But once we deliver the image, we don't know what that image was because generally we're going to have a script that's delivering the image. I as an attacker want to know what that image is and how it pertains or how it correlates to a specific user ID. I don't want to just man in the middle of it on the fly once. I want to know it. So here's the solution. They're using clear text alt tags. So they're wrapping all this encryption or these dynamically created GUIDs around the get request to the image. But right there in clear text on the page is a little alt tag. This alt tag is a uniquely indexed database value tied to a specific image. They all use a shared catalog. Every bank that uses this system has the exact same pictures in their catalog with the exact same alt tags. We don't even need to come up with it. They're indexing it for us and then giving it to us in clear text. Let that sink in. Alt banks using this system use the same catalog with the same index values on their alt tags. So the little choo-choo train that says science and technology number 1, 2, 3, 4, 5 on bank A is the same picture on bank B, C, D all the way to Z. They're all the same. So having access to any one app allows you to suck down their image catalog because you can change your security image if you don't like it. A hundred bucks will allow you to open a checking account and you can probably get free online backing or free internet bill pay out of it. Drop a hundred bucks, log in with your valid credentials, a little shell script and some WGET, suck down the entire image catalog, complete with indexed alt tags. Now you know you have the exact same database locally, what every single bank has on their website. We have no need to attack the dynamic linking function because we have a clear text alt tag and we have our own local image repository. Yes, they're static. In my experience, yes. You do a static request for a certain JPEG and it's always the same size. I got a lot to cover. I will be around for Q&A if we can just hold the questions or... Right. We're going to get to that in the demo so please hold the questions. I don't mean to be rude and I'll answer all your questions afterwards. Again, if we go back to the FFI EC document, this is designed to combat phishing, transaction fraud, and identity theft. That's the stated purpose, that's why all these banks are spending all this money and all this effort in implementing these systems. So how does it measure up to the stated purpose? Well, phishing is targeted at a specific organization. The attacker can simply copy the code from the JavaScript within the fingerprint from the target site. That's what I did. I flat out plagiarized their JavaScript and threw it in a phony authentication form. It's clear text. You have the source, it's documented. Just grab it. Just get grab it and put it on your page. There's not a lot of thinking to it. As long as the username is correct, failing a device fingerprint will present us with challenge questions. And I talked about how they're not random. It's always challenge question one. So the attacker can prompt a user for the answer to the challenge question and then just do a simple redirect to the real site. If the user has persistent cookie already set, as many probably do, they'll bypass the challenge question completely. And that challenge question and the answer that you the attacker have is valid until you decide to use it. So you don't have to even use it right away. You can go back and use it in a day or a week or an hour. Spear phishing. This is now easier than ever. Does everyone know what I mean by spear phishing? Spear phishing is when you target an individual user or individual set of users, you're not just mailing your phishing attempt to absolutely everybody that's in some spammer's database. So because valid account names can be enumerated, we can put a little bit of thinking. So if your username is cubsfan266, what do you want to guess that your email address is maybe cubsfan266 at aol.com or hotmail.com or yahoo.com. And because we can brute force, and not even brute force, more like intelligently guess device fingerprints, we can get the security picture and the security phrase for this user and send them an email. So if you get an email that's addressed to you that looks like it's from your bank and it has your bank's authentication credentials which are the image unique to you and that passphrase unique to you, you have a much greater likelihood of actually falling for this targeted phishing attack. I would guess that your average user would probably click the link or probably enter their information. If it looked like it was from their bank and it had that supposedly secret picture and passphrase that only the bank's supposed to know. This does absolutely nothing to stop fraud. Absolutely nothing. All transaction fraud takes place once you're in the system. We have the inheritance trust model within web applications. Once you're authenticated your session ID on the server side is marked authenticated. This is how web apps work. This is why you can go from page to page to page without getting prompted for a password. It's just the way they work. Once you're authenticated, all your transactions are suddenly valid. This does not stop transaction fraud in any way, shape or form. Identity theft. Does it stop identity theft? Most of these systems are doing data masking where they're starring out the account number. So even if Mr. Batataker does somehow break our impenetrable security system and they can actually see the screens within the application we're going to go ahead and start out those account numbers just so they can't get that user's information. Who has a checking account with online banking? There's this little thing that came out a few years ago. It's called Check Images where checks that you've entered are shown in your transaction history and you can actually click them and get a little PNG or a PDF that shows the front and back of your check. Well, what's on a check? Your account number, your ABA routing transit number, your full name, maybe your wife or husband's name, your full address, your signature, maybe your phone number and social security number if you're really stupid. As an attacker or identity thief, you can mask that account number all you want. Start the whole thing out because one click away is a lot more information that's going to facilitate identity theft. You're doing absolutely nothing to stop me. If you don't have a checking account, maybe it's just a savings account or it's a brokerage account or you pay your mortgage online. Credit cards, all of these companies have e-statements where you can print out an electronic copy of the statement that you get in the mail every month which has your full account number, your full legal name, your street address, tax forms, deducting interest payments on a mortgage maybe or a 1099 from your savings account or from your online brokerage account. The IRS isn't taking a tax form with the start out account number. No, you print out the tax forms online and there you have your full name, your full account number, street address, and possibly social security number. They can mask it on the summary page all they want. One or two clicks away more information, better information to facilitate identity theft. One time passwords. How am I doing on time? Oh, I've got to hurry up. We covered some of this already. Only delivery is out of band, hardware and soft tokens. If the app isn't enforcing all phases within a single session, we talked about the same issues apply. Longer non-existent TTLs, they may be valid for hours, days, weeks, or just valid until consumed. OTPs are only most effective when required for every login, so the user is always entering the OTP and always overriding that last database entry. Otherwise, I don't think that they're effective at all. The same weaknesses apply. They can be met in the middle. Very simple. You get the user to give you the one time password and you proxy it over to the real server. You get your persistent cookie set. Now all of a sudden you can bypass that new authentication system. Email or SMS delivery sets a pattern for the user. This is important. Anyone that works in security over the past 10 years, we've been trying to beat it over the heads of our users. Don't just click links and emails. If you get an email from your bank, or it looks like it's from your bank, and says you need to go login and enter some information to validate your account, don't do it. So not only are the bank's users to do this, they're requiring it. If you use one time passwords via email, you have broken what security people have been trying to teach users for years. And you're not just enforcing the bad habit, you are requiring it. They cannot login unless they do this. Cross site request forgery is possible. I'm going to skip a little bit of that, but basically with a phishing site, we can use XSRF and generate a whole lot of these one time passwords. So OTPs, how do they measure up? Slightly better than fingerprinting because it's a little more difficult to be transparent. You can't just forge a device fingerprint or do the challenge question. You need the user to stop, check their email, check their cell phone and enter it. It trains the user to trust email more. This is bad. Please stop doing it. If anyone here works for a bank, stop it. You're not helping. We're training them to click those links, and we're training them that using email for security purposes is okay. This does absolutely nothing to stop fraud or identity theft, just like we talked about. The inheritance trust model still applies once you're authenticated. Same thing. You're not doing anything. You're not helping the problem with the stated purpose of phishing, identity theft, and transaction fraud. Knowledge based archives. They're not nearly as common. I have seen a couple, so I'll talk about them real quick. They're usually used in conjunction with persistent cookies. Almost all these sites are using the pinky hash value model. By definition, public records are used, and there's always a skip this question option. Because they're getting all this information from public records, it may be something pretty obscure that you don't know the answer to, like what was the purchase price of the home you bought in 1982? Well, I don't know, and I don't want to go dig through old sales records to figure it out, so we have this handy little skip this question, I want another one. In this case, randomization, and they totally works in our favor, and hopefully you can already figure out why. Multiple requests for multiple sessions, and basic pattern analysis. Here's our challenge question example. In 2002, did you buy Honda Accord, Toyota Camry Ford, Taurus, or none of the above? I'm going to close the browser or skip that question, or come back in a day, and just keep skipping until I get the same question again. Now it's in 2002, did you buy a Nissan Sentra, a Chevy Cavalier, a Ford Taurus, or none of the above? I know this. Randomization works in our favor. This is basic stuff, guys. If possible, this is actually less effective than stupid challenge questions. It can be defeated through response analysis with pretty much zero prior knowledge, other than guessing a valid username. Same shortcomings as other solutions. Just like I said, we're not stopping fishing. We are not stopping identity theft. We are not stopping transaction fraud. In most cases, this may make identity theft easier because you're getting more personal information about the user, like maybe the purchase price of their house, or the house they bought, or the type of car they drive, all these things from public records. They're giving it to you as a challenge question, an attacker that's after identity theft, this is actually facilitating them, not hindering them. Is there a better way? There has to be. Mutual authentication. Responses must always be given. A lot of the banks are starting to do this now, but some are still not doing it. If you enter an invalid username, you get a generic error message versus a challenge question. Same responses must always be given for the same authentication criteria. Don't allow the attacker to try multiple times through multiple sessions over the course of a couple days, and do some kind of response analysis to figure out what's true and what's not. Authentication should be algorithmic. That's kind of a big one. If you want to know more about what I did by that, come see me after. Challenge questions. This is still single factor, people. You're replacing something the user knows with two things the user knows. It's still single factor. And this is flawed by design. Users can pick simple questions with very simple answers. If everyone remembers a couple years ago the big Paris Hilton, her T-Mobile sidekick was hacked, well, all they did was guess her username and her challenge question was, what's the name of your dog? It's on Google. About a week later, Fred Durst from Limp Biscuit got hacked. His challenge question was, what's your favorite band? The band he sings for. Users will pick stupid questions and they will give them stupid answers. And in some cases, if your name is CubsFan266 and you pick the challenge question, what's your favorite city? Maybe it's Chicago. NYC Gal123. Where did you go to high school? I'm going to guess New York City maybe. So based on just user names and the fact that users are stupid, we're not helping anything. We're just making the problem worse. Device fingerprinting. Current implementations can be bypassed or replicated with ease and I'm going to show that in my demo. Guys, this is client-side JavaScript that posts. It's not hard stuff. Replacing something that the user knows with something the computer knows, still factor and you have no guarantee that the computer is going to tell the truth. You're asking it to give you an answer and it may give you a valid answer or it may not. For giving thresholds on device fingerprinting and these persistent cookies, they aren't buying us anything. So hopefully you guys have been thinking about it and I haven't mentioned it yet. What about bots and trojans? If your box is owned, will any of this make any difference? No. We'll grab you, we'll use a keystroke logger to get you forward. We'll grab your persistent cookie. We'll grab your device fingerprint. You cannot stop us. Luckily for us and the security community at large, bots aren't a problem anymore. They went away. The current bot numbers are at zero. They all found Jesus. They prayed for forgiveness. They have stopped writing malcode. No. Anyone that was at Internet Wars yesterday will know. The problem's worse than ever and it doesn't look like it's getting better anytime soon. Bots are still a problem. People are still doing this and this does absolutely nothing to stop someone that may be Trojan or have a bot. Stop fingerprinting devices. Start fingerprinting behaviors. Behaviors are far more unique than Dell, IBM, HP, their standard off the line models. There's a finite subset of potentially likely answers to a device fingerprint. So stop fingerprinting devices. Plus the device can lie. I as an attacker can forge your fingerprint. There's no guarantee here. Start looking at how the users are actually using your application once they're authenticated. True transaction based behavior analysis and anomaly detection. If you always pay between $50 and $100 a month for your gas bill and suddenly you're paying $3,000, throw a flag that's outside normal usage. Or normally all you do is transfer money from checking to savings or savings to checking. Now you want to do a wire transfer internationally. That is outside your usage pattern. Throw a flag, prevent the transaction, make the customer talk to a human or go into a branch before you validate that and let it through. HTTP header information does not equal behavior analysis. There is a very large security vendor that will say this. They say they do behavior analysis. All they're doing is looking at your HTTP headers. No, not behavior analysis. Hurdles for secure implementation. As altruistic as some of this sounds I am not naive. This is not going to be easy. The sheer volume of data, the number of customers, the amount of transactions, it is going to take some time and effort to create real behavior fingerprints. I'm not under any illusions that we can solve this problem tomorrow. Exactly. Bolt-on versus built-in, this needs to be built into the application itself. Stop buying third-party products to fix the problem that your current code sucks. Get the people that wrote the code, put pressure on the vendor, fix it in the application. Stop trying to put band-aids out in front. Use a positive authentication model. New transactions should require stronger auth. Some sort of intervention, whether it's with a human or a token or going into a branch. If you're going to set up a whole bunch of new bill pays or set up a new wire transfer, new transactions should have a positive authentication model. Don't just say your session ID is valid therefore all transactions are trusted. Use hash values to transactions to prevent tampering. I'd like to talk about this a little more, but I'm really low on time. There are specific Trojans and BHOs that specifically target certain institutions. Go out to Sark or train Micro or Sophos. Type in a bank name and search through their database. People are doing this. They're writing mail code specific to specific banks, and they have a sit-in-wait approach to let you log in, wait till you do a transaction, change it on the fly. Force the user to review and verify their login events and transactions. At best, the bank may have, when you log in, your last login time was this. Your last login date was this. No, print it out. Show them all the login events. Show them all the transactions that took place under their credentials. Send it to them in the mail with their statement or show it online. Somehow let the user know how their account is being used. If it's being abused you don't necessarily know that. Hardware tokens have a good record of security. We talked about how it's commercially unfeasible, but dear Lord, please let the user opt in. If my bank would give me a token and all I had to do was pay 50 bucks, I do it. Maybe share the cost with the customer, but come on. Hardware tokens are good. They have a pretty good track record. Let's use them. If the bank doesn't want to foot the bill for the cost, let the user opt in. Okay. Demo and code. We still have time. This is dcbank.htm Simple HTML form. I just took out any company specific information. I flat out plagiarize this off the target bank. Go to their login page, view source, copy and paste. There's your web page. You can see where the blinking cursor is. Action equals. I'm posting to my POC code. It's poc.cgi just to show that I am submitting to the form I created. Down here you see all these script includes. Again, I flat out plagiarize their JavaScript and use copy and paste to the form I created. This includes I'm running their scripts on my fishing website. Nothing new. Didn't doctor the code at all. Just copy and paste their source. Here's the code. It is a pearl hack job. I am using HTTP cookies and LWP. Most of you programmers may notice I am not using strict. I am not using taint. I am not validating my input. I am not blessing my object references. If you use this code anywhere outside of a test lab, you will be owned. Right here at the top, on line 6, target URL. That's the bank I am targeting. I am creating a cookie jar for persistent cookies and putting it to a file if you want it to be temporary or on the fly. Uncomment line 15 where I create a session based cookie jar. I have a debug file that is printing requests and responses from both the fished client and the real server if you want to go through and look at it. First thing we do, print content type HTML. We are doing 200 okay. We are going to do a request method. I was going to do a get, but I didn't have the time. I am doing a post. I am reading environmental variable content length bytes from the input and just throwing it in a variable called input. Victim IP. I am storing that as, again, just querying the environmental variable for the remote header to get the victim's IP. Then I create a little hash here called victim header. You can see all I am doing is loading up my hash with just by visiting my page. HCTP accept, accept language, user agent, encoding, character set, CPU and HCTP connection. Anyone that has ever looked at an HCTP request knows what I am talking about. This little piece down here on line 48 site specific, they are looking for test JavaScript equals okay as part of their form. If I don't have it, I am concatenating it on to the end to make my request look valid. Then I create a variable called victim fp. That is my victim's fingerprint and again input. I am just reading content length bytes straight out of the request and throwing it in a variable. No validation, just bucket brigade. Grab it over here, hand it off over there. Then I call my login subroutine and I am passing my login subroutine my victim header hash and my victim fp. Here is the login subroutine. I am creating a browser agent and I am loading up the user agent with whatever was in the environmental variable that the user was using. 75 and 76 you can use a proxy. I have tested this through a proxy if you don't want it traced. Just uncomment those lines it works. Then we create a new request. We are using the post verb to target URL. Here we are again just loading up our request headers with what we are getting from the victim. We are just grabbing it over here, placing it in the bucket over here. We are spoofing the refer on line 87 and putting in content type and then down here our request is the victim fp, the victim fingerprint. We are not even really touching it. We are just grabbing it off the login form which we stole from the target site and just passing it to them again. Then we get the response from the browser request printing to the debug file, the code, the message, the header and then we parse the content. Let me go down to that. Here is the parse content subroutine. I basically throw the content to the page in an array and trim off the first top of it and then we are done. View state, that is a variable that I had to use for the specific site I am targeting. They use an ASP.net application with view state. Most of you who code ASP.net know what I am talking about. I just need to capture it and use it depending on what phase I am in just to stay in sync and in state with the server. I create a variable called pass and mark it to zero. We haven't passed anything yet. I parse it and I grab the message. If we see within the page complete login, that means we have completed device fingerprinting and we are ready to fish the user for the password so I mark pass equals one. Else if your security question, that means we did not pass they are going to prompt me for a security question so I need to grab that security question so I can give it to the user and man in the middle of them. If pass equals one, we are basically grabbing again with some simple reg X, the alt tag because that alt tag is going to have a one to one correspondence with my local image repository on my evil server. First part of the routine, if caption and if alt. Again, simple if statement, if we did return a caption and an alt tag, we know we succeeded. We are printing out some HTML that I threw together, printing it to the socket and we have our security phrase and our image based on the alt tag and hopefully you can see it like they are on line 133 image source equals alt variable.jpeg, simple. Here at the bottom, just to prove in the demo that I am doing this and not lying, I am printing out in the bottom is debug info, the contents of my victim header hash as well as splitting my input on ampersands. Again, I am just splitting on ampersands, I am not validating my input so don't use this code anywhere other than a password. Down here, just in case we fail, if we get returned the security question in our view state, we know we failed finger printing and we have to man in the middle of that password. Down here I am doing the same thing, I am just grabbing the variable for the challenge question, throwing it up on the page and debugging my state at the bottom what my victim header is and what my input values are. Simple, it is a 250 line Perl hack job, you can do it in about 100 lines but now let's actually see it. So here is Defcon Bank, this is my page I put together, I am going to do a quick view source to show you it is the same source code. There it is, posting to my form, poc.cgi right up there at the top. Again, totally plagiarized from the target site, I did very little effort on this. Down here at the bottom you can see, let me pause that, so this is the first site we looked at and they have within the code all these individual variables for browser and screen and things like that, but they are not using it, they are concatenating them all into a single value and passing it as part of a single parameter. Can you guys see that? No? Wow, that is a lot better. I hate Windows Media Player. Come see me, I will give it to you. So that is our HTML source, I am going to show you my cookies just to show that I am poofing this in any way. My cookies are clear on Firefox. So I am going to enter my user name and I am posting to my cgi that is attacking my target site, man in the middle. It is going to hang for a bit because remember I have to wait for the target server to fully respond before I can respond to the user and there is my security phrase and image, I have changed this so guys don't try and hack me please. So my security phrase is based on the alt tag that I have and then it is now time for me to enter my password. I have phished the user, I am showing those security credentials that picture in that phrase that proves you are on the real site and then let's look at the debug information so you see what I am doing. So there is my user agent string again, I am just dumping the contents of that hash called victim header and then down here this is everything that was in input that was passed as part of the post content and there is my user agent keep on scrolling just like we saw on the earlier slides there is the parameter p m f f p s c, there is my screen resolution, f p s w, there is all my software extensions f p l n, there is my language, just grabbing it off the login form. So now it is safe for me to enter my password and the user is compromised. Now I am going to use user agent switcher and switch to opera. So I just use user agent switcher, I am sure you have all seen it in Firefox, great little utility. I am now impersonating an opera 8.5 browser and we are going to run it again so that we can forcibly fail device fingerprinting. Enter my user name we failed so it is the challenge question I need to answer who is the name of the best man at my wedding, you can see in the header it is opera 8.5 one now instead of Firefox, you can see it down there in the content that it is passing opera as part of the fingerprint so I can answer any question. Voila there it is, simple. There it is, I am using opera my browser says opera within the header, it says opera within the fingerprint that I am passing it is trivial to impersonate or bypass these things with very little coding skill anything other than view source on their actual login form, copying down the JavaScript includes and throwing up a phishing site. This does not stop phishing at all. One minute crap. Conclusions, why did I do this? I did this because as I said earlier, no one is looking at this stuff and it is basic it is easy to impersonate hack or walk right by and this is supposedly what is protecting all the financial institutions in the United States of America guys this is crap. Traditional attack vectors, they are still a threat. This does nothing to address any other vulnerability types. This does not address cross-site scripting, it does not address any other type of command injection attacks, buffer overflows. This does nothing to help the problems that we already have in these applications. If XSS exists on a site, now it is worse than ever because the best an attacker used to be able to hope for was grabbing the session cookie and being able to piggyback on that victim's session. Now we grab the persistent cookie and we don't even need to worry about device fingerprinting. So now XSS if it wasn't scary enough now it is worse. Browser based vulnerabilities are still a problem. They are still vulnerabilities in Safari, Firefox and IE. That is still a problem on the client side. This doesn't address that either. We are putting controls in the wrong place. We are just layering more attack surface out front prior to authentication. We are not addressing the real problem which is once attackers get in and they will get in they are doing bad things. Financial industry problems. If a customer loses their checkbook or credit card in the real world the bank picks up the tab even if it is due to negligence. If you take out your credit card and throw it on the street and someone uses it for fraud you are covered. Online the issue isn't settled. I am done. Okay I am done. I will be in Q&A room 1. I can finish up the presentation or continue talking or answer any questions you have any accusations you want to see the code or the demo closer up. Please come see me. Thank you all very much.