Sandboxie Cristalizada

Cuan niño en la playa, hace unos meses vimos que la solución de Sandboxie ofrecía una virtualización a la carta para cualquier problema o archivo que quisiéramos abrir en un entorno controlado. Lo cierto es que es una utilidad que te permite ejecutar esos anexos sospechosos de forma más o menos segura y sin necesidad de tirar de máquinas virtuales como Virtual PC, VMWare, etc. El modelo de Sandboxie es tan bueno que hay sistemas operativos como Qubes OS (del cual vuelvo a hablar, jeje) que se basan completamente en la virtualización de todo, Chromium OS (al cual estoy deseando echarle el guante) parece que también va a apostar por un fuerte aislamiento de procesos.

Y ya está, ya tenemos seguridad. Surfeemos por las olas más peligrosas de Internet con nuestro navegador en su cajita de arena bien tranquilos de que los tiburones de las vulnerabilidades, troyanos, etc. se llevarán un chasco al morder. ¡Error!, veamos de lo que nuestra cajita de arena es capaz de protegernos por defecto:

Levantar un servicio: Sandboxie es capaz de capturar todas las llamadas a rutinas del sistema, por tanto hace una cosa en la que se basa gran captidad de malware, “hookea” esas llamadas y las intercepta según estén permitidas o no. Por defecto no podremos levantar servicios:

Ejecutar una tarea programada: No nos servirá de nada, si recordáis existía un pequeño fallo que permitía programar una tarea con el comando “at” y que el proceso lanzado fuera con unos privilegios un tanto superiores, eso en una sandbox no pasará:

¡¡Escapar de la sandbox!! No, lo he intentado, pero no se puede. Podemos probar a lanzar un Word y a partir del explorador abrir cmd.exe, exploradores, etc. de la forma recursiva que queramos hasta hacer una lista de 40 o 100 subprocesos, da igual que sea la ejecución de un comando o el lanzamiento de un notepad, todo estará en la misma cajita de arena :-S

¡¡Destrozar la sandbox!! ¿Y si lanzamos una máquina virtual dentro de VmWare? No es mala idea, hay que ver al lanzar una máquina virtual con un sistema operativo propio tendrá sus propias llamadas al sistema, que no tendrán que ver con las del anfitrión, sin embargo sandboxie detecta que nos pasamos de tamaño y lanza un error:

Con lo que la máquina virtual no carga. Sin embargo no se porta tan bien si nos da por destrozar archivos, no hay nada como ejecutar un cmd.exe y lanzar un del *.* en SYSTEM y SYSTEM32, esos comandos se ejecutarán dentro de las limitaciones de todo usuario administrador, también podemos formatear otras unidades etc. Como la SANDBOX virtualiza todos los cambios en el sistema el archivo de "cambios", irá creciendo. Sin embargo se da la particularidad de que la propia SANDBOX tira de esos archivos virtuales para correr, por lo que si nos cargamos por ejemplo la librería de la imagen, sayonara SANDBOX.

Java Virtual Machine: Otra buena idea que no funciona, si lanzamos una aplicación Java cuando quiera interactuar con el sistema será capturada, también nos aparecerá entre almohadillas “#”

Entonces no hay de que preocuparse,,, ¡o si!

Todo cambio que un programa en su cajita de arena haga en el sistema quedará reflejado dentro de la cajita de arena, es decir siempre que entres en la sandbox estará conforme el último programa ejecutado lo haya dejado. Por ejemplo si renombras cmd.exe por Pepito.exe y magnify.exe por cmd.exe (aprovechando el fallo de la lupa de Windows que comentaban en Security by Default) siempre que estés virtualizado la lupa será el cmd, de ahí que se aconseje cambiar la arena al 3x2, como a los gatos.

Pero todo esto no quita lo más importante de todo, que todo programa dentro del sanboxie tiene la capacidad de leer del sistema. No solo eso, de lanzar los comandos y aplicaciones que el usuario tenga permisos, por lo tanto podrás leer el archivo SAM o cualquier otro que te interese de los “importantes del sistema” si ejecutas tu equipo como Administrador, también podrás lanzar un FTP para mandar esa información donde quieras:

