PHP Code Injection vulnerability exists even after recommended hardening

Question

Using Burp to intercept traffic and inject code we have identified remote code execution vulnerability in a website. After entering data in input fields on the form and clicking submit the traffic was intercepted and the following commands were added to the request in the value of the input fields

%27%2bsystem(%22id%22)%2b%27 

To fix it we have done the recommended hardening

1. On all the input fields we have done the input sanitization. We we have allowed only digits and put a limit on the number of digits allowed. We have also used the functions such as htmlspecialchars , escapeshellcmd, escapeshellargs etc.

This did not help. What I am not able to understand here is that if they intercept the traffic,how are they able to bypass the input validation I have put on the form

2. So when we were able to intercept traffic and inject system command we checked the userid and removed shell access for this userid In etc/passwd it was /bin/bash for this user, we removed the access and verified that it was updated to /bin/false for this user

This also did not help

3. The user whose id was displayed using code injection is the owner of the website home directory. We didn't try changing the ownership but We tried removing execute permissions for this user on the home directory, but then the site itself became inaccessible and was giving 403 forbidden error.

So the execute permissions for this user and other users in the same group was retained

4. We have used disable_functions in php.ini to disable most of the recommended functions such as exec,system etc. We have Restarted httpd , I was hopeful that this would solve the issue, but still the issue exists. We have also used other directives such as Session cookie secure,Cookie httponly,session.referer_check,session.use_strict_mode etc. but all in vain

5. We tried removing the execute permission on /usr/bin for all users other than root. With this the vulnerability was fixed, but after sometime the site itself became inaccessible. The database was not starting as it needed these permissions. Hence we reverted back the permissions.

Could you please let me know if there is anything else that I can try or if I need to provide more information?

Answer 1

Right Idea, wrong implementation

On all the input fields we have done the input sanitization. We we have allowed only digits and put a limit on the number of digits allowed. We have also used the functions such as htmlspecialchars , escapeshellcmd, escapeshellargs etc.

Input sanitization is the crux of your problem ... but sanitizing it on the front end is just putting lipstick on a pig. Anything code that is run on the client side should not be trusted ... so sanitizing client side is purely for UI/UX functionality. For security you need to do the same sanitation on server side, and kick back error codes as needed.

Answer 2

Bolting stuff on top of a system only mitigates attacks, and it can often break intended functionality.

On all the input fields we have ... allowed only digits

Then either your detection is flawed or your input filtering isn't working. Given that you were apprently able to resolve the userid suggests the latter.

removed shell access for this userid In etc/passwd

While this is good practice it flags concerns that this machine is very badly configured to begin with - while you are looking at a very specific problem, someone should be performing a proper analysis of the full host.

is the owner of the website home directory

Is this a multi-tenant system? In such a scenario, it may be quite valid for the account to have a normal shell, however if the exploit is valid, then the system is very badly configured. How can someone afford to pen test but not pay for a dedicated VM? In 2018 that would be ridiculous. OTOH if it is a dedicated host, then the permissions model is all wrong.

tried removing execute permissions ... 403 forbidden error

That should be obvious. That it is not suggests you are very very out of your depth here. You need more help than a few Q&A here.

Most likely, the PHP code is bad - as CaffeineAddiciton says, you are trying to put lipstick on a pig. You've told us about one issue you have found - there will be many more.

The permissions model on the host is all wrong. There will be config issues elsewhere.

You don't have the skills to evaluate recommendations for hardening.

While I encourage you to learn more, it will take you a few years to acquire the skills you need to solve this properly. Meanwhile you have a system which is trivial to take over and weaponize. I strongly urge you to buy in some expertise.