10 abril 2012

En la pasada Rooted CON 2012 tuve el enorme placer de compartir escenario con Raúl Siles, en una charla programada para el sábado a última hora, en la que hablamos sobre Seguridad de aplicaciones web basadas en el DNIe. En ella se darían a conocer una serie de vulnerabilidades que se encontraban en las aplicaciones web que hacen uso del DNIe, tanto para autenticación e identificación, como para firma. Además del caso de las aplicaciones, se expuso la problemática en ciertos componentes que también son utilizados para realizar operaciones con el DNIe (como si de otro certificado se tratase...), los cuales se solicita al usuario su instalación o utilización desde su navegador.

La presentación ya se encuentra alojada en la cuenta de Slideshare de RootedCON, y la incluímos a continuación. Raúl ha publicado información acerca de la primera parte de la charla en el blog de taddong.com, en la cual además de presentar los resultados de su investigación, pone a disposición de todos un módulo para que OWASP ZAProxy reconozca el certificado del DNIe y así permitir utilizar esta herramienta de interceptación de peticiones web en aplicaciones que hagan uso de él en su negociación SSL. A partir de la diapositiva 53 accederéis a la sección de la charla en la que se exponen las vulnerabilidades en los componentes cliente:


Raúl Siles y José A. Guasch - Seguridad Web de aplicaciones
basadas en DNI-e [RootedCON 2012]




En este primer post realizaremos una introducción a los tipos de componentes que existen (en general), y con qué herramientas poder analizarlos.

Tipos de componentes cliente

Realizaremos el estudio sobre dos tipos de tecnologías utilizadas para la programación de componentes cuyas operaciones deban realizarse en el lado del cliente/navegador del usuario: ActiveX de Microsoft y Java Applets.
  • ActiveX = Software en forma de componente que funciona únicamente en navegadores Internet Explorer, y sobre plataformas Microsoft Windows (el sistema operativo puede utilizar ActiveX para otras funciones, pero en este caso nos centraremos en los utilizados mediante el navegador). Su programación se realiza en la mayoría de los casos sobre Visual Basic y C++. Los ficheros suelen tener la extensión .CAB o .EXE y se instancian mediante  una etiqueta OBJECT de HTML, con los siguientes atributos necesarios:
    • CLSSID - identificador único del componente, mediante el cual se determina si el componente existe en el sistema para su reutilización, en caso negativo, se descarga del servidor.
    • ID - identificador con el que se identificará posteriormente en el código, para la llamada a sus funciones y procedimientos.
    • CODEBASE - Ruta remota dónde se encuentra alojado el componente si se requiere su descarga.

    Los siguientes diálogos identifican la existencia de ActiveX, su solicitud de instalación, aviso al usuario por requerir su carga, etc:
Aviso en el navegador sobre la instalación de un componente ActiveX por parte de una aplicación web

  • Java Applets = A diferencia de los ActiveX, los applets de Java son multiplataforma y multinavegador, requiriendo la máquina virtual de Java para su ejecución. Estos applets avisan al usuario sobre sus requisitos a nivel de permisos antes de su ejecución, depende de si se encuentran firmados, no firmados o firmados mediante una entidad propia. Para los controles firmados se delega en el desarrollador los requisitos y accesos necesarios para el correcto funcionamiento de la aplicación, para el resto, al usuario se le muestra un aviso informando sobre la necesidad del applet. Los applets tienen extensión .JAR, y se pueden instanciar tanto por la etiqueta OBJECT de HTML como por APPLET, con los siguientes atributos:
    • CODEBASE - Dirección base desde la cual descargar el applet
    • CODE - Clase concreta del applet (en .class) que se necesita cargar, y que ofrecerá una serie de procedimientos y funciones con la que realizar operaciones.
    • ARCHIVE - Dependencias previas de clases necesarias para la carga del applet
    • NAME - identificador con el cual el applet podrá posteriormente ser utilizado mediante código Javascript.
    Se puede identificar la carga de applets cuando aparezcan los siguientes diálogos en el navegador Uno de los primeros indicadores viene cuando vemos aparecer la consola de Java, siempre que ésta se encuentre activada, en el systray de nuestro sistema:
Ejemplo de Applet de Java, cuya firma ha sido verificada correctamente, y en el que se avisa de su ejecución sin restricciones
Aviso de necesidad de ejecución de un Applet de Java cuya firma no puede ser verificada
    Otra forma de desplegar applets, de una forma mucho más sencilla, es utilizando el protocolo JNLP (Java Network Launching Protocol) mediante el cual, con un simple fichero en formato XML, es posible instanciar por completo un applet, con todas sus dependencias y parámetros iniciales.
