Our website uses cookies, which help us to improve our site and enables us to deliver the best possible service and customer experience. By clicking accept you are agreeing to our cookie policy.

How Websites Get Hacked

Tony Perez - Sucuri Co Founder and CEO • Aired April 28 ,2016

Join Sucuri for our April webinar discussing How Websites Get Hacked. Last month we learned the various impacts of a website compromise. This month, Tony will go in depth into the tactics attackers employ to compromise websites. Understanding the HOW allows us to think about the areas that are most important to us, and implement security controls to help mitigate our risk potential.

Tony is the Co-Founder & CEO at Sucuri. His passion lies in educating and bringing awareness about online threats to business owners. His passions revolve around understanding the psychology of bad actors, the impacts and havoc hacks have on website owners, and thinking through the evolution of attacks.

Questions & Answers

Besides brute force attacks on access control, we see some compromises by actors that obtains real credentials to the site via other means (keyloggers or password dumps from other sites where users have the same u/p). How to address that?

Yes, this is something we discussed in the presentation. Some attackers do have large data stores of username / password combinations they’ve purchased or stolen. The best mechanism to address this is to employ things like IP whitelisting (if possible, but can be achieved by restricting access to a VPN) or by enabling some form of MultiFactor authentication.

If you ever feel your password was part of a previous data breach, then it’s advised you change them immediately. I’d also advise leveraging things like Password Managers, and generating unique passwords for as many accounts as possible. Your goal is to not know any password. It’s harder than it seems.. :)

If I give each domain on my server an individual user permissions will that stop cross domain hacking on a server box?

It will come down to how the server is configured, but in many instances it will stop the crosssite contamination, as long as the user doesn’t have root access to the box, or doesn’t find some form of privilege escalation vulnerability.

Are there known host providers that are more susceptible than others?

A lot of the hosts that are not real hosts, but are services offered as its own revenue stream are the most susceptible.

Transcription

Tony Perez

Hey guys, how's it going? Thank you so much for joining us again for our second installation of website security webinars. Today, I want to take some time to talk about how websites get hacked. A little bit about myself, as I mentioned, my name is Tony Perez. I'm one of the Co-Founders and CEO here at Sucuri. I work in connection with my partner Daniel, who is the technical visionary here and our CTO, and kind of dictates a lot of what we do and how we build things. Him and the Technical Team kind of spend day in, day out working with our customers, and working with communities around the world on various technologies, trying to understand what's happening, how are they happening.

Then our [inaudible 00:00:43] side and our Marketing side, we're responsible for trying to convey that in a way that's absorbable. To do that, we've set up these webinars. This webinar specifically, we're going to talk about how these attacks are [inaudible 00:00:54], and at least what we believe to be the cause of them based on our research. This talk is going to be for those that maybe are currently infected, maybe those that have been infected. They always have the same kind of question, the burning question in their mind of, "How did this happen? I don't understand. Why did this happen to me?"

We won't get into so much in the "Why," but we'll get into the "How," and try to better understand how attackers function. Then understanding how they function actually helps us prepare and improve our own security posture. At least, that's our belief. With that, for those that joined us last time, this might be a little bit of a review. Our last conversation we had, we talked about the impacts of compromises. Specifically, what that means to us as an organization, or as website owners, and things that we should be on the lookout for. We talked about seven main infection types, or actions that an attacker may take once they've successfully compromised your environment.

Things like malware distribution is probably the number one thing. Distribute malware, drive-by downloads, hidden trojans, things like that try to affect the audience. Try to affect the people that are coming to you. We also talked a lot about search engine poisoning, and the effects of that. Especially as more businesses go online that are heavily reliant on their web sites. SEO is very, very important, and sub attacks are one mechanism that attackers use to abuse that. We also kind of started to flirt a little bit with things like phishing lures, and ransomware, and defacements. If you haven't, I encourage you to go back and take a look at our previous webinar, because we go into these a little bit more in-depth.

The whole object was to help you understand why we need to be looking at security, and why there's so much conversation, and what can attackers do. We also talked specifically about the impacts, and we divided them into two distinct groups. We talked about the business implications of them - so what does that mean to your brand? We also talked about the economic impacts of that. What happens if your website goes down, and now you are no longer able to generate revenue, or lead generation, or something along those lines? Then of course, the overall emotional distress. The attachment we have with our online properties, and what happens when we no longer have that access.

We then move into the technical side. What happens when ... What are we talking about when we talk about website blacklist? What does that really mean to various service providers out there? We talked about of course the SEO impact, and the impact to your visitors. Obviously, these are very high-level impacts, but these are perhaps what I feel, and what we feel, to be the top six issues that website owners are faced with. This is all really, really, interesting, right? "Okay, now we understand what they can do, but they didn't answer the 'How.'" We didn't answer specifically on the hacks themselves, and so that's what we want to do here in this conversation.

Today, there are about a little bit over a billion websites in the market, as of last night's check, and continuing to grow. As technology continued to expand, and the proliferation of technology and open source CMSs, we're seeing this evolution. Of that one billion-plus websites, we see about 33% of them are powered by CMS website. That's a pretty impressive number, and growing dramatically, as these open source technologies continue to kind of change the landscape of website development, and business development, and pushing online presences. 73% of those 33% are made up of these four CMSs - WordPress, Drupal, Joomla, and Magento. That continues to grow as they continue to evolve, and develop, and expand their exposure.

The challenge I normally see when I'm talking to website owners, however, is that we think in singularities. We think, "Oh, okay, I'm running WordPress," or, "I'm at running Joomla, and that's my specific domain." The thing that is the environment is a lot more complex than that. When we talk about the CMS itself, it's but one piece of a much ... it's one cog in a wheel. Our attack surface is actually a lot larger than this. When we talk about the applications themselves - the WordPresses, Joomlas - the application has other environments. We have things like administrative tunnels. We have other applications on the server itself that aren't part of the website, but still count as part of our attack surface. That's just within our one domain of applications.

