Unrealistic "Security Advice"

I just read a blog post (no need to direct traffic there with a link) that included the following content:

This week, I had the opportunity to interview the hacking teams that used zero-day vulnerabilities and clever exploitation techniques to compromise fully patched iPhone 4S and Android 4.0.4 (Samsung S3) and the big message from these hackers was simple: Do not use your mobile device for *anything* of value, especially for work e-mail or the transfer of sensitive business documents.

For many, this is not practical advice. After all, your mobile device is seen as an extension of the computer and there is a legitimate need to access work e-mail on iPhone/iPad, Android and BlackBerry smart phones. However, whether you are a businessman, a celebrity or the average consumer, it's important to start wrapping your mind around the idea of separating work from play on mobile devices.

This author is well-meaning, but he completely misses the bigger picture.

Against a sufficiently motivated and equipped adversary, no device is impenetrable.

Mobile devices are simply the latest platform to be vulnerable. There is no reason to think your corporate laptop is going to survive any better than your iPhone.

Now, I believe that non-mobile devices enjoy some protections that make them more defensible compared to mobile devices. Servers and workstations are generally "wrapped" with multiple defensive layers. Laptops benefit from those layers when connected to a corporate network, but may lose them when mobile. Still, even with those layers, intruders routinely penetrate networks and accomplish their missions.

One might also argue that mobile devices are more likely to be lost or stolen. I agree with that. However, full device encryption and passcodes can mitigate those risks. That's not the same as "zero-day vulnerabilities and clever exploitation techniques" however.

Despite these limitations, we still conduct work on computing devices. If we didn't, what would be the point?

We would be much better served if we accepted that prevention eventually fails, so we need detection, response, and containment for the incidents that will occur.

Software developers and security engineers should of course continue to devise better protection and resistance mechanisms, but we must remember we face an intelligent adversary who will figure out how to defeat those countermeasures.

Tweet

Read More

Lessons from NETOPS vs CND

Volume 13 Issue 2 of IATAC's IA Newsletter features an article titled Apples and Oranges: Operating and Defending the Global Information Grid by Dr Robert F Mills, Maj Michael Birdwell, and Maj Kevin Beeker. The article nicely argues for refocusing DoD's "NETOPS" and "CND" missions, where the former is defined currently as

activities conducted to operate and defend the Global Information Grid

and the latter is defined currently as

actions taken to protect, monitor, analyze, detect, and respond to unauthorized activity within DoD information systems and computer networks.

After spending years to "converge" the two missions, the authors argue DoD needs to separate them (as I understand the Air Force has done, bringing back the AFCERT for example).

I'd like to present selected excerpts with my own emphasis.

Cyberspace is a contested, warfighting domain, but we’re not really treating it as such, partly because our language and doctrine have not matured to the point that allows us to do so.

One reflection of our immature language is our inability to clearly differentiate the concepts of network operations (NETOPS) and computer network defense (CND). This creates confusion about the roles and responsibilities for provisioning, sustaining, and defending the network — much less actually using it.

Only by separating these activities can we more effectively organize, train, and equip people to perform those tasks...

Effective CND uses a defense-in-depth strategy and employs intelligence, counterintelligence, law enforcement, and other military capabilities as required. However, the CND culture is largely one of information assurance (e.g., confidentiality, integrity, and availability), system interoperability, and operations and maintenance (O&M).

Many of the things that we routinely call ‘cyberspace defense’ in cyberspace are really just O&M activities — such as setting firewall rules, patching servers and workstations, monitoring audit logs, and troubleshooting circuit problems...

[W]e do not treat cyberspace operations like those conducted in other domains... [T]housands of systems administrators routinely count and scan computers to ensure that their software and operating system patches are current. The objective is 100% compliance, but even if we could achieve that, this is a maintenance activity.

(Indeed, do we even really know how many computers we have, let alone how many are compliant?)

This is no more a defensive activity than counting all the rifles in an infantry company and inspecting them to ensure that they are properly cleaned and in working order.

Our current NETOPS/CND mindset is intentionally focused inward... Contrast this with a traditional warfighting mentality in which we study an adversary’s potential courses of action, develop and refine operational plans to meet national and military objectives, parry thrusts, and launch counter attacks.

While we do worry about internal issues such as security, force protection, logistics, and sustainment, our focus remains outward on the adversary.

Does that sound familiar? An "outward focus on the adversary" reminds me of my concept of threat-centric security instead of "inward" or vulnerability-centric security.

Our intent is not to diminish the importance of NETOPS activities... But they are not defensive activities — at least not in the classical understanding of the concept. Turning to Carl von Clausewitz, we see a much different concept of defense than is currently applied to cyberspace:

"Pure defense, however, would be completely contrary to the idea of war, since it would mean that only one side was waging it....

But if we are really waging war, we must return the enemy’s blows; and these offensive acts in a defensive war come under the heading of ‘defense’ – in other words, our offensive takes place within our own positions or theater of operations.

Thus, a defensive campaign can be fought with offensive battles, and in a defensive battle, we can employ our divisions offensively... So the defensive form of war is not a simple shield, but a shield made up of well-directed blows."

I find it interesting to see these authors cite Clauswitz. Anyone notice attrition.org blast Sun Tzu but speak better of Clauswitz recently?

These definitions of defense do not sound like our current approach to NETOPS and CND. Clausewitz might say we have a shield mentality about cyber defense...

An active defense — one that employs limited offensive action and counterattacks to deny the adversary — will be required to have a genuinely defensive capability in cyberspace.

Our recommendations to remedy this situation are as follows:

1. Redefine NETOPS as “actions taken to provision and maintain the cyberspace domain.” This would capture the current concepts of operations and maintenance while removing the ambiguity caused by including defense within the NETOPS construct.


2. Leverage concepts such as ‘mission assurance’ and ‘force protection’ to help change the culture and engage all personnel — users, maintainers, and cyber operators. Everyone has a role in security and force protection, but we are not all cyber defenders. Force protection and mission assurance are focused inward on our mission.


3. Redefine our CND construct to be more consistent with our approach to the concept of ‘defense’ in the other domains of warfare, to include the concept of active defense. This would shift the concept from maintenance to operations, from inward to outward (to our adversaries). CND is about delivering warfighting effects (e.g., denying, degrading, disrupting, and destroying the cyber capabilities of our adversaries).

I like these three recommendations from a corporate point of view:

1. IT provides "NETOPS".


2. User and management training and awareness are "force protection" activities.


3. CIRTs with Red capabilities, authorized to perform "active defense" against adversaries, perform "CND."

What do you think?

Read More

Shodan: Another Step Towards Intrusion as a Service

If you haven't seen Shodan yet, you're probably not using Twitter as a means to stay current on security issues. Shoot, I don't even follow anyone and I heard about it.

Basically a programmer named John Matherly scanned a huge swath of the Internet for certain TCP ports (80, 21, 23 at least) and published the results in a database with a nice Web front-end. This means you can put your mind in Google hacking mode, find vulnerable platforms, maybe add in some default passwords (or not), and take over someone's system. We're several steps along the Intrusion as a Service (IaaS) path already!

Incidentally, this idea is not new. I know at least one company that sold a service like this in 2004. The difference is that Shodan is free and open to the public.

Shodan is a dream for those wanting to spend Thanksgiving looking for vulnerable boxes, and a nightmare for their owners. I would not be surprised if shodan.surtri.com disappears in the next few days after receiving a call or two from TLAs or LEAs or .mil's. I predict a mad scramble by intruders during the next 24-48 hours as they use Shodan to locate, own, and secure boxes before others do.

Matt Franz asked good questions about this site in his post Where's the Controversy about Shodan? Personally I think Shodan will disappear. Many will argue that publishing information about systems is not a problem. We hear similar arguments from people defending sites that publish torrents. Personally I don't have a problem with Shodan or torrent sites. From a personal responsibility issue it would have been nice to delay notification of Shodan until after Thanksgiving.

Read More

Someone Please Explain Threats to Microsoft

It's 2007 and some people still do not know the difference between a threat and a vulnerability. I know these are just the sorts of posts that make me all sorts of new friends, but nothing I say will change their minds anyway. To wit, Threat Modeling Again, Threat Modeling Rules of Thumb:

As you go about filling in the threat model threat list, it’s important to consider the consequences of entering threats and mitigations. While it can be easy to find threats, it is important to realize that all threats have real-world consequences for the development team.

At the end of the day, this process is about ensuring that our customer’s machines aren’t compromised. When we’re deciding which threats need mitigation, we concentrate our efforts on those where the attacker can cause real damage.

When we’re threat modeling, we should ensure that we’ve identified as many of the potential threats as possible (even if you think they’re trivial). At a minimum, the threats we list that we chose to ignore will remain in the document to provide guidance for the future.

Replace every single instance of "threat" in that section with "vulnerability" and the wording will make sense.

Not using the term "threat" properly is a hallmark of Microsoft publications, as mentioned in Preview: The Security Development Lifecycle. I said this in my review of Writing Secure Code, 2nd Ed:

The major problem with WSC2E, often shared by Microsoft titles, is the misuse of terms like "threat" and "risk." Unfortunately, the implied meanings of these terms varies depending on Microsoft's context, which is evidence the authors are using the words improperly. It also makes it difficult for me to provide simple substitution rules. Sometimes Microsoft uses "threat" when they really mean "vulnerability." For example, p 94 says "I always assume that a threat will be taken advantage of." Attackers don't take advantage of threats; they ARE threats. Attackers take advantage of vulnerabilities.

Sometimes Microsoft uses terms properly, like the discussion of denial of service as an "attack" in ch 17. Unfortunately, Microsoft's mislabeled STRIDE model supposedly outlines "threats" like "Denial of service." Argh -- STRIDE is just an inverted CIA AAA model, where STRIDE elements are attacks, not "threats." Microsoft also sometimes says "threat" when they mean "risk." The two are not synonyms. Consider this from p 87: "the only viable software solution is to reduce the overall threat probability or risk to an acceptable level, and that is the ultimate goal of 'threat analysis.'" Here we see confusing threat and risk, and calling what is really risk analysis a "threat analysis." Finally, whenever you read "threat trees," think "attack trees" -- and remember Bruce Schneier worked hard on these but is apparently ignored by Microsoft.

These sentiments reappeared in my review of Security Development Lifecycle: Microsoft continues its pattern of misusing terms like "threat" that started with "Threat Modeling" and WSC2E. SDL demonstrates some movement on the part of the book's authors towards more acceptable usage, however. Material previously discussed in a "Threat Modeling" chapter in WSC2E now appears in a chapter called "Risk Analysis" (ch 9) -- but within the chapter, the terms are mostly still corrupted. Many times Microsoft misuses the term risk too. For example, p 94 says "The Security Risk Assessment is used to determine the system's level of vulnerability to attack." If you're making that decision, it's a vulnerability assessment; when you incorporate threat and asset value calculations with vulnerabilities, that's true risk assessment.

