Posts by Jim Broome | Man Vs WebApp

So, over the past few days we’ve seen several articles about the recent/potential hacking of one of our military UNAV planes over Iran. Naturally the security geek in me has been piqued to learn more details about how this was done.In the latest information, one of the Iranian engineers talks about jamming the command and control signals to the plane and forcing it to go into auto-pilot mode. Then hacking the plane at its weakest point, aka its GPS system. As a security minded person, I can make lots of arguments on the technical and security related challenges of these statements. However as a big radio frequency (RF) and remote control (RC) enthusiast, I wanted to talk to a few points of this proposed attack and what may or may not be possible.

Command and Control Jamming- If you are into RC planes and are big on electronics then finding out that there are kits out there already to build your own small scale UNAV system is nothing new. U-Nav.com (www.u-nav.com) has been in business for years and makes some of the best solutions for building solutions on the small scale. Their latest kit includes using XBee based radios or modems to send command and control information to the UNAV system from the ground station. As described in the Iranian attack, once this signal is jammed, the software goes into auto-pilot mode. This auto-pilot mode usually instructs the aircraft to fly home or to a pre-determined GPS waypoint and hover (fly in circles) around the waypoint until the command and control connection are re-established or perform a controlled crash (typically a flat spin) once power has been depleted to the craft.

Reading up on the latest Info-warfare solutions that we theorize that Iran has at their disposal, it looks as if they have the proper surface-to-air platforms to use to perform this attack. Just keep in mind that jamming most RF signals is entirely possible, just by broadcasting “noise” on the same set of frequencies that the RF receiver is trying to listen in on.

GPS Jamming – GPS jamming is extremely easy. Heck you can now find complete kits on the Internet to perform just about any jamming you need. Worried about privacy issues, install a jammer. Worried that law enforcement has installed a GPS or Lo-jack tracker on your car, install a jammer. Yep, its that easy.

Note – Just remember that it is illegal for you to build or use one in the US (as well as many other countries).

Waypoint Hacking – This is the most interesting point of the Iranian hack. According to some of the articles, Iran claims to have altered the GPS signal going to the UNAV system and giving the plane enough information to land safely at a location in Iran. What is impressive here are the technical challenges to perform this hack:

Pushing updated data to the craft – The part I struggle with the most, is the claim that a ground-based tracking station/platform was used to performed this attack. As I stated, jamming is rather easy. But jamming while also updating coordinates is complex… especially when doing this to a craft that is above your elevation, fling at 200+ MPH, and you are overriding a signal coming from a satellite that is located above both you and the target. I’d love to hear from any military types on this capability. But as stated, its one heck of a hurdle to overcome.

Knowing the Waypoint to Spoof/Alter – To have the plane land at a location of your choosing assumes you know where its original destination was located at to begin with. Since Iran stated they analyzed several previously crashed aircraft, I’ll have to assume they were able to gather this information through these or more traditional information gathering efforts..aka – everyone in the region knows all the planes come from 1 or 2 bases.

Overriding The Waypoint – The other part I struggle with in the articles is the statement that Iran chose where to land the plane. This basically assumes that they tricked the plane into thinking it was over Afghanistan instead of Iran and was to land at its pre-determined waypoint. All jokes aside about both places being mostly desert, still the locations are not identical. To do this part of the attack, you have to overide not only the physical location but also important factors such as the topology of the landing site… aka altitude, approach angle, and wind direction.

It is these last three challenges that make me question the validity of the “hack” that took place, at least as described so far. But since I know the challenges, I’m also eager to hear on the techniques and solutions to overcome these hurdles. As always, I’ll wait to hear more before giving a final verdict, but just wanted to open up a discussion on the basic hurdles that needed to be overcome for this attack to work.

For those of you who know me as well as Dan, you know that we have spoken quite often on our podcast (Information Security Place Podcast) about the effectiveness of today’s current technologies used by Web Aware Firewalls (WAFs) and Intrusion Detection/Prevention Solutions (IDS/IPS). I’m rarely one to say “I told you so”, but Larry Suto’s latest report on the effectiveness of these technologies, does kind of do that for me.

For more information about the study:

In the WAF effectiveness report, Larry illustrates the need to properly train a WAF solution on the application it is protecting to gain effective or consistent protection from the app. According to the report, it took an average of 3.5 hours by a WAF savy technician to train or tune the WAF solution to get an effective level of protection for the test application. As noted in the report, this is significantly more time spent, than the average organization spends on their production WAF installations.

One issue to note, is that many WAF solutions are leveraged to protect more than one application once they are in production, so can it be safe to say that an organization should plan to spend 2-3.5 hours per application they plan to place behind a WAF to gain that consistent level of protection for all their applications? It could be a safe assumption since many applications are not identical or leverage completely different technologies.

One element of the report I really think Larry does an effective job at illustrating is the lack of effectiveness that a traditional IDS/IPS brings to the table. Since these technologies are not designed to specifically look for your application’s vulnerabilities they require custom rulesets to be created to be effective at protecting your applications.

As announced earlier last month, NT OBJECTives released NTODefend to assist organizations in creating those custom rule sets for both WAF and IDS/IPS solutions. In the report, Larry was able to illustrate the effectiveness of NTODefend at creating custom rulesets that are unique to each of your organizations applications. In both instances, the rules created by NTODefend provided a substantial improvement for all of the platforms that can currently leverage our technology. Note, in some instances the IDS/IPS solutions actually became just as effective if not more effective than some of the WAF solutions, after applying our rules.

All in all, the report goes to show that even with these technologies in place, organizations are still required to perform ongoing testing to find vulnerabilities and then train their WAF or IDS/IPS solutions to protect their applications. Thankfully, at NT OBJECTives we have solutions to help you do just that… NTOSpider and NTODefend.