Bill’s Security Blog

A snapshot of topics of personal interest that have been talked about in the IT Security realm over the past week.

Threats/Countermeasures

Browser Security
While reading about the new attack vector called Clickjacking, I came across a useful article by US-Cert titled Securing Your Web Browser.

The guide covers specifics for both IE and Firefox, and is a must read.

Social Engineering
Get your passwords here, less than $10 USD
Brits Give Up Passwords For a £5 Gift Voucher

Attack Vectors/Trends

Clickjacking
Discovered by Robert Hansen and Jeremiah Grossman.  From: Clickjacking: Researchers raise alert for scary new cross-browser exploit

With this exploit, once you’re on the malicious web page, the bad guy can make you click on any link, any button, or anything on the page without you even seeing it happening.

Seems to rely on DHTML which cannot be disabled in browsers easily.

Work around - for the trusting types: don’t visit un-trusted sites and fill out any forms - be safe and wait for vendor patches.

Work around - for the paranoid: use Lynx or Links.

More info from US-Cert: Multiple Web Browsers Affected by Clickjacking

US-CERT is aware of public reports of a new cross-browser exploit technique called “Clickjacking.” According to one of the reports, Clickjacking gives an attacker the ability to trick a user into clicking on something only barely or momentarily noticeable. Therefore, if a user clicks on a web page, they may actually be clicking on content from another page. A separate report indicates that this flaw affects most web browsers and that no fix is available, but that disabling browser scripting and plug-ins may help mitigate some of the risks.

An additional report suggests that Firefox users consider using the NoScript plug-in as an added preventative measure. Disabling IFRAMEs by default, as outlined in the Securing Your Web Browser document, is reported to protect against the vulnerability.

News and Analysis

Blackberry
India’s government: At last, we’ve cracked Blackberry’s encryption

If this is true, why are we trusting Blackberry devices in the enterprise?

Good: We know they’ve cracked it.
Bad: Brings home the point that government knows everything about us.

Oh, I guess this is good:

“… still unable to crack BlackBerry Enterprise Service’s end-to-end AES or Triple DES, doesn’t really count as cracking Blackberry’s encryption.”

Google Chrome
Still more vulnerabilities coming out about this beta product.

Makes me think bout something - one positive about “old” code is that it’s been fully tested - most of the low-hanging-fruit should be worked out.

Much of Chrome is established code - but it looks like in the parts Google had to write - lots of issues.

Apple + Security == NULL
Java on Apple Mac OS X 10.5.4 and 10.5.5 does not prevent applets from accessing file:// URLs, which allows remote attackers to execute arbitrary programs.

National Cyber Security
Estonia posts their national Cyber Security Strategy

I’ll be reading it this week.

I think it’s pretty compelling to have a national strategy guide. I wonder how long the US document would be. I think it would take more than a decade to write, given the myriad of federal agencies that would need to be involved.

Bureaucracy = security fail.

It’s been a busy last week, and this week looks no less busy. I’ve missed out on some of my favorite blogs this past week, but will hopefully catch up if I can!

See you next week

Computer World Security reprinted a 2003 CIO.com article entitled: 2010: The Future of Security.

While I don’t like articles/news that engage in fear mongering, this article does lay out some likely outcomes of the growing perception of insecurity in computer system.

I say “growing perception” not to say that things are all fine and dandy in the security arena, but to indicate that the average Joe, and Joe’s elected official, are starting to notice.

Two things I’d like to address.

First, the article cites some work and quotes from perhaps one of my favorite software engineers, Watts Humphrey:

 We’re letting creative artists build bridges, he says, then trying to stabilize them with unlicensed laborers while they’re collapsing.

“I want the technical community to become professionals,” Humphrey says, “to say, This is how we do our job.”

TSP and PSP have already been found to reduce coding errors by factors of up to 10 or more. Microsoft tried it and reduced bugs within a 24,000-line program from more than 350 to about 25.

Humphrey also has conceived of even more radical changes, including a software engineering curriculum modeled on medical school, complete with professional internships.

Now, I’m not bashing Microsoft here, I’m trying to make a point.  Microsoft engaged in the endeavor to increase their security and reliability because of customer demand.  People got sick and friggin tired of the crap they were being fed for huge cost.

A big driver of this frustration was the infamous BSOD.  The blue screen of death put a tangible face to the problem.

The insecurity inherent in our digital world is mostly faceless.  This fact, in my opinion, will make it harder to get wide-scale changes to happen.

