Infosec VS. Airplane Security

In a previous post, I spoke about the importance of the “context” during a pentest. In a recent project, I faced a situation similar to airplane crashes. Let me explain this… Despites the fact that the crash of an airplane results sometimes in a huge amount of deaths once, airplaines can be considered as safe. Statistically, flying is less dangerous than driving to the airport with your car! Modern airplanes are very reliable: they all have multiple engines but they are designed to be able to fly with one of them being out-of-service. The cabine crew is also trained to fly in such conditions. Airplanes are also under maintenance regularly and inspected from A to Z.

Thus, how to explain that from time to time airplanes are crashing? When such incident occurs, there are always investigations and the analyze of several incidents revealed that the main cause was a suite of small or negligible issues. Handled separately, they are completely manageable and do not impact the security of the flight… in the beginning. But, a small incident might introduce a second one, then a third one, etc. If a suite of such small incidents occur, nasty things may happen up to a complete crash! This is called the “butterfly affect” which describes how a small change in a deterministic nonlinear system can result in large differences in a later state (source: Wikipedia). The human factor remains also a cause of trouble. Even if airplanes are flying “alone” with computers, some crash are due to human errors. Yeah, we always make mistakes.

But, back to the information security, what’s the relation between an airplane crash and a pentest? Let’s put aside the human factor which is a common issue. Systems can get pwned by a suite of (smaller) issues that, taken alone, are less critical. An example to illustrate this? The company “C” is deploying corporate laptops which are allowed to connect to a Citrix farm which offers several business applications. Such laptops are used in the wild via multiple Internet connections.

Two distinct findings were:

• The Citrix ICA files can be re-used across multiple computers within a short time window. This is not a bug, it’s the way Citrix is working. When you try to launch an application, an ICA file is downloaded and opened by the browser using the local Citrix client. If you break the association with the .ica extension, the file can be saved, stolen and re-use on another computer without any further authentication.
• The corporate laptops can be pwned using classing techniques (phishing / social engineering, Meterpreter payload, Meterpreter session)

The first finding taken alone, it’s a “feature“. To access the Citrix portal, users must use strong authentication. We can consider that the .ica file is downloaded by a trusted client. The second one taken alone does not impact the security of data. Nothing is stored on the internal drive. The laptop is used only to access Citrix applications. But if we put both findings together, the cocktail might be an explosive cocktail! Step 1: pwn the laptop and control it, step 2: wait for the user to authenticate and connect to the Citrix farm, step 3: Steal the .ica file and have fun!

Keep this in mind: Your infrastructure and data can be at risk if multiple non-critical issues are exploited in the right order!