We have multiple domains, and I break it out into four distinct ones when talking specifically to website owners. A lot of people don't pay a lot of attention to the environmental considerations, or environmental domain. What's going on in your local machine? Do you have desktops? There are trojans out there designed to scrape information from your local environment. Things like credentials to your financial solutions, to your social media outlets, to your websites. They're designed to look for those things. One very easy way of doing that are the trojans that target specifically your FTP clients, for instance. A lot of folks will say they're using a new password in the domains within their FTP clients. Most trojans are designed to identify them. Identifying who the host is, identify what the website is, username and password, send that off to a CNC.

With things like public Wi-Fi, man-in-the-middle attacks. Working in a public location like airports, things like that. It's kind of why we see this proliferation of ACTPS. Security communication between Point A and Point B. Then we also talk about things on the server side. Things like the OS on the server. Things like the programming languages, or the server daemons. FTP, SFTP, things like that. All those are considerations. Then there's of course is the infrastructure. Now I would be remiss if I didn't say that on the infrastructure side, or just across the surface, there are certain things that you are responsible for as a website owner. Then, there are things that your service providers are responsible for.

The key here is that there is a responsibility shared between yourself and your website. It's not one of those things ... It's contrary to what you might hear, "Oh, it's a quick install, plug-and-play. Just configure it, deploy it, and you're set." It's the complete opposite. Actually, we do ourselves a disservice when we say that, because it's not a matter of just deploying it. We have to sustain it, we have to maintain it, we have to continue to look at things like security, and make it part of our discussions. When we look at the domain specifically, here's a little bit more detailed breakdown. On the environmental side, we're looking at things like public Wi-Fi like I mentioned, on insecure networks.

Even at home, or in trusted networks like in our office. You have your end users around poor administration and maintenance. End users are a critical piece to your overall security posture, and yet we rarely look at ourselves and say, "Okay, what are we doing to ensure that we don't get hot? How are we addressing this?" On the application side, of course you have the CMS, but you also have all the non-CMS applications. You also have the custom applications that still have the same vulnerabilities, and maybe play into targeted base attacks, more than opportunistic base attacks. There's still things we have to consider on the server side. If we're running VPSs or dedicated environments, we're responsible for those operating systems. We're responsible for the programming language of the daemons we have enabled.

If we're on a shared host, maybe some of the responsibility is on your host. We have to have that conversation with the host to say, "Hey, what are you running, and is a current?" "What is your mechanisms in place to ensure that you're staying current and evolving as these patches are made available? What is that protocol?" It's okay to ask that question. Most of the best hosts out there will have an answer for you and say, "This is our protocol. This is what we do, and this is how we do it." Then of course, we need infrastructure. Leveraging good, trusted sources to ensure they're providing you the right service. I'll talk a little a bit why that's important here in a second.

In security, we have this comment on the security chain. When we look at the website domain, I think, "Okay, the security chain involves all these pieces." What it's supposed to describe, this chain, is that any piece in that ... if you think of a chain, you break one link, the entire chain falls apart. When we think of security, we can't think in terms of singularities. These are not mutually-exclusive environments; these are all interconnected. We think, "Okay, if I'm running a website, regardless of the technology that has been built in a custom manner, you still have to be responsible for the other pieces." Maybe somebody else is. Maybe you're a large enterprise, and you have a Security Operation Center, or a Network Operations Center.

Maybe you are an enterprise of one, and you don't necessarily understand all the different pieces. You need to have a way of asking the questions, "If I'm accessing this environment, this environment's critical for me, how am I doing that?" "Where does this environment sit? Okay, it sits on a host." "What does a host mean?" "What is a host providing me?" "Is it a shared environment versus a VPS?" "What about my host? How is my host addressing security?" A lot of people misunderstand the host relationship in your website. The host is responsible for the security of their network, not necessarily the security of your website, because they hand that off to you. A lot of people don't think about that, or don't have that dialogue. It's all interconnected, and we have to be aware of this.

With this understanding of your environments, let's look specifically at the types of attacks. I like to break them down into two very specific ones, and this isn't something that I've come up with, this is just something that it's known in the security space. In the market that we're in of just generic website security, is you have targeted attacks and you have attacks of opportunity. I hate to break it to folks, but most of us are not special enough to be classified on a targeted attack, and most of us fall into the realm of targets of opportunity. We're the low-hanging fruit. We failed to update. Maybe we run the oldest version of Tim Tom, because we use it for image manipulation, and we still have it on our server. Maybe we don't use it, but we left it on there.

We have this bad tendency to leave these soup kitchen servers, where we throw everything into the kitchen sink, and we just kind of leave it there. "Oh, well I'm not using it." Well it doesn't mean that it's no longer accessible. It's still there. We fall into this realm of targets of opportunity. Scanners going out there, identifying these issues. "Oh, you have it, great. Let me penetrate." On the targeted side, it's very different. It actually happens very rarely, and the motivations are different. There's enough incentive for me to focus on one target and identify how I'm going to penetrate that environment, because the return's bigger.

A classic example of this is an attack of opportunity might be a Mom and Pop running a bakery shop. There's really no incentive other than just happened to be there, and they're running the wrong version of something. A targeted attack might be something like in 2012 when NBC was compromised, and they were distributing both malware and spam on a conditional basis. It was only out for about four hours, but in those four hours, they had the opportunity to infect millions and millions of website owners. It's a really big issue. Skill levels obviously differentiate ... Obviously, it could be around ... It could be competition, it could just be hatred.

