It's time for the next installment of our Infrastructure as Code series, the blogs that will take developers like you to a whole new level of security awareness when deploying secure infrastructure within your own organization.

Oh, by the way... how did you fare with the security misconfiguration challenge in the previous blog? If you want to go ahead and tackle a missing functional level access control vulnerability right now, head on over to the platform:

(The link above will take you to the Kubernetes challenge, but once youre on the platform, use the drop-down to choose from Ansible, CloudFormation, Terraform or Docker as well. Your choice.)

Almost every application deployed today has some kind of access control mechanism that checks to see whether or not a user has permission to perform the requested functions. It's pretty much the cornerstone of good security, as well as functionality, when creating an application. In fact, all web applications need access controls in order to allow users with different privileges to use the program.

Problems can occur however when those same verification functions for access control are not performed at the infrastructure level, or are misconfigured. Without infrastructure-level access control in perfect order, it opens up an entire enterprise to hackers, who can use that vulnerability as their gateway for either unauthorized snooping or a full attack.

In fact, exploiting missing or misconfigured function access control vulnerabilities is extremely easy. Attackers don't even need to be overly skilled. They just need to know what commands execute functions within whatever framework is supporting the application. If they do, it's just a matter of trial and error. They can continually submit requests that shouldn't be allowed, and as soon as one succeeds, the targeted website, application, server, or even the entire network could be exposed.

How Do Missing Function Level Access Control Exploits Work?

There are a few ways that function level access controls can creep into an organization. For example, function level access can be left to an application and not verified by the underlying infrastructure. Or, infrastructure-level access control can be misconfigured. In some cases, administrators assume that non-authorized users won't know how to get to infrastructure resources that only higher-level users should be able to see and use a "security by obscurity" model which rarely works.

For an example of security by obscurity, the following URL is likely vulnerable to attack:

http://companywebsite.com/app/NormalUserHomepage

If an authenticated user employs a technique called Forced URL Browsing, they could try to reach a page that is only shown to administrators. An example might be:

http://companywebsite.com/app/AdminPages

If no server-side verification exists, they will simply be shown the admin pages (if its name matches the request) and will then have access to whatever additional functions that administrators do from the new page. If the server returns a "page not found" error to the attacker, they can simply keep trying until they figure out whatever name the admin page is given.

For attackers, exploiting missing function level access controls is a similar process. Instead of trying to browse unauthorized pages, they instead send in function requests. For example, they might try to create a new user with administrator rights. So their request would look something like this, depending on the framework:

POST/action/createuser name=hacker&pw=password&role=admin

If no function level access control exists, then the example above would be successful and a new administrator account would be created. Once the attacker logs back in as the new administrator, they would have the same access and permissions as any other administrator on that network or server.

The Fix for Missing Function Level Access Controls

Because it's so easy for attackers to exploit missing function level access control vulnerabilities, it's critical that they are found, fixed, and prevented. Thankfully, this is not overly difficult with some know-how and basic Infrastructure as Code security training.

The main protection will come from implementing role-based authorization at the infrastructure level. Never trust applications to handle that function. Even if they do, having infrastructure-side authorization will ensure that nothing is missed. Ideally, the authorization should come from a centralized location (for example, AWS IAM, Azure IAM, etc.) that is built into your organization's routine and applied to every new application. These authorization processes can come from the framework itself or any number of easy-to-use external modules.

Finally, your organization should embrace the concept of least privilege. All actions and functions should be denied by default, with the authorization process used to give valid users permission to do whatever they need. They should only be given enough permission to perform the required function, and only for as long as required.

Having missing function level access controls can be devastating. But thankfully, by building good infrastructure-level authorization practices into your organization, you can easily prevent this problem from ever happening.

Think you're ready to spot an access control bug in the wild? Compare these Docker code snippets; one vulnerable, one secure:

Vulnerable:

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
   tar -xvf $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER root
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

Secure:

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
   tar -xvf $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER nobody
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

Learn more, challenge yourself

Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and your customers from the ravages of other security flaws and vulnerabilities.

And if you missed it earlier, you can try an IaC gamified security challenge on the Secure Code Warrior platform to keep all your cybersecurity skills honed and up to date.

Stay tuned for the next chapter!