Backtrack 2, es una de las distribuciones live mas populares del momento (en temas de seguridad). Para los novatos, Backtrack es una live creada y mantenida por remote-exploit.org, actualmente en su version 2.0.

Backtrack 2 esta basado en Slackware con un kernel 2.6.18 (lo cual esta muy bien), cuenta con mas de 300 aplicaciones con las que hacer prácticamente todo permitiéndote el uso o bien de KDE o de Fluxbox como GUI. Como muchas otras live, si te gusta, podras instalarla en el disco duro.

Lo primero me llamo la atención al arrancarla es lo estéticamente agradable que es el arranque del sistema (Aquí os dejo un screenShot). Una vez completado el arranque te permite elegir o bien usar la consola a modo texto o arrancar Fluxbox o KDE. A mi persona mente no me gusta KDE pero si Fluxbox.

El theme en Fluxbox lo han adaptado a sus necesidades y la verdad es que lo han dejado muy bien. Lo que mas me gusto es que la barra de aplicaciones ahora ocupa todo el ancho de pantalla. El menú por otro lado esta organizado según el tipo de aplicaciones (Scanners, Password Attacks, etc), eso puede engranar, ya que muchas de las utilidades entrarían en varias de las categorías (ex: ettercap), lo cual si no estas familiarizado con ellas puede llevar a cierta confusión.

La mayor parte de las aplicaciones incluidas vienen ya preconfiguradas listas para la acción! (yei), que aunque parezca algo trivial no es nada fácil. No he tenido la oportunidad de probarlas todas (ya que hay muchas que desconozco), pero por ahora contento.

Sin embargo no todo bueno y bonito. Un pequeño “bug” que me encontré en mi portátil es el DHCP en BackTrack no es capaz de inicializar correctamente los parámetros de la red, lo cual es curioso ya que si que carga correctamente todos los drivers (tanto de la tarjeta de red normal y de la wireless). Un detalle que si que me ha fastidiado profundamente es el uso del “elvis 2.2.0” en vez del clásico “vim”. No conozco el motivo de esta decisión, pero a mi personalmente me fastidia.

Otro problema que me he encontrado es que en el otro ordenador donde la he probado he sido incapaz de arrancar el entrono gráfico por incompatibilidad de drivers. Este es el “talón de Aquiles” de las lives, así que no se lo voy a tener muy en cuenta.

BackTrack 2 por tanto es una distro completa y bien mantenida y que si tienes la suerte de que soporte tu hardware te puede ser muy util. Sin embargo, en este área hay magnificas alternativas, las cuales complementan unas a otras (el monopolio es una mala practica!). Yo personalmente procuro siempre llevar al menos una “Knoppix STD” (algo vieja pero aun de las mejores) y una “nUbuntu” (mi favorita) siempre encima, ya depender de una siempre es un riesgo por problemas de compatibilidad de drivers. A partir de hoy BackTrack se une a la lista tercera opción (debido principalmente a la ausencia del vim). Aun así os aconsejo que la probéis y me mandéis vuestras conclusiones.

Un saludo. Miggs

Cuantos de vosotros habéis oído hablar de DRM (Digital Rights Management)?.

Cuando hablamos de DRM normalmente nos referimos a aquellas técnicas implementadas por los creadores del contenido que intentan controlar el acceso y uso legitimo de material con copyright, intentando evitar la copia, uso y distribución no autorizada de dicho contenido. Por ejemplo, sistemas anticopia o uso de licencias con cientos de dígitos “requeridos” cada vez que instalamos algo (ex: 5RP2E-EPH3K-BR3LG-KMGTE-FN8PY).

Ok, y cuantos de vosotros habéis oído hablar de TC (Trusted Computing)?

Seguramente muchos menos. Pues bien, Trusted Computing es grosso modo “la versión hardware de los ya conocidos DRM (via software)”.

No soy un experto en el tema, pero sin embargo si os puedo introducir al tema. La idea consiste en implementar un pequeño chip (fisico) cuyo objetivo es filtrar el software “legitimo” del que no. Si algo es legitimo permitirá su uso, si no, no. Por supuesto tu (el consumidor pirata) no eres el que decides en cualquier caso lo que es legitimo y lo que no. En wikipedia y en bulma.net (el segundo en español), explican en mayor detalle como funciona dicho mecanismo.

