As many of you might remember, we setup a security announcement newsletter, a history of all security advisories, and an RSS feed with the most recent security advisories. We strongly advised Drupal administrators to sign up for the list. With the recent drupal.org survey we asked people if they are subscribed to either the Drupal newsletter or the Drupal security announcements, and if so, how. Turns out that a fair amount of survey participants were not subscribed to either mailing list (see graph, read more). Additional research showed that the security announcements page is not very popular in terms of page views and that, to date, only 850 people subscribed to the security announcements by e-mail ...

To that extent, we created a new ad and put it into rotation on the drupal.org main page:

By periodically featuring a security ad on a prominent spot, we hope to generate some more visibility for the security announcements and to create some awareness with regard to the importance of tracking security advisories. We invested quite some time in setting up the security infrastructure. There is no reason not to use it. Thus, If you haven't subscribed to the announcements yet, visit the security page or check the newsletter settings under my account >> edit >> my newsletters.

(Thanks to Bert Boerland and Jamey Boje for creating the ad.)

Comments

I was just caught by a hacker last week who found an old xmlrpc.php on a site of mine, and the tools he had appear to be customised to specifically target the old drupal xmlrpc implementations.

was stung last sunday night.....Now I am battling theme problems..... :)

Been away from drupal for a while.......health and other reasons.
Worked on some very cool drupal projects and I am starting some more currently.....looking forward to a drupalised future.

A fix was out hours after this exploit has gone public, drupal was the first to patch this external library vulnability of all php based systems!

A note about this has been sticky on the front page of drupal.org for month now. So in case you never read this or just didnt like to patch, best to subscribe _now_ to the mailing list!

good luck by the way in recovering database, theme and maybe even go after the Bad Guy. You might want to post your experience to drupal.org so others can leanr.

--
groets
bertb

--
groets
bert boerland

i can't seem to find the xmlrpc-advisory on the security history page (http://drupal.org/security)...

shouldn't the critical advisories from before that page was created be listed there, too? or am i just too dumb to see them?

true, but that page was created (long) AFTER the drupal exploit and fix (drupal and backwards compatibility :-)

The posting on the homepage of drupal.org has there been ever since the exploit was fixed, month ago!

--
groets
bertb

--
groets
bert boerland

i guessed so. but i still think this highly exploitable problem should be on the security page. if only as a link...

sincethe page wasnt there when the exploit was. As said, it is on the homepage, very clear, very pushy. So dont say you didnt see it :-)

But still, the point of this whole thread is:
Subscribe!
Read!
Act!

--
groets
bertb

--
groets
bert boerland

we kind of agree up to a point (i have been a subscriber to the mailing list for some time now).

but consider people who installed drupal some time ago, didn't care about updating and NOW subscribe to the mailing list and check the security page (while strangely enough not looking at the starting page ;-) they won't know about it...

It was published in the Drupal newsletters[1] [2] which did exist. It was published on the Front Page of Drupal.org. Several security vulnerability websites were notified which published the notification as well as the maintainers of the xml-rpc library.

YOU as a user on the web have a responsibility to patch your desktop system against web browser exploits (Firefox or IE) or suffer the consequences of an exploited system. You have a responsility to be aware of attachments, viruses and such. The news media has reporters that have stories on the latest outbreak and such affecting client systems of popular OS and applications.

What part of this on the client side means that you as an individual have no responsibility to stay aware of the web application you are responsible for running? A CMS is a complex web application. If you are going to go beyond the bounds of a static website, then you have a responsibility. You set it up (or learned how to). Maintaining this awareness is part of your responsibility as a site admin.

Getting exploited after a patch is out, is a consequence of not caring or not understanding those consequences. Experienced admins as well as neophytes get caught by this, small sites and large. All we can do is publish and make the information available. We cannot patch your sites for you. We cannot call you on the phone. You must remain aware of your responsilbilities.

The best practices has a mention for security practices that has been there for quite a while and I know I certainly promote that section of the handbook enough.

-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

While i agree there is no excuse for not knowing about this particular vulnerability, i also think there is no excuse for not adding it to the security page now.

How much time would it take to add a link? Certainly less time that the various replies above took, yes?

Please sign up to be a site maintainer in your spare time and volunteer to help doing the work. In the mean time you answering questions in the support forums will be appreciated.

Not a lot of people have a good understanding of the issue and rather then get it wrong, we'll just wait until those three get some spare time alright? All of us site-maintainers have varying skill levels and realms of expertise that we tend to stick to.

The vulnerabilty was published in several places. Feel free to help do work and improve drupal.org for everyone that comes after you.

In the meantime, from the newsletter I refernced earlier.. Here you go: http://drupal.org/files/sa-2005-004/advisory.txt

-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

If I add these to the security page, I would need to answer unnumbered questions about "is this a new one?". So thanks, no, it won't happen.
--
Read my developer blog on Drupal4hu.

--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

