 Hello. My name is Michael Schrenk. I live in Las Vegas, Nevada, where I write bot nets for a living and I'm here to talk about malware. Thanks for coming to my talk. So I said I write bot nets and what that basically means is that I write distributed systems that do data extraction. We do automation. We do analytics. But one thing that we get to do a lot more than probably most people is look at other people's code. It's because we download web pages and we have to write parsers for them. So we get to look at a lot of source code. And one of the things that I've noticed, I've been doing this now since the mid 90s and I've noticed that people are using JavaScript differently than they did even 10 years ago. So that's what this is about. And I believe that JavaScript is being used in a dangerous way that can be used as an attack vector. So one of the things I did to get a better idea of how people are using JavaScript, you know, if I just looking at files randomly, that means one thing. But to go off and look at 1000 of the top websites and see how they use JavaScript to be a really useful thing. So I did that. I wrote a bot that goes out and looks at a list of 1000 websites, analyzes their homepage for how they are using JavaScript. And that's part of this talk. But here's really what we're going to discuss. We are going to discuss this thing that I'm calling third party JavaScript, which is like this stuff that we're talking about right here. It's these little scripts that people include in their HTML that brings in external JavaScript libraries like, like jQuery, Google charts, you name it. There are a lot of these that people are using. And I believe that these third party JavaScript files are an attack vector. And I'm going to show you why. I'm going to give you examples. And I'm also going to teach you ways that you can use these third party files in a much, much more secure environment. So one of the things that I want to make very clear here is that I do not believe that JavaScript itself is a threat. I believe that the way people use JavaScript is a threat. And the way they're using it creates opportunities for attack vectors. So before we look at the threat, we need to figure out what exactly JavaScript is capable of doing. Well, it's basically capable of doing two things. As you probably know, if you're a developer, you know that JavaScript operates on the DOM. So anything on a web page, JavaScript pretty much has access to it with a few exceptions. But basically it can not only have access to it, but it can also change things on the website. The other thing it can do is JavaScript can communicate with other servers, right, using Ajax, you kind of technologies. Also, if you are downloading the library from an external server, you're also leaving server logs, right? So my guess is that if you went to any of these big framework supply like jQuery or Angular, if you looked in their log files, you could learn a lot about the people who are using their libraries just from the metadata that becomes created. The other thing you might say is that JavaScript, that's not dangerous, that's just like HTML, right? No, it is actually dangerous. There have been over 40,000 known examples of JavaScript malware that have not only been documented, but they're available for you at this website, at GitHub, the address is in the URL. And you can go there and you can download them, you can play with them, you can study them, you can do whatever you want to with them. But they do exist. So what exactly am I talking about when I refer to a third-party JavaScript file? Well, there's two different things that I'm referring to. There are files that are truly third-party and truly remote. That would include examples like the one over here. I got to get this down right over here. You're just making a JavaScript request to bring in or to include another JavaScript file that you will reference later. The other example would be a file that's running off of your own server, but it's one that you didn't write. You went and you downloaded somebody's library, threw it on your server, referenced that and that's the file that you're using. As far as I'm concerned, if you don't do anything else, these are both third-party JavaScript files and they can both cause some trouble. The other problem is that when you're using somebody else's code like this, you are doing it without any kind of source control whatsoever. Now, I think to some degree, the whole notion of source control is a little bit generational. And I'm going to say that because I did a very similar talk a few years ago in Sofia, Bulgaria, and I was at the Code Monsters Java 2 Days Conference. And I was talking to a room of probably, I don't know, 1,500 people or so, and I asked for a rising of hands. How many people were developers who have developed code not for the internet, not for a web application? Of all the people in that room, I maybe saw five or six hands come up and they were mostly older people like myself who had worked in other areas. Web development is a little different apparently. A lot of what we would consider traditional DevOps don't seem to apply anymore. One of them is source control. So what is source control? Well, source control is a number of things, but it assumes that you validate your production software. That's kind of basic in source control. The other thing is that it assumes that you freeze your code before you do your validation. You also need to prove that your code hasn't changed while you're validating it. So in other words, somebody makes a quick fix that may affect other things. So you probably want to look at other things too. The other thing is that you only want to release production quality software, okay? And you only make changes to known good code. Those are the things that happen with source control. Now, when you're kind of importing somebody else's code into your software, not a whole lot of this happens. Not a whole lot of this happens. The other part of source control is version control. And version control basically says that you're able to go back to a prior version if you need to, or several versions back. But you're able to keep track of changes in an orderly fashion. Again, this is not something that happens when you're just loading in other people's files that basically they're maintaining. Okay. So why are third-party libraries a problem? Well, the other problem is that they're used without any kind of validation generally. And there are reasons for this. You ever look at the code you import? A lot of the code that you download is machine readable only and it's not meant for human eyes. So it's very difficult to validate. I also hear a lot of people saying, I mentioned this a little bit earlier, people say web apps are hard to validate because well, they're just different. They're just different. For example, you don't control the choice of browser. Okay. Unless you only allow one browser, you really don't control what browser they're using. So if you are writing a bunch of server side code, you are running your code in an environment that you don't know a whole lot about. So it's really hard to validate your code in situations like that. Also, you don't control the hardware. You don't know if they're running on a phone. You don't know if it's a phone from the 90s. You don't know if they're running it on a big gaming console. You have no idea what they're running it on. The other thing is that you don't know what they're doing with their browser again. You know, your code might run differently if they have 40 tabs open, all running very complex Google charts or something. You really don't have control over that kind of stuff. So to a real extent, web development is different than other kinds of development, but we shouldn't lose sight of what we're doing. And then some people might say source control or an agile shop. We don't do source control. Well, you might have even more need to do source control if you're in an agile shop, especially version control because things are going to be changing more often. And you definitely can do source control with agile. The other thing people might say is that, well, there's nothing mission critical on our website. So we really don't care. I mean, there's not much that could happen. It's like, well, yeah, that's probably true. I just want to show you an example of a Java trip Trojan called you are an idiot. So this is a short example of what this Trojan does. It's completely harmless outside of the fact that it creates this big visual thing on your display, which is not something that you would probably want on a corporate website or for your organization in general. Not only do these little boxes appear, but they grow in number and they also sing to you too. They also say you are an idiot and they all say this in chorus. So it's quite the thing. You don't really want this. And again, this is a JavaScript exploit. So web development is unique, but you always want to be able to release stable code, right? And you want to make sure that the code you're releasing stays stable and not subject to change. You also want to be able to revert to other stable versions. But regardless of the nature of web development, source control is quite, quite important. And the more important your software is, the more important validation and source control become. Now, one of the problems with all this is that the libraries that people are importing are just so attractive that people just want to use them. And these are things that you probably would not want to write on your own. For example, frameworks, jQuery in particularly. I mean, it's incredibly useful. It just needs to be used with proper DevOps. Again, other libraries, Google Analytics, AdSense. Chart is my favorite, by the way. I use that all the time. These are not JavaScript apps that you really want to write your own. You really don't. You want to use somebody else's. And these are very capable libraries. And that's why people use them. They're just so attractive. But when you use these libraries, the assumption is that they come fully debugged and that the admins use proper source and version control. And also that they're free of exploits. We assume that they are free of exploits. And that's something we probably wouldn't do with the rest of our code. But for some reason, it happens with JavaScript. In many cases, the code that people import is very significant. And let's just look at my survey here to find out what exactly people really do with JavaScript. So how was the survey done? Well, I looked at the home pages of a Google list that I found, Google's top 1,000 websites. How effective that is in identifying the top 1,000 websites, I really don't know. I'm really not even that concerned because the list itself is pretty arbitrary. I just wanted to have a list that people could reference. And again, I just looked at the home pages for the study. I did not include looking at scripts that the JavaScript also imports. That's another thing that happens. You import one JavaScript file from some server and it imports five others. You really have no control over that. So again, the survey came from a list that I found from Google. It's an international list, which is good. And like I said, this list is probably pretty arbitrary. It's probably not that much different than what you would find from something from Alexa or somebody like that. From those 10,000 web pages that I looked at, just the home pages from those, I found over 4,100 unique imported JavaScript files. I also found that almost 75% of those websites use JavaScript. And my number is pretty consistent with other peoples. This is another person's study. And again, I don't know what websites they looked at, but they got a number that was slightly higher than mine. So I think 75 to 90 is probably a pretty close percentage of how many websites are using JavaScript. Of the websites that I looked at, those 1,000, they averaged 6.5 imported JavaScript files per home page. Two of the sites that I looked at imported over 100 separate JavaScript files just on their home page. Can you imagine that? That's the most I've ever seen. Now, this is the number that should probably stick with us. And that is 60% of the websites that we looked at imported third-party JavaScript from another domain. And those are the ones that I think are probably the most dangerous. What are people using? To nobody's surprise, a lot of people are using jQuery. I'm surprised that React and Angular aren't a little more popular. I thought they were. But again, this is primarily corporate websites. Other people may be doing other things. Again, like I said, my list is pretty arbitrary. A lot of people are using Google AdSense. That makes sense. My favorite Google chart wasn't terribly popular. So to understand what we're really talking about here, let's take a history lesson. Let's go back to 1995, the static web, and look at how things were done then. Well, then you'd sit in front of a terminal. You'd request a web page through your browser. It would bring back HTML. Your browser would parse the HTML, look for other media. Go get that media, bring it back, and render the web page. Well, we still do all those things today. But today, we also, in addition to images, we also go out and we download JavaScript from anywhere on the Internet. It could be all kinds of domains from all over the place. Most people don't really pay that much attention. But this stuff is coming from an external source, and that's why we should be taking this very seriously. Because these libraries that are imported are seldom validated by the developer who's importing them. They generally have no source control. Well, you have no source control because you're relying on somebody else to do it, and they may or may not be doing it. And you also don't have control over their server configurations. Now, this probably isn't a big deal if you're talking about Google or Amazon or one of the big players. But some of the smaller ones, do you know that they're patching their server? Do you know what kind of server they're using? You don't know any of the stuff. You're basically trusting that their server configurations are good. They're always going to be up. And again, these are not things you do when you control your source. You don't do any of those things. So what kind of threats are we really looking at here? Definitely bandwidth stealing. I'm going to give you an example that's actually not a JavaScript example, but it makes a really good point about how JavaScript is or how bandwidth is stolen in this kind of a context. There was a developer who came up with a URL shortener. And if you know what URL shorteners are, if you want to send a link to a friend either in social media or through email or something, and it's a really long link, sometimes you use a shortener that'll give you a short little link that you can use that will be expanded into your full link once they click on it and go to the site and are redirected and whatnot. Well, somebody wrote one of these that worked beautifully and became very popular, but in addition to doing the expansion of the link and redirecting them to the correct web page, it would also insert a little bit of JavaScript that would do a denial of service attack on some target. Clever exploit. But these are the kinds of things that can happen with bandwidth stealing. JavaScript is also used, by the way, in that case. The other threats are privacy violations, because JavaScript can look at DOM and it can create analytics. And like I said earlier, just downloading these libraries from another server provides a lot of metadata that really provides, that really creates opportunities for security violations. The other thing are phishing attacks, and phishing attempts are probably the most dominant forms of attacks at this point, and they can also be done through JavaScript. All right, now here's another example I wanted to give you. This is a case where somebody developed a tutorial for Google Analytics, and they also gave you a place to link to the code, how convenient. The only problem is the URL they gave was the wrong URL. It looked very much like the real URL, but it wasn't. So basically, this person just taught you how to use analytics, and now you're using that person's version of analytics, and they basically have all of your web traffic data. Plus, they could also modify the code and inject some other stuff in there, too, if they want. So you don't, again, it's important to do source control. Well, the other threat is that since server-side code runs on your machine, it doesn't run on the server, it runs on somebody else's machine, you are essentially giving people the opportunity to run arbitrary JavaScript code on a lot of users' machines. There can also be bugs and stuff and bugs and exploits. So it wasn't that long ago. There was a zero-day in jQuery, and apparently this thing had been out there for about three years. So, again, this is what happens when you don't control your own source code. So what are some other possible attack vectors if you're using third-party JavaScript? Well, things that can happen after your site is running nicely and everything looks good. The owner of the library that you're using could decide to change the code. And it might be a bug fix, it might be an update, or maybe it's something more deviant. That possibility exists, and if that possibility exists, it will, at some point, happen. Here's another possibility. The owner of the repository that you're using gets hacked, and somebody either changes the code or maybe the server just goes down, right? Part of security is availability. If these remote servers go down, again, to no fault of your own, that creates an issue. Those are other attack vectors. Other things that can happen? You can have things happening with DNS. Somebody can poison DNS, send you off to a different library. There can be DNS spoofing. There can also be some social engineering that happens that could get people to use the wrong libraries. Some other things that you open yourself up to are poor source control used by the person who maintains the repository that you're using. You can run into cross-site scripting issues. All the common exploit types happen here, too. You can have man-in-the-middle attacks. You can have API credentials sent out in clear text. I've seen that happen even on pretty legit JavaScript apps. Anyway, I don't want to discourage people from using JavaScript or even discourage people from using some of these nice frameworks and stuff that people use, but I really would like to encourage people to use them safely. So how do you safely use JavaScript? Well, one way to do it is you can download these libraries and store them locally. That at least gives you control of the source, right? You know it's not going to be changing and you know the environment that it's in. Now, if you do this, you might violate some license agreements that you have. Check with that first. Sometimes this isn't even a possibility because the files need to be remote. They might need to access some resource that is only available remotely and not available on your server. And also, doing this removes any DNS issues that you might be concerned about. Another thing you might try to do is to sandbox your script in an iframe or a frame of some type that might be useful for you. Another thing you might want to look at is using SRI, which is a method to validate that the source and the host and everything is correct. I really haven't seen many people do this. And I'm actually not sure how common this is, to be absolutely honest. The one thing I recommend all organizations doing is never, ever, ever host your website on your own network. Always get it provided by a hosting company. And the reason there is if your website does get broken into, they don't have a path to your network. It's all sitting someplace remotely and that's where it should be. Keep private things private. Let public things be public. Don't mix the two. The other thing that would be a good thing for you to do is to track changes in the libraries. And I don't know how often people do this. So in other words, if you're using a specific version of a library, make sure they don't do the updates for you. In other words, they might make changes and not tell you about it. You need to be able to track changes on any of these libraries that you're using. And finally, I would ask for you to ask yourself if you really need the functionality that this JavaScript library is providing. Do you need that submit button with the rounded edges? Maybe you don't. Maybe you could write what you need to write in pure JavaScript and not have to import those things. That would be wonderful and probably would be a lot more secure. Also, keep in mind that JavaScript is not alone here and that there are other threats around other third-party things like Flash. Some people still use Flash, PDFs, videos. And yes, even images can cause issues. And if you're curious about the kinds of issues that images can create, check out my DEF CON 15 talk. It should be on the server. The fabulous executable image exploit where I talk about how you can have images running arbitrary code on people's servers. So in conclusion, what have we learned? We have learned that JavaScript is awesome. It's not going away. Libraries are just too functional and too hard to ignore. People are going to use them. We just need to find more safe ways of using them. We've learned that source control is a vital part of DevOps. And if you're not doing source control on your entire project, you're not doing software or you're not doing source control really for your project at all. A lot of developers are using JavaScript that they really don't control. And we've also learned that most developers don't validate imported libraries. They just use them. You get that jQuery calendar working that's usually good enough for people, right? They don't do boundary testing and all the other kind of classic stuff that is involved in software test. These scripts that people are importing can be used as attack vectors. We've demonstrated that. And we've learned that there are ways to minimize your risk when using imported JavaScript libraries. So thank you. And I just want to leave you with one final message which is good DevOps can solve a lot of security issues. Thank you very much. I really enjoyed this. Thank you.