Url123 Redirect. Tried everything, I am at wits end.

At the end of the day. Issue resolved. No matter how good a software is, hackers are always looking for expliots and too this end we all should work together on these and not take developers time up blaming them.

Originally Posted by stevectaylor

At the end of the day. Issue resolved. No matter how good a software is, hackers are always looking for expliots and too this end we all should work together on these and not take developers time up blaming them.

I don't think anybody is blaming the developers for the recent problems. I am sure that the developers have done their very best to write secure code, but the hackers will always be one step ahead when it comes to finding new ways to locate end exploit vulnerabilities.

But when an attack is carried out it is extremely important that the issue is investigated and the vulnerability identified. In this case a work-around has been found to stop the attacks, but no one seems to know how the attacks actually happened. And it is quite worrying to know that there is an unidentified vulnerability that may be exploited in other ways.

Originally Posted by I, Brian

That thread got locked.

The vbseo developers say there's no correlation between the 123url.info hacking and vbseo.

And yet the vbseo board is flooded with reports of being hacked, but there are only a couple on vbulletin.com - from vbseo owners.

Hard not to conclude there's an exploit somewhere related to vbseo.

Originally Posted by Bmastro

Disabling register_globals is enough? Without reinstalling all?

Originally Posted by bforum

Andrés,

Thanks for actually providing useful information instead of just ranting like Mert did. I am, however, still somewhat sceptical.

As I understand it having register_globals on is not a security problem in itself - it just makes it easier to write insecure code. So you will need insecure code AND register_globals = on in order to carry out an attack like the one many vB/vBSEO-users have seen lately. So the real question is: Where is the insecure code? In vBSEO or in vB itself?

The links you have provided do no answer that question. Many of them are related to previous issues that have been patched a long time ago. Others seem to point to vBSEO and other 3rd party addons. And your reference to a user saying that he has disabled vBSEO doesn't make much sense as he doesn't seem to have cleaned up his site following the first infection and is also using a very old version (3.8.3) with a lot of other vulnerabilities that could have been used to infect his site.

As stated by vB staff in many of the threads you are linking to: There are no real indications that sites without addons have been attacked. And that is my point: If the insecure code is in vB then thousands of vB sites would be targeted these days. But while a large number of vBSEO sites have been targeted there is no credible information that an attack (let alone a large scale attack) is beeing carried out against vB sites that are not using vBSEO or a few other addons. Even in the threads you are linking to there are only a few people claiming not to use any addons and as mentioned above even those few claims seem to be useless.

As I see it there is very strong circumstantial evidence pointing to vBSEO as the culprit here. Security experts, like Sucuri, also seem to label this as vBSEO related. And to me it simply doesn't make sense that the hackers would show such restraint that they did not use what would be a very easy way to attack vB sites. Why would they limit themselves to vBSEO sites if the insecure code is actually in vB? And as I mentioned in my previous post: If all vB sites with register_globals on are vulnerable then why hasn't vB/vBulletin Solutions issued a warning? To them it would be a disaster if such a large number of sites was attacked.

Originally Posted by Mert Gökçeimam

Hello David ,

The safest thing to do imo :

1. Search your public dir for any suspicious files
2. Disable register_global
3. Make sure your server has correct user - privilege's set
4. Protect chmod 777 directories
5. Make sure your server doesn't allow wildcard remote MySQL connection
6. Replace all passwords on your ftp , admincp , vbseo cp , db etc... with strong information
7. Use custom config.php file

I have at this point successfully cleaned and secured more than half a dozen vBulletin forums from this exploit. The exploit has not returned to any of them.

I understand that when it hits you you are angry and agitated, but nonetheless the following statements are ALL true:

1. This is not and never has been a vBSEO issue.
2. This is not and never has been a vBulletin issue.
3. This is a SERVER SECURITY issue.

To begin with, follow the steps outline by Mert above. In particular, register_globals should NEVER be "on" and in the next version of PHP it won't even be optional.

Now, disable and then re-enable ANY add-on you have installed. It doesn't matter which one - doing this will flush the datastore where the exploit resides.

