INSTITUTO TECNOLOGICO SUPERIOR DE LA SIERRA NEGRA DE AJALPAN

ING. EN SISTEMAS COMPUTACIONALES CATEDRATICO: ING. MARCO ANTONIO ISIDRO ABRIL MATERIA: SISTEMAS OPERATIVOS I
LOGS TEST DE PENETRACION BULNERABILIDAD BACKDOOR ESCUCHA DE PUERTOS ZODODAY COOKES

ALUMNO: RAUL DIONICIO PANZO 3ER. SEMESTRE AJALPAN, PUE., NOVIEMRE DE 2012

DEFINICION DE LOGS

Un log es un registro de actividad de un sistema, que generalmente se guarda en un fichero de texto, al que se le van aadiendo lneas a medida que se realizan acciones sobre el sistema.

Se utiliza en muchos casos distintos, para guardar informacin sobre la actividad de sistemas variados. Tal vez su uso ms inmediato a nuestras actividades como desarrolladores del web sera el log de accesos al servidor web, que analizado da informacin del trfico de nuestro sitio. Cualquier servidor web dispone de un log con los accesos, pero adems, suelen disponer de otros log, por ejemplo, de errores. Los sistemas operativos tambin suelen trabajar con logs, por ejemplo para guardar incidencias, errores, accesos de usuarios, etc. A travs de los log se puede encontrar informacin para detectar posibles problemas en caso de que no funcione algn sistema como debiera o se haya producido una incidencia de seguridad. FAMILIARIZNDONOS CON LOS LOGS DE LINUX

Linux tiene un sistema muy simple para el manejo de eventos del sistema, o mejor conocidos como logs, con ver los logs nos es posible saber una increible cantidad de informacion, quien se logueo al sistema, quien hiso peticiones a un servidor de apache, que eventos han sucedido en el sistema, entre otros tantos, es por eso la importancia de saber donde buscar la informacion, y como encontrar.

Los logs de Linux se encuentran en /var/logs/ la forma ms viable para verlos es con tail y su flag -f (para ver en tiempo real lo que se va escribiendo en los logs) si usamos F (mayuscula) nos mostrara todo el contenido del archivo, y aparte nos mostrara lo que se va escribiendo segundo a segundo, es quizs ms viable que un simple cat, lo que en archivos grandes se puede volver una pesadilla.

Por lo mismo contamos con otro comando, grep, con el cual podemos buscar cadenas de texto dentro de un log, de hecho es muy completo y nos permite usar comodines y varias opciones ms. Entre los logs ms comunes y que es ms comn encontrar en un sistema con linux estan: auth.log Informacion sobre autentificaciones y logueos boot.log Informacion del boot crond Tareas programadas (cron) daemon.log Alertas especificas de algunos demonios dmesg Mensajes del kernel errors.log . el nombre lo dice everything.log .. httpd si tenemos un servidor de apache aqui se registran los eventos, en sistemas debian tiene otro nombre mail.log Logs del servidor del correo, tambien puede variar, si usamos exim sera exim_main.log etc messages.log Alertas generales del sistema mysqld.log Registro de eventos de mysql secure Log de seguridad syslog.log Recursividad RlZ un log del sistema de registro de eventos vsftpd.log El log del servidor FTP (vsfp) Xorg.0.log El log de las X

Ahora bien, si quisiramos ver cuando se a conectado el usuario pepito al servidor podramos poner sudo cat /var/log/secure |grep pepito es bastante ambiguo, pero podriamos ver los eventos involucrados con pepito, suerte.

TEST DE PENETRACIN Test de Penetracin, tambin llamado a veces hacking tico es una evaluacin activa de las medidas de seguridad de la informacin. En los entornos de red complejos actuales, la exposicin potencial al riesgo es cada vez mayor y securizar los sistemas se convierten en un autntico reto. A travs del Test de Penetracin es posible detectar el nivel de Seguridad Interna y Externa de los Sistemas de Informacin de la empresa, determinando el grado de acceso que tendra un atacante con intenciones maliciosas. Adems, el servicio chequea las vulnerabilidades que pueden ser vistas y explotadas por individuos no autorizados, crackers, agentes de informacin, ladrones, antiguos empleados, competidores, etc. Los servicios de Test de Penetracin permiten:

Evaluar vulnerabilidades por medio de la identificacin de debilidades de configuracin que puedan ser explotadas. Analizar y categorizar las debilidades explotables basadas en el impacto potencial y posibilidad de ocurrencia. Proveer recomendaciones prioritizadas para mitigar y eliminar las debilidades.

El Test de Penetracin est dirigido a la bsqueda de agujeros de seguridad de forma focalizada en uno o varios recursos crticos, como puede ser el firewall o el servidor Web. Este ser el espacio de recopilacin de todos los Post relacionados con los entornos, retos, pruebas, wargames, CTF y documentacin de la temtica Test de Penetracin. La finalidad ser desarrollar los objetivos propuestos por los desarrolladores de las pruebas. Los servicios de Test de Penetracin permiten:

Evaluar vulnerabilidades por medio de la identificacin de debilidades de configuracin que puedan ser explotadas. Analizar y categorizar las debilidades explotables basadas en el impacto potencial y posibilidad de ocurrencia. Proveer recomendaciones prioritizadas para mitigar y eliminar las debilidades.

El Test de Penetracin est dirigido a la bsqueda de agujeros de seguridad de forma focalizada en uno o varios recursos crticos, como puede ser el firewall o el servidor Web.

BackTrack: BackTrack es una distribucin GNU/Linux en formato LiveCD pensada y diseada para la auditora de seguridad y relacionada con la seguridad informtica en general. VULNERABILIDADES Son errores que permiten realizar desde afuera actos sin permiso del administrador del equipo, incluso se puede suplantar al usuario, actualmente, ya hay muchas amenazas que tratan de accesar remotamente a los ordenadores, ya sea para hacerlos servidores ilegales de Spam o para robar informacin, de los agujeros ms famosos est el LSASS y el de SVSHOST, de los cuales el Sasser y Blaster se diseminaron rpidamente. Cmo evitarlas? Es imposible evitar las vulnerabilidades al 100% incluso cuando tenemos operando en nuestro sistema cortafuegos, antispam, antivirus, y detectores de cdigo maligo. Lo que si es posible es tratar de evitarlas al mximo posible. Tengamos presente que las comunicaciones en la red constan de 7 capas segn el modelo OSI, y las vulnerabilidades pueden estar presentes en varias capas, o incluso dentro del ncleo de nuestro sistema operativo. No debemos imaginar que con un buen antivirus podemos estar libres de vulnerabilidades, ya que las vulnerabilidades no son solo mediante virus que estn radicando en nuestra computadora sino que tambin pueden llegar a ser mediante ejecucin de cdigo mientras visitemos alguna pgina web, o cuando el atacante tiene privilegios de acceso a nivel administrativo a nuestra computadora As que se debe tener presente que para evitar las vulnerabilidades no solamente basta con tener un antivirus y ejecutarlo de manera peridica

Lista de recomendaciones para tener nuestra computadora libre de virus: 1. Actualice o cheque las actualizaciones cada cierto tiempo, pues eso permite casi adelantarse a cualquier peligro que se aproveche de la vulnerabilidad. 2. Activar Firewall.

3. Programar escaneos completos del Antivirus mensuales. 4. No caer en trampas obvias como correos spam dicindote que ganaste la lotera en un pas que ni siquiera conoces. 5. Si vas a descargar msica, libros, programas ejecutables, etc. procura hacerlo solo de fuentes confiables 6- Vacunar unidades externas. (Genaro aportacin). Cmo las explotan? Aunque no siempre hay una regla general para explotar vulnerabilidades de los sistemas podemos describir a grandes rasgos una serie de pasos para llegar a tal cometido:

paso 1 conocer la existencia de la vulnerabilidad paso 2 documentarse sobre las caractersticas de la vulnerabilidad paso 3 conocer las caractersticas del sistema que se va a explotar paso 4 conseguir acceso a ese sistema con los privilegios suficientes.

Una vez conseguido el acceso al sistema en cuestin, se es libre de hacer lo que se quiera hacer, es como estar operando frente al computador vctima.

