Analytics

jueves, 31 de octubre de 2013

Participamos en la mesa redonda de la NcN

En el marco de la No cON Name 2013, la organización ha querido invitar a un miembro del equipo, en este caso a Daniel Fernández, para participar en la mesa redonda que tendrá lugar el viernes a las 16:00.

La temática principal de la mesa redonda versará acerca de las noticias que se han difundido estas últimas semanas en relación a las filtraciones de Snowden sobre las capturas masivas de información de ciudadanos relevantes (y no tan relevantes), de cómo los Estados utilizan las herramientas a su alcance para controlar la actividad de los usuarios de las tecnologías y servicios de la comunicación e Internet, en algunos casos, como parece, superando las fronteras de la legalidad y las respectivas Constituciones.

Para favorecer el debate se enfrontarán ambos lados, con un enfoque de defensores y detractores de la vigilancia y control de la información y del uso del Big Data, de forma profesional pero desenfadada y en la que se contará con la moderación de Ruth Sala (Legalconsultors) y la participación Luis Ángel Fernández Hernana (lab_RSI),  Eduardo López-Román (ICAB) y Daniel Fernández Bleda (Internet Security Auditors).

Novedades PCI DSS v3.0 (Parte II): Mejores Prácticas hasta Julio de 2015

Siguiendo con la serie de artículos que analizan la nueva versión de PCI DSS, en esta segunda entrada del blog, se analizarán los nuevos requisitos añadidos que serán buenas prácticas hasta julio de 2015. Debido a las implicaciones que tiene la implantación de estos nuevos requisitos, el PCI SSC deja un año y medio a las empresas para implantarlos.

Estos nuevos requisitos los podemos agrupar en los siguientes apartados:
1. Nuevas vulnerabilidades a verificar en el desarrollo seguro de aplicaciones
Respecto al desarrollo seguro de aplicaciones, esta nueva versión añade dos vulnerabilidades nuevas a verificar antes de que el código pase a producción. La primera vulnerabilidad a verificar es el “manejo inseguro de datos sensibles en memoria”. Lo que se pretende es evitar que se produzcan robos de información por una mala gestión de los datos en memoria, pudiendo ser estos datos robados por diferentes canales, como, por ejemplo, si se accede a los datos en memoria debido a que éstos no se eliminan una vez ya no se utilizan (se libera el espacio en memoria pero el dato sigue estando en memoria), o se fuerza el error en memoria, recogiendo los datos volcados a fichero en disco.

Para proteger las aplicaciones de esta vulnerabilidad se recomienda no almacenar el dato en memoria si no es necesario (si no tenemos el dato, no nos lo pueden robar), borrar los datos una vez que no sean necesarios, o asociar el atributo “private” a estos datos en caso de utilizar programación orientada a objetos.

La segunda vulnerabilidad añadida es “pérdida de autenticación y gestión de sesiones”. Se debe verificar que las funciones relacionadas con la autenticación y gestión de sesiones se implantan correctamente para evitar que terceros puedan apropiarse de identificadores de sesión, contraseñas en claro, etc. con el objetivo de robar cuentas de usuarios.

Para evitar esta vulnerabilidad, algunas de las medidas que se recomiendan son almacenar las credenciales utilizando hash o cifrado, no mostrar los identificadores de sesión en la URL, forzar la caducidad de las sesiones, marcar los tokens de sesión (por ejemplo, cookies) como “seguro”, o enviar credenciales a través de conexiones TLS. En resumen, evitar la manipulación de los parámetros de sesión establecida.

2. Terminales punto de venta (TPV)
Posiblemente, los requisitos referentes a la seguridad física en TPVs atendidos o desatendidos serán de los que más impacto tengan en las organizaciones, y de los más costosos de implementar, en tiempo y recursos. Debido al creciente aumento de fraudes en dichos terminales, las organizaciones deben poner controles adicionales a los TPVs que permitan gestionarlos de forma segura. Se deberán inventariar todos los TPVs, incluyendo al menos la marca y modelo, la ubicación y el número de serie. Si no se sabe qué es lo que uno tiene, es complicado protegerlo.

