In this video, you will learn to describe OS command injection attacks and the operating system flaws that allow them to occur. Explain why your applications should not execute OS commands, but use library functions instead. Explain why it is important for applications to run under the least possible privilege level. So let's start with the OS command injection. OS command injection is abuse of vulnerable application functionality that causes execution of OS commands that are specified by the attacker. No one operating system is immune to it. It can really happen on any operating system, Linux, Windows, Mac, because the vulnerability is really not in the operating system per se, it's the vulnerable application that makes it happen. These types of vulnerabilities are made possible by lack of input sanitization and also by unsafe way in which developers often execute those commands. Let's look at a concrete example. Let's say you have an application where you as one of the types of functionality that you support, you manage log files. Log files are stored as real files on the operating system. Let's say we have an interface here where we lists log files and give users ability to view by clicking on the log file and to delete, there's a little Delete icon next to each individual log file. Sounds like a fairly common scenario. Let's assume that delete command is sent as opposed to request when you click on it and, of course, we need parameters to send to the server and in this particular case, we send action, which is delete, and we send the file name. Assuming that Java is the implementation language, it's very likely what's happening on the backend is the exact function from the run-time class, gets executed, and we send the file that was specified with the full path to a remove command to the Shell Interpreter. Those of you who are familiar with Linux should recognize this pattern, those who are not, this is basically calling the Shell Interpreter and passing it an operating system command line command to it which RM is the command to delete the file. So in the end, what get's executed by the operating system is this line at the bottom, the shell interpreter with the parameter and a command in double-quotes. So what's the worst that would happen in this scenario? Because application user essentially specifies the filename and we assume that in our application we have no defensive code to verify that that file perimeter is correct, attacker really can pass anything as that parameter. In this example here, attacker could specify a simple system library, for example. You notice the dot dot convention, so in this case, attacker tells the system to travel up three folders and then down to Delete folder and then delete a system library. If there are no protections in place, this command that was originally intended, Delete log files, will actually delete an important operating system library causing denial of service. Your server will not be operational after that point, that's pretty bad. Regular user of your application just basically crash the server. But something else can also happen. The attacker can actually use Linux command syntax to inject another operating system command which is much, much worse. So in this particular case, the text in red is the text that's supplied by the user or the attacker, and let's say the file name is X, it's not really relevant what the actual filename is because there's a semicolon there and that notation means that when we're done executing the Remove command, go ahead and execute something else whatever comes after the semicolon. Semicolons in Linux is used to separate or chain together multiple OS commands. In this case, the RM-RF slash command actually on many systems would cause deletion of the entire file system which is as bad as it gets. Operating system command injection can lead to all kinds of bad outcomes. You could have full system takeover. You could have denial of service. Attacker could leak sensitive information, passwords, cryptographic keys, user personal information, confidential business data. Attackers could move to other systems. They could use your system once they've taken over it. They can move to other computers on the network, they can use it as a launching pad, and as we know, now the botnets and cryptomining are very popular forms of abuse that could happen as well. As soon as you give an attacker a way to execute an operating system command, they could do pretty much anything they want on that machine. So it's as bad as it gets. It's a game over type of event. How do we prevent this? So the first recommendation is not execute OS commands. It sounds funny. I'm not trying to make a joke here. Executing OS commands is a tool that in most cases is too heavy for the job. There are more lightweight ways of doing things, and by adding OS command execution into your application, you're adding this very wide attack surface that if you're not careful can easily be abused. Often OS commands introduces a quick fix. So let's say you want to delete the file but you don't want to figure out how to properly do it in the language that you're writing in so you think, well, let's just run the OS command, it'll be quick and easy. Essentially, you let the operating system do the heavy lifting. But as we saw in the example before, if you're not careful, a destructive OS command may slip in and cause a lot of damage. So we recommend that when you're faced with a case like this, it's best to resist the temptation to run OS commands and instead, use the functionality built-in to your language you're using or use third-party libraries. Here are some examples. If you want to remove a file, there's a function for that in Java built-in. If you want to copy a file, same story. There are examples of that in Java and in other languages. In most cases, you can avoid running an OS command. By using the library functions, the big benefit of that is that you significantly reduce the attack surface. If you run the OS command, somebody can specify any command they want. But if you are using a library function to remove a file, your attack surface narrows dramatically and it can only be abused to delete a single file elsewhere in the system and we will show later on how to protect against that, but you can see that it's now far less dangerous. So the secondary conditions we would give is to run at the least possible privilege level. We often see applications run as superuser, as root user, and in vast majority of cases that is not necessary. The problem with that is that if attacker does abuse your application functionality, if that application runs at a very high level of privileges, the attacker can do a lot of damage. So let's say if you were allowing it to delete a particular file, if application runs as the root user, it can delete all kinds of important operating system files, but when it runs as tomcat user, for example, that set of files that can be deleted narrow significantly and far less damage could be done. Actually, this recommendation running at the least possible privilege level helps in case of many other vulnerabilities, not just injection.