Luego podemos hacer dos cosas, o utilizamos un usuario con privilegios mínimos (lo que reduce la necesidad de utilizar sandboxies) o configuramos de forma segura la sandboxie, deshabilitando el acceso a ciertas carpetas o la ejecución de programas.

Por otro lado Sandboxie como aplicación que hookea las llamadas al sistema no se lleva bien con determinados antivirus y drivers, que pueden permitir “fugas” de la caja de arena o bien incompatibiliza la ejecución de cierto software bajo su control, tenéis una lista aquí, hay algún caso llamativo como el antivirus de Mcaffee, etc.

En todo caso y en previsión de accesos no deseados o ejecución de terceras aplicaciones ocultas, etc. en la configuración de toda sandbox se puede hacer lo siguiente:

- Restringir el acceso a Internet (eliminarlo o reducirlo a las aplicaciones que querramos).

- Obligar a que ciertas aplicaciones se ejecuten siempre dentro de la sandbox, o que todo lo que venga desde una unidad externa (CD, DVD, USB, etc.) se abra en una sandbox.

- Restringir derechos de administrador, esta opción es la más importante, así se evitará el acceso a archivos de sistema.

- NO habilitar ninguna de las opciones para reducir la seguridad de la sandbox (cambiar contraseñas, etc.) a nivel software o hardware.

- Bloquear el acceso al registro del sistema así como a los recursos que no deseemos compartir con la humanidad.

- No añadir (salvo que sea imprescindible) la comunicación mediante servicios COM como excepción de seguridad, esto permitirá que un programa dentro de la sandbox pueda comunicarse con otro que está fuera.

- Deshabilitar el acceso en navegadores a cookies del sistema, así como a cualquier recurso fuera de la sandboxie.

- Deshabilitar la recuperación instantanea de recursos. Cuando querramos cambiar la arena al gato, perdón a la sandboxie, esta opción permite recuperar automáticamente los archivos creados, lo que puede permitir a un virus salir fuera de la cajita. Esta opción debería mejorarse, ya que se basa en listas negras cuando parece más lógico que sea por listas blancas.

Como véis una solución de virtualización también puede quedarse corta si no se configura adecuadamente, sería trivial extraer por ejemplo los servicios que se están ejecutando o copiar el archivo de SAM a un PC externo. Por lo tanto es importante restringir los derechos y asegurarnos de que no ejecutamos software incompatible mientras mejora el aislamiento de procesos en nuestros sistemas operativos, que parece que es la tónica a seguir a partir de ahora :-p

Y esto es todo por hoy,,, que no por este 2010, ¡vuelvo pronto!

Salu2

(Not) Advanced Encryption Standard

Esta mañana me he levantado, aparte de con un frío de perros y la resaca de las filtraciones de Wikileaks, con una de esas noticias de bombo y platillo. El AES de 128 bits ha caído, o esa era la cabecera de un mail que he recibido con el siguiente link.

Arduo y veloz me he puesto a devorar el documento, el cual os resumo por aquí. La IACR o Asociación Internacional de Investigación Criptográfica está formada por un grupo de gente que investiga sobre nuevos algoritmos criptográficos o como reventar los actuales, por ejemplo la semana pasada publicaban una propuesta con nuevos algoritmos para tecnologías móviles y, unas semanas antes, publicaban este paper que mostraba como romper el AES en escasos 3 minutos.

La curiosidad del ataque es que no emplean debilidades de los algoritmos matemáticos utilizados para cifrar, esto es, un algoritmo de sustitución por bloques con 10, 12 o 14 rondas según el tamaño de la clave. En este caso se utiliza el llamado "side channel attack", que son un tipo de ataques distintos basados en las vulnerabilidades de la infraestructura que soporta un criptosistema. Estos ataques se basan en la observación y comparación de como un algoritmo utiliza recursos de un sistema, por ejemplo por los tiempos de consumo de procesador, por como varía la memoria caché o por los cambios en la radiación electromagnética (el ataque TEMPEST del cual hicimos un simulacro hace unos meses ).

