A client's Joomla 3.6.5 website was hacked. After running a virus scan and malware scan on the entire directory, nothing came up. When I searched for the malicious URLs, they appear in the database, but nowhere in the code of the website files. I'm not sure how to find the hack, or how to clean out the malicious URLs.
(11216,'http://xxxx.com/cache/j.js',NULL,'http://xxxx.com/philosophy-of-life-essay.html','',3,0,'2017-04-14 10:50:38','0000-00-00 00:00:00',301),
(11217,'http://xxxx.com/cache/jq.js',NULL,'http://xxxx.com/philosophy-of-life-essay.html','',3,0,'2017-04-14 10:50:38','0000-00-00 00:00:00',301),
(11218,'http://xxxx.com/cache/layout.css',NULL,'http://xxxx.com/philosophy-of-life-essay.html','',1,0,'2017-04-14 10:50:57','0000-00-00 00:00:00',301),
(11219,'http://xxxx.com/cache/ssc.css',NULL,'http://xxxx.com/philosophy-of-life-essay.html','',1,0,'2017-04-14 10:52:09','0000-00-00 00:00:00',301),
(11220,'http://xxxx.com/cache/jq.css',NULL,'http://xxxx.com/philosophy-of-life-essay.html','',1,0,'2017-04-14 10:52:09','0000-00-00 00:00:00',301)
Since the malicious URLs are in the database, was the database hacked? How do I remove the malicious URLs and how do I fix the hack? I know I have to change the passwords, but I'm stumped with how to unhack this site. I'm not sure how to clean out a hacked database. Any tips? Thanks!
Q: Since the malicious URLs are in the database, was the database hacked?
A: Not possible to tell with the information provided.
https://docs.joomla.org/Security_Checklist/You_have_been_hacked_or_defaced
The term "hacked" is very broad. Have credentials been fraudulently obtained? Was the website defaced? Was valid data stolen from the database? Has valid data has been removed or changed? Has new fraudulent data been added?
There are several ways any of those could have happened. One possibility is that database modifications were made through normal operation of the website, by a malicious actor who obtained credentials (login and password) to perform those operations.
Or, a malicious actor could have exploited a vulnerability in the website code. Given the predominance of XSS and SQL Injection vulnerabilities, and the relative ease of exploiting those, this is the most likely scenario. (A lot of website "plugins" are known to be vulnerable.)
Or, some other program connected to the database and performed database operations.
Q: How do I remove the malicious URLs?
A first step would be to restore a copy of the database from a known good backup.
And with a saved copy of the suspect database, we could do a comparison, to help identify data that has been removed, changed or added. (What makes a URL "malicious"? How are you defining that? All we see in the question is what appears to be some rows from a database table. How are these rows more "malicious" than other rows?)
Q: How do I fix the hack? I know I have to change the passwords ...
If an unauthorized actor has obtained login credentials, then yes, you need to change the passwords. And figure out how they obtained the credentials, and take steps to prevent that from happening again.
And close up the vulnerabilities, to prevent that from happening again.
Q: I'm stumped with how to unhack this site. I'm not sure how to clean out a hacked database. Any tips?
Restore the database from a known good backup.
And again, mitigate the vulnerabilities to prevent (or make it less likely) that this will happen again. Cross site scripting (XSS) and SQL Injection are always in the OWASP Top 10.
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#tab=OWASP_Top_10_for_2013
https://www.owasp.org/index.php/SQL_Injection
What you are experiencing is a database hack, which is the worst kind of Joomla hacks.
Reverting to a backup may be a good solution if you are running a semi-static website, however, if your website has new content every day (or had new content since the hack), then you can't revert to a backup without losing data. In this case, you will need to use MySQL's REPLACE function to replace the hacked strings with an empty value.
Once you fix the database hack, you will need to run an internal scan on your website to ensure to find if there are hacked/backdoor files anywhere. Once that is done, you will need to uninstall all the unused extensions, and you will need to uninstall all the extensions that are on Joomla's VEL list. Any extension that you have must be updated to the latest version.
Once you are done with the above, then you will need to do the following:
Change all the passwords of the website: including Joomla passwords, FTP/sFTP, database passwords (avoid using FTP if you can), cPanel passwords, etc...
Restrict Apache's access of PHP files to the 'index.php' file (that can be done in the htaccess file).
Move the website to a VPS or a dedicated server if you are on a share hosting.
This seems to be a pretty bad one! A few tips:
Be sure to check Google blacklisting status & also do a 'fetch as google' to check if there's malware showing up in search results.
It is recommended to find all the external calls from the website to other domains (usually hackers point credit card details to their own domains or emails).
A diff command would go a long way:
$ mkdir joomla-3.6.4
$ cd joomla-3.6.4
$wget https://github.com/joomla/joomla-cms/releases/download/3.6.4/Joomla_3.6.4-Stable-Full_Package.tar.gz
$ tar -zxvf Joomla_3.6.4-Stable-Full_Package.tar.gz
$ diff -r joomla-3.6.4 ./public_html
There are more steps which can be checked from this URL: https://www.getastra.com/blog/cms/joomla-security/joomla-admin-security/
Related
Some of our ColdFusion sites are having the words "coupon" inserted into their footer with a link to another site. Is there anything I can do to prevent this? Is there any software I can run to help detect any vulnerabilities? It doesn't seem to be SQL injection as the databases seem fine and nothing unusual is showing up in the logs.
There are several variations of attacks that produce this sort of result (appending a link to some malicious or nefarious site). For example, this one (Script Injection) uses the latency between a file upload and checking to insert executable code on your server.
Other attack vectors include FTP (which is why you should not use it), or other file transfer protocols. In your case the infected machine may not be the server. It could be a client machine with access to the server - a developer who has set up FTP to the server for example.
Let me know if you need formal help - we have a good track record fixing this sort of thing. If you get more clues post them and I'll try to help. I will warn you that if this is a server infectionit is at the root level and is so pervasive your only option is to start with a pristine install and reinstall your code. Bad news I know - sorry :(
We had something similar happen when one of our servers was hit by the hack Charlie Arehart describes here:
http://www.carehart.org/blog/client/index.cfm/2013/1/2/serious_security_threat
Have you had these patches?
Another option that I would recommend is searching your site(s) for any use of the <cffile> tag that isn't expected. I had a customer that somehow got a single file that was a backdoor to their site. It was particularly dangerous because it could upload files to any location on the server as well as execute any SQL command against any datasource on the server. In other words, this single file opened the door to all of the sites and databases that were running on that server.
This backdoor file (which was named vision.cfm) was often used to update footers with links to coupon and spam sites. vision.cfm was only 210 lines of code.
The entire server had to be sanitized after this was discovered.
I found out after a while that a component used on my website had an unfiltered parameter, in a WHERE condition in the following settings:
Using Joomla! 1.5, latest update.
The component is custom made, fairly small, and after reading its source I couldn't indentify any other security flaws.
The attacker was using SQLMap to do their work, as I saw its user-agent in the log.
MySQL version is 5.1.11
PHP version is 5.1.4
The database user has USAGE privilege.
The server OS is Linux.
After trying the same steps on my own box, I was able to read the database (and since I'm not an expert in sql injection I'm not sure that was all I could do).
My worry is mostly about the session table, would the attacker be able to impersonate a user from it? Aside from that, is there any chance he could have uploaded some payload to my server?
Also, could he have "magically" updated some field through this SELECT query? (No stacked queries available).
Thanks in advance.
If you can read the database, you can dump it with SQLMap and find the hash of the administrator's password.
With that hash, the attacker could crack it (or if it is MD5, find a collision fairly quickly) and login into your administrator account.
From there, your admin account is screwed. The attacker has admin privileges, so consider your site dead. Worse than that, if Joomla is like Wordpress, the attacker can use a custom PHP code in the theme, which allows them to drop to OS level and modify your Joomla installation.
In short, they can screw up your server, as Joomla executes arbitrary PHP code when it is run.
This is my first time building a website and using CodeIgniter for a school project. I was wondering whether you have any tips on uploading CI to a free web host , my database, free webhosting and basic security tips.
Can I just upload the entire CI folder? Or do I have to upload individual files (God no!)? What are my options?
What about my MySQL database - do I just upload my mysqldump to the webhost?
Also, can you recommend a good free webhost. I was thinking about 000webhost.
Any basic tips on security would also be appreciated (I've implemented many of the form_validation rules like xss_clean for starters)
Any other suggestions will be more than welcome. Thanks!
I used 000webhost.com long time ago and remembered having minor inconvenient here and there (i.e.: slow connection, server unreachable sometime). I don't have any suggestion on a good free webhost because in most situation the words "good" and "free webhost" do not belong in the same sentence. You get what you paid for.
Now, onto the uploading itself.
You need to upload the entire CI folder and your app as well
You can either zip them all and extract the zip if you have shell access to the server
You can use FTP to upload all files at once
MySQL DB: if you have SQL scripts, you can execute them in phpMyAdmin interface if the web host provider gives you access to it. Please read phpMyAdmin documentation for ways to upload your MySQL data.
In terms of security:
http://codeigniter.com/user_guide/installation/index.html
http://codeigniter.com/user_guide/general/security.html
Sanitize user input if you're using SQL expression directly
If you are using CI ORM/database library, make sure you keep yourself up to date to any security issues by checking CI mailing-list, IRC, or whichever the preferred communication channel the CI people use.
For simplicity, avoid HTML tags (as a user) input, treat them as literal
Instead of uploading individual files make the entire directory into a zip folder (or any compressed folder) to save bandwidth and time.
Also most webhosts will have an uploader, but im not sure about free hosts supporting database services, you would have to look into that.
Long story short, we found files promoting prescription drugs on our server that we didn't put there. The Windows server has very old applications and runs MySQL 5.1.11.
Beyond other security flaws, could SQL injection be used to write files to the server file system? I am certain that some of these old applications are vulnerable to SQL injection attacks. I would NOT think that this is possible, but I seem to remember reading somewhere that MySQL could access the "command line" and write files via it though I can not locate a source for that info. Then again, my mind could be playing tricks on me.
If this is possible, is there a setting that can disable it?
Also, I'm not looking for the answer that says get rid of the SQL injection vulnerability. While that obviously needs to be done; I'm looking for a quick short term fix that will prevent the rogue files from magically appearing again while the SQL injection vulnerabilities are being fixed. Fixing all the old applications is going to take lots of time.
Thanks.
It's possible, especially with suitably careless configuration.
For example, there is SELECT ... INTO OUTFILE 'file_name'
But it's also more likely to be a different security problem. I'd seriously consider taking the software offline quickly, especially if the database contains any confidential or private information
as Colin Pickard shows, yes.
but even if you can't update your application, i doubt it needs the rights it's currently running with. you need to check the user it logs in to mysql with and trip those permissions down to the minimum. specifically in this case, you should remove the FILE privilege if your app does not read/write files stored on the mysql server.
Setting the permissions of the application directory to read-only for the web account might work. This assumes that you're not already creating files in it like logfiles and such.
My website has been compromised. Some one have injected some iframe markup in my website.
How they have done this? Only on my index.html, index.php page. But I have blocked write permissions for this page, then how they able to write in my pages.
Will it effect other pages on my server?
Is there any other solutions to block this?
Thank you
<?php`
include_once("commonfiles/user_functions.php");
include_once("user_redirect.php");
include_once("designs/index.html");
?>
<iframe src='url' width='1' height='1' style='visibility: hidden;'></iframe>
This is my index.php code <iframe> is injected after the php script.
Someone with FTP access to your site (you or your developers) has a virus on their workstations. This virus has installed a keylogger that is stealing credentials from your FTP client and sending this information back to the hacker.
The hacker collects hundreds of such credentials and then uses a program to log into each server, download a file, modify it to append an iframe or block of obfuscated JavaScript or PHP, upload the file, download the next file, modify, upload, next, etc. The files downloaded may either match a set of names (such as only index., default., home.* etc) or just any html or PHP file.
The appended code is often either an iframe that is visibility: hidden or of 1x1px size, a <script> sourcing a remote JavaScript file on a dubious domain, a collection of Javascript obfuscated by some clever str.CharCode'ing, or a block of base64_encode'd eval()'d code. Unobfuscating the code, the result is often an iframe. More recently, some clever attackers are inserting remote shells, granting them backdoor access to your server.
Once all the files have been modified, the attacker logs out. Visitors to your site will be subject to malicious code from the domain linked in the iframe with the intention of installing viruses and rootkits. Among other functions, these viruses will install a keylogger to sniff FTP credentials... and the virus continues spreading.
The attacker is using your credentials, so they can only access files that you have access to. Sometimes, they will upload an additional file in certain directories with an encoded shell, allowing them return access to the server (the common ones are _captcha.php in /forums directores and img.php or gifimg.php in /gallery directories). If you host other domains on your server, as long as the user for the affected domain has no access beyond their current domain, others will not be affected.
There are two ways to stop this sort of attack -- prevention and proper antivirus. The attacks can be easily deflected by use of a firewall and limiting FTP access to only a few select IPs. The attackers are not attacking from your own workstation (yet), but rather a server elsewhere in the world. Using proper antivirus on all workstations with access to your FTP account -- or, better yet, not using Windows XP -- will help prevent the original infection from occurring.
If you are infected, it's fairly easy to clean the messes up using a bit of clever sed, depending how good you are at spotting the injection and making effective regexes. Otherwise, backups backups backups -- always have backups! ...Oh, and change your FTP password or they'll be back tomorrow.
If the php file itself has been edited to include this iframe and if there truly is no way for another script you are running to write to the file then a user account with access to the file might have been compromised. If there is a user account with access to the file that has a weak password this would be my candidate as the most likely culprit.
They may have used some form of injection on your site to acquire usernames and password hashes and bruteforced those, they might have installed a keylogger on someone's machine who has access, or they may have just brute forced your login directly (assuming you don't have some sort of mechanism in place to prevent this).
First thing I would do is ensure there are no viruses running on anyone's computer who has access to the machine. Then go about changing passwords. And finally review the php scripts of the site for possible points of injection. Trouble spots are pretty much anywhere you're taking in some kind of user input and processing it without first checking to make sure it is safe to process (i.e. failure to strip dangerous characters from a user login form).
From the comments that have been posted so far it seems almost certain that someone has gained access to a user account with write permissions on the files that are having code injected into them. It sounds like some individual has discovered one or more account passwords and has made it their pastime to occasionally log into your FTP and make some changes. Have you tried changing your passwords? I recommend using a fairly secure password, of at least 15 characters and using a variety of character types including unprintable characters if you are able (use alt/meta keys to enter UTF codepoints on the number pad).
If, after changing your password, you still observe the same problems, then there could be another issue. I would first seriously scrutinize your PHP scripts. Anywhere your scripts accept user input from a form, data stored in a cookie, or other data originating from outside the script itself (and therefore potentially "dirty" data), go over the operations of the script with this data very carefully. If you are using any such potentially dirty data to run an OS command, open/read/write a file, or query a database, then it is possible that the data contain escape characters that will escape your code, allowing an attacker to execute any code they wish within your script.
Keep an eye on your access logs. You mentioned that you remove the injected iframe code from your scripts and it keeps being re-injected, so if you can catch when it happens you can probably find a clue as to the source of the changes in your access logs.
See this thread for more on trying to block iframes.