911traff exploit on my RN 2.10.01 site

Worker Joined: Feb 18, 2006 Posts: 155 Location: Virginia

Well it looks like I have some type of javascript exploit on my site. It started
with users having problems with their IE browser on the site. After looking
closer I have found an IFRAME line in all of my index.php files sitewide.
My nuke is running in a subfolder but I even have this corruption in my root
index files.

here is the gist of the line:

IFRAME name...StatPage src...http://www.911traff.com/trf/traf.php123

I put a 123 at the end so the link won't work. I wouldn't visit the link but
I need suggestions on how to proceed. My site has IFRAMEs that we put
in it and it has several javascripts running. Any suggestions.

We are a gaming clan site and have had this site for 2 years. I am running
the latest NukeSentinel and RN 2.10.01.

Posted: Thu Oct 11, 2007 9:11 am

In order to change your PHP files, they must have access to your site. I'd start by changing all my admin passwords and make sure your have the CGI auth running in Nuke Sentinel. Then I'd reload my files from a backup after checking to make sure that the backup hasn't been exploited. Also, if you have any modules other than the standard ones that come with RN then I'd suspect that someone might be exploiting them to upload files. Also look thru the files on your server and make sure they have not added any ... this could be how your site is being exploited.

Look at your authors table too and make sure no new records have been added. And change your passwords in there.

Subject Matter Expert Joined: Feb 23, 2004 Posts: 358

You should have a fairly good estimate on when this breach most likely occurred. You need to contact your webhost support and ask them to go through their raw logs and find out which script was initially exploited, and then what they did afterwards (if anything). If your webhost is worth .02's, this will be extremely easy for them to find and provide to you.

PHrEEk

Posted: Thu Oct 11, 2007 9:51 am

I'd look in your config table with phpMyAdmin. They often slip iframe's into the footer lines in the database.

Posted: Thu Oct 11, 2007 1:27 pm

Thanks for the tips.

I do have CGI Auth running. One thing I am not sure how to do is changing
the CGI Auth & GOD passwords.

Posted: Thu Oct 11, 2007 2:22 pm

This sucks. I did a WinMerge and compared my most recent file backup (fortunately a clean backup)
and I must have about 200 index files...and every one has this IFRAME
line in the file. However, I don't see any evidence of database corruption.
I checke the Auth and Config tables and they look normal.

Posted: Thu Oct 11, 2007 2:29 pm

Just a guess, but I'm betting they have somehow planted an exploit file on your server that is in turn corrupting the rest of the files. You might want to look for any extraneous files ... I know this can be a p.i.t.a.

Posted: Thu Oct 11, 2007 2:58 pm

I did a WinMerge on my entire root and found no Unique files that are not
in my backup. I did also find a corrupted index file in my server's
private_html folder. I would have expected to find a rogue file or
something. Could such a file be hidden on my server when I can't
see it? By hidden I mean "not-visible" in my ftp program...like htaccess
files are hidden.

Due to the extensive number of files involved, I will prob have my server
host re-establish the server and reupload everything. The only module
I installed since my backup is Multiheadlines. This infection has happened
more recently.

Can a hacker use a javascript or IFRAME that I already have installed on
the site to do this? If so, I want to find the script with this hole and get rid of it.

Posted: Thu Oct 11, 2007 3:27 pm

Another observation....an index.htm file has been created in every folder
where there was no index file already. The only line in these rogue index files in that same
IFRAME line.

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

Do a Google search for traf.php. You are definitely not alone!

Posted: Thu Oct 11, 2007 6:25 pm

Also, see
[ Only registered users can see links on this board! Get registered or login! ] [ Only registered users can see links on this board! Get registered or login! ]

Posted: Thu Oct 11, 2007 7:04 pm

I read through everything but did not see a remedy to the problem. It sound
like some scary stuff. from what I understand, it uses websites to infect
personal PC's to obtain personal info.

I have asked my server host to reinstall my server and change my server
password. I have also asked our members to do a virus, spyware, and
adware scan. Does this sound like the right things to do?

I don't know what else to do.

Posted: Thu Oct 11, 2007 7:29 pm

Through just a random reading it appears it might have been a cPanel exploit. I would advise you to let your host know that the entire server may have been compromised and give them the links to have them check the server.

Posted: Thu Oct 11, 2007 8:16 pm