Y porque menciono yo esto? Pues bien, este sistema se esta empezando a implementar ya sin que la gente lo sepa. Una de las grandes “virtudes” que este sistema implementa es la habilidad de identificar a los usuarios. Cada chip tiene un número único asociado con el cual se puede identificar el equipo que esta haciendo uso del sistema. Imaginémonos que el nuevo Windows media placer no solo no reproduciera música sin licencia, si no que además le enviase a Redmond un pequeño resumen de la lista de reproducción cada semana (ex: titulo del los archivos reproducidos), por ejemplo; “UltimoMegaHitDelVerano2007.mp3” o “LaHijaDelPanaderoEnBolasEnLaPlaya.avi“. Te gustaría, no?

Cierto es, que a día de hoy algo similar se podría conseguir o bien registrando tu producto con tus datos personales, o de cierta manera con las ips. En el primer caso, el usuario es consciente de lo que esta haciendo, y en el caso de las ips, para llevar un historial de un usuario determinado, necesitas que el ISP te de los datos de dicho cliente, y aun así, solo conseguirías la ip de la red (en la cual podría haber cientos o miles de equipos). Con este nuevo sistema se podría hacer con o sin consentimiento alguno. Nótese que el consentimiento normalmente lo das al instalar una aplicación simplemente pulsando un botón.

Como veis, esto ya no se trata solo de piratear o no ciertas canciones o aplicaciones, si no de invadir la privacidad personal además de la censura de limitarte a ejecutar solo aquello que ellos decidan que es legitimo. Así que ya sabéis…, Si leéis las siglas TC en algún equipo que queráis comprar pensároslo dos veces. La única manera de que este sistema no triunfe es que los consumidores le demos la espalda.

[youtube K1H7omJW4TI]

Un saludo. Miggs

Ayer, de nuevo, un amigo mio fue víctima de un ‘dictionary-based attack’, afortunadamente, parece que el atacante lo único que hizo fue cambiarle la password del usuario en cuestión. Aun así, si alguna vez alguien se “cuela” en tu equipo, la única manera de asegurarse que la seguridad del equipo no esta comprometida es formatear y reinstalar el sistema.

Hoy voy a detallar un pelin mas como blindar nuestro servidor de ssh para disminuir el riesgo de éxito de este tipo de ataques.

Una conexión Shh consta al menos de dos elementos basicos; cliente y servidor. Las distribuciones basadas en Debian Linux, el cliente se llama ssh y su fichero de configuración se encuentra en “/etc/ssh/ssh_config”. Y el servidor se llama sshd y su configuración se encuentra en “/etc/ssh/sshd_config”. Como deberes, echale un ojo y navega entre la opciones enterandote de para que sirven cada una de las opciones, deshabilitando aquellas que no sean necesarias.

Los cambios realizados en el servidor no se harán efectivos mientras no se reinicie el servicio (“/etc/init.d/ssh restart”)!

Cambia el puerto de escucha. El puerto estándar de escucha de los servidores ssh es el 22. Mi consejo es que siempre que puedas lo cambies. Si tu servidor esta detrás de un router basta con que cambies el puerto de escucha en la NAT. Si también quieres que el cambio afecte al área local, entonces tendrás que actualizar el parámetro “Port” en “/etc/ssh/ssh_config”.

Ventajas:
Eliminas completamente las posibilidades de éxito de scripts que se dedican a ‘barrer’ ips (La gran mayoría de los intentos)

Desventajas:
En sistemas con un elevado numero de usuarios, el cambiar de puerto solo complicara la vida de los usuarios (un parámetro mas que memorizar). Siendo no siempre posible de cambiar.
Complica ligeramente el mantenimiento del sistema.

Deshabilita aquellas opciones que no se usen. Shh nos proporciona una gran cantidad de opciones y posibilidades; autenticación mediante llaves criptográficas, uso de passwords vacías, root loging, X11Fordwarding, etc. Cuanto mas controladas tengamos dichas opciones mejor (o por lo menos que sepamos lo que están activadas). Una cosa que mucha gente olvida es que con el de llaves criptográficas el uso de passwords deja de ser necesario, y el cambiar de password algún usuario no le impedirá el acceso al sistema si tiene configurada dicha opción.

