What is the location of md5_sums_vbulletin.php and what should the permissions be?

[jdj]

I'm running the suspect file versions tool in maintenance, diagnostics. I'm getting the following message:

Checksum file md5_sums_vbulletin.php is currently writable. Please ensure that this file is not writable by the webserver.

What is the location of the file md5_sums_vbulletin.php and what should the permissions be for this file?

[Craig]

/core/includes/md5_sums_vbulletin.php file so that it can't be written to by the web server. Usually something like chmod 444.

[In Omnibus]

/core/includes/md5_sums_vbulletin.php file so that it can't be written to by the web server. Usually something like chmod 444.

The permissions should be 0644. The server has to be able to read the file and write to it during upgrades.

[Wayne Luke]

The permissions should be 0644. The server has to be able to read the file and write to it during upgrades.

No... The web server shouldn't be able to write to this file. CHMOD 0444 is the best option for this file. Or the web server shouldn't be the owner. Using 0644 will continue to display the warning if the web server owns the file.

For the best security, the web server shouldn't be able to write to this file. Ideally, the web server shouldn't be able to write to any vBulletin files. You should use a different user that has write permissions to update the files on upgrades. We use 0444 on vBulletin Cloud. Apache cannot write to any vBulletin files under any circumstance.

[In Omnibus]

No... The web server shouldn't be able to write to this file. CHMOD 0444 is the best option for this file. Or the web server shouldn't be the owner. Using 0644 will continue to display the warning if the web server owns the file.

For the best security, the web server shouldn't be able to write to this file. Ideally, the web server shouldn't be able to write to any vBulletin files. You should use a different user that has write permissions to update the files on upgrades. We use 0444 on vBulletin Cloud. Apache cannot write to any vBulletin files under any circumstance.

The first permission is the Owner so, not to argue with you but you're saying the default owner permission on this file should be no permission? Because on a clean installation this morning the permissions are 0644. Did you set the permissions for this file yourself or did it ship with the wrong permissions? Or is my web server changing permissions on folders and / or files?

[Wayne Luke]

Files don't ship with permissions. Permissions are added when they are created or copied onto a drive. Most servers will set the default permissions to 0644. These should be considered insecure if the files are owned by the web server user.

If the web server user is the owner, they should be manually changed to 0444 to prevent writing to the file in order to preserve its integrity. When you allow the web server to write files to the server, you cannot guarantee the file is unaltered. So if someone gains access through the webserver and adds their own custom files, they can also overwrite this file to make sure their new files look like they are part of vBulletin.

[jdj]

I upgraded to 5.6.1PL1, ran the suspect file diagnostic tool and cleared out all the files vbulletin said it didn't recognise. A lot of the files that were not recognised as part of vbulletin were index.php files.


I now have a great long list of directories where I have the same message - index.html file not found.

Presumably I get rid of all those index.php files again, but what am I supposed to do about the "index.html - file not found" error messages. My scan is copied and pasted below.

./core
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 62 files ./core/admincp
index.php	File does not contain expected contents
Scanned 18 files ./core/clientscript
index.html	File not found
index.php	File not recognized as part of vBulletin
./core/cpstyles
index.html	File not found
Scanned 2 files ./core/customavatars
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 8 files ./core/modcp
index.php	File does not contain expected contents
Scanned 1 files ./core/packages
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 2 files ./core/store_sitemap
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 42 files ./core/vb
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 60 files ./core/vb/api
notification.php	File does not contain expected contents
Scanned 2 files ./core/vb5
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 2 files ./fonts
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 3 files ./fonts/alice
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 6 files ./fonts/arvo
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 3 files ./fonts/capriola
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 9 files ./fonts/dosis
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 12 files ./fonts/hind
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 12 files ./fonts/lato
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 8 files ./fonts/nunito
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 5 files ./fonts/oswald
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 8 files ./fonts/playfairdisplay
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 11 files ./fonts/raleway
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 14 files ./fonts/robotocondensed
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 6 files ./fonts/robotoslab
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 3 files ./fonts/stintultraexpanded
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 10 files ./fonts/ubuntu
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 97 files ./js
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 4 files ./js/blueimp
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 6 files ./js/ckeditor
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 1 files ./js/colorpicker
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 8 files ./js/flatpickr
index.html	File not found
index.php	File not recognized as part of vBulletin
Scanned 32 files ./js/jquery
index.html	File not found
index.php

[Wayne Luke]

All of those index.php files that are listed as "Not Part of vBulletin" or "Does not contain expected contents" are exploit files from the patch that should have been applied last year. If you go into those directories, you'll find that index.html has been renamed something like index.html.bak. There are probably .htaccess files in these directories that should be deleted as well.

The index.html file really isn't needed. It can be deleted without a detriment to the software. It is only in those directories because some people don't turn off directory listing in their web server and a list of files is considered a security risk. So we put a blank file named index.html and the server provides that instead of a directory listing. After you delete all the extraneous PHP files on your server, you can add the index.html files back in if you wish simply by uploading them from your vBulletin package.

Personally, I would delete everything but the attachment and /core/customavatar directories if you store those in the file system. These should be reviewed manually. Neither directory should contain a single .php file. You may keep keep the /core/includes/config.php as reference but it could be exploited as well so you'll want to replace it with a new copy. Make sure to delete all .htaccess files as well. Once done, upload a clean set of vBulletin 5.6.1 PL1 files and run upgrade.php. If you have other software or directories outside of vBulletin, you will want to inspect those directories for stray and unknown files as well or the worm will continue living on your site.

