Kristin Burke:
We have a really interesting topic this month. I know when you think about clicks and clickbait, you want to come up with the sexy headlines and the sexy topics on cybersecurity. It’s in the nitty-gritty where all sorts of bad things happen. What we’re talking about this month is relevant. It’s about open directory listings and just the data exposure risks around open directory listings. I got to admit, when I saw that, I was kind of like, all right, I’m not quite sure what this is all about, but a recent report by an organization called Censys came out and they had found 314,000 distinct internet connected devices and web servers with open directory listings. From my very simplistic thinking, this leaves data discoverable, it leaves it in a position to be exploitable, but it also seems like this is a very old problem, yet it’s still plaguing us. Can you kind of give us a backstory. What is this? Why is it relevant and why are we in 2023 and continue to face this?
Shahin Pirooz:
Great question. There’s a handful of factors that led to directory listings becoming a problem. One of them was that we were putting these web servers out back in the late 80s, 90s, that we didn’t know much about HTML and all that, and we didn’t know that there were any place we have files in a directory, somebody can go and browse that directory and see it. Fast-forward, we started creating controls and policies and web controls that help protect against directory browsing and rules that prevented crawling those things so that we can have better control over directory that are on the public.
Now, webpages were not that big a deal, so if you had a website and you had webpages, those were meant to be looked at. But let’s say you had all of your code behind a form that allowed you to download a version of your software for your customers, but the only way you gave them that link was you had to fill out the form. If that directory was not blocked from browsing, anybody could go there and grab it and get your software for free. That’s one example. So that problem became an issue. We dealt with it. We did address it as we fast forwarded.
Fast forward to about five years ago, Amazon put out these amazing tools and services that allow us to build websites on their platform as opposed to building our own servers. They built this really cool technology based on object store called S3 and S3 allows us to create files that we put into a space in these object stores that allow us to leverage those in our websites and whatever we’re doing, use them as logs. But the default configuration when you set up a bucket in S3 was that it would be browsable by the internet. Tons of people set up buckets that were supposed to be internal focus, that were supposed to be protected, that were not, and everybody got access to it. They got access to their source code, they got access to keys that they used in their code for API connections for whatever. Lots of exposures.
Fast-forward to today where we think we’ve solved all these things, Amazon made a change and said, “We’re not going to do this anymore. The default setting is off and you have to turn it on if you think you want to turn it on.” And other cloud providers followed suit as soon as they learned from Amazon’s mistake. But fast-forward to this Censys survey. Basically their job is to go out and scan assets and find out what ports are on those things, what services they’re running so that they can track what’s on the internet basically. So they found over 300,000 distinct nodes, which is web servers is one way to think about it, that had open directories even in today’s world. And that was over many countries, not just one area of focus of that.
They found hundreds of files that were hundreds of directories that had database files and spreadsheets. These are potentially database backups. Whatever they are, they probably have some sort of company asset information in them or proprietary data that you don’t want leaked. They found 9,000 files that by the file name looked like they were financial data. They found thousands of files that looked like other critical things, like they might’ve had authentication, they might’ve had password controls. There is a lot of different little factors that made up, so why is this a problem? Because now you just save the bad actors from having to get in your environment and exfiltrate data. All they have to do is copy that stuff out and then they don’t have to spend cycles trying to find the data. They can just jump into your network and encrypt the data and charge you a ransom or they don’t even have to encrypt the data. They can just publish that data and cause you all kinds of grief with regards to your reputation against customers, all that.
It is a pretty significant problem that makes the hacker’s job easy, honestly, and it’s a simple thing to fix. What I didn’t see in that Censys report was any information about how someone could find out if they’re on the list. That would be the ideal next best thing. Bar that though, people should look to see, do I have any open directories and make those scans themselves. Hire a pen testing, somebody to come and do a pen test and evaluate before the bad actors find it is the short answer. There’s ultimately three major problems with this. Number one, if you have credentials in a file, and like I said, there were thousands of files that looked like they had credential data, they don’t have to go and try to do phishing and spoofing and impersonation and all the things to get somebody’s password. They’ve got your credential files there. If you’ve got artifacts from your development, for example, an API key into your environment.
Again, that’s another way they can get into your environment and get access to data, not have to steal somebody’s credentials and spend all the cycles trying to phish and everything else. The last thing I mentioned already, which is if they have that data, they’ve already exfiltrated the data. They’re not having to come into your network, break in, do the phishing. We really are making their jobs super easy when we do this and we’re putting our reputation as individual companies on the line by having that data be leaked and put out on the dark web.
Kristin Burke:
When you mentioned those three areas, right, is there a best practice? Is there something that an organization ought to do different or is there something that they ought to do? When you think of credentials, when you think about your APIs, is there a way that they ought to think about creating them, storing them in a way that protects them more than maybe they are today?
Shahin Pirooz:
The short answer is you shouldn’t keep credentials. If we’re talking about just that small universe, you should not keep credentials in files anywhere. It just should not happen. Honestly, I would, if I could, take credentials out of active directory. The reality is any file that a hacker can get their hand onto, they can figure out how to decrypt and how to get to the information. I’ll talk about a next level problem five years from now, not today, but with all this same data in a second. But that credential data should never, it’s like for example if you remember back to when the Hawaii missile alert system went off and everybody thought in Hawaii they were getting bombed and it ended up being a hoax and a hack. The way that the hacker got into those systems and send out that message was because there was an interview of the guy who works those systems and behind him was his computer with a sticky note with his password on it.
Do not write your password down anywhere. That’s why we have password systems. There’s plenty of them out there. There’s a few of them who’ve been heavily targeted in the past couple of years and people are scared, but don’t be scared of password management systems. They’re much better than any sticky note you’re going to put on your computer and anybody can walk up and grab that password.
Kristin Burke:
There are better ways to do things, but we know that there’s part of the general public that will continue to do what they do for convenience sake. Is the Censys database or the Censys report, is this the only way that the bad guys find open directories or are they out there trolling and looking? Do they have a methodology where they’re doing it on their own? I know Censys is something they’ve exposed it and they’re reporting on it, but is there are the bad guys kind of actively looking for this anyway?
Shahin Pirooz:
It’s the same mechanism. They’re doing the same thing the Censys people did. So they’re out there looking for open directories. That’s one of the things they do. In addition to the phishing we described where they’re trying to get credentials for an environment, one of the biggest known attacks right now is, or most used method for getting into an environment more accurately stated, is getting somebody’s credentials using those on their VPN solutions. Cisco’s been hit with a lot of vulnerabilities in their VPN solution. Using those to get through the VPN into the environment.
Then once they’re inside the environment, then they start doing credential capture and once they have a password that looks like it’s a domain controller, then they start doing any elevation of privilege causing problems with that domain admin credential. Their goal is first to get into the network. Then from there it’s to get credentials that allow them to do what they need to do. Then there’s a bunch of tactics they can take credential stuffing and other things, NASH passing, and they’re able to take that simple phished credential for the front desk admin and turn it into something that causes you grief as a company.
Kristin Burke:
It sounds like the open directory is a gateway in, I mean, we think about a house or a castle or whatever, if something is unlocked or open, someone’s going to find a way to get in.
Shahin Pirooz:
A better analysis or analogy is imagine that you put all of your bank statements in boxes in your garage, but you leave your garage door open. You don’t like closing it because it makes a lot of noise or you forgot. That’s the analogy here. You’ve got a place where you’re storing stuff and you have most likely inadvertently or through configuration mistakes left the door open for the bad actor to walk in and grab a box and leave.
Kristin Burke:
Well, that kind of leads me to my next question. It seems like maybe there are two approaches here. One is how do I find out if I’m exposed? It sounds like some kind of vulnerability testing or configuring when things either have configuration drift or things are misconfigured, that there should be an initial audit of that, but then something ongoing that can alert you. Option one is kind of identify or remediate right away, but then is there something on top of that, which it sounds like there is. Right? If someone does happen to get in, how is it that you create kind of those next layers of defense to slow them down? What would you say on each of those scenarios, what would you recommend people think about?
Shahin Pirooz:
This scenario that we’re talking about today, open directories, there’s no protection. If you left the garage door open, they’re going to walk in and grab your boxes and walk away and maybe you caught them on camera, but they got your boxes and left. The reality is there is no way to protect against this because it’s literally an open door. How do you find out? Let’s go back to the first thing is a vulnerability scan alone isn’t going to do it because it’s not a vulnerability. You just left the door open. It’s not like the lock is broken. You left the door open.
This is a pen test and the pen tester’s… part of their pen testing, and this is not a typical synthetic pen test don’t find these kinds of things, you want to do a manual human-based pen test where red teaming individuals are going to be looking for things like this. They’re going to be scanning all of your assets, they’re looking at all your IP addresses, they’re looking to see, is there anything I can get into? They will find open directories in most, if they’re reputable, decent penetration testing team, they should find any open directories you have. Then you need to understand why is it open. The way to solve this is it’s more like in the development space, we’ve, over the last few years, everybody’s probably hearing the term shift left and shift left means shift security to the beginning of the development cycle as opposed to after development started.
The context is the same here from an IT because a lot of what we do today is built in a DevOps construct. DevSecOps has to all be part of our mindset and shifting that security left and asking the question when you create a bucket, when you create a directory on a file server, on a web server, “Who has access? What’s the controls to it? Is it publicly available?” Those are questions that have to be done every time we build something. The risk assessment that comes out of that penetration testing and the management of those risk is how you solve this problem.
But let’s say for example that this was you were on a service like ours that does more than the average bear and we do cloud posture management as part of the service, and we’re scanning your cloud infrastructure and we see open S3 buckets or we’re scanning your external facing assets and we show you what we found. One of the things you’ll see there is graphics of the webpages that we’ve seen. One of those pictures would be a directory listing of files. If your S3 buckets are open to the public, we would let you know those S3 buckets are open to the public and that’s a bad configuration. Are you sure you want to do this?
There are ways to monitor for this, but prevent it? No. It’s a human configuration change. There’s not an automated process or a tool that can block or prevent access to an open directory.
Kristin Burke:
Got it. Got it. Right. I keep going back to the garage door. If it’s open, it’s open. Multiple layers of security aren’t going to block an open garage. That makes sense.
Shahin Pirooz:
You can hire two armed guards to stand out there, but if they fall asleep, it’s that same notion. Ultimately, I think that the biggest challenge with this scenario is that most people aren’t even aware that the garage door is open.
Kristin Burke:
Well, and I was surprised just even reading through it and learning about it, I thought this is something, and this is the way cybersecurity is. Right? The devil’s in the details literally because there are all sorts of ways that adversaries find to get in that maybe not through neglect, through to your point, you’ve built something, you’re deploying something and maybe you think about security last, or maybe someone stands something up that you’re not aware of as a security professional, and all of a sudden the garage door’s open and you don’t know. There’s so many things an organization needs to think about that they’re maybe not trained to methodically think about. And I love that idea of shifting left, which is security has to come first. As you think about it, as you’re building, as you’re deploying it, I wonder how you share that mindset with people outside of your core IT team who might be deploying these things or rolling these things out at the organization’s peril.
Shahin Pirooz:
It isn’t IT that’s typically the challenge here. This is mostly development that causes problems like this because the IT team might build the web server, they might spin up the resources that the developers are going to use. But let me give you a very simple scenario for how this configuration change could happen. Developers building a new website, and let’s just pick a category, they’re building a tax website and you have the ability to upload your files and then go back and see your files later. But for whatever reason, their application isn’t working in their development cycles. They’re not able to show the files, but they’re able to upload them.
They decide let’s expose it to the internet, see if that fixes it. Sure enough, it fixed the problem, but you just opened the garage door and nobody ever goes back and changes that and IT has no idea. Security has no idea, unless they’re using tools like what I described to be monitoring the configurations and looking to see what open buckets do I have, scanning the web servers, and looking at all that. It’s a very simple… and this happens in IT too, and I’ll explain it in a different way. What happens is something is blocking my access to do what I’m supposed to do.
Let’s just open everything up. Let’s open up all the doors and shutters and let’s see if it works. Oh, it works great. Yeah, we’re going to go back and close the doors and shutters that we didn’t need to open, but we never get around to it. I’ve mentioned technical debt before. That’s an example of technical debt. This is a configuration debt issue that is we changed the config to be wide open instead of closed. Same thing happens on networks. That’s why we’ve talked about segmentation in the past where people will try to create segmentations and VLANs and all that, and pretty soon application A doesn’t work, so let’s open up a hole. That didn’t work. Just open the whole thing up. We don’t have time for this. We got to get this done. The VP is down our neck, the CEO’s pissed off. Let’s just open the communication. It’s inside our network.
Anyway now you have an open flat network. These configuration problems are very easy to expose and very difficult to identify. The only way to be able to continuously understand is number one, monitor for anomalous behavior. So you see something that’s different than normal, which is what we bring to the table. Number two, put better security controls in so it’s not easy to do this, and it’s easy to make changes like our NDR offering, which is system to system segmentation, takes the network virtualization a layer up and allows you to do that in a policy-based model so that if there’s something you want to allow, you simply say “Allow this to get to this and these processes” in English, and boom, it sets up all the underlying network features that allow that.
Similarly, have change controls or changing configuration in the cloud. When you are trying to build a new application, have somebody come in after the fact and do a pen test of the application before you launch it. When you add a new feature, have that feature evaluated because it’s very easy to make these mistakes. It’s not like the poor developer meant to expose the company’s assets, but they didn’t realize how big of a problem that is because they haven’t shifted left. That’s not their mindset.
Kristin Burke:
Right. Right. Right. Well, I love spending time with you every time we do this because there’s some new idea or phrase that I take away from this, and I would imagine it’s valuable to our audience. Really, this is what these talks are all about, bringing issues to the table. Some issues are what everybody’s talking about. Some issues are maybe what people aren’t talking enough about and really exposing that information to our audience and giving them some food for thought. “Hey, how do I feel about my organization? How do I feel about how I stack up in this area?” And as always, we’re happy to help. As an organization out there, if this is something you’re thinking about and thinking, wow, this was not even on my radar. We know with cybersecurity, that’s what happens, right? These things pop up like whack-a-mole, and now all of a sudden it’s urgent and you got to fix it.
Shahin Pirooz:
I thought I had that covered.
Kristin Burke:
Right. Right. Exactly. If this is something that all of a sudden you’re thinking about and saying, gosh, I wouldn’t even know how to know, please reach out to us. We have different types of health checks and analysis that we can help run. We can have a conversation with you, let you into our brain trust. We do consider a lot of these as PSAs. Right? There’s a lot that’s going on out there that the only way we’re going to help solve it is to shed some more light on it. So thank you. This was great. Shift left is my new thinking for the rest of the day. Thanks for joining us. We’ll see you next month.
Shahin Pirooz:
Thanks everyone.