Introduction
This article highlights well known website vulnerabilities, bad practices, flaws and security issues that allow hackers to compromise websites. Its purpose is strictly educative and it should be used as guide to enhance the web security applied to websites and web applications.
Material presented below is gathered based on common mistakes made by internet users having very limited computer science skills. The base level information shared here depicts an entire arsenal that lead to successful cyber attack, resulting in legitimate websites getting blacklisted by search engines and security manufacturers.
The top 7 common web security issues as collected by Quttera experts when investigating compromised websites:
1 - poor username and passwords
2 - key-loggers (PC malware) stealing user credentials that are further used to access and hijack website
3 - SQL injection to dump content of database copying login credentials stored in it
4 - installation and use of vulnerable plugins for widely used CMSs like WordPress, Joomla and Drupal.
5 - shared hosting issues - hacked website allows access to all websites installed on the same server.
6 - bad configuration of PHP (php.ini) resulting in remote files injection and remote code execution
7 - XSS flaws - cross site scripting vulnerabilities based attack as most pervasive
“Invalid handling and poor validation of the user input are most common reasons for web application crash and for opening access to website internals.”
1 - How hackers steal username and password to my website control panel
As human beings, it is pretty difficult for us to think of complicated username and password for each and every online service and, more of it, is pretty difficult for us to then recall it. Even for the services used on a daily basis.
So how password management implemented on the site? In general every provided password is passed through one way mathematical function (called hash function) which maps between password and appropriate hash value (text comprised from digits and characters). During authentication phase, website user/visitor enters previously registered username and password, website code process inputs via the hash function and further checks whether function output identical to previously stored value. If calculated hash value is identical to the stored one - user passes the validation, otherwise the login is rejected.
While one way functions require minimal resources to calculate appropriate hash value for provided input, it is pretty expensive to do the same in opposite direction, - mapping from known hash value to original input. For example MD5 [1], MD4 [2], SHA-1 [3] or in general any cryptographic hash function [4] could be used to map from user’s password to appropriate hash value.
With modern CPU’s capabilities, one could easily conquer this problem and run such function hundred of times per second and simply verify whether provided input generates required hash values. In other words, given required hash value(stolen from third party database) and wordlist containing few millions of words, it won’t take a lot of time to go over all input words and find which one produces the desired hash value.
There are more than enough of free tools available that could be used for this purpose. Most popular of them are “John the Ripper” and “Hashcat”.
Basics that can help you minimise the risk of stolen credentials:
- Use automatic tools to generate complicated password
- Use keepass (or similar utilities) to create/store/manage your password
- Use more complex or homemade algorithms for hash function implementation
- Use strong passwords (more than 10 symbols)
References:
Helpful reading:
2 - Keyloggers and other stealing user credentials malware
Basically key-loggers are software programs capable to monitor and log to a file every keystroke performed on the monitored device. Such programs can monitor web browser activity, instant messengers or email client applications while the collected data is sent to remote server for further analysis by the attacker. Initially, key-loggers have been used used by IT staff to analyze and fix technical issues, monitor device activity, for parental and employee control. They were later utilized by cyber-criminals to steal email addresses, login credential and other sensitive user information that could be used for financial benefits. Software key-loggers may be classified into these major classes:
a) Web browser add-on or extension listening on JavaScript events and log web browser activity
b) Stand-alone process monitoring keyboard activity. Cheap to develop from one side but from another side it is easily detected by most AV engines.
c) Shared library (dynamic linking library) injected into memory of another process and further running with execution permissions of the exploited process.
d) Kernel module (driver) loaded into kernel space of compromised operating system. Such key-logger can be implemented as a rootkit or keyboard device driver and it is very difficult for detection by security software.
Some keyloggers are very popular and are freely available on the internet, while more than 90% of such applications are used for malicious purposes. Search[1] for “keylogger” word on softpedia.com returned 17 pages.
Identical to all known kinds of malware, key-loggers can be installed on the targeted device without any user interaction (for example via “Drive by download” attack). It then runs transparently and insensibly to common work of the compromised device.
Well known and widely spread malicious key-loggers are Zeus[2] and Spyeye[3].
Basic preventive security measures:
- Keep your PC clean from malware using common AV and anti-keylogger solutions
- Avoid login into your dashboard from not trusted devices like public PC
References:
3 - SQL injection attacks
A dominant percent of web sites run on/ or their back-end use SQL ( Structured Query Language ) database to store website content and management information. On these sites, users input is processed by website application code and stored in SQL database for future access and or presentation. An interaction with SQL database is done via SQL commands called queries.
As an example for user input let’s take a user registration form where it is required to provide login credentials, avatar and other information relevant to the registration process. Further website will hash provided password , as it was described in 1, and store all acquired information including newly generated password into the SQL database.
Following is a PHP command example which adds new customer to existing customers table:
mysqli_query($con,"INSERT INTO Customers (First_Name, Last_Name, Age, Id, Pass, Email)
VALUES ('Michael', 'Fish',35, b354390b8d81c0a880a42bee9f586fd5, Michael@fish-net.cc)");
Next time when during login procedure, user will submit his/her username and password and this information will be retrieved from the database and compared to the submitted values.
So what is SQL injection attack? SQL injection is basically an insertion of SQL query via the user input data form into the backend database. Successful injection of SQL query may provide access to valuable information like a list of stored passwords or credit cards numbers. It may allow to run administrative commands like dump or erase database content.
Now let’s say that data form validation handler contains security vulnerability and does not validate whether the provided email is actually an email address. An example PHP code looks like this:
mysqli_query($con,"SELECT * From Customers WHERE Email LIKE $email;”);
When user submits valid email address, $email variable will contain Michael@fish-net.cc and such command will return user record previously created by “INSERT INTO” command. But if for example user inserted “%@gmail.com”, where % is SQL wildcard symbol, this command will select all registered users with gmail email address. This simple case shows that website behaviour may depend on user input and perform not-predictable operations.
Of course, SQL injections today are much more sophisticated and our intent was just to highlight its principle.
In conclusion, SQL injection is very dangerous attack since in addition to compromised website you can damage your reputation if user sensitive data will be stolen and published on web. Like it happened with social games developer RockYou, who was attacked back in December 2009 when more than 32 millions of user passwords were publicly disclosed on web.
Basic preventive security measures:
- validate and verify every user input
- periodically test your website with SQL injection scanners like http://www.mavitunasecurity.com or www.gamasec.com
- Move your website to NoSQL (https://en.wikipedia.org/wiki/NoSQL) databases like MongoDb (http://www.mongodb.org/) or couchdb (http://couchdb.apache.org/) databases.
Useful links:
Explanation video on SQL injection: http://www.youtube.com/watch?v=PB7hWlqTSqs
OWASP on SQL injection: https://www.owasp.org/index.php/SQL_Injection
Wikipedia: http://en.wikipedia.org/wiki/SQL_injection
PHP based code: http://php.net/manual/en/security.database.sql-injection.php
RockYou incident analysis: http://iqsecur.blogspot.co.il/2012/01/analysis-of-rockyou-leak.html
4 - Installation and usage of vulnerable CMS plugins
In last ten years, open source CMS packages/frameworks experienced pretty huge boost. These days the majority of very popular websites are implemented on open source CMS.
Free CMS solutions have very big community which provide supports for such CMS and enhance them with a new extensions and/or plugins. Such plugins comes to enrich initial CMS functionality, help maintain website content and to add other useful capabilities. But when implemented with bugs they often inject serious security vulnerabilities into the system.
Since 2004 WordPress CMS had more than 450 vulnerable plugins (http://www.w3bsecurity.com/warning-wordpress-plugins-vulnerability-list-from-2004-to-2013/), Drupal had more than 100 (http://www.cvedetails.com/product/2387/Drupal-Drupal.html?vendor_id=1367) and Joomla more than 90 (http://www.cvedetails.com/product/6129/Joomla-Joomla.html?vendor_id=3496) vulnerable plugins.
Pretty rich arsenal of security vulnerabilities can be found in such plugins including XSS, Denial of Service, access to sensible information, injection of malicious PHP and or JavaScript code, SQL injection, exploits injection and etc... Quttera users frequently detect malicious plugins and from time to time we post about this cases on our blog.
Unfortunately it takes some time from underground discovery of such vulnerability until public knowledge and bug fix. While during this period of time cyber criminals utilize it and compromise thousands or maybe tens of thousands of websites.
Basic preventive web security measures:
- Use only well known and well tested plugins
- Monitor your website with web malware scanner to detect malicious content as soon as possible using scheduled and on-demand malware scan
- Regularly check list of installed plugins for newly discovered and published security vulnerabilities
- Use most recent and stable version of the CMS
- Update plugins as soon as new version is available
5 - Shared Hosting issues; hacked website allows access to all websites installed on the same server
Before digging into security issues of shared hosting let’s try to understand what shared hosting is and why it is widely used by web hosting providers.
So what is shared hosting? As the name implies, we can think of it as one physical server and one web server (like Apache) hosting and servicing hundreds or maybe thousands of web sites which in turn share the same physical server, HTTP/web server and the same hard disk used to for physical storage of the content presented on the website.
<root-directory>
|
|- <root directory for website A>
|- <root directory for website B>
|
…
…
|- <root directory for website Y>
|- <root directory for website Z>
As long as main server CPU strength, network bandwidth or network capabilities of cable (network environment) connecting this server to internet and size of physical storage allows it there is no limit as to how many different websites can be hosted on one shared server.
So what is pros of such solution? In general, it is a price per month that maybe as low as few US dollars. If you’re managing small web site you don’t need and probably will never use all the capabilities provided by physical server. Dedicated physical web server will cost you much more and you it’ll take a lot of time to manage and operate it.
Usually, shared hosting provides you with dashboard UI to operate with files, FTP credentials to manage your content, Email management and capabilities to install some applications to enhance your website. The other side of the coin is security of provided service.
Once you share the resource with hundreds or maybe thousand of other web sites you cannot be sure for 100% that all these guys are committed to keep their site secure and free of malware. Add to this the use of outdated CMS with vulnerable plugins and you get the recipe for the disaster. Finally, once any of those websites are compromised, your chances to be hacked as well multiplied by tens or maybe hundred times. Successful attack may allow hacker to read/write to the files of any other accounts.
So what are security issues in shared web hosting environment?
The cancer of shared web hosting servers is the “directory traversal” attack (http://en.wikipedia.org/wiki/Directory_traversal_attack) allowing by specially crafted path to access and change files of other websites. So once at least one website was compromised and hacker gained access to an entire hard disk he can do whatever he wants. That includes: deleting content from all websites, changing index files, infect web pages with malicious code or redirecting traffic to malicious resources or simply install shell (like C99) to manage files and directories and maybe distribute malware from the infected website. In some cases websites get compromised with SEO spam injection and appear in search engines with spam content. The major problem in this case is that you cannot be sure that after remediation on your website, you won’t be infected again. Until malware won’t be removed from an entire shared web server, of course.
Useful links:
6- Security vulnerability caused by incorrect configuration of PHP interpreter
PHP, since 1995 and up to day, is one of major players on web infrastructures market. Due to its simplicity, PHP is known as not too much secure environment. Usually, PHP developers mostly concentrates on development of web application itself without paying required attention on the security issues and user input sanitation.
Regardless to web application vulnerabilities and bugs, unsecured PHP configuration may open gates for number of known attacks including SQL injection leading to leaks of sensible information, XSS (cross site scripting) , directory traversal which provides access to server’s file system, local and remote file insertion allowing execution of any PHP code as a part of website functionality. Following is pretty simple example of a code, vulnerable to remote page insertion attack:
<?php>
$req_page = $_GET[‘page’]
include( $req_page );
?>
In this example ‘page’ parameter is passed to PHP code via arguments passed inside URL and may contain reference to any local or remote files.
So how to overcome all these issues? Proper configuration of PHP is pretty difficult task and should be adopted to application needs. For example you can disable use of several PHP functions accessing OS interfaces like “exec”, “shell_exex”, “system”. Periodically test application code with static code analysis tools like RIPS (http://rips-scanner.sourceforge.net/). Validate any user input parameter passed as arguments to SQL queries. Following is a list of third party links that may help you to protect your website from PHP driven vulnerabilities.
Useful links:
PHP Security Best Practices: http://www.cyberciti.biz/tips/php-security-best-practices-tutorial.html
Securing Apache: http://www.symantec.com/connect/articles/securing-apache-step-step
Open source vulnerability scanner: http://www.openvas.org/
Securing WordPress configuration: http://blogvault.net/wordpress-security-1-securing-wp-config-php/
30+ PHP best practice for beginners: http://net.tutsplus.com/tutorials/php/30-php-best-practices-for-beginners/
PHP security manuals: http://php.net/manual/en/security.php
7 - XSS or cross site scripting vulnerabilities and attacks
XSS or cross site scripting website security vulnerability provides attacker with possibility to insert/inject JavaScript code that will be executed as a part of a original web page viewed by site visitor. The malicious JavaScript code provided as a part of user input arguments of original URL and without proper sanitation is inserted by web server into body of the HTML page.
XSS attacks classified as non persistent and persistent.
During non-persistent XSS attack, user simply access a vulnerable website using specifically crafted URL, containing the malicious script. The code running on side of vulnerable web server copies this input into the targeted HTML document and returns it back to website visitor giving to injected script possibility to run as a part of legitimate content of the required web page.
Following is an example on non persistent XSS attack.
The specifically crafted URL:
http://myxsssite.com?name=Myname<script>alert(“Hello World”)</script>
The vulnerable PHP code injecting the name argument into outputted web page without any proper validation:
<?php
$name = $_GET[‘name’];
echo “<p>Hello $name</p>”;
?>
What happens here is that $name argument passed to the echo routine without any validation and resulted in the following HTML code
<p>Hello <script>alert(“Hello World”)</script></p>
This is very simple and non damaging example will just show alerting window with text “Hello World” but in place of this simple script attacker can put any malicious script that may steal session information, inject iframes and redirect website visitor to another malicious website.
During persistent XSS attack, the injected malicious script is stored into website’s backend database and will be injected into normal webpage shown to other users. Example of such attack is a website of a social network providing end user capabilities to store his/her information on server side and be accessible by other users. Now if website is vulnerable and is not implementing input sanitation, instead of his name or occupation description malicious agent will put malicious code, this code will be stored on server’s database and shown (run) every time other users will visit malicious agent’s page. Such kind of attacks may steal session information or website administrator credentials giving hackers full access to the attacked web server.
Basic preventive web security measures:
- Validate every user’s input provided to website as a part of referenced URL
- Validate user input before this information stored into websites database
- Periodically test your website with available XSS vulnerability scanners
Useful links:
Cross site scripting presentation: http://intellavis.com/blog/?p=353
Detecting cross site scripting vulnerabilities: http://intellavis.com/blog/?p=325
Zed testing tool for finding vulnerabilities in web applications: https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
No comments:
Post a Comment