This article was originally published on 24 June 2010 on newmatilda.com.

Earlier this week, the Standing Committee on Communications tabled a report on its yearlong inquiry into cybercrime. The report, headed Hackers, Fraudsters and Botnets: Tackling the Problem of Cyber Crime makes 34 recommendations aimed at improving computer security in Australia. One of them in particular — a proposed industry code requiring Australians to install and maintain antivirus and firewall software to access the internet — has sparked some debate.

To assess the merits of that recommendation, it is necessary to understand how ISPs are presently (mostly not) regulated in the area of cyber security, and what exactly the report proposes to change.

The Internet Industry Association (IIA), a group representing ISPs, is largely responsible for writing the codes that regulate them. In relation to cyber security, the IIA recently released a voluntary code of practice titled icode. Among other things, this code lists a number of steps that ISPs may take when they become aware of malware-infected machines on their networks (such as notifying the user or disconnecting the user from the internet), but it leaves it up to the relevant ISP to decide which course of action is appropriate in the circumstances.

The current code is thus doubly voluntary. First, the code itself is voluntary, so ISPs can choose not to comply with it at all, and, second, ISPs that choose to comply with the code are not required to take any particular steps in relation to malware-infected machines on their network. That is, the current code does not provide for any mandatory steps to be taken in relation to malware-infected machines on ISPs’ networks. And in no way does it require users to install and maintain antivirus and firewall software.

The first thing that the new report proposes to change is to have an industry code that is registered. The Australian Communications and Media Authority (ACMA) presently has a power under the Telecommunications Act 1997 (Cth) to register industry codes that deal with certain things. Where such an industry code is registered, ACMA can direct an ISP to comply with the code. Failure to comply with such a direction exposes the ISP to a civil penalty of up to $250,000 per breach. A registered industry code is thus effectively mandatory.

Next, if the recommendations were adopted, ISPs would be required to take certain mandatory steps when malware-infected machines are found on their networks. Specifically, they would be required to notify the relevant users and implement graduated access restrictions (including disconnection) until the relevant machines are cleaned. Importantly, the report does not propose to require immediate disconnection of users whose machines are infected with malware, but rather a graduated response, where disconnection would presumably be the last step. This is important in particular because removal of malware often depends on the installation of up-to-date antivirus software, which is usually obtained online.

Most notably, though, the proposed code would require ISPs to include a contractual term in their acceptable use policies requiring users to install and maintain antivirus and firewall software before accessing the internet. It is this requirement that has raised the most eyebrows.

The most readily apparent problem with this recommendation is that enforcement would be impractical. The proposed code would require a new term in the contract between the ISP and the user, which could only be legally enforced by the ISP (and not, for example, by ACMA). It is not clear whether ISPs would be motivated to enforce these new contractual obligations. Most ISPs’ acceptable use policies currently prohibit the use of their services to infringe copyright, yet as the content industry will tell you, ISPs have not exactly been zealous in policing that part of their policies.

But even if the code required ISPs to actually enforce their contractual rights, for example by disconnecting users who did not comply, it would not be practical for ISPs to verify that their users have up-to-date antivirus and firewall software installed. Arguing that ISPs could manage this task, prominent cyber-security consultant Alastair MacGibbon has made the following point:

There is software available which could be on end-user machines that would allow my ISP, as I log in, to check that I have my firewall turned on, that I have an antivirus that they approve or recommend installed on my computer, and that my operating system and browser are patched — and if those things aren’t met then [my ISP would not] give me [access].

However, such software only works with certain antivirus and firewall products and only works on certain operating systems. And it would put ISPs in the position where they would have to approve particular antivirus and firewall software before users could use it, significantly limiting consumer choice. Approaching the issue of computer security this way appears to create more problems than it solves. Should ISPs be allowed — let alone forced — to dictate what antivirus and firewall products their users may use and what operating systems they may run? And should users be forced to install software from their ISPs that reports back what software they are running to their ISPs?

The other problem with the recommendation is that it is not clear what exactly users would be required to do to comply with these new contractual obligations. Would antivirus and firewall software need to be installed on all devices connected to the user’s network? Antivirus and firewall software for iPhones and iPads, for example, is not available or even possible presently. And there are many other devices for which such software is not as readily available as it is for Windows, including computers running Mac OS X and Linux (arguably because those devices do not need them to the same extent).

The question which then arises is whether any of this is really necessary. Most broadband connections are already provided using a modem-router that doubles as a firewall, and Windows itself (like most other operating systems) already includes a firewall that is on by default. While comprehensive antivirus software is not included with Windows itself (or most other operating systems), free solutions, including Microsoft Security Essentials are readily available. It is not clear how including a contractual term that most users will never read would be any more effective at encouraging use of appropriate security software than would educating users about the need for such software at the time they are provided with internet access (and perhaps via periodic reminders).

