Tarbiz

Transcription

PARISA TABRIZ: All right, cool. So hello everyone. Welcome. This is really exciting. I am I'm very happy to see so many people that are interested in security. So my name's Parisa. Peter, thanks for the awesome introduction. And I get the honor of being the master of ceremonies, and to kick off our security themed evening. So we titled this event web security, attack, defend, and profit. And myself and the next three speakers are going to each touch on those topics. So I work at Google. And some of you may be familiar with our company motto, which is, don't be evil. On the security team we extend that to, don't be evil, but do know evil. And I'm going to use this short intro to talk a little bit about why I think it's really important for developers to occasionally embrace the attacker mindset. So I've worked at Google for a little over seven years. Currently I manage the Chrome security team. But when I started at Google I was an engineer in what we call the hired hacker team. And we had this broad mission of doing whatever we could to improve the security of Google's web applications. At the time, Google was just a web app company. Today we dabble in other things. So one of the core functions of this team was to do information security consulting, security design, penetration testing. And these are just fancy ways of saying, our job was to break the software that all of the other Google engineers were building. We were trying to find holes. Ways to exploit the apps that the people doing then didn't think was possible or didn't necessarily intend, with the long term goal of actually finding ways to defend against that. So in particular, we would try to achieve some goal like theft of information or assets, being able to hijack some account credentials and log into an account we didn't own, because this is a thread we were and still are most worried about at Google. So as a developer, all of you build applications. This is a picture from prior event. And you all are good people, and you have the purest of intentions. You create useful and delightful applications that make the world and internet a better place. And honestly, you have my admiration. Because it is so much harder to build robust and secure applications, and software, than it is to break them and find holes. So you have my admiration and my gratitude. But the world is not only filled with your kind. And there are bad guys, and bad girls, that want to break your applications and abuse holes in your software, and attack your users for personal profit or gain. And these are the people that I worry about. I worry about them both as a user myself, and on behalf of the users of the software projects that I'm involved with. So to pull from my copious knowledge of ancient Chinese military strategy, I'm going to quote a famous general, Sun Tzu, and say, "To know your enemy, you must become your enemy." So if my personal experience working in software is worth anything, it's that having experience in breaking software and knowing how to practically exploit software will make you a better developer of secure software. It's one of the strongest foundations you can have. And I know that everybody here wants to build secure software. So take the black hat on, and embrace the attacker mindset for a moment. So as I said, to start the night off, I want you to think about breaking the software you use. Breaking to suffer you write. Find the holes. Find the weaknesses. And think of ways to exploit it. Because I can assure you that if you're working on anything that's successful or interesting, other people will be trying to do that. So you may as well. Only after you've totally tried to break a piece of software can you really have confidence in its robustness and its security. So we have a training for engineers at Google that encourages this attacker mindset. And we often start off with a non-software example. I want to start us off in the same way. Suppose I tasked you with trying to rip off a vending machine. This vending machine, it's in a large and crowded area. We'll say it's an airport. And I want you to get out as many snacks as you can for as little cost. And do it without getting caught. So what would you do? AUDIENCE: Walk up with a key. PARISA TABRIZ: Walk up with a key. Where are you getting a key from? AUDIENCE: [INAUDIBLE] it might change, but social engineer somebody else [INAUDIBLE]. PARISA TABRIZ: OK. Social engineering. I like it. Usually abusing the weakest link, which unfortunately sometimes is the human, is successful. So good answer. What else? AUDIENCE: Use a brick. [LAUGHTER] PARISA TABRIZ: Yes. The sledgehammer attack is often effective. I want something a little bit more stealthy. AUDIENCE: Tell security that there's a bomb inside the airport. PARISA TABRIZ: Oh. Let's-- I saw one hand. AUDIENCE: Dress up as a maintenance person, turn the machine on its side. Take out the [INAUDIBLE]. PARISA TABRIZ: How do you turn the machine on? AUDIENCE: No, on its side. PARISA TABRIZ: Oh, turn the machine on-- OK. Sure. We'll do-- Yeah. AUDIENCE: Make a coin. Make a counterfeit coin. PARISA TABRIZ: OK. Counterfeit coin, I like. I actually have an image that-- this is my favorite attack. If you search online, there is tons of resources on how to hack into vending machines. So there's resources for how to abuse the mechanical components. And you can look up the specific manual for all of these different vending machines. You can find ways to abuse the programming logic. And even the electrical components. So, I have not verified any of these. I have no guarantee that squirting salt water in the coin slot of a soda machine will create an electrical current that can result in free soda. I'm kind of doubting that one, but this is the internet. So who knows what to believe? So someone suggested counterfeit coins. And this is actually one of my favorite approaches. It involves currency where there is similar blanks, or minting techniques, used for multiple different currencies. International currencies. This is a picture of the two Euro coin, which is worth approximately $2.70. US dollars. And here are a couple of pictures of coins that have successfully fooled vending machines, and are worth vastly less. So we have the Thai baht at about an eighth of the value. The Mexican peso, the Philippine peso. There's actually a lot more that have a very similar blank. Coincidentally, I actually was in Germany last week, and I only realized at the end of my trip that someone had actually given me a Thai baht, probably as change at some point during my trip. Because I tried paying for a snack, and the cashier gave me this really nasty look like, this is not a two Euro. So I can attest from first hand that these attacks, if not successful on a vending machine, at least worked on me. So, to be clear, I'm not advocating that you go and rip off vending machines. Happily I think we have tons of food if you're hungry, and tons of booze. And apologies to people on the live stream. But thinking through possible ways to attack a system, whether it's a vending machine or a piece of software, will certainly help you build in better defenses to some of those threats and attacks. And that's what I'm encouraging you to do as you build software. So I don't know if anybody in here actually makes vending machines. I assume you care about web applications. So we want to talk about hacking web applications. Has anyone heard of any common types of web security bugs? AUDIENCE: SQL injection. PARISA TABRIZ: SQL injection. Anything else? Cross site scripting. CSRF. What does CSRF stand for? AUDIENCE: Cross site request forgery. PARISA TABRIZ: Cross site request forgery. Awesome. DDOS. Distributed denial of service attack. Cool. Any others? AUDIENCE: SSL. PARISA TABRIZ: SSL is a security thing. Maybe attacks to SSL? AUDIENCE: [INAUDIBLE]. PARISA TABRIZ: OK. We've got lots. I'm hearing lots of things that are right, or technologies that can be abused. So cross site scripting is one that you're going to hear a couple times tonight. It is the most common type of web vulnerability. It's the most common type of reported vulnerability, security bug, today. And I say that with my experience at Google. So it's the most common security bug we find in Google software. It's also the most common bug that's reported or disclosed across industry today. It's taken over buffer overflows as the most common bug. So the textbook definition. Cross site scripting, it's commonly abbreviated as XSS. It's a vulnerability that enables attackers to execute malicious code within the context of a vulnerable web application. So you get attacker gets remote code execution in a victim's session of some web app. So this is the textbook definition. Here are a bunch of headlines that I found really quickly. I cannot think of a single application that I have used that has not been vulnerable at some point to a cross site scripting bug. This applies to Google software, it applies to lots of other services that I use. And Tim, our next presenter, is actually going to give you a little bit more data as to the scope of this problem. But it's really an important bug to understand, and to think about when you're building web apps. So I gave you the textbook definition of XSS. And maybe some of you are already familiar with this bug, or have actually thought about ways to mitigate it in apps you've run. But the best way to truly understand the damage this vulnerability can cause is really to practice finding them. So just this morning, we actually launched two things which I want to point everybody to, and I encourage you to check out after this event tonight. Because they will really help hone your hacking skills. So the first is interactive guide on XSS. We'll see if links work. They do. So the URL on the slides, and of course we'll share the slides, will bring you to this nice write up of cross site scripting. And you not only get a more comprehensive description of what cross site scripting is, but really nice interactive demos where you can actually try this out and see how it works in little applications. So you have this fake search engine called Bobazillion. And one of the most common ways that a cross site scripting flaw ends up being introduced into a web application is if the application is handling user input, which is untrusted input, and not actually performing the correct sanitization or escaping before it actually includes this input in the response page. So this first example is actually trying to guide you through finding a cross site scripting flaw as a user would type input into a search engine. OK. So check out that. Go learn XSS. And once you learn all about XSS, you can check out this other really fun thing that we launched this morning, which is the XSS war game. I'll read off the top. "Welcome recruit! Cross site scripting bugs are one of the most common and dangerous types of vulnerabilities in web applications." La-la-la. "At Google, we know very well how important these bugs. In fact, Google is so serious about finding and fixing XSS, we are paying mercenaries up to $7,500." So this is true. Tim's going to talk about this again in the next talk, but we reward researchers that report cross site scripting bugs, as well as a bunch of other bugs. And this is a great way to practice finding them. So, this is the first level. And we'll actually open this as well. And you guys will all help me go through the first level. So cross site scripting. We talked about them being the most common and dangerous bugs. In this training, you will learn about this. So if we go to level one, "This level demonstrates a common cause of XSS, where user input is directly included in the page without proper escaping. Interact with the vulnerable application window below, and find a way to make it execute JavaScript of your choosing. You can take actions inside the vulnerable window, or directly edit its URL bar." So your objective for this mission is to inject a script to pop up a JavaScript alert in the frame below. Typically, as a security researcher, you're trying to demonstrate, hey, there's a bug and I'm able to actually execute code, we'll use the alert function. Because it's just a very easy indication that you're able to perform something. So that alert function is a common way to demonstrate a bug. Once you show the alert, you'll be able to advance to the next level. OK. So this actually looks very similar to the demo that I just showed. We have some user input here, and then we're going to click Search. And your goal is to find the alert box. Anybody have a solution? Raise your hand. Yes. AUDIENCE: Send my [INAUDIBLE] alerts. PARISA TABRIZ: OK. So like this? OK. And then you want me to click Search? OK. Anybody else? I need a hand. Yeah. AUDIENCE: [INAUDIBLE]. PARISA TABRIZ: Oops. Script, alert. You tell me if this looks right. Like this? Oops. Is that what you want? AUDIENCE: [INAUDIBLE]. PARISA TABRIZ: OK. We have a winner. OK. I could have passed something. We alert undefined. Good job. OK. So, with the help of our friends-- I don't know your name-- but everybody has passed the first level. And we can advance to the next level. And we're not going to go through all these, but they get increasingly more challenging, and it's a really good way to practice finding XSS and understanding really how complex these bugs can actually be. It's simple in theory, but it's really hard to eradicate them from web apps. So check that out. It's really fun. And we'll go back to this. Once you really master XSS, you can check out this interactive code lab. This is actually a couple of years old, but still totally relevant. It's called Gruyere. And it also has crested scripting bugs, as well as a bunch of the other types of common bugs that you may have heard mentioned by people in the audience before. So there's cross site request forgery, or CSRF. There is some off bypass errors in this bug, some mixed content bugs. Lots of different common security bugs. And the training will not only describe what the type of vulnerability is, but it will guide you through exercises to find the bugs, and also figure out how to fix them. Last book for anybody who can tell me why this is called Gruyere. yes. AUDIENCE: It's a type of cheese. PARISA TABRIZ: Yes, it's a type of cheese, but-- yeah, in the blue shirt. AUDIENCE: [INAUDIBLE]. PARISA TABRIZ: Yes. So, Gruyere is a delicious cheese, and it's also known for having lots of little tiny holes. I was afraid I was going to get electronically zapped for going outside the speaker zone. So check this out. This is going to help as well hone your hacking skill. Those are some excellent resources to start. After that, you should be well suited to start hacking on your own software, or the software that you use. And all of this is-- I mean have fun with it, but also it's going to help you build better software in terms of defense. And potentially even profit, which is what we're going to hear about from our next speaker. So I'm going to leave you with much more qualified hands. My three colleagues at Google are going to be speaking tonight. Tim, Eduardo, and Joel. Tim's up first. Tim works at Google, and among many other things, he makes sure that security bugs get fixed, which is actually really hard. It's one thing to find the bugs, it's another thing to get them fixed. So he spends his time working with internal engineers at Google, and also external security researchers that find and report bugs to us. And before Google, Tim worked in Australian department of defense. So he has come from far away lands too, to join us in the Bay Area. So I'm going to give it up to Tim. Enjoy. [APPLAUSE]