In December, the Wall Street Journal reported that militants in Iraq used inexpensive off-the-shelf software to intercept live video feeds from USA Predator drones, potentially providing them with information they need to evade or monitor US military operations. This episode highlights the emergence of a shadowy cyber war being waged against the US-led missions. Such events also point out a serious vulnerability in Washington's growing use of unmanned drones, which have become the weapon of choice in these theatres of operation.
How exactly does something like this happen? More important, what needs to be put into place to thwart attempts to do these sorts of things?
We need to understand how and why it happened to look at how to prevent these events from happening again. The report claims that the Shi’ite militants in Iraq used software programmes such as Sky Grabber to intercept the video feeds by taking advantage of an unprotected communications link (the drones used Cleartext transmission instead of encrypted) in some of the remotely flown planes' systems. Sky Grabber is developed by Sky Software, a Russian company that provides the offline satellite internet downloader for €21. It accepts free to air satellite data and saves information to a hard disk.
According to its web site: "So, you'll get new movie, best music and funny pictures for free.”
The same software used to steal TV shows is being repurposed in a rather innovative way to attack the drone missions.
The US government has known about the drone vulnerability, using unencrypted downlink between the unmanned craft and ground control since the US campaign in Bosnia in the 1990s, but has not corrected the problem for three reasons. The Pentagon first assumed adversaries wouldn't know how to exploit the weakness; secondly, adding encryption to the drone network that is more than a decade old involves much more than a new piece of crypto equipment on a drone. Many components of the network linking the drones to their operators in the USA, Afghanistan or Pakistan would have to be upgraded to handle the changes. And, finally, fixing the security gap would have caused delays, according to current and former military officials, and would have added to the Predator's price.
It turns out that this exposure is not a unique occurrence, but yet another example of the difficulties we face in a world of rapidly changing needs and requirements of systems that drive the need for modernisation, but at the same time we are being pushed to cut time to deployment in the field and to keep costs down.
The answer to these and other weaknesses exposed by rapidly changing threats is modernisation. The systems should be modernised through the addition of standard requirements that all systems that communicate between components on any kind should use, coupled with an ability to test and verify that these additional requirements are met without injecting dramatic time or cost additions to the delivery of these systems.
Are not these concepts usually mutually exclusive? Can this actually be accomplished? The answer is yes.
At the end of 2008, an international group was formed to characterise and prioritise a list of the most significant errors that can lead to serious software vulnerabilities. The group was the collaboration between several entities: the Sans Institute, Mitre and many top software security experts in the USA and Europe. It leveraged experiences in the long-standing understanding of the Sans Top 20 attack vectors and the more recent common weakness enumeration (CWE). Mitre maintains the CWE web site, with the support of the US Department of Homeland Security's national cyber security division.
To help characterise and prioritise entries, a threat model was developed as part of the effort that recognises that attackers have solid technical skills and are determined enough to invest time into attacking an organisation.
This list has recently been published, and is called the 2009 CWE Sans Top 25 most dangerous programming errors. It breaks the list into three groups of weaknesses:
• Insecure interaction between components: insecure ways in which data are sent and received between separate components, modules, programmes, processes, threads or systems;
• Risky resource management: ways in which software does not properly manage the creation, usage, transfer or destruction of important system resources; and
• Porous defences: ways related to defensive techniques that are often misused, abused or just plain ignored.
The area of interest for making a system such as the compromised drone safe and secure is the interaction between components section. There are nine areas of weakness identified that if corrected or prevented can make for a system with high integrity software:
1. Improper input validation
2. Improper encoding or escaping of output
3. Failure to preserve SQL query structure (SQL injection)
4. Failure to preserve web page structure (cross-site scripting)
5. Improper sanitisation of special elements used in an OS command (OS command injection)
6. Cleartext transmission of sensitive information
7. Cross-site request forgery (CSRF)
8. Race condition
9. Error message information leak
Obviously, adding the elimination of these weaknesses as new requirements for any existing system would make it safer and more secure, but many see this as adding huge amounts of additional time due to the extra exhaustive testing necessary that slows delivery and increases costs beyond control. There are new tools and techniques that can add support and verification of these requirements and still deliver on time.
Static code analysis techniques can identify most if not all of these weaknesses, depending on the vendor, in an automated fashion. For those unfamiliar with these tools, static analysis is the analysis of the software system that is performed without actually executing the programmes. The analysis is performed on the source code and in some cases on the internal representation that is created from the compilation of the code. The sophistication of the analysis performed by tools varies from those that only consider the behaviour of individual statements and declarations, to those that include the entire source code of a programme in their analysis to perform deep inter-procedural analysis of the system.
Static analysis tools can be used to identify eight out of the nine identified issues automatically without the need to add any additional unit or system tests. The other tests would have to add functional tests and/or the use of dynamic analysis tools.
These types of weaknesses are usually considered programming errors, but they can affect the architecture of the system. Modernisation efforts for the architecture of systems also need to take component to component security into account. Architects can also employ static analysis tools to help in this area.
There are active threats that take advantage of known weaknesses in our weapons systems. We need to modernise these systems to meet the challenges of the 21st century. Requirements to close and verify the known weaknesses that international organisations have identified need to be adopted as part of the requirements for new or modernised systems. The incorporation and use of static analysis ensures that the requirements to identify and remove these weaknesses accurately are met and verified while not adding additional manual testing efforts that slow delivery or add additional costs.
Thomas Schultz is a software integrity consultant for Coverity