Timing Attacks and Ruby on Rails
•Download as PPTX, PDF•
1 like•2,608 views
This talk, originally given at WellRailed, dives in to what timing attacks are, some examples, and how to defend against them. A timing attack is when an attacker can figure out stuff they shouldn’t by asking questions and measuring how long it takes for you to respond. Originally presented on 26 May 2016: www.meetup.com/wellrailed/events/231113047/
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Timing Attacks and Ruby on Rails
Similar to Timing Attacks and Ruby on Rails (20)
More from Nick Malcolm
More from Nick Malcolm (7)
Recently uploaded
Recently uploaded (20)
Timing Attacks and Ruby on Rails
- 2. whoami? Nick Malcolm Co-Founder & CTO at ThisData @nickmalcolm
- 3. What are we going to talk about? What are timing attacks? Some examples Defense!
- 4. What are timing attacks? When an attacker can figure out stuff they shouldn’t by asking questions and measuring how long it takes for you to respond
- 5. Example 1: String Comparison Many string equality operators work left to right If a user controls the input, they can execute a timing attack if params[:password] == “SECRET_PASSWORD” user.do_cool_thing!
- 6. S E C R E T “A” “B” … “S” “SA” “SB” … “SE” SS EE C
- 7. Let’s see it in action!
- 8. See it in action
- 9. Let’s see it in action!
- 10. How it worked I start with an empty string I make 1000 guesses for chars ‘a’...‘z’ I measure how long each guess takes I look at how the different characters compare to one another The likely char sticks out, so I choose that
- 11. CODE
- 12. Is this practical in real life? “We present the design of filters to significantly reduce the effects of jitter, allowing an attacker to measure events with 15-100µs accuracy across the Internet, and as good as 100ns over a local network.” Opportunities and Limits of Remote Timing Attacks SCOTT A. CROSBY, DAN S. WALLACH and RUDOLF H. RIEDI. May 2007
- 13. Am I vulnerable? When checking password equality “Forgot my password” tokens “Security Questions” API key validation, or HMAC validation
- 18. Defense secure_compare for string comparison! Rate Limiting (rack_attack)
- 20. Secure Compare* - why it works It transforms both inputs into Hashes* Hashes are EQUAL LENGTH It checks EVERY character, even if you’re already wrong This makes it CONSTANT TIME *variable_length_secure_compare
- 21. Secure Compare - why it works
- 22. Secure Compare - why it works
- 23. Secure Compare - why it works > res = 0 > res |= 115 ^ 112 => 3 > res |= 101 ^ 101 => 3
- 24. Secure Compare - why it works 12
- 25. Example 2: Password Reset Page Someone submits “foo@bar.com” We know not to say “this account did / did not exist” But when account exists, we send an email. That takes time.
- 26. Example 2: Password Reset Page def forgot_password if user = User.find_by(email: params[:email) Mailer.send_forgot_pwd(user) end render html: “<h1>If you have an account, we’ve sent you an email. Chur</h1>” end
- 27. Defense Background Job for both cases Email everyone? ¯_(ツ)_/¯
- 28. Example 2: Password Reset Page def forgot_password Resque.enqueue(ForgotPasswordSender, email: params[:email]) render html: “<h1>If you have an account, we’ve sent you an email. Chur</h1>” end
- 29. Other trouble spots Facebook The browser Internet of Things Routers
- 31. Other trouble spots Facebook The browser Internet of Things Routers
- 32. What have we talked about? What timing attacks are Examples in Rails, and elsewhere Defense - but it sure is hard!
Editor's Notes
- ThisData is a startup based out of Auckland. We are a cyber security service provider, focusing on detecting when bad guys log in to your website, pretending to be your users. Like how Facebook, Google, and others email you when someone accesses your account from a weird location. I’m @nickmalcolm on twitter, and I’m also @nickmalcolm on the Ruby NZ Slack group
- First off, thanks for letting me present to you over the interwebs! I moved up here from Wellington in October, so it’s nice to be back at WellRailed. It’s my first time doing a presentation over the internet, so yell at the laptop if you can’t see something, or I go too fast, or if the quality drops out. I’ll put the slides and example code up afterwards, and there’ll hopefully be some time for questions at the end. So! We’re going to cover three main points: what are timing attacks? We’re going to look at some examples; a really close look at timing attacks with string comparison and ruby, also timing attacks in other parts of your rails apps, and then briefly if we have time at applications in other places. After each of the examples we’ll look at a couple ways to defend against that attack. So let’s get started!
- What are timing attacks? A simple way of putting it is that a Timing Attack is when an attacker can learn information that’s supposed to be a secret, and doing that by asking lots of questions over and over, and measuring how long it takes for the computer to respond. Every computation in a computer takes some amount of time to execute, and the time can differ based on the input; with precise measurements of the time for each operation, an attacker can work backwards to figure out the input. In cryptography jargon, it’s called a side channel attack. We’re learning information without smashing our way through, or by brute force, or by using a weakness in an encryption algorithm. We’re being sly - doing on the side, in a way that might not usually get thought about.
- So the most common place you’ll find timing attacks is when you’re doing String Comparison. Many string equality operators work left to right This includes Ruby’s == operator They put the two strings side by side, and check each character one at a time If the characters in both strings match, it moves to the next character, and checks that one. As soon as two characters don’t match, it returns false The more characters you have right, the more characters it has to look at, as it moves from left to right. The longer it takes to return false.
- I have mastered powerpoint to bring you a slide of wonderousness! Your app has a password called secret. And we’re going to send a bunch of guesses at your app. First we guess just the letter “a”. Nothing else. “A” is not “s”, so it returns false straight away. So we move on. We guess just the letter “b”. Nothing else. “B” is not “s” either, so it returns false straight away. Eventually we get to the letter “S”. We guess “S”, and lo and behold, “S” does equal “S”. So we need to ask “is the next character right?”. Well, there is no next character. We guessed just “S”. So since blank does not equal “E”, we return false. Let’s say that now we’re guessing a string with two characters, s and a. Does “S” == “S”? Yes. OK, next character. Does “a” == “E”? No. And again. Eventually we get to “SE”. Does “S” == “S”. Yes. OK, next character. Does “E” == “E”? Yes. OK, next character. Does blank equal “C”? No. return. For every character we get right, we need to then go and look at the next character. It takes a really really small amount of extra time to do this.
- OK so I’ve written a script which will using a timing attack to figure out a password locally. It would be very naughty to use this against someone’s website. It would also take a lot longer, which I’ll explain in a bit.
- This is what my little password guesser will output to the console. It’s a bar graph where the x axis is an a-z character it’s guessing, and the y axis is the result of analyzing the time differences between guesses. You can see in this graph that the ‘x’ bar is an outlier; it’s much higher than all the rest. So my guesser will look at that, and decide that x must have been the correct character. It’s figured out the password starts with khx. It’s partway through figuring out the next character. Switch to showing console
- The basic idea is to make enough guesses that you see a pattern emerging. Computers are predictable. There’s a really good chance if you ask it to do the same thing twice, it’ll take almost the same amount of time. And if you ask it enough times, any random noise can be smoothed out. I’ll show you the code for my timing attacker, but it’s also just a proof of concept. I’ve crafted the example code so that it will figure the password out in a shorter amount of time. A minute instead of a week. I’ve changed the equality operator to be much slower than it would be in real life This means I only have to do 1000 guesses to pretty well accurately figure out what the next character in the password is In real life, you have to do more measurements over a longer period of time, but the principle remains the same If you just look at which character took the longest, the differences are really really small. To make it easier to see, I calculate the average across all of the guessed characters. So say, on average a character takes 1 millisecond to execute a guess. Then I compare each character against that average. Most characters stay really close to the average, because they’re … well, average! But IF there is a difference in any of the characters, they’ll stick out like a sore thumb.
- So it seems like you have to make a lot of requests, and have really sensitive timing measurements, to accurately guess a password. Also, to do this against a rails app would mean doing it across the internet. This creates latency, and gremlins in the networks can speed up or slow down requests arbitrarily. This is true, but research from 2007 has shown that a difference of as little as 15 microseconds between requests can be detected over the internet. The key is that _if_ there is a difference, you only need to do lots of experiments to figure out what that difference is. http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf https://codahale.com/a-lesson-in-timing-attacks/ A worst-case scenario for guessing an SHA1 hash would require 20×256×n measurements (20 bytes long, 256 possible options), where n is the number of measurements required to pin down a single byte. So if it took 1000 requests to guess correctly, it’d be around 5,000,000 requests. You could do that in less than a week at a barely-perceptible 10 req/s. Depending on how the rate limiting works, you could add another machine in another country, and halve that.
- The short answer is: hopefully not. Rails was leaking information in their Basic HTTP Auth library until January this year! So if you haven’t updated since then, then perhaps you are. http://weblog.rubyonrails.org/2016/1/25/Rails-5-0-0-beta1-1-4-2-5-1-4-1-14-1-3-2-22-1-and-rails-html-sanitizer-1-0-3-have-been-released/ But there are some other places we’ll commonly do vulnerable string equality checks. A really common place is if you have a simple webhook controller for some third party service you use, and you have a hardcoded token, and use == to check if it’s right. Security Questions might be another spot. If you have a really poor captcha implementation, perhaps that? Forgotten password tokens when people are resetting their password. Anywhere you have some secret, and use .eql? Or ==. Going back to that webook controller example, let’s take a look at the current rails docs.
- This is a Posts controller, and the edit action is protected by a password. Can we spot the vulnerability?
- Yes! == If you copied this code, then this controller is suceptible to a timing attack, and you should go and fix it.
- I’ve had a PR accepted which updated the docs, but it doesn’t seem to have made it live yet… :(
- So! Some of you might be feeling like this right now. Hopefully not too many. But let’s learn about how to defend against this.
- As I’ve said, rate limiting works to an extent, but it’s really just slowing the attacker down. If you have good rate limiting, and a really long password, then you’re probably putting it out of feasible reach. If you don’t have rate limiting, there is a gem called rack_attack which is super easy to use. But the real solution is to not use == or .eql?. Instead use a method called secure compare!
- This is secure_compare, and it’s sister method, variable_size_secure_compare. There are similar implementations in most languages, but this is the one Rails provides in ActiveSupport. I really think the variable_size method should’ve been the “default”, because unless you read the docs you might still use secure_compare wrong. So if you have to choose one, choose variable_size_secure_compare. I’m going to spend a couple minutes talking about why this works.
- Variable_size_secure_compare will turn both your guess, and the real secret, in to hashes. This makes them of equal size. It also has another property where a change in a guess will return a completely different string for comparison.
- So here’s an example of what hashing does. The guess and the secret are equal length. A cool side effect is that If you guess the letter a, it will turn your guess in to ‘ca 978 112...’ If you guess the letter c, it will turn your guess in to ‘2e7d2…’ Even though the hash of “secret” and your guess “c” start with a 2, the character is completely wrong. It starts with an s, not an c. There’s no feasible way to detect a pattern. The reason we hash is so that strings have equal length, but I think the way that the guess changes each time is really cool too.
- Again, the real important bit is to check every character. Doing this is what makes the equality operation take a constant amount of time. No matter how early you get a mismatch, it takes the same amount of time to return false. Once you’ve generated your strings of equal length, like the hashes, it will iterate over each character’s byte (which is a number) and exclusive OR them. That value is assigned to a variable called res using OR EQUAL. As res is assigned a truthy value, like the result of a mismatching XOR, it won’t get reassigned.
- Here’s what XORing two bytes looks like. 115 XOR 112 is 3. 101 XOR 101 is zero, because they’re the same. But that value is discarded anyway, because res is already truthy. 2.2.0 :024 > secret.unpack "C#{secret.bytesize}" => [115, 101, 99, 114, 101, 116] 2.2.0 :025 > guess = "pecret" => "pecret" 2.2.0 :026 > guess.unpack "C#{guess.bytesize}" => [112, 101, 99, 114, 101, 116] 2.2.0 :027 > res = 0 => 0 2.2.0 :028 > res |= 115 ^ 112 => 3
- Importantly, each character is subject to the XOR operation. The truthiness of res is checked for each character. And the result of each XOR is only written to res once during the execution of the method. When you get to the characters which don’t match, setting res might take a teensy bit longer. But you’ll never know which character it was that caused res to become non zero, because the whole operation continues until all characters are checked. So to reiterate, whether the characters match or don’t match, the operation still takes the same amount of time. And that’s what stops it from leaking information via timing attacks! Nifty.
- CHECK THE TIME So now we’re gonna look at a different form of information leakage via a timing attack. It has nothing to do with strings or equality operators. We know it’s good practice to not say whether or not an email address has an associated account on your website. Otherwise you could find out that johnkey@parliament.govt.nz has an account on adultfuntimes.co.nz. A common place to defend against this leak is on a password reset page. After they submit the form, we don’t say whether the account existed or not. We just say if an account existed with that address, we’ll send you a password reset email You might think that’s enough to stop information leakage. Even if we don’t give away whether the account existed in the response page, it takes longer for the response to return when there is a call to a third party email service in there. This is a timing attack caused by different code executing when a condition is met, or not met.
- Here’s the problem code. We do something which takes extra time when an account exists.
- Sending an email in a background job will make both responses really fast, but unless the “account does not exist” scenario also makes a request to a background job, then there will be perceptible differences. The background job shouldn’t send the email; it should find the account and send the email. I.e. use the background job regardless of whether the account exists or not. Some companies opt to email anyone who requests a password reset. If the account exists, the email has a link. If not it has a message like “Hey, someone asked to reset a password, but we don’t think you’re actually signed up. If it was you, you probably signed up with a different email address. Have a nice day”. I imagine that would be safe against timing attacks, but you also want to avoid spamming people - so rate limit that shiz.
- Here’s an example where we use a background job regardless of whether the account exists or not. The operation is TIME CONSTANT regardless of input.
- There is a REALLY interesting talk by Mathias Bynens of Opera, where he can accurately figure out the age of visitors to his website, using Facebook. The gist of it is:
- There is a REALLY interesting talk by Mathias Bynens of Opera, where he can accurately figure out the age of visitors to his website, using Facebook. The gist of it is: Create a whole bunch of demographic-restricted Facebook pages Use Javascript, and browser preloading, to make your website visitor access those pages over and over again If the response is really fast, Facebook is showing them an “Unauthorized” response. If the response is slow, then the page is accessible and the resources are being downloaded. Well worth a watch: https://dev.opera.com/blog/timing-attacks/
- https://dev.opera.com/blog/timing-attacks/ I haven’t done any research, but my gut tells me that there are an increasing number of internet connected devices out there which probably aren’t defending against timing attacks. If you have a public webcam with simple HTTP auth, what are the chances that it’s using a non-time-constant string comparison when checking the password?
- So to reiterate, a timing attack is where you can learn things because changing the input makes it take a longer or shorter amount of time. You need to do things in a time constant manner to defend against them. Key takeaway: try and wear your security hat every day. The more you do it, the more you’ll be able to spot problem areas in your code, or the code of your colleagues.
- ruby/string.c
- ruby/string.c Also checks string length first, which I skipped in my example
- ruby/missing/memcmp.c This iterates over each character. If two characters match, they will have the same bytecode, and minusing them will equal zero. Zero is not truthy, so it keeps going. If two characters don’t match, tmp will be non-zero, and that non-zero value is returned. In the ruby code, if memcmp returns 0, it returns true (the strings are the same).