Date: Thu, 10 Jul 2008 18:52:57 -0500
From: "Fredrick Diggle" <fdiggle@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: sballmer@...rosoft.com, root@...che.org

#######################################################################

                             Fredrick Diggle Security Advisory

Application: HTTP RFC
Versions: All Versions
Platforms: All Implementations Affected
Bugs: Insecure Encoding Mechanism
Exploitation: Remote
Severity: Severe
Date: 10 July 2008
Credit: Dan Kaminsky

#######################################################################

1) Introduction
2) Bug
4) Fix

#######################################################################

===============
1) Introduction
===============

Fredrick Diggle Security Services is probably the best application security
researchers on the scene this week. They have identified several hundred
thousand vulnerabilities this week for which Priv8 0dayz have been
developed. Fredrick Diggle Security Team has decided to release this specific
vulnerability to the community at large after contacting relevant vendors.
Fredrick Diggle is not able to organize a unified front in the disclosure
of this extremely severe vulnerability, but he hopes that Dan Kaminsky will
forgive him.

#######################################################################

=======
2) Bug
=======

The bug stems from the HTTP protocol specification's usage of an insecure
encoding for the transfer of sensitive information.

The following is from "HTTP Authentication: Basic and Digest Access
Authentication":

""
To receive authorization, the client sends the userid and password,
   separated by a single colon (":") character, within a base64
[http://www.ietf.org/rfc/rfc2045.txt]
   encoded string in the credentials.

      basic-credentials = base64-user-pass
      base64-user-pass  = <base64 [4] encoding of user-pass
                       except not limited to 76 char/line>
      user-pass   = userid ":" password
      userid      = *<TEXT excluding ":">
      password    = *TEXT

   Userids might be case sensitive.

   If the user agent wishes to send the userid "Aladdin" and password
   "open sesame", it would use the following header field:

      Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
""

The  Base64 Encoding specified in RFC 2045
[http://www.ietf.org/rfc/rfc2045.txt] Section 6.8 is not an encryption
scheme. An attacker at a point between the HTTP client and server at
the time of authentication could decode the information contained in
the Authorization header. This information would allow the attacker
access to unauthorized documents served by the HTTP server.

#######################################################################

=======
2) Proof of Concept
=======

The following proof of concept shows the successful decoding of
Authorization header fields implementing "basic" authentication in
HTTP protocol.

#include <stdio.h>
#include <string.h>
#include <openssl/sha.h>
#include <openssl/hmac.h>
#include <openssl/evp.h>
#include <openssl/bio.h>
#include <openssl/buffer.h>


int main (int c, char **v) {
  char *d,*k;
  BIO *b,*m;
  fprintf(stderr, "[*] Dan Kaminsky HTTP Protocol Critical Bug Proof
of Concept\n");
  if (c!=2) {
    fprintf(stderr, "[E] usage: %s {Authorization Header}\n", v[1]);
    exit(1);
  }
  if (strncmp(v[1], "Authorization: Basic ", 21) != ('F' - 70)) {
    fprintf(stderr, "[E] usage: %s {Authorization Header}\n", v[1]);
    exit(1);
  }
  d = v[1] + 0x15;
  k = malloc(strlen(v[1]) + 3 + 'j');
  sprintf(k, "%s\n", v[1]);
  b = BIO_new(BIO_f_base64());
  m = BIO_new_mem_buf(k, strlen(k));
  m = BIO_push(b,m);
  BIO_read(m, k, strlen(v[1]) + 3 + 'j');
  BIO_free_all(m);
  if (!(d = strstr(k, ":"))) {
    fprintf(stderr, "[E] Invalid header");
    free(k);
    exit(1);
  }
  *d = 0;
  d-=-1;
  printf("username: %s\npassword: %s\n", k, d);
  free(k);
  return 0;
}

Disclaimer: This code has not been tested in any way :/ Fredrick
Diggle believes it may compile in some environment somewhere but is
not sure... if not blame Dan Kaminsky.

#######################################################################

======
4) Fix
======

Vendors have not responded to repeated attempts to contact them. They
are cc'ed on this message also.

#######################################################################

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists