We have been noticing a large number (~3400) of fake signups over the last year and have not been able to determine where they are coming from. Common parameters:
They often come from weird, yet validly formatted, email address (many in the .ru TLD or from thefmail.com)
Some use cyrillic or arabic characters in their name (we are basically focused only on US English speakers by our content)
They do NOT trigger the Intercom.io javascript for account signup notifications
They somehow defeat reCaptcha 3
They sometimes use URLs for their username
They don't confirm (devise_confirmable)
We've been handling these by disabling the accounts, and there's obviously a few items above we could use to identify these before they even get created, but I was wondering if someone's cracked this nut already or if there's some simple best practices (pwned db check?) that might cut this down to a dull roar or out entirely.
The two big "I don't get its" are bypassing the JS and defeating recaptcha. Is this just mechanical-turking?
Do you know whether these users have been created by the same IP address? (probably not). Are the accounts sporadically created or are they created in batches? The gem rack-attack could be used to mitigate this issue, especially if at least one of these conditions is satisfied. It also comes with some sort of fail2ban filter which could be helpful, as it is designed to detect suspicious requests from 'misbehaving' clients.
I also can't understand how they possibly bypassed recaptcha.
Related
For a few years now I observe a strange behaviour, most likely triggered by enduser's email clients using my webapp (Ruby on Rails system, doesn't matter tho).
I am running a mid sized business and send out thousands of mails to my customers each month who buy leads from me.
The emails include two links, one to buy the lead and the other to give feedback. There is a dynamic part in both URLs which is a UUID, example:
offer/968ec0c1-e105-4c70-95b2-fd0c799b58f3
and
feedback/968ec0c1-e105-4c70-95b2-fd0c799b58f3
Every now and then, my webapp gets accessed at the same time on both links (which makes me confident it is not the user since it is the very same second they get accessed) but with different dynamic parts in the url, so i see in my logs
offer/NGVjZjA0YT
and
feedback/NGVjZjA0YT
It is always a random string with a length of 10 chars.
So this is not a big deal since it happens only 1-2 times per week and as far as I can tell no user is really affected by this, but still I wonder what's behind this. Did any of you experience a similar thing?
Maybe an email client wants to crawl / load a preview, seeing an uuid pattern in the url and changes it because whatever?!
I disabled link click tracking in the email sending provider (sendgrid), just as a side note. So they won't / shouldn't replace the email links. Also experienced this when sending links via AWS SES.
Im just curious. Any ideas or experiences? Thanks in advance & have a great day!
Apple's latest changes which allow users to hide their IP, hide their email, etc. are creating problems for my web-based app (non-native) which relies upon these things to build a sense of who a person is.
In most situations, I can see why these are great "features" to have, however in my use case I have a voting platform that utilizes things like email address and IP to do a decent job at detecting duplicate votes or fraudulent vote (i.e, logins from other countries, etc.).
Now, before anyone says "These aren't foolproof ways of identifying a person" and derail my actual question: I know. I'm not looking for perfection, but these methodologies shed light on the 95%+ of people who might be trying to circumvent our voting system.
Apple placing the ability to circumvent these measures by being right up in front of the user as a first-class feature shoots major holes in my existing strategy.
Is there a way to detect if a user is utilizing these methods to where I could prompt them that they need to sign-up without using these features?
I think it would be easily justifiable to explain that, due to the nature of the application being a voting website, the ability to create multiple aliases would directly undermine the purpose of the site.
Perhaps there is an email address pattern to look for (I know in my test cases, I was getting email addresses #icloud.com).
If there is no reasonable way, I need to rethink the entire process of identifying individuals and preventing aliases (phone / text confirmation, etc).
I'm not sure that this is a stack overflow appropriate question. If not, I'd appreciate a pointer to a more appropriate forum, as I haven't been able to find one.
I have a small website project that gets a few hundred daily unique users and on average I get one or two people to create an account per day. Yesterday I noticed that more users were signing up (like about 50) and today another 150 users signed up. Wonderful, right? Except that then I noticed that while the emails look legitimate, all of the usernames ended in same letters. My site requires that email be confirmed before a user gets any additional access and none of these accounts have confirmed their email. There is no apparent regularity to the creation of these accounts other than that it is happening with slowly increasing frequency.
My first question is, what is the most effective way to prevent this with the least user impact. The only thing that I can think of is adding a captcha step as part of account registration. I really dislike captcha so if anyone has a better idea for a general solution to this I'd appreciate it.
I'm also interested in this: What could this malicious user be gaining by doing this? It's not yet anything other than a minor nuisance to me. The accounts are easily identifiable and they're not (yet) being created at a rate that could represent anything like a denial of service attack. The only thing I can think is that they're trying to confirm that these emails are registered on my site. But I can't think why that would be useful. Also, if the email addresses are real, they're using my site to spam those email, but the spam is a registration confirmation for my site. So I guess they might eventually get my email provider to shut me down if they keep this up.
Thanks in advance for any help, even if that's a redirect to a different forum.
Other possibly useful information:
My site is hosted on Azure using asp.net mvc5 with identity framework
I believe that the emails are legitimate because my email provider
shows a very small bounce rate (like 1%) on these emails.
There are 2 more options which are SMS-Confirmation(by limiting the phone number), and IP restriction.
I am using Authlogic for a Ruby on Rails (2.3.9) app that I built where users can track workouts. As it grows in popularity I am worried about false/malicious sign-ups. What is the best practice here or advantages and disadvantages to each approach.
Should I simply require that the user confirm their email before successfully accessing my app? Should I only require the user fill out a successful Captcha? Are these two things mutually exclusive or should they be used together?
Just looking for some general discussion around this so I better understand.
Any botnet can set up their own mail server to spam you...
Several can get past captchas too...
Use email confirmation, captchas, and gotchas (Hidden field humans wouldn't fill in)
There are bound to be many others (Bocking all russian and chinese IPs is one of the more extreme ones) but those are the most used currently...
It's been my experience that some spam bots are actually not bots at all but rather humans from 3-world countries paid to sit there and fill out all kinds forms for whatever reason. This means that while email confirmation and captchas help, you're still bound to get some spam.
There's a few other things you could consider:
If the site is social, implement a flagging system which causes the community to become the moderator.
Have all users disabled by default, then require an admin to approve or delete them.
Require a credit card to sign up.
Some of these may or may not work depending on your case. I've found that #3 pretty much eliminates spam all together, but it may also discourage real potential customers.
Good security has more than one layer. I would at least use both and also add in functionality for auto-blocking and auto-admin alerts when attempts to escalate privileges/access blocked pages occurs. Write code to make it easy for you to permanently block certain IPs, etc… if you want as well (I like to be able to block from a secure link, because then it can be called by other services with a secure API call).
You should obfuscate email as well anywhere that it appears on a page (in my opinion, as this will help a little; not as much as it used to, though):
def obfuscate_email(email)
return nil if email.nil? #Don't bother if the parameter is nil.
lower = ('a'..'z').to_a
upper = ('A'..'Z').to_a
email.split('').map { |char|
output = lower.index(char) + 97 if lower.include?(char)
output = upper.index(char) + 65 if upper.include?(char)
output ? "&##{output};" : (char == '#' ? '#' : char)
}.join
end
I've been working on a web app that could be prone to user abuse, especially spam comments/accounts. I know that RECAPTCHA will take care of bots as far as fake users are concerned, but it won't do anything for those users who create an account and somehow put their spam comments on autopilot (like I've seen on twitter countless times).
The solution that I've thought up is to enable any user to flag another user and then have a list of flagged users (boolean attribute) come up on a users index action only accessible by the admin. Then the users that have been flagged can become candidates for banning(another boolean attribute) or unflagging. Banned users will still be able to access the site but will have greatly reduced privileges. For certain reasons, I don't want to delete users entirely.
However, when I thought of it, I realized that going through a list of flagged users to decide which ones should be banned or unflagged could be potentially very time consuming for an admin. Short of hiring someone to do the unflagging/banning of users, is there a more automated and elegant way to go about this?
I would create a table named abuses, containing both the reported user and the one that filed the report. Instead of the flagged boolean field, I suggest having a counter cache column such as "abuse_count". When this column reaches a predefined value, you could automatically "ban" the users.
Before "Web 2.0", web sites were moderated by administrators. Now, the goal is to get communities to moderate themselves. StackOverflow itself is a fantastic case study. The reputation system enables users to take on more "administrative" tasks as they prove themselves trustworthy. If you're allowing users to flag each other, you're already on this path. As for the details of the system (who can flag, unflag, and ban), I'd say you should look at various successful online communities (like StackOverflow) to see how they work, and how successful they are. In the end it will probably take some trial and error, since all communities differ.
If you want to write some code, you might create a script that looks for usage patterns typical of spammers (eg, same comment posted on multiple pages), though I think the goal should be to grow a community that does this for you. This may be more about planning than programming.
Some sophisticated spammers are happy to spend their time breaking your captcha if they feel that the reward is high enough. You should also consider looking at a spam server such as akismet for which there's a great rails plugin (https://github.com/joshfrench/rakismet).
There are other alternatives such as defensio (https://github.com/thewebfellas/defensio-ruby) as well as a gem that I found once which worked pretty well at detecting common blog spam, but I can't for the life of me find it any more.