Hardening OpenX
There are times when your website or application might get hacked. The usual reasons include weak passwords, outdated software or poor code (especially on validating user input). The same apply to OpenX – your ad server can be hacked due to an outdated version of OpenX, weak passwords, insecure server settings or a combinations of the above. Most common hacks add an iframe or script to the banner page distributing malware (a virus, trojan horse, or similar). This can get your website (the one that uses your infected openx server) to be blocked on all major browsers and most of the search engines.
To decrease the chances of having your openx hijacked, it’s recommended to follow these quick and easy steps. You’ll notice that some of them apply to any web application, like using strong passwords (at least 6 chars, using both uppercase and lowercase letters, digits and special chars).
Things to do with your OpenX installation
1. Always update the application and plugins to the latest versions. This ensures your ad server has the latest patches and security fixes, but it also makes hacking a bit more difficult. You can check if you have the latest version by going to Configuration / Product Updates in the OpenX administration interface.
2. If your administrator username is admin or administrator (or anything similar), change it to something less common, like your first name or last name. This cannot be done from the openx admin interface, but it can be done directly in mysql (using phpmyadmin for instance) – the table you are looking for is [table_prefix]_users
3. If there are other users who manage the inventory, create separate accounts for them and make them advertisers, not admins. Keep the admin account safe and do not share it with anyone.
4. If you only server banners on your website(s), you can remove all users from Advertisers and Websites. As a general rule, when you create a new advertiser, do not also create a username. If you don’t offer OpenX access to advertisers, there’s really no point in adding new users.
5. Always use the logout link to log out, instead of just closing the tab or window. This prevents session hijacking or keeping an active session on a public computer.
6. Disable all plugins that you don’t use
Things to do on the server side
1. Setup the openx database with its own username and use a really strong password. Make sure the user is only allowed to connect from the server that runs openx (where your web server is located) – this is usually the same machine, so localhost will be just fine. The password should be really strong. You can use an online password generator tool, like this one: http://www.pctools.com/guides/password/
2. Add an extra layer of authentication, using http basic auth for example. Follow the instruction in the links below:
http://httpd.apache.org/docs/2.0/howto/auth.html
http://httpd.apache.org/docs/2.0/programs/htpasswd.html
3. Change the database structure of the banner’s table so it doesn’t allow append & prepend codes anymore. You can do this by changing the two fields in the banners table ([table_prefix]_banners) from varchar(255) to varchar(0) (through phpmyadmin or the cli):
alter table openx_banners change append append varchar(0);
alter table openx_banners change prepend prepend varchar(0);
3a. Change the database structure of the zone’s table so it doesn’t allow append & prepend codes anymore – thanks Stefan for suggesting this.
alter table openx_zones change append append varchar(0);
alter table openx_zones change prepend prepend varchar(0);
Make sure to replace “openx” with the table prefix you use.
4. Set the proper permissions to all files & folders – all files should not be writable by the server by default, except the var/, plugins/ and www/images/ folders.
Your configuration file, located in var/, should not be writable:
chmod 0444 [domain].conf.php
5. Remove all installation files
What if I am already infected?
It’s important to find out all infected files or database entries and then figure out how they got there. Do not remove anything befire understanding how you got infected in the first place. You can disable the openx server temporarily (by adding this line in an .htaccess file in the folder www/delivery: deny from all).
Once you know where the security breach is, fix it, harden the server, change passwords (just to be sure), clean up the infected data and remove the deny all line from the .htaccess file.
We can also help you cleaning, securing and upgrading your openx installation(s) – contact us.
@Cristi
Thanks for the advice, I’ll try what you suggested. I’ll let you know how it turns out.
yes, the varchar(0) solution is just a temporary patch that you’d have to hope it lasts. the cron that alters the tables will do the trick, but as you said, it’s just another workaround. now that I think of it, I believe the best solution would be to alter it to varchar(0) again, then lower the privileges on the mysql user – you would only grant select, insert, delete, update (maybe replace), but no drop, create and alter. then, whenever you need to upgrade, grant all privileges, upgrade, test, and lower the privileges again.
also, remember, the problem is not with the varchar(0) “fix”, but with the mysql injection problem within openx – i’m psyched to see that such a mature application, with so many downloads, still has such security breaches.
@erik – “deny from all” will affect your ad serving as it will deny access to everything, no only php scripts. see http://httpd.apache.org/docs/current/mod/mod_access_compat.html directive, but there are a lot of other options too – here are a few suggestions:
basically, all requests to images (or other media) will be denied. if you wish to only disallow php scripts, try using the
http://stackoverflow.com/questions/2618908/how-to-prevent-a-specific-directory-from-running-php-html-and-javascript-langu
http://www.wpbeginner.com/wp-tutorials/how-to-disable-php-execution-in-certain-wordpress-directories/
http://stackoverflow.com/questions/1271899/disable-php-in-directory-including-all-sub-directories-with-htaccess
I think that another thing you should add to this is that no php code should be able to execute in the images directory. Add this to your apache vhost file:
# make sure no php files can be delivered from images/ folder
Deny from all
Order deny,allow
It will not affect your OpenX but it will make it impossible for an attacker to upload something nasty in your images directory. We have seen web shells and spambots uploaded to the images directory.
just an fyi, the solution of setting the varchar to 0 worked for a few months, but then today we suddenly got hit with another attack. The attackers somehow re-injected their malicious code into the append and prepend fields, so the varchar(0) solution isn’t exactly permanent. I’ve set up a script that periodically executes every minute and sets the varchar back to 0 and clears all the prepend and append fields in banners and zones, but this still doesn’t actually prevent injection, it simply removes it within 60 seconds of being injected… If anyone has a solution for totally preventing this type of attack from happening again (and not just having a script to undo the damage every 60 seconds) please let me know!
That’s a good comment, thank you. Most of the time, security involves additional steps that might seem like they don’t have anything to do with security at all. Take the following trivial example, involving a car. Beside installing a good alarm system on your car, it’s usually considered good practice not to let expensive stuff in the car, like phones, gadgets, money, jewelry. Same with (web) apps. Sure, the varchar(0) workaround could overwritten, but combined with the rest of the items in this article, it will definitely boost the overall security. On top of that, most attacks don’t really run sql queries, cause in that case the attacker could even drop the entire database and then everything in here wouldn’t make sense at all. Instead, most attacks rely on improper user data handling (by the app itself) or brute force attacks (on the admin area or on the server account – ftp, ssh). That’s why I recommend updating to the latest version of openx as soon as possible, and also add another layer of security, like basic auth. If they hack your ftp or ssh account, well, there isn’t much you can do but clean everything up and next time set a better password (or a tighter auth system).
Hi,
I’m being affected by the “append” code attack.
I think that if the hacker is able to execute an “update” query on the append and prepend fields of the banners and zones tables, he is also able to alter and delete all of the database content.
So, I don’t think that altering the above database fields to varchar(0) could be considered a security solution: it looks like trying to solve the problem by putting the head under the ground… What do you think?
This is very useful information. Thank you for writing this article. This information helped me secure my organization’s OpenX server which had been subject to constant code injection attacks. Setting the character limit to 0 on the append and prepend fields in the zones and banners table is a great idea. I wish I would have thought of that sooner! I was about to write a script to clear these fields every 60 seconds, but your solution is far more elegant and effective!
Thanks again for this great article and good luck to you in your endeavors!
you’re right, usually the user for mysql has full privileges, so the table structure could be changed. changes are low, for various reasons (especially because of the table prefix), but it’s possible. however, i wouldn’t run such a script every minute, i think 10-15 minutes (maybe even 30) should be fine. plus, i would do describe first and see if the column has been changed. but nevertheless you make a good point, thanks for sharing the knowledge.
Since i’m not sure that the several vulnerabilities can’t alter the table on their own, I would do a script like this and put in crontab to be run each minute:
//openx runs with all grants, if the script can make an update it can also alter a table
$DBS = Array(“ox_ads”);
foreach($DBS AS $db){
$queries = Array();
$queries[] = “ALTER TABLE `ox_zones` CHANGE `prepend` `prepend` VARCHAR( 0 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL;”;
$queries[] = “ALTER TABLE `ox_zones` CHANGE `append` `append` VARCHAR( 0 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL;”;
$queries[] = “ALTER TABLE `ox_banners` CHANGE `append` `append` VARCHAR( 0 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL;”;
$queries[] = “ALTER TABLE `ox_banners` CHANGE `prepend` `prepend` VARCHAR( 0 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL;”;
$mysql_link = mysql_connect(“localhost”, “user”, “pass”);
mysql_select_db ($db) or die(mysql_error());
foreach($queries AS $qu){
$q = mysql_query($qu) or die(mysql_error());
}
}
Thanks Stefan, will add them to the list. I haven’t had problems with the zones yet, but I don’t think they are any different than the banners, so your suggestions are a must.
Great suggestions. I would add altering openx_zones to #3 in the server side list:
alter table openx_zones change append append varchar(0);
alter table openx_zones change prepend prepend varchar(0);
I’ve had problems with the zones table as well as the banners table.