If we want to eradicate the enemy of insecurity, we have to put a face on it…

Second, the article describes how we go from “free and open” to a “police state” very well.  Summarizing:

1. The first response is litigation.
2. After litigation comes regulation.
3. “What follows regulation?” asks Jeff Schmidt. “Standards.”
4. The final phase of the corrective response to the digital Pearl Harbor will be a reformation, a cultural shift toward better, more proactive security.

But the article fails in taking this picture to it’s logical end.

I don’t believe 3 and 4 will happen.  What will happen is “governmental oversight” stemming from regulations.

Lets look at the track record of, say, the TSA.  Are we prepared to have an organization like that managing our country’s networks and infrastructure?

Likely, however, we’ll end up there.  The sad truth is, that TSA has done little to improve transportation security, and future governmental organizations will do just as ineffectively.

But the general public can SEE the TSA, and though they hate it, are somehow drinking the cool-aid and believing that things Must be more secure.

The result - why do something else?  “The TSA is there, we’re safe, aren’t we?”

In my mind, that’s the end fallacy of governmental regulation.  It:

• gives a false sense of security
• puts organizations in the position where they’ll do the bare minimum to comply.

I do believe that government can do things to change how this whole security thing shakes out, but their track record is very bad.

The best thing the government can do, in my opinion, is demand security, built-in, from the bottom-up, in everything they do.  Every contract they develop, every system they buy, every contractor they hire.

The government’s initiative in this arena would give vendors the financial incentive they need to build security into the process.

The effect is that everyone benefits.

Bill

This past week I was listening to the Digital Bond podcast for July, 2008.

One of the topics was whether or not the Hatch Nuclear Power Plant incident constitutes a cyber security incident.

About the Hatch incident:

The computer in question was used to monitor chemical and diagnostic data from one of the facility’s primary control systems, and the software update was designed to synchronize data on both systems. According to a report filed with the Nuclear Regulatory Commission, when the updated computer rebooted, it reset the data on the control system, causing safety systems to errantly interpret the lack of data as a drop in water reservoirs that cool the plant’s radioactive nuclear fuel rods. As a result, automated safety systems at the plant triggered a shutdown.

Southern Company spokeswoman Carrie Phillips said the nuclear plant’s emergency systems performed as designed, and that at no time did the malfunction endanger the security or safety of the nuclear facility.

Phillips explained that company technicians were aware that there was full two-way communication between certain computers on the plant’s corporate and control networks. But she said the engineer who installed the update was not aware that that the software was designed to synchronize data between machines on both networks, or that a reboot in the business system computer would force a similar reset in the control system machine.

Washington Post.com

The guests on the podcast seemed to be making sometimes contradictory arguments of why the incident was not a cyber security incident.

Arguments included whether or not participant had malicious intent, or whether or not any ‘real’ damage was caused.

I suspect that if you are in a regulated space where an event that is considered “cyber security” carries significant regulatory implication, then you would be motivated to call an event anything but a cyber security event.

But lets back up a second.

Information security seeks to ensure the confidentiality, availability, and integrity of information.

If an event affects either of those three, then it is a breach of information security.

If, when we refer to cyber security, we are really talking about digital information and information system security, does that somehow preclude the provision of confidentiality, availability, or integrity?

I think not.

Indeed, I think a proper definition of cyber security is the assurance of confidentiality, availability, and integrity of digital information and information systems.

The Hatch incident was a cyber security event by definition.

Let’s not try to confuse this stuff, it’s already hard enough.

Bill

The recently released bug in Altiris Notification Server allowing privilege escalation echo’s a sentiments I’ve held for a long time:

• Security products, in general, are no less vulnerable to attack than your average piece of software. (Note that this product had a similar vulnerability just a few months previously…)
• Adding security products increases your install base.
• Increasing your install base increases your attack surface.

I believe big strides toward a more secure, robust computing environment can be achieved through:

• Allowing the least required access to the minimum required services
• Reducing the install base to support least access to least services

If you can’t get those simple things right, don’t bother adding security products on top.

Every additional service (software, protocol, etc) and each additional role compounds your attack surface.

Get down to basics.

Bill

The March 15, 2008 SploitCast podcast was recorded at SchmooCon and consisted of a panel discussion including some notables in the InfoSec space: Johnny Long, Rodney Thayer, Simple Nomad, Landon Lewis, Squidly, and Matt Hillman.

Though the entire cast is a must-hear, with an extensive discussion SCADA and critical infrastructure security, the conversation turned toward practical security in a space where the boundary of the ‘network perimeter’ is rapidly vanishing.

