david wong


Quick access to articles on this page:

more on the next page...

CVE TOMEK posted June 2015

My coworker Tomek found a vulnerability in Rack, a Ruby thingy that is used pretty much in every web framework (Rails, Ramaze, Sinatra...) to translate queries (POST and GET) into Ruby objects.

Tomek: David you don't understand anything, go read this: https://www.omniref.com/ruby/gems/railties/4.2.0/symbols/Rails::Application#annotation=4084035&line=161

It all started when he read about how to_sym() used to work in Ruby versions prior to MRI 2.2. This function converts strings into symbols. A symbol is this thing: :symbol, that usually is tied to a value: :symbol => 'something' and that you must have seen written in a really nice way thanks to Ruby's lovely syntax sugar: symbol: 'something'. Developers use the to_sym() method a lot to transform the strings from GET/POST to symbols. Problem: the symbols created by to_sym() were stored in the memory and never freed. No garbage collection. That is a problem if you let user input infinitely use that to_sym() method. For example if you naively transformed the GET variables of a request to symbols through that function, then a malicious user could have queried that page with many ?stuff=something so that your code would have infinitely stocked symbols in memory until no memory was left.

Tomek was looking for the fastest method to fill up a server's memory. To do this, he tested various forms of parameters to see what would be the most effective. This included many small symbol names, large symbol names, and nested parameters. The most efficient way ended up being a lot of concurrent requests with huge symbol names, the server would go down in less than 2 minutes.

And it was through the nested parameter testing that he found CVE-2015-3225



Potential Denial of Service Vulnerability in Rack

There is a potential denial of service vulnerability in Rack. This
vulnerability has been assigned the CVE identifier CVE-2015-3225.

Versions Affected:  All.
Not affected:       None.
Fixed Versions:     1.6.2, 1.5.4

Carefully crafted requests can cause a `SystemStackError` and potentially
cause a denial of service attack.

All users running an affected release should either upgrade or use one of the workarounds immediately. 

In Ruby on Rails, one of the nice things you can do is use associative arrays (called hashes in Ruby) in your forms.

For example, in your HTML

<input type="text" name="form[name]" value="david">

would translates to Ruby as


And that is thanks to Rack! But there is a small problem here, Rack parses these nested hashes by recursively calling itself:

def normalize_params(params, name, v = nil)


    if params_hash_type?(params[k].last) && !params[k].last.key?(child_key)
      normalize_params(params[k].last, child_key, v)
      params[k] << normalize_params(params.class.new, child_key, v)

Here, Ruby seems to push a bunch of info to the stack before calling the new function. A bit like an assembly prolog.

The thing is, after a while the stack gets full and Ruby throws an exception. And then? Rack catch the exception? Tries again? We don't really know, but the program hangs there.

So Tomek found out that when you would send a POST request with a deep enough hash you would cause the program to hang. This is bad because of DoS attacks.

Also, the problem cannot happen in json because json has a nest limit, and doesn't happen in GET requests either for the same reason.

What now?

CVE and Patches are talked about here: http://www.openwall.com/lists/oss-security/2015/06/16/14

Another thread there: https://hackerone.com/reports/42797

He's still trying to find out what is happening exactly, and he just opened a blog. So who knows, he might write something about it soon.

comment on this story

OWASP Chicago posted June 2015

This evening I was at Braintree's office in Chicago for the new edition of the Owasp meeting. The offices were amazing and huge!


They had beer pong tables, ping pong tables, a mini-arcade and a bar! (all that right next to the workspace)


Plenty of nice conference rooms

conf room

Some had whiteboard tables!

whiteboard table

And in the largest building of Chicago!


1 Trojaned Gems - You can’t tell you’re using one!

Brandon Myers, a security researcher at Trustwave, was the first one to talk. He found out that when you executed gem fetch or gem install, the ruby package manager, it would allow a Man In The Middle to do a DNS poisoning attack to redirect you to his servers. Even though everything happens over TLS! This is because gem doesn't check for the domain in the certificate of rubygems.org: it just checks that the server has a valid certificate and that's all. You would then download the gem on his server and... game over.

He said that the same thing was happening when developers were pushing their gems to rubygems.org ...

That's a shame, and way worse than the downgrade https attack of go.

One way of mitigating the first MITM would be to just use curl or wget directly with https://www.rubygems.org and do whatever the gem fetch does to get the gems. Because curl or wget should have a correct implementation of TLS that dodge fake DNS responses (that's why DNSSEC is useless if you query a https webpage with a correctly signed certificate).

To mitigate the second attack Brandon talked about signed gems, and that it was far from being efficient since none of the top gems are signed.

