Site keeps getting hacked and .htaccess changed - php

I have found that I have a similar attack to the one mentioned here
giant regex hack
The file keeps getting recreated and I cannot see from where its coming. How can I fix this? Anyone with a similar experience? I am running joomla 1.5.25
How can I trace the script that includes this file? How do I secure the site?

Its always recommended that you keep the permission of your .htaccess file as readable only.
chmod 0555 .htaccess
But regarding the hack being created again and again, there could be just numerous reasons. Like the host not properly configured, such that, on a shared hosting, a script running for a different domain can access scripts for your own domain.
Also check, what kind of files do you allow to upload, whether it's Admin or Frontend. Make sure, its not just any file upload is allowed. Executable files like PHP should not be allowed to be uploaded.

Yikes, that's not a good situation. I've seen it happen a few times and more often than not the solution was to recreate the website from a clean Joomla install, copy over the data and reinstall components.
However first check that the permissions are ok (no 666, 777, etc) and definitely check the VEL to see if any of your extensions have know vulnerabilities http://docs.joomla.org/Vulnerable_Extensions_List
You could also check on the Inj3ctor database http://www.1337day.com/ .
Most hacks like these happen via out of date extensions, open permissions, or as linuxeasy mentioned a poorly configured host.
Would highly recommend installing jhackguard or eyesite on the website. Eyesite will monitor your files and notify you when changes occur -http://extensions.lesarbresdesign.info/extensions/eyesite

Related

How to track the file that loads an specific line from a rendered HTML

I got a website in Wordpress and recently we discovered that it was infected by several malware scripts that insert scripts using the common base64 and eval functions like this:
We were able to solve most of the infected files but there are still some scripts being injected into the index.html, like these:
All these scripts marked in red make a requests to sites that immediately trigger my computer antivirus.
So question here is, how can I track which file loads these lines? How can I know which file prints them? I can't just search for the string since the code is encrypted like on the first image...
The truth is, it's probably going to be more than one file, and/or it's going to be something hidden deep in a plugin/upload folder.
This is going to be a bit time-consuming, but these are generally the steps I follow when fixing a hacked site to narrow things down and make sure I got all the crap out:
1) Before you do anything else, make sure you have a backup of both the files and db. That way, if you accidentally delete something, it's easy to restore.
2) Delete any unused themes or plugins, and make sure all existing plugins are up-to-date.
3) Update WordPress to the current version. Seriously. Keeping up-to-date is important. If you're more than two major releases behind, you'll want to update incrementally. (https://codex.wordpress.org/Upgrading_WordPress_-_Extended_Instructions)
4) After you've updated, connect via FTP and look for files older than when you updated. Look for extra files that shouldn't be there--this can be tricky, because hacked files are usually named things like wp-shortcode-s.php. I usually have a copy of WP core files open in a window beside my FTP client as a reference.
5) Check the first few lines of code on php and js files in your plugins folder for malicious code. Again, you might want to have a freshly downloaded copy of the plugin to compare files to.
6) Check the uploads folder and subfolders for malicious files.
I also keep checking my hacked site here to see how I'm doing:
http://isithacked.com/
And when you're finished, you might want to read up on how to harden WP to make it more difficult to hack.
Depending on the source of the malware, it's hard to give you a precise hint. There are a few more in-depth walk-through about the topic you can find on Google, here are some good examples which could help:
https://www.wordfence.com/docs/how-to-clean-a-hacked-wordpress-site-using-wordfence/
https://blog.sucuri.net/2011/02/cleaning-up-an-infected-web-site-part-i-wordpress-and-the-pharma-hack.html
Also if you are on a shared host, potentially the issue could be coming from an other compromised user. Hopefully you have a clean version of the site so that potentially moving to an other host (and upgrading) is an option.

Custom Permissions for a Specific PHP Script

I am developing a website which provides the option that clients can upload their PHP scripts to a specific directory on my server. I want to make sure that my system is secure, and thus I do not want people to be able to use those PHP scripts to edit or view files outside of the directory they are uploaded to. In other words, if there is a file at public_html/directory1/foo.php, it should only be able to edit and view files in public_html/directory1, and should not be able to edit or view files anywhere else on the system. Is there any way of doing this?
This is super dangerous. Technically there are ways to do this if you know your way around linux/windows user and group configuration, Apache configuration, and PHP configuration. You'll need to run Apache under a user with extremely specific permissions and configure PHP to forbid certain types of commands (most notably the exec/system commands, but there are a lot of other ones that are likely to get you in trouble).
I'd strongly suggest you try to figure out a way to avoid giving your users the right to upload files to a folder where they'll be evaluated by the server as PHP. There's just too many things that can go wrong, and too many settings that can be overlooked.
If you do decide to go this route, do a lot of reading on secure PHP configuration and Apache Privilege Separation.
Since PHP is a server side script, I belive you'll find it hard to properly secure your system. Having said that, you can limit those files by running the apache server by a user which have no access to other directories, check SElinux for more info. please note that it's really hard to do so, you might forget even one file which can be used later to hack the system.
A better way might be running these server on top of a VM, so that even if someone hijacks the VM, you could always shut it down and restore it's data.

