Forum hacked, restored, now showing bare index

[squidsk]

Originally Posted by loua_oz

Just remembered. In

./includes/config.php

there is hardcoded database name and password, in plain sight, unencripted

// ****** MASTER DATABASE USERNAME & PASSWORD ******
// This is the username and password you use to access MySQL.
// These must be obtained through your webhost.
$config['MasterServer']['username'] = 'dbname_admin';
$config['MasterServer']['password'] = 'unencripted_password';

Is that how it should be? Never seen that in my life.

That's normal because you should have an .htaccess or equivalent that denies access to files within the includes directory. Where else would you store it? You can't store it in the db because you need the db username and password to access the db.

[loua_oz]

Originally Posted by alcazarx

As for the DB, you have to check it manually if its ok (or send it to an expert here), the "repair" functions that the DB or Hostings offer are to fix damaged tables or db's, not to removed unwanted elements.

What experts? Those telling me that plain password in ascii file is normal?
And what after "experts" have checked the db? A hacker capable of getting into my site would just have to go and copy/paste DB admin user name and password offered on a plate.

For decades Unix has /etc/passwd and /etc/shadow files where encrypted passwords are stored.

[ozzy47]

That is why you should protect files via .htaccess

[loua_oz]

.htaccess does not come with vanilla install.

People off the street would not know what it is but would know that plain text passwords are bad idea.

Ridiculous: it is like saying that your house will be broken into one way or another if someone really wants to do that so no need to lock it up.

[ozzy47]

The same could be said for people having to be told to put locks on their houses. Bottom line is do your research.

But I seriously doubt that is why you have been hacked so many times. If that was the case, this site, van.com as well as millions of other site would be hit as often as yours, if not on a daily basis.

[loua_oz]

There are 100s of VB sites hacked daily, the most hacked product in board software history is exactly VB 4. My hosting provider could be targeted and vulnerable, I came just a s a run off the mill together with other sites. Once there, they have plain text DB admin user and password.

What research should I do and why? I bought a product that should work like a fridge, without researching anything about it.

Oponents of VB would have a field day reading what "experts" here are advocating.

[TheLastSuperman]

Originally Posted by loua_oz

Oponents of VB would have a field day reading what "experts" here are advocating.

Which is nothing. We're simply trying to steer you in the right direction i.e. cleanup so your site is back to normal.

Go ahead, visit your site and type in the path to the config file, lets use vbulletin.org as an example: https://vborg.vbsupport.ru/includes/config.php

Even if there was no .htaccess protection, based on how the site serves content you could not download the file as it sits on the server, only save a copy of the file after its rendered therefor you cannot know the files content (original contents i.e. code only what is parsed afterwards).

Another example from http://www.thebiggestboards.com/vbulletin-forums.php would be ConceptArt.org so go ahead, visit this url then download the config.php file or however you would go about it... now tell us all the database username and password - I'll be waiting.

Long story short, I would be waiting a very long time. You seem to know a little based on what you've spent time researching but clearly do not know what you're talking about no offense intended just simple fact - I applaud your effort don't get me wrong, I wish half those I dealt with would take the time to do the research you did and I can explain all this to you above ^ but I can't understand it for you. I need you to take more time and do more research before speaking like you did above, I tell you this because I would want someone to tell me if a booger was hanging out my nose instead of letting me walk into a crowded room and speak highly about a subject while not knowing how I looked to others.

Remember if you need clarification on something just ask but being sore over a hacked site because you feel something is wrong with the software when you do not understand it, is not the way to go about things.

Edit: I assume you've already added a new user to the database with all privileges then removed the old user and updated the config.php file? If not please do so, the hacker more than likely knows your database details now since he hacked you - if you left these the same after the first time you were hacked then its no surprise he/she hacked you again.

[RichieBoy67]

It doesn't work that way. A website is not a "Fridge". It requires updates and care and maintenance.

I would be willing to bet that you really only got hacked once from failure to do a patch or something like that and you just never fixed it correctly. Now they can come and go as they wish.

I have had vbulletin sites for years and only got hacked once many, many years ago when I did not know what I was doing. Keep up to date, be careful with your plug ins and file permissions and take some precautions and you will be less likely to get hacked.

