Tom Olzak

Archive for September, 2010|Monthly archive page

What about Us?

In Government, Regulation, Risk Management, Security Management on September 30, 2010 at 14:05

Here we go again… The last time this came up, no one could respond to security researchers who asked if this also means banning testing of anything that resembles a tool that can be used to attack a network.

Existing rules stipulate that illegally accessing and interfering with computers, servers and data is punishable as a criminal offence. The proposed directive will maintain and strengthen current provisions. But it will also specifically address and punish those who build, use and sell tools and software designed to carry out cyber-attacks.

via EU to up its defence against cyber attacks | EurActiv.

Will this be another governmental knee-jerk reaction, or will reason and common-sense prevail…?  Yes, I know.  They’re politicians, but I can hope, can’t I?

A Different Kind of Whitelist?

In Business Continuity, Cybercrime, Email, Phishing, Risk Management, Spam on September 30, 2010 at 13:45

During my years as a security director, one of the weekly challenges I faced was how to tell my peers in engineering that we have more items to add to the growing list of blocked domains or IP addresses.  This was not only a management headache; it also occasionally caused a backup of the email queue feeding our perimeter Barracuda devices. If only there was a better way…

Well, Spamhaus claims it has found the answer.  Using a tightly controlled whitelist–membership is possible upon invitation by another member–Spamhaus says it provides comprehensive email filtering, free and without all the management issues faced by many enterprises.

“Unlike traditional whitelists, the Spamhaus Whitelist is not a service to help bulk mail senders improve delivery rates. You can not whitelist an IP address or domain that is used for sending marketing or soliciting bulk email, or used for sending any email on behalf of third parties. This rule therefore automatically excludes makes not eligible for whitelisting Email Service Providers, ISP customer mail relays and mail servers used by third-parties, and all bulk mailing list servers and services,” the company said in its explanation of the service.

(Source: Spamhaus Debuts New Whitelist Service | threatpost.)

Setup is easy and well documented at the Spamhaus site. At a high level,

The Spamhaus Whitelist is actually made up of two whitelists: an IP address whitelist called the ‘SWL’ and a domain whitelist called the ‘DWL’. These are published as swl.spamhaus.org and dwl.spamhaus.org respectively.

The SWL is both an IPv4 and IPv6 whitelist. It responds to queries of either IPv4 or IPv6 addresses. (Note: IPv6 handling is not yet active. Spamhaus estimates IPv6 service starting in 2011)

The DWL is a VBR (vouch-by-reference) domain whitelist designed to automate DKIM certification.

(Source: Spamhaus.org, 2010)

So what happens if a sender abuses their membership in the whitelist?  Since the new service is in beta, we really don’t have any examples of deviant behavior.  However,

Spamhaus is reserving the right to revoke whitelist status for any email etiquette transgressions, such as the distribution of bulk mail of any type. The whitelist will be maintained in both IP addresses and domain name forms as two separate, but matched, lists. Controls mean no domain or IP address that is on the Spamhaus Project blocklist can ever be whitelisted.

(Source: Spamhaus debuts whitelist service, The Register, 28 September 2010)

Note that this service uses DKIM, something Microsoft Exchange DOES NOT support.  There are third-party solutions (example) that make Exchange compatible.  But if you use Exchange, I recommend adding a front end solution, like Barracuda Spam Firewall, between the Internet and your mail servers.  Other DKIM-compatible solutions are listed at DKIM.org.

Emergency patch for ASP.NET vulnerability

In Cybercrime, Data Security, Hacking, security, Security Management on September 29, 2010 at 14:28

According to H Security, this ASP.NET vulnerability should be patched as soon as possible.  The patch, MS10-070, is available from Microsoft as of 2/28/2010.

The vulnerability can be remotely exploited to read specific ViewState values and cookies and to download files from a server without possessing the necessary authority. The Padding Oracle Exploitation Tool (Poet) is able to take advantage of this kind of vulnerability. Affected products include Microsoft SharePoint 2010, SharePoint Foundation 2010, Microsoft Office SharePoint Server 2007, Windows SharePoint Services 3.0 and Windows SharePoint Services 2.0.

via Emergency patch for ASP.NET vulnerability on its way – The H Security: News and Features.

If you build it, they will crack it…

In Access Controls, Cybercrime, Hacking, Physical Security, Risk Management, Security Management on September 21, 2010 at 14:56

