4 ms·

This sort of security article rubs me the wrong way. It's obviously written for the layman; someone who doesn't know what a "shell injection attack" is or what

by Cushman 16y ago

This sort of security article rubs me the wrong way. It's obviously written for the layman; someone who doesn't know what a "shell injection attack" is or what it enables. Thus it goes into great detail about the things that are possible if you can run arbitrary code as root (or the app user, just as bad). You can delete/alter the records! You can make fake records! You can record future activity without being noticed! Of course for most of us here reading it, we already knew that as soon as you said "shell injection." They left something unvalidated, and you got shell access. Don't get me wrong, that's a huge problem. It's also a tiny fix. Your job isn't over. I want to know, say they fix that hole, which should take all of two seconds. How secure is the system now? You say that you're "confident" you could have found another attack— do you mean you're sure there's another way to run unescaped shell commands? You're guessing. There's no evidence that there is unless you found one. You just don't know. A much, much bigger problem with the system is tossed out in a single sentence: the attack went unnoticed for two days. Wholesale alteration and interception of data passed by completely unmonitored. That's not a problem with the app, that's a problem with the system, and the human processes behind it. And as long as the people who run it aren't secure, even the most watertight app is only going to last as long as it takes someone to pick up a phone. That should be the headline here.

deleted 16y ago
[deleted]
CWuestefeld 16y ago
You say that you're "confident" you could have found another attack-- do you mean... What I read into that is that the prevention of shell injection attacks is so basic that it's likely that there are other vulnerabilities as well. For example, they're probably saving the name of the stored encrypted file into the database. Since they have a record of not checking the file extension, I'd look for the analogous SQL injection vulnerability when they do the DB insert.
- Cushman 16y ago
  Or conversely, the shell injection vulnerability is fairly obscure — forgetting to validate the extension, not something you'd usually think of as user-provided input. This indicates that there was a modicum of concern for validation, they just weren't approaching it rigorously. It's a cause for suspicion of further vulnerabilities, but not confidence. One vulnerability is not two vulnerabilities.

by Cushman 16y ago

deleted 16y ago

[deleted]

CWuestefeld 16y ago

You say that you're "confident" you could have found another attack-- do you mean... What I read into that is that the prevention of shell injection attacks is so basic that it's likely that there are other vulnerabilities as well. For example, they're probably saving the name of the stored encrypted file into the database. Since they have a record of not checking the file extension, I'd look for the analogous SQL injection vulnerability when they do the DB insert.

Cushman 16y ago
Or conversely, the shell injection vulnerability is fairly obscure — forgetting to validate the extension, not something you'd usually think of as user-provided input. This indicates that there was a modicum of concern for validation, they just weren't approaching it rigorously. It's a cause for suspicion of further vulnerabilities, but not confidence. One vulnerability is not two vulnerabilities.