Bill’s Security Blog

A snapshot of what’s been talked about in the IT Security realm over the past week.

Threats/Countermeasures

I didn’t log any URL’s for this, but I’m seeing more and more about handheld device attacks.

Some vendors are coming out with adaptations to their AV products for mobile devices.

Attackers will go after the easiest vector. How safe is your device? Are you sure?

Attack Vectors/Trends

This past week I saw a bunch of alerts on @Risk regarding bypassing authentication using cookie and session manipulation.

It reminds me that every input that comes from the user should be treated entirely as untrusted. Verification and Validation are required.

Last week I learned that the View State mechanism that Microsoft .NET uses to store data in the browser is stored in simple base 64 encoding - so even this could, in theory, be an attack vector from the client not to mention the obvious information disclosure potential.

If the user can touch it, we better be doing V&V on it.

News and Analysis

Super-collider hacked

• Large Hadron Collider’s Hacker Infiltration Highlights Vulnerabilities

DHS cant’ do cyber security.

• Critics: Homeland Security unprepared for cyberthreats

Some pondering if NSA should take over the gig

• Should NSA take over federal cybersecurity efforts?

Palin’s email account hacked.

The attackers appeared to be hiding their activities behind an anonymous web proxy while they performed their deeds.

That proxy service (Ctunnel) is cooperating with authorities.

I agree with the proxy service’s position to help the investigation. We all have a basic right to privacy, and proxy services can provide this, but we do not have the right to commit a crime without threat of prosecution.

The proxy service is making the statement, “you can be safe from prying eyes here, but don’t cross the line.”

I can get down with that.

Looks like Michelle Malkin got the scoop on how the attack transpired.

From the web - surprising political bias showing in the coverage from the blogosphere…

• Sarah Palin’s right to privacy?
• Wikileaks: Sarah Palin Yahoo Account Hacked, Posted
• Sarah Palin’s Yahoo account hijacked, e-mails posted online
• “Anonymous” hackers expose Palin’s e-mail
• Palin Yahoo Email Hacked
• Hey, it can happen to anyone ;-)
• Attacker: Hacking Sarah Palin’s email was easy

Tracking the attacker:

• Memo to US Secret Service: Net proxy may pinpoint Palin email hackers

From the Register:
Citect yanks ‘misleading’ SCADA bug advisory

Citect, a designer of software used by manufacturing plants and other industrial facilities, has removed an advisory that played down a vulnerability in one of its popular pieces of software.

Citect’s move followed last week’s release of proof-of-concept code that exploited a vulnerability in CitectSCADA, which is used to manage industrial control mechanisms known as SCADA (Supervisory Control And Data Acquisition) systems. The bug meant systems that relied on the software could potentially be exposed to tampering by disgruntled employees or terrorists.

Traditional IT software vendors have been learning this lesson for a long time.

Apple and Microsoft are still slow to the table.

But it looks like the tide is rising.

Vendors of SCADA system software are starting to feel the heat.

Many of these companies are used to writing systems that will be in place for decades. And from what I’ve read over the past few months, most of these companies use security modeling from decades ago.

I’m an advocate of two things:
1) A central set of cyber security requirements for all power related critical infrastructure.
2) US Government putting it’s money where it’s mouth should be.

The goal of the above two goals is to push security requirements into the front end of the procurement process. This pushes security needs back onto the vendors who are in the best place to ensure secure products.

Ask me about the secure composition problem later. For now, I’d settle for just one secure product…

PS - this article reminds me of the Helm’s Deep battle scene from The Two Towers, for those of you into LOTR (start at 8:40). You can say you are secure, but what say you when your defenses are obliterated?

Bill

From Electric Light & Power:
FERC proposes to close nuke cyber security gap

In an April 8, 2008 public joint meeting of FERC and the NRC, NRC staff indicated that the agency has proposed regulations to address cyber security at nuclear generating plants, but raised a concern about a potential gap in regulatory coverage because the requirements only will be directly associated with reactor safety security and emergency response, and will not extend to power continuity systems.

I’ve pondered the ramifications of this for a while.

One company, two regulatory bodies.

In the end, I believe that safety and security will be the casualty.

Nuclear power generating facilities in the US are regulated by the United States Nuclear Regulatory Commission.

Over the last year, NRC has gotten on the cyber security bandwagon. They have released a draft regulatory guide that, in theory, will increase the cyber security posture of nuclear power facilities.