Ventajas:
Conocimiento y control de todo aquello que se podrá hacer a través de ssh y por tanto eliminación de posibles sorpresas.

Desventajas:
Ninguna

Restringir el acceso a determinadas ips. Ssh nos permite dos tipos de poéticas; denegación de acceso a determinadas ips (o rangos de ips), o autorización a uno o varios rangos de ips.
En caso de que quisiéramos bloquear a todos los usuarios de telefónica, lo único que debemos hacer es denegar el acceso al rango de ips reservado para telefónica. De la misma manera si quisiéramos permitir el acceso a usuarios de Brasil, aceptaríamos aquellas ips provenientes de Brasil.
Cuidado al ser demasiado permisivos o restrictivos a la hora de permitir o limitar acceso, ya que puede ser que bloquemos a gente a la que no debamos bloquear. además recordar que mediante el uso de proxys se puede enmascarar la ip de origen y saltarse dicha limitación.

Ventajas:
Pocas

Desventajas:
Este método suele resultar problemático. El motivo por el que lo nombro es para que sepáis de su existencia, es equivalente al filtrado de MAC en redes wifi.

Uso de llaves criptográficas. Esta es la forma mas segura de conectarse a un servidor ssh. Cada usuario posee una llave publica y una privada. La llave publica se guarda en el servidor (para encriptar), y la privada es guardada por el usuario (para desencriptar). Cada vez que nos conectemos al servidor este se encargara de comprar si la nuestra llave privada concuerda con alguna de las llaves publicas alojadas almacenadas en dicho servidor. Si alguna de estas concuerda entonces nos permitirá el acceso (evitando el introducir passwords).

Ventajas:
Muy cómodo en caso de múltiples accesos desde un mismo equipo.
Evita ataques “man in the middle”.
Cada usuario se encarga de mantener, y actualizar sus llaves.
Muy complicado de acceder por fuerza bruta.

Desventajas:
Necesidad de transportar la llave privada de un sitio a otro (algo engorroso si cambias constantemente de equipo).
Responsabilidad de mantener segura la llave privada (ya que en caso de que alguien se haga con ella podrá acceder al sistema).
Puede resultar algo abstracto para gente con conocimientos limitados en criptografía.

Limitar el número de intentos fallidos. Esta técnica es independiente del servidor de ssh. Consiste en bloquear el acceso a una determinada ip después de n intentos fallidos. Aquí os dejo un link de cómo implementarlo con iptables. Lo importante es que sepáis que esta existe y se puede implementar con relativa facilidad.

Ventajas:
Reduce drásticamente la posibilidad de éxito de ‘dictionary-based attacks’.

Desventajas:
Posibilidad de bloquear a nuestros propios usuarios.
Abierto a ataques DoS.

Conclusión:
Una buena gestión de usuarios y passwords es clave. Eliminar usuarios en desuso, el uso de aplicaciones como “Johnny the ripper” para localizar passwords “vulnerables”, y el cambio periódico de passwords son la mejor manera de mantener un sistema seguro!
Como en todo el peor enemigo de cualquier administrador es el desconocimiento del sistema. Por lo general, para el típico servidor de archivos casero, con cambiar el puerto de escucha y limitar los servicios disponibles es suficiente, aunque no siempre posible. Para equipos donde la seguridad es critica mi consejo es el uso exclusivo de llaves criptográficas como método de acceso. El restringir el acceso de ips puede parecer una buena idea, sin embargo no lo recomiendo bajo ninguna circunstancia.

Supongo que la mayoría de vosotros conocereis lo que un “SQL injection attack” es. Para los que no, “SQL injection” consiste en la inserción código SQL en las variables del programa que estés ejecutando. Si tienes suerte, el programa insertara dichas variables dentro de la “query” y podremos realizar el ataque.

Por ejemplo, imaginémonos el tipo formulario de acceso a un sistema. Este tiene dos campos, cuyas variables son “$nombreUsuario” y “$password”.

Una forma de comprobar si dicho usuario existe seria con la siguiente “query”

