Symantec found that the average number of security threats on religious sites was around 115, while adult sites only carried around 25 threats per site–a particularly notable discrepancy considering that there are vastly more pornographic sites than religious ones. Also, only 2.4 percent of adult sites were found to be infected with malware, compared to 20 percent of blogs.

In (related?) news, the University of British Columbia reported a study showing that encouraging people to use their analytic thinking skills causes a reduction in religious belief, even in pious persons.  Unfortunately, the study did not touch on whether the reduction in superstition was tied to increased use of, ahem, adult sites.

Here's where playing Farmville at work will get you...

This week, the Ninth Circuit US Court of Appeals ruled on a case which has an important impact on us information security types: US vs. Nosal.

Nosal was employed by recruiting firm Korn/Ferry.  He left the firm to start his own, competing firm.  After he left, he persuaded some of his Korn/Ferry colleagues to access confidential information owned by K/F and provide it to him.  The K/F employees had access to the information as part of their work for the company, but were violating company policy in providing confidential information to a third party.  When Korn/Ferry discovered the theft of information, they initiated legal proceedings against Nosal. In addition to suing him for civil damages, they filed a criminal complaint stating that he had “aided and abetted” the Korn/Ferry employees in violating the Computer Fraud and Abuse Act of 1984 by encouraging them to “exceed their authorized access to” Korn/Ferry computers.

Let’s stop here for a moment… what Nosal and the Korn/Ferry employees are alleged to have done was clearly wrong, and Korn/Ferry would be entitled to fire the employees and recover civil damages from the whole lot of them (IMHO).  The question here is whether Nosal or the employees committed a federal crime which could lead them to jail time.

The Appeals Court did not agree with Korn/Ferry (and the federal prosecutors on the case).  In its opinion, the court pointed out that the K/F employees were allowed to access the data in the course of their work, and thus did not “exceed their authorization” and that when they passed on the information to Nosal, they were in breach of their (civil) responsibilities of their employer.  The court went further and said that interpreting the CFAA in the broad way advocated by Korn/Ferry and the prosecutors would make many very common behaviors federal crimes.

In particular, the court felt that the wider interpretation would make violation of corporate computer use policies and terms of service for Internet services criminal acts.  For example, an employee who spent time shopping, playing games, or reading the sports pages online at a company with a computer usage policy limiting use of corporate systems to business use could find themselves in the “big house.”  Now, as a corporate security professional, even I think that this is a bit excessive; corporate policy violations should lead to disciplinary actions and/or termination of employment, but prison time seems just a wee bit excessive to me.

The court also pointed out that criminalizing such a wide range of common behaviors would lead to a situation where the law would be applied inconsistently and arbitrarily.

There was a dissenting opinion, which contended that the ultimate use of the data (theft and providing it to a competitor) in and of itself was “exceeding authorized access.”  The dissenting judge used the example of a bank teller’s access to their employer’s cash.  The teller is authorized to access the cash in the course of doing their job, but would be exceeding their access should they access the cash to take it for their own use.  I am not convinced by this argument, as the taking of the cash is a separate act which is criminal in and of itself.

In any case, this court has said that federal criminal law is not meant to help companies enforce their computer usage policies and that violation of those policies is a civil matter between employer and employee.  This seems like a reasonable decision to me.

The court’s decision is worth a read – it was refreshing to read a decision which shows awareness of how the Internet is used in real life.

It looks for and removes FlashBack

It requires users to specifically enable Java on their systems

It automatically disables Java if no Java applets are run for “an extended period” – some bloggers are stating that this period is 35 days.

I’m glad Apple is taking these steps – if users are not using Java, disabling it will protect them from the rising tide of Java based malware that is out there.  I just hope that the process for re-enabling Java when needed is made easy for the non technical user.  It would be nice if Apple added a feature to “Software Update” which would be a little more proactive in nagging users to install security related updates as well.

No, this is NOT HP's latest printer...

So, remember a few weeks back, when the tech press got really silly, warning us that hackers could set our HP printers on fire remotely?  Well, it turns out that there was a security story about HP printers, but the press really missed the boat on what was actually important.  At the 28th Chaos Communications Congress (held in Berlin last week), the Columbia University researchers whose work was totally misconstrued by the press presented their work.  No, hackers cannot set your printer on fire – but they can install malware on hundreds of millions HP printers shipped since 2005, either by connecting to the printer and replacing its normal firmware with evil firmware or by getting one of your users to print out a specially crafted document which also carries their nefarious code.  Once this hack is done, your printer will become a silent (but deadly) bridgehead into your network.