Simple Nomad made the observation that end users don’t, and won’t, care about security.  Paraphrasing, it’s not that they are dumb, or stupid, but that they have different areas of expertise, and security may not be it.

The group agreed that security awareness is important, but it can’t be ‘the fix’.  Users will not become security experts.  Users can, however, be taught basics, such as not clicking on untrusted links in email.

At this point, Johnny Long stepped in.

He stated that awareness is good, and perhaps policy as well, but that when we really boil this security thing down, it reduces to three basic principles:

1. A server should not be a client
2. A client should not be a server
3. Peers should only connect in certain ways

He noted that when a computer changes roles, that’s when we know there’s a problem.

For example, when a laptop gets infected with bot malware and begins phoning home, it starts acting like a server, and that’s the behavior we should be looking for.

Important points, and I subscribe to this view of the network.

It doesn’t matter if the device is completely controlled by our IT team, or an iPhone connected inside our network… If it’s a client, it should be acting like a client…

Imagine the simplicity of this view.

Suppose we had the simple tools necessary to determine if our machines are abiding by their designated role, then what will we need to ensure about the device.

Do we have to ensure that the box is 100% patched?
Do we have to pay lots of cash for anti-virus, anti-phishing, anti-this and anti-that?
Do we have to make sure that the user has a 100% crack-resistant password?
Do we have to spend countless hours configuring our network to prevent unauthorized hosts?

Perhaps not.

One simple reason, it takes much less time to re-ghost a PC than it does to keep it ’secure’.

In my organization, for example, we could let the desktops and laptops run free on the Internet.

As long as we know what clients are allowed to do on the network, and what they are not allowed to do, then we are far better off.

Imagine this… Say you have all the latest updates, and anti-virus scanners and whatnot.  Well, do you know you are safe, or do you believe you are safe?

If you believe you are safe, then I’ll be happy to show you how you are wrong.  And if you know you are safe, then I’ll call you ignorant.

Why? Because security degrades over time.  Even the most secure system on earth is only secure until an attacker finds out a new way into the system.

For example, social engineering always works…  Plain and simple, it doesn’t matter how secure the system, if I convince you to reveal the appropriate information, I will own you.

Perhaps I need to ponder this a little more, but it seems logical that we can dramatically simplify our IT infrastructure if we focus on separation of duties in the hardware/software space, and then focused our security dollars on making sure that those roles were being followed.

The old conceptions of the network no longer apply in a space where the network perimeter is porous, or non-existent.  We need to change our thinking to match reality.

Bill

I saw the following quote in a post on the Security Focus website regarding the bug in Debian and Debian derived distros:

The latest flaw was introduced in the system because developers removed a line of code that had caused warnings about the use of uninitialized data when any program was linked to the OpenSSL library, [HD] Moore said.

It got me thinking back on the days when I was reading software engineering material like there was no tomorrow…

When I see a flaw like this, I think of all the areas where the flaw should have been caught prior to release:

• Code reviews, especially of critical/security systems
• Change/configuration control
• Testing

Though at one point in my life, I had visions of pure, mature software development processes being followed without fail in software shops around the world, I’ve come to believe that dream is a myth.

But for the love of god and all that is holy, if you are going to edit software that’s at the center of a security product or pipeline, you should be doing so within the realm of strict process.

I know there are a lot of developers out there who are editing code without much regard for process, but I urge you, think…

I urge every developer to take some time to refresh their understanding of what good software process is.  Though you may not follow it at the organizational level, we, as individuals, can bring some quality to what we do.

Here’s a few of my favorites:

• Software Release Methodology
• A Discipline for Software Engineering
• Testing Computer Software
• Planning Extreme Programming - read all software process books you can, esp the Rational books
• After the Gold Rush - Read all Steve’s books
• The Pragmatic Programmer

Read as many books in the fields of software process, lifecycle, engineering, testing as you can.  Don’t forget configuration control.

Bill

In an excellent article in the January 2008 ISSA Journal, Dan Timko sites some research done by Robert B. Cialdini regarding the tendencies in human behavior that generate positive (actionable) behavior.

The list is quite compelling.

The context of the article was social engineering, but I think that a working knowledge of these 6 tendencies may be helpful at any time we find ourselves working in meatspace.

• Reciprocation
• Consistency
• Social validation
• Liking
• Authority
• Scarcity

ISSA Members who haven’t gotten the Journal can read this article online (PDF).