 All right, so we're going to be talking beyond the basics here. It's about 9.01. We're going to go ahead and get started. So we're going to be talking about building security into your development projects. So about me, I'm Logan Kip. I am the lead security analyst at SiteLock, a website security company, an assortment of different things. We have a booth set up. You'll be able to visit and learn more about that as we go throughout the conference. We've got three general subjects I'm going to cover, and then I'm going to pass the microphone on over to my colleague, Benode, who will introduce himself. So first things first, malware. Who here has had a website under their control hacked? Hey, there we go. There we go. You know how it goes. You know, I actually thought that not so many people would be willing to raise their hands because I know it's a little embarrassing, like, you know, having some medical condition you don't want anyone to know about. But fortunately, information has been spreading like wildfire. People are becoming more aware. And people are becoming more informed about how to identify malware symptoms. So as you've probably seen throughout the wide, wide internet, there are a lot of different defacements that come about. And those are easy to spot, obviously, through their nice bragging pages. Some of them are quite spooky, actually. Hooded figures, skeletons, folks putting masking tape over faces. Scary, right? But I think the scariest malware is the stuff that you don't necessarily see right away. Spooky skeleton. Found this little Easter egg here a couple of months ago. We'll call them Fred. Fred's dead. Then, of course, there's the pharma hacks. Now, the great thing about these is they are also easy to spot, usually motivated by monetary gain, redirection, implementation of poisoned search engine results with the goal of redirecting traffic, most likely to gain revenue. Also directing to rogue pharmacies, which, of course, are a big cash cow for the underground. Then we've got the stuff that doesn't like to show itself. So the impact's about the same. With defacements, when I talk to customers or clients, rather, that have been hacked, they've got defacements. It's usually a pretty quick fix, right? But when we've got something that's hiding, doesn't want to be found, it becomes a little trickier. How do you find it? Well, we've got some suggestions later on. But obviously, this guy, we could pick up through looking for obfuscation. This appears to be base 64. Who's seen base 64 pop up on their site? Yeah, kind of nasty. But not too hard to detect with current malware detection technologies. You can kind of look for that. And there's these guys, dictionary-based. Now, it was a little bit trickier to pick up, right? Doesn't look all that strange. We've got words like Kathleen, Brandon, these are people's names. These are words from dictionaries. You really have to be kind of smart when it comes to detecting these guys. So for example, we found this. We do malware remediation. We found this one through file change monitoring. So one thing you could implement is, of course, file change monitoring. Because these little guys have popped up. They don't belong. But I'm going to show you a couple real-world examples. The first of which is an example of cross-site scripting. Cross-site scripting is a type of computer security vulnerability typically found in web applications. Cross-site scripting, or XSS, enables attackers to inject client-side scripts into websites viewed by other users. I won't go too in-depth through to the time restraints here, but there's a few different kinds there that we can talk about a little more if you catch me at the booth. So I'm going to go through an example here that was picked up by our research team. Gentleman named Weston Henry has picked up, through a routine scan, a potential cross-site scripting vulnerability. I'm not sure how well you can see this, but in this red box here, we've got a variable set called curr. I assume that means current. It's referencing some settings. This is taken from a plug-in. We've kind of removed any references to the plug-in because the goal of this isn't to call anyone out, of course. In this case, Weston did contact the plug-in developer, and this has been patched. So it's safe at this time. So we looked at settings.php, the argument current. Looks like it's just echoing straight variable contents without any type of filtering. All right. What's behind current or curr? So we found curr at lines 195 and 196. It's set to default if CNTR is empty or if the value of CNTR is not, or the value of CNTR if it is set, which is set at lines 91 and 92. And we can see it's actually passing in the value of a get variable, which is kind of dangerous if you're not doing any kind of filtering. So if get as counter is set inherits the value. So this is the kind of thing we're looking for when we're looking for cross-site scripting vulnerability. This is an outside bit of data that's being passed into the system. That's kind of dangerous. Well, could this be a reflective cross-site scripting vulnerability? Let's find out. So if we actually set the value of that to just some proof of concept, what we generally use is a nice little document cookie alert that's most visually pleasing and it's harmless. This is session-based, so this will impact only you and not anyone else that's currently on the website. So for example, if I pass in the following string here, the page slider settings as counter script alert, what we should expect to see is a pop-up, a little pop-up screen if this is in fact vulnerable. Well, let's see what happens. Sure enough. So this was a slider, and this isn't the slider you think it is. This is actually post-soak-soak. So this is something that's new. This is something that's still happening. Folks just accidentally integrate these things into their plugins, which in turn are downloaded. This is a top 1,000 plugin, so it was rather important that we found it. One thing you can do to block these as well in case you do accidentally introduce this into the environment is utilize a web application firewall, those real-time monitoring systems that are actually looking at the data that's being passed to your server. So a modern web application firewall, such as this one we're using here, is able to block this. You can use that data to figure out how people are targeting your website. So not only is it a good defense mechanism, it also helps you with your research on how to better secure your website by learning how folks are targeting you. Second example here is one presented by another one of our researchers, Mr. Gregory Bloom. We're going to call this Tango. Again, we're not calling anyone out, so we just want to educate folks. This is a really cool plugin, one that I loved using. It allows you to view and edit files on your server, zip and unzip. You could manage your database. A lot of cool features if you're not too adept at doing these things yourself. Looks something like this when you're using it. Nice little file monitoring or file management screen down at the bottom. There's some more options, database backup and restore, way cool. This particular plugin, it does require authentication. If you're not logged into WP Admin, well then you're not going to get access to it. You get this little screen, good. The plugin consists of four files, error log, file manager, index and readme. As I'd open this up here, well that's curious. If you all can see here, the authentication along with everything else relies on a very early if statement. If file exists, readme.txt. So it's not actually doing a whole lot if that file's not there, right? So what happens if we say rename that file? Call it readme1.txt, we get access. Now one of the options down at the bottom there is actually shell access. So when we get access to this plugin by accidentally renaming readme, who here removes readme files when they upload a plugin? There we got a few people. I do, I don't like them there. I don't need to read it, I've already read it. So I go and I remove readme because I don't want cluttering up my file system, the file structure and I have accidentally given someone backdoor access. Well, just what can we do? Like I said, this does give shell access. I can pop open the WP config, I have access to the database there directly. Hopefully they've got remote management set up. I can LS route and take a look. I can even cat etsy password. I can get all their usernames, so the passwords are going to be hashed. But you can do a lot of fun stuff there too. We can grab external files to deliver a malware payload, a command control module. We can make this a botnet master. We can dump the entire file structure or if anyone knows what this little string at the bottom is, we can certainly trash the entire system. So this writes random data to your SDA. That's bad, if you want to wear. So that'll go ahead and cause you a bad day. So that's the Tango plugin. And here's our friend, he's never going to give you up. So the moral of the story is it's very easy to accidentally integrate some very problematic security flaws into your environment. So my colleague's going to be talking a little bit about how to integrate security into your development life cycle. In order to assure that you're not doing this. Thanks Logan. So, Logan's explained what malware looks like, what vulnerabilities look like. Why should he care about having malware? Simply because it leads to a loss of reputation or loss of revenue, often both. There's no upside to having malware, none. So how does malware get update? Does Logan show you that there are vulnerabilities that exist in code and that could be a way that people put malware on your site? So it's simple, if I don't have any vulnerabilities in my code, no malware gets on there. Or I reduce the incidence of malware on my site. So it could be a technical problem. It could just be, I just need to make sure that all my code is bullet proof, and that would solve the problem. Unfortunately, that's not what we found. We found that the reason you have vulnerabilities in your code, the main reason you have vulnerabilities in your code is complexity. Okay? Anybody here with children? I have a two-year-old. So when we brought her home, we said, man, my life just got a whole lot more complex, right? And she started crawling, more complexity. She started walking and reaching up to stuff, more complexity. Now she talks, right? Even more complex. So complexity is inherent in anything to do with human endeavor. And over time, the complexity builds. Things just get more and more and more complex, right? So you start off with a simple HTML page. All you have is a little bit of HTML talking about your restaurant business. Over time, you're gonna find that you need more. You need an ordering system. You've decided that you're going to get cupcakes from here to 50 miles from here within 20 minutes, right? And you start adding to your website. You use a framework, you use themes, components, plugins, etc. What's that done to your code base? You've got a huge number of files now in your code base. That's running your website, right? Have you checked all the code to see if there are any vulnerabilities in there? Is it possible? Maybe you could. Maybe for version one of your website, you spend two weeks checking out all the vulnerabilities and code. And you're convinced that there's no vulnerability here. Nobody can SQL inject you, nobody can use cross-site scripting. Nobody can use any of the other OASP top ten things. You're pretty happy. Two weeks later, there's a new release. Six weeks later, there's a new release. Eight weeks later, there's yet another release of the same plugin. How often are you gonna go back and check that code? It becomes difficult to do that because you're also trying to get a cupcake 50 miles from here within 20 minutes, right? There are people here who are freelance consultants, yeah. So what happens when your client who actually owns a bakery calls you and says my website's hacked? How long does it take you to find the problem? So let's say it takes you two hours to fix the problem. Where do you spend an hour and 45 minutes finding the problem, right? Once you find the problem, the solution is pretty trivial. But you spend most of your time trying to find the problem. That's where the issue is, right? So what can we do about that? We know the complexity is gonna grow, and we know that the more complex code is, the more likely you are to find vulnerabilities in it, the more likely that malware is gonna end up on it. The other thing that makes things more complicated is that attackers are increasing the complexity of their attack. So things that were secure until last month may not be secure next month. What are you going to do about that? How would you find a way to keep checking on the vulnerability of your code or to keep protecting your code in the face of escalating complexity on the hacker side? One thing you could do is use a web application firewall. So Logan touched on a web application firewall. That's sitting between the internet and your website. It's observing the behavior of visits to your website. And it's smart enough to understand that this visit is from a hacker or this visit has a malicious intent and it blocks that request, right? So it's one thing you could do. The other thing you could do is write slightly more secure code and check how secure your code is on a periodic basis. So to demonstrate this, we actually wrote a plugin. We call it myplugin, right? And we deliberately left a vulnerability in the code. I don't know if that displays sharp enough for you to see this. Can you see where we haven't escaped or sanitized that input? So as Logan pointed out earlier, there's a chance for cross-site scripting there. And we uploaded that code into one of our tools. So we have something called a static code analyzer. What it does is it takes a look at all your source code and figures out, is there any vulnerability in here? Can I SQL inject this code? This is white box testing. So we take our code, pass it through this tool. It gives us output saying you've got a problem here, here, here and here. And then it's a lot easier to fix it. So that two hour problem now becomes a 15 minute problem. Because the tool is going to tell me where the problem is. And then I just need to fix it. So we ran it through that analysis. And our tool told us that we've got a couple problems. One is cross-site scripting, one is SQL injection. And then we went deeper into it. And we found the exact line of code where the problem starts. So down below there, what you're seeing is a call stack, right? On the left are the files in your project. Down below is the call stack. When you click on a file in the call stack, it highlights a line where the vulnerability was either introduced or keeps passing through the problem. So we found the issue, and then we fixed it. WordPress has a number of really good sanitizing functions. So escape HTML is one of those things that you would use. So we used that function from within WordPress. We removed the vulnerability, and then we ran the tool again. There are a number of security-related sanitizing functions within WordPress. You should always use them. Here's about three of those. If you go to the WordPress site, you'll see a bunch more. So escape HTML, sanitize text field, update option. These are good WordPress functions to use. After we used that, we ran that scan again. And this time we said we found that we'd come out with 100. So we're secure, we're fine with this code. The point of the story is that it's hard for human beings to go through tens of thousands of lines of code to find vulnerabilities. But it's pretty trivial for software to do that, right? What you get out of this is software that's consistently finding the problems in your code before it gets pushed. It may not be your code, it could be code that you inherited or you got because you're using a plugin or a theme or something. Which brings us to the SDLT part of it. Everybody uses some software development life cycle, right? You don't have to be a Fortune 500 company to have one. It could be as simple as this, I'm going to write code, I'm going to test. Did I find any bugs? Yes, I'm going to write more code, I'm going to test again, and then I'm going to publish. There's another version of this SDLT which is just I'm going to write code, I'm going to publish, but we'll skip that one. This we call this the insecure SDLT because all you've done here is you've tested for functionality. Does it do what I intended my site to do? When you introduce security into this SDLT, you just add one little gray box. And I don't know if it's popping enough on that screen, but you see the box on the lower right hand corner? You're writing code, you're testing. Assuming you don't find any bugs, you review your code for vulnerabilities. And we highly recommend you automate that process. So our tool is called TrueCode, and there are a number of tools out there. It doesn't matter so much whose tool you use as that you use a tool. That's going to save you a lot of time, and it's going to save you a lot of hard burn. Did you find any vulnerabilities? If you did, go back, write more code, go through your test cycle, again review for vulnerabilities. If you didn't find any, then you go into your pen testing stage. This is another thing we do with our software. Before we make a big push to production, we involve a third party. It's not that we don't have folks in our group who can do the penetration testing. But it's usually better to involve somebody other than the developer when you do pen testing. There's people who do it full time, professionally, they do it for a living. Get somebody to pen test your code. Even if you don't do the pen testing, at least do the code review for vulnerabilities, right? Once all that turns out clean, you publish. Once you take these two steps, your insecure SDLT now becomes a secure SDLT. Any questions? Penetration testing, so what happens is in the case of our static code analyzer, that's white box testing. So we're giving this piece of software all our source code and saying you analyze this and tell us where the problems could be. Penetration test is black box testing where you say, you're a person who understands how to break security. You're a person who understands how to get into websites. You could be a hacker if you wanted to, but you've chosen not to be. So that person kind of hacks your website. They'll get a get out of jail, free card from you and then go hack your site. And they tell you these are the ways I was able to get in. Yep, ours is called TrueCode. TrueCode, you got a bunch of people looking to Yeah, stop by our booth. We've got a bunch of people who can tell you all about it and get you set up. Yes, we dog food, yeah, any other questions? I'm sorry, yeah, you can do multiple files. You can just tell us where your doc route is. And then we'll give us FTP credentials and we'll pull down your entire doc route. And then we examine as a project. So if we take the PHP, we put it through a compilation process. We examine it as a project and we tell you, okay, here are all the vulnerabilities that you have in your code. Yeah, it's mainly based on complexity. So we're finding things get more and more complex. So eight years ago when we first started out, the malware we found was pretty simple. Now the attacks are getting much more sophisticated. As Logan mentioned, and Logan, jump in whenever you want. As Logan mentioned, there are more and more things that people will put on your website that they don't want you to see. Absolutely, so, I mean, in some of the slides here you saw where I reference, basically people who work with simple authentication used to work to consider the identity of the malware. Well, that's not really going to cut it anymore when we have automated systems like, for example, Sitelock's smart system, just picks it right up. So they go a little bit more complex. This is these dictionary based named variables, that's pretty tricky to pick up. Well, thank goodness we're also taking a look at file changes. Thank goodness we're notifying someone that, hey, this changed. That's a core file, should that have changed? The trends we're seeing right now are that strangely enough, folks seem to be targeting sliders, though that's just the weekly trend. It does change week by week, it doesn't seem to be any rhyme or reason. Around the holidays, you usually see a pretty big uptick in pharmacy based tax, which are usually the more complex tax because they usually have more funding and therefore usually better programmers. This last season wasn't such an uptick, though, luckily. Sufficient, but not necessary. I mean, if you have a simple code base, did you say that it's just as important that you are working with a simple code base? How simple is your code base? How many lines of code do you have? How many files do you use? Could be a few thousand lines of code. Did you write them all yourself? Well, then it's likely that you have less complexity in your code. But it'll tend to grow, and even if your code is not that complex. In our example plugin, for example, in our sample plugin, it wasn't very complex, but we introduced a cross-site scripting vulnerability. And we actually also introduced a SQL injection vulnerability. It was on purpose, but it was there. So it's just, once your code becomes complex, once your code base becomes large, then it's really difficult for you to keep on top of it manually. It depends on the product we're referring to. For static analysis, we support PHP, JavaScript, some Java. And I don't find good software, besides the regular tools, to find those that may be sitting around me in my SQL server, I'm afraid. And maybe my knowledge isn't there yet, but is it possible that I have my malware sitting on my SQL and malware that I have sitting somewhere else on my server that's not in the government domain? That's not in the government domain? Absolutely, and we see that fairly frequently. Can I repeat something? Yes, so he had asked whether it's possible for the malware to live outside of the WWW, the dock route, which is sometimes called public HTML as well, or even in the MySQL database. Absolutely, we do see that. Obviously, I don't know if it's possible until it's called by your front-end scripts. But yeah, we do see that, not as frequently as, say, PHP or JavaScript-based malware. But what you can do, that's why it's also important not just to do your file-based testing. Another approach we take is an outside-in approach, doing an external malware scan as a crawler. That's going to display the actual malware that's not in the government domain. If the malware wants to have the ability to take action, it needs to be delivered to the end user. So we're going to see it with that crawling-based method. If malware were to exist, say, higher up in the directory, it's kind of a case-by-case basis. We do see that. It's not very common. Usually, they're focusing on command and control of the website. So we do see that. We do see that. Usually, they're focusing on command and control of the website. But if we do see something higher up, well, that's definitely something we'd have to look up on a key. Yeah? Well, it's got to get in somehow, right? So we'd like to emphasize it's not just WordPress. It's your website. So there are shell scripts that could exist on your website. Providing that functionality that Logan was just referring to, so that somebody could take over your server remotely. But typically, they'll want to put malware somewhere where they can leverage it. I mean, if it's a part of your directory structure that is just not accessible at all, or is not accessed by anything on your operating system at all, there wouldn't be much point. So that's typically why we started up there. Public issue, yes? It is the crawler, actually, is not what we would typically detect that with. That would usually be our smart module. That is the file-based cleaning and detection system. That is going to find those impersonations. Usually, you can look for top brands and so on. There's actually quite the complex logic behind it. With phishing pages, it's a little trickier. And outside-in scans are not going to be the best approach because we might not see it by crawling the website. It could be something hidden away deep in some sub-directory. That's why the file-based method is used in tandem. So the best route is, well, we're looking for those names, first of all. If someone's impersonating a major bank, well, it's probably going to pop up. Why does Sally's Cupcake website have a login page for Chase Bank? That's an easy example, right? But it does become more complex, and it's a challenge every time, but that's why we have a full-time research staff because there is something new every day and maybe something we didn't pick up yesterday. We're most likely going to pick it up today if we were able to see it and analyze it. What you might consider a false positive? So the question is, what if our tool identifies something as a vulnerability or as malware, but it's not? You can write this. You can say that this is not a vulnerable piece of code because of this reason. You can identify sanitizing functions that you've written yourself, and we see that, oh, that call is eventually passing through the custom sanitization function, so it's not vulnerable anymore. We have a boot set up. Please stop by. We'll be happy to answer those questions. Anything else? The picture you saw up there was a very simplified version of what we do internally. There are several large models for SDLC. There's Waterfall, which says, wait till the end and then do everything. Not very much in favor these days unless you're NASA. There's a more agile methodology. You can do the testing as often as you like, so it helps. The more often you test. What we do is, if you're referring to our product, when we find malware, we actually remove it. If you're getting repeated malware infections in the same place, Logan, you want to take that? Absolutely. We see it a lot. This will probably have to be our last question we were out of time. We do see reinfection a lot if you haven't put countermeasures in place. You actually have much more likely to be reinfected once infected because you've been identified as a soft target. There could be lingering malware, or they could simply be reusing the same door they used before, the existing vulnerability that you haven't found. By integrating this SDLC, for example, with SAST white box testing, you would actually stand a much better chance of identifying the original vulnerability that let them in. We'd have to look at this particular case, of course, but most likely they're probably just hopping right back in the same door that they found before. The permissions? You want to get it out? Yeah, definitely want to get that cancer out. Absolutely. We are out of time. If you have the boots, if you have no questions, if you want to chat about more about any of the stuff, please stop by. We'd be happy to talk to you. We have t-shirts.