The authors try to deflect what I expect was criticism of their term misuse in previous books. On p 102 they say "The meaning of the word threat is much debated. In this book, a threat is defined as an attacker's objective." The problem with this definition is that it exposes the problems with their terminology. The authors make me cringe when I read phrases like "threats to the system ranked by risk" (p 103) or "spoofing threats risk ranking." On p 104, they are really talking about vulnerabilities when they write "All threats are uncovered through the analysis process." The one time they do use threat properly, it shows their definition is nonsensical: "consider the insider-threat scenario -- should your product protect against attackers who work for your company?" If you recognize that a threat is a party with the capabilities and intentions to exploit a vulnerability in an asset, then Microsoft is describing insiders appropriately -- but not as "an attacker's objective."

Don't get me wrong -- there's a lot to like about SDL. I gave the book four stars, and I think it would be good to read it. I fear, though, that this is another book distributed to Microsoft developers and managers riddled with sometimes confusing or outright wrong ways to think about security. This produces lasting problems that degrade the community's ability to discuss and solve software security problems.

No one is going to take us seriously until we use the right terms. Argh.

Read More

MRAPs Lose to Arms Race

Three weeks ago I wrote about Vulnerability-Centric Security regarding the Mine Resistant Ambush Protected (MRAP) vehicle, the US Army's replacement for the Hummvee pictured at left. I consider the MRAP an example of the failures of vulnerability-centric security. This morning USA Today's story MRAPs can't stop newest weapon validates my thoughts:

New military vehicles that are supposed to better protect troops from roadside explosions in Iraq aren't strong enough to withstand the latest type of bombs used by insurgents, according to Pentagon documents and military officials.

As a result, the vehicles need more armor added to them, according to a January Marine Corps document provided to USA TODAY...

"Ricocheting hull fragments, equipment debris and the penetrating slugs themselves shred vulnerable vehicle occupants who are in their path," said the document...

EFPs are explosives capped by a metal disk. The blast turns the disk into a high-speed slug that can penetrate armor.

Even with additional armor, the augmented MRAPs will still be vulnerable. This is because attackers possess advantages that defenses cannot overcome. In April I wrote Threat Advantages, which describes the strengths I see digital threats offering.

At least John Pike understands this problem.

It's doubtful new armor can stop all EFPs, said John Pike, director of Globalsecurity, a Washington-based defense think tank.

"Short of victory, they're going to continue to figure out ways to kill Americans," Pike said of the insurgents. "In any war, it is measure and countermeasure."

Investor's Business Daily agrees:

[W]e know the insurgency won't be put down with such defensive technologies. Better armor won't kill jihadists and suicide bombers. Better intelligence and better offensive tactics will.

In the digital realm, offense means actions to deter, investigate, apprehend, prosecute, and incarcerate threats. Sitting behind higher, deeper walls is not the answer. Neither is trusting the victim (the hardware, OS, application, or data) to defend itself.

Read More

Vulnerability-Centric Security

The vehicle pictured at left is a Mine Resistant Ambush Protected vehicle, the US Army's replacement for the Hummvee. I read about this vehicle in Army Times. That article said:

At a meeting to be held this week, according to a Pentagon source who spoke on condition of anonymity, the Army’s leadership is expected to request $9 billion for 9,000 MRAPs to be fielded through fiscal year 2008, with another 8,700 for fiscal 2009.

That's $1 million per vehicle.

I have a sinking feeling that although the new vehicle is "Mine Resistant," the "Ambush Protected" part will be tested by unpredictable, creative adversaries.

What does this teach us about digital security?

Frequently I hear people refer to the "if cars were like Windows" analogy. Let's take a look at cars and PCs, given the MRAP is really just a fancy car.

1. A car that doesn't start may be like a PC that doesn't boot. It could be the fault of the manufacturer or the owner, depending on maintenance, etc. If it's the manufacturer's fault, they could be held responsible for the problem.


2. A car that behaves erratically or in an unsafe manner while being driven may be like a PC that behaves erratically or crashes. It could be the fault of the manufacturer or the owner, depending on maintenance, etc. If it's the manufacturer's fault, they could be held responsible for the problem.


3. A car that gets hit by a boulder dropped from a bridge may be like a PC that is attacked by an exploit. This is not the fault of the driver or PC operator -- it's the fault of the threat dropping the boulder and the intruder launching the exploit. (Even if the PC is not patched, it's not the victim's "fault." If you can't accept that, consider the PC fully patched and the vulnerability a zero-day.)

In cases 1 and 2, we could hold either the owner or the manufacturer responsible for the problem, depending on the circumstances. In case 3, the threat is responsible.

Unfortunately, few owners are in a position to do anything about threats. If we take a vulnerability-centric approach, we end up driving vehicles like the MRAP and building layers of security around PCs (anti-virus, network firewalls, etc.) In both cases the mitigation is costly and ultimately ineffective, because the threat remains free to devise new and ingenious ways to inflict his will against the target.

