Security Art Work

(La entrada de hoy corre a cargo de Xavi Morant, colaborador de Security Art Work)

La nueva intrusión de la red interna de Sony no pasará a la historia por las técnicas utilizadas por los atacantes, ni por la dificultad en su ejecución, ni por el volumen de datos expuestos.

Esta intrusión se recordará por la escenificación que han planteado los atacantes. En sí parece una película de suspense; tiene de todo lo que se podría buscar en una novela de género: mensajes extraños, imágenes con calaveras, amenazas manifiestas, referencias al 11S, un primer aviso con un listado de todo a lo que han tenido acceso y posteriormente la publicación paulatina y meticulosa de información interna que compromete a varios grupos dentro de Sony: presupuestos, discusiones, información de sistemas informáticos y claves de acceso, además de información de los propios trabajadores (claves, número de la seguridad social, etc.), información de actores (pasaportes de Angelina Jolie y Cameron Diaz, el móvil de Brad Pitt). Después, descalificaciones expresas sobre personajes del mundillo de las películas que teniendo en cuenta que este tipo de personajes son muy propensos a aparecer en cierta clase de prensa, es evidente que amplía sobremanera la publicidad que se ha dado a esta intrusión y a los distintos grupos de personas a los que les llegará la noticia (hasta la camarera del bar de la esquina me ha preguntado por el tema este: ¿Es verdad que ha salido Brad Pitt en paños menores? En fin…).

[Read more…]

Hace unos días el Centro de Seguridad TIC de la Comunidad Valenciana (CSIRT-CV) publicó un informe de “Seguridad en Internet de las cosas”, en el que podemos encontrar una guía sobre el estado del arte de seguridad sobre este tipo de dispositivos cada vez más extendidos en la red.

Básicamente, el término IoT (Internet of Things) se atribuye a un conjunto muy grande de dispositivos conectados a Internet y no son ordenadores convencionales. Pero, ¿por qué llamarlo Internet de las Cosas? Éste término se acuñó cuando el número de dispositivos superó al número personas conectadas a Internet, por lo que ya no se podía asumir que Internet estaba formado por personas interconectadas a través de sus dispositivos, sino que realmente existen dispositivos “autónomos” conectados a la red. No nos alertemos; no estamos ante una rebelión de las máquinas (todo se andará), sino de dispositivos desatendidos que se conectan a Internet con alguna finalidad como puede ser compartir información, o facilitar acceso remoto al dispositivo.

Estos dispositivos comprenden relojes, neveras, hornos, coches, sistemas de control domótico, wearables, sistemas de control de tráfico, etc. Todos hemos visto u oído hablar, e incluso disponemos de dispositivos de este tipo, pero la mayoría no somos conscientes de las implicaciones de seguridad y los riesgos potenciales a los que se enfrentan estos dispositivos, y en consecuencia las personas y organizaciones que los empleen.

Los dispositivos IoT técnicamente no son tan distintos como parece en comparación con sistemas que históricamente han poblado la red de redes, sin embargo, existen diferencias sustanciales que hacen que sea necesario un análisis pormenorizado de los riesgos o ataques que les pueden afectar.

Uno de los puntos más importantes de estas diferencias es que en general los dispositivos IoT son dispositivos empotrados, que son menos complejos que por ejemplo un ordenador personal. Esto es debido a que están diseñados con una funcionalidad específica y no con un propósito general. Se trata de sistemas más heterogéneos puesto que los fabricantes implementan sus propias soluciones, descartando en muchos casos un sistema operativo global o común como sucede con los PCs o smartphones. Esto dificulta en gran medida el establecimiento de políticas de seguridad o la gestión de actualizaciones.

Otro punto fundamental es que, en la mayoría de los casos, el problema no está en las capacidades del dispositivo, sino en las decisiones tomadas por los fabricantes respecto a las configuraciones por defecto de los mismos. En general, los dispositivos IoT no disponen de interfaz de usuario o controles, por lo que tienen que facilitar acceso a sus interfaces de administración mediante otros medios menos amigables para el usuario, por lo que la gran mayoría de ellos (los usuarios) no serán capaces de modificar la configuración de su dispositivo. Este hecho, sumado a que los fabricantes no suelen establecer una configuración de seguridad por defecto adecuada, hace que los dispositivos posiblemente mantengan una configuración potencialmente insegura.

El último de los casos a tener en cuenta es su ubicación física; estos dispositivos normalmente se encuentran altamente distribuidos, por lo que es posible que sistemas “críticos” ya no estén protegidos en un centro de proceso de datos. Este hecho hace que sean más difíciles de proteger, ya que puede ser muy sencillo obtener acceso físico a ellos, lo que entraña uno de los riesgos potenciales más graves de seguridad.

A modo de resumen, el informe publicado por CSIRT-CV aborda los siguientes apartados principales:

• Alcance y objetivos del informe: Entorno y ámbito actuales, así como la finalidad del propio informe.
• Riesgos asociados: Identificación de los riesgos potenciales que afectan a estos dispositivos, distinguiéndolos claramente del resto de los que se encuentran conectados a la red.
• Vectores de ataque a las IoT: Posibles ataques o vulnerabilidades aprovechables que se podrían aprovechar para comprometer este tipo de dispositivos.
• Recopilación de incidentes: Casos reales de incidentes de seguridad relacionados con IoT.
• Prevención y salvaguardas: Listado de buenas prácticas para mejorar la seguridad en el uso de este tipo de dispositivos.

En la actualidad, el número de dispositivos IoT que empleamos va en aumento y se espera que la tendencia se acentúe los próximos años, especialmente los wearables, de los que no paran de surgir nuevos tipos y clases. Del mismo modo, algunos dispositivos de este tipo se están integrando en el ámbito corporativo. Este hecho supone un avance y a la vez un reto para las empresas ya que a pesar de la evolución y las ventajas puede que aportar, existe una elevada preocupación por las amenazas de seguridad que conlleva.

Por ello, debemos ser conscientes de la existencia de “Internet de las Cosas”, así como de la problemática y las recomendaciones de seguridad que se requieren para que su uso sea un avance global y no un retroceso en la seguridad, confidencialidad y libertad de las personas y organizaciones. Si el tema os ha resultado interesante os recomendamos encarecidamente la lectura de dicho informe, que os permitirá ampliar vuestros conocimientos en la materia.

El informe de “Seguridad en Internet de las Cosas” se encuentra disponible en este enlace [PDF], dentro del portal web de CSIRT-CV, y también desde su sección de descargas.

Si no tenéis nada que hacer, esta es una buena lectura para las navidades :)

Antonio Sanz en sus artículos “PDF deconstruído al aroma de shellcode”, hace un análisis empleando la utilidad peepdf de un PDF que explota la vulnerabilidad “CVE 2013-2729”.

A partir de estos artículos, se me ocurrió la idea de generar una regla de YARA para detectar estos PDF maliciosos.

Para ponernos en situación, recordemos que la vulnerabilidad CVE 2013-2729 explota un fallo de Adobe Reader X que no valida bien los datos de imágenes BMP incrustadas en el documento. Mediante este fallo se puede ejecutar código malicioso debido a que provoca un heap overflow.

La siguiente regla de yara nos permite localizar los ficheros que explotan dicha vulnerabilidad:

rule shellcode_cve_2013_2729
{
meta:
        author = "Manuel"
        company = "S2 Grupo"
        date = "2014-12-17"
        description = "PDF con shellcode CVE 2013_2729"
        link1 = "http://www.binamuse.com/papers/XFABMPReport.pdf"
        link2 = "https://github.com/feliam/CVE-2013-2729/blob/master/XFABMPExploit.py"
        link3 = "https://github.com/feliam/CVE-2013-2729/blob/master/E10.1.4.pdf "
        link4 = "https://www.securityartwork.es/2014/09/30/pdf-deconstruido-al-
                 aroma-de-shellcode-i/"
        md5test =  "eb9228f17568704676385428d3bbefff"
strings:
        $xfa1 = "XFA 1 0 R"
        $xfa2 = "XFA 2 0 R"
        $xfa3 = "XFA 3 0 R"
        $s0 = "AcroForm 2 0 R"
        $s1 = "/Filter [/Fl"
condition:
        1 of ($xfa*) and all of ($s*)
}

Para ejecutar la regla, utilizaremos la siguiente instrucción:

yara <fichero regla> -s <fichero pdf>

Esperamos que esta regla os sirva de ayuda para detectar y analizar estos hermosos PDFs con regalo que seguro que recibís estas navidades.

Comenzamos 2015 con un nuevo congreso de Seguridad Informática que nace en Santander como el primero en este ámbito en Cantabria, Sh3llCON: Security Hell Conference.

Se definen como un nuevo foro de divulgación sobre seguridad informática que surge con la finalidad de analizar las distintas amenazas y vulnerabilidades que rodean nuestra conexión diaria en las redes.

Sh3llCON se celebrará los días 23 y 24 de enero en el Hotel Santemar y contará con un interesante plantel de ponentes:

[Read more…]

Volvemos a la carga con la cuarta parte de nuestra serie sobre pfSense. En el anterior capítulo explicamos cómo configurar las opciones avanzadas del sistema (ver también la primera entrada y la segunda, para los despistados). En esta cuarta parte vamos a explicar cómo configurar “el corazón del firewall”, es decir las reglas de pfSense.

Lo primero, para facilitar la creación de reglas, es importante saber lo que son los “alias” y qué posibilidades brindan. Vamos a la pestaña superior, Firewall → Aliases.

Dentro podemos crear diversos alias como Hosts, subredes, puertos y URLs. Este es un ejemplo de creación de alias para los servidores que pertenecen a la red DMZ:

Así es como se vería un resumen de todos los Alias creados:

Ahora se trata de usar estos alias para configurar las reglas en el apartado Firewall → Rules. Lo más importante que debemos tener en cuenta al crear una regla es que prevalece la prioridad de la regla que se sitúa por encima de otra regla.

En nuestro ejemplo (y en general, en cualquier entorno en producción) la red DMZ no debe tener acceso a la red interna, ya que la DMZ es la que albergará los servidores que están expuestos a Internet y esta red no debe tener ningún tipo de comunicación hacia la red interna. Por otro lado, sí que nos interesa que se puedan gestionar los servidores desde la red interna hacia la DMZ, por lo que podemos crear una regla que permita el trafico por el puerto 22 (SSH) desde la red interna hacia la DMZ.

En el apartado Rules, la interfaz que pertenece a DMZ es “OPT1”, desde allí, existe un botón con el símbolo “+” para añadir reglas. Por tanto, creamos una regla que deniegue el acceso desde la DMZ a red interna, donde en “Destination” usamos el alias “Subnet_lan” creado anteriormente.

Exactamente de la misma forma pero desde la interfaz LAN (red interna) crearemos una regla que deniegue todo el tráfico desde red interna (LAN) a la subred DMZ (más adelante se superpondrán reglas que prevalezcan sobre esta). A continuación, creamos una regla por encima de la anterior que permita la comunicación SSH desde red interna (LAN) hasta los servidores en DMZ:

Ahora en las reglas del firewall de la interfaz LAN (nótese que el deny de DMZ hacia LAN está en el interfaz OPT1, por eso no se muestra) se vera así:

En la regla de más arriba (la más prioritaria) están permitidos dos puertos 10443 y 10022, que son los que se usan para administrar PFsense por HTTPS y SSH. Esta regla se crea por defecto y es importante que exista ya que en caso contrario, se estaría denegando el acceso al propio firewall.

El siguiente paso es configurar NAT (Network Address Traslation). Para ello en la sección NAT en Port Forwarding, configuraremos que nos permitan acceder al servidor web y al servidor FTP desde internet a estos dos equipos situados en la DMZ. En el caso del HTTP sería como se muestra en la imagen.

Tras aplicar ambas reglas, tendríamos una situación como la siguiente:

Es importante saber que al crear esta regla en NAT automáticamente se crean las reglas del firewall asociadas, de forma que se pueda hacer efectivo el acceso desde fuera hacia dentro. Por tanto, así quedarían las reglas del firewall en la interfaz WAN ahora:

Con estos ejemplos básicos ya podemos comenzar a “trastear” con pfSense y un mayor número de reglas. En el siguiente artículo veremos la implementación de herramientas como un IDS (Snort) o un proxy (Squid), dentro de pfSense.

Nota del editor: mañana por la mañana, nuestro compañero Antonio Sanz estará hablando sobre el malware del que trata el presente post, y la gestión del incidente asociado a la detección del mismo, en las VIII Jornadas STIC del CCN-CERT.

El pasado mes de agosto, varios empleados (bastante bien escogidos) de uno de nuestros clientes (una empresa estratégica), recibieron una serie de mensajes un tanto “sospechosos”, que referían el entonces relativamente reciente accidente del avión de Malaysia Airlines, sobre cuya investigación no paraban de llegar noticias.

Al abrir el documento, que en principio tenía extensión .doc, aparecía efectivamente una especie de “comunicado”, o similar, sobre el accidente en cuestión.

Sin embargo, un análisis básico revelaba que el fichero era en realidad un RTF (y no un DOC), y que venía con regalo: nuestro viejo amigo, el exploit CVE-2012-0158. Como los hashes del fichero todavía no tenían presencia pública en los servicios habituales (VirusTotal, Malwr.com, etc. obviamente, tampoco el AV corporativo lo detectaba), y dado el caracter de los destinatarios de los mensajes, pensamos que no vendría mal “jugar” un poco más con el artefacto, y lo pusimos a macerar en nuestra sandbox.

Tras unos 12 minutos (!) de espera, el especímen por fin intentó contactar con algo, y, para nuestra sorpresa, ese algo no era sino un proveedor público de servicios WebDAV. Así que el bicho utilizaba ese protocolo sobre HTTP (y no sobre HTTPS en principio), sea lo que fuera lo que pretendiera recibir o transmitir con ayuda del mismo…

Efectivamente, simulando en nuestro laboratorio el servidor WebDAV al cuál estaba intentando llegar, el especímen trataba en primer lugar de descargar información desde una determinada ruta del WebDAV, y a continuación, dejaba ficheros con nombres pseudoaleatorios, pero extensiones conocidas, sobre otra ruta.

Tras explotar, el adjunto RTF malicioso se sustituía a sí mismo por un documento “limpio” (el del comunicado sobre el accidente) que llevaba empotrado (de forma que si analizabas el documento droppeado por separado, no había forma de reparar en la existencia del exploit o del resto del malware), y lo abría con el Word, simulando perfectamente la apertura habitual de un fichero DOC.

Sin embargo, por debajo estaba droppeando y ejecutando un fichero .vbs, que a su vez droppeaba una DLL que llevaba empotrada en su propio código fuente, codificada en hexadecimal.

Esta DLL (droppeada directamente sobre %SystemRoot% si el usuario disponía de los privilegios necesarios, o sobre el perfil del usuario en caso contrario) se cargaba utilizando el comando de Windows regsvr32, persistiendo a través de una invocación del mismo sobre la habitual rama del registro HKCU\Software\Microsoft\Windows\CurrentVersion\Run. En el caso de este adjunto, la clave se escribía con el nombre Barbicas.

Profundizando sobre el análisis dinámico de la DLL (el análisis estático no arrojaba mucha más información), observamos la presencia de un packer, que para unpackear a su huésped lleva a cabo gran cantidad de operaciones intensivas en CPU (durante el proceso de unpacking, que dura varios minutos, una de las CPU del equipo víctima se mantiene al 100% de utilización). El packer desofusca el código del malware sobre nuevas páginas del mapa de memoria del proceso y pasa a ejecutarlo (direcciones 0x7FF40000 y 0x7FF80000 en la captura de muestra).

En la memoria del proceso puede encontrarse la URL del servidor WebDAV, así como el nombre de usuario y contraseña para acceder al mismo, la ruta de bajada y subida desde y hacia el servidor, y las extensiones de los ficheros que se suben al mismo.

Una vez unpackeada con técnicas estándar, fue posible dumpear la DLL (reconstruyendo su Import Table) para pasar a analizar estáticamente en más profundidad el código desofuscado. Lo primero que nos llamó la atención fue la presencia de las tablas de inicialización del algoritmo AES en la sección de datos de la DLL.

En efecto, el malware utilizaría el algoritmo de cifrado AES en modo CBC.

La clave utilizada tiene una longitud de 256 bits, estando hardcodeada en el código del ejemplar.

En efecto, el tamaño de los ficheros cifrados siempre es múltiplo de 16 bytes, el tamaño de bloque del AES, y el fichero cifrado incluye el vector de inicialización del modo de cifrado en bloques (como se desprende de los parámetros utilizados en las llamadas a las rutinas de cifrado y descifrado observadas durante el análisis dinámico que llevamos a cabo), añadiendo otros 16 bytes extra al tamaño de los ficheros.

Por lo tanto, hasta el momento teníamos un malware no público, capaz de conectarse a un servidor WebDAV (un protocolo cuanto menos original en lo que respecta a campañas sobre las que se tenga constancia) de Internet utilizando una cuenta (usuario y contraseña) hardcodeada en el código, y capaz tanto de obtener información cifrada con AES (estando la clave de 256 bits también hardcodeada) desde una ruta de esta cuenta del WebDAV para recibir instrucciones (canal de comando y control), como de cifrar y almacenar información hacia otra ruta de la cuenta del servidor WebDAV (canal de exfiltración).

Pero las sorpresas aún no habían acabado; tras analizar los demás ficheros adjuntos (recordemos que varios usuarios recibieron mensajes maliciosos), resulta que cada uno era diferente:

• El comunicado sobre el accidente aéreo droppeado (el documento “limpio”) resultó ser el mismo para todos los adjuntos
• Tanto el fichero .vbs como la DLL droppeadas eran diferentes para cada mensaje (tanto en nombre, que trataba siempre de imitar el de alguna DLL legítima de Windows, como en contenido)
• La clave del registro (Barbicas en el primer especímen analizado), variaba en cada dropper
• El tiempo de unpacking también variaba para cada adjunto, observando tiempos desde 8 minutos hasta más de 15 minutos (en cualquier caso, el proceso mantenía una de las CPU al 100%)
• El servidor WebDAV era el mismo para todos los especímenes, así como el nombre de usuario y la contraseña utilizados para iniciar sesión en el mismo (lo cuál no significa que, para otras posibles organizaciones víctima o campañas, los atacantes no puedan generar ejemplares que utilicen otras credenciales)
• Sin embargo, la clave de 256 bits para AES, así como los directorios de subida (exfiltración) y bajada (comando y control) de información, eran diferentes para cada ejemplar analizado (en todos los casos, iban hardcodeadas en el propio código)
• Las extensiones utilizadas en los ficheros subidos al WebDAV (.TAR, .TIF, .TXT, etc. en el primer adjunto) variaban en cada ejemplar

Queda claro por lo tanto que lo que observamos fue probablemente una posible campaña, utilizando malware desconocido hasta el momento y seleccionando a las víctimas de un modo altamente dirigido.

Los atacantes emplearon alguna clase de generador de especímenes; una vez un ejemplar es generado, identifica unívocamente a la víctima, así como su información exfiltrada en el WebDAV, al utilizar cuentas, directorios, extensiones de fichero y claves AES diferentes en cada mutación. Además, queda claro que esto se trataba muy seguramente de la primera fase en lo que podría haber sido una persistencia más duradera en la organización víctima.

¿Qué habríamos encontrado tras unas cuantas semanas, o meses, de compromiso?

Actualización: en 8 de diciembre de 2014, Symantec (re)bautiza el malware del que les hemos hablado (o al menos alguna de sus mutaciones) como Infostealer.Rodagose (Number of infections: 0 – 49, Number of Sites: 0 – 2).

Seguimos prefiriendo el nombre Barbicas :-) Han pasado más de 4 meses desde que observamos por primera vez el malware y el primer producto AV lo empieza a detectar (y de momento no tenemos constancia de más presencia pública, además del sitio de esta compañía AV), reportando “pocos” sitios infectados (¿se tratará pues de una campaña que ha afectado a varias organizaciones?); esto, junto al carácter altamente dirigido de las víctimas seleccionadas en el caso de nuestro cliente mantiene el interrogante por el momento.

Trataremos de mantenerles informados a medida que vaya surgiendo más información.

Actualización 2: en 9 de diciembre de 2014, Blue Coat libera un informe, (re-re)bautizando el malware como Inception. Toda la información presente en el informe es coherente con lo observado por nuestro equipo en agosto de 2014. Confirmado: es una campaña APT :-)

Actualización 3: en 10 de diciembre de 2014, Kaspersky lo ha apodado Cloud Atlas.

Para hoy tenemos una entrada de un nuevo colaborador, Alex Casanova, administrador de Sistemas Windows, Linux y Sistemas virtualizados con VMware con más de 10 años de experiencia. Adicto a las nuevas tecnologías y las telecomunicaciones dedica gran parte de su tiempo a la investigacion de sistemas radio, OSINT y redes de comunicaciones. Actualmente está involucrado en el despliegue de una red digital de comunicaciones DMR para radioaficionados. Se le puede encontrar en su twitter @hflistener y en su blog Digimodes.

Habitualmente todas las noticias sobre seguridad están centradas en el mundo de Internet y sus amenazas; pero no siempre somos conscientes de los posibles riesgos existentes en las comunicaciones fuera del plano IP. Analizar y comprender el riesgo que suponen los sistemas de radiocomunicaciones en las organizaciones debe jugar también un papel fundamental dentro de la seguridad, cuya interrupción o destrucción podría tener un gran impacto sobre la organización.

Recientemente ha sido publicado en “Communications Support Forums” una vulnerabilidad en el sistema de comunicaciones DMR (MotoTRBO) de Motorola que permitiría a un atacante, usando un terminal de radio, transmitir en la frecuencia de salida de un repetidor DMR protegido con el sistema RAS (Restricted Access to System) sin conocer la clave.

[Read more…]

La seguridad informática es casi siempre compleja, abarcando muchas áreas distintas y haciendo muy fácil caer en el equivalente técnico de la “letra de médico”.

Quién no ha tenido algún momento del estilo de tener a dos técnicos de seguridad y que comiencen a hablar de la “APT que explotaba un CVE del kernel de XP y que exfiltraba por HTTP usando 404 modificados, y que menos mal que el IDS lo pilló y le pusimos un deny en el firewall antes de que dropeara una nueva versión de malware del C2 ”.

Si eres técnico de seguridad seguramente estés sonriendo al leer estas líneas, pero si no lo eres probablemente no hayas entendido ni una coma. El problema es obvio: la seguridad informática es complicada, y comunicar en seguridad informática es más complicado todavía.

Y en mi opinión, la comunicación es algo en lo que deberíamos de trabajar todos los expertos en seguridad informática. Es necesaria tanto para convencer a la dirección para poder invertir tiempo y recursos en mejorarla, como para convencer a los usuarios de que la seguridad es necesaria (por su propio bien en muchos casos).

Por ello, me gustaría proponer una lista de libros, escritos por técnicos, pero en los que explica de una forma clara, sencilla y hasta amena, varios conceptos principales de la seguridad informática.

[Nota: Me temo que todos los libros están en el lenguaje de la pérfida Albión. Es lo que tienen los libros muy especializados …]

”Secrets and Lies: Digital Security in a Networked World”, Bruce Schneier – Ed Wiley

Schneier es uno de los mejores divulgadores actuales de la seguridad informática. Además de su blog de seguridad informática tiene varios libros publicados en los que trata de forma sencilla conceptos como el riesgo, la protección de sistemas, la criptografía y hasta la propia confianza base de la sociedad. Todos sus libros son interesantes pero “Secrets and lies” es el mejor. Si tu jefe solo tiene tiempo para leer un libro de seguridad, que lea éste.

”The Code book”, Simon Singh – Ed. Anchor

Si hay algún campo de la seguridad informática que es especialmente complicado es la criptografía (yo tengo la teoría de “la criptografía de clave pública solo se entiende a la tercera vez que te la explican”). Sin embargo, Singh hace un trabajo maravilloso explicando de una forma cristalina los conceptos más complicados de la criptografía, todo basado en momentos históricos y lleno de anécdotas. Una delicia de libro.

“Countdown to Zero Day: Stuxnet and the Launch of the World’s First Digital Weapon”, Kim Zetter – Ed Crown

Stuxnet es considerado por muchos como el primer acto de ciberguerra con todas las letras: intención, sofisticación y complejidad son palabras que vienen a la mente cuando pensamos en un malware que, posiblemente, haya abierto la caja de Pandora y que sin duda será estudiado en tiempos venideros. Zetter es capaz de narrar cómo fue detectado, analizado y erradicado de forma amena y casi adictiva, haciendo de la historia prácticamente un tecnothriller.

“Spam Nation: The Inside Story of Organized Cybercrime-from Global Epidemic to Your Front Door” – Brian Krebs, Ed. Sourcebooks

Krebs es posiblemente el periodista especializado en seguridad informática más famoso del mundo. Desde su blog analiza todas las noticias importantes de seguridad desde un punto de vista crítico pero claro. Su libro es una guía muy completa del cibercrimen, contando con todo lujo de detalles el submundo de los delitos informáticos desde los spammers hasta cómo se blanquea el dinero que es obtenido.

“The Art of Intrusion: The Real Stories Behind the Exploits of Hackers, Intruders and Deceivers” – Kevin Mitnick & William Simon, Ed. Wiley

Kevin Mitnick (alias “El Condor”) es uno de los hackers más conocidos de la historia, siendo especialmente famoso por su dominio de la ingeniería social (o como él lo llama, “hackear personas”). En este libro, basado en historias propias y de otros hackers de la época, cuenta cómo sobrepasar diversos sistemas de seguridad con pocos o nulos tecnicismos. Es muy interesante la aplicación del pensamiento lateral, y cómo atacan algunos problemas logrando saltarse la seguridad de formas a veces estúpidas pero muy efectivas.

“Inside cyberwarfare” – Jeffrey Carr, Ed O’Reilly

Ciberguerra, ciberespionaje, cibercrimen… Por mucho que cerremos los ojos, van a seguir estando ahí. Carr hace un listado muy completo de los problemas que podemos encontrarnos en Internet, enfocándose en las capacidades existentes de diversos países para la ciberguerra, así como en diferentes escenarios y tecnologías a emplear. Aunque Carr es analítico y claro, huyendo totalmente de intentar causar el pánico, el miedo que te entra en el cuerpo después de leerlo es … inquietante.

Hay muchos más libros “sencillos” para hablar de seguridad informática, pero estos son los que me han parecido más representativos. Y tú … ¿tienes algún libro de cabecera para enseñar seguridad informática a los no técnicos? ¡Compártelo!