Install the free vBSEO add-on that detects changes in the datastore so you alerted if it returns. There is another add-on at vBulletin.org which checks for 64-base code but that will NOT work.

Add the following to the top of your .htaccess file in the root directory of your forum:

Code:

Options -Indexes
php_flag register_globals 0

In ALL of your permissions 777 image directories - attachments, customavatars, customprofilepics, memberpics, etc., and any other custom image directories you may have - add the following to the top of your .htaccess file within those directories:

Code:

<Files ~ "\.(php\d*|cgi|pl|phtml)$">
order allow,deny
deny from all
</Files>

What this does is prevent anyone from uploading an executable file masquerading as an image file.

Change all your passwords to new secure passwords as others including Mert have already instructed you to do.

Now go to your cPanel and navigate to Remote Database Access Hosts. Look under Add Access Host or Access Hosts. In most cases, this should either be empty or should contain ONLY the IP address for your server. In particular, make sure that the wildcard option (%) is not enabled!

Now you have cleaned your datastore and secured your server. You should be malware free.

Originally Posted by bforum

What really scared me was the numerous claims by Mert Gökçeimam that "vBSEO has no security hole". That would indicate that vBSEO had already concluded that this is not a vBSEO problem (in spite of the strong circumstantial evidence saying otherwise) and that vBSEO was not investigating the issue further.

Originally Posted by bforum

Thanks for actually providing useful information instead of just ranting like Mert did. I am, however, still somewhat sceptical.

I wonder if you are ashamed about your posts at all. You choose to blame another person because of insecure servers and constantly blamed vBSEO. However in the end you can see that the issue has nothing to do with vBSEO.

Just an advice for the future , please don't try to attack anyone like this when you don't know the actual facts.

Originally Posted by Mert Gökçeimam

I wonder if you are ashamed about your posts at all.

No, I am far from being ashamed. But I am a bit surprised.

First of all I am surprised at the number of people who don't actually understand the problem here. A lot of people seem to be happy that the attacks have stopped after they turned off register globals. But people don't seem to understand that leaving register globals on doesn't make a server vulnerable in itself. It just makes it easier to exploit insecure code.

And that is the problem that I have raised: These attacks weren't caused by having register globals on. They were just facilitated by this setting. But the attacks could not have been succesfull without insecure code being present in either vB og vBSEO.

Secondly, I am quite surprised at the vBSEO staff. It seems that the vBSEO answer to customer concern is to attack the customer in a very aggressive way that looks very much like a vendetta.

Originally Posted by Mert Gökçeimam

You choose to blame another person because of insecure servers and constantly blamed vBSEO.

LOL. According to your previous post I was "constantly" attacking vBSEO when I wrote my second post...

What I have done is to voice my concern. I have also told you in details what I base my concern on. I have told you that a lot of things (and a lot of people) point to vBSEO as the attack vector. But instead of trying to present a case that vBSEO is NOT the culprit you just keep repeating one-liners like "vBSEO has no security hole" and pointing to general server security issues that do not explain how this attack could happen.

Originally Posted by Mert Gökçeimam

However in the end you can see that the issue has nothing to do with vBSEO.

Repeating the magic words "vBSEO has no security hole" and "server security issue" again and again doesn't actually convince me that they are true.

What does make me feel safer is that we - as I have mentioned before - have stopped using vBSEO. That ended my interest in vBSEO and vBSEO security related issues and I don't understand what is making you want to continue this debate by launching yet another of your attacks on a (former) customer several weeks after my last post. But if you insist on once again bringing attention to the fact that the vector behind the redirect attacks has still not been found then that is okay with me...

Originally Posted by bforum

No, I am far from being ashamed. But I am a bit surprised.

First of all I am surprised at the number of people who don't actually understand the problem here. A lot of people seem to be happy that the attacks have stopped after they turned off register globals. But people don't seem to understand that leaving register globals on doesn't make a server vulnerable in itself. It just makes it easier to exploit insecure code.

And that is the problem that I have raised: These attacks weren't caused by having register globals on. They were just facilitated by this setting. But the attacks could not have been succesfull without insecure code being present in either vB og vBSEO.