El Side Channel Attack en este caso se basa en la observación, se requiere que un proceso "espía" visualice como otro proceso realiza hasta 100 operaciones de cifrado, esto se consigue con apenas 2 KB de datos. No es necesario conocer el texto cifrado ni la clave (obviamente), en ese proceso de cifrado lo que hace el programa espía es ir visualizando el trozo de memoria utilizado por la librería de OpenSSL y el planificador de tareas de Linux, el "Completely Fair Linux Scheduler", a partir de ahí con una red neuronal especialmente enseñada para la ocasión lanza un pequeño proceso en background que calcula la clave (y 1 millón de cosas más) en no más de 3 minutos.

Cierto es que el ejemplo en Laboratorio es con un kernel de Linux y específico para OpenSSL, pero ello no quita que a partir de este estudio se pueda migrar a otros sistemas operativos (sobretodo de tipo Linux / Unix) con relativo esfuerzo. En el paper también se comenta que la implementación de este ataque para 192 o 256 bits es posible pero no se ha demostrado.

¿Qué supone este ataque? AES se había consolidado este último año como el algoritmo de cifrado simétrico de facto, organizaciones como el NIST o la NSA le aseguraban una robustez con 128 bits más allá del año 2015 (2030 para 256 bits ¬¬), muchos procesadores del mercado incorporan un juego de instrucciones dedicado para agilizar estas operaciones y a día de hoy no existe un algoritmo de cifrado que pueda ser considerado igual de robusto (¿3DES?). ¿Qué contramedidas implementar?, bueno en el paper se habla de no utilizar la memorica cache en los procesos de cifrado / descifrado(¿?), aunque delegar los cálculos a la RAM solo implicaría ajustar el timing de CPU, no permitir a un proceso saber el tiempo de CPU que consume otro (lo que puede complicar la planificación de tareas para el CFS u otros). Mi apuesta personal es que un sistema operativo basado en Sandboxies como Qubes podría proporcionar el aislado suficiente entre procesos para evitar este tipo de ataques "de entorno" del criptosistema. Por supuesto un buen antivirus, etc. para evitar el troyano de turno que ataque AES también ayuda.

Y eso es todo por hoy, ¡buena semana a todos!

Salu2

Warcraft DiscHack (y el Falso Positivo) I/II

El por qué de la idea

Todo comenzó a finales de Agosto, un poco cansado de que mi viejo K8 3000+ no diera mucho rendimiento con juegos relativamente viejos (Bioshock, Alone In the Dark 4, etc.) volví a instalarme el Warcraft III: The Frozen Throne. Hacía ya bastantes meses que no me ponía a “ownear” así que no sabía como estaba el percal en Battle.net, cual fue mi sorpresa cuando me di cuenta que estas batallas cibernéticas ya no son lo que eran, era muy habitual cruzarse con “hackers” que se valían de cheats como desactivar la niebla de guerra (que te permite ver las unidades enemigas) o simplemente desconectarlo, el llamado disc Hack:

Aunque a mi siempre me gustó más el video del guiry flipao que, tras padecer los sufrimientos de un demon hunter y su “Mana Burn”, lo desconecta:

El caso es que, desanimado como estaba por la ausencia de fair play decidí investigar en que consistía el dischack, que era el que más me preocupaba, por lo que podía ver el proceso del juego “war3.exe” crecía exponencialmente desde que se lanzaba el ataque, la desconexión no era instantanea, más bien el juego se ralentizaba en lo que parecía un envío de paquetes con un TTL incrementando al máximo (o al menos eso es lo 1º que pensé).

Investigación

Ni corto ni perezoso me dispuse a descargar un par de herramientas muy útiles en estos casos, el WinSock y el CheatEngine, esta última está especialmente diseñada para alterar parámetros de las partidas. Winsock es muy útil para analizar la actividad de los procesos y sus flujos de comunicaciones TCP/IP. También permite establecer filtros para parar determinados tipos de paquetes, lo que puede ser útil si queremos detener el dischack ;-)

