I have a problem with the user validation by email plugin.
Mainly my website based on elgg 1.7.15 is attacked by a remote software that automatically registers users with a not existing email addresses and then is able to complete the validation of the email address even if the email address is not existing and so not receiving the validation link.
I checked that the email addresses are wrong by sending an email to the reported address. I received a notification by the server that says that the email address is not existing.
So the attack path is the following:
1) A fake user registers with the registration form using a not existing email address.
2) The fake user is able to reconstruct the email validation link based on the following hash function: md5($user_guid . $email_address . $CONFIG->site->url . get_site_secret());
How attacker are able to build the validation token without knowing the site secret? How to solve this issue?
I will add a Captcha to avoid automatic registrations of users but for sure there is a way to reconstruct the email validation link. How to solve this? I tried also to change the function that generate the validation token, but.....
Maybe the system is using a temporal email, there are some services that
gives you a temporal email address to let you register on sites without an
email that sites could spam.
> I have a problem with the user validation by email plugin.
> Mainly my website based on elgg 1.7.15 is attacked by a remote software
> that automatically registers users with a not existing email addresses and
> then is able to complete the validation of the email address even if the
> email address is not existing and so not receiving the validation link.
> I checked that the email addresses are wrong by sending an email to the
> reported address. I received a notification by the server that says that
> the email address is not existing.
> So the attack path is the following:
> 1) A fake user registers with the registration form using a not existing
> email address.
> 2) The fake user is able to reconstruct the email validation link based on
> the following hash function: md5($user_guid . $email_address .
> $CONFIG->site->url . get_site_secret());
> How attacker are able to build the validation token without knowing the
> site secret? How to solve this issue?
> I will add a Captcha to avoid automatic registrations of users but for
> sure there is a way to reconstruct the email validation link. How to solve
> this? I tried also to change the function that generate the validation
> token, but.....
> Regards
> --
> You received this message because you are subscribed to the Google
> Groups "Elgg development" group.
> To post to this group, send email to elgg-development@googlegroups.com
> To unsubscribe from this group, send email to
> elgg-development+unsubscribe@googlegroups.com
I've done some research on this and it seems that there were some xrumer
mods designed to hit Elgg sites in particular. As far as I could gather
xrumer fakes the email and email validation. I've run a simple test to
check whether I can identify spambots on my demo sites by checking the
difference between time_created and last_action and/or last_login, and
there are matches for values under 15 seconds.
I would suggest the following:
1. First check to see if you there are any hooks that might be interfering
with the return value for 'register' hook. This might actually be a ticket
material. Menus also use 'register' hook, so if someone is trying to
overwrite a bunch of menus with 'register', 'all' and accidentally passes
return value of true, this would completely unarm uservalidationbyemail.
2. Create a hook for 'login', 'user' and check the difference between
e.time_created and ue.last_login. If the difference is less than X seconds
(usually 15) than the user is a bot. No human can fill out the registration
form and validate their email within 15 seconds.
3. Add a field to your registration form with a randomly generated name
attribute. The label would read something like 'Are you a bot?' with
'Yes'/'No' options and 'Yes' selected by default. Most hacking scripts a-la
xrumer won't be able to answer the question correctly.
On Tue, Oct 16, 2012 at 12:09 AM, germanazo <german...@gmail.com> wrote:
> Maybe the system is using a temporal email, there are some services that
> gives you a temporal email address to let you register on sites without an
> email that sites could spam.
>> I have a problem with the user validation by email plugin.
>> Mainly my website based on elgg 1.7.15 is attacked by a remote software
>> that automatically registers users with a not existing email addresses and
>> then is able to complete the validation of the email address even if the
>> email address is not existing and so not receiving the validation link.
>> I checked that the email addresses are wrong by sending an email to the
>> reported address. I received a notification by the server that says that
>> the email address is not existing.
>> So the attack path is the following:
>> 1) A fake user registers with the registration form using a not existing
>> email address.
>> 2) The fake user is able to reconstruct the email validation link based
>> on the following hash function: md5($user_guid . $email_address .
>> $CONFIG->site->url . get_site_secret());
>> How attacker are able to build the validation token without knowing the
>> site secret? How to solve this issue?
>> I will add a Captcha to avoid automatic registrations of users but for
>> sure there is a way to reconstruct the email validation link. How to solve
>> this? I tried also to change the function that generate the validation
>> token, but.....
>> Regards
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Elgg development" group.
>> To post to this group, send email to elgg-development@googlegroups.com
>> To unsubscribe from this group, send email to
>> elgg-development+unsubscribe@googlegroups.com
> --
> You received this message because you are subscribed to the Google
> Groups "Elgg development" group.
> To post to this group, send email to elgg-development@googlegroups.com
> To unsubscribe from this group, send email to
> elgg-development+unsubscribe@googlegroups.com
*"Hope is a state of mind, not of the world. Hope, in this deep and
powerful sense, is not the same as joy that things are going well, or
willingness to invest in enterprises that are obviously heading for
success, but rather an ability to work for something because it is good"* -
Vaclav Havel
How would it fake the email validation without knowing the site secret? Do you just mean they have access to email accounts?
> 'all' and accidentally passes return value of true, this would completely unarm
> uservalidationbyemail.
Are you thinking maybe this should be an event for safety purposes?
> 2. Create a hook for 'login', 'user' and check the difference between e.time_created and
> ue.last_login. If the difference is less than X seconds (usually 15) than the user is a
> bot. No human can fill out the registration form and validate their email within 15 seconds.
I disagree. I often have my e-mail open in the background and can switch to it and click the link right away. I guess I'd say if they validate under 15 seconds, ideally you'd throw another captcha or some click-through in the way, for zippy humans :)
> 3. Add a field to your registration form with a randomly generated name attribute. The
> label would read something like 'Are you a bot?' with 'Yes'/'No' options and 'Yes'
> selected by default. Most hacking scripts a-la xrumer won't be able to answer the question
> correctly.
> How would it fake the email validation without knowing the site secret? Do
> you just mean they have access to email accounts?
Not sure how exactly they handle it, but it looks like the email accounts
are created temporarily for the sake of verification and then shut down. A
lot of them use gmail accounts, which apparently they can create
automatically with an averaging captcha bypass rate. Alternatively they
seem to be using catchall email addresses. So by 'fake' I only mean that
they somehow get access to the validation link via a bogus email.
> 'all' and accidentally passes return value of true, this would completely
>> unarm
>> uservalidationbyemail.
> Are you thinking maybe this should be an event for safety purposes?
I think a different hook name would suffice.
> 2. Create a hook for 'login', 'user' and check the difference between
>> e.time_created and
>> ue.last_login. If the difference is less than X seconds (usually 15) than
>> the user is a
>> bot. No human can fill out the registration form and validate their email
>> within 15 seconds.
> I disagree. I often have my e-mail open in the background and can switch
> to it and click the link right away. I guess I'd say if they validate under
> 15 seconds, ideally you'd throw another captcha or some click-through in
> the way, for zippy humans :)
Hmmm. You are probably right on this one.
An alternative solution would be to add a hidden input with a timestamp of
when the registration form was accessed, and compare against it.
> 3. Add a field to your registration form with a randomly generated name
>> attribute. The
>> label would read something like 'Are you a bot?' with 'Yes'/'No' options
>> and 'Yes'
>> selected by default. Most hacking scripts a-la xrumer won't be able to
>> answer the question
>> correctly.
> They wouldn't just return the default option value?
Well, according to forum owners this works quite successfully. Xrumer seems
to leave the default value on fields it doesn't recognize. I would even
avoid wrapping the label in <label> tags, so that they can't pick up the
actual question.
> --
> You received this message because you are subscribed to the Google
> Groups "Elgg development" group.
> To post to this group, send email to elgg-development@googlegroups.**com<elgg-development@googlegroups.com>
> To unsubscribe from this group, send email to
> elgg-development+unsubscribe@**googlegroups.com<elgg-development%2Bunsubscr ibe@googlegroups.com>
*"Hope is a state of mind, not of the world. Hope, in this deep and
powerful sense, is not the same as joy that things are going well, or
willingness to invest in enterprises that are obviously heading for
success, but rather an ability to work for something because it is good"* -
Vaclav Havel
ismayil.khayredi...@gmail.com> wrote:
> On 10/15/12 8:26 PM, Ismayil Khayredinov wrote:
>> ...xrumer fakes the email and email validation.
>> How would it fake the email validation without knowing the site secret?
>> Do you just mean they have access to email accounts?
> Not sure how exactly they handle it, but it looks like the email accounts
> are created temporarily for the sake of verification and then shut down. A
> lot of them use gmail accounts, which apparently they can create
> automatically with an averaging captcha bypass rate. Alternatively they
> seem to be using catchall email addresses. So by 'fake' I only mean that
> they somehow get access to the validation link via a bogus email.
>> 'all' and accidentally passes return value of true, this would
>>> completely unarm
>>> uservalidationbyemail.
>> Are you thinking maybe this should be an event for safety purposes?
> I think a different hook name would suffice.
>> 2. Create a hook for 'login', 'user' and check the difference between
>>> e.time_created and
>>> ue.last_login. If the difference is less than X seconds (usually 15)
>>> than the user is a
>>> bot. No human can fill out the registration form and validate their
>>> email within 15 seconds.
>> I disagree. I often have my e-mail open in the background and can switch
>> to it and click the link right away. I guess I'd say if they validate under
>> 15 seconds, ideally you'd throw another captcha or some click-through in
>> the way, for zippy humans :)
> Hmmm. You are probably right on this one.
> An alternative solution would be to add a hidden input with a timestamp of
> when the registration form was accessed, and compare against it.
>> 3. Add a field to your registration form with a randomly generated name
>>> attribute. The
>>> label would read something like 'Are you a bot?' with 'Yes'/'No' options
>>> and 'Yes'
>>> selected by default. Most hacking scripts a-la xrumer won't be able to
>>> answer the question
>>> correctly.
>> They wouldn't just return the default option value?
> Well, according to forum owners this works quite successfully. Xrumer
> seems to leave the default value on fields it doesn't recognize. I would
> even avoid wrapping the label in <label> tags, so that they can't pick up
> the actual question.
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Elgg development" group.
>> To post to this group, send email to elgg-development@googlegroups.**com<elgg-development@googlegroups.com>
>> To unsubscribe from this group, send email to
>> elgg-development+unsubscribe@**googlegroups.com<elgg-development%2Bunsubscr ibe@googlegroups.com>
> *"Hope is a state of mind, not of the world. Hope, in this deep and
> powerful sense, is not the same as joy that things are going well, or
> willingness to invest in enterprises that are obviously heading for
> success, but rather an ability to work for something because it is good"* -
> Vaclav Havel
> --
> You received this message because you are subscribed to the Google
> Groups "Elgg development" group.
> To post to this group, send email to elgg-development@googlegroups.com
> To unsubscribe from this group, send email to
> elgg-development+unsubscribe@googlegroups.com
It doesn't look like they're working around the site secret at all, they're
basically just scripting the form submission but it's actually legitimately
loading the form and therefore the tokens as well. They're using a
validated account - if you jump to their registration section you'll see
that they are in fact going through the full registration process with
apparently throw-away email addresses.
> But not sure whether its the pre 1.8.8 tutorial or how they manage to work
> around the site secret.
> On Tue, Oct 16, 2012 at 3:17 PM, Ismayil Khayredinov <
> ismayil.khayredi...@gmail.com> wrote:
>> On 10/15/12 8:26 PM, Ismayil Khayredinov wrote:
>>> ...xrumer fakes the email and email validation.
>>> How would it fake the email validation without knowing the site secret?
>>> Do you just mean they have access to email accounts?
>> Not sure how exactly they handle it, but it looks like the email accounts
>> are created temporarily for the sake of verification and then shut down. A
>> lot of them use gmail accounts, which apparently they can create
>> automatically with an averaging captcha bypass rate. Alternatively they
>> seem to be using catchall email addresses. So by 'fake' I only mean that
>> they somehow get access to the validation link via a bogus email.
>>> 'all' and accidentally passes return value of true, this would
>>>> completely unarm
>>>> uservalidationbyemail.
>>> Are you thinking maybe this should be an event for safety purposes?
>> I think a different hook name would suffice.
>>> 2. Create a hook for 'login', 'user' and check the difference between
>>>> e.time_created and
>>>> ue.last_login. If the difference is less than X seconds (usually 15)
>>>> than the user is a
>>>> bot. No human can fill out the registration form and validate their
>>>> email within 15 seconds.
>>> I disagree. I often have my e-mail open in the background and can switch
>>> to it and click the link right away. I guess I'd say if they validate under
>>> 15 seconds, ideally you'd throw another captcha or some click-through in
>>> the way, for zippy humans :)
>> Hmmm. You are probably right on this one.
>> An alternative solution would be to add a hidden input with a timestamp
>> of when the registration form was accessed, and compare against it.
>>> 3. Add a field to your registration form with a randomly generated name
>>>> attribute. The
>>>> label would read something like 'Are you a bot?' with 'Yes'/'No'
>>>> options and 'Yes'
>>>> selected by default. Most hacking scripts a-la xrumer won't be able to
>>>> answer the question
>>>> correctly.
>>> They wouldn't just return the default option value?
>> Well, according to forum owners this works quite successfully. Xrumer
>> seems to leave the default value on fields it doesn't recognize. I would
>> even avoid wrapping the label in <label> tags, so that they can't pick up
>> the actual question.
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Elgg development" group.
>>> To post to this group, send email to elgg-development@googlegroups.**com<elgg-development@googlegroups.com>
>>> To unsubscribe from this group, send email to
>>> elgg-development+unsubscribe@**googlegroups.com<elgg-development%2Bunsubscr ibe@googlegroups.com>
>> *"Hope is a state of mind, not of the world. Hope, in this deep and
>> powerful sense, is not the same as joy that things are going well, or
>> willingness to invest in enterprises that are obviously heading for
>> success, but rather an ability to work for something because it is good"* -
>> Vaclav Havel
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Elgg development" group.
>> To post to this group, send email to elgg-development@googlegroups.com
>> To unsubscribe from this group, send email to
>> elgg-development+unsubscribe@googlegroups.com
> --
> You received this message because you are subscribed to the Google
> Groups "Elgg development" group.
> To post to this group, send email to elgg-development@googlegroups.com
> To unsubscribe from this group, send email to
> elgg-development+unsubscribe@googlegroups.com
On Saturday, October 13, 2012 12:40:06 AM UTC-5, Pixel wrote:
> Dear Sirs,
> I have a problem with the user validation by email plugin.
> Mainly my website based on elgg 1.7.15 is attacked by a remote software > that automatically registers users with a not existing email addresses and > then is able to complete the validation of the email address even if the > email address is not existing and so not receiving the validation link.
> I checked that the email addresses are wrong by sending an email to the > reported address. I received a notification by the server that says that > the email address is not existing.
> So the attack path is the following:
> 1) A fake user registers with the registration form using a not existing > email address.
> 2) The fake user is able to reconstruct the email validation link based on > the following hash function: md5($user_guid . $email_address . > $CONFIG->site->url . get_site_secret());
> How attacker are able to build the validation token without knowing the > site secret? How to solve this issue?
> I will add a Captcha to avoid automatic registrations of users but for > sure there is a way to reconstruct the email validation link. How to solve > this? I tried also to change the function that generate the validation > token, but.....
