Why Using Joomla Or Drupal Is More Secure Than Any Custom Made Application

Last week I attended a cyber security conference CyCon held in Estonia. There I had a chance to talk to a couple of guys from web development field. The discussion turned to the security of web applications. We discussed what is safer to use – publicly available open source web applications (for example – CMSes) or custom made websites.

The question is trivial. Public web applications have well known vulnerabilities with ready to use exploit kits. And new vulnerabilities pop up all the time. It doesn’t look promising in terms of security. At the same time private applications remain unknown due to the low prevalence (usually it’s only you using that particular app). Since they are not popular, they are not exploited.

However, there are two important aspects to keep in mind. First, what if you are under targeted attack? What if someone is going particularly after you? And second, what if your web app has some stupid security vulnerabilities that could be accidentally found by automatic (or semi-automatic) security scanners utilized by hackers?

In both cases you are basically left alone (unless you have a contract with the company who made the product). If using private web application you might even not know about the vulnerabilities unless (until) bad things happen.

One more point to keep in mind – if someone wants to hack your website – it will be hacked. That applies to the whole IT security in general (websites, networks, servers, etc.). The question is the time and the price.

Your goal is to make it as hard as possible, so that for the attackers it won’t be worthwhile and so they look for another target.

If you use public applications basically your task is to update them on time and also read and apply installation and security guideline principles. The biggest problem with open source web app is not the application itself, but rather its modules, plugins, etc. While main application is frequently updated, its modules might not. And that pose very important security issue. While a hacker has to find only one vulnerability for a successful attack, you as a protector have to find all the vulnerabilities to be safe.

So despite which version of web app you use it is absolutely necessary to do regular website security scanning as it could reveal possible and unknown vulnerabilities. I would say this is particularly important for custom made applications.


Custom made web application could be more secure then e.g. Joomla, but only if much attention is paid to security. By saying much attention I mean that security is in mind in the whole application development life cycle – planning, developing, testing and supporting. That requires great attitude and big investments.

If you don’t have that – stick to open source CMSes (like Joomla or Drupal). They are public and wide spread, but also many developers constantly take care of their security – as new vulnerabilities appear, they get fixed. So you are not left alone.

If you decide to use Joomla, Drupal or others, it’s very IMPORTANT to update them on time and to use all measures possible to harden them appropriately by following their installation and security guides. Also don’t forget to scan website security at regular intervals.

Best tools to check website security

Website security is a complex beast. To do a comprehensive vulnerability assessment you need to have right software, experience, patience and sometimes luck. We will provide you some guidance on selecting the best tools to check website security.

Whenever you approach a new website or just want to test your own website, the first thing is basically to scan it using your favorite security tool(s). Of course, if you’re not familiar with the website the first thing must be simply to browse it, to get the look and feel, to analyze its structure and to gather as much data as possible.

There are bunch of security scanning tools available – ranging from very expensive to free, from full-featured to very specialized. Previous blog post provides some hints on whether an expensive security testing tool is a good idea. Here we will try to show what software we use and will provide some guidance on choosing the right tools for your job.

Here is our quick top seven list:

1) W3af

Full featured and actively used framework which could be used both for audit and exploitation. It is extremely popular, powerful, flexible and easy to use framework for finding and exploiting web application vulnerabilities. It has dozens of web assessment and exploitation plugins. In some ways it is like a web-focused Metasploit.

2) BurpSuite Pro

Burp Suite is an integrated platform for attacking web applications. It contains many tools all of them sharing the same framework for handling and displaying HTTP messages, persistence, authentication, proxies, logging, alerting and extensibility.

It’s an indispensable tool for performing web application assessments. You can read web traffic and then manipulate it as much as you desire. There is a limited free version.

3) Websecurify

Ease to use tool that shows great potential. With websecurify you can do automatic and manual vulnerability testing.

4) ZAP

The Zed Attack Proxy (ZAP) is an OWASP project and is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing.

ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

5) SkipFish

Skipfish is an active web application security reconnaissance tool. It’s an excellent tool for automated initial quick assessment of the website. Written in C it is incredibly fast and can generate/analyze thousands of requests per second.

Skipfish prepares an interactive sitemap of the targeted website by carrying out a recursive crawl and dictionary-based probes. The resulting map is then annotated with the output from a number of active (but hopefully non-disruptive) security checks. After that the report is prepared which is meant to serve as a foundation for professional web application security assessment.

6) Wapiti

A tool written in python that scans the web pages of the webapp, looking for scripts and forms where it can inject data. Once it gets this list, Wapiti acts like a fuzzer, injecting payloads to see if a script is vulnerable.

