Command injection is not always connected to backend applications alone like PHP, Django, Flask, Node js. Even template injection of Django could also lead to command injection which allows the attacker to leverage and typically fully compromise the entire hosting infrastructure.
Any endpoint of a web application that allows the user to enter any input value to be processed by a backend server can be a valid start point for finding any sort of injection point. Consider that respective point as the right way to insert malicious code into the application and gain any functionality the underlying backend application can offer.
By understanding how the backend application will be working to generate various payload with trial and error method to identify the valid code to inject the template, otherwise even payload which is already available on the internet can be used for brute-forcing the input parameter.
| Command | Linux |Windows | |----------|--------|--------| | Username | whoami | whoami | |OS Version|uname -a| ver | |IP address|ifconfig|ipconfig| |Int. Conn.|netstat |netstat | |Process |ps -aux |tasklist|
This the web application which is provided by the port swinger for testing and even with wappalyzer, you would not find what is backend application which is running this application so you can go by looking into the endpoints of the application.
Since the index page is already displaying the list of products, and on clicking the product there is another page that displays in detail each product and it has a URL parameter which productId=1,2,3… but unfortunately it, not the right point for command injection since it fetches the details through API which restrict all special characters.
But you can find an interesting functionality of the application which is used to check for available stocks of the current product and it has an input parameter of the location to check the product availability. So here comes the tool usage of BurpSuite, which is a proxy-based tool used to evaluate the security of web-based applications and do hands-on testing.
You have to export and install the certificate generated from BurpSuite in order to intercept the request and modify it.
Here in the request, you would see a new parameter of store id which is a hidden parameter sent from the clientside to serverside for validation. Which means this hidden parameter would be the right point for testing out payload for command injection
By tampering the storeid parameter with payload 1;id, here id is a Linux command used to view the current user groups and uid. In the assumption that the infrastructure would be running a Linux based operating system.
After modifying the request you would forward the request to the server and stop intercept to check the response in the browser and you could see their availability count and nearby command executed output. This means our payload worked in the right sense for executing out arbitrary code in the infrastructure of the hosting service.
You could also intercept the request and sent to repeater to check all kind of payload you want to check, repeater is used to send request multiple times and check HTML response in raw text.
If you have executed any valid command in the server then you will be seeing this new popup which says Congratulations, you solved this lab!. Here is the end of a walkthrough of the portswigger lab for OS command injection in a simple case.
Command Injection attack can cause highly disruptive damage to hosting infrastructure and may lead the attacker to steal information, corrupt the data even can take full control of the server. If an attacker gains control of the server then they can use the underlying application to exploit which can result in a huge loss for the organization and which impacts the reputation of the organization too.
Blog by: T3cH_W1z4rD [@aravindha1234u]