 Hi, everyone. Thanks for joining us today. We're talking today with Metal Toad, Nathan Wilkerson, about securing Drupal and the tools to test it. Just a little bit about the Drupal Association. The Drupal Association's mission is to foster and support the Drupal community so we can collaborate together as we innovate the project. There are so many ways to help the community. We host Drupal.org and are building a tech team to improve the site. We provide grants for community members to fund ways to grow their community in the future of the project. Some of these grants are used for camps. Some of them are using the grant for a multi-city roadshow, evangelizing Drupal. We also host DrupalCon. We just had one in Austin, which brings thousands together to work on the project and bond as a community. We also provide scholarships to help community members from around the globe attend the event. And all of this is funded through our membership, our Drupalcons and our partners, just like Metal Toad. Next slide, please. Just some upcoming events. We have our next DrupalCon in Europe coming up at the end of September, beginning of October. We also have Global Training Days, which is a really fantastic program for training companies or community members that are interested in providing training to brand new Drupal students. So an introduction to Drupal, just growing the community globally and locally and providing low-cost or free Drupal training to our community members. You can find more information on the link below. And then our next webinar is July 15th. Magic Logic presents different approaches to developing Drupal websites. You can also see at the bottom for our webinars link that we are always putting on new webinars as well as recording all of our old webinars. So it's a great resource for you or any of your colleagues that are interested in learning more about Drupal from our supporting partners. Next slide. Great, thank you. And of course we have to mention our Supporting Partner Program. Metal Toad is a supporting partner and they help us do things for the community and help foster the project as well. So a big thank you to our supporting partners, especially Metal Toad and for doing our presentation today on Drupal Security. Next slide. Great, without further ado, this is Nathan from Metal Toad. He will be taking over the reins. Like I said, if you have any questions for Nathan, please use the Q&A window and I will interject as I can. Nathan, it's all you now. Thank you very much. Good morning to everyone who's joining us today. I'm Nathan Wilkerson, a little bit of background before we go on to today's presentation. Prior to my tenure here at Metal Toad, I was a network administrator where my tasks included numerous things, including hardware, security, network security, server security, PC and wireless network security. I started here and not long after we moved from web hosting to designing custom cloud environments and we brought up doing a security test package here. And that led me into application security and I just dove into it and it's been a passion of mine ever since. The basic security stack has three different groups. Your physical security is protecting your IT infrastructure locations. This is relatively simple to do. It's as easy as putting a lock on the door, either with a key or biometric or key card. Network security includes everything coming over the network. Most common practices involve firewalls, access control lists, encryption for wireless networks and that type of stuff. Those security threats are pretty straightforward and easy to do because they involve keeping people out of restricted parts of your infrastructure. Application security I find is always a little trickier because you can't just keep people out of the application. They actually have to be able to use it. And this makes finding the specific threats and vulnerabilities in your application much more important. Drupal has a great security team and they work to coordinate security issues and advisories. They produce documents on how to write secure code and documentation. But as you can see on this quote from their website, they generally don't check for security vulnerabilities in code that is contributed. They just coordinate the reports of bugs with the module developers to fix them. Here's a list of some of the common security threats found in Drupal. It's kind of hard to find a list of them because they're not well publicized. There's about two lists you'll find online. The main ones are cross-site scripting attacks, SQL injection and cross-site request forgery. We're not going to go into it too much about them right now. I just want you to see them and know what they are and we'll compare them to another list later. The other security organization I wanted to make sure to introduce is the Open Web Application Security Project or OWASP. It's an organization that is devoted to promoting best practice in web applications. To reach their goal they are promoting several tools, training best practices that go along with their security. One of the great things they do is they publish a top 10 threats facing the internet every year. The list shown now is the 2013 top 10 threats. When we compare them to threats facing Drupal we see overlapping results in red. As you can see these are threats that don't face Drupal but they face a lot of different web applications. And so it's very good to be able to know how to detect them and how to fix them. Luckily Drupal provides some great functions that if we use them correctly with best practice can prevent most of these threats. These functions will take a user's input, sanitize, check it before passing it on to the server to be used. So we all know now Drupal can fix these problems. If we follow the best practice we just need to be able to find the vulnerabilities so that we can get them fixed, patched and out to the user. So there are three tools that I found very helpful while starting to do some research into security. The first one here is Cali Linux Distribution. It's a distribution that comes with dozens of security testing tools. Including the other two I have listed here, OWASP, ZAP and Metasploit. It can come on a boot disk or be installed along the USB. It also has an EC2 AMI so you can spin up test servers quickly if you wanted to test out a bunch of tools. Metasploit is a tool that allows you to test servers for vulnerabilities. Known vulnerabilities are submitted and can be run against a server to see if the server has the vulnerabilities. The application works best for testing server OS patches and applications like Apache and MySQL patches to make sure they're present. The final tool is OWASP ZAP. It's a Zet Attack proxy that can be used to launch attacks, manually check sites, debug applications and used for continuous integration testing. It also has other great features that can be used in this like scripting, automated reports, stuff like that. There are a lot of great videos out there on ZAP. Just search for YouTube or their website. But I wanted to show you some of the basic features you can use now to start testing. Then you can go out and find more information if you need it. One thing that I found hard to find was the settings. By default, the scanner set will only find five requests to a server at a time. This is very slow for most setups and can lead to extended testing times. You would simply click the gear as you see on the toolbar right there. It's the same that's now on most Google applications. Then under the active scan, you can increase the bar to whatever fits your environment. It's not very heavy. I ran 20 connections against a local server with no problems of timed out requests or anything. Take some time to look at the other settings on the left. Spyder and Fuzzer have similar settings. And I believe there might have been others as well, but those are the three main ones you'll want to check. The most basic attack you'll need to do with this is an active scan. It's quick to start, but can take quite a while to finish. When you open the program, you'll see this Welcome Does It Attack Proxy screen. All you need to do is enter the URL you'd like to attack and press attack. You can see some of the results on the bottom of the screen starting to populate because it crawls your site finding all possible URLs before it runs the attack. The other good thing to note about the automated attack is it only stays in the domain you've specified by default. So if you have links to advertisements or your site redirects and it might redirect to production environment, it will recognize the domain change and it will just flag it as an out of scope URL and not check it. Once the spider is done, you can go to the active scan tab and see the request it is using. The table is great. It gives you the URLs. It's checking speed, size, and there'll be a flag on the right-hand side if there's any problems. Not only that, but you can click on a request that's been flagged here. See the HTTP request that was actually sent and the response. Then you can manually inspect it and see what exactly happened. As I first mentioned, performing a full attack can take several hours or days, depending on the size of the environment. In one instance, I ran it on a local dev for over 16 hours and it was still on the first phase of the attack. If you want to run a site, a test on a site or a specific feature, you can simply right-click on any one of the scan sites under the spider and do attack just on that one. It greatly increases it while allowing you to target specific aspects of your site. Active attacks are great, but they don't let you target the specific stuff you want to. To target, for this, you'll need to use a passive scan. It's very simple to set up. All you need to do is set up your browser as a proxy. So for a Mac, you just go to your settings, set up your proxy to localhost on port 8080. As soon as you do that, you'll start seeing other sites appear in a wasp. Because it picks up all web traffic, it's best to turn off all unneeded tabs and web browsers while this is going on. Otherwise, your reports will get very cluttered and it'll be harder to find stuff. One of the best aspects of the passive attack is it allows you to set breakpoints in the proxy. If you simply press the red X, you can enter a string based on URL, headers, or other criteria. And whenever the wasps app sees that, it'll freeze the response or the request before it gets sent to the server. You can then click on it, look at all the content being sent to the server, evaluate it, or change it. Then you can press the next button or play button to step through or submit the request automatically. The other really nice thing this allows you to do is to fuzz a certain field to test for cross-site scripting attacks and SQL injection. The active attack does this automatically as it detects a field as part of its attack. But like I said, that takes a while and fuzzing specific fields that are new to a form is often better to test that function instead of spending days testing everything over again. So to perform a fuzz attack against a specific field, all you need to do is look at any request you've sent, or you can start a new request by clicking on it with a breakpoint. Right-click on any of the fields you saw in the request, select the fuzz option, select the fuzz category or type of attack you want to perform. In here you see I'm doing an SQL injection. And then you pick the fuzzer attack and these are a predefined list of attacks. There's a lot of different options you can find out there for different new ones. Then you click fuzz and your fuzzer tab will automatically start populating with its attacks and the results of the attacks and what it was sent in the string. After you've been doing some passive or active attacks, you will start seeing alerts. A lot of them are header problems that they recommend fixing but are pretty low. But it's always good to be able to see what you're looking at when you see one. So you can click on the alerts tab. There's also flags in the bottom left corner of the screen showing you the rough counts so you know if there's anything critical popping up. This allows you to dig into a request. As you can see here on the screen there's the description solution and reference tabs. That gives you that information but if you actually clicked on it, you could actually see the request that went and the response it got. So once again you can dig into it, see what's causing the problem, know if it's a false positive and then correct the problem if it's not. So scheduling these can be very time consuming and they can fall by the wayside doing them on a tight timeline because of the time they take to do this in part. One of the best ways I found to avoid that is to try to integrate it into a continuous integration plan. The best way to do this is if you already have one, setting Zap up as a proxy while you're testing will allow you to see the results as they come through your test. It'll check for the headers and bad fields and other problems like that. Here at MetalTode we use B-hat test and this works great with it. It just intercepts all the data and checks it. It also allows you then to see what is found important on your site and check those specific URLs for the problems as opposed to scanning the whole site over and over again. With the reporting and saving options, this also allows you to see the changes over time on your site. So you can see the URLs grow or change and the fields grow and change and the security of your site as you make changes to it over time. I started looking at security because it was an important new service we were offering at MetalTode. But the more I looked into it, the more it becomes apparent that everyone on a project should be concerned with security. Developers should not only write secure code, but these tools allow them to debug their code more efficiently by seeing what's being sent and not having to put in code into their code to check for variables and stuff. For QA it allows you to script in many languages on the back side. It even has its own language for writing your own automated test if you don't have a system already set up. These tests are great for being able to reproduce errors and enhance your developer so they can see the problems that are actually happening, see the bad headers, see the cross-site scripting vulnerabilities, that type of stuff. For DevOps, it allows security analysis and testing, finding vulnerabilities before an attacker does so that you can secure your sites for your clients. It also allows us to quickly debug sites when clients are having problems or seeing different headers that we expect to see. It's because of this that we should adopt a more security-oriented culture of what we develop code, either open source or otherwise for your companies. It's a great way to... the open source culture, sorry, the security culture is a great way to promote security on the web as a whole so that we don't have things like Heartbleed coming up all the time. We don't have to worry about the NSA. We're making sure everything's out there secure and other people can't see it. Anyone have any questions that we haven't covered so far? Nathan, how do you feel like the security process works? What kind of timeline are you looking at for a developer to use some of these tools? For the developer, it would be more of a line of not specifically testing your product but if you left it on as a proxy in the background while you're going through and doing your development work, it would pull red flags to the surface and it would also allow you to debug it a little faster. So if there's an obvious problem, it'll detect it and let you know right away as opposed to having to go back and retest it later. And where can you do some further research on how to enable these tools? The OWASP ZAP website is a great source. There's also dozens and dozens of YouTube videos about how to use... their program. Cali's Linux has YouTube videos and so does Metasploit as well. Perfect. I do have a question. When used as a CI function, does ZAP add a significant time lag? No, it does not. We've tested it here on a couple of sites. We haven't integrated it to our process 100% yet. It took a few more seconds to run tests that take a half hour or so so you might look at another minute or so on the testing. Great. Thank you. Any other questions? We have another one. When running ZAP, will it affect the overall performance of the site or server? If you're running it on the same server you're testing, it can cause a significant load on the CPUs. At that point, if you're running on a different server, it depends on how many active connections you're running. Obviously, if you're running 40 or 50 active connections against the server that only has 20 or 30 processes available, it's going to start tying up all your processes and cause a performance problem. But if it's on a server with a lot of available processes, it might slow it down a little as it processes more intensive CPU requests, but nothing significant. Any other questions from our audience? Well, you answered everything, Nathan. We don't even have any questions. That's awesome. Everyone seems to have liked it in our comments, so great. Thank you guys for listening today. Next slide, Nathan, please. Just a reminder of some of our upcoming events. We mentioned at the beginning of the webinar, we have Trupulcon Amsterdam coming up. We have that information listed below on our website, Amsterdam2014.trupul.org, and we look forward to a lot of really great conversations with speakers and information coming your way about the latest Trupul things. We also have Trupul Global Training Days coming up. You can learn more about that. We've had a wonderful, overwhelming group of participants this year, and I know that we'll continue to grow our Trupul community by providing Trupul intro classes for our local communities and global community. Our next webinar, as a reminder, is July 15th. MagicLogic is presenting different approaches to developing Trupul websites, and you can see all of that information on association.trupul.org, and we'll have a list of previously recorded webinars, including this one in a couple days. Next slide, please. Great, and just as a reminder, look at our Trupul Association organization and individual memberships. They really help us as well as supporting partners and technology partners to foster the project, help us fund more scholarship and grants and servers, and, of course, add back to the community and really grow the Trupul project. So take a look at that and see if that's something that you're interested in or your organization is interested in as well. So it looks like we don't have...