Bill’s Security Blog

So, where have I been?

For the last 4 weeks, I’ve been working like crazy on this FERC Order.

FERC Order RM06-22-000 seeks, in a nutshell, to modify the exemption for nuclear facilities that exists in each of the CIP standards.

Comments are due to FERC today.

Essentially, the NERC CIP’s exempt nuclear facilities in the US from compliance because those facilities are regulated by the NRC.

NRC has indicated that they do not regulate all components in a plant, only those that deal with safety, security, or emergency response (SSEP).

FERC is concerned that there may be components that are not protected by NRC but play a role in in the reliability of the Bulk-Power System.

As well they should. FERC is responsible for the reliability of the grid, and power continuity.

The industry has a robust cyber security program. And I’m not saying that because I work in the industry. I say it as a security guy who is more impressed by the program the more I learn about how plants have implemented it.

The industry program considers every device within the facility, irrespective of it’s role. COP systems may get a lower risk score than some other devices, but that seems reasonable, given we are talking about a nuclear reactor.

But the fact is that all systems are under the program.

The issue FERC has is that that program is not mandated by the NRC.

NRC, on the other hand, is about to adopt a regulation that would “codify” the requirement for a cyber security program (proposed regulation 10 CFR 73.54).

NRC says the industry adopted program, “goes a long way toward meeting the requirements of the new rule.”

In any event.

You get the idea. It’s a complicated issue.

In the end, what we’d like to avoid most is a situation where we have dual or duplicate regulation on a single device. NRC regulating for X, FERC for Y.

That gets ugly.

Particularly when plant licensees are required to operate two distinct cyber security programs. Ugh.

In any event, lets cross our fingers that FERC and NRC can work out an arrangement where a single regulator (NRC) can regulate all systems under a single cyber security program regulation.

Bill

This is common theme for me.

Perhaps I should state my feelings clearly: “If you depend on wireless in a control system environment, you are friggin’ crazy!”

A few weeks ago, I wrote about a SCADA tool from Conlab called U.C.ME.

This tool touts two-way SMS management of your infrastructure! Sweet, eh?

Now, I wrote Conlab but haven’t heard anything meaningful back. Err… Well, I did. I got a quippy email… “You said you emailed us, but you never did.”

Well, I have tried again, and to no avail.

Looking at the product’s material, they seem to be referencing a company ControlSee.  I’ll contact them.  Perhaps Conlab is just a reseller?  Who knows.

I wrote Conlab, who I thought was the product creator, to ask them what kind of authentication they are doing, and how they are preventing simple things like replay attacks.

Crickets.

Google alerts just tossed me this:
“Imagine you could speak to your SCADA system… Send a text message to your SCADA system.”

More talk of controlling your infrastructure through remote access.

Zero talk of configuration and control of access.

Conlab, ControlSee, whoever, for the love of god and all that is holy, if you have any information on this, please send it to me. This kind of stuff keeps me up at night.

Bill

The attack vectors and mitigation are not exhaustive, and are exemplary only.

A denial of service (DOS) attack is an attack against limited resources. A DOS attack is an attack against the “availability” function of the typical “CIA” security triad of “Confidentiality, Integrity, and Availability”.

A DOS attack is perpetrated by applying enough pressure against a target that the target’s resource allocation is overwhelmed.

In the question you posed, a DOS attacks can be perpetrated against any resource that supports the Web infrastructure.

A successful DOS attack against a web site tends to exhaust resources in one or more of three primary categories:

1. Network resources (routing capacity, network bandwidth, etc)
2. Web server resources (processor power, memory power, host networking capacity)
3. Database server resources

Mitigating a DOS attack involves protections at all three levels of the infrastructure.

One popular DOS attack is the “Distributed Denial of Service” attack.

Mitigation for this type of attack include:

• Network layer traffic filtering to attempt to block sources of the network-based DOS traffic.
• Increased network bandwidth and capability – Can you out-power the attackers.
• Website mirroring and caching can be employed.
• Website collocating can also help. If your website is hosted on multiple physical networks, taking the site down involves attacking multiple network resources.

A second attack vector is against the web server’s physical resources.

Perhaps you can get enough traffic through the network filters to overwhelm the web server’s processing capabilities.

Mitigation for this type of attack include:

• Throttling network filtering to ensure that the web server(s) do not get more traffic than they can handle.
• Website mirroring helps by adding additional capacity.
• Caching can also help by reducing the amount of processing necessary to serve the site.

Another type of DOS attack is a targeted attack against the applications running on the website.

If the website uses a database back-end, it is possible to execute a DOS attack by using SQL Injections that destroy database integrity, or prevent database access.

Mitigation for this type of attack include:

• Proper coding practices in the web applications that prevent SQL Injection attacks.
• Proper database account security that prevents unauthorized destruction of data.
• Database redundancy that attempts to keep the data available even if one or more data source is unavailable.

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

NOTE: I have changed the name of this weekly post from “this week in infosec” to “last week in infosec” to capture the obscenely obvious.

NOTE 2: Last two weeks have been crushingly busy. Will try to catch up this coming week, but have doubts about my capability :)

Threats/Countermeasures

New core networking vulnerability in TCP on the horizon

