HACKED - Make sure you are secure

[Paul M]

Originally Posted by knucklenitz

Is there some other way, other that the hacker breaking the config.php that they could manipulate the database?

Yes, you could have a modification installed that is open to SQL injection attack. This is the most likely method.

[Angel-Wings]

Originally Posted by knucklenitz

Just to make sure I understand, moving the config.php to another directory out of the public html will not affect vb operation?

This won't increase security at all for the simple fact your VB still needs to be able to read that file. So you may move it around on the filesystem, still find a way on how VB can read this file, either by symlinking or something else.
If that is done, every "hacker" will be able to read that file as well.

Better spend your time keeping your VB & Plugins up-to-date and use things like mod_security / suhosin and the typical setups like chroot / jail. That's more time consuming but no "security by obscurity" when moving some files just to have a work-around that VB can read them.

And make sure your VB files aren't writeable by PHP itself, if you store uploads in the filesystem, move that directory outside the webroot and additionally some directories like images / signaturepics - don't need PHP because there just images are stored.

Something simple like:

<Directory /where_ever_your_vb_is_stored/(clientscript|cpstyles|customavatars...)>
php_flag_engine Off
</Directory>

<Files "/where_ever_your_vb_is_stored/includes/config.php">
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Files>

Then moving the "uploads" directory outside the webroot that it can't be accessed directly.
Finally - mod_security & suhosin should be used. First starting them both in logging mode to collect a whitelist, highly depends on how your forum is used, and once that whitelist is completed to sort out false-positives set both in blocking mode.

And - as last addition - you can setup an IDS system that creates checksum of your VB files and alerts you if there're any changes.

Yes - I can do this It won't even cost much

[knucklenitz]

I hate to hjack this thread but Angel-Wings has got my attention.

I found that the person that attacked with SQL injection came from overseas, I am in the US. Since ALL of my traffic is actually on the west coast, I used htaccess to block all but US traffic. Appears to be working so far according to my logs.

On the SQL injection note, I restored my backup database so the hacked database is gone. I have contacted the programmed of the only two mods I have installed and he indicated they work on the admincp level so injection isn't possible. Since I'm a newbie in this area, I can't confirm. Is there any way to track database activity so I can find out how they got in?

It appears the last two actions (many other http/file.php attempts before that) were the hacker going to sendmessage.php and then 45 minutes later, them going to the index probably to check that their hack worked. I have since disabled the sendmessage.php in the contact vb options.

Thanks for any input.

[snakes1100]

If you would of done as i posted in your own thread, you wouldn't of needed to restore a backup.

1. You should of upgraded vb, hacks/addons, server backend and anything else outdated.
2. Sym linking your config.php isnt going top stop the hacker either.
3. Blocking foreign based ips isnt going to stop him either.

Seeing as you still present the injection hole for him to use, he will be back to visit you again.

[Angel-Wings]

Originally Posted by knucklenitz

I found that the person that attacked with SQL injection came from overseas, I am in the US. Since ALL of my traffic is actually on the west coast, I used htaccess to block all but US traffic. Appears to be working so far according to my logs.

And the logs just say the attacker isn't coming from US West coast ? Well, in a world of bot nets and open proxies it's maybe just a matter of time until the attacker found an IP that isn't blocked.
Maybe better spend your time fixing the holes - if I don't look the door and just paste a huge poster over it the door itself isn't more "secure" and this "door" is the problem, not how to hide it from someone.

Originally Posted by knucklenitz

On the SQL injection note, I restored my backup database so the hacked database is gone. I have contacted the programmed of the only two mods I have installed and he indicated they work on the admincp level so injection isn't possible. Since I'm a newbie in this area, I can't confirm. Is there any way to track database activity so I can find out how they got in?

You can enable the Query log in your Database but this might be a performance issue. Also protecting the Admin & Mod Panel with an Auth won't hurt - just ensure the login user and password aren't written somewhere at your board.

Originally Posted by knucklenitz

It appears the last two actions (many other http/file.php attempts before that) were the hacker going to sendmessage.php and then 45 minutes later, them going to the index probably to check that their hack worked. I have since disabled the sendmessage.php in the contact vb options.

Can also be the usual "background noise" like automatic IP scans for holes in the all-time-favorites like Joomla, phpMyAdmin, Horde and some older VB holes. Dunno how the attacking people(s) read their attack logs, maybe they just filtered for 200 replies and so wanted to see if they did any damage.
Right now, try to find out how it happened and fix the hole. Then things like IP Range blocking can be done anyways - first get the system clean and up-to-date - then additional enhancements can be done.

[knucklenitz]

Originally Posted by snakes1100

If you would of done as i posted in your own thread, you wouldn't of needed to restore a backup.

1. You should of upgraded vb, hacks/addons, server backend and anything else outdated.
2. Sym linking your config.php isnt going top stop the hacker either.
3. Blocking foreign based ips isnt going to stop him either.

Seeing as you still present the injection hole for him to use, he will be back to visit you again.

I spoke with the programmer of the two mods. He indicated these mods are not accessible from anywhere but the admincp. I am not a programmer so I can't confirm. The guy has a good reputation but who can you really trust.

I am at 3.8.3 [EDIT: Actually 3.8.2]. I am not sure that 3.8.4 has any security fixes in it. I'll double check. I believe my host has the server up to date. Again, I'll double check.