By this time, we should all get it… If you build an electronic device, someone will figure out how to crack it.  The other important principle we should all understand by now is if you don’t ensure physical security of a device, either the user or someone else will be able to find a way to misuse it.  Many people do understand these vulnerabilities, but the message hasn’t seemed to make it to ScottishPower.

Figure A shows an electricity meter in Scotland.  According to an article in Evening Times (the source of the photo), criminals have found a way to crack the key used to increase the prepaid amount customers can load into their meters.

“The pre-paid power meters use a key system. Normally people visit a shop to put credit on their key, which they then take home and slot into their meter.

The conmen have cracked the system and can go into people’s houses and put credit on their machine using a hacked key. If they use this, it can be detected the next time they top up their key legitimately.”

And that isn’t all.  Apparently the criminals correctly tell the owner of the meter that the hacking will be detected the next time they want to “legally” recharge the prepaid amount; they don’t seem to care if they can save a few bucks–or pounds.  It just means that the customer is tied to the criminal for power updates.

This is simply a bad idea waiting to make a victim of the power company.  The utility placed an unprotected device into the homes of their customers and relied on customer behavior to protect the interests of the utility.  Something is very wrong with this picture.

No, it isn’t right that people steal power.  But human nature being what it is, what did ScottishPower expect.  This is a good lesson for anyone who has to deploy systems, whether meters or desktops.

Bad software can be tortuous… in a very bad way

In Application Security, Cyber Espionage, Hacking, Network Security, Risk Management on September 16, 2010 at 10:35

It isn’t any surprise that Iranians and other people using the Internet in information-restricted countries need a way to “break out.”  It is also no surprise that someone would try to build a software solution to meet this challenge.  What is a surprise is the alleged lack of due diligence applied by the creators of Haystack, an application that seemed to promise anonymity for Iranians trying to circumvent government controls.

According to the Haystack website,

“Haystack is a computer program that allows full, uncensored access to the internet even in areas with heavy internet filtering such as Iran. We use a novel approach to obfuscating traffic that is exceptionally difficult to detect, much less block, but which at the same time allows users to security use normal web browsers and network applications.

[…]

Haystack hides traffic to any from the internet at large inside traffic that looks like perfectly normal web connections to innocuous sites. The Haystack client connects to our servers which in turn talk to websites on behalf of our users.”

This sounds like a great idea.  Think of the uses for a product that allows Iranians–and maybe eventually Chinese, North Koreans, etc.–to access uncensored opinion and news.  Of course, it would have to do this without government officials being able to see what users are accessing.  And although Haystack was supposed to do this, it apparently fails miserably.

According to a tweet by security researcher Jacob Appelbaum,

“Haystack is the worst piece of software I have ever had the displeasure of ripping apart. Charlatans exposed. Media inquiries welcome.”

In other words, if you are living in Iran and hoping freely to to surf the Web AND stay out of an Iranian prison, this is probably not the software for you.  So the Censorship Research Center (CRC) pulled the product.  Probably a good idea…

So what went wrong?  The main developer of Haystack resigned publicly and sent a letter to the Liberationtech mailing list.  In the letter, Daniel Colascione takes a lot of the responsibility for releasing what was supposed to be a test application–maybe closer to a proof of concept.  According to Colascione, it was not intended for public distribution or use by people who might put their physical freedom in jeopardy.  However, hype prevailed at the CRC, launching the product into public view and setting unreasonable and incorrect expectations.

Dan Goodin writes in a 14 September 2010 article in The Register,

The Guardian, for instance, named Censorship Research Center Executive Director Austin Heap the the 2010 Innovator of the Year and called Haystack “a key technology used by Iranians to disseminate information outside the country in the protests that followed the disputed election result in June 2009.” Newsweek, the BBC, Forbes, Salon.com, and The Atlantic have also lauded the project, even though Heap now says it never made it out of development and wasn’t widely used.

At this time, no one really knows if anyone put themselves in danger by using the software.  But let’s be honest; when something is hyped this much, it inevitably makes it to users’ desktops.  Based on on my quick research into this incident, this seems more like mismanagement than the intended release of really bad software.  It looks like the CRC was carried away on the tide of growing acclaim and took the public along for the ride.  Another instance of the media getting carried away?

In any case, I think there are at least two lessons to learn from this event.

  1. Never let potentially prison-causing software out of its cage until it is fully tested by numerous security researchers trying very hard to break it.
  2. Never get carried away by the hype surrounding a new product.  Do you own research into the product and its capabilities.  We can’t rely on much of the media responsibly to do this.
%d bloggers like this: