Abuse of functionality (WASC-42):
Abuse of Functionality is an attack technique that uses a web site’s own features and functionality to attack itself or others. Abuse of Functionality can be described as the abuse of an application’s intended functionality to perform an undesirable outcome. These attacks have varied results such as consuming resources, circumventing access controls, or leaking information. The potential and level of abuse will vary from web site to web site and application to application. Abuse of functionality attacks are often a combination of other attack types and/or utilize other attack vectors.
Some examples of Abuse of Functionality are:
- Abusing Send-Mail Functions
- Abusing Password-Recovery Flows
- Abusing functionality to make unrestricted proxy requests
* Description taken from the WASC Threat Classification (WASC-42)
Abuse of functionality is something we see a lot of in penetration test reports. It’s an important part of what we do when checking the security of systems, and it’s easy to see where it fits on a risk scale for a set application. Whether an attacker gains access to the functionality through default/weak password protection, some sort of authorisation/authentication bypass, or just by direct calls to the backend functions (WebServices springs to mind for some reason). The problem can be clearly defined and reported to the client.
It’s not so clear-cut however when it comes to reporting these kind of flaws to vendors. After all, if they put the functionality into their product, it must be a desired function right? …and as long as it’s correct protected, I’m not sure they’ll see it as a real vulnerability. At least this was my thought process when dealing with abuse of functionality in the past. It’s not for us to say what a vendor does and doesn’t want to allow users to do with their products.
Still, somewhere at the back of my mind there was still a nagging desire to report these things and make the world a little bit more secure. The argument that we shouldn’t tell a vendor what’s acceptable in their own products seemed like a bad one to me. I don’t want VendorX exposing a command shell to every user just because they can! So, naturally I asked the question on twitter to try to get an overall feeling of how other security folks see this situation. Nothing in twitter land is ever black and white, and I got a few interesting responses that really made me rethink my viewpoint somewhat.
In particular @infosecmafia pointed out that logging, auditing and things like workflows could be bypassed if the vendor didn’t correctly limit the capabilities of a user (admin or not). Just because a vendor exposes some administrative access, it doesn’t mean that full administrative access is desired (or secure). I must admit, this was something I’d not really considered before. Even if the product from VendorX allows for commands to be run remotely by administrative users, it doesn’t mean that they automatically accept that an administrative user should be able to gain shell access and all the benefits that offers. If all commands are logged and audited, then gaining complete access to the underlying system could easily bypass these audits… not that any attacker would want to avoid audit trails 😉
With that said though, I’m still not sure if Vendors are ready for security professionals to start pointing out these type of abuses. It’s easy to cast aside the comments of security researchers who come to you saying “if I have admin access in your interface I can get shell”… it sounds obvious, and it is. I like @abegetchell‘s response to that, “From an operations perspective, remember, admin within an application != admin within the underlying OS“. I guess it depends on the vendor, their security posture and their overall maturity. If the vendor has a long list of outstanding security issues, these kind of flaws can easily be seen as unimportant and fall to the red pen! … and I can almost see why. 
We in the security industry like to hype the things we find, no matter how rarely they might be exploited. As much as we hate to admit, we’re not living in the perfect world where every vulnerability can and will be patched. Still, that’s a discussion for another day I think.
There are lots of opinions here… everybody knows what they say about opinions after all. 
Some say it’s a feature/functionality, others say it’s a bug and needs to be reported. Still most tend to err on the side of reporting and letting the vendor figure it out… and I’d be hard pressed to argue with that.
I’ll let you decided what you think is best. Hopefully some of these responses have you some food for thought! If you disagree or want to point out something we’ve not considered, speak up! This is a community, and without discussion, nothing changes!
Links:
Cатсн²² (in)sесuяitу / ChrisJohnRiley 