Masetrix
Well-known member
We delete the spam postings, block the accounts and use the reason for blocking "Access taken from Spambot, real owners please report to the admin ..."
Bot hacking targeting xenforo and others
- Thread starter rosal
- Start date
Mr. Jinx
Well-known member
Interesting finding @rosal!
I also find this IP address active on some accounts. Going to reset those passwords.
Wouldn't it be cool if we could compare our local user database with database likes 'have I be pwnd' through API.
If there is a match, we could reset the users password and inform the users.
I also find this IP address active on some accounts. Going to reset those passwords.
That might be possible yes. In that case, there will be more IP addresses doing this.
Wouldn't it be cool if we could compare our local user database with database likes 'have I be pwnd' through API.
If there is a match, we could reset the users password and inform the users.
Masetrix
Well-known member
That would be brute force. This would prevent the bot from entering a login with us.
However, the "bot" already has data from old (e-mail and forum) accounts. These are checked for functionality and reserved for later use.
E-mail server operators are also affected where the bot tries to use data from hacker databases to test e-mail accounts for functionality. If he finds valid accounts for his data there, he only sends a test mail from there and then moves on.
Right.
Therefore, it is nonsense to block the Bot by IP or by name.
It is better to see how many and which accounts with passwords are publicly known by watching the bot and deactivating the compromised accounts.
Masetrix
Well-known member
Yeah, i have a dream... @XenForoDevelopers.
In our case, all signups, password changes, etc. are done through main web sites (that the forums are a part of) which controls XF for us. It doesn't look like our Ukraine friends have tried to change any of the passwords yet (which would require manually going to the main site...). For our three user accounts that got breached (as mentioned above), the third user never actually logged onto the forum. The bot did, which thus automatically created the XF account since it existed in our main DB (accounts on XF are automatically created on first login to the forums if accounts exist on the main site). That's very interesting, as the bot looked like it was scanning our forums for usernames to compare to its database and then trying some. This third account doesn't fit into this theory. It is interesting that over 600 pages were scanned, 19 login attempts, with at least 3 username successes... however, 4 of the 19 were for this same username (third user). I haven't checked the other 2 usernames yet, but if if at least 6 of the 19 login attempts were successful... it is notable. It is interesting that there are so very few attempts and such a high percentage of attempts successful. It makes me wonder if the users in question had some passwords saved in a password utility on or off their computers that was breached... If that was the case, it's not yet a given they will appear in the pawned DBs.
As far as blocking vs not blocking IPs... it depends on your use case and plans. For many XF admins, it probably does make sense to keep that IP open for now. However, if you have enough policies and tech in place to inactivate stale accounts and track activity and more, then there are arguments that can be made to block. Admittedly, this probably isn't the case for most users yet.
We spent the day writing scripts and scrubbing data back to last summer. There were other Ukraine attempts, but only these 3 (from this single IP) appear successful.
In regards to a comment above, comparing logins to a pawned db has problems in and of itself, including decisions on how to handle matches especially since the positive hit rate is expected to be high. Matches aren't made for breaches from your site, but credential/pw combos in some cases, and for the most public APIs, just for password hashes. With so many breaches out there and so many of our users re-using passwords from site to site, and notably, totally different people choosing the same passwords, it's going to be an issue.
We've written XF addons before for our customer and internal use. We'll considering writing another now for wider distribution (here) and a February release. We are still crunching data first though. At the end of the day, I think as close to a solution as we can get is going to depend on attacking the problem on multiple fronts...
As far as blocking vs not blocking IPs... it depends on your use case and plans. For many XF admins, it probably does make sense to keep that IP open for now. However, if you have enough policies and tech in place to inactivate stale accounts and track activity and more, then there are arguments that can be made to block. Admittedly, this probably isn't the case for most users yet.
We spent the day writing scripts and scrubbing data back to last summer. There were other Ukraine attempts, but only these 3 (from this single IP) appear successful.
In regards to a comment above, comparing logins to a pawned db has problems in and of itself, including decisions on how to handle matches especially since the positive hit rate is expected to be high. Matches aren't made for breaches from your site, but credential/pw combos in some cases, and for the most public APIs, just for password hashes. With so many breaches out there and so many of our users re-using passwords from site to site, and notably, totally different people choosing the same passwords, it's going to be an issue.
We've written XF addons before for our customer and internal use. We'll considering writing another now for wider distribution (here) and a February release. We are still crunching data first though. At the end of the day, I think as close to a solution as we can get is going to depend on attacking the problem on multiple fronts...