magento / magento2

Prior to making any Submission(s), you must sign an Adobe Contributor License Agreement, available here at: https://opensource.adobe.com/cla.html. All Submissions you make to Adobe Inc. and its affiliates, assigns and subsidiaries (collectively “Adobe”) are subject to the terms of the Adobe Contributor License Agreement.
http://www.magento.com
Open Software License 3.0
11.54k stars 9.32k forks source link

Account signup form is attack vector for spammers, and is active in the wild. #7266

Closed cyuzik closed 3 years ago

cyuzik commented 8 years ago

Using Magento 2.1.2 running on linux with php 5.6.1.

Spammers have been posting to /customer/account/create and similar form pages to send out spam. Our server had thousands of spam messages submitted using this in the past couple of days. The site is pretty much stock running the stock template.

We've done packet captures to the server and the attackers are simply using the last name field for the spam message, and the email address as the recipient.

My proposed fix is to limit the input length for firstname and lastname fields to 15 characters, and disallow any characters except the standard ascii alphabet, lower and uppercase, and the apostrophe. The firstname and lastname fields should not allow a paragraph of text that also contains URLs.

Since in this case it appears that the attackers were using a bot, so the form validation should be done after the post and not in javascript on the page so that form validation can simply be ignored by disabling or ignoring javascript.

Here is a pastebin from one of the packet captures: http://pastebin.com/0WKvF21L

orlangur commented 8 years ago

disallow any characters except the standard ascii alphabet, lower and uppercase, and the apostrophe

Are you serious? :) There are other languages exist besides English, you know.

The firstname and lastname fields should not allow a paragraph of text that also contains URLs

Agree with this point, looks like slashes and line breaks are not really needed for these fields in any language. But I'm not sure it is worth adding to core as your case is quite narrow (was it ever reported as a problem for Magento 1?).

In vanilla core you can just enable CAPTCHA or implement any other defending techniques relevant for your store on top of it.

cyuzik commented 8 years ago

I don't know if this was ever reported in Magento 1. However if spammers found our little low-traffic server, they're definitely going to be looking for others. We have enabled CAPTCHA on the site, and that's stopped the spam, for now. Again, we're running latest patch version of Magento 2.1.2 and were hit by this.

However, we're still back to the point that there is no reasonable length limit on firstname or lastname, and further it allows entire urls in a person's name. Did you look at the pastebin? That's not someone's last name.

VahanDrnoyan commented 8 years ago

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its recipients. This is a temporary error. The following address(es) deferred:

v.drnoyan@gmail.com Domain magejet.com has exceeded the max emails per hour (203/199 (102%)) allowed. Message will be reattempted later