UPDATE:  Here’s a list of all of the printers affected by this vulnerability.

The researchers had two demos.  In the first, they caused the infected printer to silently send a copy of every document it printed to an attacker’s printer out on the Internet.  Demo two had the infected printer acting looking for internal systems vulnerable to a Windows XP exploit and then acting as a relay for the attacker to control them from outside the firewall.  This was pretty scary stuff… let’s say I send a crafted document purporting to contain a 50% off coupon for a local restaurant to your users… how many times (and on how many printers) would this get printed?

This hack is made possible by the fact that some HP printers allow their firmware to be updated without any authentication or digital signature and that all of the code within the printer runs as a super user.  It also points out the need for anti malware protections for embedded devices like printers, routers and the like.  The guys at Columbia are working on a project to do this.

As an aside, these same researchers scanned the Internet for accessible HP printers – they found over 75,000 of them, located at private companies, governments, educational institutions and in other places.  Infecting just a small percentage of these systems would provide someone with a very stealthy botnet that would be extremely difficult to remove.  The researchers feel that it may be possible for the attackers to install their code permanently, so that the only ways to get rid of the infection would be by replacing (soldered on surface mount) hardware components or trashing the printer altogether,

So… what to do?

First, update your HP printers’ firmware to the latest (December 2011 or later) firmware version, which can be found over on the HP support website.  The new drivers require printer firmware updates to be digitally signed by HP.

Next, make sure that your printers cannot be accessed from the Internet.  For most of my readers, I don’t think this will be an issue, but you never know… scan your Internet facing IPs for port 9100, which is used to submit print jobs and firmware updates to HP printers.

Third, limit where your printers can send traffic to… is there any good reason to allow a printer outbound access to the Internet?  Not that I can think of.  Putting printers on an isolated VLAN which can ONLY talk to the print server limits the damage that can be done using this attack.  Of course you really need to make sure that your print servers are patched and properly isolated as well – and when eas the last time you took a look at your print servers?

We’ve all got some work to do, people but more importantly, we need to look at embedded systems like printers, routers, access points, and the like in a new way – as potential malware targets with the computing power to take down our networks and no antivirus protection.  I can just about guarantee that the bad guys will be researching this in 2012 – it is just too juicy a target to ignore.

If you are a security pro or are responsible for printers in your organization, I’d recommend spending an hour watching the video of this presentation to get the full story.

Happy New Year, all.

OK… this story is a bit older than that movie… but it is even cooler – hacking 1903 style for the lulz!

Doesn't that look tasty...

When Microsoft comes out with an out of cycle security advisory (and during a holiday week, no less), you know something big is up.  This week’s bulletin highlights a denial of service attack and two privilege escalation vulnerabilities that affect web sites built on top of ASP.NET.   The most serious privilege escalation vulnerability could allow an attacker to execute commands on a system by sending specially crafted web requests.

The denial of service issue is related to a flaw in the way that ASP.NET (as well as PHP, Ruby and Java) handle the hash tables which are used to pass information from user web inputs to the web server.  By sending specially crafted requests to vulnerable web servers, it is possible to tie up all of their CPU resources and make them unavailable to legitimate users.  This attack was revealed at this past week’s Chaos Communications Congress in Berlin – you can watch the presentation here.

There is a very good technical description of the DoS problem and attack here.

The DoS flaw is also present in PHP, Python, some Java web frameworks, and Ruby.   Apache Tomcat 7.0.23 contains a workaround fix which limits the number of parameters accepted in a POST request.  PHP version 5.4.0 will include a workaround fix for this problem, but is not yet ready for production use.   Ruby version 1.9 and higher has a fix which solves the problem by randomizing the hash tables.

Given the recent ‘hacktivist’ activity we have been seeing, it would not surprise me if this attack was used against sites in the financial industry as well as in the public sector.  In any case, the Microsoft patch is a must for your web facing ASP.NET systems now.  The US-CERT’s vulnerability page for this issue is a good place to keep track of vendors’ responses as more platforms are found to be vulnerable.