7) Nikto

Nikto is a Perl script which performs comprehensive tests against web servers for multiple items, including over 6400 potentially dangerous files/CGIs, checks for outdated versions of over 1200 servers, and version specific problems on over 270 servers. From this perspective Nikto is kind of “signature based” tools. It also checks for server configuration items such as the presence of multiple index files, HTTP server options, and will attempt to identify installed web servers and software. Scan items and plugins are frequently updated.

Nikto won’t find all the bugs in your web app, but it will warn you about poorly configured web servers and will reveal other interesting things to poke at.

That’s all. To test website security may look simple however it’s always wise to play with the tools for some time to get the understanding what you’re doing. So called “point-and-shoot” scanning method could definitely tell you something, but it won’t reveal all the vulnerabilities.

Is my site hacked? Quick indications and symptoms showing your website is infected

There’s no doubt having your website infected is frustrating. But why is it actually so? What is wrong with being infected?

First let’s define what is an infection.

When your website is hacked, its contents are usually changed in one way or another.  The hacker may change pages to add spam, or add additional pages to the site, usually with the intent of phishing (tricking users into parting with personal and credit card information). Alternatively, they may inject malicious code (malware)—for example, scripts or iFrames that pull content from another website that tries to attack any computer that views the page.

In all the cases generally it is said that a website is infected by malware. The term “malware” covers all sorts of malicious software designed to harm a computer or network. Kinds of malware include (but are not limited to) viruses, worms, spyware, and Trojan horses. Some hackers may even take administrative control over a hacked site.

So, the answer to question what’s wrong with being infected is twofold:

First, despite all the generous intentions of your website, it is simply spreading malware. So now your site turns to be on the bad side of internet. This is not only disappointing, but also could make serious impact on your site or business credibility and reputability, not talking about possible legal consequences.

Secondly, by having malware you get immediate direct penalty by losing traffic to your site. Your site will be included in various blacklists (including Google). Visitors will see a warning and will stay away from your site, sysadmins will add preventive measures forbidding to access your site from within companies internal networks and so on and so forth. So you’d better be clean!

According to StopBadware, most common forms of infections that StopBadware sees on compromised sites are:

  • Malicious scripts
  • .htaccess redirects
  • Hidden iFrames

Malicious scripts

Malicious scripts are often used to redirect site visitors to a different website and/or load badware from another source. These scripts will often be injected by an attacker into the content of your web pages, or sometimes into other files on your server, such as images and PDFs. Sometimes, instead of injecting the entire script into your web pages, the attacker will only inject a pointer to a .js or other file that the attacker saves in a directory on your web server. To avoid detection and to mislead analytics scripts sometimes are divided into smaller parts. These parts can be spread on multiple files or even multiple websites and are combined upon running.

Many malicious scripts use obfuscation to make them more difficult for anti-virus scanners to detect:

website infected with obfuscated javascript

Some malicious scripts use names that look like they’re coming from legitimate sites (note the misspelling of “analytics”):

Malicious iframe with misspeling

.htaccess redirects

The Apache web server, which is used by many hosting providers, uses a hidden server file called .htaccess to configure certain access settings for directories on the website. Attackers will sometimes modify an existing .htaccess file on your web server or upload new .htaccess files to your web server containing instructions to redirect users to other websites, often ones that lead to badware downloads or fraudulent product sales.

Malicious httaccess redirects

Hidden iFrames

An iFrame is a section of a web page that loads content from another page or site. Attackers will often inject malicious iFrames into a web page or other file on your server. Often, these iFrames will be configured so they don’t show up on the web page when someone visits the page, but the malicious content they are loading will still load, hidden from the visitor’s view.

Malicious hidden iframe

How to find out if my site is infected?

The most obvious way is to analyze the source code and look for the forms of infection similar to described above. When you browse your own site keep focus on any unexpected results and analyze the source code of such pages. Look for obfuscated JavaScripts, iFrames, check your .htaccess file.

Also there are some symptoms that indicate about possible infection:

  • First and most common form of notice includes third party notifications. Your visitors will see a warning when they try to visit a site from the search results pages. Also they could see a warning of their antivirus software upon visiting your site. If you or other people try to visit your website but get automatically taken to some other website instead, it’s another symptom of being hacked. Surely you’ll soon receive a phone call or email that will tell you about the infection.
  • Another (indirect) symptom of possible infection is a sudden decrease of visits from search engines.
  • Your site appears in search engines using absolutely irrelevant search terms.
  • Your site could become less responsive. It takes longer to load web pages.
  • Your site or some particular web pages have been removed from search engines.
  • You notice strange files at your site that you didn’t put there.
  • Last but not least, your AdSense account is blocked.