Secondly, I am quite surprised at the vBSEO staff. It seems that the vBSEO answer to customer concern is to attack the customer in a very aggressive way that looks very much like a vendetta.

LOL. According to your previous post I was "constantly" attacking vBSEO when I wrote my second post...

What I have done is to voice my concern. I have also told you in details what I base my concern on. I have told you that a lot of things (and a lot of people) point to vBSEO as the attack vector. But instead of trying to present a case that vBSEO is NOT the culprit you just keep repeating one-liners like "vBSEO has no security hole" and pointing to general server security issues that do not explain how this attack could happen.

Repeating the magic words "vBSEO has no security hole" and "server security issue" again and again doesn't actually convince me that they are true.

What does make me feel safer is that we - as I have mentioned before - have stopped using vBSEO. That ended my interest in vBSEO and vBSEO security related issues and I don't understand what is making you want to continue this debate by launching yet another of your attacks on a (former) customer several weeks after my last post. But if you insist on once again bringing attention to the fact that the vector behind the redirect attacks has still not been found then that is okay with me...

You are, quite simply, wrong. Read my post above and the post by Mert. If you have not followed those steps, you are still vulnerable, with or without vBSEO.

What does make me feel safer is that we - as I have mentioned before - have stopped using vBSEO. That ended my interest in vBSEO and vBSEO security related issues

I have used vBSEO for 6 years, over about 8 or 9 sites.

The only site that has ever suffered from this exploit was one that was on shared hosting. It took about 20 minutes tops to sort out, following the instructions, and suggestions on the relevant thread, and has never, ever returned once.

All the other sites have never suffered from it, using vBSEO, vBulletin and other software.

If it was a general bug / exploit in vBSEO then logic tells me that all my sites would have been hit. (Incidentally all the other sites are on our own dedicated server)

I appreciate that some replies on here can be construed as short tempered, etc but that is the beauty of the written word, everyone reads it quite different.

Mert speaks a foreign language, whereas I speak English as my main language, and sometimes his way of saying things or explaining them, are not quite perfect in the way I would expect them to sound. That is hardly his or anyone else's fault, its the way of the world and the internet.

I have read hundreds of posts on here off irate people because they have been hit. But what is definite, whilst vBSEO may have been at fault back in January for their code left behind etc, they have gone over and above, in tools, help, support, and answering queries etc to help people recover from it, even though on hindisght, it was not actually their fault afterall.

The issue is mainly down to the insecure servers as documented on here hundreds of times.

FWIW I think you have made an error and have effectively undone all the hard work that vBSEO may have done for your site historically, but I respect your decision to remove it.

Put it down to life, and a misunderstanding of the written word etc and best of luck in the future with your site/s.

Originally Posted by djbaxter

If you have not followed those steps, you are still vulnerable, with or without vBSEO.

I actually agree with you. But the point is that your post doesn't contain any new information: You just repeat some very good security advice and mention some previously discovered exploits. And tell us that the problems are not vBSEO related.

But just as in previous posts by others you provide no real explanation as to why thousands of sites were attacked a few months ago. Your explanation just seems to be that "they used old tricks" that suddenly made it possible for them to get in to thousands of servers. But your explanation isn't backed up by anything (logs, a study of the sites attacked etc.). So to me it seems more like a qualified guess than an actual explanation. And when it comes to the security of our server I prefer not to guess...

Originally Posted by bforum

I actually agree with you. But the point is that your post doesn't contain any new information: You just repeat some very good security advice and mention some previously discovered exploits. And tell us that the problems are not vBSEO related.

But just as in previous posts by others you provide no real explanation as to why thousands of sites were attacked a few months ago. Your explanation just seems to be that "they used old tricks" that suddenly made it possible for them to get in to thousands of servers. But your explanation isn't backed up by anything (logs, a study of the sites attacked etc.). So to me it seems more like a qualified guess than an actual explanation. And when it comes to the security of our server I prefer not to guess...

Perhaps you missed this part of my post:

I have at this point successfully cleaned and secured more than half a dozen vBulletin forums from this exploit. The exploit has not returned to any of them.