Yep, that information is best in the hands of your webhost's security and support center. Hopefully they have qualified people to get to the bottom of it. That's why I suggested you tell them what time frame you suspect the problem started, and they can begin by looking at the logs and go from there. You shouldn't go this alone, and you should not have to 'guess' about what precautions to take. You pay for a service, and that should include security issues and resolution. If you don't get that, you need to change hosts. Good luck and good hunting!

PHrEEk

Hangin' Around Joined: May 30, 2004 Posts: 46

I had the same problem happen to me about a month ago where index files with the iframe where in every directory. Search google I found an exploit the the cpanel has where your password can be found.

Check in you cpanel -> FTP Accounts for any unauthorized accounts. Also check cpanel -> Weblizer FTP for any unauthorized ip and/or user accessing [ Only registered users can see links on this board! Get registered or login! ]

Change ALL your passwords.

Posted: Fri Oct 12, 2007 1:14 pm

Only my site was affected on the server. Host pinpointed the date of the
breach. My PC system is clean of any viruses/trojans etc. My host does
not use cpanel. It must have been a password breach. I had the user
and pass for 2 years and never changed it and it was not a strong password.
They are reinstalling my site and I am about to restore from a backup.

1 Question.....Is there a way that I can change the password for my GOD
account and a subadmin account directly in the database before installing?

I tried experimenting how to change the password on the infected site using
the admin backend...but I got the black screen of death. I guess the infection
prevented me from changing it then.

Posted: Fri Oct 12, 2007 1:51 pm

[ Only registered users can see links on this board! Get registered or login! ]

Posted: Fri Oct 12, 2007 3:28 pm

Thank you Raven...and everyone here for your help. I am working on
restoring the site now. Things should be back to normal soon.

Posted: Fri Oct 12, 2007 4:19 pm

Raven wrote:

http://www.ravenphpscripts.com/faq-2-.html#9

Off-topic...

Wow...that works? Nuke doesn't use a salt? What the heck is that site key string in config.php for anyway?

Posted: Fri Oct 12, 2007 5:35 pm

I have found that you can just put the text of what password you want into PHPmyadmin and then apply the md5 function to it (that's in the next column over to the left from the value column and it's called function and there's a dropdown and md5 is one of the choices). You will then wind up with a md5'd password which is what Nuke uses.

Posted: Fri Oct 12, 2007 6:50 pm

Wow, yeah, I just looked at Your_Account and Nuke doesn't use a salt. Not cool. And now back to the topic at hand.... Wink

Posted: Fri Oct 12, 2007 7:55 pm

Gremmie wrote:

Raven wrote:

http://www.ravenphpscripts.com/faq-2-.html#9

Off-topic...

Wow...that works? Nuke doesn't use a salt? What the heck is that site key string in config.php for anyway?

The sitekey was never used to build the password. It was used as part of the code creation for the original numeric "captcha'.

Posted: Fri Oct 12, 2007 8:09 pm

If you read up on some topics over at Waraxe, you'll see that all Nuke passwords are straight md5 hashes, and that they (the hacking community) have a few different software solutions for cracking md5 hashes. Using injection to add an entry to the authors tables is just one way to gain access. The other is to hijack an admin cookie (which contains the information about the hashed password), then use their brute force software to crack the hash. Then they simply login with your username and pass.

If you educate yourself on the available server-side security options, you can create additional layers that a hacker would need to get through, even if he had a nuke admin login/pass. There is no such thing as 100% authorization until we can do a fingerprint or retina scan over the internet Wink

Therefore, all you can do is make it an extreme hassle and waste of time for a hacker to get in.

Understand this... a VAST majority of all Nuke sites just contain content. Most hackers only want to tag your site with their banner or whatever. The TRUE motivated hacker seeks personal information like credit card numbers or what have you... these hackers will spend the time to try and breach additional layers, because there is a real potential monetary goal involved. Hackers who just want to hang graffiti on your site will NOT spend the days or weeks getting through extra layers, and will move on to an easier site. So, the moral to the story is, the use of an extra layer or two tends to discourage about 99% of any attacks, and that's a good number to have in your corner.

PHrEEk

Posted: Fri Oct 12, 2007 9:03 pm

Agree, just can't believe Nuke isn't using a salt. That would make these dictionary attacks on the passwords a little harder. Harder enough to discourage the kiddies, but not the determined ones as you mention.

Posted: Fri Oct 12, 2007 11:51 pm

I have all the changes to "salt" the cookie password so that it doesn't contain the original MD5 hash stored in the database. While I would like to "salt" the database passwords, it would require all users to re-input their passwords. The conversation is not an easy step for any existing site right now.

Once I finish testing these changes, I will release them as a part of the security patches