Notwithstanding the somewhat controversial recommendations discussed above, it is worth mentioning that the report does cover a lot of ground and makes many other good recommendations. They deal with three areas: aggregation and distribution of data about cybercrime, updating criminal and civil enforcement laws, and educating the public about computer security.

The report recommends setting up coordinated systems to gather and share information about cybercrime, with the aim of using that information to improve responses to online threats. Among other things, this would include developing a reporting system aimed at consumers and small and medium sized businesses, consisting of a centralised portal for reporting cybercrime (including malware, spam, phishing, scams, identity theft, and fraud) and a 24/7 reporting and helpline.

Criminal laws dealing with cybercrime would be reviewed and updated where necessary, and the Australian Consumer Law would be amended in two notable ways. First, consumers would gain a specific right to sue for unauthorised installation of software that monitors, collects, and discloses information about consumers’ activities (ie, spyware). Second, consumers would gain a right to sue a manufacturer for loss caused by a product that was released onto the Australian market with known security vulnerabilities.

Finally, and perhaps most importantly, the report sets out steps to improve community awareness of computer security issues. It does this in two ways. First, the report proposes a ‘public health style campaign’ to deliver messages about computer security issues as well as appropriate behaviours and technical precautions that users should take. Second, the report recommends specific changes to the law requiring, for example, the provision of security information about certain products (such as computers and routers) to users at the point of sale, and requiring also that certain products be designed to prompt and guide users to choose more secure settings (such as setting strong encryption on your wireless access point to secure your network).

While the report contains certain controversial recommendations, that’s normal for reports like this one. Meanwhile the many reasonable recommendations the committee makes — in particular the points about educating users — are a valuable contribution and deserve consideration.

Senator Stephen Conroy jumped the gun by 107 days, announcing that the Government would table legislation to mandate filtering of RC content hosted outside Australia during the autumn 2010 parliamentary sittings.

Depending on the technology, you can bypass the filter by changing your DNS servers, using an encrypted VPN service, or installing Tor (among other solutions). But some of these workarounds can take up to 60 seconds to set up. And using an encrypted tunnel, like a VPN or Tor, will slow your access while you’re using it.

Thankfully, you can also bypass the proposed mandatory filter more conveniently. Just add ?NoCleanFeed or &NoCleanFeed to the end of the blacklisted URL. If the URL doesn’t already contain a ?, add ?NoCleanFeed to the end. If it does contain a ?, add &NoCleanFeed to the end.

For example, if you try to access www.bannedsite.com/page.htm, but you’re blocked, try accessing www.bannedsite.com/page.htm?NoCleanFeed.

If you want to watch a YouTube video that was deemed too shocking for Australian citizens, like www.youtube.com/watch?v=tMiEagk2qN8, you can just try www.youtube.com/watch?v=tMiEagk2qN8&NoCleanFeed instead.

Why It Works

The proposed mandatory filter is to block individual pages containing RC content, and only those pages. It will not block all traffic to a particular IP address or to a particular website. That is, when www.youtube.com/watch?v=tMiEagk2qN8 is inevitably blacklisted as RC content, access will only be blocked to that URL, and not to any other page on www.youtube.com.

That means that you can still view Government-approved YouTube videos, like www.youtube.com/watch?v=03OJvZhU-3M.

To get that result, the filter must block access only where the host and path in the URL (the part before any ?) and the query string (the part after any ?) all match the blacklisted URL. If the filter blocked access where only the host and path matched, all YouTube videos would be blocked when any YouTube video was blacklisted because the host and path for all YouTube videos is the same (www.youtube.com/watch).

Web servers, however, normally ignore unrecognised query string parameters. For example, YouTube looks for a v parameter, which contains the ID of the video to play. You can also optionally specify a fmt parameter to specify the desired video format. And there are several others that YouTube understands. Changing these parameters will change the page that YouTube returns.

But if you pass YouTube a parameter in the query string that it doesn’t recognise, like NoCleanFeed or some other arbitrary string, it will just ignore it, and display the same content as if it were absent. But since the URL is no longer the same as the blacklisted URL, the filter won’t block it.

The same is true for most other web servers. For example, try www.google.com/search?q=test and www.google.com/search?q=test&NoCleanFeed. You should get the same page both times (though ads and other dynamic content may change).

When It Won’t Work

