One of the basic problems with code written these days is variable range checking. It takes coding time to write the code, CPU time to execute it, and engineering time to validate it. As code becomes increasingly complex, the penalties expand exponentially, so it is often skipped. This, in combination with "vestigial" code, or deliberately added "undocumented function calls" create an enormous opportunity for exploitation.
It looks to me like these systems were designed under the security through obscurity mantra (after all, who would mess with our little corner of the world?). This, of course, never works, especially today's connected world where nothing is "obscure".
I read the following list of "features" that were demonstrated to work against the simulators by Teso's Android App
- Please go here: A way of interacting with the plane where the user can dynamically tap locations on the map and change the plane’s course.
- Define area: Set detailed filters related to the airplane, for example activate something when a plane is in the area of X kilometers or when it starts flying on a predefined altitude.
- Visit ground: Crash the airplane.
- Kiss off: Remove itself from the system.
- Be punckish: A theatrical way of alerting the pilots that something is seriously wrong – lights start flashing and alarms start buzzing.
Seems like the real deal to me. The paranoid in me would speculate that the powers that be have known about this vuln for a while and this is, in part, one of the reasons for the "no electrics" ban on takeoff/landing (the most vulnerable part of any flight). I can only hope things are patched soon to make tampering more difficult. A hardened fix may require a complete change in architecture.