While some compiled software applications are vulnerable to attack vectors like Buffer Overflow attacks, websites usually don’t fall prey to the same exact vector.
Websites make use of a server to host the application (Jetty, Tomcat, Heroku, etc.) which hosts the app itself. While there may be vulnerabilities in the web app, most web development frameworks (Java/Spring, Ruby on Rails, Django, etc.) have ways of auto managing memory.
There are however circumstances where this isn’t the case. While the Ruby Server Pages on a Rails app may not be vulnerable to a memory overwrite (as with a vulnerable C application), a bad choice by a developer could be to leverage installed binaries on the OS (compiled C utilities.)
Consider a website that lets you upload a profile picture. The developer didn’t have time to write a library to convert different image types into jpg’s, so they simply opted for installed utility like ImageMagick. At this point, the website has an architecture of vulnerability. Now if an attacker gets an idea they are using an installed binary to do the image conversion, they can attack it. Some sites even broadcast, “Using [name of installed binary] to convert images.”
A careful googling for exploits might reveal a way to pass a malignant image file that will create an overflow condition.
In such a case a Rails app, although not directly vulnerable to a typical Buffer Overflow, can now be owned by attacking the leveraged utility. If an attacker compromises the application in this way, they will have the same access as the user running the utility… i.e. if Rails is being run as Root and therefore calls an installed application like ImageMagick, then said application is also being run as root… and if said application is breached with a vulnerability, then the attacker can obtain a shell with this same access level (root.)
Why would a Developer write code like this?
It’s all about leverage. Most web developers don’t have the time or resources to construct their own complex algorithms. Today many languages (Ruby, Python, Java) have libraries which can be imported. Yet there are still people who find libraries to be lacking, so they simply call System utilities (installed binaries for example) to do the work for them.
As a Tester – How to Spot Such a Case
When assigned to test software, you can ask the team if they have made decisions to leverage installable applications. If so, let them know the dangers.
If the team shrugs you off, you can find these vulnerabilities on your own by investigating their code. You can also spot it more rapidly perhaps by simply observing the website’s functionalities:
- Does the web application do any upload conversion? I.e. you upload a bmp file and it returns it as a jpg
- Does the web application advertise the use of an installable (i.e. “Made possible by [name of installed software])
If I were testing a web application for my team and it was a black box, I’d look for any point that data is being uploaded (images, audio, word docs, csv’s, etc.) Then if the data is being manipulated on the return to the user, I know that either they are leveraging a library or an installed application for the heavy lifting.
This is where you can dig deeper and look into why they are doing this, what exploits already exist for their choice, how can this be patched, etc.
In some cases you may have to prove the point to the team, by doing a Proof of Concept (writing an exploit for the web application – in a controlled environment of course!) Such POC’s help illuminate the dangers of this type of coding decision.