 Hi, everyone. Thanks for coming. Today with Baptiste, I'm going to present you Bad Memory. For those who wonder, Gustave is not here today. He has visa issues, so he's stuck in Stockholm. So Bad Memory is a talk a little bit different from what you might have seen before. We tried to give you something which is out of the box thinking, and we're going to show you a lot of cool attacks, and we have made a lot of video for you because usually the god of demo are against me, so now I'm doing video. They are on YouTube, so if you want to watch a video afterwards, you can just browse the channel and you have them. So usually, and you're all there for security, there is three ways we can know and know how to break a security mechanism. The first one is when you find a design flow, for instance, web is broken by design. You all know that, and you also have the most well-known way, which is we try to find exploit and find vulnerability into the code, this implementation. And the third one which would be the focus of this talk is how you can try to make this security mechanism a little bit irrelevant. Closer. Okay, sorry. So what do we mean by irrelevant? For a second, bear with me, let's assume you have this nice house in Wonderland, and of course you like your house, so you're going to prevent people to try to break through it. The way you do that is you have a nice security mechanism, which is a door. So the bigger the door, the more secure you are, but the clever attacker might try to do what we call side channel, and that would be the focus of this talk is try to break through the windows or try to break through the roof, right? So that's what we call side channel. Now what we're going to tell you is not about Wonderland, it's about real security. So what we have is four different stories in this talk. So the first one would be how you can actually break into a WPA network from a web page. The second one would be how you can attack HTTPS with cache injection. The third one would be how you can steal private data with what we call framework attack. And the third one would be how to attack this guy, smartphone, with something which is a new generation of click jacking. So, well, I hope we will be as loud as this guy. So, over the year, we see something which is really good. We see people moving away from web, or at least they should, from something which is more secure, which is WPA, right? And so the world is more secure, and even at the DEF CON this year, we have a secure network, so the world ship is kind of empty now. But still something remain. We are still storing the WPA key to a web interface. And our idea was, well, maybe we can't break WPA because we don't really know how to do that right now, but we probably can try to attack this web interface. And to confirm that, we went to a store and buy a huge bunch of routers from different brands, eight of them, and try to our hypothesis. And the result, that we're able to break all of this brand, and actually retrieve the WPA key. What I'm going to show you now is how we do that. So, the basic idea of this attack is we are able to execute a malicious JavaScript inside the local network because the user is browsing the web. It's not an unreasonable assumption. First reason is because a lot of websites have access to vulnerability. Go to access these websites, if you not trust me, there is a ton of them, but also because you can serve ads. And actually ads contain malicious code. It's well-known. For instance, at the beginning of this year, Avaaz released a study which shows that a lot of ad advertisement networks did a very bad job at sanitizing the advertisement. And as a result, there is a lot of malware which are distributed via a network. In case you wonder how much it costs, if you want to have 100,000 it's about 100 dollars. So it's a really cost-effective attack. How many of you are familiar with what we call the browser same origin policy? Raise your hand. Not that much people. Okay. So just make sure everyone is on the page and we'll follow what we're going to explain. The same origin policy is one of the key security mechanisms you have in the browser. It's basically meant to protect you when you are browsing multiple websites at the same time because you have multiple tabs or you have one iframe inside your page. The basic idea is the following. If you have two origin in the screen, you have evill.com and you have mail. Google.com. The same origin policy do something very simple, which is one origin can post data. It doesn't mean that the other origin has to process them, but you can post data from one origin to another. That's how web service can interact together. But you are notable from one origin to read the other one, which effectively prevents a bad guy to read your Gmail or malicious page to read your bank account. That's the same origin policy. So we can post data provided there is no CSR defense, but we can't actually read data. And you will see that it actually makes this attack a little bit hard and that's the major error we had to work around. Okay. So back to the attack. The attack requests follow. At the beginning, the attacker will pay ads or file an excess in the website and will be able to inject a malicious JavaScript inside the local network. At this point, you have to realize that the firewall is completely useless. There is no firewall because you are already inside the network. Similarly, you might say, hey, the router interface is only available from inside the network. Well, that's not an issue because we are already inside so we can access from the browser of the user the web interface. So the first thing we have to do, the first thing that this malicious ad has to do is to locate the IP of the router because we have no clue of that. A good way to do that is to look at the RFC and try all the probable IP. We do that by using such a request which is asynchronous request. And we try to see the page load or not. If the page load, then there is a web interface and it's likely that's the router. So we go to common IP and until we find the right one. So at that point, there is two kind of routers in the world. One which is web authentication or web login which is the same thing you see on Facebook, Gmail or that kind of stuff. It's basically an authentication where you have the username and password which is inside the HTML form. The other type of authentication is the one you had in previous life or web 1.0 which was the basic authentication. It's an ugly pop-up you have with username and password. And we can have to know which one you are using because if you are using a basic code, we can't really try to brute force it and the type of attack is a little bit different. And once again, the same origin policy prevents us to read the page so we don't have any idea which kind of authentication is used. Fortunately for us, we found one or two bugs in Firefox that are currently reported and we are able to know with 100% accuracy because of this bug whether which kind of authentication you are using. So when we know which authentication you are using, what we are doing is what we call fingerprinting the router. We need to know which model and which brand you have because each brand and each model have a different kind of vulnerability. To do that, we do two tricks. The first one is really one node is we try to fetch one node image from the routers. Every brand has a different logo which has a different size so we can fit gem in JavaScript and read the properties to get an idea of which image are present. The other one which we come up with is actually to defeat the basic code idea which is if you have a basic code, if you are mistaken, you will see an ugly pop-up and the user will click cancel and you're dead. So we're doing port scanning because you can do that with XHR requests. XHR requests are not bound to a specific port. You can do a lot of them except some specific one like support SMTP port. So with this, we first do a first pass of scanning all the port, get an idea of which router you might have and do further fingerprinting with image. As a result, we can tell which one are positive, which one are negative and have a pretty good idea of who you are. Actually now we're an implementation. We have a fingerprinting which works 100% and we were able to actually know each brand and each model as 100% accuracy. When we are at this point, what we have to do is authenticate to the router. Remember, the router is protected by a password. So before I'm going a little bit further, how many of you ever changed the router password at home? All of you. Fantastic. I don't trust you. No, seriously, I don't. But okay, let's assume you are all making the right choice and of course, let me raise your hand. Who choose a password which is more than 10 characters? Raise all your hand. Come on. Okay, right. So everyone has a secure, strong password, never use one-time password only for their home router, right? Well, the nice thing for us is if the default password doesn't work, what we can do is we can actually brute force it for two reasons. The first one is this kind of router do not have a CSRF defense. So we're able to try as many login as we want and we're able to inject page from the malicious JavaScript to the router. And the second one is we know we are successfully logged or not by using what we call timing attack. So a timing attack is the idea that if the page is not logged, you only see login and password which is really fast to display. So the login time will be really, really fast in the order of 300 millisecond. If we are logged, there is a ton of stuff like basic setup, router setup, wireless setup, you know, it's all huge page. So which take about one second to one second and a half. Since we're on a local network, it's really reliable because we don't have any latencies. Remember it's from the router to the browser which is inside the local network. So the latency doesn't play a role here. So we can do a good guess. If you are using basic code, and that's kind of the irony of the story is basic code is more secure because we have only one try. We don't have a way to brute force basic code because we have no way to actually tell whether you're successful or not. And if we fail, we have a pop up. We found a way at some point to actually remove the pop up, but we can't still know whether it's successful or not. So, well, in any case, we are able to brute force most of the router which moves to the web authentication part, a web login form. And as a bonus point, at some point where we had one which was even better, is we tried to authenticate and somehow our code was messed up and petitioned, hey, it's still working and we're looking at each other anyway. What happened? Actually, some of the router actually do not enforce permission so you can actually inject anything you want in it with a supplying password. I'm not going to tell you which brand because everyone is going to show them away. But yeah, very famous brand. So, once again, even if we're able to be authenticated to the router, we have no way to redirect the page which contains the WPA key, right? So at that point, we have to find new vulnerability and this time we found vulnerability inside the routers. And what we're going to use is we're going to use exercise vulnerability. We found five out of the eight brands we looked at has exercise vulnerability. And what we're going to do is very simple. We're going to inject a payload which is an external JavaScript. And this JavaScript will be injected into the router and we can do that because once again, there is no CSRF defense so there is no check where the input came from. So some of you might wonder here, well, this might work so you can have an injection but what about if the injection is not in the right page? So usually when we found an exercise, it's not on the page which has the WPA key. Well, it doesn't matter because we have what we call cross origin contamination, which means that if you have an exercise in one page, we can use that to actually open an iframe. And this iframe would be inside the same origin. So this time the same origin policy doesn't prevent us to read inside the iframe. And from this, we are just able to read the key. And at this point, we're almost done. It's almost mission complete because no thing prevents us to send back the key to home to the attacker, right? So you might wonder, well, what happened if you can't find an exercise vulnerability? Well, there is two things for you here. The first is you can use click jacking. And we found that most of any router do not have any click jacking defense. So you can use a trick found by Paul Stone, show it at the black cat show up to hotel, which is a drag and drop click jacking. If you can lose the user into drag and dropping, which is not that hard, think of making a fake game, then you can extract any data you want from a page. So all you have to do is frame the page and have the user do a drag and drop for example, feeding a puppy or moving around their mouse or whatever. And we found that eight of the router out of eight router have never do that. And two days ago, Craig Fner also showed that you can use DNS rebinding attack to actually access a page from outside so you can do this as well. And so you have the key, right? So the key is gone. And we have one problem. Can you guess what it is? Well, I have a key, but where is the network, right? You have a nice key, a long key, and the key doesn't tell you much where the router is. So we have the key, we don't know where the router is. Well, turns out that there is an app for that. And actually it's a courtesy of Firefox. So Firefox did introduce for those who don't know that in 3.5, I guess, something which is caused a leak location or browsing. So what it looked like for those who never see it is it's a little pop up on the top, which is do you want to share your location with the page? It's used to give you to give the page information of where you are so they can provide you more relevant information like restaurant or place to go through. And under the hood, what's happened is there is a partnership with Google. And Google uses this little car you see on the bottom, which are touring all the cities in the world and gathering a lot of information. And there were a lot of discussion whether it's a good thing or a bad thing for Google to collect that much data. Well, this is one example of where this data is actually harmful. So what happened under the hood? And it's also has been found by a semi-canva, which do I think a talk here, which is how I met your girlfriend. So the idea is that Google, you can, there is a protocol with Google where you actually supply the MAC address and Google will do a lookup in the database and give you what they believe is the correct coordinate. And since your access point is usually up 24 hours, 7, there is a good chance that if your city is big enough, they will know where you are. And you can know where your location is with a 500 meter precision, more or less, at least in our test. So you do all these requests, you get longitude latitude. And of course, it's usually using Google, what about just asking for a map. So you actually, the attacker just get a nice map of where the network is. So you have the WPA key, you have the network position, and then you're all set, right? Who cares about WPA? You have the key. And who want to see how it looks like in real? No one? Yeah, okay. Go for it, okay. So this is a demo of our code, fully written in JavaScript. So you see in this type one, we're doing a fingerprinting of the browser to know which kind of exploit we can use. Then we're going to port scan, find what kind of authentication we are using. It's a bug in Firefox. Then fingerprinting the routers, injecting an XSS in this case, and then we have to wait because it's an injected XSS in this case, in this SMC case. So we have to wait 20 seconds until it reboots. And then we're going to, in an invisible life frame, open it and here's your map address and your key. And this is actually the location of my own house. So if you live near me in Palo Alto, happy to take a free beer, right? Wow, it doesn't hurt to try. And that's the end of our first story. The second story is about HTTPS. And HTTPS, so we're going to show you how we can actually try to make HTTPS a little bit irrelevant, same idea. It's a kind of complex attack. So I'm going to go through five steps. First I'm going to give you a background of how a page is actually constructed, because that's where all the story begins. And then I'm going to discuss a little bit about what the cache injection attack is and I'm going to show you what are the current defense in the browser against that, because there is some. And then I'm going to show you how we were able to bypass them, actually. So a web page starts with a HTML5. We all know that. HTML5, sorry, not five. And we add to that a bunch of images and we usually add a lot of JavaScript. And maybe some flash. And all these came from different origin. You don't see it in your browser, but you can have, for instance, a map from Google, some combination from Yelp, and even some information from Facebook. Just yesterday I went to Pandora and said, hey, this is a group you look on Facebook. Do you want to listen to it? I didn't ask for it, but they are probably communicating with Facebook. So to make this faster, there is one key mechanism in the browser, which is the cache. The cache mechanism works as follows. When you request a page, this page might embed a JavaScript library. And so the browser is going to fetch it the first time. And if there is a proper header with this JavaScript library, it will stay into the cache. And the headers say, do not request me this file until a certain amount of time. So the next time you're browsing a page and this page has the same JavaScript, then it's not going to download it, it's going to get it from the cache, right? And this is a fairly common practice. I did a bit of crowding on the top, Alexa top 100, 100,000 website. And I see that 43% at least have an external JavaScript. Can you guess which is the most popular JavaScript library in the world right now? Google? Which one of Google? Google Apps? Google Ads? No, you're wrong. Google Analytics, right. And the second one is the GQuery. So the first one is Google Analytics by four, followed by GQuery. And then you have SF, SWF object, which is basically the library you just to load flash object into your page. Google Ads is fourth. And then you have Prototype, which is another JavaScript framework. So all of these guys are JavaScript library shared. So some of them are different. Google Analytics is shared. You have one instance of Google Analytics shared by everyone. And some people have their own version of GQuery, right? But all of them are external JavaScript finally built into the page. So the attack story works like this. One time, let's say in the middle, after a huge work, you go back to a coffee shop and you browse your email. So at that point, you are in an insecure network, let's say, as in the DEF CON. You connect your laptop and God knows what happened to you. Well, in this case, what we know for sure is that there is a guy which is going to do a man in the middle. What happened during this man in the middle is you're going to request any page, could be CNN, could be whatever you want. And the attacker will stop this page and will add a link to a JavaScript library, which you didn't request. But it doesn't matter because you can modify any HTML page which is not a HTTPS. There is no integrity on that. And your brother will, after that, parse it and actually request it because that's his job. At that point, instead of requesting it to the real server, the attacker will supply you a malicious version of it. So later, you go back home and you might decide to write a blog post, like how awesome was the talk about memory. And you go there and you try to log in. And actually, blogger use Google Analytics, I guess, or one of the two. And so you're going to go there. And instead of looking for the real JavaScript libraries, what it's going to do is it's going to load the Poisoned JavaScript library. And this Poisoned JavaScript library will not trigger any error because it's already accepted. And this malicious library will actually steal your login and password of HTTPS. And you will see nothing. It doesn't matter if you move any location. As long as you don't clear your browser cache, it will be in effect. And as I said, a single library is used by many websites which makes this attack so powerful is that Google Analytics is used by many, many websites. GQuery over CDN, Google CDN is used by many, many websites. So if an attacker is able to inject one of these libraries to you, he's going to compromise a lot of your HTTPS session. So you might say, hey, there is a defense against that, right? What is the defense against this one? Hmm? You have a warning, remember? Every time you try to connect to a site over HTTPS which don't have the proper SSR certificate, you get a warning. Did you attend the talk before? So yeah, you have this warning, fairly strong warning, say, hey, this is not the correct certificate. The domain name mismatch. Do not click through it. The Firefox one has three clicks until you get to the point. So every time you try to, the attacker tried to enter a bad library, malicious library, he would have to defeat these warnings. So how we defeat that? Well, the first thing is you can always trust the user to do the bad choice, right? Just trust the user to just ignore the warning and go through. And actually the user is kind of right in this case. So this is Twitter.com, right? How many of you have a Twitter account? Okay, so many people. So if you go to Twitter.com over HTTPS, it works. Now if you go to www.twitter.com, you get this. Why? Because the Twitter certificate is for Twitter.com, not www.twitter.com. And actually E-V-Cert prevents you from having a wild card in it. So there is, until you have two certificates into different IPs and come do that. Same thing for YouTube. If you try to go to www.youtube.htps.youtube.com, you get a Gmail, Google certificate, so you get a warning. So the user is kind of trying to disobey this warning. How many of you ever clicked through this kind of warning? Yeah, a lot of people as well. See, you're trying to not pay attention to this kind of warning. And even from quality show that actually 92% of the SSR certificates have a mismatch. So it's likely that at any point the user will go through them. Same thing if you think that the positive warning like cited entity give any idea and the user will pay attention to it. This is a Firefox study for Firefox 4. It's a heat map where users are clicking. The one you don't see is actually the one where you have HTTPS information. No one is clicking on it. So positive warning don't work as well. This is a more detailed stat. And actually the more expensive SSR certificate become, the less people are clicking on it. And it's bigger, right? So, but it won't be a death control if I'm just saying hey, just trust the user. What about we try to trick the browser into not displaying the warning so it's actually more effective, right? So we're going to do that. The first one is IE. So this is a warning you have for Internet Explorer. It's a pretty, pretty strong warning, right? You have two red shield and say do not, it's not recommended to continue. It will happen a lot of bad things to you. And they hope that the user won't click. Of course he will click, but assume for a second the user is responsible like you and won't click. Then we can actually find a corner case where it's not displayed. Or it's displayed in such a way that you might be confused. Do you want to see a demo of that? Thank you. So here you go. So this is a page. We're going to click to the page with the bad warning. And this is the warning you get. This yellow bar on the top. And that's it. And what you can do is just display the content or display the content. There is absolutely no choice for you. And you're going to accept it. Of course. And then when you go to blogger, you're already dead by now, right? It's in the cache. And now the SSL certificate on the top is valid, as you can see. And if I enter a login and password, not going to give you mine, but then you see we are displaying it. And this will last until your browser is cache. And the nice thing about this vulnerability in I is that you can cache when you click to your display and secure content, we actually did cache five different libraries. So if you go to Twitter, over HTTPS, and you see the e-view search on the top and we're going to do non-mixed content. This is not a warning because of the attack, but because on the bottom left there is an image over HTTPS. So we're going to do fully over HTTPS. And you see the bar is green. Everything looks secure. You enter your email and your password. And guess what? Here you go. So no warning, no nothing. And you get all your SSL compensation compromised forever. Or at least you change browser or clear cache. How many people are clearing the cache? Everyone. Okay, I'm going to stop asking questions. Okay, so we found a bunch of these. Microsoft asked us to actually do not explain you how we find them until they are all fixed. So we're not giving you any details, we're going to show you a screenshot. This is one other inconsistency, this one is really weird. Basically they show you the name is not correct and you have view certificate, but you don't have the right warning. So people might also be confused by this one. Although I prefer this one. Let's move to Firefox, right? So here is the Firefox warning. This one is different. They actually try to make it very painful to the user by doing three click. So they hope that the user is not responsible but lazy. So he's not going to do three click to get to the page. And actually Firefox do a very good job into displaying the warning and suddenly we didn't find any corner case where we are not able to display it. So we had to be more creative. How many of you ever heard about clickjacking? Raise your hand. Okay, half of the audience. So for those who never heard about clickjacking, just one slide, everyone on the same page. This is clickjacking. So the idea is the attacker display you a page like the best game ever. Download this awesome movie Iron Man 2. What's the next new movie? Inception. You can click here to download it and the user is going to do that. What happened under the hood is you have a transparent div on top of it which has another input box. And when the user is trying to do something, what he will happen is he will click on this invisible button and do something he will regret later. Of course here for Twitter they have frame busting defense. It doesn't work. It's just to give you an example. So you click and instead of clicking to download or start, you're actually clicking on leaving Twitter. So that's how we saw the Firefox challenge. Well, sure we can't remove it but we can clickjack it. And that's exactly what we're going to show you. So we were able to remove two out of the three clicks. So I assume you have this, you want to download something and you have a user argument so you click on it and actually you just clickjack your warning and you see only the last pop-up. The big warning is completely gone. And if I go to twitter.com, same as previously, you're going, oh, a blogger, sorry. Oops. If you go to blogger and tell your username and password, same story. So warning, the SSL is perfectly valid and you see the shirt on the top, the blue indicator for Firefox and you see the user and password. That's how you can do cash injection against HTTPS. For the third part of the talk we're going to, I'm going to let Baptiste show you how it works and their audience. Thanks. So for the third part of this presentation, I will show you how we can actually steal private data from users using Framlic attacks. Framlic attacks is an evolution of clickjacking and scrolling attack. Clickjacking, just presented previously by Ellie, is a term coined by Jeremiah Grossman and Robert Ensign in 2008. Scrolling attack is a new attack showed by Paul Stone in the block at Europe this year. This attack works as follow. In the first step, the attacker will double frame the target website. Here in this example, it will be the mobile version of Yahoo Mail. In the second time, the attacker will use a browser feature called the encore scrolling. This feature makes the page scroll automatically to a specific ID when adding it as the hashtag is a URL. So here in this example, every email can be associated to a specific ID. For example, the first mail from just now is associated to the to the ID checkbox 29. So if I add this ID in the URL, automatically the page will scroll. Paul Stone showed that actually from the outside frame, the attacker frame, you can actually know if the targeted website is called or not. And at this point, it breaks the same origin policy because you can know if an element is present on the page or not. If the page don't contain any email, the chain box element will not be present. So the page will not scroll. So we can actually know if there is any email in the inbox or not. In the following demo, here I will show you how we can actually conduct an attack against the mobile version of Yahoo Mail. Here you can see the victim inbox containing email from me. So if I search for my email, automatically the page will contain the ID, chain box 29. So we can actually scroll to it. But if I search for a non-existing sender, the page will be, the search will be empty. So the ID will not be present. We use this binary test to actually search in the inbox to know if the victim received email from specific senders. Here, as you can see, I can know if I receive an email from Ellie or from me. This is a very serious security breach. As you can know, as you can imagine, you can actually know if the victim received either as an account in a specific bank or other drugs on a specific website, looking in his inbox. However, to prevent this kind of attack, framing attacks like click jacking and scrolling attack, most websites use a specific defense called frame busting, which made the frame 8 page become the top of the page. Automatically. However, Facebook use a slightly different approach. When framed, Facebook display a huge dark div on the top of the page, which prevents the user from interacting with the content. But it's still able to see his information. But when you click on this dark div, automatically the page will be frame busting. However, it will not prevent us from scrolling to specific IDs. So we can conduct an attack, a framing attack on Facebook. Using three different IDs, we can actually know if the user is logged on Facebook, who he is and who are his friends. For example, to know if he's logged or not, have you any idea for an ID we can try to check? Actually, we are not searching for a specific ID if he's logged. We are searching if an ID is not present of the page. For example, the registration form was shown only on a non-logged page. So if I frame the first page, it will not scroll, so I will know that the user is not logged. So here is the demo. On the left side, you can see the framing attack result. And on the right side, what really happened under the hood, on the real attack, it will be definitely not showed. Here you can see the page on the right, it doesn't scroll. So I know that the user is logged. Here we are looking for the logged user and the page scrolls, so we know that the ID we are looking for is not the right one. If we search for the ID ID, here the page doesn't scroll, so we know who is logged. This is basically the same test for to know the friendship relation. But using a different ID to search. But actually, Facebook updated their defense to get this kind of attack. Just yesterday, well actually, Wednesday, Facebook made a different defense. Now they don't display any contents anymore, they are just display Facebook logo on the framing page. So we cannot any more use framing attack on Facebook. Okay, that's it for this third story. I will only finish with maybe the more powerful attack in the fourth story. Okay, so for the last 10 minutes, we're going to speak a little bit about this guy, smartphone. How many of you have a smartphone? Okay, once again, everyone. Good. So, I mean, it's not surprising, it will not come to any surprise to anyone. A lot of smartphone has been sold for $54 million in this first quarter into a 10, so it's a lot of smartphone. This has two effects. The first one is ITNG is not working anymore in San Francisco. And the second one is many popular websites has rolled out a mobile version of the website to accommodate this kind of small device. And people might not realize that by now, but suppose you have in your iPhone or in your Android phone or Nokia or BlackBerry is very, very different from the one you are using on your desktop counterpart, in particular because there is a lot of new feature which has been added for usability purpose. The screen is so small that what you try to do is to maximize the space which is used for display. And this actually conflict with something we have been used for almost 20 years now, which is the idea that all the security indicators you have in your browser are located on the top of it, which is what we call the Chrome. So privileged version, privileged part of the okay. Wow, impressive. Micro attack. Okay. Well, so and there are so we trust the Chrome. We really trust the Chrome on the on the browser to display information such as the URL that you can't prove and the identity. And the phone, people try to do full usability purpose. So they are trying to remove as many information, which are closer to the screen. There is also something which is makes them very, very different under the hood is because phone, you actually moving from one application to another. And since Apple did not decide to do multitasking yet, or Clinton, then you have the cookie that you we are usually expired when you close your browser on the desktop right. Do live into the browser forever until basically did not killing session cookie. So let me show you a demo of what I mean, because I think it's more visual than and it will worth a thousand word. This is Wells Fargo mobile website. Any Wells Fargo user here? Okay. Does it look like the real website? Completely. Yeah. And that's the correct idea. And as if you see the lock is here. And URL is correct. The lock is correct. There is no warning. We didn't fake anything on this part of this list. And look what happened when you click on sign in. Here you go. Any idea how we did that? No fake keyboard. No, we didn't fake the keyboard. That's capture of a real Android keyboard. Yeah, you get a correct idea. The problem with the phone, and I think if I could show you this picture, people will see better what I mean, is actually we can draw an image which looked like a URL bar, which is not one. And actually we can use the usability feature to scroll to it. That is not our idea. It was in the paper. When we come up with the idea, we look back in the reference literature. And actually there is a paper two years ago. We say it would be very, very dangerous. And I think no one pay attention to it. I hope people will start to pay attention to that. And that's really, I mean, that's the most easy attack to do, right? You can display any website. We choose WebFago. We can have Jews, Gmail, whatever. So there's coding attack. What we want to show you is tab jacking. So what is the tab jacking? Well, you take a click jacking, you take the mobile phone, you squish very, very hard, and bam, you have click jacking on sorry, tab jacking. And tab jacking is actually click jacking on sorry for phone for a very, very good reason. Six months, six months ago, we look at how many websites are using frame busting defense against click jacking. And this is a real desktop part of this website. And you see that people are kind of doing a good job. Can you guess how many websites are using frame, click jacking defense on the mobile site? Two. Like this, right? Yeah, that's Twitter and Facebook because we went to them and knocked on the door and say, hey, you should do something. Actually, how many of you remember the worm on Twitter, which was in May 2009 where you actually had this thing which is do not click here and you try the user to disobey and click here and generating more and more tweets. You remember this one? It was a huge worm. We actually took down Twitter and from for at least a day. We were able to actually reproduce it on the phone. Here's a demo. And what happened here under the hood is you have an invisible iPhone and we are using a very cool feature from the phone which is zooming. So basically the tweet button is actually the entire screen. So no matter what you click, you're actually clicking on I want to tweet and you're going to tweet something for us and you don't see it. So if you go to Twitter.com and we're not making that up, we go to the mobile website because at that time they didn't have a frame busting defense. We were able to do a tap jacking. Of course, we could have say don't not click on this link. Show the game. Click on it and do a worm. Of course, we're a good guy so we didn't do that. So that was a tap jacking. Twitter was really, really efficient to fix that code. So now they have a frame busting code. So this one is safe. But I really hope that you will try to scroll up when you try to log to your bank and realize that actually if someone is using JavaScript, it will prevent you to do that. So it's kind of a plus right now. If I have two more minutes, what I want to show you is what we're going to do demo Sunday. Sunday, we have another talk. We hope you're going to join us. We're going to speak about game security and to show you how cool it is. Here is my invincible tank. You can see it's health bar and we're going to show you how we can do attack on game on Friday afternoon. So I hope you will stay at DevCon and come to see us. Track five. Thanks everyone for showing us. And now...