...but you do have to give up your passwords

Interesting and depressing post from Ars Technica:

A federal judge has ruled that a Colorado woman can be compelled to decrypt her encrypted laptop so that the police can inspect it for incriminating evidence. The woman, Ramona Fricosu, is a defendant in a mortgage scam case. She had argued that the Fifth Amendment’s privilege against self-incrimination protected her from having to disclose the password to her hard drive, which was encrypted using PGP Desktop.

The rest of the sordid details can be found here.

It seems to me that forcing someone to reveal a password to  a computer which might contain incriminating documents should be construed in the same way as forcing them to provide other self incriminating testimony.   Just saying…

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.

Tasty snack... or identity theft tool??

From the “you can’t make this stuff up” file…

Cars of the future may use the driver’s rear end as identity protection, through a system developed at Japan’s Advanced Institute of Industrial Technology. A report surfaced earlier this month that researchers there developed a system that can recognize a person by the backside when the person takes a seat. The system performs a precise measurement of the person’s posterior, its contours and the way the person applies pressure on the seat. The developers say that in lab tests, the system was able to recognize people with 98 percent accuracy.  

To get to the bottom of this story, read more here.

oops - wrong Java!

I hate Java.  Not the country or the beverage, but the programming language.  Actually, not so much the language, but the way that it is used and distributed to PC and Mac users.  A recent report from Microsoft stated that between one third and one half of the malware that they saw between 3Q 2010 and 2Q 2011 was written in Java.  Java is a natural target for malware writers – it is cross platform and is installed on just about every computer used to connect to the Internet.  Java is a force multiplier for the bad guys.   Like any other software, the Java Runtime Environment (JRE), which allows Java applets to run on your computer, has its share of security flaws which are then exploited by attackers.  Recently, one “pernicious” Java exploit which had only been available for purchase in the “computer underground” was made available in the Metasploit toolkit, which allows less skilled attackers to use it to craft their attacks.

If you are reading this on a computer that you own personally, stop right now and make sure that you are running the latest version of Java and other browser plugins on your system – Qualys has a nice site which does this for you automatically.  Go ahead, I’ll wait…

In enterprises, upgrading Java is not as easy as it would seem.  Many applications used by business were written with a particular version of Java in mind and they will stop working if you do the “right thing” and upgrade the JRE.  As a result, many organizations are stuck with old and vulnerable versions of Java running on their systems.

There are solutions to this problem, involving installation of the new Java Runtime Engine along side the old one and then playing with the PATH or JAVA_HOME environment variables to tell Java which version of the JRE to invoke.  I’m going to be doing some research on this and will post the results.

In the mean time, a plea to applet developers… please make your software compatible with the newer, safer versions of Java.  Let’s close down malware writers’ access via this particular hole.