Security Art Work

Desde siempre el spam ha sido un problema para el buen funcionamiento de cualquier proyecto web. Tampoco es un secreto que uno de los mayores factores de generación de spam son los robots que recorren la totalidad de multitud de webs dejando huella de su paso en forma de, generalmente, comentarios y mensajes con contenido malicioso.

Pero, ¿qué medidas fiables tenemos para luchar contra el problema del spam? Muchos se basan en hacer que el usuario introduzca un texto o resultado de operación matemática, incluyéndolo de forma que una persona lo pueda procesar fácilmente pero no así un robot; estos son los conocidos Captchas. En este caso estamos dejando al usuario malintencionado (o robot de spam) entrar a nuestra web, e intentamos evitar que interactúe con ella.

Esta alternativa que les presentamos, llamada Bad Behaviour por razones obvias, partiendo de la base de la lucha contra el spam va un paso más allá, impidiendo a estos usuarios (o robots) maliciosos la entrada a su página web objetivo. Esto está muy bien pero, ¿cómo funciona Bad Behaviour? Es muy sencillo. La aplicación recibe cada petición realizada a su entorno web y comprueba diversos parámetros de la misma para detectar si la petición la ha realizado un usuario legítimo y no se trata de ningún robot ni usuario malintencionado. En caso de que encuentre una petición de este tipo, devuelve un simple error del tipo “403 Bad Behaviour”, en lugar del contenido original de la página solicitada.

Entrando más al detalle, este proceso se realiza de dos formas claramente diferenciadas. Por una parte la aplicación contiene un listado de posibles elementos o comportamientos que pueden convertir una petición en sospechosa de ser maliciosa (por ejemplo cabeceras erróneas, como la User-Agent, o peticiones que no respetan el contenido del fichero robots.txt en caso de que lo tengamos configurado), y por otra rechaza peticiones de orígenes maliciosos al conectarse a una base de datos pública de IPs maliciosas constantemente actualizada.

Este proceso puede parecer lento y su demanda de recursos alta, pero se ha demostrado que puede llegar a introducir una mejora en el tiempo de carga de las webs ya que al bloquear los accesos malintencionados se dejan de enviar páginas web completas (con todos sus elementos y contenido multimedia) y se envía un simple mensaje de error en su lugar, lo que reduce considerablemente el ancho de banda consumido por estas peticiones y la carga de los servidores.

En lo que respecta a la instalación, esta aplicación se creó inicialmente como una extensión para WordPress (motor que da vida a este mismo blog), pero su diseño modular le permite adaptarse a prácticamente cualquier aplicación basada en PHP. Actualmente existen instrucciones de instalación para otras de las aplicaciones web más comunes como MediaWiki, Drupal, DokuWiki y Geeklog, e incluso algunos CMS lo incluyen en su instalación por defecto (es el caso de LifeType).

Si no la conocían, espero que la prueben y nos dejen sus comentarios sobre la funcionalidad de esta aplicación y su funcionamiento.

Como muchos de ustedes sabrán, el pasado 6 de abril el INTECO (Instituto Nacional de Tecnologías de la Comunicación) publicó la primera versión de su aplicación ConAn, su herramienta de análisis de seguridad para entornos Windows. Se presenta como un complemento a otros sistemas de seguridad que pueda tener el cliente instalados en su máquina, ya que no interfiere en el funcionamiento de antivirus ni firewalls, sino que los complementa.

En lo que respecta a funcionalidad, ConAn agrupa la funcionalidad que hasta ahora ofrecían por separado otras herramientas, permitiendo por ejemplo revisar, entre otros, las actualizaciones del sistema y la seguridad de Internet Explorer (al estilo de MBSA), detalles sobre los procesos y servicios en ejecución (al estilo de multitud de programas, entre los que se encuentra el archiconocido Process Explorer, de Sysinternals), detalles sobre las conexiones de red establecidas y los programas que las están realizando (como en cualquier software cortafuegos), etcétera.

Para utilizar esta aplicación es necesario registrarse previamente en la web que INTECO ha preparado al respecto para posteriormente proceder a la descarga de la aplicación. La descarga es liviana (ocupa menos de 1MB) y su proceso de instalación es el típico de aplicaciones Windows.

