WebsiteBaker hacked

[bulb]

Hello,

my website (running WebsiteBaker 2.7) was recently hacked and defaced. Have contacted my provider to check the logfiles and to restore an older version from the backup. Yesterday I received a reply from the hosting support.

According the support hotline, the attacker used a bug in one of the installed WebsiteBaker modules. I installed only stable modules from here (as the modules I required were not listed here). According the support hotline, the attacker manipulated URL parameters of the module to manipulate the database and to break the system.

Searched the forum but did not found an answer how or whom to report those stuff or how to deal with kind of issues. So here some (maybe silly) questions.

a) What does the module status "stable" mean (assumed this are somehow secure modules)
b) Whom to contact if a security issue was found (forum, site admins, module author, public, not public ...)
c) Is there a list of known bugs or critical modules available somewhere
d) Is there a team which takes care about security issues like JSST
e) Is there any internal or external review process for modules listed on the two official addon sources

Think there are some more open questions but maybe this is enough for now.

Bulb

[SourDough]

According the support hotline, the attacker used a bug in one of the installed WebsiteBaker modules. I installed only stable modules from here (as the modules I required were not listed here). According the support hotline, the attacker manipulated URL parameters of the module to manipulate the database and to break the system.

If the support hotline gave you the information on the module that was exploited, and the url parameters that were used, perhaps you could pass that on to the developer of the module. 

Nick

[Ruud]

First to answer your questions..

a) The status "stable" means just as much as gmail.com's status is called Beta.
It means the developer thinks it is fully functional as he/she planned it to be.
Normally a module is published in the forum, and if there are no bug reports it might go to stable. Just like google's policy some modules will never get to stable at all.

b) Website baker is an open source community. You can always warn the community through the forum.
If you think it is sensitive info, just try to find a team member and PM him.

c) http://project.websitebaker2.org/report

d) Yes and No. Everybody is concerned about security, a small group is responsible for the core. The JSST you refer to is only taking responsibility for the core of Joomla, not for modules that are out there.

e) No, as said before, this is an open community, we welcome the development of new modules, but you should always keep in mind that not every developer is a top developer. The Website baker community relies on reports from users about security and/or functional problems.

Just some more thoughts on this issue..

I provide hosting services too..
Nothing is more easy than to blame external software (like a CMS) for problems. Since we do not know any details there is no way knowing if that might be the case.
WB (the core) has been proved very stable and safe. No security issues are reported for some years now.

Everybody here uses websitebaker, and be assured, everybody here wants WebsiteBaker as safe as possible.

Finally, please tell us (i.e. send me by PM) more details on the module that was used and the way it was misused.
If a problem is found, we will make sure the module is removed from the AMASP site, and if the module has a forum thread we could issue a warning for anybody following that thread.

Ruud

[ruebenwurzel]

Hello,

The AMASP page is waht it's name says. It is only a project where all Modules and snippets are listed. As far as i know the modules are only tested if they install and uninstall correct and work. There are no deeper checks in the way they are programmed or if the have security wholes.

Please send the owner of the AMASP Page a Mail that he urgent should remove this modul as long as this modul isn't fixed. Also please send a mail to the modul developper that he must fix his modul.

For all WB users. The core Files of WB 2.7 passed different security test without having any problems before we released this version. So we can say the core is secure. Also all modules on the official addons page are secure, as they are controlled from the WB developpers. For all other modules and snippets from anywhwere (even what you find here in the forum) we cannot state this.

Matthias

[LuuQ]

Well, it might just be useful to know which module is concerned.
Maybe some WB-users would like to uninstall this module, if it's a security hole (me too).

Regards,
Lugae

[erpe]

Yes, that is right.

Please pm me and I will remove this one from AMASP and give a warning on that page.

And for I know that only less people read the readme-page or disclaimer:
it is stated there that you download and use the listed modules and snippets on your own risk for it is not possible, to control all modules and snippets in security issues.

But: this is the first time that a wb-site is probably hacked using a security hole of a module for a long time.
So it would be important to get knowledge of this module to get this issue fixed.

rgds

erpe

[bulb]

Hello,

first thanks for your fast replies. Unfortunatelly, the hosting support has not telled much about the issue. Will contact the guys again to gather more information about the issue.

Ruud thank you very much for answering the questions I have raised, especially for the statement stable. About warning the community, I am not so happy with your proposal. I do not like "security by obscurity" but I doubt that an official forum post like "module xy" contains a vulnerability which allows to do this or that by this or this manipulation is the right way either. Wouldn´t this allow others to e.g. search via Google for sites with this vulnerability to exploit it?