You see this a lot in the religious sector. You have a church promoting one thing, and then another religion attacking that church because of that, or a church a attacks somebody. It happens all the time. Well, it happens seldomly relatively speaking, in terms of the scale of attacks we see. On attacks of opportunity, remember that it's [inaudible 00:11:33]. It's the modus operandi for website attacks, is attack as many people as possible for mass exposure, maximum return. If you just happen to be there, you happen to be there and you get affected. Now, we move with kind of the attack sequence, or the attack flow. What does it work? If you look at a high level how these attacks happen, they all kind of follow a very similar model.

For one, we talked about how targets of opportunity are highly automated. We talked about they happen about 99.9% of the time, so how do they achieve that? They achieve that through automation. Automation is very efficient, and very effective. It allows them to have greater impact. What it also allows them to do is be much faster to the draw. We saw this a few years ago with the severe SQL injection vulnerability that led to [inaudible 00:12:19] in Drupal, for instance. They said, okay, if you didn't patch within what - 8, 12 hours, whatever that number was - consider yourself affected. That was an example of how fast these attacks can occur, and it's facilitated through automation and the interconnected web that we live in.

When we dive into these attack sequences for instance, they kind of follow these six steps in some combination. There's this Reconnaissance Phase, Identification, there's the actual Exploitation itself, there's some level of Sustainment. There's the actual Compromise, and then of course, there's some level of Cleanup. It's not the same across targeted and opportunistic. When we look at Reconnaissance for instance, on the targeted side, we talked about, "Hey, I want to specifically focus on you as an organization, or as an individual. I don't necessarily know how I'm going to penetrate your environment. I don't necessarily know how I'm going to exploit you, but I want to see what's happening. What ports are being opened? What platform are you using? What plugins do you have available? Let me see kind of what I can find."

Then on the targeted side, you kind of then move into this Identification Phase. "All right, they're running WordPress 3.0, but they're running the RevSlider plugin. Maybe they're running Gravity Forms, and I know that there's two major vulnerabilities in those two plugins. They're running the right version." That, I'm identifying what I'm going to happen. The targeted attack is a little bit different. I don't necessarily know how I'm going to get in there, but I'm going to identify what that's going on, and then I'm going to proceed with my exploitation. On the opportunistic side, it's a little bit different. I'm going to into the attack with an understanding of what I want.

In 2014, we had the big discussion on RevSlider. By being able to scan the entire web, my Reconnaissance/Identification Phase occurred at the same time. In some instances, Identification goes ahead of time. I say, "Okay, I'm going to target RevSlider." Now, I want going to scan the entire internet, or entire web, and figure out anybody that's running this version of RevSlider at this version. Then if you fall into this list, then I already know I've done my Reconnaissance and my Identification at the same time. On the targeted side, I don't know necessarily know how I'm going to penetrate an environment, and I'm interested in an individual. On the opportunistic side, I'm scanning everybody based on something that I know is there that I want to exploit. I really don't care who they are, or what they do. It's neither here or there.

Then, they both go into Exploitation Phase. Once I've identified what the exploitation is, or what the issue is I want to exploit, I proceed with actually performing the exploitation. Am I successful? Once that success is achieved, it's a matter of, "Okay, all right, I'm in. What am I going to do?" Usually, this kind of goes into the Sustainment Phase. This is where attackers will go in and install their back doors, or other means of ensuring that they can retain access once the compromise is complete. They go in and they install their back doors, they put them in remote locations. They put them in areas where they don't suspect you identifying where they're at.

On the targeted side, it's a little bit more ... it can be more automated, but it doesn't necessarily have to be. Then on the automated side, it's more they're just dropping everything in there. They're dropping back doors, anything that gives them access. Then, the actual compromise. "What was my objective? Did I want to do some form of data exfiltration?" You know what we would normally see on targeted attacks, you'd think things like Target, Home Depot, things like that. It's very targeted. My interest is stealing that information, stealing credit card information. On the opportunistic side, "Am I looking just to simply distribute malware?" "Am I looking to use it as part of a DDoS campaign? Part of my botnet? "Am I looking to do all of the above?"

A few years ago, it was about doing one objective. These days, on the opportunistic side is, "Throw everything in the kitchen sink at the problem, and let's just see what sticks. Do everything." Then, on the Cleanup. The Cleanup is more not necessarily you as a website owner, but as the attacker of, "How do I ensure that I reduce the potential for detection? How do I cover my tracks?" That's more on the targeted side. We see some of it on the opportunistic side, but very, very seldomly. In this instance, we don't care if we get detected, it's just about mass exposure. One thing I wanted to kind of provide is a way to think about this. From a security perspective, this seems like a lot of information. You're like, "How am I supposed to address this?"

What I always tell my teams is, "You can't eat a sandwich without chewing, right? Focus on each individual phase, and then ask yourselves, 'Do I have the right answer for this?'" From a Reconnaissance standpoint, "How am I reducing that attack surface?" "How am I ensuring that they're not going to find things?" "Am I disabling ... " You hear a lot of security discussion on this side like, "We don't want them find our WP Admin, or our Admin CP," or whatever the case may be. "We don't want them to know what version of a CMS that I'm running," so you disable that. It's also at the server level, "What daemons am I running?" "What ports are available?" "Should I have FTP open if I'm only using SSH?" Things like that. On the Identification side, "What vulnerabilities exist?"

On the enterprise side, we talk a lot about vulnerability management programs. We don't talk a lot about that on the consumer mid-market domain. It's not a common terminology. We talk a lot about, "Update, update, update," which is really kind of patch management. Updates are there to address a number of things. From security fixes, to bugs, things like that. Not every bug is a security fix. We say, "Update," because it's easier for people to absorb, and it falls into this kind of patch management domain. Vulnerability management probably is really kind of what we're talking about. We're updating not only to fix issues, but also to address a lot of security issues, and from a security perspective we're interested in.