Una vez instalada, la aplicación pide de nuevo los datos de conexión utilizados para descargar la aplicación, dado que tras el análisis del sistema (proceso que realiza con bastante celeridad, al menos en las máquinas probadas) la aplicación vuelca el informe a la web de INTECO, para que pueda ser accedido posteriormente con mayor facilidad. Si no disponemos de conexión a Internet en la máquina a analizar tampoco hay ningún problema, ya que podremos realizar el análisis sin conexión y enviarlo posteriormente en el apartado correspondiente de la web de ConAn.

Dejando aparte los posibles problemas de privacidad y robo de datos que este envío de informes pudiera suponer y que discutiremos en otras entradas, cabe remarcar que los informes destacan por su buena estructura, el uso de iconos para mostrar los distintos niveles de seguridad y el uso de un lenguaje claro y directo que los usuarios poco familiarizados con los entresijos de la informática seguro que podrán entender. Además, en cada punto del informe se proporcionan una serie de recomendaciones de seguridad proporcionadas por la Oficina de Seguridad del Internauta, y también información adicional de organismos y otras fuentes externas, que complementan la información proporcionada por el propio INTECO. A continuación hemos incluido algunas pantallas del programa, aunque es recomendable que lo prueben ustedes mismos.

Más información y noticia original en INTECO.

Descarga del programa: ConAn

Siguiendo con la entrada sobre la inseguridad de sentirse seguro, me gustaría ahora describirles 3 tecnologías de uso habitual que dan una falsa sensación de seguridad:

– Antivirus: Siempre que le explico a algún no especialista que es un antivirus, le explico que no es un “antivirus”. Es muy sencillo; un antivirus es la forma abreviada (o comercial) de decir que es un antivirus de virus conocidos. Sí, existen módulos heurísticos y otras historias de ciencia ficción, pero la realidad es que los virus nuevos no son detectados por los antivirus hasta que son conocidos. Esto implica que si tenemos la mala suerte de toparnos con un virus de relativa novedad no conocido por nuestro antivirus, éste será de poca utilidad. Obviamente, aunque el antivirus que utilizamos lo reconozca, si el nuestro no se encuentra actualizado, la consecuencia es la misma, de ahí la importancia de actualizar las firmas del AV.

– IDS de red: Los IDS tienen el mismo problema que los antivirus: son “IDSs de patrones conocidos”, pero son mucho peores que los AV ya que por lo general no toman medidas inmediatas, sino que se limitan a registrar e informar. Además, existen numerosas ocasiones en las que están “ciegos”, como por ejemplo en el tráfico cifrado en el que funcionan todas nuestras web corporativas importantes. Además únicamente registran intrusos en base a patrones “técnicos”, pero no a nivel de “negocio”, de modo que alguien puede estar haciendo transferencias bancarias de forma masiva, y el IDS sólo vera un usuario utilizando la aplicación de transferencias.

– Los auditores de vulnerabilidades (Nessus / OpenVAS / etc): Volvemos a lo mismo. No podemos estar tranquilos con haber pasado un scanner de vulnerabilidades y ver que todo queda corregido, dado que éstos únicamente lo son de vulnerabilidades conocidas y en su gran mayoría de software conocido, por lo que todos los desarrollos adhoc pueden ser completamente vulnerables a ataques de todo tipo y pasar inadvertidos. Es cierto que en este campo las herramientas están evolucionando y cada vez son mas capaces de analizar desarrollos desconocidos, pero cualquier auditoria automática de este tipo debería incluir un disclaimer en el que se indique que la herramienta sólo comprueba vulnerabilidades en versiones y configuraciones de programas conocidos, por lo que no incluye la detección de problemas en desarrollos propios, programas no conocidos o partes no públicas que pueden ser facilmente explotables por usuarios maliciosos. De aquí la necesidad e importancia de que una auditoría de este tipo sea complementada con auditorías manuales, tanto de los desarrollos a nivel de código, como a nivel de interacción con el usuario final.

