31 marzo 2009

Los caminos del buscador de Google son inescrutables, y si no, que se lo pregunten a más de 19.000 británicos consumidores de servicios de comercio electrónico, que pudieron observar asombrados como los datos al completo de sus tarjetas de crédito aparecían como resultados de este gigante tan referenciado por aquí.

Lo más ¿gracioso? de todo es que dichos datos no quedaban disponibles a causa de un fallo en el servicio de shopping online, mediante querys imposibles con el buscador y demás, si no que era información que había sido previamente obtenida por un grupo de cibercriminales, y posteriormente subida a internet para poder ser vendida a otros delincuentes en la India.

El servidor, alojado en Vietnam, ya había sido cerrado, pero la caché de Google que sabemos que funciona a la perfección para según que servicios, conservaba una copia, fácilmente indexable, buscable, crawleable...

Según Google, los datos han sido retirados, y según la asociación británica APACS, las tarjetas de crédito canceladas, pero...¿nos quedamos conformes?

[+] Google search reveals 19,000 credit card details (InfoWorld)
Leer más...

30 marzo 2009

Semana interesante de eventos

Esta semana (si vives en Madrid) se acumulan un montón de eventos interesantes a los que merece la pena acudir.

Empezamos por el evento organizado por el Instituto Empresa sobre Seguridad y Web 2.0 para el día 31 de Marzo, la inscripción es gratuita y entre otros ponentes acuden:
Pablo Pérez San-José (Gerente del Observatorio de la Seguridad de la Información, INTECO),
Juan Ignacio Martinez (Director de desarrollo de las ieCommunities)
Jesús Rubí (Adjunto al Director, Agencia de Protección de datos).

También el día 31, se realiza el 'Foro tecnológico soluciones' en el Siti/aslan, donde hay una charla sobre seguridad: 'Evolución y requisitos en la seguridad de la red inalámbrica' a las 16:30 (como las del IE son por la mañana, es perfectamente posible acudir a las dos)

Para el día 1, también en el siti/aslan tenemos el 'Foro tecnológico tendencias' donde podemos encontrar la charla 'Seguridad, conectividad y movilidad con servicios Wimax' a las 11:30. Y antes de esa charla, a las 10:20 en el foro 'Storage' (también en el siti/aslan) da una conferencia Lorenzo Martinez (editor del blog) titulada 'Seguridad en Aplicaciones Web : 10 años de experiencia', pero en esta ocasión no va con la chapa de SbD, sino con la de su empresa. No obstante, me ha prometido que a todo aquel que le diga 'anda, tu eres el de SbD' y cite el titulo de 3 de sus posts, le invitara a una cerveza.

Finalmente, el día 2 tenemos una charla que no es estrictamente de seguridad, pero que es sumamente interesante. Diego Parilla (editor de Nubeblog) ha organizado un workshop conjunto con Amazon y SUN sobre cloud computing.

Huelga decir que todos los eventos son de entrada libre
Leer más...

SbD pide donaciones

Parece que últimamente se ha puesto de moda pedir donaciones, y como nosotros no queremos perder esta ola de generosidad que se ha creado, también vamos a pedir.

Como casi todo el mundo pide donaciones en forma de dinero, suponemos que a estas alturas el presupuesto de la gente se habrá agotado así que vamos a pedir algo diferente; queremos los logs de vuestros firewalls ! si, no es una broma, los queremos, pero no para nosotros sino para la organización Dshield

Dshield es una organización sin animo de lucro que se dedica a analizar el trafico en Internet en busca de incidencias, en su web categorizan las amenazas clasificandolas por puertos TCP-UDP, de forma que puedes saber casi casi en tiempo real que puertos 'calientes' estan siendo utilizados de forma irregular.

Para conseguir esto, se nutren de las donaciones que la gente envía en forma de logs. La gente de Dshield ha desarrollado agentes para recolectar logs de, virtualmente, casi cualquier firewall / IDS del mercado.

Si usas Windows debes buscar tu agente aquí

Si usas Linux/Unix, aquí

Además como valor añadido a la contribución, la gente de Dshield tiene un programa de defensa por el cual, si detectan actividad sospechosa contra tu host, se ponen en contacto directamente con el ISP origen del ataque e intentan mitigar el problema.

Colaborar con Dshield es una buena forma de combatir botnets y demás amenazas que acechan Internet.
Leer más...

28 marzo 2009

How to 'hacer las cosas mal' by @rroba

Vaya por delante que, personalmente, le tengo especial cariño a la revista @rroba por su trayectoria, por el hecho de que muchos amigos mios han publicado ahí y porque estar al pie del cañón tantos años, tiene mucho, mucho merito.

Dicho lo cual voy a comentar algo en lo que no han estado excesivamente a la altura. En el numero 139 hay un artículo en el que hablan sobre certificados digitales en su 'curso de hacking'.

El articulo, básicamente, es una versión de mi primer post de este blog en el que hablaba de la FNMT. La orientación que le dan en @rroba es mucho mas pragmática y lo complementan con una pequeña guia para asegurar los certificados.

Hasta aquí, todo bien, un magnifico trabajo derivado del original, a nosotros nos encanta ser de utilidad y sobre todo que vosotros encontréis útiles las cosas que publicamos, nunca hemos objetado a nadie que versione o duplique nuestro contenido. El problema es que @rroba, lejos de 'otorgar el crédito' de la técnica que comentan en su articulo, lo que hacen es mencionar únicamente el programa que publiqué junto con el post, sin siquiera una referencia a la URL original del programa, algo básico, y mucho menos citando al blog, que es el origen del tema.

A mi, con haber puesto las debidas referencias me habría bastado, incluso si hubieran tenido la cortesía de haberme puesto un mail, hubiera estado encantado de escribir un post al respecto
Leer más...

27 marzo 2009

IT Security Girl of the Year

Se ha generado cierta polémica alrededor de la primera edición de la conferencia de seguridad de TI, FRHACK, la cual tendrá lugar a principios del mes de septiembre en Besançon, Francia.

En la sección Eventos se podía ver esta imagen, que anunciaba la entrega de un premio llamado "IT Security Girl of the Year".

Utilizar una mujer en ropa interior llevando una pistola para anunciar un premio que en teoría debería tener un enfoque tecnológico, resulta bastante machista y de muy mal gusto.

Además la imagen del evento por si sola lo dice todo, de "investigadora" tiene poco por mucho logo firefox que le hayan puesto.

El premio iba a ser otorgado a Joanna Rutkowska, una reconocida investigadora en el campo del malware silencioso, oradora frecuente en conferencias de seguridad de todo el mundo. La cual fundó en 2007 un laboratorio que da servicios de consultoría de seguridad y cuyo trabajo se centra en SO y sistemas de seguridad virtualizados. No se ella, pero yo rechazaría un premio de estos individuos.

Debido al gran número de críticas por el carácter machista del premio, han modificado el site cancelando y retirando toda la información del evento.

Por si esto no fuera poco, los organizadores del FRHACK amenazaron con emprender acciones legales contra un blog que publicó una captura de pantalla de su página web. Concretamente la denuncia fue que una de las fotos (el que tiene la mujer y el arma) está protegida por derechos de autor. Resulta que los organizadores ni siquiera poseían los derechos de autor de esa foto.

El autor del blog se puso en contacto con el hombre que posee los derechos de autor (Jason Snell) y él le concedió el permiso para mantener la captura de pantalla y además declaró que "Yo, y muchos de mis colegas investigadores en seguridad, estamos acuerdo con su punto de vista. Me puse en contacto con el grupo francés de inmediato porque me impresionó por su mal gusto el uso de mi trabajo."

Aunque el mundo de TI ha sido siempre mayoritariamente masculino, siempre ha estado presente la presencia femenina, aunque en cierta forma algo cohibida. En los tiempos que corren todo esto está cambiando y cada vez se ven mujeres de TI realizando grandes labores de investigación y gestionando proyectos.

Esperamos no tener que volver a ver actitudes machistas como esta.
Leer más...

26 marzo 2009

Ya esta aquí la BlackHat Europe 2009

