Hacking Risks for Satellites Felix FX Lindner Head of Recurity Labs
Agenda Review of hacker interest in satellites Motivations and Methods Current and emerging trends in satellite hacking Lessons from computer security challenges in similar fields Recommendations for secure design and operation
History of Hacker Interest Generally, hackers are interested in everything that is technologically challenging I was introduced into hacking by people who broke into Russian military/spy satellites for imagery Astra signals were decoded by hackers using Commodore C64 home computers Satellite Pay-TV used to be the driver of interest
Satellite Hacking Presentations at BlackHat and DEFCON Year Title 1998 Low Earth Orbit Satellites 1999 Future & Existing Satellite Systems 2003 Satellite TV Technology 2004 Weaknesses in Satellite Television Protection Schemes 2007 How to freak out your Satellite Navigation 2007 Satellite Imagery Analysis 2009 Satellite Hacking 2010 Playing in a Satellite Environment
Top 5 Recent Hacking Incidents Stuxnet: Using a highly specialized computer worm to delay the Iranian uranium enrichment program Aurora: Using 0day attacks on client computers, attacking Google and several other Fortune100 companies over 1-2 years to extract their intellectual property RSA: Breaking the security of the most widely used and trusted one-time password token system in the world to break into US defense contractor networks HBGary Federal: Breaking into all relevant email accounts of a defense contracting consultancy and publishing the contents LulzSec hacktivism: spending 50 days to break into Fox News, PBS, Nintendo, pron.com, the NHS, Infraguard, the US senate, Bethesda, Minecraft, League of Legends, Escapist magazine, EVE online, the CIA, The Times, The Sun
Motivation Drives Goals 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% Confidentiality Integrity Availability 0%
Days of Attack 2,000 1,800 1,600 1,400 1,200 1,000 800 600 400 200 - Anonymous LulzSec Recreational Cybercrime Military BlackHat Services
Emerging Satellite Hacking What would one need to do in order to hijack a satellite? August 2011 on IT Security Exchange Voted Security Question of the Week Hackerspace Global Grid The hacker community needs a fallback infrastructure in case of natural and economic disaster to stay connected. Highly publicized as visions of space-borne 'SOPA Wars Constellation Constellation is a platform for research projects that use Internet-connected computers to do research in various aerospace related sciences and engineering. Small Satellites Program Stuttgart To allow the development of satellites despite high space transportation costs it was necessary to apply miniaturization and new space technologies
Satellite Assisted Hacking Most satellite hackers come from DVB background Accordingly, they keep their hardware as it is and explore 32% of all easily observable satellite traffic is now some corporation s network traffic (TCP/IP) The satellite downlinks provide the most convenient attack path into corporate networks The ability to see one part of all the communication enables many attacks that are otherwise a lot harder Reputation databases for IP address blocks have a dedicated field for Satellite Provider
Satellite Assisted Hacking Example
Breaking Satellite Phone Encryption Secret encryption algorithms developed by European Telecommunications Standards Institute (ETSI) Researchers from Ruhr University Bochum (Germany) simply obtained the respective phones and reverse engineered them GMR-1 turned out to be similar to GSM A5/2 Cipher text only attack possible due to design flaw Requires about 30 minutes on a standard PC GMR-2 is only slightly better Design weaknesses allow known plaintext attacks
Future Targets TT&C intrusions in order to obtain control when it is needed More intelligence in satellite payloads (e.g. IP routing) highly increases chance of successful direct attacks Removes the need to attack TT&C Nations could consider attacks on launch control systems in order to prevent new military satellites from reaching orbit
He who doesn t understand history is doomed to repeat it. And when it's repeated, the stakes are doubled. - Pittacus Lore LESSONS FROM THE FIELD
The Domain Knowledge Myth One of the most common myths: The domain specific knowledge required to attack our stuff is not readily available. Disproved countless times in all domains Keep in mind that we are no longer talking about bored teenagers A few quotes from hackers describing satellites: Higher-level protocols may be standard TCP/IP, plaintext, encrypted, or some totally imaginary 17 bit codeword system. The weak link are satellites themself. When you build a satellite, you don't care about security, but you care about MTTF (mean time to fail) and MTTR (mean time to repair). All I'm saying is, it's hardly rocket science.
The Secret System Myth Assumption that the attacker needs specifications of your system in order to attack it is wrong Reverse engineering is what drives many people. You are providing an incentive, not a deterrent! Secret encryption is the worst form of the secrecy myth In 1883 Auguste Kerckhoffs defined in the design principles for military ciphers (now known as Kerckhoffs Principle): It must not be required to be secret, and it must be able to fall into the hands of the enemy without inconvenience. Common Weakness Enumeration CWE-656: Reliance on Security Through Obscurity
False Focus People tend to look at potential security threats to their system by how they would attack it Lack of formal threat modeling uses up all the time and budget in the wrong place Firewalls, anti-virus, intrusion prevention Even most penetration tests are done wrong! You cannot attack this TT&C, it s in production! The hidden agenda is often to limit the scope of a penetration test to the maximum level of ineffectiveness, in order to look good to higher management and customers
It can be done right. DESIGN AND OPERATION FOR SECURITY
Threat Modeling Threat Modeling is a well established process to holistically determine possible attacks, mitigations and defenses of a complex system Identifies processes, external actors, data stores and data flows Establishes expected trust and process boundaries Results in data flow diagrams (DFD) of increasing detail Systematically working though all threats automatically determined from the DFDs models attacker process Results in efficient investment of the scarce defense resources
Test and Audit The only way to really know is to try it Use people with a track record in such things. They may be harder to get, but they are worth it. Follow your threat model Don t exclude components from 3 rd parties Verify the promised properties of everything Once you know what you can rely on and what not, you have won half of the battle
The Environment Dictates Everything There is no one size fits all We have developed solutions in automotive, aerospace and medical environments Specialized cryptography protocols Multiple secure fallback mechanisms Zero maintenance scenarios Several of our customers are now 5+ years ahead of their industry, while their competition makes the news in undesirable ways The longer the lifetime of your product, the better security the payoff from early security investments
Predictions are hard especially if they concern the future Halvar Flake CONCLUSION
Satellites are Collateral Targets 1. High-end attackers focus on high profile targets 2. High profile targets make ever increasing use of satellite communications 3. Everything in the satellite infrastructure is a perfect vantage point for the attackers Satellites will be attacked to hit their customers
Thank you. Felix FX Lindner Head fx@recurity-labs.com Recurity Labs GmbH, Berlin, Germany http://www.recurity-labs.com
Felix FX Lindner Founder, technical and research lead of a high-end security consulting and research team 23 years of computer programming 15 years of attack specialization 10 years of speaking at IT-security conferences First remote exploit against Cisco routers First attack programs running on HP printers First network router forensics system First provably secure solution for Adobe Flash
Recurity Labs GmbH Program code audits for security and reliability 30+ programming languages, 15+ CPU architectures Security Architecture and Design Reviews, verifications and proofs Invention, development and prototyping Challenging customer base Large scale scenarios Long living products Non standard requirements