Low-Hanging Fruit Series: Permissions

At VDA Labs we work with a variety of companies both large and small. During our engagements, we see many of the same reoccurring issues that allow us access to systems. To help combat these threats VDA is starting a blog series we are calling “Low-Hanging Fruit”. Throughout this series we will be talking about the most common issues we see along with how each issue can be combated. In our previous piece we talked about implementing multi-factor authentication and some of the troubles we see with implementations. This piece of VDA’s series will be on why organizations need to be more careful with permissions and giving users exactly what they need to work and no more.  This is called the principle of least privilege.

SharePoint Online and OneDrive: Turning Small Breaches Into Large Breaches

VDA’s ethical hacking attacks on organizations often begins by externally breaching staff by spraying common passwords like “Fall2019” at login portals. Most commonly in 2019, our first portal we start hammering on is an organizations O365 login. Once we gain access to any employees O365 account we start searching through the SharePoint services and other users OneDrives. VDA’s goal is to find any information that could help us continue to dig deeper (land and expand). One of VDA’s favorite places to search is Delve in O365.  Using Delve, we can discover other related users along with their documents or email attachments depending on security.

From Delve we can often understand if users have overreaching permissions – opening an organization to unnecessary risk. For example, a call center employee has no reason to be able to get into financial documents or HR documents. If that call center employee needed access to a subset of financial documents for a special project then that access should be limited in both time and scope.

During one of VDA’s engagements, we discovered that almost every user had various files shared with everyone regardless of their position or what the file was. When we asked about this, VDA discovered that every user had a folder called “Share with everyone” on their OneDrive. This folder was created for easy collaboration but in the end, poor user education meant that many files that should have been confidential where placed in this folder for ease of use.  Setups like this make it too easy for attackers to pillage with ease.

External Access: Just Because You Can, Doesn’t Mean You Should

Another large vulnerability we see is over permissive external access privileges. Many of the organizations we work with provide VPN access to every employee regardless of their role. VDA has seen organizations where every warehouse employee had access to the organizations global VPN with no type of limited access. Best practice is to limit VPN access to only users who need access and to provide VPN access to only the resources they need access to.

Some readers might be thinking to themselves “we use Citrix, RDS, or VMWare Horizon for all of our external access, so we are protected.” At VDA we have seen many implementations of VDI that still open organizations up to attacks. For example, although it may seem like RDS Remote Apps is a secure way to deploy applications remotely to all users, VDA has previously escaped clients Remote App’s sandbox. In one particular engagement VDA noticed that every user had access remotely to one Remote App. Abusing this setup, we were able to gain shell access on a RDS server remotely. If users don’t need to work remotely don’t give them the ability to connect remotely.

Create Users with the Principle of Least Privilege: Permissions Can Always Be Added Later

Before my time at VDA I was a blue team member for various organizations. One of the issues I saw that consistently caused permission bloat and inadvertent access was copying other similar user profiles during user creation. User profiles tend to acquire permissions as they age. When copying a profile the new user would end up with far more access than they should.  In order to fix this problem we created template users for each department and had only those permissions assigned at user creation.

If non-standard permissions such as VPN access or confidential share access were required, a form would need to be filled out and a ticket would be created for a permissions change. This has the dual benefit of fulfilling the idea of least privilege and providing an audit trail for who, when, and why permissions were changed.

Permissions Are Easier to Change Now Than in the Future

In summary, we want to talk about the idea of building our infrastructure secure from the start. Every project I started as part of the blue team involved understanding how to implement best practices and security for each product we used. Once a project or program is in production, it can be difficult to get the downtime needed to correct the permission and security issues along with needing to worry about unintended consequences of those changes. Temporary “Just make it work” fixes frequently become permanent and this technical debt quickly adds up.

System Administrators and Engineers should be taking the time during project implementation to understand the levers used by a system to control security and permissions. During the implementation phase it is much easier to test how various changes work and to fix any issues that might arise because of a secure configuration.  VDA would love to help your organization test the security of their staff with this and other advanced techniques, contact us about security engineering or security testing today.