The Bare Beginning

I promised to deliver yet another quality content on my blog and as promised after this particular post, my true intentions were to go ahead with posting something deep on HTTP Parameter Pollution. Looking at the awareness level (read the comments for a deep approach insight on application security!) of incoming proclaimed security researchers or bug hunters, I recently decided to make my point across and let the info-sec community know the real concepts behind Application Injection vulnerabilities. This post is focused to switch off the ego gap and provide a platform for others to realize core concepts and the necessity of such concepts to be applicable to adaptive application penetration testing!

I quickly realized the core necessity of a distinguished vulnerability levels according to their categorization and be real technical about the application security issue, most focused primarily on this post on Injection level web vulnerabilities which are very common if dug enough into. On a recent conversation with many of ‘elite’ bug hunters, I noticed, there is a huge gap on the technical consciousness level they possess and likely end up only getting T-shirts for the sake of name on Hall of fame (No pun intended!). Money would encircle you girls, knowledge will encircle you girls, cars, super-bikes and alike!

Abstract

It is mandatory to understand the basic differences which prevail between shell injection or command injection and remote code execution. Both are different in a way, and are confused in a wild. Whilst command injection leads to trigger of arbitrary ‘system’ shell commands, code execution flaws are those flaws which lead to trigger of commands which the programming languages uses, such as PHP, Ruby on Rails, Perl, etc. To be able to understand the difference, a great need for a practical example has to be placed, and hence this would be in form of sample code. To be able to really understand the differences between Remote Code Execution and Command Injection or Shell Injection, one must read the discussed concepts which were laid down before in this document regarding ‘shell’.

Stripping Off Bug Hunters – Core Concepts Explained!

To be able to deliver the audience readers with the ability to differentiate between a Shell Injection or Command Injection from Remote Code Execution, I had used simpler scripts to make a sample application and deliver the exact information which should be grasped in the execution of such scripts and how it affects in a way for normal working of the web. I had used ‘PHP’ for the demonstrations, which is self-sufficient to demonstrate these vulnerabilities and the creation procedure and will be successfully able to differentiate between Shell Injection or Command Injection and Remote Code Execution. To demonstrate Command or Shell Injection, I have used a PHP script hosted in a Linux machine which serves the functionality of file deletion process. The script is as follows:

After this script hosted using the ‘Apache’ web-server, using the same PHP script, one could be able to ‘delete’ files available on that directory since ‘rm’ is a system command for the Linux environment.

Assume, that this functionality of deletion process was needed in the web application for the users to be able to ‘maintain’ there files for reasons. For a normal user, the process involves deletion of files which are in his control and the procedure is normally executed using a ‘GET’ method to a calling parameter name ‘filename’, this functionality is demonstrated below. To be able to delete something, consider a ‘junk’ file for test purposes which was to be deleted:

The steps consists of first creating the PHP script, the code for which is demonstrated already above, the next step involved were to create a file named ‘junk.txt’ and to insert some string data into it. Next, we see that listing them in the same directory using ‘ls’, the filename ‘junk.txt’ existed. Now, if we have to test if the script worked, a normal web user would want to delete this same ‘junk.txt’ for ‘maintenance’ purposes which might be a part of the web application functionality. Hence, to test we call out the script first:

The script worked just fine as it should. The ‘GET’ parameter were not passed yet. This was to test if the web-server and the script was working. Next, I would need to pass the ‘GET’ parameter named ‘filename’ and append ‘junk.txt’ in order to delete the file from the Filesystem. The file ‘junk.txt’ existed before and to be able to deduce if the script works or not, the file should be deleted from the Filesystem once the file name is passed to the ‘GET’ parameter and is triggered:

