Nanosecond Scale Remote Timing Attacks On PHP Applications: Time To Take Them Seriously?
This article concerns the concept of a Timing Attack (described below) performed remotely over the internet or a local area network. Specifically, it addresses Remote Timing Attacks based on timing differences from a few microseconds to as little as 1 nanosecond (one billionth of a second), a timescale which has been assumed to be impossible to detect over the internet due to the interference of a€onetwork jittera€ť. In the article, I will be summarising some of the recent developments in the area with the goal of demonstrating that a dependence on network jitter as a defence is not sustainable and that PHP applications need to come to terms with these forms of attacks while they are still in their infancy.
I've been following the progress of Remote Timing Attacks with a lot of interest over the years, during which time there has been an obvious trend in improving the technique. The most recent reported cases of Remote Timing Attack vulnerabilities, for example, were against the OpenID and OAuth protocols when it was reported in July 2010 that numerous open source implementations of these protocols did not prevent the disclosure of timing information that could enable a Remote Timing Attack. It is important to note that, as with many potential attacks, the protocols themselves contain no vulnerability. This is strictly a potential vulnerability contingent on the method of implementation.
What is a Timing Attack?
A Timing Attack is a form of Side Channel Attack which allows an attacker to discover some secret input to an operation by measuring the operation's execution time often based on a set of attacker derived inputs. It's a side channel attack because it utilises non-invasive observations which don't involve altering the victim application. Other forms of side channel attacks can rely on phenomena such as sound, electromagnetic emissions, power consumption and even temperature. For a Remote Timing Attack, the non invasive observation often targets response time differentials.
A simple example, quite relevant to web applications, is that of someone attempting to compile a list of valid usernames recognised by a web application. This is a pointless exercise against many websites where usernames are often public by design (usually to enable social interaction) but there are web applications being designed where usernames are a form of sensitive data not intended for public disclosure. It has long been noted by programmers that, where usernames are not explicitly public by design, disclosing usernames indirectly is a problem. If nothing else it increases the risk of cross referencing username/password combinations from other more seriously compromised websites. We all use a different password for every single site, don't we?
At first look, this seems like an impossible task but in reality it doesn't take much thinking to realise how many web applications likely treat existing and non-existing usernames differently during a login attempt. Differing treatment may lead to clues about the validity of any username in a few ways:
- The website might reveal that the username does/does not exist via an error message or more subtle response elements (e.g. slight markup differences).
- The client might be redirected to different URLs depending on whether the username exists or not.
- An attacker might measure the response time difference between processing a login with an invalid username versus one with a known valid username.
Timing Attacks refer to the third option. Over time, many sites have figured out enough not to give away obvious clues about username existence but they still often neglect to hide the impact of the login checks performed by the server. If the login processing time of an existing user is measurably different than that for a non-existing user (bearing in mind the password is wrong for both), the additional delay imposed before sending a response back to a nefarious individual may be so noticeable that it can be reliably distinguished, over many attempts, from the normal background internet jitter. In this way, anyone could compile/validate a list of existing usernames for a web application using dictionaries of known usernames.
One simple step that is not uncommon is to log attempts to authenticate with a bad password. This audit log step might be skipped for non-existing usernames. Immediately we have one timing difference due to the differing treatment between usernames that do exist and those that don't. In this case, a simple optimisation introduced the flaw. This alone, or in combination with other operations, is all it might take to giveaway clues about a username's state based on the leaked execution time information.
These forms of attack are not restric
Truncated by Planet PHP, read more at the original (another 31006 bytes)