Dicho esto, ¿cómo actuar en estos casos? El planteamiento es muy sencillo: se debe trabajar con el supuesto de que las herramientas no existen:

– Antivirus: Debemos actuar como si no se dispusiera de antivirus. En un entorno de oficina, por ejemplo, no ejecutar programas de los que no se conozca el origen, limitar la ejecución de binarios y código externo, eliminar los ejecutables que llegan por correo electrónico, restringir la descarga de ejecutables a través del proxy web, y deshabilitar el acceso a programas en unidades CD/USB.

– Detección de intrusos de red: Al IDS de red le pasan desapercibidas muchas cosas, y potencialmente puede generar un gran número de falsos positivos. No obstante, si conoce su negocio y sus aplicaciones seguro que sabe dónde mirar para detectar cosas extrañas; trate de añadir IDS de host, o integrados dentro de la lógica del negocio, ya que serán mucho más efectivos. Y por supuesto no los utilice como excusa para no tener en perfecto estado de revista la seguridad de sus servidores.

– Auditorías de vulnerabilidades: Como se ha comentado, no es suficiente con los análisis que se limitan a los datos de la caja negra. Debemos revisar de manera no exclusivamente automática las actualizaciones de versiones de los programas, su funcionamiento cuando interactúan con el usuario, la configuración de las aplicaciones con respecto a la seguridad (usando guías de buenas practicas, o mediante el análisis de todas sus funcionalidades), y por supuesto controlar el desarrollo desde su orígenes, incluyendo la seguridad en todo el ciclo. La idea es que el hecho de que la herramienta de auditoría que utilizamos no haya encontrado un problema de seguridad no significa que no exista, e incluso puede estar más cerca de lo que pensamos.

Entonces, ¿dejamos de utilizar estas incompletas e imperfectas medidas de seguridad? Repasemos de nuevo los tres puntos:

– Antivirus: Hoy en día, en ninguna cabeza cabe el no disponer de antivirus en cualquier entorno Windows, así que además de aplicar las prácticas seguras descritas previamente, hay que asegurarse de su correcta actualización de este, para que al menos esté al día de los virus conocidos. Es decir, que obviamente sí lo debemos de tener.

– IDS: Mi opinion sobre los IDS (no compartida por muchos miembros de este blog) es que son bastante inútiles (esta entrada que va un poco en esa línea), y si no tienen funcionalidad automática de IPS sirven para muy poco (aunque eso puede generar otro tipo de problemas diferentes). En todo caso, la mayor utilidad que le veo a un IDS es la de detectar malware interno poco sofisticado, es decir intrusos internos, con lo que sí pueden ser positivos, aunque el objetivo debería ser que no llegaran dentro. También puede ser útil como herramienta de diagnóstico, para buscar algún patrón concreto en difusión amplia de malware. En definitiva, para ciertas finalidades contar con un IDS es sumamente interesante.

– Auditor de vulnerabilidades: Aunque sean herramientas imperfectas, por su bajo coste de ejecución (se realiza de manera centralizada) pueden ser un primer paso para auditar una red. Aunque es verdad que cada vez son mas inteligentes y son mas capaces de auditar desarrollos genéricos (sqlmap es una maravilla), siguen siendo potencialmente peligrosas en cuanto a que la visión de auditoria de caja negra dista mucho de ser todo lo completa que la puede realizar un “humano” y puede generar una percepción de seguridad inexistente, además de ser infinitamente mas incompleta que una auditoria de caja blanca.

Como creo que era de esperar, usen todas ellas, pero tengan en cuenta siempre los disclaimers correspondientes y no se queden tranquilos con estos “false friends“. En una entrada posterior veremos qué pasa con las certificaciones: ¿”false friends“, o no?

(Continuamos con la interrupción de las entradas de la Black Hat, en este caso para hablar de PVLANs. El lunes que viene sin falta retomamos el día 2 de la BH)

Hace unas semanas, José Luis introducía el concepto de Private VLANs (PVLANs) para la securización de las DMZ. Vamos a ver en esta entrada algunos aspectos interesantes de esta tecnología.

