“The light is on in their window. They must be home.” This is a classic example of a side information channel. They didn’t TELL you they were home. But the side effect of them being home in the evening is the light in the window — which is how you’re pretty sure they are home even though this information wasn’t communicated to you.
Another example that is a bit closer to cryptography concerns why cyphers with one-to-one correspondence between the letters of the original text and the letters of the encoded text do not work. In this case, the side channel is the information about the grammar of the English language. It is sufficient to calculate frequencies of letter appearances and likely combinations that would represent simple words like “the” and “is” to quickly understand which encoded sequence corresponds to which letter.
Both of these examples are _passive _side channels. Another option for side channel attacks is an _active _side channel exploit. An example from crypto history would be to try to get the enemy to encrypt a known message with their system. Generally, passive attacks are attacks that only observe the side-channel output. Common examples of side channel outputs in classic cryptography and computing are timing, power consumption, electromagnetic (EM) emissions, light, and sound — think of the sound of a 300-baud modem that the olden-day hackers could decode by ear!
Side-channel attacks have always been high on the list of security threats for both practitioners and academics. If you are interested in looking at the subject closer, there is a very interesting academic article by R. Spreitzer et al. that came out in December of 2017 proposing a new classification of side channel attacks:
The rekindled interest in side channel attacks is partially due to the broad use of mobile applications with always-on connectivity. Multiple radio devices on the motherboard, such as WiFi and Bluetooth, have created additional risks for side-channel attacks.
Two other recent scary examples are the infamous Specter and Meltdown exploits. Through no fault of the application logic, apps are being compromised because of the way speculative execution works in the processor! Basically, the CPU does it first and checks if it was the right thing to do later. While these issues are not classically side channel, they are artifacts of a shared environment and are not that different from exploits associated with multiple processes sharing the same L2 cache on the processor motherboard.
One can argue that all those issues are low level and should be taken care of by the system designers. Not true!
Let’s take a look at server level side-channel attacks.
Even though a browser is aware that different sides are independent and that the information should not be shared across different tabs — it can’t always help it.
Some information has to be shared by all the apps in the browser — for example, the change in memory consumption. One interesting aspect is timing. If you know the application structure (and its interface was designed as responsive), you can figure out what frame the user has requested simply by monitoring the timing and the duration of redraw requests.
Check out some excellent examples in this whitepaper:
Another way to access information that doesn’t belong to you is to look at the corner cases and case frequencies. Remember the “the” and “is” frequencies we talked about earlier? Now imagine the user is trying to select their doctor’s last name from a drop-down list in a hospital app. If the user types “Jo,” a long possible list will be returned; if he types “Zy,” the list will be much shorter. Good encryption or not, after not very long, the malicious monitor will be able to derive information about the doctor’s name.
In another example, the same researchers looked at an actual tax application and found a set of questions that were only asked if your income was between $110K and $150K, just from following the application logic. Better read this fascinating article for yourself:
Side-Channel Leaks in Web Applications: A Reality Today, a Challenge Tomorrow by Shuo Chen et al.: <https://www.informatics.indiana.edu/xw7/papers/chen2010side.pdf>
Yet another class of widespread exploits are based on on timing techniques. Time-based techniques such as sleep/delay/gp_sleep calls or heavy queries are frequently the basis of ISQL injections that are designated as an A1 risk according to OWASP Top-10 2017.
Injection is a good example of a side channel attack when an attacker receives information from the database by guessing it byte by byte and proving the guesses by matching them to the time of the query evaluation. This pretty old and powerful technique allows them to steal data even if no other methods are available. Chema Alonso et al. presented this approach at DefCon 2016:
“The effective solutions to the side-channel problem have to be application-specific, relying on an in-depth understanding of the application being protected.”
Hope is never lost! There are three strategies you can employ. Some common side channel issues on popular platforms and applications are known, and patches are offered for system libraries. For example, the SSH input timing attack is mitigated with the introduction of random noise packets, the Intel Specter bug is mitigated with patches to Windows and Linux OS, and so on. Secondly, design-time application-specific mitigation is a good SDL practice. For instance, the issue with returned lists of different sizes can be mitigated with a reasonable padding policy. Last but not least, especially for web applications, operationally monitoring an application for suspicious client behavior should prevent both information leakage and possible exploits based on it. Timing-dependent attacks would not pass through a behavioral-aware WAF, so that is another good mitigation strategy.
What You Should Know About Side-Channel Attacks, Like Meltdown was originally published in Wallarm on Medium, where people are continuing the conversation by highlighting and responding to this story.