Blackhat Europa está a la vuelta de la esquina, ya estamos a menos de un mes para el 16 y 17 de abril. Otro año más se celebra en Amsterdam, por alguna extraña razón que desconocemos, este sitio es uno de los preferidos para una de las conferencias más importantes de seguridad. Aunque algo nos hace pensar que pronto cambien de localización.

Bromas aparte, con agenda publicada a menos de un mes, somos muchos los que ya estamos organizando el viaje para vernos allí.

Parece imposible hacer un resumen de todo lo que se presentará, así que copio todas y marco en negrita las que a mi personalmente más interés me despiertan.

  1. Stripping SSL To Defeat HTTPS In Practice - Moxie Marlinspike
  2. Fun and Games Using In-Memory Execution on Mac OS X - Charlie Miller, Vincenzo Iozzo
  3. Advanced SQL Injection exploitation to Operating System Full Control - Bernardo Damele Assumpcao Guimaraes
  4. Cutting Through the Hype: An Analysis of Application Testing Methodologies - Jon Miller, Neel Mehta, Alex Wheeler, David Bonvillian
  5. Cutting Through the Hype: An Analysis of Application Testing Methodologies part 2 - Jon Miller, Neel Mehta, Alex Wheeler, David Bonvillian
  6. Alice in User-Land: Hijacking the Linux Kernel via /dev/mem Anthony Lineberry
  7. SAP Penetration Testing - Mariano Nunez Di Croce
  8. A Cloud Security Ghost Security - Craig Balding
  9. All Your Packets Are Belong to Us - Attacking Backbone Technologies - Enno Rey, Daniel Mende
  10. VAASeline: VNC Attack Automation - Rich Smith
  11. Taming the Beast : Assess Kerberos-Protected Networks - Emmanuel Bouillon
  12. Integrating Maltego with Offensive and Defensive Open Source Tools Roelof Temmingh and Chris Bohme
  13. Hijacking Mobile Data Connections - Roberto Gassira', Roberto Piccirillo
  14. Passports Reloaded Goes Mobile - Jeroen van Beek
  15. Yes It Is Too WiFi, and No It's Not Inherently Secure - Rob Havelt
  16. Tactical Fingerprinting Using Metadata, Hidden Info and Lost Data - Chema Alonso, Enrique Rando
  17. Detecting "Certified Pre-owned" Software and Devices Chris Wysopal
  18. Masibty: A Web Application Firewall Based on Anomaly Detection - Stefano Zanero
  19. .NET Framework Rootkits: Backdoors inside your Framework - Erez Metula
  20. Stack Smashing as of Today: A State-of-the-art Overview on Buffer Overflow Protections on linux_x86_64 - Hagen Fritsch
  21. WiShMaster - WIndows SHellcode MASTERy- Benjamin Caillat
  22. Shuntaint: Emulation-based Security Testing for Formal Verification - Bruno Luiz
  23. OpenOffice Security Design Weaknesses - Part 1 Eric Filiol
  24. OpenOffice Security Design Weaknesses - Part 2 Eric Filiol
Leer más...

Problemas de autenticación para Kevin Mitnick

El archipopularmente conocido hacker... perdón, "profesional de la seguridad" de los 80 y 90, Kevin Mitnick, ha declarado haber tenido problemas para probar su autenticación en Facebook.

Paradójicamente, Kevin, es conocido precisamente por sus excelentes habilidades para robar la identidad de otras personas, convenciendo a la gente mediante ingeniería social, para conseguir información confidencial, contraseñas, acceso a lugares restrigidos, etc,.... Sin embargo en la, también popular, red social Facebook, fue incapaz de acceder a su propia cuenta durante semanas. El motivo: Los administradores de la propia red social no creyeron que era quien decía ser.

Después de llevar 2 años utilizando Facebook, el 22 de Febrero de 2009, le resulta imposible acceder a su perfil. Envió un correo preguntando qué sucedía y la respuesta es que había violado los términos de utilización por registrarse con un nombre falso. Se le ocurrió enviar un correo desde su cuenta de su empresa Mitnick Security Consulting para probar que era él de verdad. Los administradores respondieron que sólo aceptaban correos electrónicos de la cuenta que él tenía registrada en Facebook y que había sido borrada junto al perfil que creían falso, por lo que no les valía.

Finalmente el problema fue solucionado. La gente de Facebook insiste en que es tanto el afán de que los miembros de Facebook no falseen su identidad, que a veces se cometen errores como este.

Según palabras del propio Mitnick: "Me resulta muy frustrante, puesto que yo solía ser muy influyente a la hora de simular ser otras personas, y ahora ni siquiera soy capaz de probar que soy el verdadero Kevin Mitnick en realidad"

La noticia original en cnet la podéis leer aquí
Leer más...

25 marzo 2009

Publicada la agenda del V OWASP Spain Chapter Meeting

El viernes 15 de Mayo, en Barcelona, se celebrará la quinta edición del congreso OWASP Spain Chapter Meeting. Y hace unos días, se publicó lo que será la agenda del día, describiendo las conferencias y horarios.

El lugar elegido para el conjunto de conferencias es el Ateneu Barcelonès, un emplazamiento mucho más amplio que el utilizado en anteriores ocasiones.

Como resumen, el congreso contará con la siguiente programación, comenzando el registro a las 15.00h y finalizando alrededor de las 20.30h:

-----o-----
15:30h - 15:35h - Bienvenida y presentación (Vicente Aguilera)
15:35h - 16:30h - Sintonizar la función de seguridad con el negocio (Alberto Partida)
16:30h - 17:25h - LDAP Injection & Blind LDAP Injection (Chema Alonso)
17:25h - 18:00h - Coffee Break
18:00h - 18:55h - Gestión de Incidentes de Seguridad Web en la BIT (Jorge Martín)
18:55h - 19:50h - Extensión de módulos de pruebas de seguridad de OWASP Webgoat (Daniel Cabezas y Daniel Muñiz)
19:50h - 20:25h - Mesa redonda (Ponentes + Invitados)
20:25h - 20:30h - Despedida y cierre del evento

-----o-----


El evento es gratuíto y muy recomendable, y la pre-inscripción la podréis realizar enviando un correo a vicente.aguilera@owasp.org con el asunto INSCRIPCIÓN.

¡No dudéis en dejarnos cualquier comentario en caso de que asistáis!

[+] Agenda del V OWASP Spain Chapter Meeting
Leer más...

Análisis de Adobe Flash

Uno de los controles que la metodología OWASP contempla es el análisis de archivos web Adobe Flash (.swf). que en numerosas ocasiones presentan vulnerabilidades explotables o información sensible vital para que la revisión sea completa.

Para analizar la seguridad de estos archivos compilados, primero se utilizan herramientas de decompilación, como por ejemplo SWF Decompiler (comercial) o Flare (gratuita), que muestran los objetos y código (en ActionScript) y posteriormente se analiza en busca de vulnerabilidades. Al igual que se haría para un applet en Java o un ActiveX.

No existen muchas aplicaciones que ayuden a esta revisión de código, como erlswf, y permita semi-automatizarla, como ocurre para otros lenguajes. Por este motivo HP, que tras la compra de SpiDynamics en 2007 ha demostrando su interés por la seguridad web, ha liberado SWFScan, una herramienta que facilita esta labor. Su formato es similar a Scrawl, otra pequeña utilidad de HP para la detección de SQL Injections.

En las pruebas que hemos realizado ha funcionado de una forma más que aceptable, ya que además de los análisis de seguridad de código fuente, realiza la decompilación previa.

Entre sus características principales está la posibilidad de seleccionar entre más de 60 pruebas a realizar, comprobar las buenas prácticas de Adobe y decompilar ActionScript en su versión 2 y 3.

Otras características contemplan:
  • Señalización del código vulnerable
  • Reporte de vulnerabilidades con explicación y recomendación
  • Generación de un informe en HTML (un poco pobre, todo sea dicho de paso)
  • Exportación del código fuente
  • Identificación de todas las URLs
  • Señalización de funciones que puedan ser críticas, como crypt() o loadedUserXml
Este software nos hace pensar que es posible que el motor de la herramienta o una versión mejorada se incluya en su aplicación de análisis web WebInspect y esta, está muy lejos de ser gratuita.

La siguiente captura muestra un análisis sobre un archivo que almacena en el propio código fuente los usuarios y contraseñas (risas).


La configuración de las distintas pruebas que permite analizar:


Más información:
http://www.adobe.com/devnet/flashplayer/articles/swfscan.html
http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/03/20/exposing-flash-application-vulnerabilities-with-swfscan.aspx
Leer más...

24 marzo 2009

El futuro firewall de Linux.

Como ya ocurrió con los antiguos ipfwadm e ipchains, ahora le toca a iptables. El actual firewall de Linux tiene los días contados. El grupo encargado de Netfilter ha publicado una versión preliminar del sucesor: nftables.

Este nuevo cortafuegos se ha desarrollado desde cero, sufre numerosos e importantes cambios. Como principal mejoría la posibilidad de añadir en una sola entrada varias acciones para un a misma regla.

nftables está compuesto por tres componentes: la implementación del kernel, la librería de comunicación (libnl) y el frontend para usuario.

La sintaxis de configuración cambia por completo, eliminando complejidad y siendo más flexible.

Algunos ejemplos de esta nueva sintaxis:

# nft add rule output tcp dport 22 log accept

# nft add rule inet filter output tcp dport 22 log accept


Leer más...

Mentalismo 2.0 (la solución)

En el post anterior presentábamos, a modo de broma, un problema que en muchos casos es desconocido y que tiene implicaciones bastante mas serias de las que parece.

Para empezar, el 'truco' que usábamos en nuestra Maquina Zoltar es un fallo que viene de antiguo (2006-2007) con respecto al uso de hojas de estilo CSS, que permite interrogar a un navegador por las webs donde ha estado previamente.

El fallo fue inicialmente reportado por Jeremiah Grossman que hacía uso de Javascript para interrogar al navegador por los sitios web visitados, posteriormente (malas noticias para los amigos de NoScript), la gente de ha.ckers.org perfeccionó el ataque sin necesidad de hacer uso de Javascript (en este último trabajo es en el que se basa nuestra maquina Zoltar).

El ataque supone una merma considerable de la privacidad ya que, si bien no se puede obtener el historial de navegación integro, si que se puede averiguar 'preguntándole' al navegador web.

¿Que supone esto? bueno, pongamos escenarios: tu puedes ir, por ejemplo, a la web de www.empresa.com con idea de entregar tu CV en su sección de RRHH y ellos, mientras introduces tu CV, averiguar si eres asiduo de webs eróticas, deportivas o de la competencia.
Imaginemos una intranet en la que los empleados realizan tramites administrativos, una empresa podría averiguar si ese trabajador se ha conectado, por ejemplo, a infojobs.

Ni que decir tiene del valor que puede tener para una compañía que venda sus productos online poder saber si tu eres usuario de la competencia, incluso para ofrecerte descuentos especiales

Pero el tema es realmente mas peligroso, cuando tu buscas algo en google, google formatea las URLs de una forma conocida (por ejemplo: http://www.google.com/search?hl=es&q=securitybydefault&btnG=Buscar+con+Google&lr=) y sabiendo esto, se puede averiguar si, por ejemplo, tu has preguntado a google por 'pornografia infantil' o 'matar a mi jefe'.

¿Inquietante, verdad? Las soluciones, aparte de tener activado en tu navegador el borrado del historial de navegación en cada sesión, poco mas se puede hacer. En firefox hay dos extensiones orientadas al tema, pero ambas están desactualizadas y no funcionan en Firefox 3.x: SafeHistory SafeCache

anieto2k referenció hace tiempo una peculiar forma de explotar este bug.
Leer más...

23 marzo 2009

Mentalismo 2.0

Hay que asumirlo, la crisis esta haciendo que mucha gente se tenga que re-inventar para seguir subsistiendo. Yo mismo, cada día veo llegar a la empresa donde trabajo jovencitos imberbes que ya dominan Python, C, ensamblador y contribuyen activamente en Metasploit, con ganas de arrasar y que miran codiciosamente mis privilegios ganados con años de trabajo (portátil último modelo, horario de entrada flexible, compadreo con el staf ...)

Así que después de sopesar profesiones alternativas, me ha llamado la atención el mentalismo. Nuestros compañeros de S21sec ya hicieron un brillante ejercicio de mentalismo hace tiempo, así que tras recluirme todo el fin de semana para buscar y re-leer esas fabulosas guías que publicó el mito erótico de los 90 y mago Juan Tamariz, he construido una pequeña 'ciber Maquina Zoltar' (como la que aparecía en la película Big) con dotes adivinatorias.

¿Y que hace nuestra maquina Zoltar? bueno, digamos que es capaz de averiguar y registrar los sitios web que has visitado en tu navegador. ¿No te lo crees? Vale pues pongamosla a prueba.

Tomemos, por ejemplo, como referencia los siguientes sitios web lideres en su segmento:

www.as.com
www.marca.com
www.elpais.com
www.elmundo.es
www.meneame.net
www.barrapunto.com
www.microsiervos.com
www.enriquedans.com
www.hazteoir.org

Nuestra maquina Zoltar es capaz de averiguar si has navegado por alguno de esos sitios web y además, para despejar dudas de que no se trata de un 'efecto óptico', guardará en un fichero almacenado en mi servidor los datos obtenidos (Si estás tras un proxy, como los datos van asociados a la IP publica, tal vez se mezclen).

Tan solo has de ir aquí y comprobarlo por tus propios ojos.

Nota: Como por aquí nos visita gente muy habilidosa, he deshabilitado los comentarios del post para que nadie chafe el truco. Mañana, publicaremos la solución
Leer más...

21 marzo 2009

Haciendo el Ciber Houdini

Harry Houdini fue un famoso mago que se granjeo fama a base de realizar actuaciones en las que, el plato fuerte, eran los trucos de escapismo por el cual el simpático mago conseguía zafarse de tanques de agua, gruesas cadenas y toda suerte de esposas y candados que pretendían retenerle.

En muchas ocasiones, por diversas circunstancias, el entorno en el que estamos conectados tiene el acceso al exterior restringido mediante un Proxy http, a priori, este Proxy restringe el uso de ciertos protocolos y en otros casos nos obliga a usar versiones web de esos protocolos (por ejemplo, mensajería instantánea). Adicionalmente, es posible que el Proxy tenga restricciones sobre el tipo de paginas web “aceptables”, por no hablar de la falta de privacidad que supone navegar teniendo la certeza de que toda nuestra navegación se esta registrando con todo lujo de detalles.

Desde SBD vamos a proponer un sistema para poder “escapar” de todo lo expuesto anteriormente y conseguir acceso ilimitado con privacidad adicional.
Para ello necesitamos unos cuantos requerimientos tanto en el entorno como en las herramientas. Para poder poner en practica esta técnica necesitamos:

  • Una maquina con conexión permanente a Internet (vale un ADSL)
  • Que esa maquina sea unívocamente localizable (ya sea mediante una IP fija o una dirección IP dinámica accesible a través de un nombre DNS fijo conseguido a través de DynDNS
  • Un host que ejecute alguna versión de Linux o *BSD accesible a través de la dirección anterior con el puerto 443 disponible

Una vez tengamos esos requisitos, procedemos a instalar el software necesario para poder “saltar”.
En la maquina Linux / *BSD necesitamos instalar un servidor OpenSSH (sería extraño que no formara parte del software base) y un software de tipo Proxy-Socks llamado Nylon . Este software debería compilar correctamente en cualquier sistema Unix.
Todo eso es para la parte “servidor”, en la parte cliente (basada en windows) únicamente necesitamos tener disponible el software Putty

Configuración Servidor

Asumiendo que ya tenemos instalado el servidor OpenSSH y Nylon, vamos a configurar primero el servidor OpenSSH para que escuche en el puerto 443. El motivo de hacer esto es porque para realizar una conexión “limpia” a través de un Proxy http solo se puede realizar empleando el método CONNECT y la mayoría de los proxys tienen restringida esa funcionalidad para que se realice contra puertos 443.

Editamos /etc/ssh/sshd_config y añadimos Port 443 para que escuche también en ese puerto, re-iniciamos el servicio y comprobamos que al ejecutar telnet localhost 443 aparece el banner de OpenSSH

$ telnet localhost 443
Trying 127.0.0.1...
Connected to localhost
Escape character is '^]'.
SSH-2.0-OpenSSH_4.3

El siguiente paso es configurar el Proxy Nylon que será el que nos permita hacer uso de cualquier aplicación que implemente conectividad a proxys socks (MSN Messenger, firefox, Explorer …)
La forma de configurar el Proxy es ejecutarlo de la siguiente forma:

/usr/local/bin/nylon -s -a 127.0.0.1 -i lo

Ejecutándolo de esta forma, el proxy únicamente es accesible en la dirección local (no podría usarse directamente desde Internet, evitando que algún amigo-de-lo-ajeno lo empleé para hacer el mal) Lo interesante es que añadas a tu rc.local (si usas Redhat/Fedora/Centos) o /etc/init.d/bootmisc.sh (Si usas un sistema basado en Debian) la ejecución de Nylon para hacer que, en futuros re-inicios, el proxy esté disponible.
El ultimo paso que hay que hacer es crear una cuenta en el sistema para conectarnos, valdría cualquier cuenta con login habilitado pero por motivos de higiene es recomendable crear una cuenta nueva, por ejemplo, salto:
#adduser salto
#passwd salto
Con esto quedaría configurado nuestro servidor de salto, ahora veamos la configuración de la parte cliente basada en Putty.

Configuración cliente

Primero de todo debemos crear una nueva sesión en putty a la que llamaremos “salto” y en ella configuramos la maquina donde tenemos ejecutando OpenSSH y Nylon


El siguiente paso es configurar el proxy interno HTTP del lugar en el que nos encontremos, tenemos que especificar el host, el puerto, nuestro usuario y contraseña


El siguiente punto es crear el túnel inverso por SSH para poder acceder a Nylon, para ello configuramos Putty de la siguiente forma:



pulsamos “add” y la configuración queda de la siguiente forma:


Una vez realizada la configuración, la salvamos


El último paso es pulsar “Open” y acceder a nuestra maquina de salto, si todo funciona como es debido, en nuestra maquina cliente tendremos abierto el puerto 1080 que a su vez estará conectado con el puerto 1080 (donde escucha Nylon) de nuestra maquina de salto. Lo ultimo que nos queda es re-configurar nuestras aplicaciones para que usen un proxy socks en la dirección 127.0.0.1 puerto 1080


Feliz navegación !
Leer más...

20 marzo 2009

Malware afecta a cajeros automáticos

Una de 'crimen organizado' para empezar el fin de semana, por lo visto DieBold, empresa fabricante de Cajeros Automáticos basados en software Windows que, entre sus clientes se encuentran (cito textualmente de una nota de prensa) :
Caja Madrid, BBVA, Banco Santander, Caixa Penedés, CAM, Caixa Galicia y Caixa Nova
ha sido victima de un sabotaje en sus sistemas mediante la introducción de Malware para capturar datos bancarios. Según se puede leer en la noticia original, la gente de Sophos ha detectado un troyano (llamado Troj/Skimmer-A) en los sistemas Windows que suministra este fabricante.

No queda ni de lejos claro como ha podido llegar ese troyano a los equipos, pero todo parece apuntar a un ataque desde dentro

La 'buena noticia' es que el troyano ha sido programado únicamente para capturar transacciones Rusas, Ukranianas y de EEUU.

Mas información en el post de Dancho Danchev, y en el blog de Sophos
Leer más...

19 marzo 2009

Edge-Security Golpea duro.

Edge-Security, equipo formado por especialistas de seguridad ha liberado nueva versión de su herramienta de análisis web ProxyStrike.

Esta aplicación actualiza a la versión 2.1, permite interceptar conexiones web y alterarlas, tal y como hacen otras herramientas como burp proxy, paros, webscarab, etcétera. Entre las principales características destaca la posibilidad de utilizar complementos que permiten la detección de vulnerabilidades SQL Injection, XSS, SSI o desarrollarnos los nuestros propios.

Una de las grandes ventajas es que está programada en python y en comparación a otras herramientas Java es mucho más rápida.

Una de sus grandes desventajas, es que está programada en python y su instalación en Windows puede ser complicada (por los módulos), sobre todo comparado a los típicos: "Siguiente, siguiente, reiniciar". Actualización: Como comenta el autor, existe un paquete sencillo para su uso en entornos Windows. ¡Ya no hay defectos!

En la web se puede ver un vídeo comentado, con musiquilla y todo, donde hacen un repaso de sus funcionalidades.

Leer más...

18 marzo 2009

La curiosidad mató a Comcast

En la sección de negocio, innovación, tecnología y sociedad del blog del New York Times se hacen eco de una noticia en la que se dan lugar ciertos hechos que hemos comentado varias veces en Security By Default.
En primer lugar, un nombre importante, digamos por ejemplo Comcast, la compañía lider en telecomunicaciones de EE.UU, que proporciona televisión e internet a un gran número de estadounidenses. No perdáis este nombre, que después le añadiremos verbo y complementos.
En segundo lugar, nos da la curiosidad después de leer un artículo que trata el tema de nuestra confidencialidad, o ausencia de ella mejor dicho, y queremos saber lo que el resto del mundo podría saber de nosotros. Utilicemos, en tercer lugar, un servicio de internet, relacionado con identidades, con el que dado un nombre y apellidos obtenemos ocurrencias en múltiples sitios. Por ejemplo, pipl. Seguidamente, nos damos cuenta que aparecemos en varios lugares, entre ellos, el youtube de los documentos, como lo definían en genbeta hace un par de años, Scribd. La cosa no acaba ahí, no es que aparezcan sólo nuestros nombres y apellidos...el problema es que también aparece nuestra contraseña, que para más inri, es la que usamos para todo. Esta información no venía sola: con ella, un listado de 7999 lineas más de ese mismo estilo, pero con otras personas. Era un listado de 8.000 nombres de usuarios y contraseñas de Comcast.
Esto es lo que se encontró un profesor de universidad especialista en tecnología (que no en contraseñas por lo que parece...), en el que raudo y veloz se dispuso a notificar este hecho a Comcast, al F.B.I. y a Scribd, que rápidamente eliminó el documento, que había sido visto ya por más de 340 personas y descargado por otras 27.
¿Intrusión en Comcast? Poco probable. ¿Publicación por parte de algún empleado de la compañía? Quizás. ¿Phishing en Comcast? Personalmente, creo que tenemos ganador, aunque la propia victima, recordemos de nuevo, especialista en tecnología con la misma contraseña para todo, diga que no recuerda haber sido víctima de un phishing. Comcast como no, ha hablado sobre el tema, y aquí llegamos a otro hecho que se repite mucho en este tipo de incidentes cuando la compañía da la cara...no un momento, en eso consiste, al final no dan la cara... resumiendo, declaran y cito NO textualmente: "¿8000? no hombre no, unos 700, al resto no les hagáis caso que ya no son clientes".


Leer más...

17 marzo 2009

Protección física a la consola Linux

En este artículo vamos a revisar distintos controles para evitar el acceso no autorizado a un equipo mediante el acceso físico al sistema (o a la consola). Como siempre, ninguna opción soluciona el problema, pero todas ellas añaden capas de seguridad adicionales.

Añadir contraseña a la BIOS

La primera configuración a modificar es asignar a la BIOS una contraseña de acceso, de esta forma no se podrá alterar el orden de inicio de dispositivos y arrancar con un CD o USB.

La modificación de la BIOS varía según los distintos fabricantes.

En algunos casos se puede arrancar un menú de "Configuración de inicio", o boot, pulsando una tecla cuando el sistema carga la BIOS, esta opción también se ha de deshabilitar.

Añadir contraseña al Grub/Lilo

Los sistemas de gestión de arranque, como Grub y Lilo, permiten modificar en tiempo de ejecución el arranque normal del sistema con parámetros que evitan la parte de autenticación finalpermiten acceso a su consola, así como el arranque de otro sistema operativo instalado en el equipo. Para evitar estas alteraciones se puede definir controles mitigadores.

En el caso de Grub, mediante la ejecución del siguiente comando:
/sbin/grub-md5-crypt
Que devuelve un hash md5 y que ha de ser introducido en el archivo: /boot/grub/grub.conf

De la forma: password --md5 <hash anterior>

Finalmente, para evitar el arranque de otro sistema operativo, se ha de modificar el /boot/grub/grub.conf y bajo la línea "title", del sistema operativo a bloquear, hay que añadir una línea: "lock". Esta medida ha de ser implantada junto a la anterior, es decir, se ha de definir una contraseña previamente.

El resultado final debería tener este aspecto:
title DOS
lock
password --md5 <hash del comando anterior>
En el caso de Lilo, la primera recomendación es su migración a Grub, ya que este dispone de menos mecanismos de seguridad y sus controles han sido evitados en distintas ocasiones. Como esta recomendación no siempre es aplicable, las medidas a adoptar son similares, se ha de asignar una contraseña en su fichero de configuración: /etc/lilo.conf

Antes de la primera etiqueta "image", se introduce la línea:

password=<contraseña>

Una vez modificado, se ha de ejecutar "lilo" para almacenar los cambios.
Para que otros usuarios no puedan leer el fichero, este ha de tener permisos 600:

chmod 600 /etc/lilo.conf

Lilo permite especificar contraseñas distintas dependiendo de la imagen, así como la opción de que solo sea solicitada en caso de que se introduzcan parámetros en el inicio. Podeís consultar más información en las referencias.

http://www.gnu.org/software/grub/manual/grub.html#Security
http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/security-guide/s1-wstation-boot-sec.html


Añadir autenticación al modo "single-user"

Para añadir autenticación al modo single-user se modifica el archivo /etc/inittab y se añade la siguiente línea:

~~:S:wait:/sbin/sulogin

De esta forma, si el sistema es arrancado en este modo, no se presentará la consola de root directamente y solicitará antes su contraseña.

Referencia: http://linux.die.net/man/5/inittab

Deshabilitar las teclas interactivas

Las distribuciones basadas en el fabuloso mundo RedHat, como Fedora, CentOS, RHEL, etc, permiten arrancar interactivamente seleccionando que servicios arrancar y cuales no, con lo que se podría evitar, por ejemplo, el arranque del firewall.

Esta opción se puede eliminar modificando el archivo: /etc/sysconfig/init y cambiando el parámetro PROMPT a "no".
PROMPT=no
Referencia:http://www.redhat.com/docs/manuals/linux/RHL-8.0-Manual/ref-guide/s1-boot-init-shutdown-sysconfig.html


Activar tiempos de espera en la shell

De la shell (bourne again shell) ya hemos hablado en otra entrada, aquí remarcar que existe la posibilidad de que haga cierre de sesión (exit) automáticamente si no hay actividad.

Editando el archivo: /etc/profile añadir una línea:
TMOUT=600
Los 600 son segundos de inactividad.

Referencia: http://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html

Activar bloqueo de pantalla

El bloqueo de pantalla se puede activar de distintas maneras que dependiendo del entorno que se utiliza.

Si el sistema no tiene arrancado el servidor X, es necesario instalar la aplicación "vlock". Una vez instalada, su uso es tan fácil como llamarlo mediante el comando:
vlock -a
Si el equipo tiene entorno gráfico, se puede configurar el protector de pantalla para que este bloquee el equipo cuando es ejecutado. Esta configuración dependerá del gestor utilizado.

http://docs.kde.org/stable/en/kdebase-workspace/kcontrol/screensaver/index.html
http://live.gnome.org/GnomeScreensaver/FrequentlyAskedQuestions

Desactivar Ctrl+Alt+Del

En ocasiones se puede reiniciar el equipo "accidentalmente", mediante la combinación de teclas Ctrl+Alt+Del que son pulsadas en un terminal en vez de donde se pretendía... El objetivo de esta medida es deshabilitar esta combinación para que no tengan ningún efecto y haya que recurrir al comando 'reboot' o el botón de reinicio.

Para modificar el comportamiento, se edita el fichero: /etc/inittab comentando la línea:
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
Para que los cambios tengan efecto, es necesario reiniciar el servicio init: init q

Desactivar permisos especiales sobre unidades removibles

En algunas distribuciones, como RedHat, el módulo de PAM (pam_console), asigna permisos especiales a los usuarios que acceden localmente al sistema, de esta forma se les permite montar unidades como el CDROM o la disquetera. Puesto que estas unidades son removibles y contienen información desconocida, se aconseja eliminar este permiso. Para ello, se edita el fichero: /etc/security/console.perms.d/50-default.perms comentado las líneas en las que se muestre "<floppy>" y "<cdrom>"

El Benchmark de CIS deja a disposición este script para realizar la tarea:

cd /etc/security
CONS_PERM_FILE="console.perms"
DEF_FILE="console.perms.d/50-default.perms"
test -f $DEF_FILE && CONS_PERM_FILE="$DEF_FILE"
awk '( $1 == "<console>" ) && ( $3 !~
/sound|fb|kbd|joystick|v4l|mainboard|gpm|scanner|memstick|diskonkey/ ) \
{ $1 = "#<console>" }; { print }' ${CONS_PERM_FILE}-preCIS > $CONS_PERM_FILE
chown root:root $CONS_PERM_FILE
chmod 0600 $CONS_PERM_FILE
echo "diff ${CONS_PERM_FILE}-preCIS $CONS_PERM_FILE"
diff ${CONS_PERM_FILE}-preCIS $CONS_PERM_FILE


Referencia: http://www.redhat.com/docs/manuals/linux/RHL-7.1-Manual/ref-guide/s1-access-privileges-console-access.html

Desactivar permisos especiales sobre aplicaciones

Con la misma problemática que en el punto anterior, se permite a usuarios conectados en consola la ejecución de comandos de sistema como la parada o reinicio del equipo, para evitar esta funcionalidad basta con ejecutar:

rm -f /etc/security/console.apps/poweroff
rm -f /etc/security/console.apps/halt
rm -f /etc/security/console.apps/reboot

Referencia:http://www.redhat.com/docs/manuals/linux/RHL-7.1-Manual/ref-guide/s1-access-privileges-console-access.html

Cifrado

Si alguien accede al servidor, lo abre y extrae el HD, accederá a la información de forma sencilla utilizando este disco como secundario en otro sistema. Para evitar la fuga de información puede cifrarse su contenido mediante dmcrypt. De esta forma, aunque el disco sea robado, la información permanecerá inacesible para el curioso.

Para montar dmcrypt en una partición, de la cual su contenido será eliminado, y resumiendo al máximo los comandos:
cryptsetup luksFormat /dev/sdb1
cryptsetup luksOpen /dev/sdb1 volumen
mkfs.ext3 /dev/mapper/volumen
mount /dev/mapper/volumen
Hay extensa documentación para crear contenedores en vez de particiones, así como de especificar distintas opciones.



Tarjeta de video.

La mejor opción para evitar el acceso a la consola es eliminar el soporte en el kernel para la tarjeta gráfica, configurando el sistema para que únicamente se pueda acceder mediante puerto serie o remotamente.

Esta configuración aunque parece exagerada es la más eficaz. Para ello hay que editar tanto el inittab, como el grub o lilo.

Referencias:
http://www.vanemery.com/Linux/Serial/serial-console.html
http://znark.com/tech/serialconsole.html


Leer más...

Así actuan las redes de pedofilia

Leo en el blog de uno de los grandes gurús de la seguridad informática, Bruce Schneier, al que tuvimos la oportunidad de escuchar y conocer en persona en el Security Blogger Submit 2009, un artículo que ha hecho que se me pongan los pelos como escarpias.

En él, se nos cuenta que dichas redes funcionan mediante la correcta sincronización de varias piezas en un complejo engranaje. El primer paso es conseguir identidades falsas así como dinero asociado a dichas identidades. Para ello, existe una figura humana llamada "Carders" (personas que consiguen tarjetas de crédito y de identidad válidas de una forma ilícita). Éstos, contactan con falsificadores, que literalmente clonan dichas tarjetas robadas en documentos plásticos físicos. Dicho material se vende posteriormente a los "operadores" como kits de tarjetas de crédito. En USA además se pueden comprar tarjetas regalo de Visa y Mastercard (como las de iTunes, Ikea o el Corte Inglés). Esto, unido a una identidad falsa, permite hacer pagos válidos por Internet de forma anónima, para comprar por ejemplo los dominios o los servidores donde se alojarán los contenidos. Otras alternativas para anoninimizar dichas compras (y no poder ser relacionado con un dominio pedófilo) puede ser la utilización de un mecanismo análogo a Paypal (pero utilizado en Europa del Este) denominado Webmoney, utilizando una identidad falsa también.

En general se suelen comprar servidores para estos fines en Alemania, debido a que es sabido que son muy fiables, rápidos y baratos.
Una vez comprado el servidor, se hace una conexión contra el mismo a través de diferentes máquinas proxy a través de SSH. La máquina es "securizada" por el vendedor de pedofilia (mejor dicho por quien contrata para ello) utilizando contenedores cifrados como TrueCrypt (donde irán almacenados los contenidos prohibidos subidos por supuesto a través de varios proxies que anonimicen los orígenes) y deshabilitando completamente los logs de la máquina a fin de dejar posibles trazas. Además se suelen configurar medidas por las cuales, cuando se detecta un login mediante la consola, automáticamente se desmonta el contenedor cifrado. Lógicamente cuando se apaga la máquina físicamente sucederá lo mismo.

Igualmente, para poder subir contenidos se dejan habilitados en el firewall de la máquina una lista de IPs desde las que se permiten dichos accesos. Estas direcciones IP corresponden a otro tipo de servidores también comprados de las mismas maneras ya detalladas, en los que se aplican también tácticas de anonimización mediante Truecrypt y deshabilitado de logs. Estos servidores proxy o forwarders (como indica Bruce), desplegados por diferentes países de todo el mundo, actúan de puentes para poder subir de forma anónima los contenidos (utilizando túneles SSH y forwarding de puertos por ejemplo).

Asimismo, estos servidores proxy son los que actuarán como gateways para los consumidores de pedofilia, permitiendo que el servidor de Alemania que mencionábamos antes no pueda ser motivo de sospecha y sin accesos directos de pedófilos (excepto por estos servidores proxy que canalizan todas las solicitudes).

Para dotar de balanceo de carga a "la solución", se establece, a nivel DNS, para el dominio pedófilo comprado, un TTL (Time To Live) de unos pocos minutos, de manera que cuando diferentes usuarios pregunten por el dominio, cada X tiempo el servidor conteste con la IP de uno de los servidores proxy comentados en modo Round Robin.

El autor, nos deja luego con una reflexión en la que dice que una vez entendido el funcionamiento de estas mafias, es francamente muy complicado de pillar a los causantes de su existencia (aunque según mi punto de vista, los causantes no son los proveedores, sino los consumidores). Dice además que precisamente por este tipo de cosas, los políticos justifican la monitorización del contenido digital que circula por las redes, la creación de proyectos como Echelon o Carnivore por ejemplo, el caso de la ley que obliga a los ISPs a guardar registro de absolutamente todas las comunicaciones entrantes y salientes, la prohibición de utilización de longitudes de clave de más de 40 bits en la criptografía, la de exportar software de cifrado como se hizo con PGP,...

En otros casos, se ha utilizado el terrorismo como argumento para prohibir sobre la utilización de algoritmos y programas específicos de cifrado. Es bien sabido que las células terroristas utilizan los mecanismos de los que nos provee la criptografía para cifrar las comunicaciones, así como la información contenida en los propios PC's referentes a sus objetivos, estrategias y tácticas.

¿Es la pornografía infantil o el terrorismo la excusa para poder saber qué es lo que hacemos, cuándo, quiénes y desde dónde? Está claro que realmente necesario cierto control,... pero, ¿son suficientes dichos controles? ¿evolucionan a la misma velocidad que los mecanismos que los ciberdelincuentes utilizan para evitarlos?

Para quien quiera leerse el artículo entero en inglés (traducido del original en alemán), puede encontrarlo aquí:
Leer más...

16 marzo 2009

Hackeos memorables: La 'iglesia' de la cienciología

Todos hemos oído hablar de la 'iglesia' de la cienciología, esa organización bastante oscura que, si por algo se ha caracterizado, es por su excesivo celo a la hora de preservar su opacidad, y su decidida apuesta por emplear recursos legales para ello.

Lo que tal vez no todo el mundo sepa es como fueron literalmente humillados por uno de esos Hackers 'old School' llamado Keith Henson.

Pongámonos en situación, hace años, en la época de la isla-tortuga, los grupos de hackers adolescentes y en definitiva, en los albores del Internet-para-masas Español, se puso muy de moda una guía bastante buena llamada 'GUIDE TO (mostly) HARMLESS HACKING' (Guía del Hacker mas o menos inofensivo) editada por Carolyn Meinel. En esa guía, bastante divertida de leer (por cierto) se contaba una de las anécdotas mas hilarantes que jamas he escuchado.

Por lo visto el ex-marido de Carolyn, Keith Henson, a quien no le debían caer excesivamente bien los cienciologos, les envió un correo bastante burlón indicando que había colocado todos sus documentos mas secretos y confidenciales en la IP 127.0.0.1, esta dirección como supongo la mayoría ya sabe, es una dirección virtual que apunta a tu propio PC, es decir, si haces un ping 127.0.0.1 en realidad estas pingeando tu propio PC.

El caso es que los cienciologos se conectaron a esa IP y descubrieron horrorizados que, efectivamente, ahí se encontraban documentos altamente secretos de la cienciología, así que no dudaron en poner una demanda judicial contra el bueno de Keith. Evidentemente y según cuenta Carolyn, el juez una vez informado de que era 127.0.0.1 y del absurdo, despachó a los cienciologos entre risas.

No he podido encontrar confirmación 'oficial' de la anécdota mas alla del relato antes mencionado, lo que si es cierto es que Keith ha tenido serios problemas legales con los cienciólogos, hasta el punto de tener que huir a Canada para no acabar en prisión. Se puede leer bastante al respecto en la Wikipedia.

El capitulo donde se menciona la anécdota, traducido al castellano se puede leer aquí
Leer más...

Gateway wireless casero seguro

Recuerdo a una lectora de este blog preguntándome tiempo atrás por algún router para su conexión a Internet de casa (un saludo para Lain).

Pues bien, el fabricante de routers Linksys (este sí que es propiedad de Cisco y no D-Link como erré en un post anterior) ha firmado un acuerdo con el conocido fabricante de antivirus Trend Micro para incluir su suite de protección de navegación segura Home Network Defender en algunos de los routers Linksys.

Principalmente, esta solución provee a las conexiones ADSL de un nivel mejorado de seguridad en navegación, reduciendo las amenazas del phising, riesgos de robos de identidad, antivirus por supuesto, anti-spyware, controles parentales (al estar integrados dentro del router, se evita que "niños demasiado hábiles" puedan deshabilitarlos si son configurables en el propio PC). Asimismo permite la posibilidad de generar reportes de red en los que se puedan ver intentos de violaciones de lo permitido.

Los modelos de routers que incorporan este tipo de tecnología son los Linksys WRT310N y WRT610N. El servicio costará unos $60 al año, por lo que se puede contar con una solución más segura (al menos garantizada por dos de los fabricantes de productos de seguridad y networking más conocidos) para poder navegar de una forma más tranquila en entornos SOHO o simplemente para aquellos que quieran mayor protección delegada en el gateway desde casa.
Leer más...

15 marzo 2009

El extraño caso de w00tw00t.at.ISC.SANS.DFind

En todos los ámbitos de la vida siempre hay fenómenos extraños, con diversas explicaciones que nunca llegan a ser totalmente esclarecidos.

El caso del que hablo hoy es un misterioso log que aparece en los servidores web sin una explicación aparentemente clara, el fenómeno se manifiesta en una entrada en los logs del servidor web similar a esta:

GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1

Si hacéis la pertinente búsqueda en google veréis miles y miles de entradas en foros y webs preguntando si eso se trata de algún troyano, vulnerabilidad en alguna aplicación o ataque.

En principio el hecho de que aparezca ISC.SANS da a pensar que se trate de algo relacionado con el prestigioso SANS, pero como se puede ver en su web, ellos niegan tener nada que ver y mencionan vagamente la existencia de un scaner de vulnerabilidades que, por la razón que sea, deja esa marca en los logs.

Mi experiencia es que, dado el volumen de peticiones que recibo, (unas 100 x mes) que no van acompañadas de ataques o pruebas de vulnerabilidades, me hace descartar que se trate de la herramienta que mencionan.

En algunos foros se dice que 'alguien' a quien no le cae bien el SANS se dedica a enviar ese tráfico hacia los servidores web para dañar la imagen.

Sea como fuere, lo tranquilizante del asunto es que, hasta que se demuestre lo contrario, esa petición web no supone riesgo alguno
Leer más...

14 marzo 2009

Historia de un virus: Viernes 13

En 2009 llevamos una curiosa sucesión de días considerados por los supersticiosos como malignos. En Enero el 13 cayó martes, en Febrero cayó en viernes y en Marzo también, viernes 13. Qué recuerdos en los que la gente decía que como era viernes 13 (e incluso algún martes también lo he oido) iba a desenchufar el ordenador (aquellos Intel 286, 386 y 486 de la época) para evitar coger virus. Yo, que en aquella época estaba descubriendo esto de la informática (gracias amigo Domingo), me quedaba impactado por oir hablar de que por un virus informático hubiera gente que desenchufara el PC (por parecerme ridículo por supuesto, no porque me lo creyera).

Investigando el por qué de las cosas, el virus Viernes 13 (o Jerusalem) fue llamado así por la fecha en que se descubrió (Viernes 13 de Mayo de 1988) y porque, aunque se quedaba residente en la memoria RAM (ralentizando además la ejecución de los programas al incluir un delay), se activaba y efectuaba su ira cuando coincidía en el calendario que era viernes 13, borrando del sistema aquellos programas que intentaban ejecutarse. Su forma de reproducirse era incrementando la longitud de los ficheros .COM y .EXE.

El bulo de que el martes 13 también había que tener cuidado con los PCs y los virus era el mashup de otra historia. Por todos es conocido que en países como España o Grecia, así como en Latinoamérica, la supersitición de que el martes 13 es un día considerado como "de mala suerte" (en Italia es el viernes 17). En culturas anglosajonas es el Viernes 13 debido a que dicen que fue el viernes 13 de 1307 (explicado en el libro El Código DaVinci) cuando el rey Felipe IV de Francia, ordenó capturar y juzgar por la Inquisición a los Caballeros Templarios.

Dejando de lado los escepticismos, creo que ya nadie desenchufará (o no encenderá) el ordenador los viernes 13. Está claro que actualmente el volumen de gente que conoce el funcionamiento de un virus es mayor, hay más información.
Leer más...

13 marzo 2009

CodeGate 2009

El grupo Team CLGT, participantes en la Capture the Flag de BeistLab, CodeGate 2009, ha publicado un extenso documento con el detalle de cada una de las pruebas de clasificación de este concurso.

El nivel técnico es muy alto y es complicado seguir las pruebas incluso con la propia explicación.
Entre las pruebas se encuentran desarrollo de numerosos exploits, técnicas forenses, criptografía e incluso hay una prueba muy curiosa de esteganografía.

Eso si, no apto para gente con complejos, estos documentos te hacen ver lo largo que es el camino del verdadero Samurai.

Por cierto, España tiene representación con los setsi pandas, que han quedado sextos. Todo un orgullo.
Leer más...

12 marzo 2009

Contratar a un convicto

Recientemente han sido publicadas un par de historias relacionadas con el siempre controvertido hecho de contratar a alguien con antecedentes penales para desempeñar labores relacionadas con la seguridad informática.

La primera noticia habla de una startup llamada Mahalo cuyo dueño tiene en plantilla a un empleado con antecedentes por liderar y gestionar una botnet. La segunda noticia es aun mas candente, un hacker/pirata rumano que cumple una pena de prisión en Italia es objeto de deseo por parte de varias compañías, este ultimo caso cumple con todos los estereotipos: chico brillante, con proezas intelectuales contrastables y de brillantez fuera de lo común.

Sobre estos temas yo me he encontrado con posturas muy enconadas, por un lado aquellos que defienden los actos delictivos como 'pecadillos fruto de la curiosidad' con una visión muy permisiva. Del otro lado, están los que defienden que un delito es un delito y que contratar a un ex-pirata para acometer labores de seguridad es como meter al zorro en el gallinero.

Quitando el mediático asunto de Mitnick, en España tenemos casos bastante notables, me consta que mucha gente involucrada en el 'Caso Hispahack' ahora mismo desempeña incluso labores de gestión en equipos de seguridad, y también conozco casos de gente que fue victima de la 'operación milenium' que se han reconvertido al lado profesional.
Leer más...

11 marzo 2009

Google, SEO y malware


Para qué nos vamos a engañar: Google es poderoso, es capaz de generar incertidumbre a nivel mundial, y "sin querer", poder desviar la atención de la gente a un lado o a otro.


Pongamos en situación, exactamente en el que todo el planeta GMail cayó. Debido a este hecho, las 3 palabras más repetidas en ese momento fueron "Gmail is down". Se convirtió en una marca, en un slogan perfecto para hacer camisetas, gorras, chapas, etc, pero la cosa no quedó ahí.

Juntemos esa frase con el propio buscador de Google. Lo normal es que aparecieran miles y miles de enlaces a noticias que hablasen del tema, posts de blogs personales...pues no, los más avispados, ya vieron el filón a este query tan predecible. Si se junta en un recipiente un nombre de archivo descriptivo que incluya los términos más relevantes, un summary que coincida con el resultado más importante que arroja la búsqueda, y el hecho de que mucha gente suele hacer click siempre en todos los primeros resultados para comparar cual de ellos es que el mejor acierta en lo buscado...pues tenemos un método para distribuir malware y demás bichos.


Lejos queda aquella época, en la que alguien hacía un virus o troyano y tenía que pensar después como distribuirlo para infectar al mayor número de gente; mientras el crawler del motor de búsqueda de Google siga así de cuadriculado en su asignación de "mejores resultados" basándose en modas, sin fijarse en lo que verdad importa como es el contenido, contamos con el mejor aliado.


[+] Enlace original: Blog de McAfee - Google Trends Abused to Serve Malware
Leer más...

10 marzo 2009

Dentro del mundo de la seguridad física, y aprovechando las diferentes capacidades que nos brinda la tecnología GPS (hasta que dejen de permitirnos la utilización gratuita de los satélites y haya que pagar por ellos), quiero mencionar ciertas aplicaciones que pueden ser muy interesantes.

El mínimo común múltiplo de dichas aplicaciones incluyen la utilización de un dispositivo de localización GPS con una tarjeta SIM y conectividad GPRS, UMTS o HSDPA Dicho equipo es capaz de enviar vía tarjeta SIM, hacia un servidor web determinado y de forma periódica, las coordenadas detectadas por el chip GPS interno. ¿Utilidades que puede tener este invento? Desde control de flotas de vehículos (camiones/furgonetas de reparto, gestión óptima de taxis,...), así como monitorización/localización de personas mayores, niños, mascotas, colectivos de ganado,... (sí, ya sé positivamente que mezclar personas que presentan ciertas debilidades físicas o mentales y animales, a modo de ejemplos no es del todo adecuado), marcado de según qué tipo de objetos para su control (véase el caso de introducir un dispositivo en un alijo de drogas/armas y hacer su seguimiento en un momento dado para desmantelar una banda organizada),.... y todo ello en tiempo real.

Evidentemente, el conocer las coordenadas de localización provistas por el dispositivo, es mucho más útil si además se facilita la superposición de las mismas sobre un mapa, que permita identificar con una calle/cruce de una ciudad a la que podamos acudir con el séptimo de caballería. Por ello, hay multitud de empresas que ofrecen el servicio (tras autenticación mediante usuario/contraseña) de superponer las coordenadas enviadas por el dispositivo sobre una cartografía entendible (generalmente se utiliza Google Maps). Entre otras podemos destacar, como servicios comerciales (o casi comerciales, puesto que permiten funcionalizades libres): www.locatormap.eu, Sanav, Grupo Detector (venden el dispositivo por unos 700 euros con instalación incluida de forma oculta en el coche más un mantenimiento anual de 150 euros más o menos),...

En cuanto a proyectos libres (aquellos que permiten la instalación propia de un servidor de aplicaciones o web y base de datos a los que enviar las coordenadas los dispositivos) podemos destacar: OpenGTS/OpenDMTP... Ambos, aparte de ser compatibles con los dispositivos GC101M y GC101FA, proveen de una aplicación que se puede instalar en una PDA con GPS (en versiones C++ y java). De momento sólo está soportada/probada en la PDA HP hw6945????? aunque tengo en mi To Do probarla en mi antigua Qtek 9100 con una antena GPS bluetooth desde hace un tiempo :-$

Llegados a este punto, lo que me gustaría plantear, tal cual reza el título de este artículo es: ¿Cómo de protegida se encuentra la información de coordenadas por parte de las empresas que proveen de este servicio? ¿Hasta qué punto la autenticación que proveen mediante usuario/contraseña es fácilmente comprometible? La realidad es que dicha información podría ser objeto de compra por multitud de empresas que quieran recopilar datos sobre la rutina diaria de determinado tipo de personas a fin de ofrecerles publicidad más certera, mafias que deseen conocer recorridos y horarios para desvalijar casas vacías, etc,...

¿Quién nos asegura que nuestros datos de navegación (de vehículo) mantendrán unos niveles adecuados de seguridad a fin de mantener nuestra privacidad? En general las organizaciones que ofrecen estos servicios de tracking suelen hacerlo de una forma gratuita (o con una versión gratis y una de pago más funcional) por lo que (sin haberme leído los términos de su licencia de uso) se puede intuir que los datos que ahí se almacenan son parte de su propiedad para poderlos vender, o utilizar a su voluntad.

Por estas razones, pienso que puede merecer la pena la configuración, a nivel "casero" (o en caso de necesitar una disponibilidad total en un hosting), de una instancia como las ofrecidas por el proyecto OpenDmtp, no dejando la información en manos externas al menos. Ya os iré contando si merece o no la pena :D
Leer más...

09 marzo 2009

Con la llegada primero de Ceres-FNMT y posteriormente con el impulso del DNI-E, la administración Española ha ido lanzando una serie de servicios-online que permiten realizar todo tipo de trámites, desde presentar la declaración de la renta hasta consultar el informe de vida laboral de la seguridad social.

Obviamente todos estos trámites van protegidos por sesiones SSL lo que a priori puede parecer un entorno totalmente confiable.

Lo que no todo el mundo sabe es que SSL como tal, no es un protocolo único, mas bien es una enorme familia de protocolos, empezando por que existen 4 versiones (SSL v1, SSL v2, SSL v3 y TLS) además en cada versión se pueden negociar diferentes algoritmos con sus correspondientes longitudes.

Podriamos decir que el mundo SSL es como el mundo de las hipotecas, existen algoritmos AAA fiables y algoritmos subprime inseguros y poco aconsejables.

En concreto, el objeto de este estudio es la parte de los algoritmos simétricos que a la postre, son los que cifran los datos en tránsito.

Unanimemente la comunidad criptográfica considera los algoritmos de cifrado simétrico por debajo de 128 bits como inseguros. No olvidemos que, en la época que EEUU aplicaba fuertes restricciones criptográficas, el limite estaba en 40-bits.

Haciendo uso de la herramienta 'manyssl' (herramienta que permite interrogar que algoritmos acepta en una negociación ssl un servidor) he auditado unos cuantos de los servidores que aparecen listados en el portal del dni-e.

¿El resultado? La totalidad de ellos permiten un mínimo de 2 algoritmos inseguros, pero lo normal es ver disponibles bastantes mas:

Como se puede apreciar en el gráfico, la CMT, el INEM y la Agencia de Protección de Datos, son los menos vulnerables (2 algoritmos) y destaca NIC por sus desnhorrosos 15.

Que un servidor web permita negociar algoritmos SSL inseguros no significa que las transacciones con ellos sean inseguras, ya que lo normal es que tu navegador, cuando se conecte al servidor, negocie algoritmos óptimos.

El problema es que potencialmente esos servidores, que gestionan transacciones importantes, son susceptibles de que alguien se conecte a ellos de forma insegura. En muchos casos soportan incluso SSL v2 que tiene en su haber un horrible bug de tipo 'downgrade' que permite tomar el control de una sesión SSL.

¿Solución? Deshabilitar los algoritmos inseguros y en caso de que alguien intente conectar y no soporte las versiones seguras, advertírselo para que se actualice

El documento completo del estudio con los algoritmos, se puede descargar desde aquí y está en formato OpenOffice
Leer más...

07 marzo 2009

Hackeos memorables: El Twitter de Enrique Dans

Puede parecer muy petulante que auto-incluya en nuestra sección de 'Hackeos memorables' algo que hemos realizado nosotros, pero dada la repercusión que el asunto está tomando, me voy a permitir la licencia.

Recientemente se ha publicado que Twitter en su método de actualización basado en SMS es susceptible de ser 'spoofeado' enviando sms cuyo origen sea el numero de móvil que está asociado a la cuenta.

Lo del SMS Spoofing no es nada nuevo, ya escribimos tiempo atrás un premonitorio artículo sobre la fiabilidad de los SMS y los servicios basados en el numero de origen.

El caso es que una vez en conocimiento del ataque, me decidí a hacer pruebas, lo primero que me hacia falta era un servicio para enviar sms en el que pudiera editar a mi antojo el numero de origen, probé BromaSMS pero este servicio solo se puede emplear en números nacionales (el numero para postear en twitter es un +44 inglés) así que ese servicio no me era útil. Después de pensarlo un poco, recordé que la gente de lleida.net tienen un servicio que permite enviar SMS desde la web, una vez registrado me puse a probar en mi casi-abandonada cuenta Twitter.

Sorprendentemente los updates enviados desde el servicio de LLeida funcionaban, así que después de pensar en las posibilidades del bug, me vino a la cabeza la persona mas pro-twitter de España: Enrique Dans.

Solo me faltaba un detalle, conocer el teléfono que estaba asociado a la cuenta de Twitter. La búsqueda fue sencilla ya que Enrique publica como datos de contacto su teléfono móvil. En principio pensé que el numero ahí publicado solo seria algún tipo de móvil-filtro re-dirigido al verdadero, pero solo había una forma de salir de dudas: haciendo la prueba.

El resultado, como se puede apreciar, fue satisfactorio:


Enrique en su post sobre el tema apuesta por que los operadores de telefonía Españoles filtren ese tipo de mensajes. Yo, desde mi punto de vista, no soy tan optimista, si hicieran eso, servicios como el de lleida (perfectamente legitimo) dejarían de funcionar. En este caso el problema viene de implementar un servicio sustentado en algo tan poco seguro como el numero de teléfono. Yo lo veo análogo a si permitieran updates vía correo-electrónico tomando como elemento validador el correo origen. La solución por tanto pasa por implementar algún tipo de contraseña que tuviera que viajar junto al SMS para dar por buena la actualización.

Solo nos queda agradecer a Enrique por su fair-play y tomarse tan deportivamente el asunto
Leer más...