Entonces ocurrió algo que personalmente odio, ante la descarga de Winsock el Avast saltó como loco y borró el .rar que lo contenía, dando una alerta por troyano, pensando que esto suele ocurrir con las herramientas de hacking lo subí a virustotal para conocer terceras opiniones, con este resultado : 37/43 positivos con muchos Generic.WinTrojan de por medio o W32/Trojan, etc. (deberían hacer un chiste con estas alertas: Tienes menos personalidad que un Generic.WinTrojan), en mi espíritu paranoico cesé mis actividades de investigación en Warcraft y las sustituía por otras, ¿Qué hacíar realmente WinSock?, ¿me podía fiar?

Lo que realmente investigué

Como laboratorio personal tengo una pequeña máquina virtual con Windows XP SP2 , ideal para hacer un destrozo y luego volver a la normalidad como si nada, en estos casos la función de snapshot de VMWare Workstation viene de perlas. Utilizaré solo dos herramientas para averiguar que hace WinSock:

- Regshot

- Process Monitor

Con regshot obtendré rápidamente una instantánea del registro de sistema, después instalaré y ejecutaré WinSock, tomando una nueva instánea. Regshot comparará ambas imágenes y me dirá los cambios. El programa es muy sencillo e intuitivo de utilizar así que no tiene pérdida:

Tras todo ello vemos bastantes cambios en el registro, aunque muchos están relacionados con cosas que no son WinSock, las únicas entradas relevantes son las siguientes:

HKU\S-1-5-21-1935655697-764733703-839522115-1003\Software\Microsoft\Windows\ShellNoRoam\MUICache\C:\Documents and Settings\GigA\Escritorio\WPE PRO.exe: "WPE PRO"

HKU\S-1-5-21-1935655697-764733703-839522115-1003\Software\WinRAR\ArcHistory\0: "C:\Documents and Settings\GigA\Escritorio\wpepro09x.zip"

La primera parece que ha incluido en el listado de software de Windows la aplicación WPE PRO, con la ruta que tiene en el sistema, y la ha cacheado para futuras llamadas. La segunda cambia el histórico de WinRar para que figure el zip de Winsock. Nada extraño por ahora.

Tras esto lanzamos process monitor, esta herramienta de Microsoft combina las bondades de Filemon y Regmon, que formaban parte de SysInternals y han sido combinadas en este nuevo producto. Es perfecto para monitorizar la actividad de un proceso, las librerías de las que depende, las llamadas que realiza, el tráfico de red que genera, los archivos que crea, etc. etc. En este caso vemos que WinSock genera bastante actividad en el sistema, que además mezclada con el resto de procesos puede generar bastante confusión, por suerte con un botón derecho “Hightlight WPE-PRO” nos resaltará en verde lo que nos interesa.

Hay bastantes líneas, muchas de ellas son sencillamente utilización de fuentes de Windows (para lo cual tiene que leer muchos archivos), hay otras en las que llama a la librería que adjunta, WpeSpy.dll.

El programa comienza como es obvio cargándose en memoria, después pasa a añadir a la carpeta prefetch de Windows varios un archivo con la aplicación, en el mismo se han encontrado referencias a entradas de registro del mismo WPE, por lo cual entendemos que quiere que Windows tenga cacheada la aplicación para próximas sesiones. Después realizar varias consultas al sistema, mapeando la unidad raiz “C:\” así como otras de Windows, System32, etc. Después pasa a generar varios archivos en la carpeta fantasma de Windows, la odiada, enigmática y poco comprendida desde el punto de vista de los usuarios WinSxS, así que podemos suponer correctamente que tenemos varios hard-links nuevos para la posteridad.

Tras perdernos durante varios minutos por el registro de actividades de WinSock comenzamos a sospechar que todo es terriblemente normal, no hay conexiones a Internet, no hay creación de ficheros extraños, vemos múltiples llamadas a principalmente dos archivos del core de Windows, kernel32.dll y ntdlm.dll, uno para realizar llamadas al sistema (recordemos que este software sirve para monitorizar procesos) y otro para el gestor de archivos. También hay llamadas a otras librerías y drivers (como wsock32.dll) que entiendo muy necesarios para su ejecución:

Conclusión