Qu consecuencias traen? Simplifican un ataque, permitiendo a los crackers obtener ms permisos en el equipo vctima y poder usarlo al libre albedro, o el sistema puede ejecutar automticamente cdigos maliciosos, abrir puertos, o en algunos casos es el almacenaciemto incorrecto de datos privados, como contraseas. Un ejemplo es elRemote File Inclusion hola

No es el da de los Santos Inocentes, ni de aqu (28 de Diciembre) ni internacional (April's Fool). El sbado 9 de Junio Sergei Golubchik, coordinador de seguridad de MariaDB publicaba un post en la lista OSS-SEC sobre una grave vulnerabilidad que afectaba a diferentes versiones de MySQL y MariaDB.

Se evidencia la posibilidad de autenticarse como usuario con mximos privilegios (root) nicamente realizando conexiones simultneas, con CUALQUIER contrasea introducida como parmetro y contra un servidor vulnerable. Al cabo de un nmero indeterminado de intentos fallidos, el servidor aceptar la conexin y se realizar la autenticacin de forma

satisfactoria. Sin ms. Sin shellcodes raras, sin casusticas extraas: nicamente tenemos que tener delante un servidor vulnerable, que cumpla con las siguientes versiones: Son vulnerables todas las versiones de MariaDB y MySQL hasta la 5.1.61, 5.2.11, 5.3.5 y 5.5.22 NO SON vulnerables las versiones de MySQL 5.1.63, 5.5.24 y 5.6.6 NO SON vulnerables las versiones de MariaDB 5.1.62, 5.2.12, 5.3.6 y 5.5.23 Con la siguiente lnea en shell script, teniendo instalada una base de datos vulnerable en el sistema local, y contando con el cliente 'mysql', se podra realizar una autenticacin como usuario root sin conocer la contrasea:

for i in `seq 1 1000`; do mysql -u root --password=blablabla -h 127.0.0.1 2>/dev/null; done

Bsicamente, se ejecutar la sentencia de autenticacin mediante cliente por consola (comandomysql) como usuario root (-u root) y cualquier contrasea (--

password=blablabla) contra el servidor vulnerable presente en el mismo sistema donde se ejecuta este script (-h 127.0.0.1), sin mostrar ningn mensaje de error por pantalla (2>/dev/null).

Vamos a ver el ejemplo real. Las siguientes pruebas se han realizado sobre una Fedora Core 16, con MySQL versin 5.5.21:

En primer lugar, y para este ejemplo, cambiaremos la contrasea original de MySQL para el usuario root, que antes la tenamos establecida a 'password', para que ahora sea 'SuperPassWordDeLaMuerte':

Seguidamente, salimos de la sesin de root, y nos quedamos como usuario sin privilegios, y ejecutamos la secuencia anterior, que realizar conexiones como usuario root y cualquier contrasea, programando un total de 1000 intentos. A continuacin se ejecutar la consola de mysql satisfactoriamente:

Comprobamos el usuario con el que estamos autenticados mediante la sentencia select current_user(), obteniendo como resultado 'root@localhost'

Obviamente, este "ataque" ya se encuentra integrado como exploit de Metasploit Framework, permitiendo adems el volcado de hashes de todos los usuarios, todo ello con el mdulo mysql_authbypass_hashdump:

Actualmente Vulnerabilidad en Apache permite acceder a servidores internos Vulnerabilidad en Apache permite acceder a servidores internos.

Encontramos en cert.inteco.es la siguiente informacin:

Importancia: 4 - Alta Fecha de publicacin: 07/10/2011 Recursos afectados

Apache 1.3 y Apache 2 hasta la versin 2.2.20 estn afectadas por esta vulnerabilidad.

Descripcin La empresa de seguridad "Context Information Security" ha descubierto una vulnerabilidad en el servidor web Apache cuando est corriendo como "Reverse Proxy" permitiendo a usuarios externos acceder a servidores internos. Solucin Apache Foundatin ya ha publicado una actualizacin de seguridad para la versin 2.2.21que soluciona la vulnerabilidad. Una solucin temporal sera aadir una barra (/) extra a la regla rewrite como se indica en el ejemplo del ltimo prrafo en el detalle del aviso. Detalle El mdulo mod_rewrite de Apache proporciona un mtodo flexible para analizar sintcticamente (parsear) y reescribir solicitudes web al vuelo mediante expresiones regulares. Un uso comn de este mdulo es emplearlo como balanceador de carga entre varios servidores web o para segregar el contenido dinmico del contenido esttico cuando Apache se est ejecutando como "Reverse Proxy".

El problema radica en la forma en la que mod_rewrite resuelve determinadas solicitudes GET cuando se utiliza el smbolo @. Las implicaciones de esto permitiran que, por ejemplo, una peticin de la siguiente forma:

GET @ServidorInternoNoAccesible/console HTTP/1.0

se convirtiese en la URL

http://ServidorInterno:80@ServidorIn...esible/console

La URL resultante apuntara a ServidorInternoNoAccesible y tomara ServidorInternocomo usuario y 80 como password, solicitando la carga de la pgina console. El motivo de esta interpretacin se debe a que el mdulo mod_rewrite no discrimina determinadas solicitudes de acuerdo a la especificacin URI (RFC 3986), la cual admite la siguiente estructura:

Imgen extrada de Context

Una vez realizada la solicitud, ServidorInternoNoAccesible ignorar dichas credenciales y respondera de form legtima a la misma. El nico prerequisito que un atacante debera conocer sera el nombre o IP del servidor no pblico al que se desea conectar, aunque estos podran conseguirse mediante fuerza bruta.

Si el fichero de configuracin de Apache contiene la siguiente lnea:

RewriteRule ^(.*) http://ServidorInterno: 80$ [p]

en lugar de (fjese en la barra despus del puerto):

RewriteRule ^(.*) http://ServidorInterno: 80/$ [p]

sera susceptible de ser explotado desde Internet permitiendo por tanto que un usuario externo se conectase a cualquier servidor interno accesible por el proxy.

tiene una gran popularidad y aceptacin en la comunidad que se mueve en torno a la seguridad informtica. Deriva de la unin de dos grandes distribuciones orientadas a la seguridad, el Auditor + WHAX. WHAX es la evolucin del Whoppix,(WhiteHat Knoppix) el cual pas a basarse en SLAX en lugar de en Knoppix. Incluye larga lista de herramientas de seguridad listas para usar, entre las que destacan numerosos scanners de puertos y vulnerabilidades, archivos de exploits, sniffers, herramientas de anlisis forense y herramientas para la auditora Wireless. Fue incluida en la famosa lista Top 100 Network Security Tools del 2006 disponible en SecTools.Org BAKDROP

Puerta trasera En la informtica, una puerta trasera (o en ingls backdoor), en un sistema informtico es una secuencia especial dentro del cdigo de programacin, mediante la cual se pueden evitar los sistemas de seguridad del algoritmo (autentificacin) para acceder al sistema. Aunque estas puertas pueden ser utilizadas para fines maliciosos y espionaje no siempre son un error, pueden haber sido diseadas con la intencin de tener una entrada secreta. Puertas traseras ms conocidas Los ms conocidos son Back Orifice y NetBus, dos de los primeros backdoors, que hasta nuestros das siguen vigentes aunque en menor cantidad dado que la mayora de los programas antivirus los detectan. Otro muy conocido es el SubSeven, que tambin fue introducido en millones de ordenadores en el mundo.

Escucha de puertos Dentro de las tcnicas del hacking, una de las ms utilizadas es el Escaneo de Puertos, o Escucha de Puertos. Qu es el Escaneo de Puertos? Consiste en el envo de una serie de seales denominadas paquetes, que llegan a la mquina atacada, y esta responde reenviando otra determinada cantidad de paquetes, que el escaneador decodificara y traducir.

Dicha informacin consta esencialmente del nmero IP de la mquina atacada y datos sobre el o los puertos que se encuentran en ese momento abiertos. Cabe aclarar que con solo dos datos de esa informacin (nmero IP y un puerto abierto vulnerable), es ms que suficiente para realizar un ataque, o intentar tomar el control del ordenador. Muchos programas escaneadores de puertos permiten realizar escaneos masivos porinternet, encontrando aquellas mquinas vulnerables. Incluso dentro de Windows encontramos una herramienta utilizada en redes llamadaTelnet, que permite realizar un escaneo de puertos bajo DOS. De todas manerase esta herramienta no es muy potente para los hackers, y tambin puede dar errores en sus resultados (por ejemplo, una falta de respuesta de un determinado puerto, lo interpreta como "puerto cerrado", lo cual no necesariamente es cierto). Si queremos evitar cualquier tipo de intrusin a nuestro ordenador mediante el escaneo de puertos, la mejor opcin ser utilizar un buen Firewall (o Cortafuego), el cual se encarg de bloquear el envo continuo de paquetes que realizan los escaneadores. Windows cuenta con firewalls desde Windows XP SP2 en adelante.

Direcciones IP y puertos de escucha Cmo configurar Apache para que escuche en direcciones IP y puertos especficos. Cuando Apache se inicia, comienza a esperar peticiones entrantes en determinados puertos y direcciones de la mquina en la que se est ejecutando. Sin embargo, si quiere que Apache escuche solamente en determinados puertos especficos, o solamente en determinadas direcciones, o en una combinacin de ambos, debe especificarlo adecuadamente. Esto puede adems combinarlo con la posibilidad de usar hosts virtuales, funcionalidad con la que un servidor Apache puede responder a peticiones en diferentes direcciones IP, diferentes nombres de hosts y diferentes puertos. La directiva Listen le indica al servidor que acepte peticiones entrantes solamente en los puertos y en las combinaciones de puertos y direcciones que se especifiquen. Si solo se especifica un nmero de puerto en la directiva Listen el servidor escuchar en ese puerto, en todas las interfaces de red de la mquina. Si se especifica una direccin IP y un puerto, el servidor escuchar solamente en la interfaz de red a la que pertenezca esa direccin IP y solamente en el puerto indicado. Se pueden usar varias directivas Listen

para especificar varias direcciones IP y puertos de escucha. El servidor responder a las peticiones de todas las direcciones y puertos que se incluyan. Por ejemplo, para hacer que el servidor acepte conexiones tanto en el puerto 80 como en el puerto 8000, puede usar:

Listen 80 Listen 8000 Para hacer que el servidor acepte conexiones en dos interfaces de red y puertos especficos, use

Listen 192.170.2.1:80 Listen 192.170.2.5:8000 Las direcciones IPv6 deben escribirse entre corchetes, como en el siguiente ejemplo:

Listen [2001:db8::a00:20ff:fea7:ccea]:80 Consideraciones especiales para IPv6 Cada vez ms plataformas implementan IPv6, y APR soporta IPv6 en la mayor parte de esas plataformas, permitiendo que Apache use sockets IPv6 y pueda tratar las peticiones que se envan con IPv6. Un factor de complejidad para los administradores de Apache es si un socket IPv6 puede tratar tanto conexiones IPv4 como IPv6. Para tratar conexiones IPv4 con sockets IPv6 se utiliza un traductor de direcciones IPv4-IPv6, cuyo uso est permitido por defecto en la mayor parte de las plataformas, pero que est desactivado por defecto en FreeBSD, NetBSD, y OpenBSD para cumplir con la poltica system-wide en esas palaformas. Pero incluso en los sistemas en los que no est permitido su uso por defecto, un parmetro especial de configure puede modificar ese comportamiento. Si quiere que Apache trate conexiones IPv4 y IPv6 con un mnimo de sockets, lo que requiere traducir direcciones IPv4 a IPv6, especifique la opcin de configure --enable-v4mapped y use directivas Listen genricas de la siguiente forma:

Listen 80 Con --enable-v4-mapped, las directivas Listen en el fichero de configuracin por defecto creado por Apache usarn ese formato. --enable-v4-mapped es el valor por defecto en

todas las plataformas excepto en FreeBSD, NetBSD, y OpenBSD, de modo que esa es probablemente la manera en que su servidor Apache fue construido. Si quiere que Apache solo procese conexiones IPv4, sin tener en cuenta cul es su plataforma o qu soporta APR, especifique una direccin IPv4 en todas las directivas Listen, como en estos ejemplos:

Listen 0.0.0.0:80 Listen 192.170.2.1:80

Si quiere que Apache procese conexiones IPv4 y IPv6 en sockets diferentes (es decir, deshabilitar la conversin de direcciones IPv4 a IPv6), especifique la opcin de configure -disable-v4-mapped y use directivas Listen especficas como en el siguiente ejemplo:

Listen [::]:80 Listen 0.0.0.0:80

Con --disable-v4-mapped, las directivas Listen en el fichero de configuracin que Apache crea por defecto usarn ese formato. --disable-v4-mapped se usa por defecto en FreeBSD, NetBSD, y OpenBSD.

Cmo funciona este mecanismo en hosts virtuales Listen no implementa hosts virtuales. Solo le dice al servidor principal en qu direcciones y puertos tiene que escuchar. Si no se usan directivas <VirtualHost>, el servidor se comporta de la misma manera con todas las peticiones que se acepten. Sin embargo,<VirtualHost> puede usarse para especificar un comportamiento diferente en una o varias direcciones y puertos. Para implementar un host virtual, hay que indicarle primero al servidor que escuche en aquellas direcciones y puertos a usar. Entonces se debe crear un una seccin <VirtualHost> en una direccin y puerto especficos para determinar el comportamiento de ese host virtual. Tenga en cuenta que si se especifica en una seccin <VirtualHost> una direccin y puerto en los que el servidor no est escuchando, ese host virtual no podr ser accedido.

COKIES Dnde se guardan? La tabla siguiente muestra dnde guardan las cookies los navegadores de Firefox e Internet Explorer.

Firefox

En un nico fichero, de nombre cookies.txt (Windows) o cookies (Unix), en la carpeta del perfil Firefox del usuario. Para Windows XP, por ejemplo, esta carpeta est en C:\Documents and Settings\[usuario]\Datos de programa\Mozilla\Firefox\Profiles. Un slo fichero almacena todas lascookies del usuario. Nota: normalmente, la carpeta Datos de programa no se muestra, porque Windows XP est configurado por defecto para no mostrar archivos y carpetas ocultos. Depende del sistema operativo Windows. Para el Windows XP, normalmente se encontrarn en una carpeta Cookies, dentro de la carpeta de configuracin local del usuario (C:\Documents and Settings\[usuario]\Cookies). En esta carpeta, existe un fichero de extensin .txt para cada cookie. Su nombre tiene la forma[usuario]@[dominio.txt], donde dominio es la direccin de la mquina o bien el directorio (si es que no es el raz) desde donde se envi la cookie.

Internet Explorer

Debido a que las cookies se almacenan en memoria hasta que se cierra el navegador, (momento en que se escriben en el fichero), no es posible ver qu cookies se han aceptado durante la sesin en curso hasta que se sale (salvo que se utilice alguna extensin del Firefox para mostrarlas). Sin embargo, escribiendo el siguiente comando en la barra de direcciones: JavaScript:alert(document.cookie); Aparecer un cuadro con informacin sobre las cookies que se estn utilizando en ese instante. Esto no funciona con Microsoft Internet Explorer. Qu guardan las cookies? Cada galleta representa una pequea porcin de informacin que se aade al fichero de cookies con el siguiente formato:

Set-Cookie: [nombre]=[valor]; expires=[fecha]; path=[camino]; domain=[dominio]; secure

nombre valor expires fechaCaducidad dominio

Nombre del dato almacenado. Valor del dato almacenado. = Parmetro opcional que indica el tiempo que se conservar la galleta. Si no se especifica, la cookie se destruye cuando el usuario sale de la sesin en curso. El navegador devolver la cookie a todo host que encaje con el nombre de dominio parcial. Si no se especifica ningn dominio, entonces el navegador slo la devolver a la mquina que la origin. Adems, este atributo viene acompaado de un flag que indica si todas las mquinas dentro del dominio especificado pueden acceder a la variable. El navegador contrasta este atributo con la URL antes de devolver la cookie. Slo es devuelta cuando se abren documentos de URLs que contengan el valor de este atributo en el path. Este atributo indica que la galleta slo ser transmitida a travs de un canal seguro con SSL.

camino

secure