Thought things were over when Kaminsky’s bug got fixed? Guess again.

From Rich Mogul’s Securosis blog: Massive TCP Flaw Looming (selected quotes)

Basically, it’s a massive unpatched denial of service attack that can take down nearly anything that uses TCP, in some cases forcing remote systems to reboot or potentially causing local damage. Codified in a tool called “Sockstress”, Robert E. Lee and Jack C. Louis seem to be having trouble getting the infrastructure vendors to pay attention.

From what Robert told me, supported by the articles, this tool allows an attacker to basically take down anything they want from nearly anywhere (like a home connection).

Rich points to other material:
Dark Reading Room: New DOS Attack Is a Killer
SearchSecurity: New attacks reveal fundamental problems with TCP

Rich followed up with a post on October 3: Why The TCP Attack Is Likely Bad, But Not That Bad - again, quoting selectively:

Here’s what I think you need to know:

1. It is almost certainly real.
2. Using this technique, an attacker with very few resources can lock up the TCP stack of the target system, potentially draining other resources, and maybe even forcing a reboot (Could this trash a host OS? We don’t know yet.).
3. Anything that accepts TCP connections is vulnerable. I believe that means passive sniffing/routing is safe.
4. The attack is obvious and traceable. Since we are using TCP and creating open connections (not UDP) it means spoofing/anonymous attacks don’t seem possible.
5. Thus, I’d be more worried about a botnet that floods your upstream provider than this targeted attack.
6. This is the kind of thing we should be able to filter, once our defenses are updated.

Countermeasures -
None at the moment - prayer might be a good start. From the SearchSecurity article:

“The best advice I have right now is don’t allow anonymous connections. Make whitelist so only certain IP addresses can come in,” Lee said, acknowledging the impracticality of that for a Web server or mail server or virtually any other TCP-enabled device. “There’s no real workaround right now.”

Verizon - Security FAIL
From BugTraq:
Verizon FIOS (and DSL?) wireless access point insecure default WEP key

By default, the 40-bit WEP key for the wireless router provided by
Verizon to FiOS (fiber optic) and possibly DSL customers is set to the
last 40 bits of the router’s 48-bit MAC address. This is significant
because the router’s MAC address (the MAC address of it’s WAN-side
ethernet port) is easily discoverable using kismet without even
needing to know the WEP key.

When I got my FIOS, I was excited to see that they at least had WEB enabled by default.

Because I don’t trust any wireless connection, I didn’t even bother looking too closely at the default WEP key. The built-in firewall is enabled, and it seemed much better of a default configuration than I expected.

But using the MAC as the WEP key… Uh… FAIL

Countermeasure - Change your WEP key. Do it… 5 minutes…

Yes, you can crack WEP easily, but why make it obscenely obvious. Changing the default at least makes the attacker have to work more than 30 seconds.

Attack Vectors/Trends

Exploiting web trends to serve malware
From ZDNet’s ZeroDay blog post: Cybercriminals syndicating Google Trends keywords to serve malware

In an underground ecosystem that is anything but old fashioned when it comes to abusing legitimate web services, cybecriminals have started exploiting the traffic momentum, and by monitoring the peak traffic for popular search queries using Google’s Trends, are syndicating the keywords in order to acquire the traffic and direct it to malware serving blogs primarily hosted at Windows Live’s Spaces.

One method for distributing malware is getting people to visit your malicious website and then using browser hacks or other tactics to get the user to download and install your app.

This technique takes advantage of popular search terms to seed their malware pages, increasing their relevancy in searches.

Cute.

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

I have been spending some time lately researching the growing trend of using wireless and other remote connectivity services in SCADA networks and other control system applications.

Being an Infosec guy, this is hugely concerning.

Subversion of wireless and other remote technologies is very easy relative to a wired network at a facility.

SImple examples of the types of issues we can expect:

• Replay attacks
• DOS attacks
• Unauthorized disclosure
• Additional attack vectors

Some control systems (running a candy making facility, for example) - may not associate very high risk values to these vectors.

But what if you are a water plant, sewage treatment facility, auto manufacturer.

What kind of damage can be done if:

• An attacker can sent arbitrary alarm messages
• An attacker can send arbitrary alarm reset messages
• An attacker can flood the wireless device - preventing alarms from sounding

You get the idea.

On PACE, I just read a post: New software for wireless automation control, regarding Conlab’s U.C.ME product:

U.C.ME-OPC interfaces with any SCADA/HMI, OPC or DDE server to provide efficient, rapid and secure two-way communication with SCADA platforms, remote devices and users, via text messaging (SMS) or telephony, says the company.

Now, from what it looks like, the U.C.ME system does not alter settings on any devices - it’s simply a monitoring tool, but what if your command and control decisions are based on the information coming out of U.C.ME?

I have contacted Conlab for more information and will report back.

For now, it’s best to take some precautions:

1. Know that every message sent by your systems over a wireless network will be read by an adversary.
2. Assume that all data received from this system, or by this system may be forged.
3. Know that not hearing from the system doesn’t mean anything is going wrong, or that hearing from the system means there is a problem.

Essentially: If you use wireless technologies of any tye in the control system space, don’t trust the data at all… Not one bit.

Bill

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.