Si, ha sido una falsa alarma, lo cual puede dejar a uno más perplejo que anteriormente, ¿37 antivirus dando un falso positivo?, al menos podrían limar un poquito las alertas y que solo fuese un Warning: Hacking Tool, pero no veo el Trojano por ningún lado, e imagino que ellos tampoco. Mi teoría es la que todos estaréis pensado, alguien lo clasifica así una vez por alguna razón y los demás copian la firma. Recuerdo el caso de una casa de antivirus que generó un falso positivo “adrede” solo para comprobar que 24 horas después todas las demás habían hecho lo mismo, sin pararse a investigar claro qué era aquel positivo.

Bueno, y ahora que tenemos una cierta confianza en nuestras herramientas vamos a analizar el famoso, “dischack” de Warcraft, pero será en otra entrada ;-)

Hacking y publicidad: Kawasaki

Desde que Angelina Jolie protagonizara la película “Hackers” allá en 1995, (enganchándome definitivamente en el mundillo de la informática - quien iba a decir que 15 años después, sería considerada una de las mujeres más bellas del mundo), la utilización de los piratas informáticos en la gran pantalla ha sido una tónica habitual, nunca olvidaré como nos salvó la vida un virus informático en la película de Will Smith “Independence Day” o como utilizaban el Nmap para desenvolverse por los mundos de Matrix:

Y es que los hackers siempre han sido esas personas misteriosas y extrañas, a las cuales das la mano mientras se vuelcan la agenda de tu teléfono y piratean la tragaperras del bar. La historia desde los tiempos de Kevin Mitnick hasta el Zar de Internet de Obama no ha desvelado ese halo místico que sigue rodeando a los hackers. Eso quieras que no siempre nos ha venido bien a los que nos dedicamos a esta profesión (en mayor o menor medida), nos hace sentirnos como John Wayne y decir de vez en cuando un, “no te preocupes nena, yo te rompo ese candado y tienes Interné gratis”, (para acabar haciendo un downgrade de Windows Vista o peores, ejem, pero esa es otra historia).