How do we know that exists? On the enterprise side, they employ scanners. For non-CMS applications, you have things like Nessus, or w3af, things like that that are designed to go and look, "Hey, do I have weaknesses?" "Do I have things like SQL injection, or cross-site scripting, or other similar vulnerabilities in my code from the remote perspective?" On the CMS side, fortunately we have a lot of CMS-specific scanners. We have things like WPScan, and Joomla Scan, and CMS Scan, and Drupal Scan, and things like that that are designed for specific CMSs, and then CMSs as a whole. They better understand how the CMSs are built, and they know how to manipulate the objects to see if they can't find some form of vulnerability.

Why not integrate that into your posture? You have to be very sensitive here. You can't just deploy it, or you have a lot of false negatives, or false positives, and it can create a lot of noise. You want to be sure you're working with your Developer on that. Exploitation. Okay, so we've gone through the process of reducing our potential attack surface. We've implemented controls to figure out ways to reduce, or identify, potential vulnerabilities that others are going to be looking for. We understand that nothing we do will be 100%, so how are we addressing that? How are we mitigating these exploitation attempts? In some instances when working with vulnerabilities, there's a lot of components to it.

It's not ... I can't just look at this and say, "Oh, he didn't validate his input." "Oh, he didn't sanitize his output." No. Sometimes, it's a combination of bugs together that create a vulnerability. How are you ensuring that you're implementing the tools to do that? Some controls these days is employment of things like firewalls, or intrusion prevention systems, designed to more help more proactively mitigate these attacks. They're not the Easy Button. They're not the silver bullet that we've all been wanting for, but they help reduce your risk posture, and your overall security posture dramatically. Then, there's the Sustainment piece. We know that when they go through this Phase, if they are successful, they're going to do some form of sustainment activity. How do we know what's happening in the edge? How do we know if back doors and are in there?

Back doors don't present themselves externally. They present themselves on the back end, and don't necessarily present themselves. You have to know what you're looking for. Are you employing intrusion detection systems of any kind? Things that are looking for integrity changes, additional files? Are you being aware of what's happening in your environment? A lot of this, as a website owner you'd know these things. "Oh wow, this file doesn't belong." "Wow, where did this plugin come from?" These things should be indicators of a potential issue. Then, the actual compromise. How do you know if you're compromised? The most recent studies going out right now, from the enterprise down to the small Mom and Pop, is most people just don't know that they're compromised until they've been notified of it. Until the network feels the pressure - they lost $80 million - or whatever the case may be.

Or, they've been blacklisted by Google, depending on who you are as an organization. Then of course, on the cleanup side. Auditing gets a bad rap, or logging gets a bad rap. People just don't like to do it, but it's important. Logging provides you ... it's the one mechanism you have in place to help you in the event of all failure. You want to understand how this happened. How did they get in, and what did they penetrate? I would imagine that most of us just don't want it to happen again, right? If it happens one time, shame on us. After that, let's figure out what happened, and let's improve our control. None of these controls tell you that you will never compromised. They just tell you that you can address them, and not be that low-hanging fruit, and not be part of that. Make it just that much harder for the attackers to penetrate your environment.

There's one attack that isn't necessarily compromising your environment. It targets your availability. By availability, I mean the accessibility of your site to your audience. Someone types in your domain, and they want some information back. What we're seeing is a slow growth in things like denial of services attacks, or distributed denial of service attacks. They're not necessarily ... the intent is different. When we look at traditional hacks, the hacks are designed to, "I want to compromise this environment, and my intent is to do something with this environment." When we're looking at availability attacks, what we're talking about is, "I really could care less about your audience, and I could really care less about doing anything in your environment. I just want to make sure that your site is not available." "I will blackmail you, I will force you to pay me some ransom, and I will continue to attack your site and overwhelm your resources."

In some instances, it's not that complicated. Especially as we've seen this evolution of denial of service attacks on things like Layer 7. Inundating your environment with HTTP requests of some kind, to the point where it saturates the network. Maybe your host comes in and says, "You know what, I'm sorry, but you're on a shared box. I just can't afford you to be in our environment anymore, because you're having residual effects across my entire network." They kick you off, and all of a sudden now, your website that you're most dependent on is off. It's not necessarily a hack where they compromise the environment, but it's a hack in where they could bring down the availability of your site. Which could have of course adverse effects on you and your business.

That's great. We went over the environmental considerations. We went over the sequence, or the flow of attacks. Now, let's talk about the specific vectors. When I talk about vectors, I break it down into five distinct domains. Access Control, Vulnerabilities, Cross-site Contamination, Third-Party Integrations, and of course, Hosting. I'm going to talk about each one of them here in a second. On the Access Control side, I think it's ... I like to use this term, and some people are like, "Oh, no, people don't understand that." I like to think that people are a lot smarter than we give them credit for, and so I like to use the proper terms. Access Control, or Authentication Authorization. Does somebody have access to gain entry into a specific area?

If you're working on a CMS, they all have administrative panels. How are you securing that? How are you ensuring and looking at that and saying, "I have the right people accessing it from the right locations, and I'm not allowing people to get in."? It extends beyond that. We just talked about the environmental considerations in the overall chain. How are we doing that on the server itself? How are we doing that on a hosting administrative panel? How are we doing it in things like FTP, and SFTP, and SSH? All those are access mechanisms to get into your environment. It does no good if I secured my CMS, but do nothing to the neighboring applications. They're all doing going to the same location, they're just multiple doors. We need to look at that.

The same thing applies when you have multiple sites. This is a big challenge with the way that hosts are configured today. They allow you to create one account, and in that account, you can install 100 domains till you're blue in the face. Somebody goes in it, you secure one website, but you don't secure any of the other websites. Then you don't address the Access Control issue, and that becomes a hodgepodge of issues for you in the future. The attacks specifically against this are what we would consider to be brute force attacks. They're very rudimentary attacks - they've been around for a very long time - but they're very effective as well, which is why we continue to see them. It's a combination of guesses between username and password, trying to find the right combination.

