Attacks on ezPublish installs ? via registration ?

Author Message

allan tong

Monday 28 January 2008 5:02:05 am

Hi All,
Please help with this

I have many registration to my v3.75 installed site.
I think it is a spam emal attack, ?? or ??
there are 20 or more such registration to my site now. from the pass 24 hours.

what can be done .
any help ?
thanks in advance

Allant

A new user has registered.

Account information.
Username: http://extet.info/ringtones-for-blackberry.html
Email: taylor@mail630.gsfc.nasa.gov

Link to user information:
http://domain xxx.com/index.php/shop/content/view/full/743

---------------------------------------------------------------

A new user has registered.

Account information.
Username: http://thebondcenter.info/polyphonic-ringtones-for-free.html
Email: plasma@list.ru

Link to user information:
http://domain xxx.com/index.php/shop/content/view/full/744

Aleksey Tik

Monday 28 January 2008 5:35:53 am

this looks like robot registration. You can use a regidtration via email confirm, or image with string on it.

Peter Scott

Monday 28 January 2008 4:33:50 pm

I have a similar problem and it is occurring on two separate servers on all ez sites on those servers. The problem is happening on versions from 3.9 to 3.9.3 inclusive. Some of the username submitted have also included php scripts as usernames. Definately a robot attack.

Peter Scott

Monday 28 January 2008 4:36:29 pm

These started to appear on my sites on the 25/01/08. What can we do about this with out disabling the registration?

Aleksey Tik

Monday 28 January 2008 11:41:39 pm

i think the way to avoid this is an independ from your CMS. it may be anithing (include eZ Publish). You may validate an username and password for range of accepted characters (avoid, for example, PHP script as username, because characters "?", "<" and ">" are not valid in username). Also you can use a "CAPCHA" system as a part of registration (see http://en.wikipedia.org/wiki/CAPTCHA). You may use a confirmation of registration by email. So, there are a numbers of ways.

André R.

Tuesday 29 January 2008 1:15:24 am

http://ez.no/content/advancedsearch?&SearchText=captcha&SubTreeArray%5B%5D=21358&SearchDate=-1&SearchPageLimit=4

eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom

allan tong

Saturday 02 February 2008 7:00:16 am

Many thanks to all
trying to install "CAPCHA" now

Patrick Renaud

Wednesday 14 May 2008 1:11:55 am

Greetings,

We have such a problem of robot attack using the registering process... despite our using the antispam extension.

Has anyone had the same kind of problem ? And if you were able to solve it... how ?

Thanks !

Ca, c'est fait !

Piotrek Karaś

Wednesday 14 May 2008 3:07:15 am

Which antispam extension do you use and what's the result of the attack exactly?

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

paul bolger

Wednesday 14 May 2008 3:19:27 pm

I've been getting a few of these too, on alec.org.au (running 3.9.1). I'm not sure if I can really see the point - most just fill out the form and don't confirm so don't get activated - but a couple have. I suspect that someone somewhere is paying a fee per registration for people to sign up to anything possible and add spam links.

I've added reCAPTCHA, but I can't see that that is going to make any difference if the spammer is human.

Paul Bolger

Piotrek Karaś

Wednesday 14 May 2008 10:58:16 pm

Paul,

I can't agree with you. Of course, almost any human being can complete the registration process, but I believe we are talking bots here and these are two completely separate topics in my opinion. While couple of human registrations should not do much harm, couple of thousand automatic ones will definitely do.

As to the CAPTCHA solutions, make sure the one you're using cannot be omitted (the datatype cannot return 'accept' upon validation if its data is missing, which has been the default behavior of many datatypes so far). This has been discussed several times, I'm sure you can find information on that here in the forum as well as at http://issues.ez.no

Cheers,
Piotrek

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Kristof Coomans

Thursday 15 May 2008 1:20:21 am

FYI: the issue Piotrek refers to: http://issues.ez.no/10655

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

Patrick Renaud

Thursday 15 May 2008 1:22:40 am

Hi Piotrek, Paul,
The extension we use is Antispam : http://ez.no/developer/contribs/datatypes/antispam
The captcha field is required and cannot - as far as my knowledge goes - be omitted.
Anyway, thanks for your answers, I'll check http://issues.ez.no

[Edit] And thanks Kristof ! ;)

Ca, c'est fait !

Kristof Coomans

Thursday 15 May 2008 1:40:32 am

Hi Patrick

Unfortunately I must say that at first sight this datatype indeed has the problem Piotrek mentioned:

function validateAttributeHTTPInput( &$http, $base, &$objectAttribute, $isInformationCollector = false )
    {
        $classAttribute =& $objectAttribute->contentClassAttribute();
        $classparam = SckAntiSpamType::classAttributeContent( $classAttribute );
        $is_required = $objectAttribute->validateIsRequired();
        $must_validate = ($isInformationCollector == $classAttribute->attribute( 'is_information_collector' ) );
        
        if( $http->hasPostVariable( $base . '_sckantispam_answer_' . $objectAttribute->attribute( 'id' ) ) )
        {
            if( $is_required === true && $must_validate === true )
            {
                $answer =& $http->postVariable( $base . '_sckantispam_answer_' . $objectAttribute->attribute( 'id' ) );

                if( $answer != $objectAttribute->content() )
                {
                    $objectAttribute->setValidationError( "Antispam code is incorrect." );
                    return EZ_INPUT_VALIDATOR_STATE_INVALID;
                }
            }
        }

        return EZ_INPUT_VALIDATOR_STATE_ACCEPTED;
    }

As you can see, when the post variable is not present the validation method will return EZ_INPUT_VALIDATOR_STATE_ACCEPTED. So omitting the post variable is enough to bypass the check.

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

Piotrek Karaś

Thursday 15 May 2008 3:38:05 am

However, it should usually be quite easy to modify the attribute validation method to secure it. All you need to do is to arrange it to fit the following closed-system pattern:

if( ok )
{ 
   return EZ_INPUT_VALIDATOR_STATE_ACCEPTED;
}
return EZ_INPUT_VALIDATOR_STATE_INVALID;

instead of open one:

if( !ok )
{ 
   return EZ_INPUT_VALIDATOR_STATE_INVALID;
}
return EZ_INPUT_VALIDATOR_STATE_ACCEPTED;

Usually it would take no more than 10 minutes.
Good luck,
Piotrek

PS. If this doesn't help, there might be something wrong with your CAPTCHA extension... ;)

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.