I used to make avionics for a living and I don't even understand what this man is talking about. (I don't think he does too) That seems to be just an ACARS sniffer.
ACARS and ADS-b has nothing do to with aircraft control systems. You don't need an android app to intercept satellite communication and even if you 'root' the ACARS computer, it is not connected to the systems that could control the airplane.
Also: to pass DO-254 at level A you must have physical switches for flight/computer functionality, that said, no software can engage autopilot or change AP behavior, you need physical switches to do that. They are NOT similar to keyboard buttons, those switches actually interfere at the hardware level.
There seems to be two threads here bashing heads against each other
1. The specific details of this (admittedly movie-plot-threat) are wonky and not believed by reasonable people in the industry
2. The digital security of most systems when looked at by Internet-hardened veterans is somewhere between vulnerable and laughable, so why should planes be different (ie gas and water control pumps with ethernet ports and factory set default passwords like admin)
2. seems to be most peoples default response - "hey look, another thing thats been connected to the internet, its probably wide open"
That is a good response to have as a) anecdotally it seems to be right 9 times out of 10, and b) its the right side of caution anyway.
The fact that 1. is much harder to do than perhaps shown is indicative that things in the FAA arent as bad as say, sewage treatment industry.
But, even so, all our systems are now connected and so much more vulnerable. And even if this guy cannot down planes with his android phone, he has gotten a hell of a lot closer than anyone not totally paranoid would assume.
I think the correct response would be
This specific setup does not apparently live up to the
media hype. However, all digital security is undergoing a
period of massively increased attack, and we should never
be complacent. He has gotten further than we expected
feasible and will be looking at a program of fixing attack
vectors run under the same rules as air-crash
investigation. Any known bug is investigated, understood
and a comprehensive solution made transparently available
to the industry.
The airline industry is rightly proud of its safety record, and it should see this as an opportunity to become rightly proud of its digital security record too.
UCSD and UW researchers have demonstrated the ability for an attacker to take full control of many modern cars just by dialing the car's 3G modem.
By "full control", I mean everything from "unlock the doors and start the engine" to "engage/disable the brakes and stop the engine"
Over a range of experiments, both in the lab and in road tests, we
demonstrate the ability to adversarially control a wide range of
automotive functions and completely ignore driver input — including
disabling the brakes, selectively braking individual wheels on demand,
stopping the engine, and so on. We find that it is possible to bypass
rudimentary network security protections within the car, such as
maliciously bridging between our car’s two internal subnets.
Edit: No, they really did demonstrate these vulnerabilities on real cars, it's not a theoretical analysis. Here's a link to their full research talk: http://www.youtube.com/watch?v=bHfOziIwXic
Unfortunately, the article you cite is similar to OP's article.
In this paper we intentionally and explicitly skirt the question
of a “threat model.” Instead, we focus primarily on what an attacker
could do to a car if she was able to maliciously communicate on the
car’s internal network. That said, this does beg the question of how
she might be able to gain such access.
While we leave a full analysis of the modern automobile’s attack
surface to future research, we briefly describe here the two “kinds”
of vectors by which one might gain access to a car’s internal networks.
So, no, they didn't ACTUALLY dial a car's 3G modem. That is merely a theorized attack vector. There is no proof of concept here.
No, they really did demonstrate these vulnerabilities on real cars, it's not a theoretical analysis. Here's a link to their full research talk: http://www.youtube.com/watch?v=bHfOziIwXic
I've been to both the UW and UCSD security labs and have seen their videos. It's real.
This is ongoing work and honestly I cited the first article I could find.
The comparison here oversimplifies. Avionics engineers are on this thread saying there's no physical/logical connectivity between RF and flight control systems. But that's not true of cars; we know cars do have at least some RF controls, and we're far less certain of the connectivity between CAN devices in a car than the avionics people are of the connectivity between ACARS and flight control.
Here is a video of a similar attack being performed on a real car by another researcher who discovered the same vulnerabilities/attack vector in parallel to the academic team (1m30s):
2) The slides don't provide enough details, I haven't had time to listen to the talk to see if it fills in more info - the critical part is how/if he's managed to convince the FMS to accept ACARS uplinks other than the 'harmless' three defined uplink messages that are automatically accepted by the FMS without pilot acknowledgement. My guess is that by having access to a FMS code/simulator, he figured out a buffer overflow or other hack that lets him inject FMS command messages without pilot acknowledgment, which is normally required of all other uplink messages.
3) In my admittedly tiny amount of experience, the designers of avionics communications protocols aren't dumb. They tend to be very old-school looking formats (low level, fixed fields, etc) because they were often designed when avionics equipment had little processing power, but at the same time this means that the format spec has a small surface area. Also sometimes it's possible that there's not 'security' as we think of it in terms of encrypted links, but there is often a lot of thought put into the messaging sequence (send/ack/etc), including pilot confirmation, to ensure that garbage isn't accepted.
I used to work on interfaces to all the computers on the latest 747 and the 787 and there is no wireless way to talk to any of the computers or sensors that have any input to controlling the airplane.
I am not making this up.
On the 747-400 I was on a group whose computer got input from all the 70+ computers on the airplane. It was all wired.
On the 787 I worked on a database during the development of the airplane that tracked all the information that flowed between computers. Nothing came to any computer that controlled the airplane that was not by wire or fiber optics.
I also dealt with ACARS. It is a read-only system on the airplane. It gets information from other computers and transmits it via satellite to the ground.
But do any of those 70+ computers receive RF input? Are there any RF receivers anywhere on the same wired network--or is all RF reception air-gapped from flight control?
"I used to work on interfaces to all the computers on the latest 747 and the 787 and there is no wireless way to talk to any of the computers or sensors that have any input to controlling the airplane."
Don't they get weather data from somewhere? And if the pilot thought there was a thunderstorm or heavy turbulence in some direction, wouldn't they fly the plane through what appeared to be the clearest route on their own? (And does the autopilot not take weather into account?)
Yes, most (if not all) modern airliners have a radar dish in the nose of the aircraft. If you wanted to mess with this, you'd have to spoof radar echoes. Not something you can do from an android phone for sure.
"And does the autopilot not take weather into account?"
No, not in the slightest. Pilots adjust autopilot settings to account for weather. It is not automatic.
i believe you only dealt with the intended usage of the APIs and interfaces?
this may be the same as someone that sets up a SCADA to the local city water&power and believe the intranet is isolated, until a month later another contract requires for a public server in the office and they just connect the entire thing to the internet.
Let me add to the surprise. I once wrote a nice piece of software that controlled hospital equipment (automated blood coagulation analyzer, to be precise). It is a quite serious piece of equipment used for post-operation patient recovery. As far as I know, a well regulated area.
Equipment went through stringent certification, passed all tests, deployed in hospitals, etc. All well and good, right? Did I mention, that I was 13, when I wrote that piece of software ;) And I guess you can imagine the quality of that code :)
Well, to tell the truth, that story has happened almost twenty years back, before outsourcing really kicked in. Equipment was developed in Russia, for Russian market. And I also had some five years of playing with C/x86 asm, by the time I was 13.
So no, it actually was not that bad. No kids were harmed, and no QA teams in India were involved.
" Attacks of this kind work only when the auto-pilot is on, so the trick is to switch it off, then fly the plane by using analog instruments. "
Seems like auto-pilot is required to be on already. A wild guess, but maybe his exploit feeds the auto-pilot incorrect information, causing it to make counteracting decisions that effectively give him control.
I'm guessing the exploits he's talking about are buffer overflows in the on-board ACARS receivers. Correct me if I'm wrong, but I think that ACARS can directly update/access the FMS? If so, then you could exploit the vulnerability to change data in the FMS. If the autopilot is in nav mode, i.e. set to follow the flight plan in the FMS, then you could alter the course the plane follows.
Perhaps also there is stuff you could do with the weight/balance info stored in the FMS?
(I lost my reply on a copy-paste / expired link, let's try again)
Sensors 'broadcast' the information across the systems in a very simple way (electronic but not hackable). Everyone get its data directly from sensors.
The FMC is like a pilot without hands. It is a client of the flight control system (another computer) like the pilot itself. When the pilot connects it (this is physically controlled) it can change the parameters of the AP, but it stills not controlling the airplane.
Hypothesis (this is wild): you physically get to the FMC and hack it. The only thing you will be able to do is to change the route (only if) it is engaged. But under a class A/B airspace, this will be immediately be noticed by air controllers that will notify the pilots. Anyway, the pilot should notice it right away. The FMC functionality is very restricted, really.
Wow, you used to work on avionics software? What was it like? Were the software development practices different? Did you use any static analysis / verification software to prove correctness? What were the software people at your company like? Were they all old guys with really conservative software development practices based on their battle hardened experiences? Were a lot of the people you worked with pilots?
(Apologies for taking the thread OT, I'm just getting my pilot's license now and have always been fascinated by avionics.)
Did you read the part of the article that says,
> gather information about the onboard computer as well as to exploit its vulnerabilities by delivering spoofed malicious messages that affect the "behavior" of the plane.
Being able to control the flight management system, which as you probably know controls much of the automation in a plane including the flight path and position sounds pretty dire. Also sending false data to a plane/pilots poses a security threat in of itself without taking over the FMS.
The spoofed messages is easy to believe, but these message systems (ADS-B and ACARS) do not interface with the FMS and thus an attacker should not be able to take over the FMS in this way. So some critical piece of information is missing.
Most crashes happen due to pilot error, especially connected to the instruments.
Something as simple as a bad from the six-pack of a small plane could be bad news (note: these are usually 100% mechanical systems). As a pilot of small aircraft, goofing up my instruments might help me tie the world record for "lowest flight ever". Something as simple as coordinating my turns with a bad indicator might make me go into a spin (I'm fairly inexperienced).
I can only imagine what would happen to a big jet.
> Something as simple as coordinating my turns with a bad indicator might make me go into a spin (I'm fairly inexperienced).
Please don't take any (more?) solo flights until you've remedied this. It should be possible for a pilot to safely fly a small aircraft with no instruments whatsoever in VMC. Instruments do fail, and you must be ready. If you'll spin just because your turn coordinator is wonky, you're not safe.
I've lost airspeed, altitude, and turn coordination. (Not at the same time.) The airspeed one got very interesting due to several confounding factors all hitting at once, and the other two were non-events. I would not sit in a cockpit without an instructor if I wasn't confident that I could safely return to the ground even if the entire instrument panel went away.
Large aircraft are different, but please, get better training on no-instrument flying in your small craft.
You need your instructor to start covering up some instruments when you're flying. A typical single engine aircraft is pretty easy to fly without any instruments at all.
That said, bad instrumentation can certainly take down a plane; Air France 447 was a combination of iced up pitot tubes (no air speed indicator) and bad piloting (incompetent stall recovery).
HOWEVER, as a few other people have pointed out, this guy is only interfering with ADS-B and ACARS. Both of those are situational awareness tools, not flight instruments. I am aware of no commercial flight that has gone down due to a failure of situational awareness instruments.
Taking out ADS-B and ACARS is no worse than taking out ground-based radar and VHF radios. People have known how to mess with radar and radios since their inception, but that hasn't posed a security risk for aviation. I expect ADS_B, ACARS and GPS vulnerabilities to be the same.
There's a logical fallacy in there. Having access to the mechanism that causes "most accidents" only allows you to cause accidents with a frequency of the order with which those system failures cause accidents already.
"Instrument-related pilot error" may (citation needed) cause "most accidents". There are still vanishingly few instrument-related pilot error accidents.
(And in any case, ACARS isn't really an instrument, it's a datalink standard for communication with the outside world -- instruments internal to the aircraft don't use it.)
Step 2) How likely is someone to catch me on the details? (Low)
Step 3) How dramatic can I make this sound?
Step 4) Press Release / Slide Show / Simulation
Step 5) Enjoy sugar hit of popularity.
Step 6) Get asked about vuln / exploit / PoC
Step 7) Fffuuuuuuuuu... Look! Jazz hands!
Step 8) Go to Step 1.
If you work for a boutique security consultancy, interleave elements of panhandling to various customers, clueless managers beating their chests and claiming expertise, and the occasional Congresscritter / Talking Head interview.
It is frustrating that this kind of noise drowns out the signal of actual, thoughtful research or reasonable disclosure. It is the hacker equivalent of security theater where Sensational New Discoveries (TM) distract from hard work and serious issues.
This is more true than not true (my friend Chris likes to call these talks "look at this debug port debugging!"). Some caveats, though:
* Some of these talks are real. For instance, bodega ATMs could in fact be jackpotted. You really could open up most of the hotel room locks.
* Some of these talks involve genuinely interesting technical challenges. For instance, anything involving custom RF work. Or the tolling systems, which also had hardware cryptography. You can appreciate these talks just for technical walkthrough.
* In almost every instance, talks like these target industry verticals where there is little to no attention given to software security. A different kind of software developer works on the firmware for a utility smart meter. There is value in forcibly plugging them in to software security.
As an owner/operator of an established boutique security company, I'd push back a little on the panhandling dig. First, the giant security companies are just as bad about that. Second, not every boutique firm traffics in "look at this debug port debugging" talks. I don't see a lot of BS Stach and Liu talks either. For that matter, n runs has a good reputation too.
"Look at this debug port" is spot on, and relevant in the case of the bodega ATM. It's a WinCE single board computer behind a pathetic lock. Pointing out the silliness of the design is relevant. The theatrics that followed? Not so much.
I think it is fair to say not all boutiques play the sensationalist card. The ones that actually refuse to do this presentation clown cycle suffer some damage and have to work harder, because the showy ones grab mindshare while.
I also agree, the big ones do it, too, but it is harder to pick out against the slow lumbering noises as they rumble from one puppy mill PCIDSS gig to the next.
I liked Barnaby Jack's presentation, but I have a bias for people who came up at eEye.
I think there's room every year for 1-2 theatrical security presentations --- not that I want to give them! --- and that demonstrating that it's easy to jackpot an ATM or pop open a hotel room door is a perfectly valid bit of theater.
I also think some topics become theatrical without sacrificing technical value. For instance, Nate Lawson, Peter Ferrie and I picked a fight with Joanna Rutkowska a few years ago. There was a lot of drama. But the drama was about the accuracy of HPET timers, the AGP GART, and whether we could probe the branch translation buffers to detect hypercalls. I don't think it should have mattered if we got on stage in clown suits and shot nerf guns at the audience; if you're giving a talk about address remapping chipsets, I think it's all fair game. (In fairness: Rutkowska did not agree about the value of the drama.)
I agree that the theater gets tiresome, and, in particular, I think if you're going to shoot for theater, you'd better be right. Your exploit should work. It should work in the real world. It should be repeatable. The problem with the hype cycle here isn't that "taking an airplane down with an Android app" is a bogus topic. It's that you don't believe it's actually possible.
I've done the media thing occasionally. It certainly works, and it's fun, but it's also feels like a distraction from doing the important things.
Many years ago a group of folks tried to move the industry away from the "find a bug, win a prize" model that the industry had settled into, seeing it as a local maximum. They didn't seem to have much success.
ADS-B, this is just automating a couple of things, firstly the classic mode-c transponder. Secondly things like weather information and other such, which is often read out on good old analogue radio such as AWOS.
Messing around with that wouldn't be any different from people just SQUARKing fake data.
I suppose there could be opportunity for security exploits on the digital device listening, but the airline industry is very legally enforced at applying updates.
With regards to ACARS I have no idea, as a PPL my rust bucket has nothing that fancy. I suppose there could be buffer overflow type things, or a flaw in the encryption.
However I still feel that this is a little bit sensationalist, as it stands you could create chaos as it just VHF radio and voices.
There's a huge difference between an old-style transponder and ADS-B in terms of spoofability. To make a transponder position show up on radar, you need to actually put a transponder there. You can spoof altitude to an extent, and you can potentially spoof being farther away by delaying your echo, but you can't spoof the radial at all. And you can't spoof being closer than you really are, which means you can't e.g. falsely trigger a TCAS system.
ADS-B is a simple broadcast of coordinates. Spoofing a position there is just a matter of broadcasting coordinates that aren't where you actually are.
True, but given the way the ATC or TCAS receivers work, they really care about the history of the echos.
They are looking for a vector. It would be theoretically possible to create a ghost, give it a speed and heading to make people avoid it. But I'm not sure what it would achieve. Maybe I'm not being creative enough.
Thing is though, why would that be any different to "FY holding London NDB UFY 60 descending 40." on the radio. If you then dropped off the radio completely a massive poostorm would happen as ATC tried to figure out who that transmission came from. Whilst ATC have to try and find the plane that thinks it's got full service in class-a space (non pilots this is the busy bits of sky where you have to get permission from guys on the ground) they would divert away from that area.
I'm not aware of a TCAS system which doesn't alert the pilot to the fact it is changing the autopilot heading. If this happened in busy controlled airspace, it would have to be with acknowledgement from ATC or the pilot would at worse do a near miss to avoid a phantom that wasn't there, he certainly wouldn't hit one that was to avoid a ghost which ground wasn't warning him of.
If you're over the north atlantic and the TCAS wants to change heading or attitude, it will alert the meatbag AFAIK.
History is a good point, but does TCAS really care? I thought it was a fairly simple device in that regard. It has only vague directional sensing.
As for twiddling the autopilot and acknowledgement with ATC, I'm not aware that either is the case. TCAS simply informs the pilot, and current systems never advise any horizontal maneuvers, only climb/descend, because their ability to detect horizontal position is fairly crap. A TCAS advisory takes precedence over ATC commands and is expected to be obeyed immediately unless there's an obvious immediate danger to doing so. You never inform ATC of the TCAS alert and ask what to do, you always obey the machine, then tell ATC what's going on when you have time. If ATC notices the impending collision and gives you instructions that contradict the TCAS's instructions, you follow TCAS and ignore ATC.
I'm doubtful. I believe you could easily spoof ADS-B and ACARS messages, but I'm not sure how that gives you control. The best I can think of is that you could spoof other airplanes nearby, and trigger TCAS (collision avoidance) to automatically move in the opposite direction. There is no way the pilot's would notice this, though.
The only other option is, as another commenter mentioned, a buffer overflow, or similar, that would allow the ACARS receiver to load a program in the FMS. In normal operation, FMS programs are not controllable remotely.
The only other option is, as another commenter mentioned, a buffer overflow, or similar, that would allow the ACARS receiver to load a program in the FMS. In normal operation, FMS programs are not controllable remotely.
This is the clear implication in the article - compromising the ACARS receiver, then using that access to further compromise another element like the FMS. The article states that the pilot can regain control by disconnecting the AP.
Note that maneuvers prompted by TCAS aren't automated. The TCAS system tells the pilot, who then obeys the machine. (Or sometimes he doesn't, and then the two planes might bump.) So, yes, definitely can't go unnoticed by the pilot, since he's an integral part of the system.
I'm not an expert, all my knowledge about ADS-B is what I gained while writing dump1090[1].
The vulnerability of ADS-B, as I understand it, is the ability to mimic that there is a collision with another aircraft, since it is trivial, as far as I can tell, to send a message impersonating another aircraft.
There is no cryptography of authentication whatsoever in ADS-B, you just write the aircraft ICAO address into a field.
So if I simulate aircrafts in collision route, I think the system will tell the pilot to climb or the reverse, depending on the condition. Maybe this can be used to create troubles...
You are correct, but modern receivers will actually use the transmitter like a "NDB" and will detect that the incoming position is not the same as the stated in those messages, ignoring them.
The same thing happens with sudden changes in GPS messages that are completely out of alignment with the inertial system, they will be ignored. (unless you somehow are capable of knowing exactly where the plane is and gradually hack the GPS messages)
ILS systems are maybe the most dangerous and prone to hacking, but keep in mind that those frequencies are under surveillance and police is dispatched within seconds of a clandestine transmission on those frequencies. Again, here the gps and inertial is also used to guarantee nothing completely wrong is accepted as valid ILS sources.
How are ILS frequencies policed? Does the airport have receivers in multiple locations which automatically detect a failure, and notify someone in the tower?
Collision avoidance is not a function of the transponder. ADS-B merely communicates the position of local traffic.
ACAS is responsible for determining the vectors for the aircraft and the local targets. If there is a collision path calculated, ACAS then communicates with the target's ACAS to determine which way each aircraft is going to move. The pilot is then responsible for executing this action.
I find the skepticism here a little surprising. These are unencrypted, trivially spoofable protocols that haven't been exposed to attack before--of course there are going to be buffer overflow bugs and unexpected, exploitable connections between vulnerable components and critical systems (if they're not already the same machine).
(I believe if you spoof ADS-B it means you can generate TCAS warnings, which pilots are trained to prioritize over ATC commands due to earlier incidents where TCAS was correct and ATC was wrong: http://en.wikipedia.org/wiki/%C3%9Cberlingen_mid-air_collisi... )
They issue isn't can they be spoofed? It is can you crash a plane remotely? Or even can you force a plane to go somewhere? The answer to both is basically no. You can confuse the heck out of the pilot, and possibly make them do some maneuvering until they ignore the system (and send the police after you).
Realistically the idea of putting encryption on ADS is one of the stupider ideas ever. I mean can you imagine a crash caused because someone didn't update their CA list, and thus it rejected a the signature of another plane?
Anyways, you could just jam the whole ADS-B system for your region. The system is protected by aggressive action against rogue transmitters.
Also the "with an android phone" part is disingenuous, as you'll need a fair amount of equipment.
From the linked article and the slide deck, I've determined that the only thing exploited was the simulator software, which was running on a machine that the group already had full access on. There's no avionics being used in this. They're 'simulating' a set up with commercial PCs and training software. They're using the two communications standards, ADS-B and ACARS to communicate to a 'box' that they already had control over and already hooked into.
"In real life, the range would be limited depending on the antennas used (if going directly for the plane), or global (if misusing one of the two big ACARS players such as SITA or ARINC)"
It seems to me that the article has a lot of "in real life" caveats. Theres a lot of elements that have to be in place in order for an attack like this to work, beginning with the fact that the attacker would need a powerful, very specific transmitter for the ACARS frequencies.
The way I see it this look more of a publicity stunt than anything else.
I have done long haul 2.4ghz wireless links before with directional antennas (60+ miles).
36K feet is 6NM vertical. I have an antenna in my car, and enough power with the car running to reach a large aircraft audience. This doesn't even take into account if I have the transmitter and a lithium ion battery in my luggage (I've travelled across the world with Pelican cases loaded with AV and IT kit; no one asks, and they've only been opened by the TSA twice).
TL;DR Unauthenticated, unencrypted radio protocols are vulnerable, that's all.
I doubt ACARS requires particularly high power on the receiver end. For VHF aircraft voice communications, a simple handheld transmitter/receiver running off a boring rechargeable battery, drawing little enough power to last all day while stil fitting in your hand, will easily reach 100 miles line of sight.
Your radio horizon if you're a ground attacker will be limited by your antenna height. Attacked with powerful transmitted in Class B airspace at a busy airport? You're gonna have a bad time.
Of course that's what it's for. He's attempting to get publicity to spread the word about his possible exploit. And of course it has "in real life" caveats. He tried it in a closed simulated system.
The idea here is that it is a possible exploit. Sure the media are a bunch of morons who just bounce from one headline to another, but not to treat this as a real possibility would be foolhardy. It needs to be tried in an controlled environment and mitigated if necessary (after real life testing)and feasible.
Airline pilot here, with experience with both systems, but not technical knowledge of the inner parts or how much they are capable. I have to leave right now, I´ll be expanding this comment a bit latter.
By now just tell you that both systems are capable of creating great troubles if they can be accessed as easily as he claims (and I think they are).
A pilot probably wouldn't know how all the systems work together. (They probably know what ACARS and ADS-B -do-, but not the implementation details.) You would want an avionics engineer--so someone who works at Honeywell, Rockwell-Collins, Garmin, etc.
If you can access the wiring in the aircraft, especially with the new fly-by-wire stuff, you could cause problems. None of the communications are encrypted (as far as I know), because it's pretty much assumed you can trust what's on the a/c buses. Also, redundancy helps get rid of erroneous data when it only shows up on one bus.
I don't know much about ACARS and ADS-B. While it wouldn't surprise me if there were problems, we also tend to notice rogue transmissions in our spectrum. Much more quickly than people realize.
In the ATC system planes don't actually get routed electronically. Controllers give verbal clearances and tell pilots where traffic is.
This sounds more like spoofing an SMS from the airline's dispatch.
Sort of makes sense simulator would have ability to load scenarios without pilot acknowledgement, has no bearing on whether it would work in an Boeing or Airbus.
The ATC system is pretty vulnerable to DOS though.
But TCAS is preempted by GPWS and stall warnings, so the damage is limited to cases where you are flying at altitude directly under another airliner and you can spoof an RA for the plane above to descend into the plane below. The statistical likelihood of this configuration and a malicious attacker that can spoof TCAS is probably so low as to not cause much worry.
(Also, despite procedures, airline pilots are not automatons. They may be able to insert their brain into the loop to avoid disaster, despite the opposite happening from time to time.)
TCAS says "Traffic! Descend!" Pilot descends abruptly, calls ATC, resumes normal navigation. Happens again, same outcome, this time pilot notes TCAS inop, turns it off.
TCAS isn't "completely" automated, as it requires the pilot to actually obey. There's a squishy brain in the loop. Given that, I'm having a hard time imagining a way to do any damage (although you could easily create a huge hassle if you could spoof alerts at will). Even if you could create TCAS alerts that would steer planes into each other, the TCAS would then detect that and separate them again.
No you wouldn't have to "fake" the primary radar return.
Civilian Air Traffic Controllers in the US, Australia and numerous other countries only have Secondary Radar.
It used to be the running joke when I learnt to fly.
"How is a Cessna 150 like a Stealth Fighter?"
"With the transponder turned off.. neither will show on secondary radar"
The US Air Force, NORAD and NATO still maintain primary Air Defense radar. Especially in the US, a business jet or airliner without a functioning and active transponder is likely to get intercepted by a F-16 and escorted to land at the nearest suitable airport.
It probably fell off the list the first time around because the title seems like it "must be linkbait," so many resisted clicking on it until it's high up on the front page. Then you start reading and realize it's about as far from linkbait as you can get! Amazing work by Hugo Teso, and also going the extra mile to show the PoC on Android is exactly the right method to get this problem noticed and increase the chances it will be worked on.
I think talks like these are the absolute best way to light a fire under vendors (or an industry) to get these issues addressed. In this case we're no doubt talking about a very expensive remediation process. It also makes you wonder how bad the security will be for the next-gen GPS based systems.
I do worry the protections are not strong enough for researchers who give these talks, especially in areas like national security. It's a brave thing that Teso did going public with these vulnerabilities, and I sincerely hope we aren't reading about harassment coming his way in the future.
Not entirely on topic, but I also remember seeing something a few years ago about how you could actually telnet (sic) into some airliner flight control computers if you were able to splice into the physical cables (which run under the floors). Something about not using ssh because it messed up the prompts... Will have to find it.
I worked on the 787 and a derivative of the 747. They use protocols defined by ARINC (google it) that are only used in the airplane industry. Stuff like telnet need not apply.
How about a simple hardware device covertly attached to the plane's flaps and rudders... Then using a smart phone to control that hardware device, thus mechanically overriding the onboard aircraft control system and giving an attacker a degree of control over the plane.
How hard is it to get access to a plane to install something like this? Is it possible for a plane to pass an inspection with this device installed?
I imagine the motors that control the flaps are powerful, but even being able to lock them up would be useful. Lets say the plane rolls 10 degrees. We can then trigger the device that physically jams the motor, locking the flap in that position.
This could be like some small gel that expands and hardens.
Good luck getting onto a commercial apron and installing that with nobody - not even the pilots who perform the preflight inspection or the before takeoff checklist - noticing.
Meanwhile, millions (billions?) of dollars, hours of time, and degredations of privacy and dignity all go into trying to reduce the chance of someone being able to sneak a Toothpaste Bomb (over 3oz!) onto a plane.
Article fails to mention you would need a HUGE transmitter, not just your phone. They wouldn't let you get enough transmitter on to the plane to do it. And from the ground you would have to have a strong directional transmitter with enough siting capabilities to keep the plane in line of site for hundreds of miles.
That's not something most people have access to, and in most places someone would notice that you put up a 30 foot parabolic with auto-aligning mounts on your house.
You also don't need to be on the plane. A typical ADS-B transmitter can be picked up pretty easily from over 100 miles away--I can broadcast to every aircraft over Los Angeles from my backyard if I want.
I don't know about ACARS, but I would imagine it's similar.
This reminds me the movie "Independence Day" in which scientist uploads a "virus" to alien spacecraft and disable communications between mothership and alien spacecrafts.
"Teso has not shared too many details about the tools he used to effect the attack, as the vulnerabilities have yet to be fixed."
"has not shared" but then what is the security and methods by which he keeps the info private within his own computing environment? A motivated attacker could certainly take the initiative to get the info from him. Either by physical break in, phishing or some other devious method.
It looks like he's using my drone ground control software mavelous as a front-end to control the simulated target aircraft: https://github.com/wiseman/mavelous
Between the TSA groping you at the terminal and now the scary possibility of ne'er do wells initiating shenanigans from their smartphones in mid-air, it's enough to make me never want to fly again.
Not on the flights I've been on recently. As long as it's in airplane mode you're fine.
Also you think somebody doing something illegal like this is going to listen to any rule that involves turning your phone off? If anything they'll just be discreet about it.
I love the polite, hoity-toity tone of the euphemisms used for some of the more horrible functions: "Please go here", "Visit ground", "Kiss off", "Be punckish"
ACARS and ADS-b has nothing do to with aircraft control systems. You don't need an android app to intercept satellite communication and even if you 'root' the ACARS computer, it is not connected to the systems that could control the airplane.
Also: to pass DO-254 at level A you must have physical switches for flight/computer functionality, that said, no software can engage autopilot or change AP behavior, you need physical switches to do that. They are NOT similar to keyboard buttons, those switches actually interfere at the hardware level.