Blog: Canadian Government Web Security Problems
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
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)
- 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.