The challenge today though is that it's not as random as we may think, because there's so many lists available from some of the major compromises that occurred in 2012, '14, '16, in which these large databases of username and passwords. The fact is that they depend on human nature. Human nature is we use the same username and password across all our platforms. Why? Because we as humans can't remember, and we fail to use things like LastPassword, or password managers, and so we try to remember it. We say, "Okay, I'm going to use the same password across all my domains." Use it in LinkedIn, that gets compromised, and now they can access all your information. It's just a matter of finding the right combination.

Whether I talk about priorities, or I talk about if one is more important than the other, I think the one that's most important, at least to me and to us, is the exploitation of vulnerabilities. Again though, attackers take advantage of what they expect human nature to be. Where we just don't naturally want to help ourselves. When we see an update, "Well, we can't update it," or it might be a challenge. "Well, if we update it, it might break. It might have a conflict," things like that. Attackers understand that. When we look at software vulnerabilities, we're talking specifically about bugs in code. Sometimes, they're security issues, and very blatant. Like, "Wow, that piece of code is not doing the proper sanitization or validation." We can expect something like a cross-site scripting attack, or we can expect something like a SQL injection attack.

Sometimes, it's a little bit more complicated than that. Maybe sometimes, it's abusing an arbitrary kind of file upload vulnerability of some kind, and then using that to do a remote code execution. Using that to do something else. Maybe it's just tying two bugs together, allowing me to do one thing. Maybe the vulnerabilities extend beyond the application and go to the server. A bug in the application and a bug in a server will create one vulnerability. It's this daisy-chaining of events, or daisy-chaining of bugs, that allow us to create a security vulnerability that we could then later exploit. I encourage everybody to become familiar with OWASP, or the Open Web Application Security Project. They do a really good job about every three years sitting down and trying to understand what they consider to be their top ten issues affecting websites.

They actually have about I think 250, 256 different types of vulnerability. I might be wrong in that number. It's been a while since I looked at it. They do offer a lot of great recommendations on cheat sheets on cross-site scripting, or cheat sheets on SQL injection. It's not designed to be the all-encompassing, but for someone starting off from the development standpoint, maybe start looking at that. Just even as website owners, just to be familiar with the potential vulnerabilities and what they occur. Why? Because vulnerabilities have always been there. Vulnerabilities are not going away. Vulnerabilities are because we as humans introduce errors into how we do things, and that's just natural.

We can't say, "I want code, or I want a plugin that has no vulnerabilities." You're already thinking about it incorrectly. You're never going to get that. If anybody ever tells you, "With our application, you will have no vulnerabilities," that's just completely incorrect. That just means nobody's found it yet. This is specifically rampant right now in CMS applications. Not because they're more or less insecure than anything else, it's just because there's more interest in researching that and identifying vulnerabilities, because the impacts are much greater. If we took a look at targets of opportunity, if I can look at anybody running on WordPress specific version, or Joomla specific version, it's a lot easier for me. The potential for impact is greater, and the potential for return is greater as well.

When I talk about Access Control and I talk about software vulnerabilities, I'm talking specifically about external attacks, or hacks, and how they happen. When I talk about cross-site contamination however, I'm talking more about internal hacks. What cross-contamination refers to is the lateral movement that occurs. In large enterprises, I penetrate the perimeter and I can literally move across the network. Identify all the networks, devices, servers, things like that. Now take that, reduce that, and focus specifically in the web environment, on the web server. I penetrate your shared account, you have 100 different servers, 100 different websites within that account. I can then now laterally move across those environments.

Maybe they're all in the same platform, but maybe you have multiple different platforms. Maybe you have a WordPress install for your blog, and another WordPress install for your main site. Maybe you have a store where you're using Magento, or maybe you're using OsCommerce, whatever the case is. You secure one environment, but you don't secure the other environment. Using one environment to penetrate the other environment, I can now laterally move across the rest of the environment to identify other weaknesses. Maybe I want to target your main website or whatever the case, or just target any website in the environment. It's often the contributing factor for the infections. This is kind of where you hear things like permissions, and default prefixes, and stuff like that. This is actually kind of where it comes.

Those don't necessarily lead to external attacks. Those are more a configuration issue that lead to internal attacks, through the form of something like cross-site contamination. Third-Party Integrations. We don't talk about this enough, and I think we should because it's becoming a bigger and bigger problem. Especially when we talk about the integration of ads, ad networks into our environments. There's a concept of known as malvertising, and malvertising is malware and advertising kind of meshed together, because that's how creative we are in the Security World. What it refers to is just abusing these ad networks. Ad networks are based on trust. "I'm going to go to this network because I trust that they're going to serve me up the right ads." Well, attackers understand that. This concept of "Own one, own them all."

"If I can attack the ad network and embed my payload within the actual image of the malware, I know that it's going to rotate through your site, or some site at some point. I really don't care which sites they go through, as long as it captures that image." The problem with this is that a lot of website owners will get very irate, like, "I don't understand, I've been infected. I can see I was blacklisted, but nobody can find it." They go to [inaudible 00:29:49] find it, that doesn't find it. They use the latest plugin or extension, that doesn't find it. They're going crazy. "I rebuilt it, it doesn't happen." Come to find out, they have three different ad networks coming through their environment, and the payload is highly, highly conditional. It makes a very, very challenging to identify. I'm not joking about that.

Sometimes it could show up once a day. Maybe it shows up once per IP, or IP range. Maybe it shows up per geography. There's all these configurations that have to be taken into consideration to try to identify something. Malvertising is something that continues to grow, continues to be a problem. We've seen it affect some of the largest brands in the world, and it affects some of the smallest brands as well. It's something we need to be thinking about. When we're talked to integrators, we need to be asking the questions, "What are your security postures?" "What is your protocol for potential malware issues?" If you are running ad networks in your site, you need to be asking yourself, "If I have an issue, could it be my ad network? If so, how do I know that? How do I define that? Let's remove it for a second, let's see what happens."