It's not a "guess" of any kind. What I said is based on experience with this exploit and learning how to eradicate it and ensure that it does not return.

Now answer this question:

Have you performed ALL of the steps mentioned in my post and Mert's?

Hi
I (my forum) was affected by this url123.com virus. Basically if you search on google for my forum and click on the search result for my forum, it would take you to a spam site. Happened once last month. I had my hosting company clean it. I thought it won't return. BAM two weeks later, same thing. So this time I took the matter very seriously.

I followed Andrés Durán and Cem Kümük's advice from the ticket (also partially followed mert's and djbaxter's

Originally Posted by Mert Gökçeimam

text

Originally Posted by djbaxter

text

post as well. you may click on to see the post).

Here's what I did:

a. I had my hosting company scan and remove the malware and database injection.

b. I also had them turn off register_globals as well.

c. I have updated my vbseo from 3.3.0 to 3.6.0 PL2

I plan on changing password for forum, vbseo and cpanel (am I missing any?). So, my BIG question to you guys would be, what can I DO next or what security steps I should do next to make sure I don't get hit by this spam or other url redirect etc EVER again? your suggestion will be very appreciated. Thank you for you time.

Originally Posted by Metalgearsolid_x

Hi
I (my forum) was affected by this url123.com virus. Basically if you search on google for my forum and click on the search result for my forum, it would take you to a spam site. Happened once last month. I had my hosting company clean it. I thought it won't return. BAM two weeks later, same thing. So this time I took the matter very seriously.

I followed Andrés Durán and Cem Kümük's advice from the ticket (also partially followed mert's and djbaxter's

post as well. you may click on to see the post).

Here's what I did:

a. I had my hosting company scan and remove the malware and database injection.

b. I also had them turn off register_globals as well.

c. I have updated my vbseo from 3.3.0 to 3.6.0 PL2

I plan on changing password for forum, vbseo and cpanel (am I missing any?). So, my BIG question to you guys would be, what can I DO next or what security steps I should do next to make sure I don't get hit by this spam or other url redirect etc EVER again? your suggestion will be very appreciated. Thank you for you time.

you should be fine with that. Also it would be good protect directories, add a second "login and password" to control panel, etc...

From my post above:

In ALL of your permissions 777 image directories - attachments, customavatars, customprofilepics, memberpics, etc., and any other custom image directories you may have - add the following to the top of your .htaccess file within those directories:

Code:

<Files ~ "\.(php\d*|cgi|pl|phtml)$">
order allow,deny
deny from all
</Files>

What this does is prevent anyone from uploading an executable file masquerading as an image file.

and

Now go to your cPanel and navigate to Remote Database Access Hosts. Look under Add Access Host or Access Hosts. In most cases, this should either be empty or should contain ONLY the IP address for your server. In particular, make sure that the wildcard option (%) is not enabled!

If you have NOT done these two steps, you are at risk for re-infection.

Also, double check your directory permissions and ensure that any folders that do not need to be 777 are 644.

Originally Posted by djbaxter

Install the free vBSEO add-on that detects changes in the datastore so you alerted if it returns. There is another add-on at vBulletin.org which checks for 64-base code but that will NOT work.

Where can I download this?

See this thread: http://www.vbseo.com/f5/faqs-rogue-p...release-52862/

Download file from here: Download the Testing Utility (vbseo_checkplugins4.zip v.4

Originally Posted by djbaxter

In ALL of your permissions 777 image directories - attachments, customavatars, customprofilepics, memberpics, etc.

Is there a graphic or table of which permissions I have usually to set in vbSEO/vb? I got a lot of files which have 755 but only this directory got 777: clientscript/vbulletin_css

Should I change all 755 to 644?

Originally Posted by djbaxter

Now go to your cPanel and navigate to Remote Database Access Hosts. Look under Add Access Host or Access Hosts. In most cases, this should either be empty or should contain ONLY the IP address for your server. In particular, make sure that the wildcard option (%) is not enabled!

My Hoster told me that I cannot change this, because I use a shared webspace... what now? I cannot afford a server and it is a good hoster so far.