Coders Conquer Security Infrastructure as Code Series - Using Components From Untrusted Sources

Published Jun 15, 2020
by Matias Madou, Ph.D.
cASE sTUDY

Coders Conquer Security Infrastructure as Code Series - Using Components From Untrusted Sources

Published Jun 15, 2020
by Matias Madou, Ph.D.
View Resource
View Resource

We're nearing the end of our Infrastructure as Code series, but it has been great to help developers like you on their IaC security journey.

Have you been playing the challenges? What's your score so far? Before we get started, let's see how much you already know about the pitfalls of using components from untrusted sources:

Still have some work to do? Read on:

The vulnerability-inducing behavior that we are going to focus on today is using code from untrusted sources, a seemingly benign practice that is causing big problems. There are many advantages to using open source code and resources. In general, it allows experts to contribute their ideas, work and even completed code to repositories like GitHub to be used by others struggling to make a program or an app behave properly. Using completed code to govern program functions saves developers from having to reinvent the wheel every time they need to create a new application.

However, using code snippets from unreliable, unvetted or even potentially dangerous sources carries a lot of risk. In fact, using code from untrusted sources is one of the most common ways that both major and minor security vulnerabilities creep into otherwise secure applications. Sometimes, those vulnerabilities are accidentally induced by their creators. There have also been instances where malicious code was written by potential attackers. The code is then shared with the hope of ensnaring victims who will drop it into their applications.

Why is using code from untrusted sources dangerous?

Let's say a developer is in a hurry and needs to configure an application they are developing. That can be a tricky process. So instead of spending a lot of time trying to work out every possible configuration, they do a Google search and find someone who has already completed a seemingly perfect configuration file. Even though the developer knows nothing about the person who wrote the code, adding it to a new application is relatively easy. It can be done in the Docker environment using two lines:

RUN cd /etc/apache2/sites-available/ && \
   wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
   9d372cfa8855a6be74bcca86efadfbbf/raw/\
   fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf

Now the Docker image will dynamically pull in the third party config file. And even if the file is tested and found to be okay at the time, the fact that the pointer is now embedded in the new application's code means that there is a permanent dependency in place. Days, weeks or months later, the file could be altered by the original author or an attacker who compromised the code repository. Suddenly, the shared config file can tell the application to perform very differently than intended, possibly giving access to unauthorized users or even directly stealing data and exfiltrating it.

A better way to use shared resources

If your organization allows the use of code from outside sources, then processes must be put in place to ensure that it is done safely. When evaluating outside code for potential use, be sure to acquire components from official sources only using secure links. And even then, you should never link to an outside source to pull in that code, as that removes the process from your control. Instead, approved code should be brought into a secure library and only used from that protected location. So in a Docker environment, the code would look like this:

COPY src/config/default-ssl.conf /etc/apache2/sites-available/

Instead of relying on remote third party configuration files, this would instead rely on a local copy of those files. This will prevent any unexpected or malicious changes from being made.

In addition to using a secure code library, a patch management process should be put in place to continually monitor components throughout the software lifecycle. All client and server-side components should also be checked for security alerts using tools like NVD or CVE. Finally, remove any unused or unnecessary dependencies and features that might come along for the ride with the outside code.

By following these steps, developers can more safely make use of external resources without accidentally inducing vulnerabilities into their applications and 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 a demo of the IaC challenges in the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.



View Resource
View Resource

Author

Matias Madou, Ph.D.

Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.

Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.

Want more?

Dive into onto our latest secure coding insights on the blog.

Our extensive resource library aims to empower the human approach to secure coding upskilling.

View Blog
Want more?

Get the latest research on developer-driven security

Our extensive resource library is full of helpful resources from whitepapers to webinars to get you started with developer-driven secure coding. Explore it now.

Resource Hub

Coders Conquer Security Infrastructure as Code Series - Using Components From Untrusted Sources

Published Jun 15, 2020
By Matias Madou, Ph.D.

We're nearing the end of our Infrastructure as Code series, but it has been great to help developers like you on their IaC security journey.

Have you been playing the challenges? What's your score so far? Before we get started, let's see how much you already know about the pitfalls of using components from untrusted sources:

Still have some work to do? Read on:

The vulnerability-inducing behavior that we are going to focus on today is using code from untrusted sources, a seemingly benign practice that is causing big problems. There are many advantages to using open source code and resources. In general, it allows experts to contribute their ideas, work and even completed code to repositories like GitHub to be used by others struggling to make a program or an app behave properly. Using completed code to govern program functions saves developers from having to reinvent the wheel every time they need to create a new application.

However, using code snippets from unreliable, unvetted or even potentially dangerous sources carries a lot of risk. In fact, using code from untrusted sources is one of the most common ways that both major and minor security vulnerabilities creep into otherwise secure applications. Sometimes, those vulnerabilities are accidentally induced by their creators. There have also been instances where malicious code was written by potential attackers. The code is then shared with the hope of ensnaring victims who will drop it into their applications.

Why is using code from untrusted sources dangerous?

Let's say a developer is in a hurry and needs to configure an application they are developing. That can be a tricky process. So instead of spending a lot of time trying to work out every possible configuration, they do a Google search and find someone who has already completed a seemingly perfect configuration file. Even though the developer knows nothing about the person who wrote the code, adding it to a new application is relatively easy. It can be done in the Docker environment using two lines:

RUN cd /etc/apache2/sites-available/ && \
   wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
   9d372cfa8855a6be74bcca86efadfbbf/raw/\
   fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf

Now the Docker image will dynamically pull in the third party config file. And even if the file is tested and found to be okay at the time, the fact that the pointer is now embedded in the new application's code means that there is a permanent dependency in place. Days, weeks or months later, the file could be altered by the original author or an attacker who compromised the code repository. Suddenly, the shared config file can tell the application to perform very differently than intended, possibly giving access to unauthorized users or even directly stealing data and exfiltrating it.

A better way to use shared resources

If your organization allows the use of code from outside sources, then processes must be put in place to ensure that it is done safely. When evaluating outside code for potential use, be sure to acquire components from official sources only using secure links. And even then, you should never link to an outside source to pull in that code, as that removes the process from your control. Instead, approved code should be brought into a secure library and only used from that protected location. So in a Docker environment, the code would look like this:

COPY src/config/default-ssl.conf /etc/apache2/sites-available/

Instead of relying on remote third party configuration files, this would instead rely on a local copy of those files. This will prevent any unexpected or malicious changes from being made.

In addition to using a secure code library, a patch management process should be put in place to continually monitor components throughout the software lifecycle. All client and server-side components should also be checked for security alerts using tools like NVD or CVE. Finally, remove any unused or unnecessary dependencies and features that might come along for the ride with the outside code.

By following these steps, developers can more safely make use of external resources without accidentally inducing vulnerabilities into their applications and 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 a demo of the IaC challenges in the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.



We would like your permission to send you information on our products and/or related secure coding topics. We’ll always treat your personal details with the utmost care and will never sell them to other companies for marketing purposes.

To submit the form, please enable 'Analytics' cookies. Feel free to disable them again once you're done.