Triggering this, will delete the file from the system, hence after the passed file name was triggered to be deleted by the PHP script, the file would cease to exist from the Filesystem. However, this leads to command injection vulnerability by exploiting the features of Linux Filesystem to execute shell commands with appended ‘|’, ‘;’ or ‘&&’ characters and then passing the extra ‘shell commands’, an attacker would want to execute. To demonstrate this, the following payload would return the ‘uid’, ‘gid’ and the ‘group’ id in a Linux environment:

Triggering the above, the results obtained were:

It could be deduced, that ‘;’ character played a major role in execution of the first command which a file name being passed as a value for the ‘GET’ parameter ‘filename’, but was ended by ‘;’ character and then followed ‘id’ which brought back the results of the ‘system()’ execution from within PHP code which was supposed to be executed, if thought logically. This same result would be possible via using the pipe i.e: ‘|’ character which would pipe out the output of the first command and lead to execution of the next command after the pipe:

On a Windows environment, this could had been a ‘&&’ character being used which was demonstrated in the web shell section detailed in this document before using a vulnerable application called ‘Mutillidae’. This is what is known to be Shell Injection or Command Injection wherein system shell commands are being executed or called for a malicious purpose by an attacker to harvest more information on a target or to do much more than what is documented here.

A good command injection example with ‘Ruby On Rails’ powered applications could be seen here. Another example of a remote command injection on a CISCO based Linksys router could be witnessed here. The necessity to look at these examples is to make the reader aware of the diversity of so many variants of using command injections which could be used in a malicious way for a web attacker ‘to carry out intrusions or information harvesting operations. The point is to grasp the concept and differentiate this same vulnerability against a vulnerability called ‘Remote Code Execution’. The next section of the continuation does not only define remote code execution but would be also detailing on ‘RCE’ for an introduction demonstration which would deal off with the later concepts covered briefly in some other document.