Se deben establecer procedimientos para realizar revisiones periódicas de los TPVs, verificando que éstos no han sido manipulados, y no se han colocado skimmers u otro tipo de dispositivos que permitan capturar los datos de tarjeta.

Por último, se deberán desarrollar procedimientos para gestionar el mantenimiento de los TPVs. Es decir, se debe identificar a los proveedores que realizan el mantenimiento, evitando posibles ataques de ingeniería social, alertar a quien corresponda en caso de detectar comportamientos extraños de individuos alrededor del TPV o verificar que el reemplazo del TPV en su totalidad o alguna pieza ha sido autorizado previamente.

Además de establecer estos procedimientos, se deberán impartir formaciones a los empleados para que conozcan estos procedimientos, conozcan los posibles ataques que pueden sufrir los TPVs, y las situaciones en las que deben alertar a sus responsables.

3. Test de intrusión
Se debe desarrollar una metodología para la ejecución de tests de intrusión. Esta metodología, debe basarse en las buenas prácticas de la industria como por ejemplo, NIST SP800-115, Open Source Security Testing Methodology Manual (OSSTMM), OWASP (para aplicaciones web), etc., tener en cuenta todo el entorno de datos de tarjeta, validar la segmentación, revisar las vulnerabilidades que hayan aparecido en los últimos 12 meses, especificar el periodo de retención de los resultados de los tests de intrusión y las actividades derivadas del plan de remediación, y al menos verificar que los sistemas no son vulnerables a las vulnerabilidades que aparecen en apartado 6.5.x (inyecciones SQL, buffer overflow, etc.).

Aunque se mantiene que se debe hacer al menos una vez al año, o tras un cambio significativo, un test de intrusión interno y otro externo a nivel de aplicación y a nivel de red, sí se especifica que para este último se deben evaluar todos los componentes que soportan la red así como sus sistemas operativos.

4. Gestión de proveedores externos
Se exige más compromiso a los proveedores de servicio en el cumplimiento del estándar. Como vimos en el artículo anterior, las organizaciones deben identificar los requisitos cuyo cumplimiento depende de los proveedores, depende de la organización o depende de ambos. Los proveedores que procesen, transmitan o almacenen datos de tarjeta en nombre de la organización deben comprometerse con las organizaciones a cumplir con todos los requisitos PCI DSS que les afecten. Además de incluirse en el clausulado del contrato, la organización deberá auditar a sus proveedores para asegurar que el compromiso es efectivo.

En caso de que el proveedor haya certificado su servicio, éste deberá proporcionar evidencia de que eso es así, bien saliendo publicado en las listas de VISA y MasterCard en caso de pasar la auditoría, o bien entregando el SAQ relleno y firmado por el banco.

Y por último, se pretende aplicar la misma política de control de acceso de los usuarios internos a los proveedores  otorgando cuentas individuales a cualquier proveedor que acceda al entorno PCI DSS. El proveedor debe ser consciente de que está prohibido el uso de cuentas genéricas y compartidas, independientemente de que el acceso sea puntual o habitual. De esta manera se pretende “atar en corto” a los proveedores, y garantizar la imputabilidad a un individuo de todas las acciones que se ejecuten en el sistema.

Con estos requisitos el PCI SSC da una vuelta de tuerca (algunos dirán que dos o tres) al estándar, aumentando la seguridad del entorno no tanto en la parte técnica, sino en la parte administrativa y documental. Lo que se busca es aumentar la seguridad en la gestión de los controles, cerrando agujeros que, en función de la interpretación de las organizaciones y QSAs, podrían causar serios problemas de seguridad.


Autor: Carmen de Alba - CISA, CISM, PCI QSA, PA QSA
Departamento de Consultoría

