• United States




Check your access control permissions before hackers do

Apr 25, 20197 mins
AuthenticationInternet SecuritySecurity

Every organization has devices, networks or cloud services with improperly configured permissions that expose sensitive data or could allow hackers to gain privileged access. Check them now.

I’ve repeatedly talked about the two biggest cybersecurity risks to most organizations: social engineering and unpatched software. A few weeks, ago I added passwords as the likely third biggest security issue facing most organizations. Now, I’m adding a fourth largest threat: incorrect access control permissions.

Of the hundreds if not thousands of security reviews I’ve done over the past two decades, I’ve always found incorrectly set permissions (when that was within scope of the review) on single PCs, devices, networks or cloud instances. These days operating system vendors have a good set of default permissions. It’s the admins and end-users who are making the mistakes that are leaving their devices and private information open to the world.

I don’t have hard data to show that incorrect access control permissions are the fourth biggest security issue, but I do know there are a lot of exposed documents and folders. According to Varonis, 18.9% percent of companies with more than 1 million folders have 100,000 folders accessible by every employee, 19.3% have over 1,000 sensitive folders open to everyone, and 19.6% of companies have over 1,000 folders with inconsistent permissions.

The two most dangerous types of incorrectly set permissions

Depending on the OS and device, there can be dozens of individual granular permissions, along with inheritance issues and group membership considerations that can add up to permission mistakes. It’s easy for a single security principal (e.g., a user) to get permission to something they shouldn’t have access to. That’s a problem, but I’m not even talking about those sorts of small, individual mistakes.

I’m talking about major permission mistakes involving just two main permission types: Everyone Write/Modify and Everyone Read on files and folders that should not have those permissions. This could come about from those exact permissions set, or from some larger, even more permissive set of permissions, like Everyone-Full Control (in Windows) or World- mask+777 (in Linux). It also frequently happens due to incorrectly set database permissions, which equate the same issues.

Worldwide, there are likely millions of incorrectly set, overly permissive permissions. Most are due to configuration mistakes. All hackers have to do is look.

Cloud configuration mistakes

Examples abound of data exposures due to cloud configuration mistakes, especially around Amazon’s AWS cloud service customers. Here are a few:

Azure, Google and other cloud service provider customers also make the same types of mistakes, but it seems that because AWS is the largest cloud provider with the most customers, it gets the brunt of the news reporting.

Find your own local zero-day

I have found dozens of locally exploitable zero-days over my career. It’s easy to do. Search a bit and I bet you can find one, too. When I do a security review on a computer, I always look for locally installed software running in an elevated security context (e.g., admin, system or root) that mistakenly allows regular end users to modify its executables. I find them all the time. Each finding is a potential escalation-of-privilege attack. All an end user has to do is replace the vulnerable executable with a malicious program of their own with the same name, or if they are advanced enough, modify the legitimate executable and add something malicious. When they reboot the computer or stop-start the service/daemon, the zero-day exploit is launched.

It’s a rarity that I don’t find one of these locally exploitable executable files on any computer that I audit, but sometimes I have to search a handful or a dozen or so computers to find one. When I do find them, I alert the customer and then the vendor. These are usually global mistakes that impact every customer who has the same installed program (and version). In most cases the vendor fixes the issue on its next version update. In a few instances, I’ve had the vendor push a new update to fix the problem, and then claim the original problem, which I documented and had screenshots of, didn’t exist. That’s OK, at least it’s getting fixed.

Excessive network folder permissions

I often check network folder permissions, especially logon folders that every user can access. These logon folders often contain shared executables or scripts that are executed for every user and device that logs on. Again, I often find overly permissive executables or scripts that any user can modify and will impact every other user logging on. I’ve found this mistake in some of the world’s largest companies. In fact, the larger they are, the more likely it is that I’ll find this issue.

Overly permissive reads

I look for Everyone Read folders. It is a common permission to find, even Everyone Write, on folders and shares that are meant to be used by every user. Examples include: WindowsTemp or  Temp, /etc, /bin. What I look for is all the non-default folders and shares, something like /Human Resources, Payroll. It usually doesn’t take long crawling around the average file server (check all drives and shares) to find an overly permissive permission.

A special subset I often find is regarding backup files. Admins often back up large sets of data to “spare” drives and shares when troubleshooting an issue, or even as a regular part of their backup scheme. Almost always the folders or shares holding these backups have overly permissive permissions. So, take note of backup folders and shares when you find them.

Go up a folder

For a book I’m writing, a Fortune 50 vendor gave me access to requested public data within a particular subfolder on a global drive share. The vendor said, “You can access and use anything here,” along with the link. It was on a global photo sharing website. The view of the folder allowed me to “go up a parent folder” and when I clicked on it, I had access to hundreds of other folders, many I’m sure containing non-public information. After confirming what I was seeing, I contacted the company representative who assured me that they would get the issue resolved. It’s all in a day’s work.

How to solve the incorrect permissions problem

The obvious solution is to look for the incorrectly set permissions. Myriad computer security tools can make the task easier. You just define what permissions you are looking for, put in a range of computers, give it the right security credentials to do the job, and it will return a list of what meets the criteria. If you don’t have one, just do an internet search on “tools check file permissions”. You’ll get back dozens of possible candidates, including free (limited) editions of some pretty powerful commercial versions.

Do periodic audits on all computers and devices storing sensitive data. This often requires that you first have a good inventory of where that data is. Make sure that all data stakeholders understand that sensitive data requires period file, folder and database permission auditing. Make them responsible for it. Then do period spot checks to see if they are doing their technical fiduciary audits.

Of course, finding issues after the fact is more costly than fixing the problem before it’s a problem. When anyone puts up a new server, application or sensitive data repository, make verifying permissions a part of the go-live check list. If someone installs a new program on a computer for the first time in the environment, do a permissions check after it is installed. Recognize that deploy and decay is not your friend and is a big reason for overly permissive permissions. It’s easy to get sloppy.

Overly permissive permissions may or may not be the fourth biggest cybersecurity risk, but given the headlines about permissions mistakes exposing huge amounts of data, it sure seems to be the case. Since we are going even more into cloud-based servers and services, make checking file permissions a part of your security culture.


Roger A. Grimes is a contributing editor. Roger holds more than 40 computer certifications and has authored ten books on computer security. He has been fighting malware and malicious hackers since 1987, beginning with disassembling early DOS viruses. He specializes in protecting host computers from hackers and malware, and consults to companies from the Fortune 100 to small businesses. A frequent industry speaker and educator, Roger currently works for KnowBe4 as the Data-Driven Defense Evangelist and is the author of Cryptography Apocalypse.

More from this author