CodeIgniter: Is it safe to delete index.html from all folders?

I'm new to CodeIgniter. I notice that all CodeIgniter folders (cache, config, controllers, core, errors, etc...) contains an index.html file that basically says "Directory access is forbidden". Correct me if I'm wrong, but I don't think it is possible to get to any of these folders from the web based on CodeIgniter's default configuration.
What is the purpose of these index.html files? Can I just delete them, or do I leave them alone?
Thanks much.
The purpose of them is to prevent the contents of the directory from displaying if directory listing is enabled on your server. Apache servers by default have directory listing enabled.
There are several instances where given the right circumstances you might be able to attempt to browse to a folder directly. These would mainly be caused by a server which is not configured properly, or an exploit. Therefore it is really best if you just leave the index.html files alone (they aren't hurting anything, and they don't take up that much space).
I'd even go as far as to suggest that you too add an index.html file to any and all folders which you create.
They are there for fail-safes, ie. if for some reason the directory structure would get to be publicly browsable.
I can't see any reason to remove them.
If your codeigniter installation (system and app folders) is outside of your public server directory, then they're not going to help with anything since they could never be served. In that case, it doesn't matter whether they exist or not, since you could never get to their directories anyway.
I say remove them for two reasons:
1) If Apache is configured to allow directory browsing, then it doesn't matter what your index.html says. So claiming that "Directory access if forbidden" when it's really not, amounts to security through obscurity, which is an undesirable security strategy.
2) I disagree with the idea that "if it's not hurting anything, just leave it alone". I've spent many an hour trying to figure out the purpose of a particular piece of code, only later to find out that it wasn't doing anything at all. Remove unused code. The inheritors of your projects will curse you less.
They are for your security, if someone tries to access your folder on the server by your domain URL (if your server is configured in a wrong way), it will prevent you from loading those files by triggering that HTML file
It would be safe for you to keep the file indeed.

Is it possible to create a self-installing PHP framework?

Ok this might seems a bad idea or an obvious one. But let's imagine a CMS like PHPBB. And let's imagine you'd build one. I'd create just 1 file called PHPBB.install.php and running it it will create all folders and files needed with PHP. I mean, the user run it just once and every file and folder of the app is created via the PHP file.
Why to do this?
Well mostly because it's cleaner and you are pretty much sure it creates everything as you wish (obliviously checking everything about the server first). Also, having all the files backed-up inside a file you would be able to restore it very easily by deleting everything and reinstalling it running again PHPBB.install.php. Backing-up files like this will allow you to also prevent errors: How? When an error occurred in a file, this file is restored as it was and automatically re-run.
It would be too heavy!
The installation would happen only once and you'd be sure the user will not forget to place the files correctly. The error-preventing will worth the cause and it would also happen only once.
Now the questions:
Does this technique exists? If so, What's its name?
Why would you discourage it?
As others have said, an installer.
It requires the web server to have permission to write to the filesystem, and ends up having the files owned by the user the web server runs as. Even when one has the ability to change filesystem permissions, it's usually a longer process than just extracting an archive and having the initial setup verify permissions.
Does this technique exists? If so, What's its name?
I'd advise to read about __halt_compiler(). It allows you to mix PHP code with non-php data which is not parsed, so you may have PHP code ("installer") and binary data (e.g., compressed contents of all the files) in single PHP file.
1 - Yes, there is a single install file in PHPBB. You run through an online wizard defining your settings and then it installs automatically.
http://www.phpbb.com/support/documents.php?mode=install&version=3&sid=908f5766fc04868ccb985c1b1e6dee4b#quickinstall
2 - The only reason to discourage it would be if you want the user to understand exactly how the system works. Automatically installing it means the user has no need to understand the nitty gritty of it all - of course, many see this as a good thing.

My -tpl file won't update!

I am running the site at www.euroworker.no, it's a linux server and the site has a backend editor. It's a smarty/php site, and when I try to update a few of the .tpl's (two or three) they don't update. I have tried uploading through FTP and that doesn't work either.
It runs on the livecart system.
any ideas?
Thanks!
Most likely, Smarty is fetching the template from the cache and not rebuilding it. If it's a one-time thing, just empty the cache directory or directories (templates_c). If it happens more often, you may have to adjust smarty's caching behaviour in the configuration (among others, $smarty->cachingand $smarty->cache_lifetime)
Are you saying that when you attempt to upload a new version it isn't updating the file? Or it's updating the file but the browser output does not conform to the new standards?
If it's the latter problem, delete all the files in your template_c directory. If it's the former problem, er, might want to check out ServerFault or SuperUser.

Categories