La publicidad y el marketing no son ajenas a esta moda, surgiendo términos como urban hacking que viene a ser algo así como utilizar la ciudad para cosas que no fue diseñada (yo siempre lo entendí como ser de mente abierta, o creativa...). Si bien las grandes marcas de Seguridad deben emplear la publicidad para hacerse mercado, normalmente los resultados son bastante pobres y no suelen atraer al consumidor medio (en mi humilde opinión), más bien provocar risillas o comentarios entre el personal del sector (todavía recuerdo el video de SOPHOS de kill a zombie, por que al fin y al cabo todos los antivirus te venden un 100% de seguridad (já).

Fuera de nuestra industria hoy os traigo un ejemplo de publicidad + hacking que nos brinda Kawasaky en su aniversario, lo podéis ver aquí http://www.kawaniversario.com/

Donde un supuesto hacker se carga la web conforme entramos,, yo me he quedado con las ganas de ver motos :-(

Curiosidad matinal, un saludo!

Gadget de Seguridad: WIFI ROBIN

Estupefacto me he quedado al encontrarme con este curioso aparato que, por qué no decirlo, roza la ilegalidad. Al menos tal y como la publicidad nos lo muestra:

"WifiRobin le permitirá utilizar Internet de manera gratuita y así ahorrar cuotas mensuales de suscripción. WifiRobin sólo necesita decodificar la contraseña de cada conexión con una vez y la recuerda. La gente no sabrá que alguien está compartiendo con la conexión!"

Es decir, Wifi Robin es un router que permite crackear automáticamente las redes inalámbricas protegidas con WEP con solo darle un botón, también promete intentarlo con WPA, aunque las probabilidades de éxito son bastante bajas.

En fin, un gadget bajo el eslogan "¡No vuelva a pagar por utilizar Internet! que realmente dice, ¡que paguen otros por usted!, sale al módico precio de 123 €, pero como no vas a pagar más por utilizar Internet supongo que no sale caro,, :-S

Salu2

PD: Sobre que los usuarios no sabrán que está utilizando su red no haremos comentarios :)

Payment Card Industry Data Security Standard v2

Buenos días,

Para empezar la semana una de evolución normativa / regulatoria. En Octubre se va a publicar la siguiente versión del estándar de seguridad de la industria de pago con tarjeta (la del dinero de plástico, vamos), algunos cambios ya se han adelantado a alto nivel, los cuales os pego por aquí. Todo ello dentro de un ciclo de vida que se ha extendido de 2 a 3 años, más acorde con los criterios de madurez en el gobierno de la información actuales:

Requirement Impact	Reason for Change	Proposed Change	Category
PCI DSS Intro	Clarify Applicability of PCI DSS and cardholder data.	Clarify that PCI DSS Requirements 3.3 and 3.4 apply only to PAN. Align language with PTS Secure Reading and Exchange of Data (SRED) module.	Clarification
Scope of Assessment	Ensure all locations of cardholder data are included in scope of PCI DSS assessments	Clarify that all locations and flows of cardholder data should be identified and documented to ensure accurate scoping of cardholder data environment.	Additional Guidance
PCI DSS Intro and various requirements	Provide guidance on virtualization.	Expanded definition of system components to include virtual components. Updated requirement 2.2.1 to clarify intent of “one primary function per server” and use of virtualization.	Additional Guidance
PCI DSS Requirement 1	Further clarification of the DMZ.	Provide clarification on secure boundaries between internet and card holder data environment.	Clarification
PCI DSS Requirement 3.2	Clarify applicability of PCI DSS to Issuers or Issuer Processors.	Recognize that Issuers have a legitimate business need to store Sensitive Authentication Data.	Clarification

PCI DSS Requirement 3.6	Clarify key management processes.	Clarify processes and increase flexibility for cryptographic key changes, retired or replaced keys, and use of split control and dual knowledge.	Clarification
PCI DSS Requirement 6.2	Apply a risk based approach for addressing vulnerabilities.	Update requirement to allow vulnerabilities to be ranked and prioritized according to risk.	Evolving Requirement
PCI DSS Requirement 6.5	Merge requirements to eliminate redundancy and Expand examples of secure coding standards to include more than OWASP.	Merge requirement 6.3.1 into 6.5 to eliminate redundancy for secure coding for internal and Web-facing applications. Include examples of additional secure coding standards, such as CWE and CERT.	Clarification
PCI DSS Requirement 12.3.10	Clarify remote copy, move, and storage of CHD.	Update requirement to allow business justification for copy, move, and storage of CHD during remote access.	Clarification
PA DSS General	Payment Applications on Hardware Terminals.	Provide further guidance on PA-DSS applicability to hardware terminals.	Additional Guidance
PA-DSS Requirement 4.4	Payment applications should facilitate centralized logging.	Add sub-requirement for payment applications to support centralized logging, in alignment with PCI DSS requirement 10.5.3.	Evolving Requirement
PA-DSS Requirements 10 & 11	Merge PA-DSS Requirements 10 and 11	Combine requirements 10 and 11 (remote update and access requirements) to remove redundancies.	Clarification

Esto se traducirá en Objetivos de Control, Controles y requisitos de seguridad. Hay cosas curiosas como no basarse solo en OWASP para los test de intrusión de aplicaciones web, gestión del ciclo de vida de claves criptográficas, mayor separación de capas y clara definición de las DMZ, etc.

Habrá que estar atentos en los próximos meses. Más información aquí.

Darik's Boot and Nuke

Cuantas veces os ha ocurrido de encontraros en un edificio en llamas acompañados de una bella mujer (recién rescatada) y perseguidos por maleantes mientras extraíais los planos del diseño de la última cangre burguer del PC del señor cangrejo, pero no, habéis dejado demasiadas pistas y sabéis que seréis capturados, rastreados, torturados,, o no.

Ejem, también si os ha ocurrido que os toca reciclar un disco duro o PC, tenéis que devolver un equipo prestado de un cliente o queréis vender el Pen Drive que os han regalado en eBay o quizás vais a hacer algo como Virginia, que se yo. En resumen, es preciso deshaceros de un dispositivo de almacenamiento, ¿Qué necesitáis para hacer esto con garantías? Es decir, que esa información sea eliminada de forma segura tal y como vimos en el post de Safe Destroy y no recuperable en un Data Carving Challenger. Pues estuve buscando algo que me sirviera para llevar siempre encima, en el pack de los imprescindibles junto al Hiren’s Boot, el Kon Boot, etc. Hasta que encontré el Darik’s Boot and Nuke. Una ISO de 10 MB que cumple con su cometido, auto arrancable, las opciones por defecto garantizan un borrado seguro y además configurable según los métodos “seguros” de borrado, esto es, DoD, Guttman, etc.

Os dejo unos pantallazos del DBAN CD en acción, acabando con una de mis máquinas virtuales:

Menu de "Inicio"

Entramos al Menu Interactivo y seleccionamos.

¡¡Y a destruir!!

Ya sabéis, por si un día hay que salir por patas.

Salu2

Hackers are here, Where are you?

Con este conocido eslogan del Ec-Council doy paso a esta breve entrada donde por fin, tras unas breves vacaciones, he decidido ponerme con el CEH a saco, tal y como ocurriera con el CISSP el año anterior.

El CEH, o Certified Ethical Hacking es una certificación enfocada en la parte más técnica de la Seguridad Informática y como tal es ideal para que pen testers o auditores aprendan las técnicas de hacking más habituales. Al contrario que con CISA, CISSP, etc. el proceso de certificación es mucho más sencillo, el único requisito es tener dos años de experiencia en seguridad informática e incluso dejan la puerta abierta a que si no los tienes pueden estudiar tu caso (por ejemplo, recién licenciados). Con ello y tras prepararte el examen (por tu cuenta o pagando un curso de formación) te presentas, haces un examen tipo test al uso y ya estás certificado. Es decir:

De forma un tanto curiosa una vez aprobada la certificación no te exigen créditos CPE para mantenerla (leer comentarios), lo cual personalmente es de agradecer ya que no debes estar preocupándote cada año por demostrar que estás reciclado permanentemente. Os dejo algunos datos de interés:

Dominios de conocimiento:

1. Introduction to Ethical Hacking
2. Hacking Laws
3. Footprinting
4. Google Hacking
5. Scanning
6. Enumeration
7. System Hacking
8. Trojans and Backdoors
9. Viruses and Worms
10. Sniffers
11. Social Engineering
12. Phishing
13. Hacking Email Accounts
14. Denial of Service
15. Session Hijacking
16. Hacking Webservers
17. Web Application Vulnerabilities
18. Web Based Password Cracking Techniques
19. SQL Injection
20. Hacking Wireless Networks
21. Physical Security
22. Linux Hacking
23. Evading IDS, Honeypots and Firewalls
24. Buffer Overflows
25. Cryptography
26. Penetration Testing Methodologies

Estos dominios se dividen en 66 módulos. Tenéis el brochure del material aquí. En cuanto al examen:

• Se puede realizar en cualquier centro prometric de España.
• El calendario de exámenes es flexible, no son dos convocatorias cerradas de forma anual como ocurre en otras certificaciones.
• El coste del examen son 200€.
• 150 preguntas multi respuesta.
• 70% de acierto para aprobar.

Ahora paciencia y a estudiar. Por cierto, y a colación del mundo de las certificaciones, os referencio una entrada del blog segu-info ayer publicaban el escrito de Shon Harris donde discute y da respuesta a muchas preguntas sobre CISSP que la gente se plantea. Shon es Consultora de Seguridad y da clases de formación CISSP, publicó un libro / manual / guía para prepararse la certificación, no es el oficial de ISC2 pero tiene tanto tirón (es bastante más entretenido) que mucha gente (como yo, por ejemplo) se preparan la certificación solo con el.

Salu2

TCP Split Handshake

Que mejor forma de retomar el blog que mandando un afectuoso salud a mis apreciados lectores, si los tuviera delante haríamos algo tal que así:

GigA --------->Hola:Lector

GigA:Hola + Mano<----------Lector

GigA:Mano<---------------->Mano:Lector

Etc.

Esto por si no lo habéis entendido es un saludo normal y corriente, que da paso a una conversación. Los humanos, fieles copiadores de lo que vemos en el mundo real decidimos trasladar esta forma de saludo a la informática, para que dos ordenadores pudieran iniciar su conversación lo harán de la misma forma. Es lo que conocemos como ThreeWay-Handsake , que originales somos:

Lo gracioso es que en el mundo virtual, al igual que en el real, pasamos del saludo a 3 bandas y pillamos a alguien desprevenido y le damos una colleja diciéndole: ¡ay maestro agujas!, ¡como vá capataz! (resto de saludos José Mota©), sin dejarle hablar ni nada. Esto entre colegas e incluso desconocidos puede ser gracioso, pero entre frías máquinas sin corazón es desastroso, tanto como que pueden reaccionar de formas raras, reiniciándose, parándose, ignorándote o accediendo a un nivel superior de funcionalidad (muchas veces esto también puede ocurrir con las mujeres), así una máquina se queda algo confusa cuando se le intenta abrir una conexión por ejemplo un SYN SEQ 1000, te responde con un SYN ACK 1000+1 SEQ 1500, y tu ignoras completamente su respuesta y vuelves a hacer otro SYN, y otro, y otro, y vas cambiando puerto, o le saturas un servicio a intentos de conexión, etc. Son muchas de las variedades de handshake que se pueden hacer en un escaner de puertos (para lo que vendría bien recordar esta entrada).

Sin embargo parecía que estaba todo inventado en lo que a saludos se refiere, cual es mi sorpresa cuando ayer me encontré esta interesante investigación de la gente de Macrothink, el TCP Split Handshake. Trasladado al lenguaje humano sería como realizar el saludo de forma normal, pero definir y recalcar cada una de las fases sin hacer nunca 2 cosas a la vez (¿?¿?), vale. Os pongo la imagen y me explico:

¿Qué es lo que se ha hecho?, separar el SYN, ACK que hace el servidor en dos pasos bien diferenciados, en dos paquetes distintos, algo que recoge perfectamente la RFC 793 en su página 27. Algo tan inocente como esto se ha probado con IDS/ IPS, routers, servidores, etc. con resultados más que soprendentes, y es que un servidor que tenga el protocolo de establecimiento de conexiones TCP alterado puede comprometer a sus clientes en una infinidad de casos. Veamos como reacciona el cliente cuando el servidor hace el split:

Lo que era un ThreeWay Handshake acaba convirtiéndose un FiveWay,,, de esto no decía nada la RFC 793. Otras curiosidades de esta particular forma de saludarse son que algunos IPS (lo probaron con un Juniper) no detectaron el ataque, sirviendo el splits tcp como técnica de evasión ya que, al no detectar la conexión como establecida no detectaba ataque alguno. En caso de NAT se encuentra de todo, desde un PIX-515 que era incapaz de hacer NAT y salir hacia otras redes con el splits TCP a un Cisco 2631 que se metía hasta Internet, luego parece que dependiendo del caso el NAT a priori no nos protegerá de este tipo de intentos de conexión. Finalmente, si estás ofreciendo un servicio en un puerto cualquiera, digamos el 22, y tu máquina es sometida a un escáner de red con un NMAP o similares no reaccionará tampoco de la forma habitual, pudiendo quedar oculto ese servicio o mal identificado:

Efectivamente esto para un atacante persistente no es un problema pero por ejemplo, para un barrido de un virus puede ser una “medida de seguridad”.

En resumen, este comportamiento anómalo en el establecimiento de conexiones por Split Handshake va a obligar a todo tipo de proveedores de equipos de comunicaciones, servidores, appliances de seguridad, etc. a añadir una excepción más o a contemplar que el ThreeWay Handshake no es la única forma de establecer una conexión TCP. Parece mentira que algo que lleva tantos años usándose no haya sido evaluado por muchos fabricantes en el 2010.

Ah, si queréis jugar tenéis scripts de ejemplo y capturas de Wireshark aquí, está hecho en Ruby y necesitareis las librerías libpcap para poder ejecutarlo.

Salu2