Attackers Can Hijack Joomla Sites Via User-Agent Strings (softpedia.com) 66
An anonymous reader writes: Joomla just issued a emergency security patch after Sucuri observed a large number of attacks on Joomla sites using malicious user-agent strings. Attackers were adding malicious code to custom-made user-agent strings, which were not sanitized and stored in the database. These allowed attackers to trigger remote code on the site and grant them a backdoor into targeted websites. Even if Joomla doesn't care about older versions, the bug was so critical that it issued security patches even for EOL versions going back to 1.5.x.
I've been wondering which product was the target.. (Score:3)
Re: (Score:1)
The target is to serve malware. If they can easily exploit a widely used package to spread malware, the phish jump right in the boat.
Re: (Score:2)
Well, I have been seeing really strange Cookie, Host, Connection, request strings, etc. for ever and I sometimes wonder what the target is. Don't take for granted those pokes are only targeted at joomla.
It's 2015 already, sanitize your damn inputs! (Score:4, Insightful)
It's been 15 years since the explosive growth of the Internet started, dammit. Any "programmer" in this day and age who doesn't sanitize inputs for absolutely every parameter from an service facing the internet should be barred from using a compiler permanently.
Re: (Score:1)
You have to put it in a framework or an API, otherwise modern programmers can't understand it.
Re: (Score:2)
Re: (Score:2)
Good one, I have observed a tendency lately where newbies seem to thing that API are delivered by the baby stork. They even teach the youngsters that programming techniques used in API (for the internal work of the API) are bad and have them coming up with resource hog code that is supposed to be somehow better nevertheless.
Then, there are the APIs built on top of other APIs that achieve sensibly the same goal.
Re: (Score:2)
Re: (Score:2)
Why just services facing the internet?
Even services facing just the LAN/DMZ should sanitize their inputs. If an attacker manages to compromise one host, don't make it easy to compromise the rest.
It's likely that the user agent string was not considered "input" any more than the IP address in the log is.
Even now, among clueful people, there are those that don't realize the user agent in a browser can be arbitrarily changed.
both, because bad guys are bad and libs exist (Score:3)
Parameterized queries can certainly help reduce injections, and they should be used.
Also, if the quantity field is supposed to be in the range 1-50, don't accept quantity = "1 ;`exec rm -rf /`"
That's obviously an attack and nothing good is going to come from that transaction, so terminally cleanly but quickly. You don't need to store an order for that number of tickets.
A couple of significant security issues have been related to later statistical analysis of the data. The real-time application handled it f
where do you see a quantity field posting a messag (Score:2)
I see you managed to post a message. Where exactly do you see a "quantity" field on the posting form? Did I put some character other than digits in that quantity field? Do you see any numeric fields? Hint - there are some. If the numeric fields on this form accept free-form text and put it in the database, the programmers fucked up. Give that a try. See if you can put words in the numeric fields on this form.
Re: where do you see a quantity field posting a me (Score:1)
Really? It's HIPAA moron.
Re: (Score:3)
Who said anything about databases?
You need to sanitize the inputs before you:
I don't care about your fucking database and your fucking parametrized statements, you still need to verify that your inputs are sane.
Re: (Score:2)
What is the difference between "business rules that need to be validated and checked" and "sanitize your inputs"?
(Hint: "this field should not contain semicolons" is just as much a sanity check/validation as "this field contains a latitude entry and thus should be between -90 and 90".)
Re: (Score:2)
-- The Elements of Programming Style by B. W. Kernighan and P. J. Plauger, McGraw-Hill, New York, 1974.
See? Smart programmers knew bad or malicious input forty years ago. Trust me, even back in the days of FORTRAN card decks people tried to figure out ways to make the computer do things that would annoy or inconvenience the sysadmins.
In this case the exploit was actually quite tricksy. Normally you don't think of the user agent as user input; it's supposed to come
Re: (Score:2)
I know. Plus in most cases parameterized statements are far more efficient because they only need to be parsed once.
But all it takes is a moment of laziness when you're dealing with input you assume to be safe to get into trouble. Since it's a lazy habit, there are static code analzyzers that can catch most instances of SQL Injection; I wouldn't be surprised if that's how the attackers figured this out.
Won't work in this case... (Score:1)
Re: (Score:1)
Joomla uses MySQL and PHP. Most PHP code has so many security flaws that the matter was brought up in a meta discussion on stackoverflow. Sadly the discussion ebbed of with the genius resolution of adding a comment to any flawed answer and to this day any PHP user searching stackoverflow for answers will find highly flawed suggestions upvoted with any comment pointing out its problems long deleted in any of the cleanups performed from time to time ( a problem brought up on meta and outright ignored, since a
Re: (Score:2)
For all your fervor toward solid security practices you still miss it completely. This issue has absolutely nothing to do with the internet. The exact same security principles apply to, and should be applied in systems, without regard to internet connectivity. There are many solid reasons why this is true, but the simplest and easiest to understand is that somebody may, at a subsequent date, connect the system to the internet.
Re: (Score:1)
That doesn't change the problem here I don't believe. It probably wasn't database injection, but PHP injection. It's not the "storage", but the processing (in PHP) that caused the problem here.
Re: (Score:2)
It's been 15 years since the explosive growth of the Internet started, dammit. Any "programmer" in this day and age who doesn't sanitize inputs for absolutely every parameter from an service facing the internet should be barred from using a compiler permanently.
It wouldn't help in this case. The language used for joomla doesn't require the programmer to use a compiler.
Re: (Score:1)
Define "sanitize" in this case. What is and isn't a valid user-agent string? (and considering future devices that haven't been invented yet.)
WHY?!? (Score:5, Insightful)
Seriously, how can this still be possible?? Don't developers ever learn? Use / develop a secure database driver and let ALL your database queries go though that driver. And when I say ALL, I actually mean ALL!!! We've had SQL injections 20 years ago. There is no excuse to have your application vulnerable for this ancient shit! Really.
I know that my rant tells nothing new, but as a security professional, this shit is really starting to annoy me. I see this shit every week. And because of developers not being able to write secure code, companies get hacked, personal information gets stolen, governments act tough and come up with all sorts of security theater bullshit which results in my privacy getting invaded. So, yes, incompetent developers fucking their shit affects me personally! I really hate incompetent developers...
Re: (Score:2)
I'm surprised that they haven't made a database driver that requires you to use parameters for all queries. Basically the query should refuse to run and throw an exception if it finds a place where you provided a literal value instead of providing it via a parameter.
The entire idea of even having an "escape string" function is stupid because there will be places where people forget to use it. Especially when there are cases where you're not supposed to use it, such as when you have a variable that represen
Re: (Score:1)
Because it's Doctrine (Score:2)
Doctrine 2 has this. It's a Lexer/Parser combo, not just a parser. In Doctrine 2 the dialect is DQL which is transformed to SQL for the particular driver dialect. I understand there are several ORMs across the languages but Doctrine 2 stands on top.
Re: (Score:1)
Re: (Score:3)
Except I don't think this is actually an SQL injection and so you could have the most secure database driver with prepared statements and all of that jazz and it probably wouldn't matter.
It looks like (the details I've read are pretty slim) it's actually a php object injection [owasp.org]. Apparently, this has happened to Joomla before [karmainsecurity.com].
Basically it sounds like the useragent string is stored in the database correctly (but unverified and/or unsanitized) and then other code is pulling it from the database and trusting tha
Re: (Score:2)
While I usually remember to sanitize strings, situations often occur where you need legitimate punctuation or character patterns that you didn't or couldn't anticipate up front. It then errors out and makes the developer, me, look bad.
Can one anticipate all legitimate future User-Agent string patterns up front? Who knows what wazoo devices will be invented in the future.
Basically one is weighing an approximately
Re: (Score:2)
Basically one is weighing an approximately 1 in 100 chance a hacker getting in from an injection attack versus roughly a 1 in 5 chance that scrubbing will create practical problems for legitimate users (considering all the data collected from multiple sources and fields over time).
What practical problem could treating something like a user agent string as a raw string value possibly cause?
Re: (Score:2)
Re: (Score:2)
Another case of "most stupid coder possible"... (Score:2)
Really, this is old, well known, easy to avoid. People that make mistakes like this have no business programing. The real problem is very likely though that management hired the cheapest people it could get.
Re: (Score:2)
Really, this is old, well known, easy to avoid. People that make mistakes like this have no business programing. The real problem is very likely though that management hired the cheapest people it could get.
It's an open source project. There's no hiring people involved. Read up before you comment.
Re: (Score:2)
Not really that much different. There is letting people with no clue contribute involved. Also quite a few contributors to FOSS projects _are_ hired, most not by the project itself, but sometimes even that. But I guess you did not know that little well-known detail.
Astounding (Score:2)
Really, it's astounding that after all this time, major software apps still don't sanitize their input.
It'd be hilarious if it wasn't so sad.
There are dozens of decent sanitizer scripts and utilities out there, FFS, pick one and use it.
Re: (Score:1)
I don't sanitise my input. I sanitise my output. And you should too.
Besides, "sanitise" is the wrong word. "Escape" is better. "Sanitise" tends to be irreversible. If it fails, you can try to do a post-mortem and still have no clue what went wrong since sanitising threw away everything important.
Wow (Score:2)