Most servers will ignore unrecognised query string parameters, but not all will. Where the server doesn’t ignore unrecognised parameters, you may get an error or an unexpected page. In that case, you’ll have to fall back to one of the other methods for bypassing the filter.

And, of course, if all else fails, you can still send your favourite RC content by carrier pigeon. It’s faster than Australian Internet access anyway.

A couple of days ago, Wired reported on the questionable use of Flash cookies revealed by a UC Berkley study. While non-novice Internet users are generally aware of cookies and their implications, fewer users are aware that Adobe’s popular Flash plugin stores its own cookies separately from normal browser cookies.

If you’re using Mozilla Firefox, you can use the BetterPrivacy add-on to automatically delete all of your Flash cookies each time you close your browser. You can also configure BetterPrivacy to delete the cookies every few minutes. Or to allow you to manually delete them using its interface.

If you’re using Internet Explorer, Chrome, or another browser, you can also use the Flash Settings Manager found here. It’s a good idea to browse through this anyway, as it contains some handy privacy settings (including the ability to disable Flask cookies entirely).

And, for Mac OS X, there’s Flush.app.

Last week, Forensic Innovations Inc announced on its blog that it has a tool that can identify headerless encrypted data, such as TrueCrypt volumes. Yesterday, this story was picked up by Slashdot.

Good ciphers, like AES, output ciphertext that is computationally indistinguishable from random data. An encryption tool that properly implements such a cipher to generate headerless encrypted data will also produce output that is computationally indistinguishable from random data.

For Forensic Innovations Inc’s tool to work, it would have to be able to distinguish between random or pseudo-random data and the output of ciphers like AES. I ran a quick test to see whether it could. It can’t.

I downloaded a trial copy of FI TOOLS for Windows 2.23. I then generated two 10 MB files filled with pseudo-random data. I used a PowerShell script to do this:

The first file, random-1.dat, is filled with pseudo-random data generated by the System.Random class from the Microsoft .NET Framework. This class provides a very weak random stream. It should be distinguishable from a truly random stream.

The second file, random-2.dat, is filled with pseudo-random data generated by the System.Security.Cryptography.RNGCryptoServiceProvider from the Microsoft .NET Framework. This class provides cryptographically strong pseudo-random data that should be computationally indistinguishable from truly random data.

Finally, I created a third file, random-3.dat, which was a 10 MB headerless TrueCrypt volume created using the default settings and using a strong random password.

Here is the result:

As you can see, the tool identified each of the files as headerless encrypted data. Only random-3.dat was actually headerless encrypted data. In other words, the tool cannot distinguish between pseudo-random data and headerless encrypted data.

On 26 March 2009, the Classification Board website was hacked, and the text on the homepage was replaced. The altered site was available for around three-and-a-half hours before it was taken offline. And, five days later, a placeholder page was posted.

Today, nearly a full month after the site was hacked, the site is now back online:

The entire website appears to have been overhauled. Most notably, the design and layout of the site has been updated. Presumably, attention was given to security too.

While I hadn’t spent much time on the old Classification Board website, the new site appears to be an improvement. It’s certainly better than the Courts Administration Authority of South Australia website, which is still firmly lodged in the ’90s.

On 20 March 2008, I wrote about CommSec’s use of non-SSL frames pages for its online banking. Although the CommSec homepage is delivered using SSL with an Extended Validation Certificate, once you log in you’re presented with a non-SSL frames page:

gHacks posted recently that you can use NoScript, an add-on for Firefox, to force the browser to use HTTPS for specified domains. You can use it to force CommSec to use HTTPS too.

To do this, download NoScript from here. Open the options for NoScript and go to the HTTPS sub-tab on the Advanced tab. Under ‘Force the following sites to use secure (HTTPS) connections’, enter ‘*.comsec.com.au’:

Now, the CommSec website should always use HTTPS:

You can use this same method to force other websites to use HTTPS too, like Facebook or Twitter.

Remember, though, that NoScript’s primary function is to block scripts and other active content found on most websites. This is useful for security conscious users, but it’ll break most websites.

If you want to force certain websites to use HTTPS but don’t want to block scripts or other active content, you have to disable that blocking in the NoScript options.

Update: It turns out that forcing HTTPS connections for *.comsec.com.au breaks some functionality. Forcing HTTPS connections for only www.comsec.com.au achieves the same goal, but without breaking anything (that I know of):

The reason why *.comsec.com.au doesn’t work is that CommSec doesn’t support HTTPS connections to prices.comsec.com.au. So when you try to get a stock quote, your browser will attempt an HTTPS connection, which will fail.

