Tony Perez – Sucuri Co-Founder
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 blocklist? 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 blocklisted 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 blocklisted, 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.
