Quote:
No idea how the captcha and register.php talk to each other, but that means the captcha is not working and the robot is posting directly to register.php.

It would be useful to take a look at your server access logs. With a human registration, you'll see a POST method request for register.php. The first part of the entry will look like:



The leading IP address is the host making the request. You *could* block the address, but if this is a sustained campaign the address will change. The second part is the referer. For a human registration it should be like:



If this is blank, it will be relatively easy to block. If not, then you need to back track and find if there is a GET request for register.php. If the referer is missing here, it can also be blocked. If not, then it needs a developer fix.

It is possible that the user agent string (following the referer) contains 'libwww-perl', in which case you can use the fix mentioned in my earlier post. However, I would suspect the UA has been spoofed to look like a regular browser, or Google, but you never know!.

It is a world wide campaign. Also XOOPS France users have reported this problem.

From my Apache logs, I get them regulary with following pattern:
GET /modules/newbb/index.php
GET /register.php
GET /modules/profile/register.php (par redirect)
POST /modules/profile/register.php
GET /modules/newbb/index.php
POST /user.php (not always)
GET /user.php?xoops_redirect=%2Fuser.php&PHPSESSID=xxx (not always)

Done by IP: 219.157.200.19, 221.236.180.178, 68.169.137.67, 188.92.74.83, 58.68.9.242, 86.197.145.201, 75.135.132.235, 24.144.201.189, 207.62.142.147, 219.157.200.19, 143.90.221.194, 8.9.209.2, 24.42.110.110, 95.172.24.210, 218.102.129.141, 121.96.179.27

Until now, none of them succeeded (knockin' wood).

The multitude of IP and the fact that sometimes the IP changes during the sequence, prove that this is done trough a botnet.

It started mid august.

It seems that it can solve the captcha. Has anybody logs to sustain that?

I think it is maybe possible to block the registration by adding a field that is obliged to fill in during registration on the first page. I think you should set the preference for saving between pages to off.

@preachur: which captcha did you install exactly?

If the white page came after submitting the form, then there must be something wrong with the code that is verifying the Captcha. Can you show an extract of your change?

If you have no interest in the users of the places with the botted computers, block their net with .htaccess eg for 74.53.160.210


@Peekay: The user agents looks normal eg:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Mozilla/4.0 (compatible; MSIE 6.0; America Online Browser 1.1; rev1.2; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)
Also the referrer is correct: /modules/profile/register.php
To know more about the post on register, we need a way to log the posted query.

Can you find a GET request for register.php, before the POST, without a referer?

It's just that I have a contact form spammer on a non-xoops site and their robot use a GET with no referer, followed a few second later with POST with the correct referer. Blocking the POST method doesn't work, but blocking the GET does.

I'm confident that the user agents will all be spoofed.

Ultimately, it may not be possible to block in htaccess, but worth a try first.

No, all referrers were defined.
Only .htaccess blocking is via IP or net. Only problem is there are a lot!

Well, I've checked the logs on a couple of my XOOPS sites and there are some GET requests for register.php without a referer (direct requests, search engines... who knows). User registration is turned off, so I don't have an actual incident of robot registration to investigate.

Blocking access to register.php if the referer is blank might work, or maybe not. If the exploit originates from a chain of elite proxy servers, even blocking the host addresses will prove futile.

IMHO this needs to be taken up by the XOOPS devs ASAP as a security issue.

The captcha is supposed to ensure that human interaction is detected before allowing a registration to proceed. At the moment, this safeguard clearly doesn't work.

The knowledge of some of you is awesome. However, from someone who regards himself as an informed user but not an expert, what would you say is the objective of such bot registrations?

Second, I have reviewed the last half dozen registrations on my 2.3.3 site but didn't see any using google.com as their URL.

I then searched the URL field in the users table in the XOOPS db for google.com and found two registrations, both occurring on 11/10/09. One was activated, one was not. I deleted the first of these but have kept the second one temporarily. It is interesting that I apparently did not get a notification email for these registrations even though I am set to do so. Is this bot somehow able to block sending them? Would requiring admin approval of registrations block this activity?

I do have some custom fields that come up in the second page of the registration process, a couple of them required. All of these fields had been filled in with nonsense strings of characters.

I haven't yet tried to find these entries in my server logs but if you guys think the info would be useful I can go digging for it.

Barry Cooper (barryC)

Quote:It surely would. With date and time of the registration from the user, it would be easy to locate it in the logs.

Do you have the captcha enabled?

PS when you delete the user, you allow them to register again with the same email address. Best is to have a banned users group, where they can be moved to and set all permissions for this group to off. (When they are logged in, they find they have even less possibilities then when being anonymous.)

@barryc

I just logged in to post the same suggestion as Ghia regarding banning users (beat me to it!).

The people behind this exploit have clearly found a loophole in XOOPS authorisation system. It could be a 'proof-of-concept' attack with no objective other than for the hacker's amusement. I haven't read of any destructive actions being carried out as a result of the registrations?. The most common result is comment spam, e.g. multiple posts in the user forum.

However, if a robot can easily become a user, it may develop a longing to be the webmaster, so this needs to be treated seriously.

There is very little info to evaluate in order to block automated registration requests using an htaccess file, so I think some changes need to be made to XOOPS registration procedure.

I do have captcha enabled on my site.

I just went looking for the log entry for the one "google.com" registration that I have. When I look at the profile for that user it is time stamped Nov. 10, 09:7.28 (i.e. Member Since 11-10-09:7.28). The problem is, I cannot find a log entry that accesses register.php corresponding to that time. I have cut and pasted my log entries for Nov. 10, 09 and saved it as a file. I could send that to one of you if you think you could help find suspicious entries. I have found several on that day that look odd to me in that there are successive accesses in close succession, that is only 1-2 seconds apart, which seem faster than a human could fill out forms. Please let me know if one of you would be willing to receive the file by email.

Another odd thing I noticed for this registration is that two fields in the second registration page, namely first name and last name, which are required fields, were not filled in. If I try to do a test registration without filling in those fields, the attempt is rejected. I'm wondering if this bot bypasses the second registration page.

It would be useful for XOOPS to record the IP address when users register. I don't think it currently does this. Am I correct? I realize the IP may be spoofed but it would make finding the entries in the log easier.

Finally, I had not thought of the banned users group idea and I've implemented it now. I moved my one "google.com" user into it. All check boxes for module and block access are left unchecked. One odd thing I noticed is that if I try to bring up the profile of the user through the profile search option I am denied access, even though I'm logged on as webmaster. I can only access the account by using admin/find user, then clicking edit when the hit comes up. If I click on the userID, again I am denied access. Can anyone explain this?

One obvious problem with this is that relying on not allowing a certain email address to be used twice won't work if the email address is being spoofed and varied. This technique, though, would be a useful way to block legitimate registered users who are for some reason unwelcome (usually for posting inflammatory or indecent remarks).

Let me know if one of you is willing to look at that log file. It's not too big.

Barry Cooper (barryC)

You have a PM