why not add an "archive" section on drupal.org?
listing older exploits in a concise manner wouldn't get "are those new" reaction i suppose.
and, yes, i would offer to help myself if my current workload would allow it ( i DID however contribute to the server-fund)

my provider just disabled xmlrpc.php because of high processor load. I knew about the xmlprc problem but didn't bother since the site was not public (on my public site I have removed it a long time ago). Not a good idea. In the logs I see one user agent named 'Python-urllib/2.4' which might indicate, that some script is just scanning IP ranges and found the site this way. I should have known better.

For those of you that still failed to update / workaround the XMLRPC issue a warning: McAfee describes the worm Lupper that takes advantage of the vulnerability.

Excerpt:

The worm blindly attacks web servers by sending malicious http requests on port 80. If the target server is running one of the vulnerable scripts at specific URLs and is configured to permit external shell commands and remote file download in the PHP/CGI environment, a copy of the worm could be downloaded and executed.

Like its precedents, the infected computers form a global network of compromised servers based on peer to peer communication principles. This network can be used, for example, for Distributed Denial of Service (DDoS) attacks or other purposes because it can accept remote commands. It is also capable of harvesting email addresses stored in files on the web server.

EDIT: Fixed McAfee link

I've kept a copy of the code, and its different, doesn't scan for as many vunerable files, but specifically scans for:

/xmlrpc.php
/xmlrpc/xmlrpc.php
/xmlsrv/xmlrpc.php
/services/xmlrpc.php
/blog/xmlrpc.php
/drupal/xmlrpc.php
/community/xmlrpc.php
/blogs/xmlrpc.php
/blogs/xmlsrv/xmlrpc.php
/blog/xmlsrv/xmlrpc.php
/blogtest/xmlsrv/xmlrpc.php
/b2/xmlsrv/xmlrpc.php
/b2evo/xmlsrv/xmlrpc.php
/wordpress/xmlrpc.php

And it/they installed the zkmem virus.
http://www.google.com.au/search?q=zkmem

http://www.chkrootkit.org/ confirms it.

So I guess that's two variants that specifically target xmlrpc ;-(

According to this SANS story there are indeed multiple variants targeting the same (and related) vulnerabilities.

I just had such a scan, and there was a curious result that I don't understand. I haven't upgraded to fix the xmlrpc exploit, but I have removed the file. When the scan tried to GET and POST to the above files, it received 404 errors on most. But two didn't. Those are:

"POST /blog/xmlrpc.php HTTP/1.1" 200 61294
"POST /blog/xmlsrv/xmlrpc.php HTTP/1.1" 200 61373

I don't have an xmlrpc.php anywhere that can be accessed. Why didn't they get a 404 error?

There are some contributed modules that people commonly use that apparently had security fixes. It would be good to add those to the security feed and newsletter, no?

Just last night I discovered that a client's site that was up to date with 4.6.3 still got hacked, with an unregistered user publishing a forum node without registering, without permissions. I still don't know how he/she did it, and the logs are gone as this happened over a week ago and the client is not on a support retainer with us, so I've not been monitoring the site regularly.

But we could not simply unpublish the node so we had to delete it. The message was rather benign, and we're thankful this wasn't a malicious attack.

What I did is update the flexinode, webform and phptemplate modules, as they handle input and permissions. And I see that they had some security updates over the past couple of months -- which is something that I think should be flagged here. (Even on unsupported sites, we'll do any indicated security updates.)

I realize that contributed modules are not part of the core. But as a community service, I think that any security-related update should be tagged for this feed, too.

Laura
===
pingVisionrare patternscattered sunshine

_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet

If you look here: http://drupal.org/security
You will see that the very first announced vulnerability issue with the new setup was with flexinode. The next was an authorize.net.

-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

The reader I was using wasn't refreshing, and I didn't see the older stuff. I guess it was a pretty good idea, eh? ;)

Laura
===
pingVisionrare patternscattered sunshine

_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet

Shall we assume you are subscribed now? :)

-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

One thing to do would be to put the security warnings in a "Old Testament" mode. For example, I lapsed on updating one of my drupal sites to fix the xmlrpc bug. My third party host suspended my account and agreed to let me back in to back up things only after a few support tickets. They then insist on wiping out the entire account, files, email, databases, everything. I'm lucky that I have a hosting company that even allows that. The previous company I used just blocked me out and cleaned it, without patiently waiting for me to go in and back up.

IF YOU DON"T UPDATE YOUR SITE SHALL BE DESTROYED.

That would have worked for me. :)

Who are we (=security team) to issue such warnings? I personally would be happy to predict in fiery words the Ten Plagues coming down to your head if you do not upgrade, if that would make people upgrade but I think this will only bring many negative comments on the style...
--
Read my developer blog on Drupal4hu.

--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

I was joking, but serious too. I'm not saying that you (the security team) haven't done this in the past but this one area that clearly benefits from using a plain vocabulary that will trigger a reaction in users.

When I posted this forum topic 850 people were subscribed to the security announcement mailing list. At the time of this writing (little less than a week later) 1250 people are subscribed. Getting better. :)