Two other problem were that if a fix comes around, gem update --system is vulnerable to the attack (since gem is itself a gem) and not using the fully secure gem signing allows some dependencies of not being signed (and thus a MITM would be able to modify those).

2 Attacking and Defending DevOps

Patrick Thomas and Alec Gleason followed by explaining how much they pwned their client with heartbleed, passwords in clear and github hooks. They then explained how you could get more information out of a pwned machine if there was git, vagrant, chef, docker and other non-crypto stuff installed on the machine.

All of this was facilitated by Devops,




They said it was still a good thing but if done correctly.

After that I went to Chisec meet some people of the security community!

comment on this story

Let's Encrypt Overview posted June 2015


What is Let's Encrypt?




How does it work?


sudo apt-get install lets-encrypt
lets-encrypt example.com

And voila.

Behing the curtains this is what happens:



  2. The CA will register your public key










But how does it really work?





ACME spec








POST /acme/new-registration HTTP/1.1
Host: example.com

 "payload":"<payload contents>",
   "signature":"<signature 1 contents>"}


Once you are registered, you can perform several actions:

  • Update your infos


Boulder's guts






New Authorization


You make a request to a certain URI.



API calls


  • SimpleHTTPS






New Certificate



a CSR example, containing the identifier and the public key


2:                       WFE ---NewCertificate--> RA
3:                                                RA ---IssueCertificate--> CA
4:                                                                          CA --> CFSSL
5:                                                                          CA <-- CFSSL




Other stuff


  • Renew a certificate
  • Read the Terms of Service



key ceremony






Links from the past weeks posted June 2015

I've been posting some more links to the links section:

Daniel J. Bernstein: "How to manipulate standards"

DJB being DJB

djbcrypto djbjesus

Downloading Software Safely Is Nearly Impossible

The funny tale of a dude who wants to safely ssh to his server on his brand new windows laptop. This follows by how to safely download, execute and use PuttY... and it's hilarious.

About Public Key Pinning

Cloudflare explains Logjam


An awesome article written by Filippo that complements mine quite well. I don't know who made this logo but it rocks!

Recent Hacks

A timeline of famous hacks, leaks, etc... If you are curious

Cooperative Strategy

A whitehouse blogpost by Ed Felten on cooperative strategy, a nice counter-intuitive puzzle that I will not forget!

Alice and Bob are playing a game. They are teammates, so they will win or lose together. Before the game starts, they can talk to each other and agree on a strategy.
When the game starts, Alice and Bob go into separate soundproof rooms – they cannot communicate with each other in any way. They each flip a coin and note whether it came up Heads or Tails. (No funny business allowed – it has to be an honest coin flip and they have to tell the truth later about how it came out.) Now Alice writes down a guess as to the result of Bob’s coin flip; and Bob likewise writes down a guess as to Alice’s flip.
If either or both of the written-down guesses turns out to be correct, then Alice and Bob both win as a team. But if both written-down guesses are wrong, then they both lose.

Cryptography in Wolfram

Okay that one seems kind of useless. But if someone wants to tell me otherwise I'm all ears! But this seems more like a stunt to introduce their new cloud service:


Adios Hola!

If you haven't heard, some people from (or not) Lulzsec have found some serious vulns on the Hola! Plugin. And also they are not happy. Personally I find this Hola! really useful as a free solution to get a netflix US account when not in the US and being able to watch youtube (because everything is "blocked in your country" when you are not in the US). And the fact that you are basically a TOR node is also nice, it increases global anonymity! But that's just my opinion.

Elliptic Curve Playground

Play with elliptic curves!


You can find more on the links section. You can also suggest me links there =)

1 comment

Hacking Week 2015 : Crypto 4 Write-Up posted June 2015

The Hacking Week ended 2 weeks ago and EISTI got the victory.

I'm the proud creator of the crypto challenge number 4, still available here, which was solved 12 times.


I also wrote a Proof of Solvableness, reading it should teach you about a simple and elegant crypto attack on RSA: the Same Modulus Attack.

(Note that I wrote that back in January)

Let's start

We are presentend with 4 files:

  • alice.pub
  • irc.log
  • mykey.pem
  • secret

the irc.log reads like this:

Session Start: Thu Feb 05 20:49:04 2015
Session Ident: #mastercsi
[20:49] * Now talking in #mastercsi
[20:49] * Topic is 'http://www.math.u-bordeaux1.fr/CSI/ |||| http://www.youtube.com/watch?v=zuDtACzKGRs   "das boot, ouh, ja" ||| http://www.koreus.com/video/chat-saut-balcon.html ||| http://blog.cryptographyengineering.com/ ||| http://www.youtube.com/watch?v=K1LZ60eMpiw ||| petit chat http://www.youtube.com/watch?v=eu2kVcWKvRo ||| sun : t'as le droit de boire quand même va'
[20:49] * Set by [email protected]:41d0:52:100::65d on Sat Nov 22 00:06:50
[20:49] <asdf> et donc j'ai chopé une vieille clé rsa qu'alice utilisait
[20:49] <qwer> alice la alice? tu te fous de moi ?
[20:49] <asdf> haha non
[20:49] <asdf> mais le truc est corrompu, ça a l'air de marcher pour chiffrer mais la moitié de la clé a disparu
[20:49] <qwer> attend j'ai sa clé publique qui traine quelque part, et même un fichier chiffré avec. me suis toujours demandé ce que c'était...
[20:50] <asdf> je t'ai envoyé le truc, mais ça m'étonnerait que ça soit la même clé non ?
[21:22] * Disconnected
Session Close: Thu Feb 05 21:22:11 2015

so alice.pub seems to be alice public rsa key. secret seems to be the file encrypted under this key and mykey.pem should be the partial key which was found.

Private-Key: (1024 bit)
publicExponent: 3 (0x3)
prime1: 245 (0xf5)
prime2: 207 (0xcf)
exponent1: 163 (0xa3)
exponent2: 138 (0x8a)
coefficient: 189 (0xbd)

It looks like prime1, prime2 and some other stuff are pretty short. I guess this is what he meant by "half the key" is messed up.

By the way this is what a RSA PrivateKey should look like:

> RSAPrivateKey ::= SEQUENCE {
    version           Version,
    modulus           INTEGER,  -- n
    publicExponent    INTEGER,  -- e
    privateExponent   INTEGER,  -- d
    prime1            INTEGER,  -- p
    prime2            INTEGER,  -- q
    exponent1         INTEGER,  -- d mod (p-1)
    exponent2         INTEGER,  -- d mod (q-1)
    coefficient       INTEGER,  -- (inverse of q) mod p
    otherPrimeInfos   OtherPrimeInfos OPTIONAL

So this is what exponent1, exponent2 and coefficient are. Just additional information so that computations are faster thanks to CRT.

Let's ignore that for the moment.

$ openssl rsa -pubin -in alice.pub -modulus -noout
$ openssl rsa -in mykey.pem -modulus -noout

the partial key and alice public key seems to share the same modulus. this is vulnerable. If our public/private exponents are not messed up, this means we can factor the modulus and thus inverse Alice's public key.

Let's retrieve all the info we have and put them in a file:

openssl rsa -pubin -in alice.pub -modulus -noout | sed 's/Modulus=//' | xclip -selection c

Here's the modulus. We know that our public key is 3, let's get the private key in the clipboard as well

openssl asn1parse -in mykey.pem | grep 129 | tail -n1 | awk '{ print $7}' | sed 's/://' | xclip -selection c

here I parse mykey.pem with openssl. I select the lines I want with grep. It returns two results, the modulus and the private key. I select only the second line with tail. I select only the 7th column with awk. I remove the : with sed. And now I have a beautiful integer in my clipboard.

Okay so let's do a bit of Sage now:

# let's write the info we have
modulus = int(0xC6C83529A2388F146365C5F5FD4B0D888961B95DE10FFA8853A3C2CBED750E9959BD0FF872C2232F6BAD32624F356A82D062755E1E4FEDAE54E8CA2471FC8D13AC700EE25720D4D9089FD6FBD42F12E6A41E1C1DE81F578C32132AD08594E851841D0239CD410DEF11D1C15EE75B92F86A04F7C6C7F36B9046B8FB2FE29565B1)

public = 3
private = int(0x848578C66C25B4B84243D94EA8DCB3B05B967B93EB5FFC5AE26D2C87F3A35F10E67E0AA5A1D6C21F9D1E2196DF78F1AC8AEC4E3EBEDFF3C98DF086C2F6A85E0BEFC0CA19C5E2495549FEE52E513E7BE9F22207D24B847FBB0CB5BAB795C690053E652D11539A2D960FEADECB9B175487000F7812CEACF5DB83301606CC357DA3)

# now let's factor the modulus
k = (private * public - 1)//2
carre = 1
g = 2
while carre == 1 or carre == modulus - 1:
    g += 1
    carre = power_mod(g, k, modulus)

p = gcd(carre - 1, modulus) 

This does not work. This should work.

Let's re-do the maths:

We know that our private and public keys cancel out. This is RSA:

private * public = 1 mod phi(N)

so we have private * public - 1 = 0 mod phi(N)

So for any g in our ring, we should have g^(private * public - 1) = 1 mod N

This is how RSA works.

Let's write it like that: private * public - 1 = k with k a multiple of phi(n). And we know that phi(n) = (p-1)(q-1) is even. So it could be written like this: k = 2^t * r with r an odd number.

Now if we take a random g mod N and we do g^(k/2) it should be the square root of a 1.

The Chinese Remainder Theorem tells us that there are 4 square roots mod N:

  • 1 mod p
  • -1 mod p
  • 1 mod q
  • -1 mod q

and two of them should be 1 mod N and -1 mod N. The 2 others should be different from 1 and -1 mod N. That's what I was trying to find in my code.

Once we have found this x mod N which is a square root of 1 mod N, we know that it is either x = 1 mod p or x = -1 mod p. If we are in the first case, we shoudl have x - 1 = 0 mod p which translates into x - 1 is a multiple of p. Doing gcd(x - 1, N) should give us p the first prime. If you don't understand it maybe check Dan Boneh's explanation (proof end of page 3) which should be clearer than mine.

With p it's easy to get q the other prime.

But it doesn't work...

Ah! I forgot that g^(k/2) could equal 1 all the time if k/2 were to be a multiple of phi(n). So let's code a loop that divides k by 2 and tries any g^k until it is giving us something else than 1. Then we know how many times we have to divide k by 2 so it's not a multiple of phi(n) anymore.

It turns out we just have to do it 3 times. And then it magically works. A bit more of Sage gives us the primes:

# p and q our primes
p = gcd(carre - 1, modulus) 
q = modulus // p

# now that we have factored N let's find alice decryption key
public = 65537
private = inverse_mod(public, phi)

Now that we have Alice's private key there are two ways to decrypt our secret:

  • recreate a valid rsa key with those values and use openssl rsautl
  • figure out how openssl rsautl works to do it ourselves

Let's do the first one. We'll modify our mykey.pem for this:

openssl rsa -in  mykey.pem -outform DER -out newkey.bin
xxd -p newkey.bin > newkey.hex

we get this:


This is a DER encoding. One particular encoding from the ASN.1 family. It is a TLV kind of encoding (Type Lenght Value).

For example in:

02 8181 00c6c83529a2388f146365c5f5fd4b0d888961b95de10ffa8853

first is coded the type 02 (integer), then the length (81 repeated twice because the value block is bigger than 127bits, so we set the first byte to 81 (10000001, the first bit means it is a long way of defining the length, the 7 following bits are the number of byte it will take to define the length, in our case only one and it will be the next one) and the second byte to the actual size), then there is our modulo in hexadecimal. Note that the most significant bit of our value has to be zero if it is a positive integer, that's why we use 41 instead of 40 and lead the payload with 00.

So let's take the time and break this apart:

3082 // some header
0122 // the length of everything that follows (in byte)
0201 // integer of size 1
028181 // integer of size 0x81 (our modulus)
0201 // integer of size 1 (our public key)
028181 // integer of size 0x81 (our private key)
0202 // integer of size 2 (prime 1)
0202 // integer of size 2 (prime 2)
0202 // integer of size 2 (exponent 1)
0202 // integer of size 2 (exponent 2)
0202 // integer of size 2 (coefficient)

Now let's remove everything which is after the modulus and let's refill the file with our own values. Let's go back in Sage to calculate them:

public = 65537
private = inverse_mod(public, phi)
exponent1 = inverse_mod(private, p - 1)
exponent2 = inverse_mod(private, q - 1)
coefficient = inverse_mod(q, p)

After filling and modifying the header's length accordingly, we obtain a nice hexadecimal file that we can transform back to binary:

xxd -r -p new_key.hex | openssl asn1parse -inform DER

It works! So now let's decrypt with is shall we?

xxd -r -p new_key.hex | openssl rsa -inform DER -outform PEM -out newkey.pem
openssl rsautl -decrypt -in secret -inkey newkey.pem

We have our secret :)!


The Logjam Attack posted May 2015


The paper containing most information is here:


Not an implementation bug, flaw lives in the TLS protocol




  • Certificate which is the server's certificate
  • ServerKeyExchange which contains the weak parameters and his public key.
  • ServerHelloDone which signals the end of his transmission.









(taken from the paper)

Not an implementation bug, but implementations do help




(taken from the paper)

Defense from the Server


Defense from the Client





1024 bits primes?



Where is TLS used?

TLS is not only used in https!



comment on this story