[HACK] Paswords en claro en MARCA DIGITAL

[Bernardo Quintero]

> > '%' (URL) Encoding is *not* unicode encoding - unicode is a multibyte
> > character set, which uses binary values outside the 32-127 range of
> > printable ASCII. When unicode characters are used in URLs, they are
> > usually/often expressed in 'utf-8' encoding, which uses a short sequence
>
> Sacado de http://www.hispasec.com/unaaldia.asp?id=726
>
> "Los caracteres UNICODE son la representación hexadecimal de su valor
ASCII
> precedido de un símbolo %."

A veces es complicao resumir en una frase :)

La idea de Unicode es tener una representación numérica de cada carácter
(de cualquier idioma, símbolos matemáticos, etc, etc) independientemente de
la plataforma, el lenguaje o el programa que se esté utilizando.  Si bien el
estándar
se basó en el archiconocido código ASCII que recoge el alfabeto latino, va
más allá
permitiendo codificar todos los caracteres para cualquier lenguaje del
mundo.
Para dar cabida a tanto carácter, Unicode utiliza un conjunto de 16bits
(65.564
caracteres) en vez de los 7 u 8 bits típicos del ASCII con el máximo en
256.

Da la casualidad que el juego Latin-1 lo incluye en sus primeros 256
caracteres,
así el código U+0041 representa el carácter "A" del alfabeto latino (se
utiliza el
prefijo "U" para indicar que es un código Unicode). El número hexadecimal
0041, en decimal sería el 65, que también da la casualidad que es el código
ASCII del carácter "A". Todo esto es porque estamos con el juego de
caracteres
latinos... así que aunque no es lo mismo ASCII que Unicode, si es cierto que
a efectos de nuestro alfabeto los códigos coinciden.... lo que puede dar
lugar
a confusiones o a simplificaciones como la que es motivo de esta discusión.

Lo que alguien comentaba del "utf-8", es una de las tres codificaciones que
se
definen en el estándar Unicode según se utilice como unidad 8,16 o 32bits:
"utf-8", "utf-16" o "utf-32". "utf-8" es normalmente utilizado en HTML y
permite utilizar bytes, y da la casualidad que esos códigos corresponden a
los mismos valores en bytes que el juego ASCII (lo hemos visto antes)....
lo que permite que los caracteres "normales" codificados en Unicode UTF-8
puedan ser utilizados en muchos paquetes software sin necesidad de tener que
modificarlos para su reconocimiento.

Cuando el carácter Unicode a representar en "utf-8" conlleva utilizar un
código de más de 7 bits ya no coincide con el ASCII, y se debe representar
como combinaciones de 2 o mas bytes donde se tienen en cuenta unos
determinados bits:

00-07 bits 0xxxxxxx
08-11 bits 110xxxxx 10xxxxxx
12-16 bits 1110xxxx 10xxxxxx 10xxxxxx
17-21 bits 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

Osea, que utilizando la codificación Unicode "utf-8" para HTTP podemos
usar "%47%45%54 %57%57%57"  en lugar de "GET WWW"... y estaremos
utilizando Unicode... y también da la casualidad de que coincide con el
código
ASCII.

Así que, si es cierto que en HTTP si cogemos un carácter de nuestro
alfabeto,
lo pasamos a hexadecimal según el código ASCII, y le anteponemos el símbolo
"%"... estaremos ante el código Unicode (que era la frase "resumen" que
había salido
en aquella noticia de Hispasec). Esto difiere según el alfabeto y carácter
que se
quiera representar, cómo he comentado anteriormente.

Volvamos a nuestra "A" y al "utf-8" (código 41 en unicode -hexadecimal- que
coincide con el 65 ASCII -decimal).

En binario la podemos representar con 7bits 1000001, por lo que en
codificación
"utf-8" utilizamos el patrón 0xxxxxxx, osea 01000001.

Si le aplicaramos incorrectamente a la "A" el patrón 08-11 bits 110xxxxx
10xxxxxx,
tendríamos 11000001 10000001, en hexadecimal C1 81. La vulnerabilidad de los
servidores webs, como la ya corregida en Internet Information Server,
consistía en
que decodificaba estos patrones erróneos... osea, que si le metíamos en la
URL
 %C1%81 lo interpretaba como "A", y además esta interpretación lo hacía a
posteriori de la rutina que comprobaba la seguridad de los paths, para no
permitir
que se apunte fuera del directorio público.

Una "A" no sirve de mucho, pero aplicando lo anterior, se obtenía  %c0% como
representación errónea de "/" y %c1%9c como "\"... caracteres muchos más
productivos para ir escalando directorios y conseguir acceder a la raiz del
sistema :)

Saludos,
Bernardo Quintero
bernardo at hispasec.com