
Joomla SQL Injection Attacks in the Wild - ebarock
https://blog.sucuri.net/2015/10/joomla-sql-injection-attacks-in-the-wild.html
======
abluecloud
I'm literally not surprised by anything in this article. Joomla is a mess (my
opinion, doesn't actually matter to my point), written in PHP so whenever a
patch is released, you can see exactly what the exploit was. In fact, I'm
surprised it's not less than 2 hours.

So obviously, "Patch now!" \- although, that's not the prerogative of this
site, it's to convince you to purchase their "website antivirus" \-- which I
still can't work out what it actually does, or where it sits.

~~~
thaumaturgy
I can't tell for sure either. Their pages about it, as usual, are heavy on
marketing and light on technical details. In one case it looks like they offer
a CloudFlare-like service
([http://cloudproxy.sucuri.net/features](http://cloudproxy.sucuri.net/features)),
and then in another case, they offer it as a Wordpress plugin
([https://wordpress.org/plugins/sucuri-cloudproxy-
waf/faq/](https://wordpress.org/plugins/sucuri-cloudproxy-waf/faq/)) (and
presumably for other platforms too).

Given modern web development trends though, I'm sure they'll be very
successful at selling their product without bothering with things like
technical details.

------
lfender6445
apparently this impacts versions 3.2.0 through 3.4.4
[https://developer.joomla.org/security-
centre/628-20151001-co...](https://developer.joomla.org/security-
centre/628-20151001-core-sql-injection.html) but has been fixed in release
3.4.5

------
drawkbox
Joomla, from the age of the monolithic frameworks, easy to take down and
infiltrate because it is monolithic molasses. I feel for the souls trapped in
the joomla monolith sludge.

------
solidpy
Joomla looks like a project frozen in time. The code and template engine reek
of old php.

I'm glad I don't have to maintain anything in it again.

~~~
razster
But it is such a simple CMS. I can make user groups and assign each group to a
section or download section using DocMan. I can revoke rights to one use or
the whole group. I cannot do this in Wordpress.

~~~
SignMeTheHELLUp
That kind of authentication and authorization can be found in any respectable
CMS. Choosing Joomla because Wordpress isn't any better is like choosing to
drink your own urine for breakfast because stools taste worse.

~~~
SignMeTheHELLUp
delete akwlcy4

------
danielcid
Good (related) read about this vulnerability by the Trustwave team:

[https://www.trustwave.com/Resources/SpiderLabs-
Blog/Joomla-S...](https://www.trustwave.com/Resources/SpiderLabs-Blog/Joomla-
SQL-Injection-Vulnerability-Exploit-Results-in-Full-Administrative-Access/)

------
ArtDev
Apparently, the fabled "Joomla Jackal" is alive and well.

I wouldn't touch that software with a 10-foot pole.

------
kbenson
Ah, the tainted legacy of PHP applications originally built in the early
2000's. I doubt anything has been responsible for more exploits than the lack
of the ability to do parameter binding in PHP's original MySQL driver.

~~~
teh_klev
The driver isn't totally to blame, too many developers weren't and still
aren't trained properly.

The problem is actually that users would probably never have used parameter
binding even if it was available. Despite the original mysql driver not
supporting parameter binding you could still mitigate against SQL injection
attacks even back then. The mysql_real_escape_string() function is available
to help prevent SQL injection attacks, it's been around since the dawn of PHP4
(yes I know it's not totally secure if you're not aware of your character
encoding [0]) . But barely anyone used it, or even understood the purpose of
mysql_real_escape_string().

I've had to trawl through ancient customer code which uses the old mysql
driver on our hosting platform to explain why their site got hijacked. There's
more often that not even a single use of mysql_real_escape_string(). This is
code written by pro-developers I'm often told. There's not even attempts to
perform naive quote escaping.

The real issue is education. There are still hoards of developers who have
never heard of SQL injection. Part of the problem was that the PHP
documentation from back in the day provided poor examples, the other part
sites like W3S omitting any mention of mitigating against SQL injection
attacks. So folks merrily copy/paste never even having heard of the concept of
SQL injection.

I still have to educate customers about SQL injection attacks and many still
stick their heads in the sand and don't want to believe this could possibly
happen, or blame us.

And for all of the PHP team's prognostications about binning the mysql driver,
folks will just move on to mysqli or PDO and still carry on doing stuff like:

    
    
      $sql = "SELECT name FROM people WHERE name='$name'";
    

This isn't a problem specific to PHP, it's still endemic in codebases written
in Classic ASP, ASP.NET, Java, python all churned out by herds of badly
trained developers blissfully ignorant of the mess they're creating for their
clients.

[0]:
[http://stackoverflow.com/a/12118602/419](http://stackoverflow.com/a/12118602/419)

~~~
kbenson
Yes, but mysql_real_escape_string is a horrible, inefficient solution to a
well understood problem with well understood industry standard solutions.
Bound parameters were introduced into Perl's DBI module in August of _1995_
[1] and in the DBD::mysql module in 1997, and those reference DBD::Oracle when
noting where you can get more info, so they weren't the first.

My main problem with PHP on this subject is that their response to this
problem for _years_ was so lackluster, when it wasn't non-existent, that I
can't give tutorials all the blame. The entire ecosystem was initially built
on terrible, insecure practices for negligible benefit (I'm looking at you,
register_globals), and it cost everyone on the web, not just PHP developers,
for many years. And it's not like they didn't have multiple chances to fix
major problems. Conversions from PHP 3 to PHP 4 were happening back in 2001.
The mysql extension survived that. It also survived the migration from PHP 4
to PHP 5 in 2004. They fixed register_globals back in the PHP 4 release in
2001, but it took until 5.5, released in June of 2013 to deprecate the mysql
driver.

1:
[http://search.cpan.org/~timb/DBI-1.634/Changes#Changes_in_DB...](http://search.cpan.org/~timb/DBI-1.634/Changes#Changes_in_DBI_0.61,_22_Aug_1995)

------
stefivanov
RIP Joomla! Didn't even know people still use it ...

------
razster
Is Wordpress any better?

~~~
rmdoss
Different... But WordPress core seems to have a better security track record
as of lately.

~~~
teh_klev
As a hoster I can say that WordPress is pretty good provided you keep up to
date. Security problems such as SQL injection attacks usually arise from badly
written third party plugins that don't and won't take advantage of core data
access API's, and instead write their own crap.

~~~
razster
I really enjoy Joomla because of the 3RD party module, such as Docman, for my
clients. My sites run just so users can login, go to the download section
which is running Docman. I can assign users in groups to certain downloads.

When I work on a Joomla site I disable the Administrator.php page and make a
.htaccess line that will redirect anyone attempting to access that page. So
far I've never had one SQL injection/base64 exploits (I think thats what it is
called). As long as I keep it updated I should be fine.