A lot of modules also seem to be no longer active supported, so the option to contact the developer is sometimes not given.

Will ask the hosting support for more details and then contact either the module developer (if still active) or the officials hosting the modules on their sites.

Bulb

[WebBird]

a) What does the module status "stable" mean (assumed this are somehow secure modules)

For me (as a module developer) "stable" means: It's proven to do what it should do. There are no known bugs.

"Stable" state in most cases does say nothing about security.

The questions you ask are VERY important! There should be answers for each of them.

I'd like to hear which module caused the security problem. (You may send me a PM if you'd prefer to keep this quiet.)

[WebBird]

Just some more thoughts.

On CPAN (Comprehensive Perl Archive Network), there are testers who run automated tests for all modules (and module versions) uploaded there. If the test fails, the detailed test results are mailed to the module author, and listed as an overview on the module page.

Example:

http://search.cpan.org/~mab/CGI-Application-Plugin-Config-Any-0.13/ (Module overview)
http://www.cpantesters.org/show/CGI-Application-Plugin-Config-Any.html#CGI-Application-Plugin-Config-Any-0.13 (more detailed reports)

(I can also give an example for a failure report mail if desired.)

The failure report contains some more details, so the module author can fix the issue.

I think it would be great to have something similar (but "smaller") for WB modules. As ruebenwurzel said, core modules have to pass some security checks. It would be a first step to create a bunch of test cases an add-on has to pass to be considered as "tested". AMASP could provide an icon for modules that passed these tests.

[doc]

Hi,

a) What does the module status "stable" mean (assumed this are somehow secure modules)

For me, stable means all features I had in mind are implemented and sufficiently tested on various platforms.

However, basic security measures for the most common (obvious) attacks from outside (without access to WB backend) like direct file access without permissions, XSS, SQL injection, CSRF and not to forget filtering of user inputs should be applied to all PHP scripts uploaded to the WWW, no matter for what purpose.

As already mentioned by Erpe, Matthias. It is important to make clear, that modules are not free of bugs and may contain security issues which may allow to take over the webserver. It must also be made clear, that 3rd party modules listed on either AMASP or the WB Addons repository do NOT pass (to my knowledge) any security checks before they are added - even if they should from my point of view. Even with manual checks, one will most likely not find all possible bugs. Main reason are limited resources, time or coding experience.

To make people aware of this, one should maybe add a kind of accept button before users can download modules (read terms and agree to it). Maybe also highlight the module status to make the possible danger behind more obvious e.g. like Typo3 or Firefox Addons (experimental Addons highlighted in red).

There were some issues (not too long ago) with some older module versions like "FCKEditor", "Download Gallery", "Guestbook" "Image gallery", "Feedback". Most issues were serious ones, which could be used to manipulate the database and/or to upload root shells to the webspace.

I also agree to WebBird. There will never be a guarantee that modules are free of critical bugs, but a sort of "checklist" and or internal/external scanning and reviewing process for both, AMASP and Addons repository would help to maintain a minimum level of security.

Regards Christian

[bulb]

Hello,

have sent a PM to Ruud and Erpe with the list of modules I have had used on my website.

According my provider, the attack was performed by passing over parameters to URLs pointing to my WebsiteBaker module folder. They have analysed the attack and enabled PHP magic quotes as a result of the attack. Maybe you should check if magic quotes are enabled to prevent possible attacks using the same or similar exploit.

Not sure if I will receive any more specific informaton. Maybe I also should change my provider

Bulb

[bulb]

Hello again,

the hosting company sucessfully restored my site from a backup. They have removed a PHP script which is not part of WebsiteBaker and found some manipulated database entries. Have changed my websitebaker, database and FTP accounts and removed all modules donwloaded from the two sources mentioned to avoid further attacks.

If the provider provides further information, I will contact you guys again. Thanks for your help on that.
Last question. Can I subsrice somewhere so I get a mail if a new version or security issues is available for either modules or the CMS itself?

Bulb

[doc]

@Bulb:
Have you asked your hosting company to send you the URLs they have "identitied" as the root cause for the hack? Also the name of the PHP script you mentioned in your last reply which was not part of WB would be good to know. This information would help the developers to further analyse, reproduce and finally to fix the issue.