------- This is a copy of the message, including all the headers. ------ Received: from o3.sgmail.github.com ([192.254.112.98]:42436) by server with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from bounces+848413-cb49-vahan=magejet.com@sgmail.github.com) id 1c1h3p-0001JE-16 for vahan@magejet.com; Tue, 01 Nov 2016 21:57:37 +0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=github.com; h=from:reply-to:to:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=zGIIYJNAi/z5FjDkJ1YIoPbXw6k=; b=dn9dR/pg1FCzL10t aI3EZ5WHT17k3z+VElrzNCF147z2lCcwV03/Y3hVxKM9/SZW9GAEo9ghBwdZxIy6 FhSlqwg1duWxU7p0i9vmmEAwIM0MvQM8RHnvz20h5yw7azd3eIwThvZ0hhgDC0Yh UflsKzPddUI+fNUN3IsELyY+0k4= Received: by filter0926p1mdw1.sendgrid.net with SMTP id filter0926p1mdw1-607-58190FA8-41 2016-11-01 21:56:56.824337286 +0000 UTC Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2b-ext-cp1-prd.iad.github.net [192.30.253.17]) by ismtpd0004p1iad1.sendgrid.net (SG) with ESMTP id VTLCYl-gRBKbAePTQ-EPEg for vahan@magejet.com; Tue, 01 Nov 2016 21:56:56.722 +0000 (UTC) Date: Tue, 01 Nov 2016 14:56:56 -0700 From: cyuzik notifications@github.com Reply-To: magento/magento2 reply@reply.github.com To: magento/magento2 magento2@noreply.github.com Message-ID: magento/magento2/issues/7266/257710935@github.com In-Reply-To: magento/magento2/issues/7266@github.com References: magento/magento2/issues/7266@github.com Subject: Re: [magento/magento2] Account signup form is attack vector for spammers, and is active in the wild. (#7266) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58190fa867f70_23de23f961ddf12c01050c"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: cyuzik X-GitHub-Recipient: VahanDrnoyan List-ID: magento/magento2 List-Archive: https://github.com/magento/magento2 List-Post: mailto:reply@reply.github.com List-Unsubscribe: mailto:unsub+0160ca77d376ddbe9e73f6123519f72b863a08bb60b16c7492cf000000011430d1a892a169ce0b1f8a86@reply.github.com, https://github.com/notifications/unsubscribe/AWDKd70leluBWslvStd7Hs3H0WL7fmBYks5q57WogaJpZM4Kmcns X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: vahan@magejet.com X-SG-EID: T/muHZc0wF2VNc1ajYppATxEyT7LuWxT/+k7pXLVung1v4jgEbWmL0GdvfB9muu0+IfqRzFHdeoMln kbXYv4FHChPyKjY5/V94L31Biz2l26ugYn1Dv0b4LsbGrve0zOvEjK8TQisATFPUXFcA+sgb5U09iY PlVXPz8TnkTAW7BDWj7Z+2tWhLgJuHeEEryu5TF6+m9iZY/dCGccDBxSRQ==

----==_mimepart_58190fa867f70_23de23f961ddf12c01050c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit

I don't know if this was ever reported in Magento 1. However if spammers found our little low-traffic server, they're definitely going to be looking for others. We have enabled CAPTCHA on the site, and that's stopped the spam, for now. Again, we're running latest patch version of Magento 2.1.2 and were hit by this.

However, we're still back to the point that there is no reasonable length limit on firstname or lastname, and further it allows entire urls in a person's name. Did you look at the pastebin? That's not someone's last name.

You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/magento/magento2/issues/7266#issuecomment-257710935 ----==_mimepart_58190fa867f70_23de23f961ddf12c01050c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I don't know if this was ever reported in Magento 1. However if spammers= found our little low-traffic server, they're definitely going to be lookin= g for others. We have enabled CAPTCHA on the site, and that's stopped the s= pam, for now. Again, we're running latest patch version of Magento 2.1.2 an= d were hit by this.

However, we're still back to the point that there is no reasonable lengt= h limit on firstname or lastname, and further it allows entire urls in a pe= rson's name. Did you look at the pastebin? That's not someone's last name.<= /p>

&mda= sh;
You are receiving this because you are subscribed to this thread.<= br />Reply to this email directly, view it on GitHub, or mute the thread.3D""

<div itemscope itemtype=3D"http://schema.org/EmailMessage"> <div itemprop=3D"action" itemscope itemtype=3D"http://schema.org/ViewAction= "> <link itemprop=3D"url" href=3D"https://github.com/magento/magento2/issues= /7266#issuecomment-257710935"> <meta itemprop=3D"name" content=3D"View Issue">

<meta itemprop=3D"description" content=3D"View this Issue on GitHub">

<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_version"= :"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"Gi= tHub"},"entity":{"external_key":"github/magento/magento2","title":"magento/= magento2","subtitle":"GitHub repository","main_image_url":"https://cloud.gi= thubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c= 7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/14= 3418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"O= pen in GitHub","url":"https://github.com/magento/magento2"}},"updates":{"sn= ippets":[{"icon":"PERSON","message":"@cyuzik in #7266: I don't know if this= was ever reported in Magento 1. However if spammers found our little low-t= raffic server, they're definitely going to be looking for others. We have e= nabled CAPTCHA on the site, and that's stopped the spam, for now. Again, we= 're running latest patch version of Magento 2.1.2 and were hit by this.\r\n= \r\nHowever, we're still back to the point that there is no reasonable leng= th limit on firstname or lastname, and further it allows entire urls in a p= erson's name. Did you look at the pastebin? That's not someone's last name.= "}],"action":{"name":"View Issue","url":"https://github.com/magento/magento= 2/issues/7266#issuecomment-257710935"}}}=

----==_mimepart_58190fa867f70_23de23f961ddf12c01050c--

redboxdigital-m2 commented 8 years ago

Any validation you do on names is either going to be not strict enough, or way to strict. I feel like rate limiting is probably the way forward here.

rganin commented 8 years ago

@cyuzik , Thank you for reporting, the issue is acknowledged, created internal ticket MAGETWO-60396 for adding more strict fields validation.

cyuzik commented 8 years ago

@rganin You're welcome. Any idea when this ticket could be resolved?

magento-engcom-team commented 7 years ago

@cyuzik, thank you for your report. We've created internal ticket(s) MAGETWO-60396 to track progress on the issue.

lgrassini commented 6 years ago

I just found out spammers are able to bypass the CAPTCHA validation by using "/_nosecret/1" in the URL. Example: https://www.domain.com/customer/account/create/_nosecret/1/

This is CRITICAL. We got 5000 spam emails sent from our store that will affect our domain deliverability as soon as we got included into a spam database.

dan-ding commented 6 years ago

I wouldn't count on magento fixing this anytime soon. From what I hear they think it's fixed in 2.4 (not 2.2.4, actual 2.4.x)

You could block/redirect all urls with _nosecret in them like with nginx:

location ~* _nosecret {
  return 500;
}

though doing so will possibly break something else with accounts (user or admin).

dan-ding commented 6 years ago

The other thing one can do it limit the length of first and last (and any of the other registration fields). Doing so will limit messages spammers can send, and hopefully, be too short in length to be useful to them. I suggest to use length as the other validations will prevent actual folks names.

jsdupuis commented 6 years ago

Same problem here on Magento CE 2.2.4. Magento captcha is Enabled on the Registration form. Doesn't stop bots from creating hundreds of customer accounts per day (most mail.ru and gmail). Any update?

dan-ding commented 6 years ago

@jsdupuis Magento Captcha seems to only be effective by messing with legitimate users. And on top of that, there is a backdoor (https://github.com/magento/magento2/issues/7266#issuecomment-379312482). The fastest thing you I think you can do is restricting the character length of the fields (like name can only be 30 characters or something). The limited fields aren't useful to spammers.

I believe Magento is going to include https://github.com/magespecialist/m2-MSP_ReCaptcha at some point in the future, and while I'm not a fan of it, it may be good enough for you.

Ctucker9233 commented 5 years ago

@magento-engcom-team What is going on with this?

terrybakshi commented 4 years ago

@magento-engcom-team What is going on with this?

Nothing, Team is too busy to focus on 2.3.3, just fix it yourself if you can no time for fixing the issues. :)

zw1111 commented 4 years ago

I call BS on the response to this issue. This is an obvious security vulnerability in Magento, which has been reported over 3 years ago! This security vulnerability has been exploited by spammers for years now.

The consequences of this security vulnerability are ecommerce stores can have their IP blacklisted for sending legitimate emails to customers because spammers are using the _nosecret vulnerability. GMAIL, Microsoft and others will immediately send legitimate email to junk mail, or block it entirely. I mean, WHY IN THE WORLD WOULD YOU HAVE CAPTCHA IF SPAMMERS CAN STILL BY-PASS IT? All legitimate customers will use captcha, and all spammers will use the _nosecret vulnerability to bypass. What's the point of it then?

Spammers won't even exploit the _nosecret vulnerability through a browser. They can easily post the GET or POST requests directly, which also bypasses any length restrictions on the browser form fields. Any length restrictions would have to be done on the back end. Regardless, if captcha is specified, then the _nosecret bypass should not even be able to be used in the first place.

This security vulnerability that has been exploited by spammers for years needs to be fixed!

terrybakshi commented 4 years ago

I call BS on the response to this issue. This is an obvious security vulnerability in Magento, which has been reported over 3 years ago! This security vulnerability has been exploited by spammers for years now.

The consequences of this security vulnerability are ecommerce stores can have their IP blacklisted for sending legitimate emails to customers because spammers are using the _nosecret vulnerability. GMAIL, Microsoft and others will immediately send legitimate email to junk mail, or block it entirely. I mean, WHY IN THE WORLD WOULD YOU HAVE CAPTCHA IF SPAMMERS CAN STILL BY-PASS IT? All legitimate customers will use captcha, and all spammers will use the _nosecret vulnerability to bypass. What's the point of it then?

Spammers won't even exploit the _nosecret vulnerability through a browser. They can easily post the GET or POST requests directly, which also bypasses any length restrictions on the browser form fields. Any length restrictions would have to be done on the back end. Regardless, if captcha is specified, then the _nosecret bypass should not even be able to be used in the first place.

This security vulnerability that has been exploited by spammers for years needs to be fixed!

They don't have time to fix all the known bug and issues, They only have time to keep on introducing new versions every couple of months. No point in updating when no bugs and known issues aren't been fixed yet.

ifeltsweet commented 4 years ago

Our domain has become pretty useless at deliverability exactly due to this attack vector. It's astonishing how such an important security bug has been all but ignored by the team for so long even though this has been reported multiple times:

What's the reason for allowing URLs in first or last names?

I'm lost for words.

Git987886 commented 4 years ago

Did someone succeed in limiting the number of characters? Changing "max_text_length" in the table customer_eav_attribute did not help. The validation is not working at all and it is still possible to create accounts with more than the characters limit.

Changes were made to :

stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 14 days if no further activity occurs. Is this issue still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? Thank you for your contributions!