martes, 29 de octubre de 2013

Volvemos a patrocinar la No cON Name 2013 (#ncn2k13)

La No cON Name ( NcN ) es el congreso de seguridad informática y hacking más antiguo en España. Con una periodicidad anual reúne tanto a nuevas promesas del sector, expertos, así como a profesionales en el campo de la informática en general, redes telemáticas, programación o ingeniería de protección de software.

Un año más, volvemos a colaborar como sponsor en la No cON Name 2013 que se celebrará en Barcelona los días 1 y 2 de noviembre.

Recordad que los días 30 y 31 de octubre podéis disfrutar de talleres y formaciones.
A continuación os dejamos el programa:
1 de noviembre de 2013
  • 08:00 – Apertura
  • 09:30 - Inauguración X Edición
  • 10:00 -  Cloud Computing, Big Data, Smart Cities... ¿y las personas? Ruth Sala Ordoñez
  • 11:05 – Coffee Break
  • 11:35 - One FlAw Over the Cuckoo’s. Iñaki Rodríguez / Ricardo J. Rodríguez
  • 12:20 – La defensa de Chewbacca. Vicente Aceituno
  • 13:15 – Comida
  • 15:00 – Pinout & flashing a Nokia pone. Carlos Fouz
  • 16:00 - Mesa Redonda
  • 17:00 – Descanso
  • 17:15 – Securización de servicios con OAuth. Jordi Giménez
  • 18:15 - A journey into userland rootkits for Android. Sebastián Guerrero
2 de noviembre de 2013
  • 8:30 - Apertura
  • 9:00 – Tu PO**A through the NFC. Ricardo J. Rodríguez
  • 10:00 – Ofuscación y estenografía de binarios. David Guillén
  • 10:55 – Coffee Break
  • 11:35 - Mesa Redonda
  • 12:30 – Client-Side password encryption the 8oolb Gorilla is your sysadmin. Pedro Fortuny / Carlos Amieva
  • 13:15 - Comida
  • 15:00 - /*!Bypass Web Application Firewall*/. Omar Palomino
  • 16:05 -  Keep your sandbox for malware analysis unnoticed. Alberto Ortega
  • 17:00 – Descanso
  • 17:25 -  Defeating WhatsApp's Lack of Privacy. Jaime Sánchez / Pablo San Emeterio
  • 18:30 -  All your content providers are belong to me. Sebastián Guerrero
  • 19:00 - Ganadores CTF / CLAUSURA

viernes, 25 de octubre de 2013

Novedades PCI DSS v3.0 (Parte I)

El 7 de noviembre sale la versión 3.0 de PCI DSS. El PCI SSC ha empezado a distribuir los borradores de la norma entre los QSAs (Qualified Security Assessors) y he aquí las primeras conclusiones sobre el borrador. Esta nueva versión viene con una profunda revisión de todos los requisitos, derivada de la necesidad de ir evolucionando y perfeccionando la filosofía del estándar con el paso del tiempo, pero, en ningún caso, desdice o invalida requisitos de la versión anterior y la estructura de los 12 requerimientos sigue siendo la misma.

Aunque se han incluido varios requisitos (alrededor de 30 nuevos), se puede decir que la nueva versión requiere un esfuerzo extra por parte de las organizaciones en la parte documental. El PCI SSC da por hecho que la red se segmenta, que se recogen logs de todos los componentes, que los sistemas son bastionados, etc., pero la parte documental y procedimental no está correctamente desarrollado o implantado, y en este aspecto se centran la mayoría de los cambios y aclaraciones introducidos.

Analizando el borrador se puede decir que, en primer lugar, se han modificado un gran número de requisitos para eliminar ambigüedades en aquellos que permitían interpretaciones diferentes, tanto en QSAs como en el personal de las organizaciones. Y en segundo lugar, se han desarrollado nuevos requisitos que pretenden cubrir ciertas carencias que tiene la versión 2.0. De entre estos nuevos requisitos añadidos cabe destacar aquellos que, por el impacto que tiene su aplicación en el entorno PCI DSS, hasta junio de 2015 serán considerados como buenas prácticas y a partir de esta fecha serán requisitos de obligado cumplimiento.

En este primer artículo se analizan por requerimientos los nuevos requisitos más significativos, dejando para posteriores artículos los requisitos que son buenas prácticas hasta junio de 2015 y los requisitos modificados.

Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Respecto a los mapas de red detallados, se exige que en éstos aparezcan los flujos de datos de tarjeta a través de las redes y sistemas.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Para mantener un control estricto de todos los componentes del entorno, se requiere mantener actualizado un inventario de activos al nivel de hardware y de software. Este requisito está relacionado con el mapa de red. Con un inventario completo de los componentes y tecnologías del entorno PCI DSS, es más sencillo verificar que en el mapa de red se han tenido en cuenta todos los componentes del entorno sin inconsistencias.

Requirement 3: Protect stored cardholder data
En relación a la visualización de los datos de tarjeta en claro, se incluye un nuevo requisito que exige que todos los roles de las personas que accedan a los datos de tarjeta en claro deben estar identificados. Este nuevo requisito enlaza con los requisitos de control de acceso del requerimiento 7, obligando a las organizaciones a tener una relación entre aplicaciones, ficheros, logs, etc. que contienen datos de tarjeta, y los roles autorizados para cada uno de ellos.

Por lo tanto, deberá existir una “Matriz de Acceso al PAN Completo”, donde se justifique, para cada uno de los roles autorizados, la necesidad de acceder al dato en claro, y cualquier otro rol que no aparezca en esta matriz deberá ver los datos de tarjeta enmascarados.

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs.
Para aquellos equipos que no sean susceptibles de ser afectados por malware (mainframe, sistemas UNIX, etc.), se deberá realizar un análisis periódico, en el que se analicen si los riesgos actuales podrían afectar de algún modo  a dichos equipos. Esto implica que se deben revisar las publicaciones de los fabricantes de dichos equipos, las publicaciones de los fabricantes de antivirus, las publicaciones de seguridad de distintas organizaciones expertas en temas de seguridad, que permitan identificar si estos componentes corren el riesgo de verse afectados por cualquier tipo de malware.
Además, las organizaciones deberán tener en su repositorio documental las características de los antivirus activos en el entorno PCI DSS, en el que se pueda verificar que dichos antivirus protegen los componentes del entorno y detectan y eliminan todo tipo de software malicioso conocido.

Requirement 7: Restrict access to cardholder data by business need to know
Para cada uno de los componentes del entorno, se deben identificar los roles que necesitan acceso, así como los privilegios que tienen. Lo más recomendable es establecer una matriz de control de acceso. Este requisito viene a completar la gestión de accesos de los usuarios del entorno PCI DSS.

A pesar del trabajo adicional que implica documentar para cada componente del entorno, los roles y permisos asociados, este control permite tener una gestión eficaz y ordenada de los roles y usuarios.

Requirement 8: Identify and authenticate access to system components.
En esta nueva revisión se ha incluido la gestión de credenciales para el control de acceso físico. Por lo tanto, se deberá establecer un procedimiento de altas y bajas de los usuarios, en los que se tenga en cuenta que si a un empleado se le entrega una tarjeta inteligente, un token u otro dispositivo de autenticación, éste deberá ser devuelto en el momento en que el usuario cause baja en la empresa o cambie el puesto de trabajo.

También se especifica que, cualquier dispositivo físico de autenticación entregado a cualquier empleado, es de uso personal e intransferible, y que deberá verificarse que dichos dispositivos no son compartidos entre varios usuarios.

Requirement 9: Restrict physical access to cardholder data.
En la versión 2.0 se obligaba a controlar y gestionar los accesos físicos a CPDs de las visitas. A partir de ahora, también deberá gestionarse y controlarse los accesos físicos del personal interno y externo de la organización. Como todo lo relativo al control de acceso, los permisos de acceso deben basarse en función de su trabajo, y éstos deben ser revocados de manera inmediata cuando un empleado cause baja en la empresa o cambie de puesto de trabajo (y ya no sea necesario tener acceso a zonas específicas).

Respecto a la gestión de destrucción de soportes, la nueva versión puntualiza que, aquellos contenedores que almacenen información con datos sensibles, deberán securizarse asegurando que no podrán ser accesibles por personal no autorizado.

Requirement 10: Track and monitor all access to network resources and cardholder data.
Tanto para las alertas generadas por la plataforma de centralización y correlación de logs como para las alertas generadas por la aplicación de monitorización de archivos críticos, se debe establecer un proceso de revisión y gestión de alertas. Es decir, debe haber unos procedimientos documentados que permitan gestionar el ciclo de vida de las alertas, desde el momento en que un operador las detecta hasta que éstas se cierran.

Requirement 11: Regularly test security systems and processes.
A los tests de intrusión se le añade una nueva funcionalidad: verificar de forma global, que la segmentación es efectiva y los controles implantados están operativos y funcionan de acuerdo a lo establecido, aislando los componentes dentro del entorno de otras redes y componentes no confiables.

Requirement 12: Maintain a policy that addresses information security for all personnel.
Respecto a la gestión de proveedores, para cada servicio prestado por los proveedores, se deberán mapear los requisitos que son responsabilidad del proveedor de servicios, los requisitos que son responsabilidad de la organización, y los requisitos cuya responsabilidad sea compartida por el proveedor de servicios y la organización.

Por último, cabe destacar que el requisito 12.2 (“Develop daily operational security procedures that are consistent with requirements in this specification (for example, user account maintenance procedures, and log review procedures)”) de la norma ha sido eliminado, y en su lugar, al final de cada requerimiento, se ha incluido un requisito que exige documentar y distribuir a todos los empleados internos y externos las políticas, los procedimientos, las instrucciones de trabajo, etc. para que puedan operar de acuerdo a éstos.


Autor: Carmen de Alba - CISA, CISM, PCI QSA, PA QSA
Departamento de Consultoría

jueves, 24 de octubre de 2013

BYOD: Bring your Own Device (parte I)

BYOD (Bring Your Own Device)

¿Qué es el BYOD?

“El BYOD (Bring Your Own Device) es una política empresarial en donde los empleados llevan sus propios dispositivos a su lugar de trabajo para tener acceso a recursos de la empresa tales como correos electrónicos, bases de datos y archivos en servidores así como datos y aplicaciones personales.”

En entornos corporativos esta política se conoce desde hace ya tiempo.  Se calcula que en Estados Unidos más del 70% de las compañías dan soporte a programas de BYOD de algún tipo.
Actualmente, con la evolución que está sufriendo la tecnología, este fenómeno ha aumentado y cada vez es más difícil pedir a los trabajadores que se hagan un downgrade  tecnológico cuando llegan a su puesto de trabajo.

Problemática

El BYOD está produciendo grandes cambios en las organizaciones y los negocios, creando dos tipos de tendencias: una entre los que creen que ayuda a los empleados a ser más productivos, y otra en la que piensan que eleva la moral de los empleados ya que permite más flexibilidad dentro de la empresa. Pero esta forma de funcionar genera un problema asociado que es el de rastrear y controlar el acceso a las redes privadas y corporativas. Para poder llevar a cabo esta política empresarial, los dispositivos deberían tener configurados unos protocolos de seguridad para evitar accesos no deseados, ya que de lo contrario el resultado podría ser perjudicial para la empresa debido a las fisuras que podrían aparecer, como filtraciones de información o introducir aplicaciones perniciosas a la red corporativa que pueden infectar al resto de equipos de la empresa. Por ejemplo, si un empleado utiliza su smartphone para acceder a la red de la compañía y luego lo pierde, la información confidencial guardada en el teléfono podría llegar a manos no confiables y esta situación podría derivar en multitud de problemas incluyendo pérdidas económicas además de una pérdida de imagen corporativa.

Ventajas e Inconvenientes

Como con cualquier otra política corporativa el BOYD tiene sus pros y sus contras.
Ventajas:
  • Mayor productividad
  • Flexibilidad
  • Uso del dispositivo en cualquier momento y lugar
  • Mejor atención al cliente

Por lo tanto, con BYOD se tiene más flexibilidad para poder conectarse a los recursos de la organización desde el propio dispositivo del empleado y, sobre todo, se podrá hacer uso de la velocidad de conexión al emplear las comunicaciones de la empresa en lugar de la conectividad del propio dispositivo.
Inconvenientes:
  • Riesgo en la seguridad y la privacidad de la información
  • Requiere nuevas políticas de control de accesos
  • Precisa recursos de red suficientes para soportar la llegada de los dispositivos
  • Necesidad de soporte TI para multitud de dispositivos, aplicaciones y software

Si se analiza desde el punto de vista de la seguridad corporativa, el llegar al puesto de trabajo y conectar el dispositivo (ya sea smartphone, tableta o portátil) a la red de la organización ya supone un riesgo. Hay que tener en cuenta que el mismo dispositivo que se utiliza para uso personal, se está conectando directamente a la red de la empresa. Por otro lado, si se permite a los empleados conectarse con su dispositivo se puede perder el control sobre la información corporativa e incluso una fuga de la misma. En este sentido, se pueden implementar medidas como, por ejemplo, una solución DLP que inspeccione este tipo de acciones.

Como conclusión se puede decir que son varias las ventajas que proporciona BYOD, siempre y cuando se apliquen las mismas medidas de seguridad a los dispositivos personales que al resto de equipos de la organización.

REFERENCIAS

El blog de Enrique Dans - BYOD e informática corporativa
Hacking-ético -  BYOD: Ventajas e inconvenientes – Problemas de seguridad
Computing.es - BYOD, historia de dos posturas TIC enfrentadas

lunes, 14 de octubre de 2013

La Protección de Infraestructuras Críticas y la Ciberseguridad Industrial

El Centro de Ciberseguridad Industrial ha publicado el documento en el que se ha estado trabajando los últimos meses "La protección de Infraestructuras Críticas y la Ciberseguridad Industrial". El documento analiza las similitudes y divergencias entre la "Protección de Infraestructuras Críticas" y la "Ciberseguridad Industrial", tratando de aclarar el alcance de cada una de estas expresiones o ámbitos, los puntos en común, objetivos, principales responsables en cada ámbito con su correspondiente descripción, principales problemas en ámbitos como por ejemplo algo tan básico como la formación y especialización de los profesionales en ciberseguridad, algo que es escaso actualmente.

Particularmente destacable es la sección de estado del arte de este documento, digna de mención por el trabajo de investigación y recopilación de información, ya que se detallan las iniciativas existentes en Estados Unidos, Europa, Latinoamérica, así como iniciativas más concretas como las de España, Holanda y Reino Unido.

El documento se ha dividido en dos versiones, una versión pública y una versión completa de pago. Ambas versiones pueden obtenerse a través del siguiente enlace:
http://www.cci-es.org/web/cci/detalle-evento/-/journal_content/56/10694/43073#.

Del mismo modo que con el "Mapa de Ruta de la Ciberseguridad Industrial En España" publicado en Junio 2013, Internet Security Auditors también ha colaborado activamente en el desarrollo de este nuevo documento y que ha sido publicado en Octubre 2013.


Autor: Marc Segarra - CISM, CISA, CISSP, PCI QSA, PCI PA QSA, ISO27001 Lead Auditor
Departamento de Consultoría.

jueves, 10 de octubre de 2013

iKAT – Interactive Kiosk Attack Tool

1. Introducción

iKAT, Interactive Kiosk Attack Tool, es una herramienta diseñada para facilitar a los consultores de seguridad la tarea de auditoría en entornos de navegación “restringidos”, tales como terminales de quioscos que proveen acceso a Internet, así como a terminales Citrix, WebTVs, etc, proporcionando métodos para acceder al sistema operativo subyacente y realizar una escalada de privilegios local de forma automática.

Presentado como un sitio web SaaS (Software como servicio), ofrece un gran número de técnicas para evadir dichos entornos de navegación y lograr obtener una ejecución de comandos en sus sistemas.

Además de poder descargarlo y configurarlo en nuestra propia máquina, también existe la posibilidad de utilizar su versión online a través de la dirección http://ikat.ha.cked.net.

2. Funcionamiento

Su funcionamiento es bastante sencillo. A la hora de auditar un quiosco tan sólo hay que establecer una conexión al lugar donde se esté ejecutándose iKAT. Una vez realizada la conexión, la herramienta identifica el sistema operativo que está siendo usado en el quiosco, poniendo a nuestra disposición un menú con las distintas categorías de técnicas disponibles para el mismo.

Figura 1. Menú principal iKAT (Entorno Windows)


3. Módulos de la herramienta

Las categorías que incluye esta herramienta son las siguientes:
Auto Exploitation (Autoexplotación)
Técnicas que se aprovechan de forma automática de las distintas vulnerabilidades conocidas en los navegadores, cuyo objetivo es el de lograr ejecutar comandos en el sistema. Tiene la opción de hacer uso del módulo Browser AutoPwn de Metasploit Framework, que puede ser útil para realizar posteriormente tareas de post-explotación.

Reconnaissance (Reconocimiento)
Herramientas para obtener información del objetivo, como puede ser el navegador usado, plugins y variables del mismo, configuración de flash, etc.

File System Links (Enlaces al sistema de ficheros)
Listas de enlaces accesibles desde el navegador a archivos y directorios útiles del sistema de ficheros local, como unidades de disco, recursos de red, herramientas administrativas, escritorio, etc. Para ello se aprovecha, entre otras cosas, de los handlers disponibles de Windows Shell.

Common Dialogs (Diálogos comunes)
Distintas opciones con el fin de lograr salir del entorno controlado a través de cuadros  de diálogo comunes, como puede ser guardar, guardar como, abrir, importar, exportar, ayuda, buscar, imprimir, etc.

URI / File Handlers (Manejadores de ficheros / URI)
Lista de enlaces a los manejadores de archivos y protocolos más comunes, cuyo fin es el de averiguar las aplicaciones instaladas que están asociadas a distintos ficheros y/o protocolos.

Browser Addons (Complementos del navegador)
Applets de Java, .NET ClickOnce, controles ActiveX y plugins de Firefox para intentar obtener una ejecución de comandos sobre el sistema.

iKAT Tools (Herramientas iKAT)
Arsenal completo de herramientas diseñadas para ayudar en la explotación de este tipo de entornos, como métodos para intentar descargar ficheros y ejecutarlos, binarios de Win32 (cmd, netcat, wget), documentos de Office y PDF para aprovecharse de vulnerabilidades del software, etc.

Figura 2. Ejemplo de explotación mediante plugins del navegador
Crash a Kiosk (Denegación de Servicio)
Técnicas que se aprovechan de vulnerabilidades y plugins del navegador con el fin de bloquear la aplicación del quiosco, consiguiendo de esta manera exponer el sistema operativo subyacente.

En resumen, iKAT es sin duda alguna una gran herramienta para auditar este tipo de entornos restringidos de una manera sencilla y potente.


Autor: Daniel García
Departamento de Auditoría.