Remote Code Execution is a vulnerability which could be exploited from a machine in a remote location which is geographically separated from the victim machine and uses the programming code such as PHP, Ruby, Perl, Python, etc. as its executed residue for a web attacker to intrude. In simpler terms, shell injections or command injection used UNIX/Linux/*nix or Windows environments shell and were dependent on their shell capabilities while in Remote Code Execution, the exploitation deals with the processing language code such as PHP, Perl, Ruby, Python, etc. and uses the injected ‘code’ as a part of the application programming language in order to dynamically alter the execution flow such that the attacker would be able to control the execution. The language allows dynamic evaluation at run-time.
Remote Code Execution is different from a Remote Command Execution. The later could again be termed as Shell Injection or Command Injection leading to execution of arbitrary commands using the capabilities of the operating system shell. In Remote Code Execution, abbreviated as ‘RCE’, the sole purpose is to use the processing language flaw because the application developer might not had stood up against mitigating the flaws at earlier stages while the application was being developed. Now, it is also to be noted that Remote Code Execution could be obtained via SQL Injection flaw, via Local File Inclusion Flaw, or Remote Code Execution could also lead to Shell Injection or Command Injection flaw. To be able to deliver the concept here, consider PHP as the programming language processor of choice running at the back-end. Having said that, as shown earlier in this document, command injection used similar PHP script, here to demonstrate remote code execution for a basic introductory demonstration, I’d be using similar script, but the functionality and the exploitation technique would be different. Remember, any shell injection or command injection which happens across the wide area network which is the ‘Internet’ could be termed as ‘Remote Command Execution’, the process of ‘injecting’ the payload is termed as ‘Remote Command Injection’. The demonstration below is for Remote Code Execution, code as in raw code which the back-end processing language supports, which might lead to arbitrary command execution but should not be confused with ‘command injection’ vulnerabilities in itself. To be able to deliver a simpler form of a PHP code which would be able to induce he concept of Remote Code Execution, consider the script below:

The functionality of the script is to use the ‘eval’ function which is included in PHP. The functionality of using ‘eval’ is to evaluate any string passed onto the ‘code’ GET parameter to be treated as a PHP code and return the operation which follows next as a result of such an evaluation. Testing if the script which was prepared was executing as it should be, we should be able to receive the rendered version of the PHP script in our browser:

This just illustrated that the script was working as it should. The only thing was to test for the functionality which could be witnessed by appending a ‘query string’ consisting of the ‘query parameter’ and the ‘query keyword’ which has to be passed as a value as a part of the query string. This query value which is to be submitted would contain a ‘payload’ which will be treated by the PHP processor as executable PHP code since the ‘eval’ function treats anything passed such as ‘strings’ into PHP context based strings for PHP based evaluation which a malicious attacker could misuse since his version of ‘string’ would be malicious in purpose. The following ‘payload’ as a part of the query keyword value will illustrate the concept for Remote Code Execution:

The appended payload consist of ‘phpinfo()’ which is a PHP function and passed as a ‘string’ for the ‘eval’ function to evaluate. Since ‘eval’ function in its nature to parse anything passed to it as PHP code would be formulated, the resultant is rich information disclosure, as observed below:

Notice, a ‘;’ was appended after ‘phpinfo()’ for the function to be terminated for execution purposes. Without such a character, the execution would not occur. The results which were obtained as a result of using the ‘eval’ function were massive information disclosure which could be useful to an attacker. PHP version numbers and all the configuration used for the back-end PHP were disclosed. This is what a Remote Code Execution looks like and this again is a distinguishing feature from Remote Command Execution, Command Injection or Shell Injection. Remote Code Execution could also be leveraged in such a way to bend the attack towards a leading ‘remote command execution’ or execution of arbitrary system shell commands which would be covered in coming research which discusses ‘Remote Code Execution’ in details. Hence, the conceptual differences between shell injection or command injection or remote command injection and remote code execution was delivered. This could be later used for security information awareness (read comments for details).

Naked Bitter Truth

As far as the differences for Code Injection goes, in the research before in this series (not yet published publicly), I resembled ‘code injection’ to be a flaw which is used via the ‘processing’ language. If the processing language is the browsers render engine which renders web-pages and use HTML, its HTML code injection. In a similar fashion, if the processor was to be PHP, the same would be PHP code injection. But the difference between HTML Code Injection and PHP Code Injection lies in its type. HTML Code Injection would be client side code injection, whilst PHP Code Injection vulnerabilities would be server side code injection since PHP runs on a web-server and processes the web logic. Having said that, I had detailed both HTML and PHP Code Injection to encircle the client side and the server side nature before. Now, to be able to differentiate between Code Injection and Command Injection, the same concept as above applies. In Code Injection, one has to introduce or inject ‘code’ taking into consideration of the language used; while in Command injection, the system shell commands would suffice enough for command execution.

Shritam Bhowmick is an application penetration tester professionally equipped with traditional as well as professional application penetration test experience adding value to Defencely Inc. Red Team and currently holds Technical Expertise at application threat reporting and coordination for Defencely Inc.’s global clients. At his belt of accomplishments, he has experience in identifying critical application vulnerabilities and add value to Defencely Inc. with his research work. The R&D sector towards application security is growing green at Defencely and is taken care by him. Professionally, he have had experiences with several other companies working on critical application penetration test engagement, leading the Red Team and also holds experience training curious students at his leisure time. The application security guy!

Out of professional expertise at Application Security, Shritam Bhowmick utilizes his knowledge for constructive Red Teaming Penetration Test Engagements for Indian Top Notch Clients and has a proven record for his excellence in the field of IT Security. A Google search with his name would suffice the eye.

Shritam Bhowmick has been delivering numerous research papers which are mostly application security centric and loves to go beyond in the details. This approach has taken him into innovating stuff rather than re-inventing the wheel for others to harness old security concepts. In his spare time, which is barely a little; he blogs, brain-storms on web security concepts and prefers to stay away from the normal living. Apart from his professional living, he finds bliss in reading books, playing chess, philanthropy, and basket-ball for the sweat. He wildly loves watching horror movies for the thrill.