In the absence of broad guidance, the industry has been operating under a policy developed by the industry, and approved by the NRC as an acceptable approach for ensuring cyber security.

Both these documents (much to my distress) are withheld from public disclosure.

The NRC’s job is to oversee the nuclear fleet (and other non-military nuclear related industry) and protect the public from potential harmful effects of radiation. After all, nuclear power plants in the US are using a radioactive isotope of Uranium (U235) as a heat source.

Since safety is the NRC’s primary mission, continuity of power concerns may be secondary.

The Federal Energy Regulatory Commission, on the other hand, is tasked with ensuring the safety, security, and continuity of the power grid.

In non-nuclear facilities, there is not an additional regulatory body concerned with the fuel source. The entire scope of operations falls under the regulatory oversight of the FERC.

The gap in regulatory oversight of nuclear generating facilities lies in the area between those set of assets that can be considered “safety related” and those that are considered non-safety related, but are important to continuity of power.

And things get really ugly when certain devices play both roles.

And that’s where this ball of wax gets really out of hand.

NRC is developing one set of standards for securing safety systems, and FERC (via NERC) has developed standards to ensure continuity of power.

Anyone who’s made it past basic algebra knows you can’t maximize two variables in an equation. You can maximize safety, or you can maximize your ability to ensure continuity of power, but not both.

Having grown up in Washington, I think I can smell which way the wind is blowing here.

The result will be that many systems will be under the regulation of two different entities, both with competing interests.

In the end, the operator will have to make a choice, and no matter which he chooses, he fails at achieving the requirements of either body.

In the situation, the best the operator can do is to shoot for the minimum set of configurations that meets all the requirements that match both sets of regulation.

I have to tell you, given that we are talking about a nuclear power reactor, I’d rather the operator not skimp on safety to ensure continuity of power.

What should be done?

It’s my opinion, having read the NRC’s draft regulatory guide, and spent some time looking over the NERC CIP’s that what we really need to do is take a step back.

I believe that continuity of power is a byproduct of the secure operation of any power facility.

I believe as well that safety is a byproduct of the same secure operation.

That said, I believe that what is best will be the development of a set of cyber security policies and procedures that are facility agnostic, and that ensure that digital systems within power generating facilities are secured.

Let the chips fall where they may. Implementing such a plan my require major modifications to the regulatory framework, but if it is what needs to be done, it needs to be done.

I can assure you that crackers do not care if FERC or NRC is running the show.

Bill

A snapshot of what’s been talked about in the IT Security realm over the past week.

Attack Vectors/Trends

This weekend I was listening to an episode of hmm… I think it was SecuraBit.

In any event, they spent some time talking about something I have posted about before: GIFAR.

GIFAR is combining Java JAR applets inside a GIF image.

When I first heard of it, I thought it was a neat vector, but didn’t fully consider the threat until I was listening to the podcast.

How many sites let users upload a profile image? Or how many social networking sites allow people to upload images and make galleries?

So, this bug is back on the radar.

News and Analysis

Microsoft, Apple, and age old bugs

This week @RISK listed a series of Microsoft image processing buffer overflows.

Buffer overflows. Yep, you heard it right.

Microsoft still doesn’t get it. Boundary checking is to a software developer what firewalls are to a network admin.

Shame on you, Microsoft.

The part that really gets my goat on this is that these are being discovered by researchers. Not by Microsoft. You can run automatic code checkers that will tell you that you have assignments with improper bounds checking.

This means that not only have Microsoft’s developers not gotten the clue, but also that Microsoft isn’t even doing the due diligence to do automated validation.

Fail.

Now, to be fair, there are several similar bugs this week in Apple products, including both host OS and iPhone.

But Apple is not enterprise ready, and it should not be used in the enterprise, and if it is, you get what you get.

Microsoft, on the other hand, explicitly bills themselves as the enterprise product. I expect more.

Google Chrome

I wrote a little about Chrome in last week’s This Week in Infosec.

Many more bugs have been discovered.

This is odd coming from Google that traditionally has pretty tight code.

Either they were rushing to market, or hoping that the community would debug for them.

Either way, they lost credibility with me. Yes, it’s still beta software, but some of these bugs are pretty basic stuff, like buffer overflows, which are insanely easy to find in the code.

Quoting pieces from PC Magazine’s “Electrical Grid Vulnerable to Hackers, House Told”

“The harm could extend not only to the economy and the health and welfare of our citizens, but event to the ability of our military forces to defend us, since many military installations rely on the bulk power system for their electricity,” said Joseph Kelliher, chairman of the Federal Energy Regulatory Commission (FERC).