I am pretty sure that I cleaned your vBulletin directory last year but I guess the worm is in some other directory on the server and was missed.

[jdj]

I am pretty sure that I cleaned your vBulletin directory last year but I guess the worm is in some other directory on the server and was missed.

The only other directories on there are there to display banner ads.

If you had to put a directory on the site for banner ads which would be scanned by the software, where would be the best place to put it?

[Wayne Luke]

The software won't scan directories that it isn't programmed to scan.

When you click the download button in the member's area, the server creates a unique download for your license. At the same time, it creates an MD5 hash of every file in that package and writes them to the md5_sums_vbulletin.php file. It will then ZIP the entire package and present it to you for saving on your computer. This happens for every single download. My files are actually different than your files.

For custom files, I recommend following vBulletin's directory structure. Just create your own custom sub-directory. So for the images used in ad banners, I would store them in /images/ads or /images/custom. For Javascript, I would store the files in /js/ads or /js/custom. PHP Code should be bundled into "Packages" and stored in the /core/packages directory using their own unique package name. There is an example package included in the /do_not_upload/development directory.

You can also create your own md5_sums_XXXX file to check your custom directories. The tool to do this is in the /do_not_upload/checksum directory. When you run vB5Checksum.phar from the command line it will provide instructions on how to use it. The command to run it would be php vB5Checksum.phar

Here are the instructions:

This script generates the checksum manifest (md5_sums_<product>.php)
based on the provided configuration file. The generated manifest will
be written to the core/includes directory by default.

Usage: php vB5Checksum.phar --config <file> [--out <file>] [options]
   php vB5Checksum.phar --config sample_checksum_config.php
   php vB5Checksum.phar --config sample_checksum_config.php --verbose

Required:
 --config <file>    Use this config file. See the provided
                    sample_checksum_config.php for more info.

Optional:
 --out    <file>    This script will write the manifest to this file
                    instead of the default location at
                    <forumroot>/core/includes/md5_sums_<productid>.php
                    (where <forumroot> and <productid> are from the
                    config file).
                    If an existing directory is specified instead of a
                    file path, a md5_sums_<productid>.php file will be
                    written in that directory.

 --verbose          Output additional info during the process like which
                    directory is being processed.
                    Useful for debugging if the script fails to generate
                                        the manifest properly.

 --validate         Exit after validating config file, do not generate
                                        checksum manifest.

 --help             Display this help and exit.

If you do not create Checksum files for your custom files, then vBulletin will output something like "This directory is not part of vBulletin and should be reviewed manually." I don't know the exact wording offhand.

[Wayne Luke]

As an example of a configuration file for the Checksum tool, I have attached one that I created to created a file for cached templates and CSS on my own test server. I have a batch file that runs the upgrade script and then generates the checksum file(s) for my test installations every time I upgrade vBulletin. That can be multiple times every week depending on what I am doing.

[jdj]

For custom files, I recommend following vBulletin's directory structure. Just create your own custom sub-directory. .

So if you are storing attachments in the directory structure rather than the database, where would you recommend putting the custom sub-directory for the attachments directory?

And where would you recommend putting the custom sub-directory for the site map?

[Wayne Luke]

For the best security, attachments should be stored outside the webroot directory.

./public_html
./vb_attachments

Most people can't deal with the security permissions and their hosting providers won't assist them so, the general recommendation is to just create it within the vBulletin directory and CHMOD 0777.

./public_html/attachments

Custom Avatars should be in /core/customavatars otherwise they don't work in the AdminCP properly due to its legacy code.

The site map will automatically be stored in /core/store_sitemap. There is no benefit to changing this location.

[jdj]

For the best security, attachments should be stored outside the webroot directory.

./public_html
./vb_attachments

Most people can't deal with the security permissions and their hosting providers won't assist them so, the general recommendation is to just create it within the vBulletin directory and CHMOD 0777.

./public_html/attachments

I had a trawl through the attachments directory and found a number of gibberish files with the *.php file extension plus a couple of files called index.php, all of which I removed. It's a long job going through the attachments directory.

If most people are faced with having to store their attachments in something like /public_html/attachments which is what I do then I would have thought that much as the sitemap is stored in a default directory then it would be better if the attachments are stored in a default directory and scanned for files with unusual file extensions. Most of the files that I can see in there say *.attach, *.thumb or *.small and a couple say *.icon. The suspect file tool is more useful that it was but if it also scanned a default attachment directory and flagged up files with unexpected extensions that would be more useful.

[Wayne Luke]

I had a trawl through the attachments directory and found a number of gibberish files with the *.php file extension plus a couple of files called index.php, all of which I removed. It's a long job going through the attachments directory.

If most people are faced with having to store their attachments in something like /public_html/attachments which is what I do then I would have thought that much as the sitemap is stored in a default directory then it would be better if the attachments are stored in a default directory and scanned for files with unusual file extensions. Most of the files that I can see in there say *.attach, *.thumb or *.small and a couple say *.icon. The suspect file tool is more useful that it was but if it also scanned a default attachment directory and flagged up files with unexpected extensions that would be more useful.

I am sorry, I didn't see this sooner. It can be a lot of work to clean out the attachment directory. Checking from the command line and simply deleting all *.php files would be easier but not everyone has access to the command line. I suggest that you copy the .htaccess file provided in /core/customavatars into your attachment directory or place the attachment directory outside the web root (i.e. outside public_html).