Then, Hosting. Now hosting gets a really bad rap. It's been a long time since we've seen mass compromises in hosting, and so a lot of people actually get it wrong. They say, "Oh, it was my host's fault." It actually isn't, and it is. The problem with the Hosting World right now is that it's so saturated, and it's so easy to get online. It's so easy to push a new website saying, "I'm a host." We also have a challenge in which we have hosts that aren't really hosts. We have a Marketing Company that wants to provide an all-inclusive whitelabel solution to their customer. They'll spin up a little AWS instance, and they'll say "Hey, I am now a host for my customers." Yet, they don't know their elbow from the rear on how to manage that environment.

They have the little AWS server, they misconfigure it. They have no staff on hand to help support it, but the website owner is completely unaware of that. They just say, "Well, they're hosting it. They're offering it. I'm trusting them, they must know what they're doing." That doesn't necessarily happen, and so we have these inexperienced service providers that are actually adding confusion to the hosting marketplace. As long as you stay to more reputable, larger organizations, you should be okay. The way I like to kind of use an analogy for this is: It's like me going to my car wash guy and saying, "Hey, can you change out the transmission in my car?" The car wash guy's like, "Well yeah, I'm kind of mechanical. I can do it," and he changes out your transmission.

He's like, "Now, I'm going to offer this full-inclusive car service where I'll wash your car and change your transmission." It's a little bit dire, but you hopefully get the point, right? Each of these things, just like you go to a Marketing person, just like to go to a Development shop or an SEO shop. Hosting security things are things that you need to be taking into consideration, and serious consideration, if you're going to go live and depend on your website. It's actually one of the really leading causes for cross-site contamination. These insecure hosts don't know how to configure these environments. One neighboring site that doesn't even fall within your account has the potential to affect all your websites, just because of improper deployment, improper configuration.

With that, we talked about all these different things. We talked about the environment, we talked about attack flow sequence, things like that. What are we supposed to make sense of this? When I do this, I always like to add this section here on website security. It's not a static state. We're always looking for the Easy Button. It's like, "Hey, just tell me what I have to do. Tell me the top ten things I need to do." The problem is that that doesn't exist in security. It's a continuous process. It's an evolution, that the landscape continues to evolve, and we have to stay ahead of that. If you're not willing to do that, then you need to leverage somebody that will do that for you if you depend on your website for anything.

I like to think about it in these five domains. You need to be thinking about it for, "How do I protect my environment, but I know that protection's never 100%." "How do I detect?" "How do I know what's happening, and the potentials of something happening?" "If something does happen, how do I know that?" Then of course, "What is my response plan? Am I going to address it? Is my host going to address it?" A lot of website owners don't realize that a host don't necessarily address your security issues. They'll either charge you more. They'll disable your sites. They'll kick you out of their network. Then all of a sudden, that adds to that emotional distress that I originally talked about, like, "What am I going to do? How am I going to do it?"

Then basic basic things like maintenance. Maintenance and best practices is something that is already known in the security space, but unfortunately in the domains that we operate, aren't necessarily right. Too many people are creating websites. They don't understand the basics of, "How do I administer a site?" "How do I employ proper patch management or update sequences?" Things like that. "How do I employ things like least privilege?" Instead of giving everybody admin, give only a few people admin. I'll get into more conversation on this in the future in another webinar. The other challenge I find is that we often look at technology as the end-all-be-all, but it's but one piece of our approach. Security has always been made up of people, process, and technology.

Technology by itself is dumb. Okay, I buy a firewall, I implemented my network, but I don't configure it. I leave the default admin as "Username" and "Password." I just installed a very expensive appliance in my network. Maybe I purchase a plugin and I install the plugin, but I do none of the configuration components in that. What good is that? No. It's a combination. People get the technology, they deploy it, and then they configure it based on your environment. There's no single blueprint. There's no configuration that works for everybody. Every website's a little bit different. Then, we have a process for that. "How do we check it?" "How do we stay on it?" "Okay, we're seeing attacks." "Do we need to evolve it?" "Do we need to change it?" "What do we need to do to ensure that we're staying ahead of it?" It's just, it's a continuous process.

Then lastly, I just like to tell folks, just like we go to hosting providers or Marketing folks, or SEO folks, security just isn't a DIY project. It never has been. This is a difficult concept for a lot of folks to understand. Especially in open source communities, where it's all about, "Oh, we can figure it out." The challenge is that it changes too fast. It's too many things happening to stay ahead of. As you can tell, just from this very, very short, truncated version of how websites get hacked. With that, as again, my name is Tony. I'm with Sucuri. What we offer here is specifically on a protection detection response domain. We leverage a defensive depth kind of approach. Where we understand there's no one piece by itself that is the ideal solution, but it's a combination of things. With that, I'll turn it back over to you, Kristen. If there are any questions, open it up.

Questions & Answers

Besides brute force attacks on access control, we see some compromises by actors that obtains real credentials to the site via other means (keyloggers or password dumps from other sites where users have the same u/p). How to address that?

Yes, this is something we discussed in the presentation. Some attackers do have large data stores of username / password combinations they’ve purchased or stolen. The best mechanism to address this is to employ things like IP whitelisting (if possible, but can be achieved by restricting access to a VPN) or by enabling some form of MultiFactor authentication.

If you ever feel your password was part of a previous data breach, then it’s advised you change them immediately. I’d also advise leveraging things like Password Managers, and generating unique passwords for as many accounts as possible. Your goal is to not know any password. It’s harder than it seems.. :)

If I give each domain on my server an individual user permissions will that stop cross domain hacking on a server box?