Como vimos, las PVLANs (Private Vlan’s) consiguen el objetivo propuesto de aislar los servidores de la DMZ unos de otros. Lo que no está claro es qué rango de direcciones IP, o mejor dicho a qué subred va a ir asociado cada servidor. Hay gente que tiene la falsa creencia de que para conseguir aislar los servidores unos de otros tenemos que gastar subredes distintas, utilizando una para cada servidor, e incluso gastando para ello las PVLAN’s. Y aquí es donde radica la ventaja de dicha tecnología: sólo necesitamos una subred para asignar direcciones IP a nuestros servidores alojados en la DMZ. Por ejemplo, si disponemos de 50 servidores en la DMZ, y no queremos que se vean unos a otros, en lugar de utilizar 50 subredes diferentes (por ejemplo, 192.168.1.x, 192.168.2.x., …, 192.168.50.x) podemos utilizar una única subred para todos ellos (por ejemplo, 192.168.1.1, 192.168.1.2, …, 192.168.1.50), y con PVLANs conseguiríamos el objetivo de aislar los servidores, dando la sensación de que cada servidor está aislado del resto.

[Read more…]

(N.d.E.: Interrumpimos la programación habitual de la Black Hat para hablar de máscaras en su sentido menos erótico festivo. No obstante, que reine la calma, ya que mañana continuaremos con el día 2 de la BH a cargo de Roberto)

Como ustedes saben, los permisos en las máquinas Unix/Linux se dividen en tres dominios: usuario, grupo y otros. A cada uno de estos dominios se le puede aplicar tres permisos: ejecución (x o 1), escritura (w o 2) y lectura (r o 4). Cuando un usuario en Linux crea un fichero o un directorio, éstos deben tener unos permisos. Estos permisos por defecto se establecen mediante una máscara. Hasta aquí, nada nuevo bajo el sol.

El comando para listar los permisos por defecto, la máscara, es umask:

$ umask
0022
$ mkdir directorio
$ touch fichero
$ ls -l
total 4
drwxr-xr-x 2 moxilo moxilo 4096 2010-04-15 00:07 directorio
-rw-r--r-- 1 moxilo moxilo    0 2010-04-15 00:07 fichero

Como ven, para un directorio los permisos por defectos son 755, y para el fichero 644. Estos permisos por defecto son establecidos por la máscara del usuario, en nuestro caso 0022. Para nuestro ejemplo tomamos los tres últimos números (022). Pero, ¿por qué 022? Pese a que tradicionalmente se ha creído que estos permisos se obtienen por la resta del valor 777 menos la máscara en el caso de los directorios, y de 666 menos la máscara para los ficheros, ésta es una conclusión errónea. Lo que realmente ocurre no es la operación resta, sino la operación AND de la negación de la máscara.

En el caso de los directorios la operación es 777 (111 111 111) AND ~(valor mascara en binario), y para los ficheros es igual pero con 666. Veámoslo con un ejemplo:

1º) Dada una mascara con valor 136, su representación en binario es 001 011 110.
2º) La negación de la mascara es el valor 110 100 001.
3º) Para calcular los permisos de los directorios, se realiza la operación AND entre 777 y la negación de la mascara: 111 111 111 AND 110 100 001 dando como resultado 110 100 001, es decir 641.
4º) Para el caso de los ficheros sería la operación AND entre 666 y la negación de la mascara: 110 110 110 AND 110 100 001, dando como resultado 110 100 000, es decir 640.

Si hubiéramos hecho la operación resta para directorios, veríamos que: 777 – 136 = 641, es decir el mismo que con la operación “AND ~(Mascara)”. En cambio, esto no sucede así con los ficheros, ya que 666 – 136 = 530, cuando su valor real es 640.

Por tanto, en caso de los ficheros, una máscara cuyo valor sea 136 estaría dando por defecto permisos de lectura y escritura al usuario (6), de lectura al grupo (4) y ninguno a otros (0). Pero no permisos de lectura y ejecución (5) al usuario y permiso de escritura y ejecución al grupo (3) que es el valor que obtendríamos si restáramos.

$ umask 0136
$ umask
0136
$ mkdir directorio
$ touch fichero
$ ls -l
total 4
drw-r----x 2 moxilo moxilo 4096 2010-04-21 22:09 directorio
-rw-r----- 1 moxilo moxilo    0 2010-04-21 22:10 fichero

Por tanto, recuerden que el método de la resta sirve únicamente para los directorios, pero no así para los ficheros. Es por ello que debemos tener precaución cuando realicemos una modificación sobre la máscara; mi recomendación, si me lo permiten, sería cambiar la mascara a 0027.

En su segundo día, la Black Hat Europa comenzó con la presentación de Thai Duong y Juliano Rizzo sobre Crypto ataques a aplicaciones web. Su investigación se ha dirigido a cryptoanalizar el modo de cifrado por bloque Cipher-Block Chaining. CBC fue inventado por IBM en 1976. En este cifrado, a cada bloque de texto plano se le aplica una operación XOR con el resultado del bloque anterior. De esta manera el resultado de un módulo es dependiente de los anteriores, excepto para el primero que se utiliza un vector de inicialización IV. La siguiente imagen es muy ilustrativa:

El tamaño de bloque suele ser de 8 bytes con un cifrado DES/triple DES o 16 bytes para AES. Por lo que respecta a la clave de cifrado se utiliza 56 bits para DES, 168 bits para triple DES y 128, 192 o 256 para AES. Pero, ¿qué ocurre si el último bloque de texto plano no es del tamaño requerido? Pues que es completado con información arbitraria, normalmente 0’s por seguridad. Esta última afirmación es justamente una de las debilidades del sistema.

Thai Duong y Juliano Rizzo presentaron el ataque Padding Oracle, el cual requiere que el atacante pueda interceptar mensajes con padding y a su vez tenga acceso al sistema que lo comprueba a modo de oráculo. El proceso que un atacante podría realizar para comprobar si el rellenado de bits es correcto es el siguiente:

• Se remite la cadena cifrada al oráculo.
• El oráculo mediante la clave de cifrado comprueba si es correcto el padding
• El oráculo contestará al atacante con un 0 si es incorrecto o un 1 si es correcto.

Si el lector quiere ampliar conocimientos en cuanto al proceso completo recuperación de la trama de bytes original puede consultar su paper, disponible online.

Como caso práctico de implementación del ataque, Thai y Juliano presentaron la rotura de un captcha que utiliza este modo de cifrado. El sistema utiliza CBC para albergar el texto detrás de la imagen difuminada, lo que han denominado ERC.

<img src=”/captha?token=ERC”/>

El ERC se guarda en un campo oculto del formulario o en una cookie. Cuando el usuario remite el código introducido por teclado, el servidor compara la cadena con el resultado de descifrar el ERC. Si son iguales el resultado del captcha es correcto. De esta forma el servidor que recibe el ERC es susceptible a ataques de Padding Oracle siempre y cuando respondan ante rellenados de bits incorrectos. En la mayoría de sistemas, cuando se modifica el ERC y el rellenado es correcto el servidor devuelve una imagen con un código difuso, pero el problema viene cuando el servidor ha inicializado el IV con información aleatoria dificultando la obtención de P0. Para solventarlo, Thai y Juliano proponen obtener P0 y el IV de una imagen introducida por un usuario normal.

Otros sistemas que utilizan CBC e identificados por los autores del ataque, son las View States de JavaServer Faces. Nuevamente, un 10 para estos chicos.

La BH Europa, en general nos ha dejado muy buen sabor de boca, aunque no todo fueron peritas en dulce. La única nota negativa la trajo James Arlen, que a través de un seductor titulo SCADA and ICS for Security Experts tuvo a la audiencia expectante, esperando las últimas novedades sobre seguridad SCADA. Nada mas allá de la realidad, detrás de un gran orador —todo hay que reconocerlo— la conferencia no aportó novedad alguna, vertiente técnica, o aplicación interesante.