Regarding your last question. There is no subsribe list for modules or the WebsiteBaker core available to get information via mail when a secuirty issue was found. However, security issues related to the core of WebsiteBaker can be tracked by activating the forum notification for this sub board: "Security Announcement".

Christian

[pcwacht]

A lot of modules also seem to be no longer active supported, so the option to contact the developer is sometimes not given.

There are other developpers or coders who can 'repair' those modules when something bad was found

I agree it is bad to post the mdules name when it is still vulnareble, but someone needs to know it so he can fix the faulty module.

Allso lot of coders use a module as base for heir new module.


John

[WebBird]

Maybe it's one first step to add a "Security announcement" section to AMASP.

Edit: For German speaking developers, maybe this site is useful: http://www.cms-sicherheit.de/

[erpe]

This is a good idea, but:

who will work out these security guidelines
and
who will control, if the module is coded referred to these guidelines?

Or should it be something  like a self control?

The modules could have a sign (like w3c) if they pass these test.


rgds

erpe

[WebBird]

Well, it would be great to have automated tests like on CPAN. But maybe this is far too optimistic.

[CodeALot]

What bothers me here, is the fact that so far nobody has identified the module that caused the trouble. Even though it wasn't downloaded from an "official" source, I'd still like to know which module it was. There may be lots of users of it out there.

[WebBird]

I can say that Bookings was potentially vulnerable in the backend. This was corrected with version 2.15. But I don't know which module caused that hack. (Just that Bookings was installed there, too.)

I think most (well, many) modules are vulnerable in the backend. The question is: Is there a chance for a hacker to break into the backend?

[chio]

Sorry for my poor english..

If I was a provider and had no clue what happend - or I dont want to say anything specific, I would say:

...the attacker manipulated URL parameters of the module to manipulate the database and to break the system....

This is a usual thing. Could have been - or not.
If the provider knows what happend, why doesn't he tell exactly what?

One of my clients site was also hacked some days ago. The provider was so friendly to tell the truth: The attacker used a security hole in the DNS-server to redirect all urls to a phishing site.
This had nothing to do with WebsiteBaker at all and THIS is a usual type of hacking these days.
There was nothing even touched on my clients site.

[doc]

Hello,

well, we had security issues with some modules in the past, which allowed SQL injections or file uploads via manipulated URL parameters (also without access to the backend). Most issues found in the past were related to the Download Gallery, the WYSIWYG editors and image galleries.

As the list of installed modules was provided by bulb, the question raised by CodeALot is a valid one.
Even if there is no need for "panic", one should treat this kind of issues very serious (e.g. by providing a statement, progress update by the "official bakers").

Regards Christian

[Xagone]

so basicly it mean one module it install had php in it that was not checking if the constant WB_URL was active ?

[doc]

so basicly it mean one module it install had php in it that was not checking if the constant WB_URL was active ?

Didn´t get you. I was talking about modules which did not properly filter user inputs (e.g. via GET parameter), which were exploited to e.g. upload files or to manipulate the database via SQL-Injection.

Cheers Christian

[Ruud]

so basicly it mean one module it install had php in it that was not checking if the constant WB_URL was active ?

No, checking the WB_URL is a fine way to check if you (as a developer) can access databases and so..
The lack of that constant means that you cannot do anything in the "WB world".

In this case it is still not clear what caused the site to be hacked.
As soon as providers tell you they found a problem, and they will not tell you in detail what happened you can be 99% sure it was a hack on provider level.

According my provider, the attack was performed by passing over parameters to URLs pointing to my WebsiteBaker module folder

the hosting company sucessfully restored my site from a backup. They have removed a PHP script which is not part of websitebaker

This could still be explained by someone having FTP access, controlpanel access or even access to another website on the same shared server and by that being able to put his own code on the attacked webserver.

I am not saying WB is 100% safe.. No software is 100% safe..
There are many sites/persons out there that are testing platforms like WB, and list found security holes.
Currently there are (as far as I know) no known issues out there.

Ruud

[Xagone]

as a provider myself i've seen ppl trying to hack WB

they start by checking /admin and in the admin the soon found it's WB.

so they try accessing using various stupid login/pass, like "admin", "god", "1234", "asdf", "qwerty" etc....

they check some module by trying injection on the url, but sooner or later they try accessing directly a module in it's module section.

and that's why all my php in modules begins by :

Code:

if(!defined('WB_URL')) { header("HTTP/1.0 404 Not Found"); die('Page not found'); }