Apache-mod_session_crypto module in the Padding Oracle vulnerability analysis-vulnerability warning-the black bar safety net

Recently, security researchers at theWeb serverApache mod_session_crypto module found a Padding Oracle vulnerability. An attacker can exploit this vulnerability to decrypt the session data, and even can be used to specify the data to be encrypted.
Vulnerability details
Product: Apache HTTP Server mod_session_crypto
Affected version: 2. 3 to 2. 5
Has been fixed version: 2.4.25
Vulnerability type: the Padding Oracle
Security risk: high
Vendor URL: https://httpd.apache.org/docs/trunk/mod/mod_session_crypto.html
Vendor status: already released fix version
Bulletin web site: https://www.redteam-pentesting.de/advisories/rt-sa-2016-001.txt
Bulletin status: published
CVE: CVE-2016-0736
CVE URL: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0736
Introduction
People can be combined using the Apache HTTP server mod_session_crypto module, the mod_session module and mod_session_cookie modules, the session data is stored to the user’s browser in encrypted Cookies. This avoids the use of server-side session state, so as to facilitate the incoming HTTP request is assigned to a plurality of not need to share the session state of the applicationthe Web serverabove.
More details
Module mod_session_crypto using symmetric encryption techniques to encrypt and decrypt session data, and use the mod_session sends the encrypted after the data is stored to the user browser’s Cookie, usually called“session”. Thereafter, the decryption of the session for the application’s environment variable, or a custom HTTP request header. The application can add custom HTTP response header is usually“X-Replace-Session”, the HTTP server uses the header value to replace the session content. Set mod_session and mod_session_crypto of specific methods please refer to the following document:
https://httpd.apache.org/docs/2.4/mod/mod_session.html#basicexamples
Module mod_session_crypto is configured to use 3DES or AES encryption algorithm, key size, as the case may be, the default is AES256。 Specific the encryption work is done by the function“encrypt_string”:
modules/session/mod_session_crypto. c
/**

• Encrypt the string given as per the current config.
• Returns APR_SUCCESS if successful.
  */
  static apr_status_t encrypt_string(request_rec * r, const apr_crypto_t *f,
  session_crypto_dir_conf *dconf, const char *in, char **out)
  {
  […]
  apr_crypto_key_t *key = NULL;
  […]
  const unsigned char iv = NULL;
  […]
  / use a uuid as a salt value, and prepend it to our result */
  apr_uuid_get(&salt);
  […]
  res = apr_crypto_passphrase(&key, &ivSize, passphrase,
  strlen(passphrase),
  (unsigned char *) (&salt), sizeof(apr_uuid_t),
  *cipher, APR_MODE_CBC, 1, 4096, f, r->pool);
  […]
  res = apr_crypto_block_encrypt_init(&block, &iv, key, &blockSize, r->pool);
  […]
  res = apr_crypto_block_encrypt(&encrypt, &encryptlen, (unsigned char )in,
  strlen(in), block);
  […]
  res = apr_crypto_block_encrypt_finish(encrypt + encryptlen, &tlen, block);
  […]
  / prepend the salt and the iv to the result /
  combined = apr_palloc(r->pool, ivSize + encryptlen + sizeof(apr_uuid_t));
  memcpy(combined, &salt, sizeof(apr_uuid_t));
  memcpy(combined + sizeof(apr_uuid_t), iv, ivSize);
  memcpy(combined + sizeof(apr_uuid_t) + ivSize, encrypt, encryptlen);
  / base64 encode the result */
  base64 = apr_palloc(r->pool, apr_base64_encode_len(ivSize + encryptlen +
  sizeof(apr_uuid_t) + 1)
• sizeof(char));
  […]
  return res;
  }
  The source code shows the encryption key is based on the configuration of the password and a randomly selected salt by calling the function“apr_crypto_passphrase”generated. This function is used internally by PBKDF2 to generate the key. Then, the data is encrypted, and the salt and the IV into the encryption after the data front. Before returning, the function of the encrypted data is base64 encoding process.
  Since this process can not guarantee that the ciphertext’s integrity, so the Apache module can’t detect the session back to the server before whether it has been tampered with. This often means that the attacker can use the Padding Oracle attack, i.e., the session is decrypted and the encrypted specifying any data.
  Proof-of-concept code（POC）
  Below we reproduce the security vulnerability. First, enable the module mod_session, the mod_session_crypto and mod_session_cookie, and as shown in the configuration:
  Session On
  SessionEnv On
  SessionCookieName session path=/
  SessionHeader X-Replace-Session
  SessionCryptoPassphrase RedTeam
  In addition, for the folder to write one of the following shown in the CGI script, then the CGI script is saved as“status. rb”, for the client to use:
  #!/ usr/bin/env ruby
  require ‘cgi’

[1] [2] [3] next