--------------- Added 09 Sep 2015 at 23:33 ---------------

I would be interested in knowing what version got hacked originally.

--------------- Added 09 Sep 2015 at 23:35 ---------------

Also, what are you talking about "plain test passwords"? Passwords are not stored anywhere as text.##OK, I see you are talking about the file system. Every script I have used, wordpress, joomla and countless others have a config file with this information. That file should never be seen by anyone unless using ftp and if a hacker already is that far than you have already been hacked.

--------------- Added 09 Sep 2015 at 23:36 ---------------

Originally Posted by loua_oz

Thank you,
The hacked directory (root and subdirectories) were saved by the provider as soon as I requested them to down the site (it was displaying hackers' message and I could not get into admin to shut it down).

Just went in and chmod to 000 what they saved, thanks for that. Poking around the site there is nothing visibly wrong.

If a file or directory are touched, it shows the timestamp that sticks out when the directories are listed.
Several times I saw things like "maill.php" that was inserted without harming the site contents.

Indeed, as I am on the shared server, could be 100s of sites hosted on one physical machine.
However disciplined I might be, a slacky site owner on the server may invite a trouble for all ?

Is there some tool to check the database? The cPanel provided by webhostinghub.com has "database repair" and it ran cleanly.

--------------- Added 09 Sep 2015 at 01:16 ---------------

Just remembered. In

./includes/config.php

there is hardcoded database name and password, in plain sight, unencripted

// ****** MASTER DATABASE USERNAME & PASSWORD ******
// This is the username and password you use to access MySQL.
// These must be obtained through your webhost.
$config['MasterServer']['username'] = 'dbname_admin';
$config['MasterServer']['password'] = 'unencripted_password';

Is that how it should be? Never seen that in my life.

Nobody should ever be able to see that if your file permissions are correct. If you can see that in plain site you have a problem with your file permissions. Most files should be at 644.

[cellarius]

This debate is ridicoulous. Every webscript I have ever used has database credentials in plain text in a config file. There's just no other way to do it, since the script has to be able to access this information. Of course you could encrypt it, but since the script needs to be able to decrypt it again to use it, you'd have to store the key somewhere. As others have pointed out, the config file can't be accessed from the outside. If an attacker has access to your ftp or shell, it's really too late.

[loua_oz]

My site is back to normal, has been since first 3-4 posts here and without anyone's help.
- File permissions are 644, directories 755.
- Originally it was 4.1 hacked in 2010. That was before warning "remove install directory" was issued, even specialist installation by VB staff left it onsite. Site re-provisioned.
- Months of experimenting with the site, Mods, plugins, messing...wiped the site and got another specialist installation (May 2011, Jake Bunce did it).
- over years, 6 times found (using Maintenance - Diagnostics) .php files that are not part of VB, a glance through and they seemed to be spam mailers.
- 2 times webhostinghub.com located and quarantined spam mailers (since they upgraded their software 3 months ago)
- 1 time found (last week) a file "class.php" in the includes directory
- on Monday the site was hacked and taken down

Keep on changing passwords into 40 characters long, spaces, mixed letters.

Daily run of Diagnostics. Daily backups.

--------------- Added [DATE]1441871454[/DATE] at [TIME]1441871454[/TIME] ---------------

Originally Posted by cellarius

This debate is ridicoulous. Every webscript I have ever used has database credentials in plain text in a config file. There's just no other way to do it, since the script has to be able to access this information. Of course you could encrypt it, but since the script needs to be able to decrypt it again to use it, you'd have to store the key somewhere. As others have pointed out, the config file can't be accessed from the outside. If an attacker has access to your ftp or shell, it's really too late.

Let's see why this debate is ridiculous: because coders and VB staff participating here have not told us (may well be news to them) that plain text database admin user name and password in

/includes/config.php

are used when initially creating the database from the sheet supplied for paid install or from own notes. Some may stay with that password, most would change it.

Just changed my cPanel, mail and database passwords and in

/includes/config.php

the password is the same as it was upon creation, should not be valid. But the site does not care.

That is another question: why is it then in /includes, why not in /install and removed before the site is powered up?