1 of 30

Practical Exploitation of Insecure Randomness

Breaking V8’s Math.random, practically

2 of 30

whoami

Currently: Security Engineer at Cruise
Previously: AppSec at Dropbox
Very nerd snipe-able

@d0nutptr

I guess introducing myself is a good a start as any to a conference talk.

Hi. I’m Nathanial Lattimer. ��I’m currently a Senior Security Engineer working at a startup called Cruise headquartered in San Francisco. That’s also where I’m giving this presentation from; the comfort of my own home.

I, previously, got my start doing security, professionally, at Dropbox where I joined the application security team. There I focused a lot of my energy in running Dropbox’s bug bounty program on hackerone.

Speaking of which, if you haven’t hacked on Dropbox before, definitely give it a go. They have a really permissive scope, pay well, and have one of the most competent appsec teams out there. It’s a rewarding experience that definitely leave you walking away having learned something.

�To continue on, as mentioned on the slide, I’m pretty nerd snipe-able. If you find *just* the right thing to get my attention, you’ll ruin any chance of me being productive for the whole day.

�Unfortunately (or, rather, fortunately) for me, a friend of mine did just that. They reached out to me asking for some help on a node application they were pentesting.

3 of 30

My friend showed me some code that looks similar to the above function (this was a grey-box test).

This function was used whenever a user wanted to recover access to their account. It would generate a random number using Math.random, multiply it by some constant (in this case, it was 10_000), and then would send this code via SMS to the user.

If the user then put this code in the next prompt, they would be able to reset the password for the account and log in. Clearly, in an application like this, there are tons of other vectors that you’d rather explore first. �

XSS on the frontend
SSRF to attack internal services
CSRF to get the user to do actions on your behalf
Perhaps there’s some sort of type juggling attack due to the loose and strict equality checking present in javascript
Tons of potential for IDORS and other business logic

But my friend saw Math.random and said “hey d0nut, you busy?” and I got to work.

4 of 30

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/random

If you’re not familiar with Math.random, just like in most languages with this construct, Math.random is a random number generator that is NOT cryptographically secure.

These functions tend to use operations with various levels of “reverse-ability” to generate the next value in the sequence. To any good AppSec engineer, they’ll correctly identify this as a vulnerability.

�However, generally we don’t put a lot of credence to exploiting insecure randomness. Yes, it’s bad. Yes, it undermines your cryptography, but in terms of practical exploitation? It’s not really there.. ��Especially when we look at the code in the previous slide. We took the raw randomness and ran a step function atop it; this is elided randomness. Surely it’s not feasible to exploit without thousands and thousands or even millions of codes.

Well, as any good bug hunter or red teamer, I decided PoC || GTFO.

5 of 30

Math.random: Under the hood

6 of 30

Math.random: Under the hood

7 of 30

Prior Work?

8 of 30

Prior Work?

9 of 30

Prior Work?

10 of 30

Z3

11 of 30

Z3 in action

12 of 30

So plug-in XS128+ and solve??

13 of 30

Challenge 1: Math.floor

14 of 30

Challenge 1: Math.floor

15 of 30

Adding Math.floor to the solver

16 of 30

Symbolically Perform XS128+

17 of 30

Calculate the u64 (converted to a double later)

18 of 30

Tell Z3 that this should equal the next known value

Expected, known value

From previous slide

19 of 30

Simulating Math.floor in Z3 - IEEE 754 😰

20 of 30

Simulating Math.floor (by cheating)

We can ignore the sign (msb)
Exponent MUST be equal to 1023 (not 100% true.. but we’ll ignore that)

21 of 30

Simulating Math.floor in Z3

22 of 30

Challenge 2: Double Trouble

23 of 30

Sept 24, 2018

24 of 30

Problem 3: Cache miss-take

25 of 30

How Math.random *REALLY* works...

26 of 30

How Math.random *REALLY* works...

27 of 30

How Math.random *REALLY* works...

28 of 30

Implications?

We need to reverse our inputs
Sometimes inputs can cross cache-fill events

29 of 30

Enough Theory, Let’s do a Demo

30 of 30

My Socials

@d0nutptr