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.
Related
I'm learning to code and encounter a problem with making a form using HTML.
In the book, it stated that "every <form> element requires an action attribute and its value is the URL for the page on the server that will receive the information in the form when it is submitted."
But I thought about it for a long time, and I couldn't figure it out. What is meant by "the URL for the page on the server". If I got a site uploaded to a web hosting company, I would need to get it there? Or I need to rent a server elsewhere so that I will get one? Or it just fine to be store on a local file? Because I saw the data need to be processed by PHP, although I don't know whats that.
Can anyone help me with this? Really appreciated.
Regards,
Ace
An HTTP(S) URL will include a hostname (which identifies a computer (acting as a server) on a network) and a path (and possibly some other components which don't matter for this question).
When you type a URL into the address bar of a browser, the browser will make a request to the server and ask for whatever is at the path.
The server will respond (typically with some data like an HTML document).
The server has to perform some logic to decide what to respond with. Typically this will either be:
Reading a file from its hard disk and returning the contents or
Executing a program and generating some content programmatically
When you submit a form, you are making a request to a URL with some data attached to it. Almost all of the time you will want the server to execute a program and do something with that data (such as put it in a database).
The program that gets executed can be written in any programming language you like (such as Perl, PHP, JavaScript, Java, or whatever).
If I got a site uploaded to a web hosting company, I would need to get it there?
Typically, if you have web hosting already then you will use that web hosting for any server-side programming you need to do.
If the hosting service doesn't provide you with any server-side hosting options (i.e. if it is just static hosting such as you might find from Github Pages). Then that isn't an option. Likewise if the server-side options they program aren't suitable for you (e.g. they only support PHP but you want to run something written in Node.js) then you'll have to find an alternative.
The two alternatives you have are:
Move everything to hosting that provides the features you want
Host something elsewhere and keep the majority of your site in the original hosting
(There is nothing wrong with the latter option, I have one site which uses Amazon S3 static hosting for most of it but has a couple of web services running in Heroku).
Or I need to rent a server elsewhere so that I will get one?
Dedicated hosting is almost certainly very expensive overkill for your purposes.
Or it just fine to be store on a local file?
It isn't possible to do server-side programming with a file: scheme URL. There's no server to execute the program.
If you are only working locally then you can install a web server on your computer. This is normal for development purposes.
It is probably worth mentioning that there are a few common server-side programs which are available prewritten with hosting services (e.g. contact forms which email you when someone fills them in). These typically come with advertising and require that the <form> and its contents are constructed with the specific fields the service expects. If you look for one of these be careful to follow their instructions precisely.
Aside: The statement that the action attribute is required is flat out wrong. It is an optional attribute and in its absence the form will be submitted to the URL of the current page.
HTML is a front-end tool that allows you to take inputs using a form from the user. once the user clicks the submit button a post request is sent to the back-end tool (PHP in this casse; PHP is a back-end programming language). the back-end tool handles the information given and deals with it to your liking. the action attribute is basically telling the front-end (HTML) where to give the information to the back-end(PHP) which is in the form of a URL.
i highly suggest trying out this example on W3schools :
https://www.w3schools.com/tags/att_form_action.asp
I see you want to send your HTML form data to a PHP script. You can use WAMP server or XAMP server to do this locally. You should use the PHP script file path as the input for the .
For instance,
Home.html
<HTML>
....
<form action="process.php">
...
</form>
</HTML>
So, when you submit the form , the form data is passed onto the PHP file which you can access using a $_[SUBMIT] super global array in your PHP script.
Check github for projects on HTML,JAVASCRIPT,PHP.
Here's one to start: https://github.com/kristej/Uniform-Database-Management.git
If you are sending the data to an online server, you need to own it to process it. Hence try it out locally first.
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/
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.
Recently I had problems with my email account (gmx.net). I have about 30 failed login attempts a day. But that is not the topic of the question (I already changed my password).
It got me thinking. Is this in automatic attack? And if so, how is it done? I took a look at the HTML code of the page and found out, that it is pretty easy to just copy the source code of the form element and do a login attempt through a local html file (copy and paste, new HTML file, open in browser, enter your credentials, submit). That means it is an easy task to automate such things (write a little script, that does a post with various values --> Brute Force attack). I was about to write an email to the mail hosted, when I found out, that the exact same process can be done on facebook.com....
I had the impression, that since we have all these new fancy web frameworks like Rails, Django and so on, we have an automatic protection against such attacks (for example the protect from forgery which Rails includes http://ruby.about.com/od/security/a/forgeryprotect.htm)
My question here is:
Is there any sane reason to allow a login attempt from another server?
Don't give me "API", the most APIs for web application require a manual login process before authorization.
I know there are many more ways to brute force attack any website login (use a framework that controls a browser etc...) and there are many ways to protect (IP-banning etc). But shouldn't disabling a remote login be one of the first security mechanisms you would take?
First off, I realize that there is no such thing as a perfectly secure solution (and even if there were, its usability would be crap).
That said, how do you protect your MySQL database from being compromised by someone downloading your code and picking through it? Based on my experience with PHP, it seems obligatory to store it within the code at some point or another, which sends up flags for me. I can see where refactoring to obfuscate variable, constant, and (user-defined) function names could be beneficial, but in the end it'd still be possible to trace through it and find the file with the DB login information.
Ideas?
Usually the MySQL auth information is stored in an external configuration file. The MySQL user used by the web-based app is given limited permissions such as SELECT, INSERT, UPDATE, DELETE and not given permissions such as ALTER, DROP, DELETE. If you want to release the code to the public you would not include your private config file, but a generic/instructional/minimal config file instead.
Storing the MySQL auth info in an encrypted format is somewhat silly, as you'd need to store the private key / unencryption locally as well. If it is trivial for an unauthenticated user to view the code or configuration files on your server the problem isn't the code - it's your server setup & config.
Security can be assisted by storing any hard-coded information (in config files or scripts) outside of the web-root, and by suppressing (on the production code) error messages. That way, hopefully, your users won't see that userValidate() expects exactly three paramaters.
pygorex1 is correct, you should use external configuration files where "external" means a file outside the web root. So even if there would be a configuration error in your web server which would allow the user to see your source code, they would not be able to see the database credentials since they cannot be accessed directly via the browser.
pygorex1 is also right on the user permissions. Limiting the mysql user's access to a minimum is always preferred. Even if a hacker would get the your mysql password and username, he would not be able to do significant damage if the user permissions are only limited to eg SELECT-queries. One thing he forgot to mention was that the mysql user should only be allowed to log in from localhost (or from whatever host the web application is on), never use wildcards in the allowed hosts.