I can't see how just updating as you suggested would have removed the hack they injected without me restoring the backup (note that this was a database restore only, not entire system). No matter what I did, it showed a disturbing picture and hackers text. It seems that would be in the database no matter what updates were performed.

Originally Posted by Angel-Wings

And the logs just say the attacker isn't coming from US West coast ? Well, in a world of bot nets and open proxies it's maybe just a matter of time until the attacker found an IP that isn't blocked.
Maybe better spend your time fixing the holes - if I don't look the door and just paste a huge poster over it the door itself isn't more "secure" and this "door" is the problem, not how to hide it from someone.

I figured this wasn't a fix but a band-aid until I got the hole fixed. I also have some code in the htaccess to deny proxy and other items. Found it online and learning as I go, hope it works.

RewriteEngine on
RewriteCond %{HTTP:VIA}                 !^$ [OR]
RewriteCond %{HTTP:FORWARDED}           !^$ [OR]
RewriteCond %{HTTP:USERAGENT_VIA}       !^$ [OR]
RewriteCond %{HTTP:X_FORWARDED_FOR}     !^$ [OR]
RewriteCond %{HTTP:PROXY_CONNECTION}    !^$ [OR]
RewriteCond %{HTTP:XPROXY_CONNECTION}   !^$ [OR]
RewriteCond %{HTTP:HTTP_PC_REMOTE_ADDR} !^$ [OR]
RewriteCond %{HTTP:HTTP_CLIENT_IP}      !^$
RewriteRule ^(.*)$ - [F]

Originally Posted by Angel-Wings

You can enable the Query log in your Database but this might be a performance issue. Also protecting the Admin & Mod Panel with an Auth won't hurt - just ensure the login user and password aren't written somewhere at your board.

I have htaccess for admin and mod cp for that requires authentication.

Originally Posted by Angel-Wings

Can also be the usual "background noise" like automatic IP scans for holes in the all-time-favorites like Joomla, phpMyAdmin, Horde and some older VB holes. Dunno how the attacking people(s) read their attack logs, maybe they just filtered for 200 replies and so wanted to see if they did any damage.
Right now, try to find out how it happened and fix the hole. Then things like IP Range blocking can be done anyways - first get the system clean and up-to-date - then additional enhancements can be done.

I guess I am taking the right steps, just out of order. I'm still at a loss for figuring out how they 'injected' in the first place. Please forgive my ignorance. From what I've read, VBulletin is pretty secure against injection as long as there aren't any mods. Is this a fact? I am using the VB default style so it shouldn't be an issue there. How would I be able to tell if the two mods I have are not secure?

Thanks again for input.

[CarlitoBrigante]

We had about a dozen of cases in the past week from our clients of websites with vBulletin that were hacked. Anyhow, it turned out all of them had been hacked through a Wordpress installed on the server. Some of our clients had old WP installation they had forgotten about, others did not upgrade as they were recommend to, and script kids entered through WP, took the passwd file, and decrypted passwords, gaining FTP access.

There are many ways to prevent this; keep your system always updated; keep your applications always updated; and then do everything you can to secure your system. The best way to prevent attacks that write files to a directory to execute them is to have a system like SELinux in place, or GRSecurity. There are wonderful linux distributions that, for a few bucks per year, provide a secured kernel with many layers of protection applied - from modsecurity to granular permissions, and everything in between.

[snakes1100]

The reason i stated you didnt need to restore from a back up is that you could of just removed the code they injected, which was likely a base64 code into a template, most likely spacer_open.

As stated, you haven't plugged the hole and your not going to stop him from revisiting your forum doing a IP block or symlinking your config file.

Unless you know for sure that everything on your site/server is secure, your at risk

@Carlito, excellent point on the WP, thats why i told him everything needs to be upgraded.

[knucklenitz]

Originally Posted by snakes1100

The reason i stated you didnt need to restore from a back up is that you could of just removed the code they injected, which was likely a base64 code into a template, most likely spacer_open.

As stated, you haven't plugged the hole and your not going to stop him from revisiting your forum doing a IP block or symlinking your config file.

Unless you know for sure that everything on your site/server is secure, your at risk

@Carlito, excellent point on the WP, thats why i told him everything needs to be upgraded.

I see. I'm learning as I go here.

I just upgraded to 3.8.4. I'm not familiar with the coding of databases. Is it something I can check now to see if there is a hole and the 'base64 code into a template, most likely spacer_open' can be used again? How does one check for these vulnerabilities?

No Wordpress on my side but I did talk to my host and this being a shared server, I guess there is always a possiblity of someone hacking another database or application on the other virtuals and affecting my system?

[Angel-Wings]

Originally Posted by knucklenitz

No Wordpress on my side but I did talk to my host and this being a shared server, I guess there is always a possiblity of someone hacking another database or application on the other virtuals and affecting my system?

Well - if that's the case then it's the hoster's fault by not separating client websites enough - it's possible for one "hacked" website to access all other sites.
Really depends on how their machines are configured so blaming them might be too early - still yes, it's possible.
Hope you still have the logs saved - maybe they'll like to see them for analysis.

Oh - and you htaccess just blocks proxies that shout out to the world they are proxies. No "real" hacker would use such anyways.
Like said - really recommend mod_sec to block things you don't want - beginning with direct IP access and ending with filtering bad useragents or injection attacks.