When it comes to Cyber Warfare: Shoot the Hostage
Last Updated on Tuesday, 15 September 2009 08:02 Written by Jeffreycarr Tuesday, 15 September 2009 08:02
Harry: OK, Airport. Gunman with one hostage, using her for cover. Jack?
Jack: Shoot the hostage.
Harry: What?
Jack: Take her out of the equation.
Harry: You’re deeply nuts, Jack.
-“Speed” (1994), written by Graham Yost
The fun of movie scenarios aside, consider the same strategy when the hostage is not a human being but a piece of technology or a legacy policy that is protected by powerful interests or politics.
Here’s a new scenario. A state or non-state hacker attacks U.S. critical infrastructures and DoD networks at will and without fear of detection or attribution. He is able to do this from behind the protection of two very valuable “hostages” or, more precisely, two politically touchy issues that U.S. government officials including the Congress are loathe to change – using Microsoft Windows and regulating a segment of private industry.
Hostage 1: The pervasive use of Microsoft Windows Operating System throughout the federal government but particularly within the Department of Defense, the Intelligence Community, and privately owned critical networks controlling the power, water, transportation, and communication networks.
Hostage 2: The uninterrupted, sustained economic growth of U.S. Internet service providers, data centers, and domain name registrars who profit and growth before security by not taking a deep enough look at who they sell their services to (e.g., criminal organizations and nationalistic hackers who prefer the reliability and speed of U.S. networks to the ones found in their own countries).
In this case, the best solution, bar none, is to metaphorically “shoot the hostage”, thus denying an adversary of both his weapons (1) malware configured for the Windows OS and (2) his attack platform – the most reliable Internet services companies in the world.
Shoot the first hostage by switching from Microsoft Windows to Red Hat Linux for all of the networks suffering high daily intrusion rates. Red Hat Linux is a proven secure OS with less than 90% of the bugs found per 1000 lines of code than with Windows. Many decision makers don’t know that it is the most certified operating system in the world and it’s already in use by some of the U.S. government’s most secretive agencies. Computers are changed out every 3 to 4 years on average anyway, so the monetary pain is probably not as great as it might seem. The benefit, however, would be immediate. Further, the exchange of operating systems only on high value boxes would not change the economics equation for virus writers. There would still be about one billion Windows PCs for them to take advantage of.
Shoot the second hostage by cracking down on U.S. companies that provide Internet services to individuals and companies who engage in illegal activities, provide false WHOIS information, and other indicators that they are potential platforms for cyber attacks. The StopGeorgia.ru forum whose members were responsible for many attacks against Georgian government Web sites including SQLi attacks that compromised government data bases was hosted on a server owned by SoftLayer Technologies of Plano, TX.
The DDoS attacks of July, 2009 which targeted U.S. government and South Korean government Web sites were not controlled by a master server in North Korea, or China. The master server turned out to be located in Miami, FL.
ESTDomains, McColo, Atrivo – all owned or controlled by Russian organized crime were all set up as U.S. companies with servers on U.S. soil. The Russian criminal underground prefers to host their Web operations outside of Russia to avoid prosecution. And the robust U.S. power grid, cheap broadband, and friendly business environment makes this country the ideal platform for cyber operations against any target in the world, including the U.S. government.
Congress needs to send a strong signal to U.S. Internet hosting and service provider companies that profit must be tempered by due diligence, and that they are, effectively, a strategic asset and should be regulated accordingly.
Neither of these recommendations are politically safe, however the U.S. is now facing a serious threat from a new domain with so many evolving permutations that senior leadership, both civilian and military, seem to be standing still. And that’s absolutely the wrong strategy to employ.
————————-
The above is an excerpt from Chapter 13 “Advice to Policy Makers” from the forthcoming O’Reilly Media book “Inside Cyber Warfare”. It still needs a lot of work so comments are appreciated, but the points that I’m trying to deliver in a provocative and memorable way for non-geek policy makers are key issues that, if implemented, will reduce our vulnerability for our high value targets, and reduce the operational effectiveness of Non-state actors engaged in State attacks.
————————–
This doesn’t protect those critical systems against more blunt attacks; a DDoS doesn’t care what system you’re running, or how patched it is. The major weapon or tool here is the botnets.
I would propose this as an alternative; mandate a network access control check by all US ISPs (to include DISA and other government ISPs), and ‘encourage’ it by all ISP’s whose traffic runs through US infrastructure. A check of end-point patching compliance and minimal security posture (i.e. firewall on, and active/current client anti-malware software) becomes a pre-requisite step for internet access via an ISP.
The trick here is how to make this acceptable for privacy concerns (scanning my system to make sure I’m secure? What else are you scanning for – pirated software, child porn, hate speech etc.) and the prospect of a tiered internet – a quarantine zone, a “wild west” zone and a “cleared” zone.
Your assertions about the C&C for the botnet used in the RoK/USA DDoS attacks are incorrect – please see this presentation for a more precise overview, thanks!
Interesting proposal, Mike. Thanks for posting it. Regarding your comment about lack of protection against DDOS attacks, that’s true however I’m more concerned about the use of SQLi attacks to penetrate a high value network than a blunt DDoS attack. The former is much more dangerous with teh exception of mega-botnets of Conficker size or larger. Dealing with them is an entirely different problem.
Roland, I looked at your deck and didn’t see any mention of the Global Digital servers which acted as Master servers for the C&C servers that ran the botnet.
Kudos on the deck, although I disagree with your assessment of the seriousness of the Estonia and Georgia attacks. You make no mention of the successful SQLi attacks which compromised Georgian government servers, for example.
Here is Global Digital Broadcast’s acknowledgement of the involvement of their servers in the attack. Note that the master server was in Miami, FL.
http://www.globaldigitalbroadcast.com/newspage.php?newsId=123
There was no single ‘master server’ for the RoK/USA DDoS attacks, FYI – there were multiple C&C servers spread throughout the world. This is mentioned in my preso, and is based upon verified, hands-on research.
My focus on the Estonian and Georgian attacks – indeed, the focus on the whole deck – was on the DDoS portion of the attacks, which was trivial in nature. The slide deck is about DDoS, not about attempts to compromise servers.
In my opinion, the biggest issue with your proposed hostage (2) situation is that there is a lack of empowered, knowledgeable enforcement. Policing the ISPs and other technology providers who are enabling these attacks required a major investment in hiring people with the requisite expertise. The legal framework for prosecuting these crimes can be worked, even if it’s an application of existing standards – RICO maybe?
For hostage (1), the biggest issue is the disparate funding for development and acquisition, and operations. DoD for example is mandated to separate those functions. Because the acquisition agents usually procure in a monopoly situation (i.e. the DoD can’t choose to get key systems from anyone else) they are not incentivized to provide an operationally efficient system – their performance is measured by keeping down cost, and keeping on schedule.
To do that, they gravitate towards the Windows ecosystem. The Operators want a secure, stable system, but get limited input to the acquisition process. The cheapest and most efficient system to operate isn’t necessarily the cheapest and fastest one to develop.
The governance levels who should be able to compare these competing interests lack the technical expertise and don’t have the holistic knowledge of ACTUAL IT spending to influence the process or make appropriate compromises.
This makes little sense. First, there’s no evidence that a linux distribution is any safer than a Windows distribution. Both suffer frequent software flaws. Red Hat had a recent issue where their RPM repository was secretly tainted: http://isc.sans.org/diary.html?storyid=4921&rss
Additionally, Microsoft now has the best generic exploit mitigation technology. Successfully exploiting a bug on 64 bit Windows 7 with DEP, ASLR, GS, SafeSEH, and SEH chain validation is a nightmare. It’s far easier to hack most Linux software at this point and definitely easier to taint an open source software package.
Finally, there’s the small problem of hundreds of thousands of users and decades of legacy software built for Windows.
Roland, it was BKIS that first identified the existence of a master server owned by Global Digital as running the C&C servers. Are you disputing their report?
http://www.pcworld.idg.com.au/article/311070/uk_north_korea_source_ddos_attacks_researcher_says
I’m curious as to the decision that lead to only recommending Red Hat. Is it for reasons of OS support, security track record, or personal preference?
Matthew’s arguments carry echoes of validity (as much as I generally dislike Windows and feel that his generalization of Linux’s security mechanisms is flawed and shallow). A major switch from any OS to any other will not go unnoticed by malware writers. They will target whichever platform will have the most financial yield. Ten years ago there was very little to monetize on a Mac, today with stronger uptake in schools and in the home, and more people conducting business on them, the Mac has become another targeted platform.
However, our major issues in malware propagation today are not simply software exploit mitigation. Some of the most successful malware requires the user to install it manually under the guise of updating a codec or other software component. This attack would be successful across the vast majority of OS’s save for those that use ONLY explicitly signed content.
The game as we are playing it now does not have a winning solution (in my opinion). We can however change the rules if we change the way users interact with their information and machines. User awareness would prevent spread of easily the majority of malicious code. Better web interface security and management would result in fewer incidents of drive-by infections (yes I’m alluding to hardening sites against SQL injections).
There’ve been multiple assertions made about the existence of a higher-tier distribution point for the updated target lists; Miami, FL and the UK have both been mentioned by multiple parties in that regard. I’m not commenting on those assertions, apologies for being unclear.
What I’m stating is that the actual command-and-control servers with which the bots checked in to look for updated target lists were several in number, and not concentrated in one country. Please do note that BKIS have stated this, as well.
In the above snippet from your book, there’s an inadvertent implication that there was a single C&C server, when in reality there were multiple C&C servers – just semantics, really.
I think that it would be more relevant to the topic of your book to also cite the distributed C&C infrastructure, and note that it was an attempt to increase the resilience of this particular botnet. There’re lots of other examples of various botnets using obfuscated and resilient C&C mechanisms (Conficker is one recent example), and making the point that the miscreants are actively employing high-availability techniques beyond those employed by many legitimate organizations would be both enlightening and interesting to many of your target audience.
At any rate, thanks for listening, and good luck with your book!
Thanks to everyone for the comments. I’ll raise some of these criticisms in a second version of this contribution for the book.
Just a few comments in the meantime:
1. Replacing Windows with Linux or another OS is only being proposed for the highest value targets in gov and critical infrastuctures. It won’t make a dent in the overall percentage of Windows systems out there so there won’t be any financial incentive for the malware propagators to switch targets.
2. These two propositions aren’t being fielded as a total fix. Simply a way to reduce the target area and make finding reliable platforms and servers more difficult for the bad guys. At least let’s stop them from attacking the U.S. from U.S. servers. That would be a good start, IMO.
3. We need to start picking the best tool for the job, rather than the one that’s easiest or cheapest or most convenient. Windows simply isn’t the best tool for the job. Perhaps it never has been.
This post has been linked for the HOT5 Daily 9/16/2009, at The Unreligious Right
Matthew, we should be clear about the fact that it was those OpenSSH packages that were tainted, not the entire repo — and that the tainted packages never saw the light of day, as the link you mention indicates.
You also mentioned that the Windows 7 protections are superior to those found in Linux. I don’t care to argue hypotheticals, so I’ll wait for Windows 7 to be Common Criteria certified at EAL4+ under CAPP, LSPP, and RBACPP before I start comparing the two. But I suspect that SELinux gives Red Hat an edge here.
All software will have security flaws, despite everyone’s best efforts. I think it’s safe to say, as admin mentions, that Red Hat’s security track record is among the best in the industry. You can find the metrics here: https://www.redhat.com/security/data/metrics/
nb: I work for Red Hat, but certainly don’t speak for them.
[...] When It Comes to Cyberwarfare, Shoot the Hostage – Jeff Carr, IntelFusion [...]
To the criticisms of Windows vs Linux, this is an old war and one that’s not likely to shift here. For what it’s worth, I only run Windows inside VMs, excluding one system. Generally I run CentOS and OS X. Linux has a smaller attack surface when properly configured, but if a vulnerability is present on an exposed service, IMO it is easier to obtain code execution.
That being said, I’ve spent far more time doing exploit development in Windows and for modern MS OSes it’s a nightmare. Windows 2008 is mass market now and Windows 7 is in ‘gold disk’ mode meaning what’s available now is what’s being printed to disk. I’m not going to argue certifications. Systems being certified as whatever doesn’t really affect their security posture.
I also don’t think using disclosed software flaws as a bug is a good metric. All OS vendors manipulate the stats to make themselves look better.
What I’m talking about with security is the amount of time it takes to find and develop an exploit. Microsoft SDLC is quite good and their generic (OS level) security features are quite impressive. Linux has made decent ground with NX and stack overflows, but it’s light years behind in mandatory fuzzing and heap protections such as SafeSEH and ASLR. I don’t have metrics, but my ballpark estimation is that it’s easier to gain code execution on Linux than Windows 2008 or Windows 7.
SELinux is a bit different than anti-exploit protections. SELinux may prevent an exploited process from otherwise affecting the system, though there have been bypasses. To my knowledge, it does nothing to prevent a process from being exploited. It’s certainly a related factor, but once a system is compromised it’s generally only a matter of time to gain full access.
What would really be useful would be metrics for exploiting linux vulnerabilities. Immunity Inc, has some stats on what it takes to exploit windows bugs, but I haven’t seen anything similar for Linux. Until then, the discussion is really only conjecture with varying degrees of applicability.
Going back to chain of trust in distribution, Apache is still recovering from a recent attack and has yet to verify their binaries weren’t tainted. Their blog currently only states that they think they weren’t tainted.
Linux has a role, but it’s not as a cutting edge security platform. Additionally, the government largely has a culture against open source. I’ve fought many battles to use linux and about every 6 months I’d be pinged to justify why I was using linux and other open source products. Shifting the government on that front would be a miracle.
As far as “shooting the hostage goes”, this remains the sole reason for why rhe PRC developed the Kylin OS.
Indeed, they went even further and developed their own chipsets (“Godson”), which is akin to taking out all possible future hostages just to be on the safe side.
I recommend the July 2009 US Congress Hearing on the subject: http://www.uscc.gov/hearings/2009hearings/transcripts/09_04_30_trans/09_04_30_trans.pdf