Seleccionemos por tanto un componente de cada tecnología sobre los cuales aplicar lo que vayamos mostrando: para el ActiveX utilizaremos el .cab del CAPICOM, librería utilizada para facilitar la interactuación con la CryptoAPI Windows. Para los ejemplos con el Applet Java, utilizaremos este HelloWorld que se encuentra en este enlace de la web de Oracle sobre la introducción a la programación de applets.

En primer lugar resaltar que ambos contenedores base (el .cab para ActiveX y el .jar en Applets de Java) pueden ser desempaquetados con un simple descompresor de ficheros, como si de un .zip se tratase. Para el caso de los ActiveX (.cab) veremos un conjunto de librerías DLL u OCX, así como otros recursos.

Fichero .cab correspondiente con el componente ActiveX

Descompresión del archivo mediante descompresor

Contenido del fichero .cab

Dentro de los applets Java (.jar), obtendremos todos los recursos (iconos, imágenes, propiedades...) incluyendo los ficheros .class, dónde se encuentra la lógica y programación de la aplicación.


Fichero de Applet en .jar

Descomprimir como si se tratase de cualquier fichero comprimido en ZIP

Contenido del fichero .jar

Una vez tenemos los ficheros que conforman los componentes, podremos realizar las típicas tareas de análisis de aplicaciones, como si de cualquier otra pieza de software se tratase. A continuación recopilamos herramientas que nos servirán para poder realizar un análisis más en profundidad, como son visores de funciones, debuggers/depuradores y fuzzers.

Herramientas para analizar componentes ActiveX

Visores de funciones disponibles en ActiveX

OLE/COM Object Viewer - Aplicación perteneciente al Windows Resource Kit de Microsoft tanto de Windows Server 2000 como de Windows Server 2003. Con ella podremos acceder a información acerca de los controles presentes en el sistema, información de sus interfaces, etc. Para poder ver información más detallada, como por ejemplo parámetros y tipos aceptados por las funciones disponibles, necesitaremos incluir la librería iViewers.dll para obtener toda la información del componente, y no sólo sus propiedades.


COMRaider - Si bien esta aplicación de iDefense está ideada principalmente para el fuzzing de componentes ActiveX, podemos aprovecharla también para tener una visión completa de las funciones  con sus correspondientes parámetros aceptados. Todas las herramientas muestran los entresijos de los componentes, pero personalmente es la que más me gusta, y eso que se ha quedado un poco anticuada en cuanto a interfaz...Podréis descargarla del siguiente repositorio, ya que su enlace a los labs de iDefense ya no se encuentra disponible.

Abriendo la .dll del CAPICOM con COMRaider, obteniendo funciones y parámetros permitidos por el componente

Debuggers de componentes ActiveX

En esta ocasión, como si de cualquier otra librería se tratase, las DLL principales de los ActiveX pueden ser procesadas mediante un debugger como puede ser OllyDBG, IDA de Hex-Rays o el Immunity Debugger. Estas herramientas nos permitirán realizar ingeniería inversa sobre las librerías y poder buscar vulnerabilidades asociadas a estos componentes que se incluyen en la ejecución de Internet Explorer cuando son instanciados.

Fuzzers para ActiveX

Para el que no lo sepa, diremos que los fuzzers son programas encargados de probar la integridad de aplicaciones y componentes, realizando llamadas a los procedimientos que contienen, en base a multitud de casuísticas y diferentes tipos de valores para los parámetros. Una vez se identifican las funciones disponibles (y que obviamente acepten parámetros) se obtiene el tipo asociado a dichos parámetros y se crea un banco de pruebas instanciando el componente y controlando su comportamiento durante el flujo de ejecución.

Para realizar fuzzing sobre ActiveX, tenemos varias herramientas, entre las que destacamos la anteriormente mencionada COMRaider de iDefense Labs, además de dranzer del CERT, AxMan de HDMoore, etc.

Os recomiendo este post de Alex titulado "Seguridad en ActiveX" con información detallada sobre cómo realizar pruebas sobre componentes ActiveX utilizando estas y otras herramientas. 

Herramientas para analizar componentes Applets Java

Una vez disponemos de un directorio con el contenido del fichero .jar tras ser descomprimido, veremos una jerarquia de directorios en los que se incluyen ficheros con extensión .class.

Contenido del fichero .jar, con dos ficheros .class y la carpeta de meta-información META-INF.

Decompiladores de Applets Java

