Have you ever read about a cyber attack strategy the night before you caught yourself writing a vulnerability for one?

Last night, I became intrigued with the timing attack. For my friends reading who aren’t as paranoid as me, it is, in a broad sense, a strategy in penetrating security in cyber systems where you analyze the amount of time it takes for a response to derive something about the system. For example, you can analyze the time it takes for a system to respond to a erroneous login attempt to derive up to which bit in your password string was correct (assuming you know your target’s username). I won’t delve too deeply into the implementations of a script to execute this attack, so like many teachers I’ve had before me I will leave it as an exercise for the reader.

Today, I almost left myself wide open for a less severe and more naive version of the attack than in the given example. Let’s say in the system I’m building I need to validate objects called “requests”. Today I tasked myself with the need to validate these “requests”, so I wrote a block of code represented by this pseudocode in my “request” controller:

if request doesn't exist {
   return request_error
}

if request is invalid {
   return request_error
}

Looks simple enough. If a “request” sent by a user doesn’t exist in our system, we return a request_error. Afterwards, we check if the request is invalid by our internal definition, and also return a request_error. By returning the same error for both cases, a clever attacker will not be able to tell which case failed!

Good shit, Ivan. You’ve built yourself a secure routine. Give yourself a pat on the back and commit your changes.

Oh but wait, what about that timing attack you read about last night?

Quite honestly I would’ve never thought twice about this block of code if not for reading about timing attacks last night. It dawned on me that someone could easily analyze the time it takes for the request_error to be returned, which they then would be able to derive whether the failed report existed or if it was invalid.

Although knowing whether a request failed because of its absence from our system or if its invalid may not seem like a severe vulnerability, a clever attacker may gain more fruitful insights and derive further vulnerabilities about the system.

Although it was frightening to know that I would’ve never noticed this vulnerability had I not read up about it the night before, I was relieved to have come up with a solution. A viable strategy to protect yourself from these kinds of attacks is to implement a constant time response system. Like so:

bool bad = false
Timer t = Timer()
int CHECK_UPPER_BOUND = 100 //assumption

t.start()

if request doesn't exist {
    bad = true
} else if request is invalid {
    bad = true
}

t.end()

//Pad the return
if t.timePassed < CHECK_UPPER_BOUND{
    wait(CHECK_UPPER_BOUND - t.timePassed)
}

if bad {
   return request_error
}

With the addition and modification of a few lines, I would be safe until a clever reader points out another vulnerability which I would be very grateful for. Using a flag, in this case bad, to check through the error conditions, then checking for whether the flag had identified an error after both conditions. I’ve also added the use of timers to make sure the checks return as if they ran in the worst case.*

I hope you enjoyed my write up of a problem I found interesting today. Please feel free to leave comments on any thoughts or complaints you have about this post, my ignorance about cyber security, my grammatical error(s), or my overall story telling abilities.

*my dear friend Colin Chartier graciously pointed out that my previous general solution would fail in the case of the checks being not constant time checks. This meant that an attacker would still receive different timings on requests that fail only either of the cases. A solution he suggested for this case was to “pad” the check to return at a certain time.