this is just a public service announcement concerning spammers and their game... and a question.
lately my error log has been populated in groups of 93 errors each, and all for a IP'less guest (possibly ipv6?) and pointing toward the security.php and the cleantalk.php (mod i have running).
the attempted URL is always more than 128 characters after index- and resembles a session token. So, it appears these guys are trying to get in using recycled sessions?
it's not a problem for my forum (the primary one, anyway) as i don't handle sessions in that manner, but... for folks using flat files written to a folder that is easily accessible or is pointing to a common location (such as /tmp), and while having their php arranged to recycle sessions, it certainly could be an issue.
I know this is nothing new, but it sure seems popular lately.
the only errors i see (other than users entering incorrect passwords) are related to this, and they are usually attempting to access a page directly (as example: index.php?action=post;topic=xxx;num_replies=xx)
which kinda indicates to me what their intentions are (posting in a thread)...
question: is there a way to see what they are trying to post using these breadcrumbs left behind? I just want to have absolute confirmation this is what is happening, and possibly find the source with this information, if obtainable. (i suspect it's some organization paid to help some poor sap's SEO/ranking, and/or direct links to some site selling something in the questionable categories)....
[ I was thinking 'they' are doing this in an automated script that appends the SMF sites URL to the script and executes it in one shot- including the content of the attempted post. ]
thanks all!!!
If I really wanted to make them disappear (go to the source of the problem, as you pointed out), I would go fishing :). There are probably better ways to do this, but I would let one of them register and post in the forum, copy the content, delete the account afterwards and do with that info... whatever it is I wanted to do.
Oh, almost forgot :). I would make a backup first :D.
Just for the record, been having problems with bots for years. There are always around 10 bots crawling my forum. Some of them managed to register and post (deleted the posts, deleted the accounts, can't remember what it is they posted, something to do with the growth of a certain human organ :D), so I just raised the security of the forum (default captcha integrated in SMF 2.0.15 set on extra hard and 3 questions).
I dont have a problem with them getting through... Fortunately. :-)
The sessions arent managed via server stored files, they're on the client and/or in ram...
However, its my guess these guys scour web for smf installs and then attack when found... The exploit is likely solely on instances of smf that use file sessions and store in common named and unprotected directories. If this is the case, I wager they bust right through.... Which is why I mentioned it here, so folks can take measures to prevent it and which may be as simple as renaming the ditectory the sessions files are stored, or ensuring its not readable by just anyone.
These guys are jerks, no? Is the money that good in doing this stuff? I wager they'd make more simply taking donations to stop!!! :-)
Quote from: drewactual on March 04, 2018, 05:20:43 PM
Which is why I mentioned it here, so folks can take measures to prevent it and which may be as simple as renaming the ditectory the sessions files are stored, or ensuring its not readable by just anyone.
As far as I know, php dumps the sessions in a temp folder, which is emptied from time to time... and I think you can't access this folder, it's not in your webspace, it's shared by all of the users on a shared hosting server.
I think they're just trying to brute force their way in. First line of attack, try to post, maybe the admin forgot to block posting of unregistered members. If that fails, try to register and post... and keep doing this until the server starts to bleed :D.
definitely trying brute..... they just hit my security php 372 times in the same second. the error is "looking for array returned null", and the only thing recorded as to 'who' is a session's ID.
my old shared server set the sessions file to a directory called '/tmp', which was accessible only by me, and with a permissions of 0755, but you're right- in many shared environments it's in a top level directory above and local users, and shared by all on that server.
i use memcached as the handler and hold the sessions in suspension, making it more difficult and something not easily mimicked.
i've studied what i do know about these guys- and i just went three days without a visit from them- and all i know is they are pretty well cloaked... i guess i could install a server level track on all approaching IP's and at least identify them there, and then install a server level IP ban (stopping them before they get in even as far as the forum) but at risk of slowing the page as well as potentially impacting honest users.
Just remember that they tend to change IPs every few days or so. That's why I never bothered to block them. The new IPs are within the same range, but I firmly believe that blocking an IP range is not a good idea.
Quote from: drewactual on March 04, 2018, 05:20:43 PM
However, its my guess these guys scour web for smf installs and then attack when found... The exploit is likely solely on instances of smf that use file sessions and store in common named and unprotected directories. If this is the case, I wager they bust right through.... Which is why I mentioned it here, so folks can take measures to prevent it and which may be as simple as renaming the ditectory the sessions files are stored, or ensuring its not readable by just anyone.
I'd wager they are not specifically aiming SMF, but all sorts of scripts on the web - searching for outdated versions using known weaknesses.
If you take a look at your server's access logs, you'll see all sorts of funny attempts made blindly...
Quote from: Aleksi "Lex" Kilpinen on March 13, 2018, 01:37:07 PM
I'd wager they are not specifically aiming SMF, but all sorts of scripts on the web - searching for outdated versions using known weaknesses.
Agree on that ;).