OS Command Injection
Video Activity
Operating System Command Injection (or OSCi) is a severe security flaw that allows malicious users to execute shell commands on a remote system. In this AppSec Tutorial, developers will see how an OSCi attack is performed, then learn how to defend their code against this threat
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Time
1 hour 41 minutes
Difficulty
Beginner
Video Description
Operating System Command Injection (or OSCi) is a severe security flaw that allows malicious users to execute shell commands on a remote system. In this AppSec Tutorial, developers will see how an OSCi attack is performed, then learn how to defend their code against this threat
Video Transcription
00:06
Absecon Tutorials OS command injection
00:09
about this course
00:12
operating system. Command injection is a type of application, security, vulnerability and the family of injection flaws.
00:19
The presence of this flaw in applications code could allow malicious users to cause far reaching damage.
00:25
In this course, you'll see an example of how this weakness can be exploited and then how it can be fixed to get the most out of this course. If you haven't already done so, we recommend that you take our introduction to Web applications Security Course First
00:40
OS commend Injection attacks can be performed in a variety of ways. The goal, however, is always the same, and that is to run shell commands on a target system. Hello, my name is Kevin Richard, and I'm a security researcher. With VERACODE.
00:54
Today, I'd like to provide a brief demonstration of the application security weakness called operating system command injection or OS command injection. For short
01:03
to do so, I'm going to use an application called Very Insecure, a Web app we're building to demonstrate a number of real security vulnerabilities.
01:11
Let's get started.
01:14
Take a look at the page on my screen.
01:17
In another course, I shared an example of a page that a visitor could use to download certain files.
01:23
Now here's the simple admin view behind that page, with which an internal user could add or remove files from that drop down box.
01:32
We have a control that lists the currently available files and options to either add or remove files
01:38
at the surface. This appears to be a simple and straightforward feature.
01:42
As I will demonstrate, however, this page is vulnerable to an OS command injection attack.
01:49
Let's assume the role of an attacker, one who will seek to use this application in ways that its creator did not intend or expect.
01:57
In this example, the attacker wants to ultimately find out how to abuse this pages functionality in order to carry out prohibited actions against it.
02:07
In this case, although the attacker cannot access the application source code, they can still in for properties about it, based on the applications behavior or on previously observed mistakes in other applications.
02:21
In this case, the attacker wants to know how the instruction to remove a book is represented behind the scenes
02:27
and wants to know how the application handles input from its users.
02:31
We can inspect such an operation by using a type of tool called an intercepting proxy which can interrupt and modify all http traffic used inside of this application.
02:43
Here, I've selected one of the most popular tools of this kind called birk proxy.
02:49
I will ask this tool to start monitoring my browser's traffic,
02:53
then select a new file
02:54
and click remove
02:57
when I click the button. Notice that nothing happens yet because in a separate window, Burke has intercepted the http request that my clique had just created
03:07
and we'll hold on to it so that I can inspect or modify properties of it before releasing it.
03:12
So we'll switch to Brooke to inspect that request.
03:16
The post body of the request reveals some interesting things about how this operation is to be performed.
03:23
In fact, between all of the possible ways to implement this procedure
03:27
are fictional Developer probably chose the most insecure off them. All
03:31
the files are literally accessed by their name on desk, clearly visible within the request which does court the risk of directory traverse A ll attacks
03:42
even more dangerous than that. However,
03:44
that file name appears to be the lone argument to an OS level commend contained within that request.
03:50
Recall that in Windows D L is the command to delete a file.
03:54
Had this pen Olynyk system, we might have seen an R N command instead.
04:00
In any case, this is a command for the operating system and not the application to perform.
04:06
If the attacker thinks about this for just a moment, knowing that this command will be run on a back end system inspires a host of possibilities for Missy's,
04:15
we could, for example, try to use directory traverse A ll, attacks toe, locate and delete files for which we weren't given access.
04:23
However, we can do much more than that
04:26
because the command itself is visible in the post body. I can change it from Dell to any other single command.
04:32
But better still, if I want to perform or complex operations, the command show can itself invoke a new command shell
04:42
to prove that this is possible. I'll change Del to see MD dot e x e, which will start a new command show and allow us to run new commends or execute herbal programs.
04:53
Vulnerability of this scale, if not diminished by access, permissions or other countermeasures, could open the door to potentially anything that you can imagine on this system.
05:03
For instance, I'll have the shell rename a file in the directory.
05:08
So let's specify the file
05:11
and that we want to change its name to you have been hacked dot t x t.
05:15
Then let's have Burke release the request to that it was holding so it can finally reach the server and complete.
05:25
And indeed, when I checked the location on desk, this file name has been illicitly changed.
05:30
It doesn't have to end there, though
05:32
anything that an internal user of this application could do from their own command line up loading and running scripts pivoting into other systems and so on. The attacker can now do remotely if there are no other restrictions in place.
05:47
Disability creates a very serious liability for the designer of the application and its users, as this weakness could potentially compromise all data connected to this system.
05:59
To summarize this demonstration, if an attacker is allowed to specify any portion of an OS commend to be run via an application,
06:06
it may be possible to misuse this ability in a variety of very serious ways.
06:12
The level of exposure depends on the effectiveness of input validation routines, if any.
06:17
Also, please note that this is only one example of Allah's command injection and does not represent every possible setting for this flaw.
06:26
Toe learn more about different kinds of payloads and attacks as well. A steps for remediation.
06:30
Please continue to watch our training videos or participate in our training courses.
06:35
This is Kevin Richard from Perricone. Thank you very much for watching.
06:41
If a valid O s command injection flaw has been detected in your application, the next step is to update your code in order to remediate it.
06:48
Click on any tab to see how to secure your code from the threat of OS command Ejection.
06:58
Hello again. This is Captain Richard, security researcher with Erica. And you've been watching our absent Victoria Ll on OS Commend injection
07:06
in the last section. We revealed how an attacker might discover and exploit an instance of this very severe vulnerability and explained how it could potentially grant direct access to the operating system of a restricted host.
07:19
Now that you've gained a basic understanding of this threat,
07:23
let's demonstrate how to fix it.
07:26
As is often the case in upset. There are a few possible ways to remediate OS command injection,
07:30
so I encourage you to select the strategy that best applies to your application and its unique circumstances.
07:40
First, let's examine the code from our previous example that was used to remove the files from the directory.
07:46
Recall that when the user clicks the remove button, the Web application takes the books of the user has selected
07:51
and includes these in an OS level command that will delete the corresponding files on disk
07:59
wants to use her supplied string reaches the job back end the command that it contains will be executed. The recall to java dot lined up run time, not exact.
08:09
We'll focus our attention on this line because this is the line that triggers the vulnerability.
08:15
If you're watching this video because veracode his flight OS commend injection flaws in the skin of your application, chances are each flaw points to a call to this method somewhere within your code.
08:26
In our example, the input comes from a Web browser, but that's not what makes this operation vulnerable
08:33
here. What's significant is that the user has had the ability to temper with the data while it was still in transit.
08:39
So for this reason, we demonstrated how to use Bert Proxy to modify the raw data of http requests.
08:48
Changing the data sent by the Web client will directly impact the command that the job back and shells out later
08:56
when it comes to addressing US command injection. The best recommendation is actually to avoid the use of operating system calls all together whenever it's possible to do so.
09:07
This is for two reasons.
09:09
First, the risk incurred by shelling out client data, as the US is in most cases simply too great.
09:16
Second, there is often an existing A P I or library call that can be used in place of an external process.
09:22
In our example, it's possible to remove this call to exact and instead delete the file by treating it as a file object and calling it's delete method, as shown here
09:35
in general for solutions where you're certain that you need to invoke a new process. The preferred method in Java is to use the process builder class instead of wrong time dot exact.
09:46
This is the job of a P I for creating OS processes and because it doesn't run through the shell. It does not require any special validation to avoid injection attacks.
09:58
If there is no a pl our library call that can take the place of a new process, and if it is absolutely necessary to include data that comes from a user controlled source, then it is essential that you validate the data before executing the command
10:13
in performing validation. It is usually much easier to define a set of acceptable characters than to try to define the complete set of characters to reject.
10:22
Therefore, we recommend that you apply a contextual white list to the data instead of trying to create a black list for the target environment in question.
10:31
In our previous example, we might have chosen to apply your rule that only allowed, create or delete commands in keeping with the two buttons shown on screen.
10:39
Then we want to ensure that the file name we pass is an argument is legal, so we could validate that it's of the form file name dot file extension.
10:48
But again, in this case, the best recommendation would still be to redesign this workflow so that it no longer uses any shell commands at all.
10:58
Additionally, in Java, if you are using run time dot exact, it may be possible to switch to a safer overload of this method.
11:07
There are six total versions of this method, and each provides a different set of possible restrictions on the scope of the operation.
11:13
For example, instead of using the version that just takes an entire command is an argument, we can switch to the version that takes a string right in which the first member of the array is the command itself, and every other element is treated as an argument.
11:28
We would then hard code the command that we wish to execute, isolating it from user control
11:33
and believe only the user's choice of book as a dynamic attributes.
11:39
This choice, in turn, would still need to undergo validation
11:43
as a final note. The flaw in our example represents an extreme form of OS command injection. I'll bite not one without precedent.
11:52
If America Skin has reported this flaw in your application,
11:56
it's possible that the details of these issues will differ from the exploit that you've just seen
12:01
in particular. If the arguments to your command are strictly controlled
12:05
or if it can be shown that user tempering is not possible,
12:09
then the floor may be a candidate for mitigation by design.
12:13
Additionally, some instances of this flaw that occur with industrial environments may be candidates for mitigation by OS environment.
12:22
If you would like more information, please schedule a consultation call with our security consulting team or contact for Could support.
12:30
This has been kept in Richard from Veracode. Thank you very much for your time.
12:37
Hello again. This is Kevin Richard, security researcher with Erica, and you've been watching our AB secretarial on OS Commend injection
12:46
in the last section, we revealed how an attacker might discover and exploit an instance of this very severe vulnerability and explained how it could potentially grant direct access to the operating system of a restricted host.
13:00
Now that you've gained a basic understanding of this threat,
13:03
let's demonstrate how to fix it.
13:05
As is often the case in upset, there are a few possible ways to remediate OS command injection,
13:11
so I encourage you to select the strategy that best applies to your application and its unique circumstances.
13:18
First, let's examine the code from our previous example that was used to remove the files from the directory
13:24
recall that when the user clicks the remove button,
13:28
the Web application takes the books of the user has selected
13:31
and includes these in an OS level command that will delete the corresponding files on disk.
13:37
Once the user supplied string reaches the dot net back and the command that it contains will be executed to recall two system dot diagnostic stop process starts starts.
13:48
We'll focus our attention on this line because this is the line that triggers the vulnerability.
13:54
If you're watching this video because veracode his flight OS commend injection flaws in the skin of your application, chances are each flaw points to a call to this method somewhere within your code.
14:05
In our example, the input comes from a Web browser, but that's not what makes this operation vulnerable
14:13
here. What's significant is that the user has had the ability to temper with the data while it was still in transit.
14:18
So for this reason, we demonstrated how to use Bert Proxy to modify the raw data of http requests.
14:26
Changing the data sent by the Web client will directly impact the command that the back end shells out later
14:35
when it comes to addressing US command injection. The best recommendation is actually to avoid the use of operating system calls all together whenever it's possible to do so.
14:46
This is for two reasons.
14:48
First, the risk incurred by shelling out client data, as the US is in most cases simply too great.
14:54
Second, there is often an existing A P I or library call that can be used in place of an external process.
15:03
In our example, it's possible to remove this call to process, starts start and instead delete the file by treating it as a file object and calling It's delete method has shown here.
15:16
If there is no A P I or library call that can take the place of a new process, and if it is absolutely necessary to include data that comes from a user controlled source, then it is essential that you validate the data before executing the command.
15:31
In performing validation. It is usually much easier to define a set of acceptable characters
15:37
than to try to define the complete set of characters to reject.
15:41
Therefore, we recommend that you apply a contextual white list to the data instead of trying to create a blacklist for the target environment in question.
15:48
In our previous example, we might have chosen to apply your rule that only allowed, create or delete commands in keeping with the two buttons shown on screen.
15:58
Then we want to ensure that the file name we pass is an argument is legal,
16:03
so we could validate that it's of the form file name dot file extension.
16:07
But again, in this case, the best recommendation would still be to redesign this workflow so that it no longer uses any show commands at all.
16:18
As a final note, the flaw in our example represents an extreme form of OS command ejection. I'll bite not one without precedent.
16:26
If America Skin has reported this flaw in your application,
16:30
it's possible that the details of these issues will differ from the exploit that you've just seen
16:36
in particular. If the arguments to your command are strictly controlled
16:40
or if it can be shown that user tempering is not possible,
16:44
then the farm may be a candidate for mitigation by design.
16:48
Additionally, some instances of this flaw that occur with industrial environments may be candidates for mitigation by OS environment.
16:56
If you would like more information, please schedule a consultation call with our security consulting team.
17:02
More contact for could support.
17:04
This has been kept in Richard from Veracode. Thank you very much for your time.
17:11
The scope of this course was not intended to cover every possible circumstance in which OS come injection could arise. Rather, it was designed to convey the basic idea of this flaw.
17:21
Further information is available through the following links.
17:26
Thank you for viewing this opsec tutorial on OS command injection.
Up Next
Instructed By
Similar Content
