Video Stream for Unmanned Drone Hacked

In what can only be described as a complete failure to plan for security, multiple news organizations are reporting that Iraqi insurgents are able to intercept the video stream sent from unmaned US drones.

It really is amazing that any data would be sent over an unencrypted channel. According to the article, the video was sent via satellite and did not use any sort of encryption. The insurgents were able to use a publicly available satellite grabbing software to intercept the stream.

I have to wonder if this design was something that "slipped through the cracks" or was deemed low risk and too expensive to implement encryption controls.

We will of course never know what decisions led to the lack of data encryption in the drone. We can only hope that this event will be a reminder that any electronic device of value must be designed with a threat model and comprehensive security controls to thwart digital attacks.


-Michael Coates

DefendTheApp - An OWASP AppSensor Project

DefendTheApp.com is now live. This site provides a fully functioning demonstration application that has implemented an AppSensor detection and response capability. The site also provides easy links to all relevant AppSensor information.


Not familiar with AppSensor? The basic idea is this; currently applications use a variety of secure development techniques to prevent an attacker from being able to break into the application. Secure development is great, however, we can't just stop there.

Consider the defensive strategies used by physical banks, prisons, federal buildings, etc. We do use security controls to prevent attacks (locked doors, ID card to enter) , however, we also use a variety of methods to monitor and detect attackers before they have succeeded in their devious intents (cameras, guards, motion sensors, alarms). And in the real world, we put most of our faith in the ability to detect and catch a criminal, not in the ability to design a system that can withstand a relentless and unrestricted series of attacks.

This is the idea of AppSensor. Implement detection points within the application to discover a malicious user that is probing for vulnerabilities. Once the user is detected and a threshold of malicious activity is reached, report the user as an attacker and lock that user out of the application. If you can detect attackers and lock them out before the attacker finds a vulnerability, then you've significantly enhanced the security of your application.

-Michael Coates

Droid Jail Break Released

Jail break code has been released for the new Motorola Droid phone running on Verizon network. The code works for Droid running on Android 2.0 or Android 2.0.1.

Unlike the iPhone, the Android platform is designed to be open. So it will be interesting to see what additional benefits are provided by jail breaking the droid.

A few things to consider before you jail break your droid.

• You put all sorts of sensitive data in that phone.
  
• The phone is linked to your credit card. A malicious app that calls up Cambodia each night will cost you $$$.
• Do you trust that code you are installing on your phone? If it works as described, jail breaking will remove whatever barriers were left on an already open phone. More information is needed, but there is a potential that you are putting yourself at more risk by doing this.
• (Unrelated to jail breaking) Please secure whatever apps you do end up installing. It really was pretty bad when people jail broke the iPhone and installed SSH with the default root password.
  

-Michael Coates

IP Spoofing

If you are using any sort of IP based filtering within your application, then you need to evaluate how IP spoofing attacks affect your security controls. In order to make a fair evaluation you will need a basic understanding of IP spoofing attacks.

Let's look at two different scenarios.

Scenario #1 Attacker wants to spoof an arbitrary IP address and the attacker is not on the same subnet (broadcast domain) as the targeted IP address. Example: attacker is 1.2.3.4 and wishing to spoof 4.5.6.7

Scenario #2 Attacker wants to spoof an IP address of someone on his own subnet (broadcast domain). Example: attacker is 192.168.1.55 and wishing to spoof 192.168.1.58 (assuming subnet of 255.255.255.0)


Scenario #1

The attacker can create forged TCP packets and modifies the source IP address to be any value. One tool that can do this is HPING2.

What can you (the attacker) do:

• Send an initial TCP packet with any source IP address
• Send a series of UDP packets with any source IP address
• Send a series of unrelated TCP packets from the same or varying IP addresses

What can't you (the attacker) do:

• Receive any responses to your forged messages. The responses, if sent, would go to the forged IP address.
• Send a string of related TCP packets (e.g. reconstruct an actual TCP exchange). This is because you can't complete the handshake or guess the necessary information to continue the TCP connection.

Scenario #2

The attacker can perform a variety of attacks to forge or take-over the IP address on the same subnet.

Attack Options:

• Simplest - Statically define your IP address to the target IP address
• Switch your MAC address to the MAC address of the current NIC for the target IP address and attempt to assume control of IP
• Execute man in the middle attack via arp spoofing (see tool Cain & Abel) and then gain control of user's unencrypted transmissions. You could likely modify or redirect traffic to accomplish your original spoofing goal.

What can you (the attacker) do:

• Assume control of the IP address. Note: This means you can send/receive valid data using the targeted IP address as your own. It does not grant you access to existing sessions that the user had with any websites (because you don't have the user's session cookies).
  

What can't you (the attacker) do:

• Intercept encrypted (e.g. SSL/TLS) communication destined for the target IP address without alerting the targeted user in some way (browser warning message for MitM invalid certificate).
  

Hope this is helpful. This is by no means an exhaustive list of attack techniques, but something to consider if your are using IP related controls within an application.

-Michael Coates

iPhone Privacy Presentation

• Slides 1 - 14: History of iPhone privacy issues
• Slide 15: Personal data that can be easily accessed by rogue applications
• Slide 19: Recommendations to mitigate security concerns on iPhone

Link to original pdf


-Michael Coates

iPhone, Android Support Weak SSL Ciphers

Mobile devices are handling increasingly sensitive data as financial and banking applications are deployed to the iPhone and Android based phones. However, the challenges of SSL/TLS are being revisited on these mobile devices. Unfortunately, we are not learning from our previous mistakes with standard browsers.

Today I discovered that both the iPhone and the Android software emulator (sorry, don't have a droid yet) both support weak cipher suites. For example, both devices support DES-CBC-SHA as well as a slew of other weak ciphers. To put that in perspective, DES was phased out of FIPS documents in 2002 and could be broken as early as 1999.

All modern web browsers that I have tested on computers (e.g. not mobile devices) have all disabled support for any weak cipher suites. It is quite amazing to see such a step back for mobile devices.

What's the impact? Unfortunately, many high profile web servers also support weak ciphers. As a result there is a possibility that the iPhone or Android browser could be paired up with one of these sites and decide upon a weak cipher suite. This means that all of that sensitive financial information will be exchanged using an encryption that could be broken by a determined attacker.

A few screen shots:

iPhone connecting with DES-CBC-SHA



Android emulator connecting with with DES-CBC-SHA




Confused about SSL/TLS? Let OWASP help you - TLS Cheat Sheet

-Michael Coates