If you encounter one or more of these symptoms there might be a chance your website is hacked. There are some tools and services that let you check your website for malware or help to monitor your site’s status on a periodic basic. More on these tools will be in the upcoming posts.

Web Application Scanners comparison – is more expensive always better

Tools - expensive or free?

Tools – expensive or free?

Web application security scanners can cost from a hundred to tens of thousands of dollars. And they can be free as well. There are many tools or apps that can be used in web application assessments. It could be very hard to decide which tool is the right one. Some of them are better used alongside a manual test, where others are more designed for non-security specialist IT staff as more “black box” scanning tools. On top of that there are scripts and point-and-click tools that can be used to assess specific areas of web application security.

So when considering specific scanner first of all you should answer such questions as:

  • Do I need comprehensive scanner for testing whole web application or just a scanner that is good at some specific area? This relates to other question: many scanners vs one.
  • Am I going to play with setup, parameters, request manipulation or do I need a simple so called point-and-click tool?
  • Will I use this scanner for actually exploiting web application?
  • What kind of reporting I want?
  • And finally: am I going to pay for it?

The best way to choose appropriate scanner is to play with it. Then you see if it fits your needs or not. After testing multiple scanners, tools, scripts you’ll get experience and intuitively see what is good and what is not, what suits for one situation and what for another, etc.

Scanners comparison charts could also serve as a good point of reference. Tools are benchmarked on how they are able to detect (in some cases – and exploit) security vulnerabilities. Usually scanners are compared on certain points:

  1. How much vulnerabilities they managed to detect on specially crafted web application?
  2. How much manual input was required?
  3. False positive rate (scanner indicates a vulnerability when actually it doesn’t exit)
  4. False negative rate (missed vulnerabilities) – inversely proportional to first point.
  5. How much time it took to scan an application?

By looking at some comparison charts it’s clear that the most expensive scanners are not necessary the best in all situations. As a rule of thumb, expensive scanners have many features, full scan coverage (in terms of types of vulnerabilities, scanning methods, etc.), nice looking user interface and great reports.

Free open-source web application scanners, on the other hand, usually are harder to configure, have poorer GUI and miss good reporting capabilities. However, their vulnerability detection rate could be the same or even better than their commercial counterparts.

Shay Chen has a great blog post where he compares 60 (!) commercial and open-source black box web application vulnerability scanners.

Looking at the comparison charts we can see that open source tools presented very good results. Indeed, some of them are at the top in the charts. As Mr. Chen concludes, “the distance between open source tools and commercial tools is not as big as it used to be”.

However, it was also mentioned that open source tools tend to have more false positives and be relatively unstable when compared to most commercial tools. Besides, open source tools are usually more difficult to install and use, and still require fine-tuning in various fields.

So if your background is rather technical, you can safely use open source tools with great success. However, if you don’t have much technical experience and don’t want to learn all the bits and pieces and prefer decent usage experience – stay on the safer side and use commercial products (some have free limited versions).

The good news is that if you have limited budged and still want to do vulnerability assessments or pen-testing, you won’t be left alone. There is a wide variety of open-source tools that are not worse than their commercial alternatives – all you need is to put some more work into it.  We’ll present some How-To’s and recommendations regarding specific tools in future articles.

For better results it’s common to combine various tools – from both commercial and open-source sides. One tool might be easier to use, another one might be more accurate, third one – faster. Mix everything and see what works and what not.

Good look!

Vulnerability Assessment vs Penetration Testing

Vulnerability Assessment vs Penetration TestingUsually when we talk to our clients we notice some confusion regarding terms vulnerability assessment (VA) and penetration testing (or pen-testing). Terms are also confused in blogs, job descriptions, presentations, etc.

Term penetration testing is usually used instead of vulnerability assessment (and NOT wise versa). Maybe that’s because penetration testing sounds cooler. But usually what people actually want is vulnerability assessment, not penetration testing.

Vulnerability assessment consists of assessing and documenting the possible vulnerabilities and recommend mitigation measures and improvements.

Penetration test has a broader scope. It consists of vulnerability assessment, but goes one step further. It usually involves active exploitation of security vulnerabilities found during VA phase.

Vulnerability assessments are what most companies generally do, as the systems they are testing are live production systems and can’t afford to be disrupted by active exploits which might crash the systems. Most commonly what’s required is not more than to assess and document the possible vulnerabilities and recommend mitigation measures and improvements.