Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

12/17/2009
09:09 PM
George V. Hulme
George V. Hulme
Commentary
50%
50%

Security Reminders From "Hacked" Predator Drones

The Wall Street Journal reported today that Iraqi militants are able to intercept live feeds from U.S. military predator drones with standard hardware equipment and a $30 software application.

The Wall Street Journal reported today that Iraqi militants are able to intercept live feeds from U.S. military predator drones with standard hardware equipment and a $30 software application.Having the enemy be able to see where you are watching and spying is not usually a good thing, unless it's part of a trick or campaign to confuse. Such as letting the enemy snoop on the wrong things, so they miss what you're really up to. But when it comes to the ability for anyone with a satellite dish, modem, and $30, to snoop on the U.S. military's unmanned drones - I doubt that's what's going on.

According to the Wall Street Journal story the Department of Defense knew that the video feeds were being sent unencrypted:

The U.S. government has known about the flaw since the U.S. campaign in Bosnia in the 1990s, current and former officials said. But the Pentagon assumed local adversaries wouldn't know how to exploit it, the officials said.

It's a cliché in the IT security community, and it's true: you can't rely on security by obscurity and argue that a system is secure. And you don't ever want to underestimate the skills of an IT adversary. But that's exactly what the Pentagon seems to have done if they "assumed adversaries wouldn't know how to exploit it."

Besides: what is the exploit, Really? Grabbing live video-streams broadcast unencrypted over the air?

If you want a system to be secure, a good path to choose is to make it inherently secure. So maybe the video feed service from the UAVs should have of been threat-modeled years ago when the system was being designed. If it had of been done properly, threats would had of been identified and the ones deemed important would had of been mitigated.

Another lesson: it tends to be considerably more expensive to retrofit security into a system, than design it to be secure from the jump. Now, in order to encrypt the feeds retroactively, the government (through its contractor) is going to have to find a way to encrypt the video feeds. Perhaps that encryption will require some form of hardware update for all of the UAVs. It's also likely going to require an update on all of the vehicles that use these feeds, as well as portable troop receivers in order to work. None of this is usually cheap to add after the fact.

The encryption method will require some form of key management. To be of any use, those keys will have to be able to be quickly updated, in the event the enemy is able to get hold of them. In fact, they'll probably have to be updated frequently, because the safest assumption is that the keys are breached from time to time.

All of this would had of probably been easier to initially design and build. Which takes us to another lesson in IT security from this incident.

Building secure systems is not fast or convenient. In the rush to get some capability out on the street, no one wants to hear that the system has to wait for a few hours, days, weeks, or months while it is being "threat-modeled" and security controls are being built-in.

The usual response goes like this: "Wait? What? We ain't got time to wait. We'll deal with those problems later."

The problem is that "later" is also usually when the problem is exponentially more expensive to fix, and you've already been hacked.

It's true of software, and apparently true of UAVs, too.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/21/2020
Cybersecurity Bounces Back, but Talent Still Absent
Simone Petrella, Chief Executive Officer, CyberVista,  9/16/2020
Meet the Computer Scientist Who Helped Push for Paper Ballots
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/16/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Latest Comment: Exactly
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-24619
PUBLISHED: 2020-09-22
In mainwindow.cpp in Shotcut before 20.09.13, the upgrade check misuses TLS because of setPeerVerifyMode(QSslSocket::VerifyNone). A man-in-the-middle attacker could offer a spoofed download resource.
CVE-2020-8887
PUBLISHED: 2020-09-22
Telestream Tektronix Medius before 10.7.5 and Sentry before 10.7.5 have a SQL injection vulnerability allowing an unauthenticated attacker to dump database contents via the page parameter in a page=login request to index.php (aka the server login page).
CVE-2020-7734
PUBLISHED: 2020-09-22
All versions of package cabot are vulnerable to Cross-site Scripting (XSS) via the Endpoint column.
CVE-2020-6564
PUBLISHED: 2020-09-21
Inappropriate implementation in permissions in Google Chrome prior to 85.0.4183.83 allowed a remote attacker to spoof the contents of a permission dialog via a crafted HTML page.
CVE-2020-6565
PUBLISHED: 2020-09-21
Inappropriate implementation in Omnibox in Google Chrome on iOS prior to 85.0.4183.83 allowed a remote attacker to spoof the contents of the Omnibox (URL bar) via a crafted HTML page.