코드 시리즈로 보안 인프라를 정복하는 코더 시리즈: 잘못된 보안 구성 - 부적절한 권한

Threats to cybersecurity these days are ubiquitous and relentless. It's gotten so bad that trying to keep up with them after programs are deployed has become almost impossible. Instead, shrewd organizations are embracing the concept of infrastructure as code, whereby developers contribute to crafting secure applications while they are still being created. This series is all about getting you security-ready, so you can understand steps you can take as a developer to begin deploying secure infrastructure as code in your own organization.

Security misconfigurations, especially those of the improper permissions variety, most often happen whenever a developer creates a new user or grants permission for an application as a tool in order to accomplish a task. For example, this could be done to collect information from a database. But if the permissions for the new user are set too high, or not configured by default for the task at hand, it can introduce a serious vulnerability into the code.

Before we get into it, why not test your skills right now? Try to find and fix some improper permission vulnerabilities:

How did you do? Let's dig a little deeper:

Giving a user or application full permissions, or simply never bothering to define what the new user should be able to accomplish and what behaviors are restricted, is certainly the fastest way to get new code in place. And if all goes perfectly well, the application will make use of those permissions to accomplish its assigned task. The danger is that a hacker will discover this process and then compromise that user. Even though the user was created to accomplish a specific function for a particular application, if compromised it can allow an attacker to endanger other applications, data or even the network.

How are security misconfigurations exploited?

To visualize the danger, let's take a look at how a common task is sometimes coded within the Docker cloud environment. Let's say that a developer is using the Prometheus MySQL Exporter service to collect information from a database. The easiest way to allow that to happen is to grant the exporter permission to access the database. So the code might be something like:

FROM mysql:latest
   COPY ./scripts/create_users.sh /docker-entrypoint-initdb.d/
   USER 999
     CREATE USER exporter@% IDENTIFIED BY $EXPORTER_PASSWORD;
       GRANT ALL ON *.* TO exporter@%;
       GRANT SELECT ON performance_schema.* TO exporter@%;

This would certainly make it so that the exporter could accomplish its task. However, because the permissions are not defined, the exporter actually has the ability to do almost anything. Obviously, the exporter itself would never act outside of its programmed behaviors. But what would happen if an attacker were able to compromise the exporter service? In that case, because it was given full permissions, the attacker could perform all kinds of unauthorized tasks with the SQL service.

Securing and eliminating improper permissions

Here again, we turn to the concept of infrastructure as code. If you code security into your applications as they are being created, then the network is always going to be on a much better overall footing when it comes to cybersecurity.

In the Docker example from above, if a developer wants the Prometheus MySQL Exporter to be able to query a database, they can make that happen more safely by defining what it should be allowed to accomplish. A good example of this would be:

FROM mysql:latest
COPY ./scripts/create_users.sh /docker-entrypoint-initdb.d/
USER 999
   CREATE USER exporter@% IDENTIFIED BY $EXPORTER_PASSWORD;
   GRANT PROCESS, REPLICATION CLIENT ON *.* TO exporter@%;
   GRANT SELECT ON performance_schema.* TO exporter@%;

In this case, the MySQL user configured for the Prometheus MySQL Exporter service only has restricted permissions over the MySQL service. Specifically, only PROCESS and REPLICATION CLIENT privileges are allowed. This would prevent a malicious user from taking advantage of a compromised Prometheus MySQL exporter service.

Restricting permissions at the code level can ensure that users and applications only have enough permissions for the task at hand. And that can go a long way to securing your networks and embracing the concept of infrastructure as code.

Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try our showcase of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.