The Energy Policy Act of 2005 gave FERC the authority to approve reliability standards regarding the nation’s bulk power system. But FERC can only approve standards; it cannot actually craft them. That job falls to the North American Electric Reliability Corporation (NERC), which worked with the industry to develop standards it presented to FERC in August 2006. FERC gave those standards its final approval in January 2008.

That type of timeline is acceptable for most issues relating to the nation’s power system, but when it comes to possible cyber attacks, the government needs to be able to act within hours or days, not three years, Kelliher said.

FERC is limited by the paper shuffling and red tape created by the 2005 legislation. If FERC identifies a problem, it can order NERC to develop a solution within 60 days, but Kelliher said he is not sure NERC “could meet this schedule in practice.”

FERC “does not have sufficient authority to guard against national security threats to reliability of the electric system,” Kelliher said.

He said FERC should also be able to compel utilities to make changes, and the commission’s power should perhaps extend beyond the bulk power system, which at this point does not include Alaska, Hawaii, or local distribution facilities, which include major cities like New York and Washington, D.C.

Ok.

So after NERC’s lambasting in front of congress a few month’s ago, FERC probably feels like it needs to flex it’s muscles a little. You know, show us that it’s relevant in the space.

To me this smells of “bureaucrat seeks to increase his power using fear-mongering and scare tactics.”

The problem with granting FERC these additional powers will be obvious to anyone working in a regulated environment. Currently NERC issues standards to which utilities must comply. FERC is now seeking the ability to issue additional regulatory requirements.

You can’t serve two masters.

FERC is seeking these responsibilities under the guise that they need to respond to “urgent and sudden” threats.

But in reality, if they gain this power, it’s my contention that the situation will be worse, not better. An alternate approach should be considered.

So, what constitutes the kind of threat that would trigger a FERC requirement? Would it be the kind of threat that triggered the TSA to stop allowing passengers to carry any liquids on air-planes?

One core problem I see is that rapid, non-vetted changes in a system increases overall risk.

If this wasn’t the case, then why are our bulk power generation facilities setting up sophisticated configuration management (CM) procedures to ensure that their systems don’t move into an inconsistent state without sufficient vetting?

Additional regulation and mandate will not get us to a true, lasting security.

The regulatory environment is just plain broke in just about every instance that I see. The answer is not more regulation and oversight, the answer is using a different approach.

Achieving confidence in the security posture of the electrical grid requires a few simple things, that as of yet, are not done:

• Define what “a secure grid” looks like. A realistic view can help drive where we want to go. Security for security’s sake is a waste of time, effort, and money. Tell the industry where it needs to go.
• Build smart, responsible regulation that pushes the industry in a measurable way toward that goal.
• Develop tools and resources to facilitate this migration. For example, develop generic contract language that companies can use when making software and hardware purchases that shifts the burden of secure product development onto the appropriate party.
• Develop financial incentives to motivate the change. In the corporate security arena, you see a rapid movement toward data security in the wake of very costly data disclosures. Power operators don’t make money when the lights are out, but you can also incentivize good performance through corporate tax credits for up-time and availability.
• Foster an environment of open communication where all parties can come together to enhance their practices, policies, and procedures.

The writing is on the wall if the bulk power generation industry does not see the light and start moving aggressively toward showing a significant commitment to security.

Other industries should take note.

Bill

A snapshot of what’s been talked about in the IT Security realm over the past week.

Threats/Countermeasures