It will come down to how the server is configured, but in many instances it will stop the crosssite contamination, as long as the user doesn’t have root access to the box, or doesn’t find some form of privilege escalation vulnerability.

Are there known host providers that are more susceptible than others?

A lot of the hosts that are not real hosts, but are services offered as its own revenue stream are the most susceptible.

Hi Tony, would there be any conflict using Wordfence together with Sucuri?

There shouldn’t be, but sometimes there are. Wordfence can generate a lot of false positives, which can cause confusion (i.e., Wordfence says this is a bad file, Sucuri says it’s not) get into this endless back and forth. They also have a tendency to block our network and have been unwilling to whitelist our network so there could be issues there. For the most part it should work fine.

We are using your service and all traffic goes to our website through your servers, do we still need to update our code regularly as we can see virtual patching done by your firewall on most of the attacks ?

Having a strong patch management process is always recommended. Our virtual patching will address exploit attempts against vulnerabilities in your environment, often the ones addressed via patches. While we’d never say you don’t have to anymore, you will be covered if there is a delay.

I experienced problems with attacks, defacement on wordpress environment... etc. But also with Sucuri installed. Also scan function never identified the malwares installed by attackers. For now, I have to say that only emails from logged in users and emails from login failed (brute force attacks) were useful

This doesn’t surprise me, the plugin is a utility plugin. There are varying degrees of security plugins in the WordPress ecosystem which I’ve written about in the past. It’s not designed to do a comprehensive scan. I encourage you to read how the remote scanner works . The free plugin is not what Sucuri is about, we are a security company first, the plugin is a simple utility for the WordPress platform. I’d also encourage you to check out the hardening features and play with the posthack and auditing components. It’s a great tool to maintain visibility into what is going on with your environment.

What do you think about Patchman as proactive security application ? Can I use your service as a reseller?

Don’t think much about patchman, I suppose it helps keep up with an organization's patch management process. As for reselling, I’d encourage you to reach out to our team to see if there are any potential synergies.

As a Sucuri customer, is WPScan automatically deployed or available for deployment? Is it freeware or subscription model outside Sucuri? Do you have a checklist for small staff users, a set of basic things we should do and how often we should use them? Are there hosts that you recommend

I like the folks over at SiteGround , I’d check them out. If you’re looking for a managed WordPress host I’d encourage you to check out WPEngine.

If you’re using WordPress, which I believe you are, I’d encourage you to install our free Security plugin out of the repo . It’s very simple, easy to use, and the best part is that it provides a very straightforward list of things to do to harden the environment. Lastly, I’d redirect your attention to the Hardening section on the repo . Hope this helps, let me know if there is anything else I can do. Lastly, for WPScan, they are a free to use product and so you don’t require any Sucuri services to use it. :)

Are WP security plugins like iThemes Security Pro any good?

The question isn’t whether something is good or bad, but what you’re looking to do. The iThemes Security Pro plugin is a great utility tool, if you want to go in and configure and tweak we highly encourage it. Read more on my thoughts about security plugins in the WordPress ecosystem.

What type of tools or services besides Sucuri would you suggest for a website built on Wordpress? What would you suggest to tighten any back doors on a WordPress CMS environment? Any blogs or websites we can check out on a weekly basis to read up on the latest threats or learn to plug things up?

Not sure, what are you trying to do? Security tools? Marketing tools? Business tools? I’d suggest not tightening, but removing them if possible. The key however will be identify them, and I suggest doing that via some form of integrity checks and / or employment of an Intrusion Detection System (IDS).

You can always stay on top of the latest security vulnerabilities by visiting the WP Scan Vulnerability Database . And of course our blog .

Sucuri offers a pretty good website checker tool, are there any others out there that can offer help in diagnosing vulnerabilities or attacks?

Well vulnerabilities are different than compromises. So if you’re looking for vulnerabilities I’d recommend the ​WPScan project ​which we also sponsor, and you can also use ​Unmask Parasites and ​SiteCheck​.

Many of us are using 3rd party services for email campaigns, SEO, Zapier, etc. What advice for these environments for us?

These are tough, I too use some of them. I always encourage having an open line of communication with the service providers to understand how they handle security. I also don’t like things like Universal Tag Managers where someone is able to bypass security controls designed to reduce access to an environment.

We have seen an increase in attempts on Joomla, is this become an known industry wide pattern? Are there any stats available on the number of sites hacked and what platforms are most vulnerable?

Great question, stay tuned for more info on this in our next webinar.

My WordPress website utilizes Sucuri's CloudProxy Website Firewall. Is there any need for me to also install another security plugin like iThemes Security Pro or Wordfence?

Nope, as long as everything is configured you’re fine. We’d recommend our ​free WP plugin​as it’ll look at things from an auditing perspective, other than that you’re fine.

One form of attack turns a WordPress site into an outbound message sender. What is this about and how can it be detected?

Oh yes, very annoying. They sometimes abuse your forms send function, so adding a captcha will often address that. Sometimes it’s a server side script, which is very annoying, and you’ll need to identify where the script is. Others it’s abuse of a server misconfiguration for the mail server. Just there I mentioned three distinct scenarios, without more information it’d be difficult to answer this question.

Thinking of risk containment. Does docker images provide any barriers in "shared environments" if you run several sites in separate docker containers on a same setup.

It’ll come to the configuration of the docker images, but in many instances it should offer good functional isolation.

Can you recommend a Password Manager?

Fan of 1Password and LastPass.

WordPress recently released a new update. Because of customized code and plugins on our website, it can be quite time consuming for our web development team to make sure everything is compatible with the newest WordPress version. How do I know which WordPress updates are critical to website security? What kind of timeline do I have before I become vulnerable? If my website it protected by CloudProxy, why do I need to worry about websites and plugin updates?