Por el contrario, Manish Saindane de Attack and Defense Labs acudió con una propuesta sobre como atacar aplicaciones que utilizan objetos serializados en Java. Manish ha desarrollado un plugin para Burp que permite al Pentester editar objetos Java on the fly. La serialización de objetos Java es un protocolo implementado por Sun para convertir objetos en tramas de bytes, con el objetivo de guardarlos en disco o transmitirlos por la red. Este flujo de datos contiene la suficiente información para reconstruir el objeto original. A título informativo, la clase que puede instanciar objetos de este tipo son ObjectOutputStream y ObjectInputStream, cuyos métodos serializables son: readObject(), writeObject().

Cuando un objeto serializado es transmitido por la red se puede identificar por su cabecera con los bytes 0xac 0xed, aunque es posible que viaje comprimido en formato zip. Si el objeto es de tipo String, por ejemplo, éste vendrá codificado en UTF-8 modificado. El ataque funciona de la siguiente manera:

[Read more…]

Continuando con la crónica de la BH Europa que estamos realizando estos días, en la cuarta exposición Paul Stone de Context (empresa de seguridad del Reino Unido) vino con una propuesta muy interesante sobre nuevas técnicas de ClickHacking, presentándonos una nueva herramienta que permite implementar este tipo de ataques. Destacar que ésta se puede descargar y juguetear con ella.

El ClickHacking es un término relativamente nuevo (sobre 2 años), que básicamente consiste en hacer que el usuario pinche (clickee) en cierto contenido oculto a través del uso de iframes, permitiendo a un atacante realizar acciones como un usuario lícito. Un ataque típico contra versiones de Flash antiguas permitía a un usuario mal intencionado tomar el control de la cámara y el micrófono de la víctima habilitando la configuración de seguridad.

Este tipo de nuevas técnicas presentan las siguientes características:

• Se evita la protección Anti-CSRF
• Se inyectan Clicks no datos
• No funciona el ataque si la distribución de la página cambia
• Requiere de la interacción con el usuario
• Se puede evitar con Anti-Framing

Pues bien, vamos a ver un ejemplo de cómo utilizar esta fantástica herramienta, aunque para aquellos interesados, nada mejor que probar la aplicación directamente. En primer lugar cargamos el Framework abriendo con el navegador el recurso cjtool.html. En el frame izquierdo tenemos el menú de acciones y en el derecho el entorno de acción.

En el cuadro de texto URL introducimos la dirección de la página que queremos que interactúe con el usuario de forma oculta. En el marco derecho por tanto y tras pinchar en “Go”, identificamos los campos donde queremos inyectar el Click. En este caso vamos a hacer la prueba con un entorno phpLDAPadmin. Nuestro objetivo será que cuando el usuario realice un primer Click se rellene el campo contraseña con un valor arbitrario, y en una segunda pulsación del ratón se producirá un evento sobre el botón enviar. Este ejemplo es meramente ilustrativo de cómo utilizar la herramienta, ya que no se pretende autenticarse con las credenciales del usuario legítimo. Un escenario real donde se pudiera aprovechar esta vulnerabilidad sería por ejemplo, un site bancario donde el atacante mediante una serie de acciones sobre la página pudiera completar una transacción bancaria a favor del atacante.

Volviendo al ejemplo, en el menú izquierdo encontramos las acciones que se pueden “programar” sobre la página: Cargar URL, hacer un Click, introducir texto, arrastrar contenido, o extraer contenido. Introducimos en primera instancia una cadena de texto arbitraria en el campo contraseña. Hacemos click en Enter Text, arrastramos la cruz verde desde el menú izquierdo al campo contraseña del frame derecho, y por último introducimos la cadena deseada.

Lo siguiente es establecer la acción de presionar sobre el botón “Entrar”. Pulsamos sobre el botón “Click” y nuevamente arrastramos la cruz sobre “Entrar”.

Una vez establecidas las acciones que queremos que realice el usuario, podemos simularlo con Replay Steps. Inmediatamente en el marco derecho vemos como el puntero se sitúa sobre el campo contraseña movamos donde movamos el ratón. Tras hacer click, la cadena programada es copiada en el formulario, pasando el puntero nuevamente al botón “Entrar”. Una última pulsación permite entrar en la aplicación sin que el usuario lícito se entere.

Sin ninguna duda, un gran trabajo de Paul Stone y el equipo de Context, ¡un 10!