Storm Worm
Inevitably, lots of scam hurricane relief sites are popping up :(

• Here we go again - Hurricane Relief Sites
• More Hurricane Domains

Attack Vectors/Trends

Malware

Malware is morphing much faster than any antivirus can keep up, as evidenced by an ISC handler’s diary entry: “Malware Analysis: Tools are only so good

If you want to be able to sleep at night, don’t rely solely on your AV to keep you save.

News and Analysis

The Number of Machines Controlled by Botnets Has Jumped 4x in Last 3 Months

I was perusing some of the data put out by the Shadowserver Foundation that tracks botnets. One piece of information grabbed my eye, namely that over the last 3 months, the number of infected machines quadrupled. During the same time period, there isn’t an appreciable increase in new malware, new viruses or anything that would obviously indicated why this is so.

Google Chrome
Google released a beta of their new Internet browser, Chrome.

A very good overview of the Google Chrome can be found over at SecuraBit.

Naturally, security folks have already been pounding on the product.

Security thoughts: It’s a beta product, what do you expect. Lots of bugs have been discovered.

Privacy minded folks don’t like the EULA that basically says that Google owns everything you do in the browser. Blog posts, sites visited, anything you do in the browser is Google’s.

Naturally, Google is backing away, and vows to change the EULA.

A smattering of vulnerabilities:

• Google Chrome Arbitrary File Download Vulnerability
• Google Chrome Remote Denial of Service Vulnerability

Several exploits for Chrome are showing up in Milw0rm.

See you next week,
Bill

On June 11, Core Security Technologies released a remotely exploitable CitecSCADA ODBC vulnerability. (US-CERT VU#476345)

Exploit code is now in the wild.

A patch is available upon request from the vendor.

Bill

A good ‘overview’ article on Energy Central, “Securing the Grid”

This is a little scary, though:

Utilities, meanwhile, are trying to adapt to this changing world. The evidence suggests that while no company has ignored earlier advisories, those entities have varied understandings of what it required of them. In fact, all of the utilities interviewed by government regulators have requested more information as it relates to how they could be attacked and what mitigation efforts are available to stop such breaches.

Couple that paragraph with the fact that most control system people think their situation is unique, and that traditional IT security doesn’t have anything to offer them, and it’s a recipe for disaster.

Bill

Quoting selectively from The Korea Time’s article:
“Defense Ministry’s Cyber Network Is Hacker-Proof”

A Defense Ministry spokesman assured Tuesday that the department’s cyber-security system is “hacker-proof,” adding that its intra-net computer data network is detached from the external Internet.

But Defense Ministry spokesman Won Tae-jae told local reporters during a press briefing Tuesday that the ministry’s intra-net network is not connected to the external Web, “so that outsiders can’t approach the internal network through the Internet.”

And regarding computers with Web access, “we have been instructing our staff not to store any military data on those computers. Also, our staff members are not allowed to use programs like word-processing on Internet-enabled computers,” the spokesman said. “We are also constantly monitoring our network and the Web-enabled computers.”

I don’t know what self-respecting security professional would ever make a claim that any piece of electronic is “hacker proof.”

I mean, someone hacked a damn coffee maker for christ sake.

And as far as physical separation of networks. Ya, it’s great in theory.

But what about: “Malware infects space station laptops“?

It’s hard to get more physically isolated than being on the International Space Station 200 miles into outer space.

Learning from the Oracle debacle, perhaps one might be tempted to make such a claim if their intent was to draw a lot attention from hackers/crackers in order to test and improve defenses.

Something tells me that’s not what the Defense Ministry meant.

Bill

Bruce Schnier summarizes and expands on the discussion from several security professionals in his post, “Security ROI” - quoting parts:

“ROI” as used in a security context is inaccurate. Security is not an investment that provides a return, like a new factory or a financial instrument. It’s an expense that, hopefully, pays for itself in cost savings. Security is about loss prevention, not about earnings. The term just doesn’t make sense in this context.

And a company should implement only security countermeasures that affect its bottom line positively. It shouldn’t spend more on a security problem than the problem is worth. Conversely, it shouldn’t ignore problems that are costing it money when there are cheaper mitigation alternatives.

I don’t necessarily agree that you should see a direct impact on your bottom line as the result of a security investment. I believe security investment is more like insurance where there may be no direct cost savings, but reduction in potential cost. I also like the insurance analogy because I think most non-security people can quickly grasp this analogy.

Let me explain.

As Bruce alludes to in his article, he traditional model for calculating risk in the security space is:
risk = threat x vulnerability x consequence

In my mind, “security” investment helps provide the mitigation necessary to reduce the vulnerability variable to a point where the risk value is acceptable.

Security countermeasures are a risk mitigation strategy.

Insurance is a little different, it helps offset the consequence variable.

But there is a similarity between “security” and “insurance” that I think most business people can understand.

They are both investments you are happy to pay, because they offset expected risk.

I have health insurance, car insurance, term insurance, permanent insurance, disability insurance, and probably a host of others as a part of my compensation package.

I’m very happy to “throw this money away” because it offsets risk to the point that I’m happy.

If I died today, I know my fiance will be taken care of, financially. I don’t see a direct reduction in my expenses, or increase in bottom line revenue if the threat never materializes.

I think business investment in security products and services are similar.

We implement them to reduce the risk value to the point where we are satisfied.

I like the insurance analogy, and think that it is much more tactile for non-security folks.

Bill