Thinking we can build "invulnerable" vehicles like the MRAP is like Bruce Schneier thinking we can build invulnerable software. Sure, you can make more attack-resistant vehicles and software, but for what cost? Ultimately the threat must be directly addressed. No one thinks the way to peace in Iraq is by giving every Iraqi a bunker in which to live and a MRAP to drive. Why do people think we can do that with software?

Read More

Monitor Your Routers

Today I read this new Cisco advisory containing these words:

Cisco routers and switches running Cisco IOS® or Cisco IOS XR software may be vulnerable to a remotely exploitable crafted IP option Denial of Service (DoS) attack. Exploitation of the vulnerability may potentially allow for arbitrary code execution. The vulnerability may be exploited after processing an Internet Control Message Protocol (ICMP) packet, Protocol Independent Multicast version 2 (PIMv2) packet, Pragmatic General Multicast (PGM) packet, or URL Rendezvous Directory (URD) packet containing a specific crafted IP option in the packet's IP header...

A crafted packet addressed directly to a vulnerable device running Cisco IOS software may result in the device reloading or may allow execution of arbitrary code.

This is the sort of "magic packet" that's an attacker's silver bullet. Send an ICMP echo with the right IP option to a router interface and whammo -- you could 0wn the router. Who would notice? Most people consider their border router an appliance that connects to an ISP, and only begin watching traffic behind the router. I've been worried about this scenario since I posted Ethernet to your ISP in 2005 and read Hacking Exposed: Cisco Networks in 2006.

A router, like a printer, is just a computer in a different box. We should design architectures such that all nodes within our control can be independently and passively observed by a trusted platform. We should not rely on a potential target to reliably report its security status without some form of external validation, such as traffic collected and analyzed by network security monitoring processes. This Cisco advisory reminds me of a case I encountered at Foundstone. Shortly after joining the company in early 2002 the Apache chunked encoding vulnerability became known in certain circles. As the new forensics guy on the incident response team, I was asked how I could tell if Foundstone's Apache Web server was hacked. I replied that I would first check session data collected by a trusted sensor looking for unusual patterns to and from the Web server, as far back as the data and my time would allow.

Foundstone, being an assessment company, didn't share my opinions on NSM. No such data was available, so the host integrity assessment descended into the untrustworthy and often fruitless attempt to find artifacts of compromise on the Web server itself. Of course the Web server could not be taken down for forensic imaging, so we performed a live response and looked for anything unusual.

This case was one of the easier ones in the sense that all that was at stake was a single server. We didn't have a farm of Web servers, any of which could have been hacked.

Whenever I am trying to scope an incident I always turn to network data first and host data second. The network data helps decide which hosts merit additional individual scrutiny at the host-centric level. It makes no sense and is not time-efficient to deeply or even quickly analyze a decent-sized group of potential victims.

Because most security shops do not bother to collect NSM data, their first response activities usually involve a system administrator perusing the victim file system, manually checking potentially altered or erased logs on the target, and inspecting potentially obfuscated processes in memory controlled by a root kit. While I believe it can be important to collect live response data and even image and inspect a hard drive, I never start an incident response with those activities.

Remember: network first. I don't care if the intruder uses an encrypted channel. As long as he has utilized the network in a mildly suspicious manner, I will have some validation that the system is not behaving as expected. This presumes system owners know what is normal, preferably by comparing a history of network data against more recent, potentially suspect, activity.

---

Copyright 2007 Richard Bejtlich

Read More

Intel Premier IT Security Graphic

The image at left is from the first issue of an Intel marketing magazine called Premier IT. I like it because it shows many of the terms I try to describe in this blog, in relationship to each other. In English, the graphic says something like the following:

Threats exploit vulnerabilities, thereby exposing assets to a loss of confidentiality/integrity/availability, causing business impact.

I disagree that business impact is mitigated by controls. I think those terms were connected to make a pretty cyclical diagram. I would also say that controls mitigate attacks (exploits) by threats, not the threats themselves. Imprisonment mitigates threats.

The next diagram shows Intel emphasizes Policy at the base, followed by Training and Education, then Technology and Testing, and finally Monitoring and Enforcement. I think the Training and Education piece is marginally effective at best, at least for the general user population. It's tough enough for security pros to keep up with the latest attacks. It's impossible for general users. The school of hard knocks (i.e., experience) is doing a better job teaching the general user population not to trust anything online. I like the recommendation for Continuous monitoring for attacks and policy violations.

The last diagram positions most of the components of digital security within context. It includes Governance and Personnel, Physical Security, Network Security, Platform Security, Application Security, Storage Security, and File and Data Security. I like this image because it makes me question what aspects of this environment I understand and can personally implement.

Read More

Many Intruders Remain Unpredictable

The second of the three security principles listed in my first book is:

Many intruders are unpredictable.

