I have an old joomla installation which was hacked. All I know for now only index.php was changed and they messed with my user accounts. I downloaded index.php from the current version but at one point it calls $app->dispatch(); which requires a component name parameter in my version. Does anyone know what parameter this should be? I tried: null, 'home', 'application',...
Also I'm planning on updating to the newest version later, however I can't seem to find my current version number. I found somewhere that it is displayed in the admin pages but I can't access them yet. Can I find it in the code files somewhere?
EDIT: The index.php from version 1.5.22 worked. Apparently the correct version was 1.5.3. Does anyone know what else I should check that might have been hacked/messed with?
Why not get a copy of the version you used?
http://forum.joomla.org/viewtopic.php?p=2221953
You can go to the joomla project on
joomlacode.org, then select the search
tab. From there you type in "1.0.10"
and select Releases to search in. You
should get some results. Click on the
one you are searching for, the files
can be found on the files tab, this
time the tab is on a blue bar (more to
the bottom of the screen).
Although I'd recommend upgrading completely, to stop being re-hacked again.
====== Answer to second question
How big is the site? Usually if it's just a link spamming attack a quick once over will suffice.
The next issue is that you need to patch the hole that caused the problem, in this case upgrading to the latest Joomla (1.6 - I believe) is the first port of call.
Have you modifed the Joomla system in such a way that the hack could have been opened up by you?
My advice, reset the admin passwords and upgrade Joomla.
Very difficult to say anything else without seeing what the "hack" was.
I had to clean out a hacked Joomla install recently. My tip is to grep all the files base64_decode: some hacks consist of decoding a huge string that emits php.
find ./ | xargs grep base64_decode
The hack looked like this: error_reporting(0);eval(base64_decode('JGxMOXdGMWFZNHpY.....
This particular piece of code detected googlebot and other crawlers, and then emitted a list of spam links heavy on viagra. If a normal user agent string was used it showed a normal site. I had to use a firefox extension that changes the user agent to debug this.
The next step would be getting rid of the exploit and then either patching Joomla and waiting for the next exploit or switching to something more secure, like static html or a well-maintained CMS.
Fortunately Joomla has really nice documentation on how to recover from a hack. http://docs.joomla.org/Security_Checklist_7. As Pino mentioned, it is critical that you are always on the latest version to minimize your exposure to security exploits.
Related
I've had this working in the past (earlier version of Joomla), but must have changed something and I can't get it work (even in a brand new site). I'm using Joomla 3.4.8, the newest version of JCE, and DirectPhp.
I have Global Configuration > Text Filter Settings > Super Users set to No Filtering, and have adjusted JCE Administration > Editor Profiles > Default > Editor Parameters > Advanced > Allow PHP to yes.
Yet, when I save a any article with Php code I get a 403 error. Without the php code it saves correctly.
Does anybody have any hints?
Many of our clients are facing the same problem. It turned out it is related to their host forcing browser caching on non-static content. Please follow the guide here ( http://www.itoctopus.com/how-to-disable-browser-caching-in-joomla-backend ) and add the appropriate code to the .htaccess file to prevent browser caching. Please post back here if it fixes your problem or not.
One way around this that I worked out was to edit the php code in PHPmyAdmin directly.
It seems that mod_security on your apache server is causing the error to be forced when either your code is bad or is restricted. (this is not a bad thing as it stops hacking attempts on your site really.)
Going through phpMyAdmin requires a bit more skill but works all the same.
Anyway that is what I do now when I encounter this issue. (the hard part is finding what is causing the error in the first place)
Probably mod_security is set to block PHP injection attacks, and it sees that as one. The way to tell is check the apache error log and the mod security audit log. Then, if you have access to the config files, you can configure an exception based around either that url or that variable to whitelist it from PHP injection checks.
WARNING: If you do that, be sure the code handling that form will be able to defend itself from injections, because you just stopped apache from defending it.
But the best solution for this is to write a plugin you can invoke from the content item, rather than inject all that code into your content. Makes it easier to maintain -- changes are localized instead of scattered across lots of database records. Change the plugin once and every page that needs it gets the change, instead of having to touch each and every item in the db to make that same change.
PS: There's a Joomla Stack Exchange. Check the list (top right, at time of writing).
My website has been hacked again. There are many foreign url such as here.
I've checked the database and there is nothing strange in my database. Does anyone know what kind of hacked attack like this?
Then I have to execute all files with exit (); and I quit "on /libraries/import.legacy.php".
If I give exit () under
JLoader :: register ('JRoute', JPATH_PLATFORM. '/joomla/application/route.php');
The result my website is still able to walk with the strange link.
but if I give exit() in the above
JLoader :: register ('JRoute', JPATH_PLATFORM. '/joomla/application/route.php')
The result is the website stops.
Are you running the newest version of Joomla? It's very important to keep a CMS updated as security issues are regularly discovered and patched. The same applies for all the extra plugins you're using.
Note that once your file system has been breached, it's very hard to make sure nothing else has been modified. You might think everything is clean, but you surely could have missed things. Often a clean install is the best option.
I'd suggest to find someone with experience in website security to find out what kind of attack is being used and how they have been using it. We don't have enough information to find out the problem for you.
I am in the process of migrating an existing Drupal website from another provider to Bluehost.com -- while I think using Bluehost.com is not relevant in this context I thought I'd mention it anyway, in case there are indeed some particularities I'm not aware of.
The site is a Drupal 6 installation and it did work previously I am told on bluehost too so you think it shouldn't be any problems, however, having copied it over I encounter a big problem: all the responses from Drupal are sent with Content-Encoding set to application/x-gzip. This has the implication of all browser presenting a download dialog box rather than rendering the content.
I have actually curl'd the index page and ran it through gunzip and the output is the correct HTML for the site -- just that it somehow ends up being gzip'd and this mangles the content type and confuses the browsers.
Talking to previous maintainers of the site they suggested using PHP 5.4 (they were running it on php 5.5 as I understand and despite all the Drupal suggestions it was running perfectly well I'm told).
I am trying to eliminate now any type of gzip'ing that occurs here so I've got it down to a few layers which could cause it but eliminating those it still doesn't work:
SetEnv no-gzip 1 in .htaccess
zlib.output_compression = Off in php.ini
drupal had the boost module installed and some corresponding settings in .htaccess -- i've removed those from the .htaccess file as well as deleting the boost directory from sites/all/modules
The problem still stands and my files are being sent to the browser compressed. Is there any other way to disable this?
Note that this only happens for pages inside Drupal, having uploaded a simple php page and navigate to that url works fine -- which suggests therefore a drupal (rather than apache/php) problem.
I've noticed a module mimedetect which has a definition for application/x-gzip in there but not sure how could this affect it as removing this didn't render anything useful either.
Any ideas where to look and/or what might cause it?
Happy to provide any other insights that might be useful in diagnosing this.
Ok so having actually reset the database cache and with the settings above this now works. I'm trying to figure out which one of the above actually solved it.
I am developing an application in the Kohana PHP framework that assesses performance. The end result of the process is a webpage listing the overall scoring and a color coded list of divs and results.
The original idea was to have the option to save this as a non-editable PDF file and email the user. After further research I have found this to be non as straight forward as I hoped.
The best solution seemed to be installing the unix application wkhtmltopdf but as the destination is shared hosting I am unable to install this on the server.
My question is, what's the best option to save a non editable review of the assessment to the user?
Thank you for help with this.
I guess the only way to generate a snapshot, or review how you call it, is by storing it on the server side and only grant access via a read only protocol. So basically by offering it as a 'web page'.
Still everyone can save and modify the markup. But that is the case for every file you generate, regardless of the type of file. Ok, maybe except DRM infected files. But you don't want to do that, trust me.
Oh, and you could also print the files. Printouts are pretty hard to be edited. Though even that is not impossible...
I found a PHP version that is pre-built as a Kohana Module - github.com/ryross/pdfview
I've built a CMS (using the Codeigniter PHP framework) that we use for all our clients. I'm constantly tweaking it, and it gets hard to keep track of which clients have which version. We really want everyone to always have the latest version.
I've written it in a way so that updates and upgrades generally only involve uploading the new version via FTP, and deleting the old one - I just don't touch the /uploads or /themes directories (everything specific to the site is either there or in the database). Everything is a module, and each module has it's own version number (as well as the core CMS), as well as an install and uninstall script for each version, but I have to manually FTP the files first, then run the module's install script from the control panel. I wrote and will continue to write everything personally, so I have complete control over the code.
What I'd like is to be able to upgrade the core CMS and individual modules from the control panel of the CMS itself. This is a "CMS for Dummies", so asking people to FTP or do anything remotely technical is out of the question. I'm envisioning something like a message popping up on login, or in the list of installed modules, like "New version available".
I'm confident that I can sort out most of the technical details once I get this going, but I'm not sure which direction to take. I can think of ways to attempt this with cURL (to authenticate and pull source files from somewhere on our server) and PHP's native filesystem functions like unlink(), file_put_contents(), etc. to preform the actual updates to files or stuff the "old" CMS in a backup directory and set up the new one, but even as I'm writing this post - it sounds like a recipe for disaster.
I don't use git/github or anything, but I have the feeling something like that could help? How should (or shouldn't) I approach this?
Theres a bunch of ways to do this but the least complicated is just to have Git installedo n your client servers and set up a cron job that runs a git pull origin master every now and then. If your application uses Migrations it should be easy as hell to do.
You can do this as it sounds like you are in full control of your clients. For something like PyroCMS or PancakeApp that doesn't work because anyone can have it on any server and we have to be a little smarter. We just download a ZIP which contains all changed files and a list of deleted files, which means the file system is updated nicely.
We have a list of installations which we can ping with a HTTP request so the system knows to run the download, or the click can hit "Upgrade" when they log in.
You can use Git from your CMS: Glip. The cron would be a url on your own system, without installing Git.
#Obsidian Wouldn't a DNS poisoning attack also compromise most methods being mentioned in this thread?
Additionally SSH could be compromised by a man in the middle attack as well.
While total paranoia is a good thing when dealing with security, Wordpress being a GPL codebase would make it easy to detect an unauthorized code change in your code if such an attack did occur, so resolution would be easy.
SSH and Git does sound like a good solution, but what is the intended audience?
Have you taken a look at how WordPress does it?
That would seem to do what you want.
Check this page for a description of how it works.
http://tech.ipstenu.org/2011/how-the-wordpress-upgrade-works/