Now, quotes should work, but they will be delivered over HTTP. And your browser will give you a warning to that effect.

Three versions of the ACMA blacklist have leaked to Wikileaks. Then it was revealed that anyone could extract the blacklist from the Integard filter in a 30-second hack. Now the Classification Board website has been hacked:

The text on the homepage has been replaced with the following:

This site contains information about the boards that have the right to CONTROL YOUR FREEDOMZ. The Classification Board has the right to not just classify content (the name is an ELABORATE TRICK), but also the right to DECIDE WHAT IS AND ISNT APPROPRIATE and BAN CONTENT FROM THE PUBLIC. We are part of an ELABORATE DECEPTION from CHINA to CONTROL AND SHEEPIFY the NATION, to PROTECT THE CHILDREN. All opposers must HATE CHILDREN, and therefore must be KILLED WITH A LARGE MELONS during the PROSECUTION PARTIES IN SEPTEMBER. Come join our ALIEN SPACE PARTY.

Wouldn’t it have been ironic had the hackers elected to post the leaked ACMA blacklist on the site and then report the site to ACMA?

Update: The first report of the hack was made at around 8:00 pm AEDT on 26 March 2009. At around 11:30 pm AEDT, the site started returning HTTP status code 400, ‘Bad Request’. On 29 March 2009 at around 3:00 pm AEDT, the site started refusing connections altogether.

Now, on 31 March 2009 at around 6:40 pm AEDT, the site is now back up, albeit showing only a temporary placeholder page.

Near the head of the page is this:

Important note: We are currently upgrading our website and some features are temporarily unavailable. We apologise for any inconvenience caused.

It took five days to get to this stage.

Update: On 24 March 2009, nearly a full month after the site was hacked, an overhauled version of the site is finally back online.

In June 2008, CommSec introduced an integrated banking and trading solution. The idea is that you can do all of your securities trading and all of your banking using the one website. And you get a tastefully designed CommSec Debit MasterCard too. Why wouldn’t you sign up?

Logging In

You arrive at the CommSec website. You’re greeted by the CommSec homepage sitting comfortably underneath a green address bar.

Protected by an Extended Validation Certificate, you enter your Client ID and password. You’re taken to the next page.

Your browser prompts you to remember your password. That’s okay, though, because CommSec uses a second password, one that you can’t save, when you actually want to execute a financial transaction. But what else is missing?

Oops. We’ve lost the SSL. And this appears to be by design.

By Broken Design

CommSec uses frames. The navigation bar is in one frame and the content is in another. The content frame uses SSL only when the content is sensitive. For example, it uses SSL when displaying account balances, but not when displaying market prices.

But the parent page and the navigation frame never use SSL. Since the link to, say, ‘Cash Management’ is itself on an unsecured page, a man in the middle can change the link to point anywhere.

That means you never know where you’ll go when you click ‘Cash Management’. And since you never know (without some serious digging) whether the content frame is at the www.comsec.com.au domain and whether it’s using SSL, you’ll never know whether it’s safe to enter your details there.

Mitigating Factors

CommSec’s site has some characteristics that make man-in-the-middle attacks more difficult. First, the authentication cookie is an SSL-only cookie.

A man in the middle cannot, therefore, acquire that cookie. He or she would need to use some social engineering to get your credentials. For example, the man in the middle could prompt you for your Client ID and password. You’re likely to trust such a prompt, since you came to the site independently and CommSec does itself prompt for such confirmation.

The second mitigating factor is that CommSec uses (optional) SMS security. Whenever you make a payment to a third party (and in certain other circumstances), CommSec will send you a one-time code to your mobile phone.

But, again, social engineering should work. The man in the middle can merely ask you for the code when you go to check your balances, or your details, or when you attempt to perform some transaction.

Conclusion

Delivering sensitive information over HTTPS within an HTTP frame is just bad design. It hides the nature of the connection from the user, who then has no way of telling whether the information is being sent securely or not.

From the perspective of the user, an attack might look like this: they type the CommSec URL, making sure to include ‘https://’. They see a green address bar. They login. They’re taken to an HTTP page (as they always have been). They click the ‘Cash Management’ link, but they’re prompted to confirm their identity first by entering their details and then an SMS code. Having no reason to suspect the site, having accessed it over HTTPS with a green bar, they enter their details. They’re taken to their cash management page. Only now there’s several thousand dollars missing.

I understand that there are performance considerations for delivering market data, charts, etc over SSL, but this kind of design is unacceptable. It confuses already confused users, making social engineering too easy.

Steve Gibson would roll over in his grave, if it weren’t for the fact that he’s still alive doing a great security podcast.