Continuando con la crónica de la BH Europa, un magistral Christopher Tarnovsky vino a presentarnos Hacking Smartcards, un trabajo de más de seis meses que ha comenzado a dar sus frutos durante este último mes y que ha expuesto en exclusiva para la Black Hat.

Para que todos nos hagamos una idea sobre que ha versado su trabajo o su impacto, comentar que en nuestra vida diaria vivimos con Smartcarts: monederos electrónicos, gestiones bancarias, soporte para albergar el certificado del DNI-e. Una Smartcard era uno de los dispositivos más seguros y donde fabricantes de tarjetas y entidades bancarias depositaban su confianza. Pues bien, este “monstruo” pensó lo que es obvio, en algún punto de la circuitería interna del chip existe un bus de datos donde la información viaja en claro antes de pasar al módulo de cifrado. Esta frase, que resulta muy fácil decir, es una tarea faraónica dado los millones y millones de transistores, puertas lógicas y buses que puede tener el integrado.

En el mundo existen prácticamente 3 fabricantes de estos tipos de tarjetas que implementan una unidad de proceso 6805 (ST), 8051 (NXP) o AVR (ATMEL). Su estudio ha sido orientado al fabricante INFINEON, aunque como él comentaba el ataque puede ser extendido a otros modelos. Las fases que ha seguido Christopher para llevar a cabo el Hack son:

[Read more…]

Como era de esperar una de las conferencias de seguridad más importantes del mundo, la Black Hat, no ha defraudado en su vertiente europea. Un gran escenario, el Palau de Congresos de Catalunya, ha servido de perfecto telón de fondo para albergar a la crème de la crème de los profesionales de la seguridad mundial, es por eso que S2 Grupo no podía faltar. Nada más llegar, un dato aportado por la organización resulta a un servidor sensiblemente preocupante, la distribución de asistentes por países refleja un escaso interés por parte del auditorio español (empresas, entidades públicas, I+D) haci las seguridad y la protección de la información. Con una participación entorno a 500 personas, tan solo 28 españoles constaban como inscritos. Por el contrario colegas de la profesión con un importante número de horas de vuelo a sus espaldas el día anterior, como Estados Unidos, aportaban 58 asistentes. Vietnam, la India, Alemania, Argentina, Francia o Rusia hacían presencia de forma significativa.

El evento fue en su primer día inaugurado por Max Kelly, máximo responsable de seguridad del bien conocido portal social Facebook. Éste introdujo los valores de seguridad que son aplicados en su política y que muchos de nosotros en nuestras organizaciones deberíamos seguir. En primera instancia, según palabras de Max, Facebook persigue mediante su equipo legal a todo aquel atacante o intruso que realice acciones ilícitas contra sus sistemas, mediante la CAN-SPAM (15 USC 7701), Computer Security Fraud And Abuse Act (18 USC 1030) y evidentemente los Facebook’s Rights and Responsabilities. Para dar soporte a acciones técnicas se apoyan en la comunidad mundial de la seguridad White-Hats, analizando los ataques recibidos con el objetivo de conocer a tu enemigo. Por último hubo una frase de su presentación que debe incitar a la reflexión colectiva: Compliance isn’t security. Ahí queda eso.

Como entrantes, Joe Grand, presentador del programa de televisión de Discovery Channel Prototype This, presentó la charla Hardware is the new Software. Mientras los pentesters normalmente suelen dirigir sus acciones contra aplicaciones, servidores de correo o páginas web, el hardware es el gran olvidado. Joe comentó que hoy en día la preocupación por la seguridad a este nivel sigue avanzando en menor medida que la relativa al software, pudiendo comprometer los dispositivos mediante simples tipos de ataques que siguen funcionando desde hace años. Esto es debido a la escasa preparación en materias de seguridad de los diseñadores de hardware. Pero, ¿cómo adentrarse en este mundo? Entre otras, sugirió dos paginas donde fundamentalmente se puede adquirir material para ello, www.adafruit.com y www.makershed.com. Es necesario básicamente: ChipQuickSMD (kit de eliminación limpia de integrados), Picoscope (osciloscopio software), microscopio y un soldador claro.

[Read more…]