Slashdot Mirror
Attackers Can Hijack Joomla Sites Via User-Agent Strings (softpedia.com)
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 seeing really strange agent strings for a few weeks in my web server log files. I was wondering what the target was.
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.
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.
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...
It doesn't have to be like this. All we need to do is make sure we keep talking.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Oh that's what it is, some form of web content management system written in php.
InB4 PHP and MySQL blame.
There fixed it for you.
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.
Just cruising through this digital world at 33 1/3 rpm...
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.
Programmers like you are the fucking problem.
You don't sanitize your inputs, you use fucking parameterized statements to access the database; always. If you have to do any sanitizing beyond that you need to pick a different language; one where you can't escape string data and transform it into run time code.
" 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." Banning them from compilers wouldn't stop them here....Joomla is PHP. Just upload the file uncompiled and watch the magic happen :P
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 fine by parameterizing it or escaping it properly, but later summary statistics were generated by a tool that was exploited by specially-crafted strings. Why allow that? You know the input is crap, so why knowingly send crap to other libraries or systems? There's no need to "correctly" send hack attempts down the line. If it's supposed to be a hostname, but it contains backticks and semicolons, stop it right there. No need to pass that to getbyhostbyname() or anywhere else, other than your security monitoring systems.
Garbage. Far worse than Drupal which is worse than WordPress which at least isn't Drupal.
Need six static web pages? Here have some epic bloat.
succuri did something other than fuck up my favorite forums? Finally!
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.
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.
https://github.com/joomla/joomla-cms/commit/995db72ff4eaa544e38b4da3630b7a1ac0146264#diff-aba80b5850bf0435954b29dece250cbfL1011
```php
if (in_array('fix_browser', $this->_security) && isset($_SERVER['HTTP_USER_AGENT']))
```
This line was removed and the HTTP_USER_AGENT is no longer stored in the session, which could be stored in the database.
But read the code: Security through an in_array? fix_browser as a string?
I'm still looking forward to what PSR-7 components will come out of the Joomla camp.
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.
Everything I write is lies, read between the lines.
Wow, you weren't very fucking clear about what you meant.
That crap wouldn't even make it past my facade layer because your quantity value would be cast as an integer value, and get kicked back as an error. And if your database or services are properly setup, it's still not an issue.
There should always be validation on the front end, but that's only for honest users and is never to be trusted. Once again, never trust form validation, but always do it. On the back end, string data is always string data (even `rm -rf /` or ') drop database system; -- ) is legit input as it is here; numeric data is always numeric and just fails without worrying about validation; string based numeric data OTOH for example CC info, need special validation rules that frequently go beyond sanitizing inputs and those should be covered in the requirements. If you have to start thinking about sanitizing inputs and stop using parameterized statements; you're going to get fucked, so concentrate on doing it well and right, not fast and easy.
If you code your shit right; you don't think about sanitizing inputs; you just think about the business rules and writing solid code you have no problem. (My code has survived security audits, penetration tests, third party PCI compliance, and HIPPA audits; I try and even break it when I find a new vulnerability and I know the back end.)
Really? It's HIPAA moron.
1 line of Javascript is all it takes to turn that number-only input into a text one. That is CLIENT side... sanitize the inputs, they can't be trusted.