CVE-2019-5420

Uma vulnerabilidade pode permitir que um atacante adivinhe o token secreto gerado automaticamente no modo de desenvolvimento.

Ruby-on-Rails quando está sendo executado em modo de desenvolvimento. No modo de desenvolvimento, é possível para um atacante adivinhar a chave usada para proteger as sessões.

Decriptação:

Geração da chave:

O Rails utiliza 3 ambientes (desenvolvimento, teste, produção), quando uma aplicação usa o modo de desenvolvimento você consegue adivinhar o token secreto e decriptar a sessão criptografada.

A chave usada para proteger a sessão é derivada do nome da aplicação.

Exemplo:

rails new Jakom

Jakom: Nome da Aplicação.

Com isso podemos adivinhar que a chave é a saída do método de geração:

PKDF2_HMAC_SHA1[ MD5 [ APPNAME + "::Application" ] , salt: "authenticated encrypted cookie" , iterations: 1000 , key's length: 32 ]

Como podemos ver aqui:

key = pbkdf2_hmac("sha1", md5_name.encode("utf-8"), "authenticated encrypted cookie".encode("utf-8"), 1000, 32)

Decriptar a sessão com a chave:

No Rails, as sessões são criptografadas com AES-265-GCM, se você tiver a chave pode decriptar/criptografar sessões.

A última coisa que você precisará é o formato da sessão:

BASE64 [ DATA ] -- BASE64 [ IV ] -- BASE64 [ AUTH_TAG ]

Exemplo de decriptação:

Como podemos ver aqui:

data = binascii.hexlify(base64.b64decode(base64_data.split("--")[0])).decode("utf-8")
iv = binascii.hexlify(base64.b64decode(base64_data.split("--")[1])).decode("utf-8")
tag = binascii.hexlify(base64.b64decode(base64_data.split("--")[2])).decode("utf-8")

A primeira parte do cookie de sessão são os dados criptografados, a segunda parte é o IV, a terceira parte é a tag GCM (Authentication Tag). Com essas informações podemos decriptar nossas sessões diretamente:

Exemplo: