viernes, 6 de julio de 2012

Tranki pap@s


"Tranki pap@s" es un libro en donde sus autores, Pere Cervantes y Oliver Tauste, pretenden enseñar a padres y educadores acerca de las precauciones que deben de tener en cuenta a la hora de navegar por Internet nuestros peques y jóvenes. Os pongo el índice de contenidos del libro, sacado de un preview:

  1. Para que nos entendamos, ¿qué es Internet?
  2. Mi hij@ sabe más de Internet que yo.
  3. Los pequeñ@s navegantes y los delitos informáticos.
  4. Aprende de los principales riesgos de la Red y cómo prevenirlos.
  5. Cómo prevenir la pornografía infantil. Un toque de atención.
  6. Herramientas para padres. La importancia del control parental.
  7. Cómo actuar en caso de que un menor sea víctima de un delito por Internet.

Aquí os dejo la entrevista en Onda Cero a Oliver Tauste, miembro del Cuerpo Nacional de Policía, titulada "Los padres deben ser guardianes de los menores en Internet", junto con algunas impresiones:


La entrevista no tiene ningún desperdicio, y al final acabas enterándote una cosa o dos que no sabías, o que simplemente llaman la atención. Términos como cyberbullying, sexting o grooming están a la orden del día. Otra cosa que comenta Oliver, y me gustó mucho la comparativa, es que las contraseñas (referente a redes sociales) son como la ropa interior:

  • No hay que dejarlas a la vista.
  • Cambiarlas regularmente.
  • Y no compartirla con nadie.


También se comentan temas como la activación remota de tu webcam por parte de terceros, ... así que cuidadito con lo que se hace delante del ordenador. Y no os creáis que es algo exclusivo de Windows, ni mucho menos.

Bueno, espero que os haya gustado el post. Salu2!!

lunes, 4 de junio de 2012

domingo, 3 de junio de 2012

SSDP

Mientras desarrollaba las tareas con el Wireshark para el post anterior, me encontré con lo siguiente:


Queriendo saber de qué se trataba, busqué acerca del protocolo en cuestión, y la IP de destino que figuraba en la comunicación, 239.255.255.250.

El protocolo es SSDP (Simple Service Discovery Protocol), y sirve para detectar dispositivos UPnP de la red, mientras que la IP 239.255.255.250 es la dirección de broadcast para el descubrimiento (M-SEARCH) o anuncio (NOTIFY) de servicios, empleando el puerto UDP 1900 para dicho propósito.


Si queremos desactivar el servicio en nuestro equipo, consultar el Soporte Microsoft (para máquinas Windows), y si queremos hacer lo mismo en el router, habrá que buscar la opción correspondiente a UPnP en los parámetros de configuración del mismo y desactivarlo.

También, a raíz de ésto, encontré un artículo interesante, dividido en tres partes, y que os dejo a continuación:

Ataque al UPnP en Red (I)
Ataque al UPnP en Red (II)
Ataque al UPnP en Red (y III)

jueves, 24 de mayo de 2012

DHCP

DHCP, de Dynamic Host Configuration Protocol, es un protocolo que permite configurar automáticamente los parámetros de red de equipos que pertenecen a una red TCP/IP. Se basa en Bootp, emplea UDP en la capa de transporte, y los puertos empleados son el 68 para el cliente, y el 67 para el servidor. No voy a extenderme explicando los fundamentos de dicho protocolo, ya que hay bastante información al respecto en Internet, aparte del RFC 2131, pero sí he querido contrastar dicha información con un caso práctico o real, en este caso, con mi propio equipo y Wireshark.

Como vemos en la siguiente imagen, ésta es la negociación básica entre un cliente y un servidor DHCP:


Y aquí, la negociación que ha capturado Wireshark, entre mi equipo y el router:


De un vistazo rápido, vemos que inicialmente, el cliente, al no tener dirección IP, empleará la 0.0.0.0, y hasta que no localiza el servidor, manda el aviso a todo dios con 255.255.255.255 (broadcast). También vemos que todo el proceso, tiene asignado un mismo identificador de transacción.

Ahora, voy a poner una imagen detallada y una breve descripción de cada paso:
  • DHCP Discover - El cliente hace un broadcast para localizar algún servidor disponible.

  • DHCP Offer - El servidor responde al cliente ofreciendo unos parámetros de configuración de red.

  • DHCP Request - Mensaje del cliente al servidor aceptando la configuración propuesta por el servidor en el paso anterior. También puede ser que el cliente, con este mensaje, mande confirmación de la configuración que tenía antes de un reinicio, o simplemente que esté pidiendo una extensión del tiempo de préstamo de dicha configuración.

  • DHCP Ack - El servidor acepta la solicitud del cliente y envía acuse de recibo.

  • DHCP Inform - El cliente solicita parámetros de configuración local: confirmación de configuración actual, reestablecimiento del tiempo de concesión, etc.

Esto es lo que he obtenido al ejecutar un 
#ipconfig /release



Para finalizar, pongo la definición de algunos parámetros que vemos en las capturas anteriores:

Transaction ID: un número aleatorio escogido por el cliente, que sirve para identificar los mensajes intercambiados entre cliente y servidor.

Client IP addr: dirección IP cliente. Solo se establece si se está en estado BOUND, RENEW o REBINDING y puede responder a peticiones ARP.

Your IP addr: "tu" dirección IP (cliente).

Next Server IP addr: IP del siguiente servidor que emplee bootstrap, devuelto por el servidor en un DHCPOFFER o DHCPACK.

Relay agent IP addr: IP de un agente de relay (un host o un router) empleado para pasar mensajes entre cliente y servidor.

Client MAC addr: dirección hardware del cliente.

Boot file name: fichero con parámetros de "boot" o arranque.

Magic cookie: heredado de y empleado por bootp, tiene asociada información del fabricante. Consiste en 4 octetos con la notación 99.130.83.99 en decimal o 63.82.53.63 en hexadecimal.

Option: Parameter Request List: el cliente informa al servidor de los parámetros de configuración en los que está interesado. Ésto se consigue enviando los tags de cada parámetro en cuestión.

Referencias:

viernes, 13 de abril de 2012

Descarga torrents "un poquito más rápido"

Esta entrada está inspirada un poco en "El diario de Juanito" y su "¡batch, con dos cojones!" (ya veréis por qué), y la posibilidad que tenemos de descargar pelis por medio de la web elitetorrent.net. La idea es un script en batch (no me matéis) que automatice un poco lo que es la descarga del torrent, y posteriormente el fichero de la película correspondiente. El software empleado para la descarga de torrents es uTorrent en este caso. Esto no es la nueva revolución o la herramienta definitiva, ni mucho menos. Solo he querido compartir las cosillas que me he ido encontrando por el camino, y básicamente aprender de lo realizado. A continuación, el código:



Bien, tenemos dos cosillas que resolver, por un lado descargarnos el archivo .torrent de la web, y luego, abrirlo con el uTorrent para proceder a la descarga de la peli.

1. Descarga de el/los archivo/s .torrent

Aquí entra en juego nuestro amigo wget (yo he usado la versión 1.11.4). Si os fijáis en las opciones que he empleado en la llamada del comando, creo un log que añade la fecha actual al nombre del fichero, le digo que espere 30 segundos en caso de reintento de descarga, y lo más curioso, empleo el parámetro content-disposition. Esto último es por lo siguiente: por ejemplo, si nos vamos a descargar la de "Transformers 3", una vez estemos en la página pertinente, le daríamos al botón de "Descargar el .torrent":


Cuando pulsamos el enlace, lo que ocurre es que se abre el cuadro de diálogo para salvar el archivo .torrent. Esto viene determinado por la respuesta HTTP que recibimos del servidor, que contiene el parámetro Content-Disposition, aclarado en el RFC 1806. Os pongo el intercambio de cabeceras HTTP obtenido con el plug-in de Firefox HTTP Live Headers, para que lo veáis más claro:


Bien, según el RFC, el valor "attachment" da la posibilidad al usuario de guardar el fichero. Por otro lado, el parámetro "filename" indica qué fichero u objeto es el que podemos bajarnos. Como curiosidad podéis ver que están usando un nginx.

El script tiene como parámetros de entrada un rango de valores numéricos (un ID inicial y un ID final). He querido llamar ID al número que emplean en la web para clasificar las películas. Por ejemplo, en la petición que he realizado, sería el número que vemos al final de la URL:

http://www.elitetorrent.net/get-torrent/16184

Por lo tanto, comenzará a descargarse torrents, tomando ese número de la URL, desde uno inicial hasta uno final que le pongamos. Ahora, si lo que hacía era lanzar una tras otra las llamadas a wget (un flooding en toda regla), lo que me pasaba era que me redireccionaba a una página .php que mostraba un CAPTCHA, para verificar que era un humano y no un robot. Lo que quise probar primero era ver qué criterio empleaban para hacer esa detección. Abrí la misma web con Firefox, y luego con Chrome, y de ambas maneras me mostraba el CAPTCHA. Con esto, por lo menos, podía concluir que no están usando el User-Agent como parámetro de verificación ni nada por el estilo, y que simplemente estarían comprobando la IP de origen. El "parche" que se me ocurrió entonces fue lanzar las peticiones de forma aleatoria en el tiempo, y no seguidas, usando el random módulo 60, ya que no creo que se tarde más de un minuto entre una descarga y otra si lo hicieras de forma manual. También es verdad que esto no emula al 100% una interacción manual, pero bueno, la cosa es que ya se descargaban los torrents sin problemas en la carpeta designada.

2. Ejecutar uTorrent con los .torrent obtenidos en el punto anterior

Primer problema, abrir el uTorrent con todos los ficheros de un taponazo. Para ello uso el bucle for, pero al no poder acumular los valores en una variable dentro del loop, tuve que emplear el call. Segundo, ejecuto el uTorrent con start para que el script continúe con su ejecución, porque si no, lo que pasaba era que había que cerrar la aplicación de forma manual para que el script siguiera corriendo. Por defecto he puesto un timeout de 4 horas, pero bueno, eso es a gusto del consumidor. Finalmente, una vez pase el periodo señalado, termino el uTorrent con un taskkill, ya que, aunque tiene opciones de autoapagado, no están disponibles por línea de comandos (o al menos yo no las he encontrado). Lo he puesto en comentario, pero ya si quisiéramos, podríamos proceder a apagar la máquina (se le podría añadir un retardo para que de tiempo a cerrar todo de forma ordenada y limpia).

3. Conclusiones

  • Esto es más bien para dejarlo corriendo durante la noche, o algo así, y tener al día siguiente las pelis descargadas.
  • Se podría adaptar a otras webs, para que no estar limitados a un solo site.
  • Optimizar los parámetros de configuración del uTorrent para mejorar las descargas, (quizás un tema para otro post).
  • La siguiente vez que arranques uTorrent, lo que hace éste es comprobar el estado de las descargas activas (Check), por lo que la puesta en marcha es más lenta.
  • Probar las posibilidades de otra aplicación que no sea uTorrent.
  • El problema con lo de las IDs es que, en el rango que pongas, pueden estar mezcladas películas de baja calidad, series, películas HD, etc. por lo que ahí te puedes estar descargando cualquier cosa de lo más variopinta.
  • El lugar de destino de las descargas podría ser un NAS o cualquier otra ubicación de gran capacidad.
  • Mejoras y más ideas, además de mucho más óptimas hay seguro, vamos. Prueba de ello son algunas cosillas que he visto por los foros, que empleaban listas RSS para estarse actualizados, etc., o en la entrevista de PaulDotCom en Español a Jorge Martínez (o como me gusta llamarlo, "El hombre que susurra a las máquinas", jejeje), en el que el tío cuenta como anécdota las virguerías que se montó con algo por el estilo.

Bueno, espero que os haya parecido interesante por lo menos :P Seguiré en ello, a ver qué más cosas se me ocurren. Cualquier comentario o crítica, más que bien recibida, que eso también es parte del aprendizaje. Además, me gustaría hacer algo por el estilo en Python.

Saludos ;)

sábado, 31 de marzo de 2012

Burning Safari

Burning Safari es un corto de animación realizado por unos alumnos de la escuela parisina de arte, imagen y media llamada Gobelins (todo un referente a nivel mundial), del año 2006. Lo conocí gracias al crack de mi hermano, y quisiera compartirlo con todos vosotros. Espero que lo disfrutéis:



En su página web tenéis la galería de imágenes, (que incluye bocetos, concept art, etc.) y vídeos del making-of.

viernes, 30 de marzo de 2012

Tipos de malware

Este post viene a raíz del WebCast Análisis Forense en un entorno malware, de Juan Luis García Rambla, MVP Windows Security. Me gustó mucho cómo definió los tipos de malware que existen actualmente, lo cual, evidentemente, está muy resumido:

Malware por comportamiento
  • Ocultación de elementos:
             - Rootkit: sofware que tiene como objetivo el control de la máquina, haciéndose invisible para los usuarios o aplicaciones.

  • Gestión del sistema remoto:
             - Troyanos: programas que se instalan en nuestra máquina y se ponen a la escucha por un puerto para que conecte el atacante.
             - Troyanos reversos: un troyano, pero donde la víctima es la que establece la conexión con el atacante.

  • Modificación del sistema:
             - Rootkit.
             - Spyware: recopilan información de una persona o una organización sin su consentimiento.

  • Captura de datos:
             - Spyware.
             - Keylogger: recuperan información de las pulsaciones realizadas sobre el teclado.

Os recomiendo encarecidamente que le echéis un vistazo al WebCast. Realmente merece la pena. Comenta por encima las herramientas Helix, KGB Spy y algunas de la suite de SysInternals, como Filemon y Regmon, y cómo se aplicarían en un caso práctico.

Asignar el Default Gateway en Linux

Como soy un poco torpe, y cada vez que quería configurar esta parte me iba a Internet a mirarlo, he querido poner aquí (en plan Memento), el comando que permite asignar el default gateway o puerta de enlace predeterminada, en un sistema Linux:

route add default gw 192.168.1.1

Sacado de howtonetworks.net, donde podéis echar un vistazo a los típicos comandos de red en Linux.

Saludos!

martes, 13 de marzo de 2012

RootedCON 2012 - día 3

Último día ya, con ganas de saber lo que nos vamos a encontrar. Allá vamos:

Jornada III: sábado 3 de marzo

José Pico y David Pérez. Nuevos escenarios de ataque con estación base falsa GSM/GPRS.


Bueno, creo que con la que han sembrado, poco más hay que decir de estos cracks (o científicos, como les calificó Román) de Taddong. Todo lo que nos explicaron viene con sumo detalle en su libro Hacking y seguridad en comunicaciones móviles GSM/GPRS/UMTS/LTE, y también los vi en la Gira Up To Secure de este año, donde cuentan todo lo que saben, pero muy resumido. Aquí, como hicieron también el año pasado, se meten a saco a demostrarnos de lo que están hablando. Esta vez ya parece que tienen una Jaula de Faraday más en condiciones.

En cuanto a mis notas, tampoco he cogido muchas, ya que todo lo expuesto está bastante documentado ya:

OpenBTS: para la estación base falsa.

Asterisk: software open source para proveer servicios de telefonía sobre IP.



Sebastián Guerrero. Pimp Your Android.


La charla de Sebastián me ha gustado mucho, entretenida y directa al grano. Además, el tema tratado aquí hay que tenerlo bastante en cuenta si vemos que los dispositivos móviles ya superan en número a nivel mundial a los sistemas de sobremesa. Principalmente, lo que hizo fue destripar el sistema Android mediante ciertas técnicas forenses, y tener en cuenta algunos consejos para que vuestras parejas, hermanos, amigos, etc. no sepan tanto de ustedes como sabe vuestro Android. Por cierto, dentro de poco va a liberar todo el material que usó en el Lab de Ingeniería Inversa en Android.

Notas:

fichero .apk: formato equivalente al .jar de JAVA, pero para Android.

A.R.E.: máquina virtual de Android Reverse Engineering, de www.honeynet.org.

www.android-x86.org: vamos a ejecutar Android en nuestro PC.

SQL-Viewer: para echar un ojo a todos nuestros datos que se almacenan en bbdd SQLite, y cómo no, sin cifrar.

Tapjacking: pulsar botones de una aplicación que crees legítima, cuando estás aceptando opciones de una "aplicación maliciosa" que corre por debajo.

/dev/mem y /dev/fmem.



Ricardo J. Rodríguez. Mejora en el Proceso de Desempacado usando técnicas DBI.


Ricardo explicó en su discurso cómo analizar el comportamiento de un binario en tiempo de ejecución, un poco acerca de cómo deofuscar código, y todo esto mediante Dynamic Binary Instrumentation (DBI). Me gustó que hiciera como una introducción, para los cafres como yo (puede que fuera el único) que todavía tenemos atravesado todo lo que es ensamblador, lenguaje a bajo nivel y todo eso. Mis notas tienen muchas cosas de la charla de Pablo San Emeterio, así que pongo lo más relevante:

Mark Zbikowski

packers: compresión de ejecutables.

OllyDbg: para analizar ficheros binarios.

OmniUnpack.

GNUPacker.

Armadillo Debugger.



Hugo Teso. Inguma 0.5 - Red Wagon.


Esta charla de Hugo se salía de lo convencional, y pudimos ver las posibilidades que existen de practicar hacking sobre estaciones aéreas, vehículos no tripulados, y cosas de ese tipo. Me gustó en líneas generales, pero reconozco que me costó seguirla, y que para mi gusto, se alargó un poco más de la cuenta. También tenía de qué hablar, pues primero presentó sus herramientas, Inguma y Bokken, y luego se metió a saco a explicar todo lo de los avioncitos, material militar, etc.

Notas:

UAV: Vehículo Áereo No Tripulado.

UAS: Unmanned Aircraft Systems.

ZigBee: nombre de la especificación de un conjunto de protocolos de alto nivel de comunicación inalámbrica para su utilización con radiodifusión digital de bajo consumo, basada en el estándar IEEE 802.15.4 de redes inalámbricas de área personal (wireless personal area network, WPAN).

MAVLink: Micro Air Vehicle Communication Protocol.

ACARS: Aircraft Communications Addressing and Reporting System.

RTOS: Real Time Operating System.



RootedForge 2012.

Esto era para ponentes que tenían ideas que exponer y darlas a conocer, para obtener participación, patrocinadores, financiación, ... y difundir sus proyectos a la comunidad. Como íbamos ya con retraso, y cada ponente iba a toda leche, por tener solo 3 minutos disponibles, pues ni se me pasó por la cabeza el sacar fotos ni coger notas. Esperaremos a los vídeos o a las diapositivas a ver. Eso no quita que no fueran iniciativas muy chulas.



Manu Quintans y Frank Ruiz. All Your Crimeware Are Belong To Us!


Estos chicos me parecieron muy cercanos. Se dedican a perseguir a los niños malos. Saben bastante acerca de cómo operan las mafias en Internet, cómo se organizan, sus pautas de conducta, etc. y de eso es a lo que vinieron a hablar. Hacían mucho hincapié en los rusos. Son muy buenos en su trabajo, y como anécdota, pusieron unas capturas de un pwned en toda regla del proxy de Chema y Manu. ¡Qué cracks!

Notas:

VPS: Servidor Virtual Privado. Esto venía a cuento de cómo las mafias adquirían y explotaban estos servidores.

Carberp: ejemplo de troyano empleado para sacar beneficios económicos.

Black Hole Exploits Kit: herramienta ya lista, con sus ventanas, módulos, panel de gestión, ... para lanzar los exploits cuando uno quiera, con un simple click. Se puede adquirir como si fueras al mercadillo a comprar, como quien dice.

Phoenix Exploits Kit: otro kit que podríamos coger y ... pa la saca.



Raúl Siles y José A. Guasch. Seguridad de aplicaciones web basadas en DNI-e.


Empezó Raúl, también de Taddong, hablándonos sobre todo lo del DNI-e, que España era pionera y líder en el uso de DNI-e, pero... fallábamos en la seguridad. Y en eso se centraba la charla. De una forma muy amena, y de manera que el público no se pudiera desenganchar de lo que iba diciendo, pudimos ver ejemplos de cómo saltarse la supuesta protección que nos brinda nuestro querido DNI-e (gracias cookies). Como reseña, decir que el DNI-e tiene dos certificados: uno para la autentificación, y otro para firmar. Luego José Antonio nos mostró lo que se es capaz de hacer si no hay ningún control en los ActiveX y Applets que se te vayan instalando en el equipo (que vengan firmados, no decirle a todo que SÍ, etc.). Muy buena charla para finalizar la Rooted, ¡sí señor!

Notas:

Man-in-Remote: creo que ésto es justo a lo que se refería Raúl: Man In Remote (or PKCS#11 redirection).

PKCS#11: Public-Key Cryptography Standards.

mAdministración: gestión de tareas administrativas on-line, pero a través de dispositivos móviles.

TLSSLed

OddJob: troyano bancario.

OWASP ZAP: Zed Attack Proxy.

STS: Strict Transport Security.

cve.mitre.org: Common Vulnerabilities and Exposures.

ChilKat: librerías de utilidades para distintos lenguajes de programación.

OWASP Session Management Cheat Sheet: consejos a la hora de manejar sesiones de usuario en aplicaciones web.



Premios RootedArena y Clausura.


Finalizamos la Rooted, con entrega de premios del RootedArena, desmadre total tirándonos pelotitas de goma y unas palabras de Nico Waisman, donde nos habló de la EkoParty.

Y un ejemplo del ambiente que hubo en todo momento en la Con:


¡¡Os espero a tod@s el año que viene!! ;)

lunes, 12 de marzo de 2012

RootedCON 2012 - día 2

Bien, comenzamos sin más preámbulo con las charlas del segundo día, notas, etc. Solo destacar que después de la experiencia del día 1, esta vez se organizaron mejor los descansos de la mañana con las Conchas Codan (creo que ya es emblema de la Rooted, casi que por méritos propios).

Jornada II: viernes 2 de marzo

Gerardo García Peña. Enfoque práctico a la denegación de servicio.


Gerardo, especialista en Seguridad de Deloitte, nos expone sus ideas acerca de qué es la Denegación de Servicio (DoS), qué aspectos hay que tener en cuenta a la hora de tratar con ella y nos muestra una especie de metodología para tener todos los aspectos cubiertos y no llevarnos sustos de última hora. Reconozco que esta charla me ha costado seguirla, no por dudar de los conocimientos técnicos del ponente, pero más por los temas tratados en sí y el detalle de los mismos. Vamos, que todavía me queda un largo trecho para alcanzar ese nivel. En cuanto a Gerardo, pues decir que está muy metido en lo suyo y que se ve que le gusta lo que hace. Al final, recomendó un chorro enorme de bibliografía, y de lo más variadito.

En cuanto a mis notas, pongo lo siguiente:

Herramientas de DoS: Chucuchu, LOIC, Dosis (basado en MGEN), Atackw y hping2.

Akamai: como una posible medida (a aplicar con muchas otras) para poder hacer frente a un DoS, o un DDoS.

ano.localhost.org: web con "el contenido gráfico más ofensivo y estúpido de la red".

Varnish: un acelerador web genérico.

Labrea Tarpit: "Sticky" Honeypot e IDS. Otra posible medida preventiva, donde podrías estudiar los patrones de ataque, y así tomar contramedidas.



Lorenzo Martínez. Welcome to your secure /home, $user.


Lorenzo, otro clásico de SecurityByDefault. Este es ¡¡el hombre que susurra a las máquinas!! Su charla va de domótica pero en plan DIY, y ya tiene varios artículos publicados de cómo tunea los accesorios que tiene en el hogar. Vamos, ya tiene montado hasta Skynet... solo falta encontrar a John O'Connor :P Y todito con Perl (con dos cojones también, por supuesto).

Notas:

Dongle Bluetooth: "pinchos" que proporcionan conectividad por dicho protocolo.

face.com: API para crearte tus aplicaciones de reconocimiento facial.

OpenCV: biblioteca libre de visión artificial, empleada en este caso para videovigilancia y reconocimiento facial también.

Loquendo: permite interacción con dispositivos mediante la voz.


Bueno, con todas esas herramientas, y aplicadas al hogar, ya os podéis imaginar lo que tiene montado, ¿no?



Carlos Díaz y Francisco Jesús Gómez. CMD: Look who's talking too.


Lo que demuestran aquí estos chicos de Telefónica I + D, es cómo emplear DNS para llevar a cabo una fuga de información o un método de infección mediante la transferencia, en cachos, de algún código malicioso que pueda ir infectando a todos los clientes que realicen sus consultas DNS. Todo esto a modo de resumen resumido ;) También lo tienen muy bien documentado como un draft de la IETF.

Notas:

Open Resolver: admitir y resolver correctamente preguntas recursivas para clientes fuera de su dominio administrativo.

Open emitter: open resolver que emplea la misma IP tanto para atender a los clientes como para consultar los servidores de nombre autoritativos.

DNS as covert channel: emplear tráfico DNS para transmitir datos que no quieres que sean detectados.

Feedorbot: comparte comandos cifrados en Base64 desde un C&C. Encapsula datos en registros TXT y codificados en Base64.

Hiloti

Morto: gusano que emplea registros TXT para comunicarse.

Wombat: Worldwide Observatory of Malicious Behaviors and Attack Threats.

iseclab EXPOSURE: Exposing Malicious Domains.

dnsdb.isc.org: base de datos de información de Nombres de Dominio que puede ser utilizada para un análisis exhaustivo en "modo offline" para detección de malware, actividades ilegales, etc.

Webboar: información de dominio.

dnscapy: herramienta para creación de un túnel SSH con paquetes DNS.

OZynameDNS: desarrollado por Dan Kaminsky para ejecutar un túnel DNS.

iodine de Kryo: envío de tráfico IPv4 sobre DNS. Por ejemplo, para saltarse los firewalls.

NXDOMAIN: Non-existent Internet Domain Names.



Jaime Peñalba. Live Free or Die Hacking.


Esta charla/presentación/como quieras llamarlo ha sido una de mis favoritas del día. Aparte de su alto contenido técnico y de ver ejemplos "en vivo" (al final eran vídeos grabados), Jaime (@NighterMan) nos ha mostrado a todos lo que normalmente solemos ver en pelis de ciencia-ficción, y nada de hacking con MacOSX, como Lizbeth Salander, sino realmente en plan underground total. Mientras veíamos el vídeo, iba explicando todo lo que iba aconteciendo, todo con ventana de comandos puro y duro. Básicamente, mostró cómo conseguía hacerse una conexión anónima en plan Tor, pero utilizando estaciones GPS, aparatos de vídeo, impresoras (con PJL), ... todo lo que sea susceptible de conectar a la red. Una vez conseguido esto, procedía a lanzar el rootkit lsnake. Otras herramientas suyas son Hookle y ashell, si no me equivoco.

Por el otro lado estaba Javier (@Javiover), miembro de la Unidad de Delitos Telemáticos de la Guardia Civil, el cual explicaba qué pautas suelen seguir y en qué patrones se suelen fijar para coger a los cibercriminales de los "auténticos", los que saben lo que están haciendo vaya, además de que ellos mismos tienen que ser hackers (NO confundir con crackers) para pensar como los delincuentes.

Vamos, ¡de película!



Eloi Sanfélix y Javier Moreno. Hardware hacking on your couch.


Estos cracks nos mostraron cómo también podemos hacer hacking con hardware, pasar un buen rato, y de forma barata (50€ - 60€). La pena fue que no hubo tiempo para poder ver las demos que traían, en su totalidad. Mencionaron como referencia dontstuffbeansupyournose.com, donde podremos ver algo similar a lo que presentaron Eloi y Javier. En cuanto a mis notas:

i2c: mencionaron este bus como ejemplo del hacking de las baterías de los MacBook por Charlie Miller.

JTAG: Joint Test Action Group. Creo que una de sus demos era ver cómo usaban el JTAG.

Bus Pirate

Open Bench Logic Sniffer

OpenOCD



Pablo San Emeterio. WHF - Windows Hooking Framework.

Lo siento Pablo, se me pasó la foto. Ya cuando me di cuenta, había terminado la charla y la parte de las preguntas y todo. Bueno, eso no quita que el tema fuese de lo más interesante, y para mí, todo esto del Hooking era algo de lo que solamente había leído hasta ahora. Simplemente consiste en interceptar las llamadas a las librerías, ejecutables, etc., meter lo que tú quieres hacer (tu código) y dejar que siga con la ejecución. La herramienta era una GUI de lo más cómoda para llevar a cabo el Hooking en Windows. Eso sí, todavía le quedaban cosas por pulir.

Notas:

Optenet: empresa de seguridad que ofrece SaaS.

Spy++: Spy++ (SPYXX.EXE) es una utilidad basada en Win32 que proporciona una vista gráfica de los procesos del sistema, así como los correspondientes subprocesos, ventanas y mensajes de ventana.

Espacio de usuario

PEB: Process Environment Block.

IAT: Import Address Table.

Espacio de kernel

SSDT: System Service Descriptor Table.

IDT: Interrupt Descriptor Table.


formato PE: Portable Executable, formato de ejecutables, librerías y objetos de entornos Windows de 32-bit y 64-bit.



Chema Alonso y Manu "The Sur". Owning "bad" guys {and mafia} with Javascript botnets.


Supongo que esta charla era una de las más esperadas del día. ¿Quién no conoce ya al Maligno? Aquí, Chema y Manu explicaban cómo crearse una botnet comprometiendo a los usuarios mediante Javascript y tratando de que piquen con un proxy de estos de navegación anónima y tal.

Ya he visto que Chema ha puesto una explicación muy detallada de esta charla en su blog, así que ¡aprovechad para echarle un ojo!

Como notas, pues pongo únicamente lo siguiente:

BeEF: The Browser Exploitation Framework Project.

La IP del SQUID Proxy que emplearon era 85.25.108.154.



RootedPanel. Comunidad de Seguridad.


Finalmente, la mesa redonda de la jornada. Lo que se trató fue hablar un poco acerca de los eventos de seguridad informática a nivel nacional, y concretamente se habló de la NoConName. Los miembros del panel fueron Román, y los fundadores de la NcN Nico Castellano, Héctor Pantoja y Hugo H. Castellano.


El listón estaba muy alto para el día 3!!