I think the new Adobe Acrobat Reader vulnerability demonstrates this perfectly. (I'm not calling Stefano Di Paola an intruder; anyone who uses his technique maliciously is an intruder, though.)

Who would have thought to abuse a .pdf viewer in such a manner? Read more about the problem here.

This event reminds me of soccer goal security.

Read More

Brian Krebs on Internet Explorer Vulnerability Window

Brian Krebs posted an excellent article titled Internet Explorer Unsafe for 284 Days in 2006. Brian writes:

For all its touted security improvements, the release of Microsoft's new Internet Explorer 7 browser in November came too late in the year to improve the lot of IE users, who make up roughly 80 percent of the world's online community. For a total 284 days in 2006 (or more than nine months out of the year), exploit code for known, unpatched critical flaws in pre-IE7 versions of the browser was publicly available on the Internet. (emphasis added)

How did the competition fare?

In contrast, Internet Explorer's closest competitor in terms of market share -- Mozilla's Firefox browser -- experienced a single period lasting just nine days last year in which exploit code for a serious security hole was posted online before Mozilla shipped a patch to remedy the problem. (emphasis added)

This is exactly the sort of security metric I like to see. There are plenty of ways one could criticize these results, perhaps by asking about the underground group in Bulgaria sitting on 92 Mozilla 0-days? (just kidding) In the real world these are the sorts of numbers that best approximate our understanding of digital vulnerability. In terms of threat, Brian writes:

Likewise, there were at least 98 days last year in which no software fixes from Microsoft were available to fix IE flaws that criminals were actively using to steal personal and financial data from users.

I don't know how he measures the "98 days," but that gives you an idea of the degree to which these IE vulnerabilities were being exploited and risk moved from a probability to a certainty.

Don't just measure how many of your systems are patched. Measure how long they were vulnerable. Being patched does not mean being invulnerable, when vulnerabilities exist for which no patch is available.

Once you make these measurements, act on them. Consider alternatives. Complain to the vendor. Exercise the purse strings. Don't continue to be abused.

Read More

The Worst of All Possible Worlds

Sometimes I read configuration guides that advise installing anti-virus products on servers. Since I don't run Windows servers in production environments, I can usually ignore such advice. The proponents of the "anti-virus everywhere" mindset think that adding anti-virus is, at the very least, a "defense-in-depth" measure. This was debated last year, actually.

A lesson I learned from the excellent book Protect Your Windows Network is that "defense-in-depth" is not a cost-free justification for security measures. Every configuration and installation aspect of a system provides benefits as well as costs. Something implemented for "defense-in-depth" (whether truly believed to be helpful, or ignorantly applied) may turn out to harm a system.

Thanks to Harlan Carvey, I learned of another example of a defense-in-depth technique damaging security. This is the worst of all possible worlds -- adding a security measure that results in massive vulnerability. This upcoming eEye advisory warns:

A remotely exploitable vulnerability exists within the Symantec Antivirus program. This flaw does not require any end user interaction for exploitation and can compromise affected systems, allowing for the execution of malicious code with SYSTEM level access.

So you add anti-virus to a server, and BANG. 0wn3d.

Harlan focused on the following quote in the email he sent me:

"People shouldn't panic," [eEye's] Maiffret said. "There shouldn't be any exploits until a patch is produced."

This is a reference to the fact that once a patch is released, white, gray, and black hat security researchers race to analyze it to identify the vulnerable code fixed by the patch. Harlan wonders (accurately) if the underground (or others) already know about this vulnerability, and whether they are already exploiting it.

Keep this case in mind if you believe that "adding security" is a cost-free endeavor.

Read More

Thoughts on Patching

As I continue through my list of security notes, I thought I would share a few ideas here. I recorded these while seeing Ron Gula discuss vulnerability management at RMISC.

Many people recommend automated patching, at least for desktops. In the enterprise, some people believe patches should be tested prior to rollout. This sounds like automated patching must be disabled. I'm wondering if anyoen has implemented delayed automated patching. In other words, automatic updates are enabled, but with a two or three day delay.

Those two or three days give the enterprise security group time to test the patch. If everything is ok, they let the automated patch proceed. If the patch breaks something critical, they instruct the desktops to not install the patch until further orders. I think this approach strikes a good balance since I would prefer to have automated patch installation be the default tactic, not manual installation.

Determining which systems are vulnerable results in imagining a continuum of assessment tactics.

• At the most unobtrusive level we have a "paper review" of an inventory of systems and their reported patch levels.


• Next comes passive assessment of traffic to and from clients and servers.


• Traditional vulnerability scanning, without logging in to the target, is the next least obtrusive way to assess hosts.


• Logging in to a host with credentials is another option.


• Installing an agent on the host is a medium-impact approach.


• Exploiting the host is the final way to definitively see if a host is vulnerable.

On a related note, Ron mentioned that the costs of demonstrating compliance far exceed those of maintaining compliance. This is sad. Ron also noted he believes auditors should work for the CFO and not the CIO. I agree.

Read More

Real Wireless Vulnerability

At ShmooCon one talk discussed a somewhat obvious and not that exciting (to me) feature of Windows wireless networking. I don't consider automatic network connectivity to be a vulnerability, only a bad design choice. However, this morning I read this advisory on a real wireless vulnerability in FreeBSD's (and possible other BSD's) wireless code. From the advisory:

II.  Problem Description

An integer overflow in the handling of corrupt IEEE 802.11 beacon or
probe response frames when scanning for existing wireless networks can
result in the frame overflowing a buffer.

III. Impact

An attacker able broadcast a carefully crafted beacon or probe response
frame may be able to execute arbitrary code within the context of the
FreeBSD kernel on any system scanning for wireless networks.

That's cool. Insert wireless NIC, be 0wn3d. I'm glad I heard about this prior to Black Hat Federal next week.

Read More

In Defense of HD Moore

Thanks to Tom Ptacek, I learned of a truly lame SANS poll questioning the responsibility of the Metasploit ie_xp_pfv_metafile component. The poll results as of now show the following:

Was the release of the 2nd generation WMF exploit on Dec 31st 2005 irresponsible ?

35 % =>Yes, I 'd like to see the authors brought to justice
21 % =>Yes, they made the world a worse place
32 % =>No, the bad guys had already equal ammunition
11 % =>No, I believe the ends did justify the means
Total Answers: 1379

Regarding the first option -- what law exists against writing Metasploit components? About the last -- what "ends" are in play? I would have liked to have seen the following option:

"No, I now have a means to test the effectiveness of patches, 
anti-virus/malware products, and other defensive measures."

Without a way to test the effectiveness of countermeasures, defenders are as much at the mercy of the intruders as they are the software vendors who fail to provide timely patches.

I found that many of the poll comments do not seem to reflect the majority of "Yes" (meaning "irresponsible") votes, and some reflect the sentiment of this post.

I highly recommend reading Tom's post and his link to criticism of SATAN in 1995. The history major in me speaks up once in a while to say "nothing ever changes."

Read More

Microsoft Says Wait One More Week

I just received notice of the updated Microsoft Security Advisory on the WMF fiasco. It states:

Microsoft has completed development of the security update for the vulnerability. The security update is now being localized and tested to ensure quality and application compatibility. Microsoft’s goal is to release the update on Tuesday, January 10, 2006, as part of its monthly release of security bulletins. This release is predicated on successful completion of quality testing...

What’s Microsoft’s response to the availability of third party patches for the WMF vulnerability?

Microsoft recommends that customers download and deploy the security update for the WMF vulnerability that we are targeting for release on January 10, 2006.

As a general rule, it is a best practice to utilize security updates for software vulnerabilities from the original vendor of the software. With Microsoft software, Microsoft carefully reviews and tests security updates to ensure that they are of high quality and have been evaluated thoroughly for application compatibility. In addition, Microsoft’s security updates are offered in 23 languages for all affected versions of the software simultaneously.

Microsoft cannot provide similar assurance for independent third party security updates.

In other words, get 0wn3d, stay 0wn3d.

I'm going to keep my eye on the Kaspersky Lab Analyst Diary for news on any other WMF worms.

Read More

The Power of Open Source

One of the criticisms of open source software is that there is no one to blame when a customer needs a problem solved. For example, if an open source OS or application is found to suffer a vulnerability, no one is seen to be responsible for patching it. Following this line of thinking, commercial software is considered a superior choice for consumers (whether corporations or individuals). When a problem happens, users can rely on the vendor.

The recent SANS ISC post about the WMF vulnerability has completely annihilated this argument. I have criticized SANS in the past, but I cannot fault their handling of the ongoing fiasco. I've never seen anything like this plea by Tom Liston before:

Looking forward to the week ahead, I find myself in the very peculiar position of having to say something that I don't believe has ever been said here in the Handler's diary before: "Please, trust us."

I've written more than a few diaries, and I've often been silly or said funny things, but now, I'm being as straightforward and honest as I can possibly be: the Microsoft WMF vulnerability is bad. It is very, very bad.

We've received many emails from people saying that no one in a corporate environment will find using an unofficial patch acceptable.

Acceptable or not, folks, you have to trust someone in this situation.

To the best of my knowledge, over the past 5 years, this rag-tag group of volunteers hasn't asked for your trust: we've earned it. Now we're going to expend some of that hard-earned trust:

This is a bad situation that will only get worse. The very best response that our collective wisdom can create is contained in this advice - unregister shimgvw.dll and use the unofficial patch. You need to trust us.

The unofficial patch Tom references was written by Ilfak Guilfanov and described here. What is this? It's a patch created by a non-Microsoft developer, acting more rapidly than Microsoft itself. Sure, you can argue that Microsoft is working now to develop a patch that will hopefully address deeper problems, perhaps serious problems. Nevertheless, SANS has reverse engineered the unoffical patch to ensure its validity, wrote a FAQ about the vulnerability, and is now hosting a .msi to ease patch installation. This is unprecedented.

Where is Microsoft on this issue? They published their initial advisory on 28 Dec and updated it 30 Dec. Nothing they've done has helped resolve the issue. Meanwhile, the Metasploit project has released a module to generate malicious WMF files. This puts exploit creation in the hands of the lowest common denomintaor.

F-Secure reports the WMF issue is truly "a feature, not a bug," due to Microsoft's design of the WMF format. In fact, F-secure says

"'The WMF vulnerability' probably affects more computers than any other security vulnerability, ever."

Everyone who paid good money to Microsoft to fulfill its duty as a commercial vendor selling closed, proprietary software is still waiting for an official patch. Meanwhile, users are owned by exploit spam and targeted WMF email attacks. Remember this example the next time your management refuses to allow running open source software because "no one is responsible for problems."

When private third parties like SANS and Ilfak Guilfanov have to step up to the plate to save the world, the argument for exclusively running closed, proprietary software with a poor security record is weak indeed.

Note: I do not mean to unduly criticize Microsoft employees. I know several of them who are really sharp. At the end of the day, however, Microsoft as a corporation is AWOL on the WMF issue.

Update: SANS has temporarily pulled their .msi. However, I just installed the original .exe on a Windows XP SP2 system without incident. I also unregistered the shimgvw.dll library. Ilfak Guilfanov's patch creates this directory on the host:

C:\Program Files\WindowsMetafileFix>dir
 Volume in drive C has no label.
 Volume Serial Number is 30EF-BD7B

 Directory of C:\Program Files\WindowsMetafileFix>

01/02/2006  08:52 AM     DIR           .
01/02/2006  08:52 AM     DIR           ..
01/01/2006  12:38 PM               155 compile.bat
01/01/2006  03:54 PM             1,141 Readme.txt
01/02/2006  08:52 AM             3,537 unins000.dat
01/02/2006  08:52 AM           673,546 unins000.exe
01/01/2006  03:41 PM             7,022 wmfhotfix.cpp
               5 File(s)        685,401 bytes
               2 Dir(s)   3,207,041,024 bytes free

C:\Program Files\WindowsMetafileFix>type Readme.txt
MS WINDOWS METAFILE VULNERABILITY HOTFIX v1.3

PLEASE READ THE FOLLOWING CAREFULLY!

This is a temporary fix for the MS Windows
Metafile file vulnerability:

http://www.hexblog.com/2005/12/wmf_vuln.html

It has been tested on Windows 2000, Windows XP,
and Windows XP Professional 64bit.
Please use it at your own risk and switch
to the official patch from Microsoft as soon
as it is be available.

THIS FIX IS PROVIDED 'AS IS' WITHOUT WARRANTY OF
ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF FITNESS
FOR A PURPOSE, OR THE WARRANTY OF NON-INFRINGEMENT.

IN NO EVENT SHALL ILFAK GUILFANOV BE LIABLE TO YOU
OR ANY THIRD PARTIES FOR ANY SPECIAL, PUNITIVE,
INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES
OF ANY KIND, OR ANY DAMAGES WHATSOEVER, INCLUDING,
WITHOUT LIMITATION, THOSE RESULTING FROM LOSS OF USE,
DATA OR PROFITS, WHETHER OR NOT HE HAS BEEN ADVISED
OF THE POSSIBILITY OF SUCH DAMAGES, AND ON ANY THEORY OF
LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE USE
OF THIS SOFTWARE.

Copyright 2006 by Ilfak Guilfanov, ig@hexblog.com
http://www.hexblog.com

As you can see, you can inspect the .cpp file and compile it yourself if you do not want to run the compiled wmffix_hexblog13.exe.

Read More

Remote Heap Overflow in VMware Products

Thanks to a heads-up from "yomama" in the #snort channel, I learned of this advisory from Tim Shelton:

"A vulnerability was identified in VMware Workstation (And others) vmnat.exe, which could be exploited by remote attackers to execute arbitrary commands.

This vulnerability allows the escape from a VMware Virtual Machine into userland space and compromising the host.

'Vmnat' is unable to process specially crafted 'EPRT' and 'PORT' FTP Requests."

This implies that someone who connects to a FTP server using traffic that is processed by vmnat.exe can exploit vmnat.exe.

As a VMware Workstation user, I am glad to see they have published a new version to address the vulnerability.

Read More

Defense Seldom Wins Wars

In preparation for my career as an Air Force intelligence officer, I studied history at the US Air Force Academy. Since then I have enjoyed lectures produced by The Teaching Company, like Famous Romans. One of the lessons I have taken from this course is that defense seldom (if ever) wins wars. I was reminded of this lesson when I read Tom Ptacek's post " The Only Defense Is A Good Defense."

Tom is replying to my post where I said the following:

"I also do not agree [with SANS.edu] that 'knowledge... is the only defense to the growing threat.' The best defense is a strong offense. That means hunting down and prosecuting threats. No amount of defense can sufficient protect any moderately complex enterprise against determined intruders."

Tom disagrees and says that "Firewalls", "IT and Network Security teams", and "Vulnerability Research" have "done the most to improve security over the last 5 years." If we consider the risk equation to be something like "Risk = Threat X Vulnerability X Asset value", we must realize that Tom's points all address the vulnerability side of the equation. Applying countermeasures to the vulnerability aspect of the risk equation leaves the threat component untouched.

When the attacker is allowed freedom of maneuver, the defender will lose. The side with initiative has the superior position, unless the defenses are so unsurmountable that attack is more costly than defense. Let's return to the Famous Romans lecture for a moment. Prior to the rule of the emperor Hadrian, the Roman Empire had pursued an expansionist foreign policy. Rome had lost many battles to its neighbors, but those neighbors essentially remained on the defensive. They feared Rome would invade, conquer, and eliminate them (at worse).

When Hadrian became emperor in 117 AD, he changed Rome's foreign policy. He decided to consolidate the empire's borders. His most famous action was the building of Hadrian's Wall, separating England from Scotland. The wall was the ultimate statement of defense, as is sought to keep barbarians separated from Roman cities like London.

In some respects, this ultimate defensive maneuver was a success; London flourished. However, the building of the wall signalled weakness to Rome's enemies. Instead of being seen as a statement of strength, barbarians interpreted as a sign the Romans would not seek to conquer them. Rome looked weak, not strong. Within a century Rome would come under increasing barbarian attack, and the remaining shell of the western "empire" was formally overthrown in 476 AD.

Now, you might say that defense can prove superior to offense. You might cite trench warfare of the late 19th century, and the horror of World War I. In those cases, it is true that the weapons possessed by each side were so horribly destructive that attacks were fruitless and bloody endeavors. However, the arrival of the tank and over a million US troops changed the equation. Offensive action eventually won WWI for the allies.

A particularly clever historian might say the Cold War was won by defense. Some argue the US out-spent, or had the capability to out-spend, Soviet Russia. That is true. Another factor was President Reagan's plan to build the Strategic Defense Initiative (SDI, or "Star Wars.) SDI changed the security situation for the Soviets. The security paradigm of "mutually assured destruction" held that seeking to wipe out the enemy was a worthless action. Once the enemy detected missile launches, he could reply with his own volley. Both sets of missiles would wipe out each side's weapons, leaving neither with an advantage to leverage in a post-exchange world.

SDI altered this nuclear attack outcome. With SDI deployed, the US could potentially preserve some of its weapons for a second round of attacks. This second round gave the US superiority over its Soviet opponent. Suddenly a nuclear war became "winnable," as insane as that sounds. In this case, then, defense was important, but only to preserve the weapons of offense.

In the final analysis, what makes you feel safer -- a lack of criminals on your street, or iron bars on your windows?

Read More

SANS Replaces Several Threat References in Top 20

Last week I posted comments about several misuses of the word "threat" in the latest SANS twenty most critical Internet security vulnerabilities. After receiving an email from Alan Paller, I returned to the SANS site and saw many of my recommended changes were made. For example, you can now "Jump To Index of Top 20 Vulnerabilities", instead of "threats." I appreciate SANS taking my suggestions to heart.

Update: It's becoming clear where the confusion regarding "threat" vs "vulnerability" originates for the SANS Top 20. One of you pointed me towards the article Mac OS X Under Scrutiny. See how many misuses of the term threat you can find. Here's a freebie:

"SANS's Dhamankar stressed that the intent was not to call the Mac OS X operating system a threat, but to give Mac users a wake up call."

Read More

The Good and the Bad About the New SANS Top 20

Back in January I noted that SANS was not using the terms "threat" and "vulnerability" properly in its call for help on the "twenty most critical Internet security vulnerabilities," represented by the logo at left.

You will remember that a threat is a party with the capabilities and intentions to exploit a vulnerability in an asset. A vulnerability is a weakness in an asset that could lead to exploitation. An intruder (the threat) exploits a hole (the vulnerability) in Microsoft IIS to gain remote control of a Web server. In other words, threats exploit vulnerabilities.

Today, version 6 of the Top 20 was released. I'll start with "the good." I believe the majority of the 2005 content is much better than the 2004 edition. The 2004 list, and previous lists, displayed 10 Windows vulnerabilities and 10 (often dubious) Unix vulnerabilities. The 2005 list, in contrast, displays the following vulnerabilities:

Top Vulnerabilities in Windows Systems

        * W1. Windows Services
        * W2. Internet Explorer
        * W3. Windows Libraries
        * W4. Microsoft Office and Outlook Express
        * W5. Windows Configuration Weaknesses

Top Vulnerabilities in Cross-Platform Applications

        * C1. Backup Software
        * C2. Anti-virus Software
        * C3. PHP-based Applications
        * C4. Database Software
        * C5. File Sharing Applications
        * C6. DNS Software
        * C7. Media Players
        * C8. Instant Messaging Applications
        * C9. Mozilla and Firefox Browsers
        * C10. Other Cross-platform Applications

Top Vulnerabilities in UNIX Systems

        * U1. UNIX Configuration Weaknesses
        * U2. Mac OS X

Top Vulnerabilities in Networking Products

        * N1. Cisco IOS and non-IOS Products
        * N2. Juniper, CheckPoint and Symantec Products
        * N3. Cisco Devices Configuration Weaknesses

Bravo. I think that is a significant step towards realizing the scope of the problem at hand. To be fair to Microsoft, I believe there could have been "Unix services" and "Unix libraries" sections. I applaud the addition of network products and other applications. Content-wise, this is a great resource.

Now, "the bad." The top of the page has this link: -----Jump To Index of Top 20 Threats -----. For Pete's sake, the title of the document is "The Twenty Most Critical Internet Security Vulnerabilities." These are not threats.

Let's see other terms in use:

In the introduction we see:

"In addition to Windows and UNIX categories, we have also included Cross-Platform Applications and Networking Products. The change reflects the dynamic nature of the evolving threat landscape."

I can accept this use of the term threat, if the intent is to refer to parties who exploit vulnerabilities.

Next:

"We will update the list and the instructions as more critical threats and more current or convenient methods of protection are identified, and we welcome your input along the way."

Here, threats should be "vulnerabilities".

Section C2:

"Compromising a gateway could potentially cause a much larger impact since the gateway is the outer layer of protection and the only protection for some threats in many small organizations."

This should either replace "threats" with "vulnerabilities", or "for some" with "from some".

Section C5:

"The main threats arising from P2P software are:"

I think threats should be "risks" here, although the list is a muddle of different issues.

Later in that section:

"The number of threats using P2P, IM, IRC, and CIFS within Symantec's top 50 malicious code reports has increased by 39% over the previous six-month period."

Here, I can accept the use of the term as long as the intent is to describe parties abusing P2P, IM, etc.

Section C8:

"These applications provide an increasing security threat to an organization. The major threats are the following:"

Here's a simple rule of thumb: applications can never be "threats." Again, I suggest replacing the second "threats" here with "risks".

One final note: I am not a lone voice speaking on this subject. The Financial Times, of all people, is linked from the SANS page with a story Hackers pose new threat to desktop software. That's the proper use of the term threat, since a hacker is a "party."

Security will not be taken seriously as a "profession" until its "thought leaders" use basic terms properly.

Read More