The security mailing list is great and all, but I have to ask the daring question:

Why wasn't this seen in the first place?
I'm not blaming just Drupal (as many others did it as well) but I wish many software developers would adopt the philosophy like OpenBSD.

Sadly, I'm having to move away from Drupal becuase of this.
When I see Drupal in the ports package, I'll reconsider it.

Heck, I'm half way tempted to become a developer myself to do this, but their are *way* too many modules that (seem to) have soo little security consideration.

I would like to urge Drupal to add to the 'coding standards' page something about security and using hardened PHP code.

On the flip side, after my friend got rooted (big time, they made a '/tmp/...' file that you can't get rid of) becuase he doesn't have time to update every release as well as the other modules as well as the patches from those modules (IE: taxonomy_access requires you to patch taxonomy -- so you have to wait until that module get's updated before you can upgrade sometimes) -- so he and I have taken the very security paranoid route and would prefer security over functionality... the price of freedom is forever vigilance.

I'll see what I can do to help... but my coding skills (in php) probably aren't as good as y'alls. We shall see.

-----------------
"Our greatest glory is not in never failing but in rising every time we fall." -- Confusious

-----------------
"Our greatest glory is not in never failing but in rising every time we fall." -- Confusious

Nazadus : Proactivity is very hard to have as a culture in security. I think that the timing is good. They where becoming popular, they got the new website, and now the right thing to do is the security list and they did it. The risk was acceptable.

Also note that Drupal is not for a military usage cms like OpenBSD is to the GNU/Linux community.

When I see Drupal in the ports package, I'll reconsider it.

Ports package are usually for software that needs to compile. You don't need to compile Drupal to make it work.

Oh and...

What I need is something which can handle:

Multiple blogs
Calander of events
Photo album
can read rss feeds and have them in a block
forum would be handy
multiple users hopefully having custom profiles.

I hope that your needs changed because doing that with wikipedia? Good luck.

Alexandre Racine

www.gardienvirtuel.com Sécurité informatique, conformité, consultation, etc

www.salsamontreal.com La référence salsa à Montréal

I'm not blaming just Drupal (as many others did it as well) but I wish many software developers would adopt the philosophy like OpenBSD.

Sadly, I'm having to move away from Drupal becuase of this.
When I see Drupal in the ports package, I'll reconsider it.

I'm not quite sure I understand the logic of those two statements.

You want the Drupal Project to be like OpenBSD Project (I assume the security auditing, and proactive patching etc), and because of this won't reconsider Drupal until it is in 'ports'?

But isn't 'ports' outside OpenBSDs security umbrella? ie ports aren't guaranteed to have had any extra attention paid to their security.

I think the OpenBSD team would be the first to chastise any admin for not keeping up with security announcements no matter what medium they came by.

Or have I misunderstood what you meant?

--
Anton

But isn't 'ports' outside OpenBSDs security umbrella? ie ports aren't guaranteed to have had any extra attention paid to their security.

Yes, you are correct. All it means is that someone has gone to the trouble to ensure it runs under OpenBSD (which is often an issue due to OpenBSD’s security measures).

Ironically, while i’ve been running OpenBSD for about three years now, i’m thinking of migrating to MacOS X to improve security. While OpenBSD is arguably the more secure OS by design, in practice, upgrading OpenBSD is a pain in the ass, so i tend not to do it as often as i should. If you don’t keep current, you aren’t secure. With MacOS X, updating is so very easy, so i always do it. So for me it seems to be a choice between running a theoretically more secure OS which is almost never up-to-date, or an OS which is always kept current.

Ironically, while i’ve been running OpenBSD for about three years now, i’m thinking of migrating to MacOS X to improve security. While OpenBSD is arguably the more secure OS by design, in practice, upgrading OpenBSD is a pain in the ass, so i tend not to do it as often as i should. If you don’t keep current, you aren’t secure. With MacOS X, updating is so very easy, so i always do it. So for me it seems to be a choice between running a theoretically more secure OS which is almost never up-to-date, or an OS which is always kept current.

Yeah, the hassle of patching is the same reason I tend to only use OpenBSD on firewalls and stick to Debian for servers. A bare OpenBSD firewall hardly ever needs any patching, but it's a different story when you're dealing with 3rd party code on servers...

If patching OpenBSD was like Debian, I'd use it everywhere.

--
Anton

Three weeks after this announcement (and two weeks after the update in the comments), 1580 people are subscribed to the security announcements.

"1580 people are subscribed to the security announcements."

How about an update pie chart then :-)

when is there comming a security module on drupal 6???

security in a module?

this thread is old and in a deprecated forum.

Security provided by a module doesn't make sense really.
Think about the idea of securing code with more code.

What secures the security module? another? and then that module? another?

The security of Drupal is one of its best feature. To report any security issue, one can use the instructions specified here http://drupal.org/security-team

Only the current and one previous version of Drupal are actively supported, currently 6.x and 5.x.