Well, if a vulnerability is disclosed and patched and made public, then you are vulnerable at that moment. Technically, you’re vulnerable as long as the vulnerability is in the environment, whether it’s disclosed or not.. :) Attacks to said vulnerability can happen as quick as a few hours from disclosure, to a few days, just depends on how big of an issue it is. As for why worry about updates, it’s good habits. No solution is ever 100%, but they are best practices everyone should follow.

What type of penetration testing/intrusion detection testing is available when our sites are behind Sucuri's CloudProxy?

Not sure I understand the question. Are you looking to test the effectiveness of the product? Or are you looking to test your own environment?

What are the legal liability to agencies that want to use Sucuri for their clients?

I encourage you to reach out to our team to discuss further.

Which platform is safer­ Wordpress or Drupal? We are currently using Wordpress, but not trained in Drupal, which is more complicated. Does it really matter? Is it safer if the site is managed by a Cloud­based host?

The CMS doesn’t matter, the issue is not the platform, it’s often how it’s deployed and the end user. What do you mean by a cloud­based host?

Do you consider Bluehost to be reputable/secure?

They’re a shared host, I encourage you to ​read how hosts account for your website’s security​.

As a volunteer with self taught skills, what are my low­cost options for security?

Don’t know where to start with this question, it’d be like me asking a mechanic ­ Hey, don’t want to spend any money, but can you tell me how to rebuild my engine? It’d be impossible to cram years of knowledge into this response, but I what I recommend is starting with small manageable parts. Focus on how you log in, employ things like Two Factor Authentication and have a good patch management process (i.e., apply updates). Additionally, you want a backup at all times.

Can you describe your cloudproxy product? Can that be purchased as a separate product?

The CloudProxy is a custom Website Application Firewall (WAF) / Intrusion Prevention System (IPS) designed specifically for websites, tailored for Content Management Systems (CMS) like

WordPress, Joomla!, Drupal, Magento and so many others. It functions as reverse proxy in which we filter all incoming traffic for malicious requests; those requests are then stripped from the requests before sending it off to your host. It helps mitigate Distributed Denial of Service (DDoS) attacks and exploit attempts against software vulnerabilities (i.e., SQLi, RCE, LFI, RFI, XSS, etc…). Yes, you can purchase the ​Website Firewall​independent of our Website Security Stack.

Is hosting your own website on a windows server safe?

If you configure and maintain it, yes. The problem is, most don’t know how to configure or maintain it, making it challenging.

Which CMS engine seems to be the most secure?

I wrote an article that kinda talks to this, check it out.

Is it good practice to use Sucuri's WAF along with CloudFlare, so that I can take advantage of their CDN network?

If you really need 70 + points of presence, then sure, but the Sucuri Firewall will provide you a Content Distribution Network (CDN) and in many instances it’ll address your needs perfectly. It will work together however.

Would you speak to injection attacks and how Sucuri can be used to protect this attack vector?

There are various forms of injection attacks, see my explanation for question 24 how the Sucuri Firewall works. It should help explain how the technology works and how malicious requests are stripped. If it doesn’t, let me know and I’ll try to explain in more detail.

Can't we take any actions against Hackers ?

If you can locate them, sure. The problem however is it’s very difficult to do what’s called attribution, the process of identifying who did it. If you’re big enough, you can work with law enforcement in your country as well.

First of all I love your products.. We have a number of Joomla 2/3 site and would like to know do we need Akeeba Tools if we use Sucuri? I feel like maybe it is overkill? Can you explain what a honeypot is?

Ah, thanks so much. Depends, which Akeeba tools are you using? Would need to know more to better answer. A honeypot is an environment used to attract attackers so that we can study their actions. Think of honey, or sugar, attract the ants and watch what they do.. :)

Can you talk a little slower? It's a little difficult to understand.

I’m so sorry, but hopefully the recording will allow you to slow it down. I just get so darn excited.. :)

Is SSL must in any website? If yes, how secure is Let's Encrypt?

Personally, don’t think it is. Especially if you’re not taking other security precautions, ​I wrote an article on the subject​. LetsEncrypt is a Certificate Authority (CA), they are good to go.

Is Sucuri the only tool we need? Or is it wise to use Sucuri along with other products like a Firewall, and SiteLock, WordFence, SSL, and iTheme Security? Or others?

If you used all the products at the same time, I can’t help but think you’ll run into a number of conflicts and likely find yourself curled in a ball in the corner crying. We built Sucuri so that it was the only tool you’d need, which is why we focus on the core areas ­ Protection, Detection and Response. If we only focused on one area, then I’d say definitely supplement, but what you’ll find, unless you are a security person, using all the tools will be overkill.

Does he have default or preferred settings for the Sucuri plugin in WordPress?

I usually run the Kill PHP execution feature, by far the one feature I recommend everyone use.

Most of my attacks on my clients websites come from brute force attacks. What is the best way to combat this?

Personally, I’d recommend a WAF/IPS solution like the Sucuri Firewall so that you can stop getting the notifications and stop worrying about it. You can also employ things like IP whitelisting or 2FA on your access nodes.

If I utilize WPEngine they say the have robust security and if anything gets through and hurts a site hosted on their platform they actually pay you guys Sucuri to fix it and I don’t get charge WP Engine covers costs. Why would I need Sucuri on top of WP Engine?

WP Engine is a great host, we are a great Security company. They do leverage our remediation services via our partnership. When a compromise occurs however, you won’t be able to engage us, and it doesn’t include our protection services. So if you’re getting compromised, and you’re ok with just cleaning it, then definitely stick with the WPE service on security. If you’re looking to engage with our security team, understand what happened, and work to make sure it doesn’t happen again, then I’d encourage working with ours. It’ll come down to preference. In many instances, I have found that when it comes to security, website owners want to work directly with us when shit hits the fan.