One of the reasons given about why the government should worry about open source software is security.  I'm rather tired of this argument, so after hearing it one too many times, I decided to take some action. 

The concern is that if a piece of software is open for everyone, including hackers, it will be more vulnerable. This has been shot down any number of times, with some of the best known arguments stemming from the idea that many eyeballs will give you better confidence in the security of your software. Others security experts that have argued that good open source software is as secure as proprietary software and will likely have fewer bugs. 

However, most arguments are looking at security on an application level rather than a system level. When looking at websites, you have to look at all of the elements which a hacker can gain access to, not just a single application. 

It is well known that every software project will eventually have security issues that need to be addressed through patches or newer releases of the code.  If there isn't a techie with authority, time and knowledge to apply those security patches in a reasonable time-frame, then you won't have a secure site for long.

If there aren't good practices for managing backups, removing old or unnecessary files, striping out files and minimizing the information which is guessable on your website, then there will be security risks.  A determined hacker can learn a lot about an organization by analyzing stray pieces of ASP code from an old backup. 

Custom built applications or proprietary tools built with a small user base are also huge security risks, because in most instances there aren't the security professionals available to continue to monitor a piece of software.  Security standards and threads are changing all of the time, as are the languages which web applications are written in. 

As I discussed in a previous blog post, there are over 7 million dynamic pages (.php, .asp, jsp, etc.) within the gc.ca domain.  Each of those 7 million pages may have one or more security issues.  Using a unified CMS like Drupal would significantly reduce the security risks for the Government of Canada because it would significantly cut down the number of access points.

Because there is a security community built around Drupal (and the other open source software that it works with), the software out of the box is more secure than most government websites (based on a small sample).  Given the lack of internal auditing for security practices within the government, migrating sites over to Drupal is going to be the most cost effective way of addressing both the security issues posed to government data as well as to the users of the government websites. 

The Canadian Government does have some policies on this front, the Operational Security Standard: Management of Information Technology Security (MITS), is a start.  However, clearly there's a gap between policy & practice.

So I picked some sites, largely through Netcraft's list of gc.ca servers and then targeted them with a Grendel Scan of their security. I'm not going to list which sites I selected for obvious reasons, but I have notified all of them and provided details of the potential security issues. I am not all that hopeful that I will get any responses from my emails. 

I had reports of:

• Outdated software was detected
• Various FrontPage files that could be used to gain information about the server or attack it
• IIS files shows http links on and off site which might show host trust relationships and other machines on network.
• TRACE option enabled which could allow XSS or credential theft.
• A Frontpage counter CGI & imagemap.exe can be a source of security vulnerabilities
• FCKeditor file upload scripts which could be edited by remote attacker
• Many backup files located for a wide range of file types

Other Reports & Descriptions from Grendel Scan

I decided to include the full description (hiding some of the site specific data) that was provided by the scan of government sites.  Mostly, this is because it provides readers with a sense of what is at stake but also what acronyms like CSRF mean and why things like IP address leakages & proxies might be a concern. 

Private IP address leakage

Private IP addresses defined by RFC 1918 are not rout-able on the Internet, but are frequently used on Internet-exposed devices and then changed by Network Address Translation (NAT).

Knowing the private IP address of a server can help an attacker to craft better attacks against internal assets.

Proxy server detected

The web server is also acting as a proxy server. A CONNECT command was issued for "grendel-scan.com:443". The response code was 200, indicating a successful connection. Note that this test is not very sophisticated right now, and should be manually confirmed.

An attacker might be able to access web servers through the proxy server that would otherwise be blocked by a firewall. If the CONNECT method is supported, any TCP protocol can be tunneled.

HTTP debug method was enabled

The TRACE/TRACK method was enabled on the server

An attack known as Cross Site Tracing (XST) leverages this method to steal cookies. Once a session key in a cookie is obtained by an attacker, he can hijack a legitimate user session.

Similar session IDs detected

The cookie named sessionID appears to be used to track session state. A minimum of 128  bits of random data is generally recommended

If the session ID is generated in a predictable manner, an attacker could hijack legitimate sessions by guessing the session IDs of authenticated users.

Potential CSRF detected

One or more cross-site request forgery (CSRF) vulnerabilities may have been identified. CSRF allows an attacker to force a user to execute arbitrary commands against the vulnerable website. This is possible when the structure of the command is predictable. If the command can be requested as a GET, then a simple IMG tag on an attack website can force the browser to send the command. A POST request can be sent using some simple JavaScript. The browser will send any cookies or authentication credentials associated with the targeted attack, because it has no way of knowing that the request was not intentionally executed by the user.

A list of queries that appear to be vulnerable to CSRF is below. A specific form may be found on multiple pages, but was only tested once.

Cross-Site Scripting (XSS)

When the attack string was supplied as the parameter value, it appears to have been placed in the results in a way that allows arbitrary JavaScript to be executed. A unique token was used for tracking purposes during testing.

Note that some test attacks use a fictional JavaScript function (testXSS) for testing. This is because some anti-XSS filters will block common JavaScript functions (e.g. "alert") by name. This is not a sufficient security control; the fictional function allows the test to proceed more rapidly than testing multiple real functions. Other test attacks use a fictional hostname (notreal.fake) or a fictional IP address (123.321.1.1) for testing. To perform an actual XSS attack, replace it with the name of a host that you control.

Cross site scripting can (XSS) is a vulnerability that allows an attacker to insert arbitrary web content (HTML, JavaScript, etc) into an otherwise legitimate page. Because the URL is still on the targeted website, a user may consider it to be a trusted link. This can be leveraged to perform many attacks, such as:

• Reformatting the page to appear as a login page, but with the credentials sent to the attacker
• Sending the users session key to the attacker, allowing for session hijacking
• Forcing the users browser to send attacks to other websites
• Logging the users keystrokes 

Before using any data (stored or user-supplied) to generate web page content intended to be simple text, escape all HTML meta characters.

Possible SQL Injection

When a single quote (') was appended to the parameters listed below, a SQL error message was returned. This could indicate a SQL injection vulnerability.

SQL injection can allow an attacker to obtain the information stored in your database. Under some circumstances it can also allow for arbitrary command execution on the database server. 

Directory traversal vulnerability

A possible directory traversal vulnerability was detected in the "FN" parameter. The original value of the parameter was "contact.htm". When the value of ".contact.htm" was used instead, it appears that a different page was returned, perhaps an error message. When a value of "./contact.htm" was used, it appears that the response matched the original request. This implies that the parameter is vulnerable to directory traversal attacks. However, this test may be prone to false positives, so further investigation is recommended.

Depending on the function of the page, directory traversal attacks might be used to read or execute arbitrary files already on the server.