SELECT *
FROM tablaUsuarios
WHERE (userId = ‘$nombreUsuario’) AND (pass = ‘$password’);

Donde:

• tablaUsuarios -> tabla que contiene los usuarios
• userId -> campo de la tabla que contiene los nombre de usario
• pass -> campo de la tabla que contiene las passwords.

Si la query devuelve algún resultado entonces le damos acceso al usuario.
Bien, imaginémonos que como nombre de usuario introdujésemos lo siguiente;

• $nombreUsuario = pepito’ OR ‘x’=’x
• $password = nose’ OR ‘y’=’y

La query resultante seria la siguiente:

SELECT *
FROM tablaUsuarios
WHERE (userId = ‘pepito’ OR ‘x’=’x’) AND (pass = ‘nose’ OR ‘y’=’y’);

Como veis, la cláusula WHERE será siempre cierta y por tanto es muy probable que consigamos acceso al sistema (seguramente con el primer miembro de la lista).

La verdad es que es una pena que rara vez se hable del tema en entornos educativos, ya que existen formas de evitar dichas vulnerabilidades, y un correcto acceso a la información es básico. Muchas son las empresas que han sufrido de dichos ataques, y aun así, poco lo que se esta haciendo para advertir a las futuras generaciones de ingenieros y programadores.

No voy a entrar en mayor detalle en este tema ya que esta extensamente documentado en la red y con google podréis encontrar cientos de ejemplos, así como de soluciones o guías de prevención para evitar posibles ataques.

Sin embargo un video que si que os recomiendo ver es este.

Miggs

Saludos a todos! Durante esta semana se ha celebrado linux.conf.au 2007 en la Universidad de New South Wales en Sydney, Australia. Mucha gente importante se ha reunido aquí durante unos días para dar a conocer sus últimos proyectos. Compañías de la talla de IBM, Intel, Hp, Google, RedHat o Ubuntu y nombres de la talla de Linus Torvalds nos han hablado un poquito de los proyectos en los que se esta trabando ahora mismo, así como lo que nos vamos a encontrar en el mercado en los próximos meses.
Muchas han sido las conferencias, y muchos los proyectos presentados. Personalmente, el que más me llamo la atención fue el proyecto “olpc” (one laptop per child), el cual pretende acercar la tecnología a las zonas más pobres del planeta. La verdad es que se ha hablado mucho de dicho proyecto y seguramente ya habréis oído hablar de el.
Pues bueno, los representantes de dicho proyecto trajeron seis portátiles para darlos a conocer. Son una monada! Después de juguetear con uno de ellos durante unos minutos, la verdad es que me dejaron muy impresionado. Un 10 para ellos!
Tuve la oportunidad de hablar con los enviados de Intel, los cuales también trajeron varios prototipos de ordenadores ultra potables con los que según ellos querían llevar los sistemas de navegación en los coches un paso adelante.
Como anécdota, el enviado de fedora core habla español! para que veáis la importancia que tiene nuestra lengua en el mundo. Resulta que el chico había pasado tres anos en Perú, y bueno, me contó un par de curiosidades sobre como instalar sistemas Linux en reproductores de mp3 (tema muy interesante ahora que por fin las pantallas son a color y con altas resoluciones).

Aquí para acceder a la galería de fotos de icaix.
Aquí la pagina web de la conferencia (noticias, fotos, etc)
Aquí una entrevista con Linux Torvalds donde habla del futuro del kernel 2.6 y 2.7.

Un saludo. Miggs

Una de peculiaridades que tiene Linux es que puedes personalizarte un sistema, meterlo en un CD, DVD, o USB y llevártelo contigo a cualquier parte. Este tipo de sistemas se llaman distribuciones Live! y todas las grandes distribuciones tienen la suya. Ubuntu Live, Knoppix Live, Fedora Core Live, etc. Incluso en ICAI había un proyecto “GNU/Linux Entre Comillas”, desafortunadamente, a día de hoy el proyecto parece parado, y el link de descarga roto.

Aquí he creado una entrada en la wiki donde controlar el proyecto. El objetivo es montar un sistema lo mas ligero posible (intentar no superar los 200 MB), incluir la mayor cantidad de drivers y cargado con las mejores herramientas de seguridad. De tal manera que podáis probar los “how to” de seguridad que vayan apareciendo sin necesidad de instalar Linux.

La primera versión Alpha no saldrá a corto plazo. A día de hoy mi conocimiento en el tema es cero, pero espero ponerme rápidamente al día, con el compromiso de que la primera Alpha se publicara antes de Junio! lanzando la primera beta antes de septiembre.

La wiki estará actualizada en todo momento, podéis hacer sugerencias tanto en el foro, como en la zona de comentarios de noticias. Si queréis colaborar como probadores, mandarme un mail mangel12321@gmail.com.

El logo lo he sacado de Aqui, si quereis usarlo, leerlos la licencia!

Un saludo. Miggs

Ayer, un amigo me comentaba que el número de pingüinos que aparecen en la cabecera de la pantalla mientras se inicia el sistema depende del numero de núcleos del procesador (núcleo != procesador). Por ejemplo, con un procesador de la familia Core Duo, o con un P4 con tecnología Hyper Threading habilitada (Hyper Threading simula dos nucleos virtuales), te aparecerán dos pingüinos. Si por el contrario solo tienes un núcleo, pues te fastidias y solo te aparece uno.

Para ser sinceros, el icono es feo feo feo! Así que ni cortos ni perezosos, decidimos que debíamos cambiarlo. En teoría, no puede de ser muy complicado. Encontrar donde se encuentra el logo en el kernel y reemplazarlo. Como siempre lo primero que hicimos fue preguntarle a nuestro amigo “google”, que aunque el pobre no sepa mucho, siempre sabe donde si que nos pueden ayudar.

No tardamos mucho en encontrar esta wiki donde se explican dos métodos distintos para hacerlo. En ambos lo primero que hay que hacer es convertir nuestro logo a formato .ppm con 223 colores. Una vez finalizado puedes;

Simplemente reemplazar el antiguo logo por el nuevo. Este se encuentra dentro de “drivers/video/logo” dentro del código fuente del kernel.

El segundo método (más correcto) te indica que ficheros hay que editar y que código añadir para que la opción aparezca en el menú de configuración del kernel.

Una vez completado cualquiera de los dos pasos toca recompilar el kernel. La próxima ver que arranquemos el sistema los cambios deberían haber hecho efecto. Aquí os dejo una fotillo de mi portátil.

Os animo a que lo proveis, no se tarda mas de media hora, y la verdad es que queda muy simpatico el asunto.

Un saludo. Miggs

Navegando por attackprevention.com me he cruzado con un articulo la mar de gracioso. “The six Dumbest ways to secure a wireless LAN”, algo Así como “Las seis maneras mas absurdas de proteger una wireless LAN”.
Tanto si usáis wifi como si no en casa, este es un articulo que conviene leer.
Poco o nada mas que decir. Aqui el link

Miggs

Como buen administrador, después de los espectaculares resultados obtenidos en “Navegando entre los logs”, he intentado indagar en el tema, buscando sobre todo la fuente del ataque.
Al parecer, icaix.com no es la única experimentando dichos escaneos. Al tipo de ataque lo denominan ‘dictionary-based attack’, gracias a google he encontré a un tal “Zorg of #texter” (www.wget.home.ro) escribió un simple programita en C, con el cual a través de una lista de usuarios y passwords introducidas a “pelo” dentro del código, intenta conseguir acceso en la víctima.
Aquí os dejo el código. El programa (exploit) es muy sencillote de seguir y de customizar.

Hay varias soluciones para reducir las posibilidades de exito de dicho exploit:

• La primera es evitar el uso de usuarios y passwords comunes. In icaix todos los usuarios con acceso a la shell tienen un pequeño prefijo antes del nombre de usuario (icaix1_miggs, icaix2_cdc, icaix3_game…).
• La segunda es cambiar el puerto de escucha. Si por defecto el sshd escucha en el puerto 22, pues cambiarlo al 2222. Así evitaras todo este tipo de exploits automatizados.
• La tercera el limitar el acceso a determinados rangos de ips. Por ejemplo, bloquear las ips pertenecientes a nigeria, rumania, china, y japon.
• Otra opción es el uso de algún script que bloquee automáticamente la ip del posible intruso después de n intentos de acceso consecutivos fallidos. Uno de los primeros que me encontrado es este “sshblack”, pero hay multitud mas. Tengo que aclarar que no lo he probado todavía. Personalmente no me gusta porque el tiro te puede salir por la culata y quedarte bloqueado tu mismo.
• Por ultimo, y seguramente la mas segura, es el uso de “Rsaauthentication”, lo cual se basa en el uso de “llaves criptograficas” para loguearse. Cada usuario posee una llave privada, y una llave publica. La llave privada es secreta para uso propio. Y la llave publica es publica. Cualquier usuario que quiera enviar un mensaje lo encriptara con la llave publica, y solo el poseedor de la llave privada debería ser capaz de desencriptarla. Durante la configuración del servidor (o en cualquier momento), incluimos las llaves publicas de los usuarios con acceso a este. Una vez echo esto, los usuarios solo necesitan la llave privada para loguearse (nada de passwords). Este método además evita posibles ataques “man in the middle”. Os he dejado un tutorial en la sección de howto, al que podéis acceder directamente aquí.

Pues eso es todo. Os recomiendo que intentéis el ultimo método en casa!

Un saludo, Miggs.

Hoy le he pegado un repasillo a los logs a ver si se había colado alguien en el ultimo mes. No tiene mala pinta, 3945 solicitudes de acceso denegadas! la verdad es que ya me gustaría tener ese numero de visitas en la web… Lamentablemente no es así, además, los muy jodidos ni se meten en la pagina para verla y postear algún comentario!, aunque la verdad… Viniendo de Alemania, Francia, Dinamarca, Korea o Japon, no les culpo, no se deben enterar de nada.

Aunque 3945 intentos de acceso parezcan muchos, el numero de ataques no llega a la decena. Lo que pasa es que cada ataque lo intenta cientos de veces en periodos de entre 10 min y algo mas de una hora (Brute force attack).

Afortunadamente, ninguno de ellos consiguió colarse. Sin embargo, el análisis de los logs me esta dando mucho que pensar.

Analizando dichos datos, podría concluir que hay tres tipos de ataques:

• El primero, el mas altruista de los tres, se intenta hacer con acceso de root, con el fin de conseguir completo control de la maquina. El ataque consiste en adivinar la password probando a ciegas con las mas comunes, seguramente con ayuda de algún diccionario de passwords. Fuji esta configurado para no permitir dos intentos consecutivos en menos de tres segundos, es decir, si te equivocas te toca esperar tres segundos. Esto para un usuario normal es razonable, y con esto se consigue eliminar la posibilidad de probar todas la posibles passwords.
• El segundo ataque, el cual dudo mucho que funcione demasiado bien a día de hoy. Consiste en comprobar si los nombres de usuarios mas comúnmente usados, tienen la password en blanco. Supongo que se dará el caso de que por error o por una mala gestión de cuentas, el ataque pueda ser exitoso, sin embargo, a día de hoy todos los sistemas están configurados por defecto de tal manera que obligan a los usuarios usar una passwords de n caracteres (n > 0), aun así aquí os dejo un listado de los nombres de usuario con los que lo han intentado
• El tercero es una mezcla de los dos anteriores. Por cada usuario lo intenta un par de veces con las passwords mas comunes a ver si cuela.

A mi personalmente me gusta el primero el que mas…, si intentas hacerte con un equipo, que sea con todos lo privilegios. Obviamente no conseguirás romper los servidores de telefónica, sin embargo, ahora que se esta poniendo de moda lo de montarse un servidor en casa el numero de posibles víctimas esta aumentando considerablemente.Bueno gente
Aquí el log (he filtrado toda la basura para hacerlo mas fácil de seguir, así como los accesos de los usuarios de verdad para preservar la anonimidad y la seguridad del sistema)
Miggs.

P.S.: Por supuesto, me he puesto en contacto con ISP responsables de las ips dándoles a conocer dichos intentos.

PS 2: Si me intentáis hackear por favor mantenerme informado. No me importa que lo hagáis, es mas, os animo. Eso si, si encontráis alguna vulnerabilidad por favor avisarme.