A diferencia con los ActiveX, los .class de los Applets de Java pueden ser decompilados, mostrando el código fuente "casi" completo del applet, algo que nos viene genial para poder identificar más rápidamente posibles vulnerabilidades sin tener que recurrir a métodos de prueba y error como los que se utilizan realizando fuzzing a las aplicaciones. Dos de los decompiladores más famosos de ficheros .class son el JD-GUI, el JADClipse que integra el decompilador jad con Eclipse, y el DJ Java Decompiler (obsoleto, GUI para el comando jad).

A continuación vamos a decompilar el simple HelloWorld.class mediante JD-GUI:

Decompilación del código HelloWorld.class mediante JD-GUI

Importante destacar los iconos que se encuentran a la izquierda de la función init(), cuyo color (verde en este caso) indica el tipo de declaración realizada de las funciones. En caso de disponer de un ícono verde, la función es pública y puede ser instanciada de forma externa. Ya tenemos el código fuente completo, en el que si sabemos interpretar mínimamente código Java, veremos una gestión de excepciones y una función que se encarga de crear una etiqueta con el texto "Hello World" en él dentro del applet cuando éste sea cargado en la aplicación. 

Debugger para Applets Java

JavaSnoop fue presentado en la BlackHat de Las Vegas en el 2010 por Arshan Dabirsiaghi, director de investigación de la empresa Aspect Security. Esta herramienta nos permite adjuntarnos al proceso del applet en su ejecución, como ocurre con los típicos debuggers de binarios, instalando "hooks" en los métodos disponibles. Si bien los decompiladores de Applets nos dan todo el código, con esta herramienta se facilita enormemente la realización de pruebas concretas sobre los métodos soportados por el Applet.

Una vez tenemos la aplicación en nuestro sistema, lo iniciamos mediante el correspondiente fichero de inicialización (startup.bat/.sh):

Inicio de JavaSnoop 1.0
Se pueden realizar dos funciones, abrir un nuevo proceso sobre el que adjuntarse, o adjuntarse a un proceso ya existente. Para el ejemplo, nos adjuntaremos al proceso que se encuentra ejecutando el applet de HelloWorld dentro de la página de ejemplo de la propia web de Oracle mediante el botón "Attach & Snoop Process":

Seleccionando el proceso sobre el que nos adjuntaremos y realizaremos la depuración

Adjuntados al proceso correctamente
Añadiendo un hook en las funciones disponibles del applet.

La aplicación nos permite añadir "hooks" a funciones. En el ejemplo de la captura anterior se reconoce la función HelloWorld, entre otras propias de librerias cargadas por el componente (parte gráfica de la etiqueta dónde se muestra el mensaje).

Y bien, ya hemos presentado algunas herramientas que nos permitirán preparar un entorno con el cual comenzar el análisis de componentes ActiveX y applets Java. En el siguiente post comenzaremos a revisar vulnerabilidades típicas que se encuentran en este tipo de componentes.

4 comments :

Longinos Recuero dijo...

Tuve la suerte de poder disfrutar de esta charla en directo y la verdad es que fue increíble.

En cuanto al post que acabas de publicar, sencillamente estupendo. Un gran trabajo que personalmente valoro mucho.

Gracias por compartir tus inquietudes con la comunidad.

Security By Default dijo...

Muchísimas gracias por tus palabras Longinos.

Como se comentó durante la charla, se intentaría ampliar todo lo que comentado durante ella tanto en posts como directamente en la página del proyecto OWASP sobre el DNIe, y además así la comunidad podrá seguir ampliando este tipo de trabajos con otras herramientas, o incluso aportando nuevas, ya que, si bien la charla versaba sobre los componentes DNIe, todo podría trasladarse a otras aplicaciones web que utilicen además componentes para realizar operaciones determinadas.

¡De nuevo muchas gracias!

José A. Guasch

Román Ramírez dijo...

Excelente documento. La verdad es que leyendo el artículo me genera sensación de "completitud" con la charla.

Y me hace nacer la idea de si no sería interesante que se hicieran este tipo de artículos sobre todas las charlas, comentando detalles adicionales etc.

Operación: RootedDeeper :))

Una duda sin mas dijo...

Acabo de leer esta serie de articulos relacionados con el DNIe. Habitualmente uso una web app que hace uso de los applet java solicitando un pin para acceder a la tarjeta (no es un DNIe pero lleva un certificado digital con los datos a modo de DNIe) y asi validarme y darme acceso. Mi pregunta es si seria posible "capturar" esa ventana del applet para generar un script que se auntentique solo.

gracias y enhorabuena por la pagina