| |||||||||
Hacking
¿Cómo puedo obtener la clave del Administrador en un Windows NT/2000? Ante todo aclaremos que no hay recetas mágicas. Dado que lo usual es que no se tiene acceso a los DC, lo ideal es utilizar un sniffer para capturar los hashes de los passwords de los usuarios directamente desde la red, para luego hacer un proceso de crackeo off-line. Un reconocido crackeador de passwords de Windows es el programa L0phtcrack (www.l0pth.com), que no solamente permite hacer el proceso de crackeo, sino que además incorpora un sniffer dentro del mismo paquete. En caso de tener acceso a los DC, puede intentarse el uso del programa pwdump2 (www.webspan.net/~tas/pwdump2/), que inserta su código dentro de un programa en RAM con privilegios administrativos, y realiza un vuelco de la SAM, en forma de texto, a la pantalla. Luego este archivo puede utilizarse conjuntamente con el L0pthcrack para crackear los passwords Todo lo antedicho funcionará sobre Windows NT, y sobre Windows 2000 solamente sobre aquellas cuentas que NO se encuentren almacenadas en AD.
¿Cómo pueden violar la seguridad de mi servidor NOVELL? Existe un FAQ (en inglés) al respecto en www.nmrc.org/faqs/netware/index.html
Forma de Crackear los Password en un servidor Netware Existen varias formas de lograrlo, por defecto se asume que la opción de Intruder Detection está Off, también que la opción unencryted password está habilitada y por último que existe la posibilidad de plantar un programa Password Catcher..... La funcionalidad de Intruder Detection On es proteger el servidor contra los ataques de los programas Sniffers...los cuales pueden ser introducidos vía ftp, telnet o en servidores www o a través de un e-mail al Webmaster del Intranetware.... Novell ha facilitado a los administradores de red formas para controlar estos ataques...Las últimas versiones del programa LOGIN:EXE encriptan los paswords antes de transmitirlos por el medio (cableado), el administrador debe asegurarse en tener las últimas actualizaciones de dicho programa. En versiones anteriores de shell tal como NEXT (para mantener compatibilidad con viejas estaciones de trabajo) se debe colocar la siguiente instrucción en la consola o en el archivo AUTOEXEC.NCF: Por defecto está Off después que se realiza la instalación. Si el Craker tiene acceso remoto a la consola puede resetear los passwords con los siguientes NLM: MODULO NLM Cuenta Netware version(s) supported Se puede plantar un programa password catcher o un lector Keystroke para obtener los passwords cuando los usuarios hagan login a la red. El programa LOGIN.EXE está localizado en SYS:LOGIN y normalmente está protegido contra los accesos no autorizados. El sitio más apropiado para que los Crackers coloquen uno de éstos programas de captura de password es en una estación de trabajo con el atributo Hidden habilitado (puede ser de forma remota). La desventaja para el administrador es que Netware ni se enterará de la existencia de ese programa. Existe una ubicación aún mejor para el Cracker, que puede ser una máquina de acceso común, tal como PcAnywhere utilizada para acceso remoto. En muchas instalaciones se permite que PcAnywhere tenga acceso a las demás máquinas clientes de la red y solo confiando en las caraterísticas de seguridad ofrecidas por Netware.
Crackear con el SETPWD.NLM Vía RCONSOLE, se pueden cambiar los password en SYS:SYSTEM de la siguiente forma: Para Netware 3.1X LOAD [SYS:SYSTEM]SETPWD [username] [newpassword] Para Netware 4.XX y 5 LOAD [SYS:SYSTEM]SETPWD [username] [newpassword] Si el servidor tiene replicación, entonces el Cracker tendrá acceso a todos los servidores. Tomado de: Anti Online y New Order magazines. Probado en: Laboratorio de AAIAA C.A.
¿Cómo pueden violar la seguridad de mi servidor UNIX/Linux? Si descontamos el caso de un ID de usuario conocido que tenga su password nulo, igual al user ID, o la palabra 'password', necesitaremos hacer una investigación preliminar. Lo primero sería colectar cuanta información sea posible sobre el sitio en cuestión. Podemos consultar catálogos para obtener direcciones de email, páginas web, grupos de noticias, la base de datos que contenga las direcciones IP asignadas a ese sistema (ARIN, RIPE, APNIC), el registro de dominio (InterNIC), etc. Luego puede hacerse un escaneo de los puertos para conocer los servicios disponibles e intentar averiguar el tipo y versión de los mismos. Por ejemplo, si está corriendo un servidor web en el puerto 80, podemos averiguar su versión de la siguiente forma: $ telnet dirección_IP 80 Entre los headers de la respuesta tendremos el tipo (Apache, IIS, etc.) y la versión (por ej. IIS 4.0), salvo que el servidor esté configurado para no brindar esta información (lo cual es una excelente idea, hay que consultar la información del servidor para aprender cómo se configura este comportamiento). De forma similar, utilizando telnet o netcat, podremos informarnos sobre los distintos servicios disponibles. Conociendo el tipo y versión de los servicios, podremos buscar xploits en alguno de los sites mencionados en el punto 18.0, hacer pruebas del xploit en nuestra LAN de pruebas, y una vez conocidos los detalles aplicarlo al site destino. Si tenemos acceso mediante login local como usuarios comunes, el mecanismo es similar pero aplicando xploits locales, que son más abundantes. Dado que cada sistema estará configurado de manera diferente, con diferentes versiones de los servicios configuradas de variadas formas, no puede aplicarse una receta más específica (no hay soluciones mágicas), pero cabe destacar que el peor enemigo del administrador UNIX/Linux es la configuración por defecto, que no suele ser la ideal en prácticamente ninguna distribución.
¿Cómo y dónde debe reportarse un incidente serio de seguridad? El texto "Steps for Recovering from a UNIX Root Compromise", disponible en www.cert.org/tech_tips/root_compromise.html y el RFC-2196 "Site Security Handbook" discuten procedimientos a aplicar en el caso de un compromiso serio de seguridad en el sistema Los motivos para reportar incidentes pueden ser:
Los tipos de incidentes a reportar pueden ser (lista no excluyente): Aataques DoS (Denial of Service)
Usualmente los incidentes se reportarán a:
La información que debe proveerse para ayudar a responder al incidente es (tomar en cuenta que puede terminar en manos del atacante en ciertos casos):
Qué deseamos que la persona informada haga al respecto (solucionar un error, confirmarlo, explicarlo, monitorear la red, informarse al respecto, etc.) Dicho todo esto, cabe aclarar que no hay que avisar incidentes si os aparecen tres cartelitos seguidos en el Zone Alarm o si os están haciendo un ping, esto es para cosas más serias. Extraído de es.comp.hackers
>>> Volver a la portada de underground & seguridad |
ContenidosArtículos
| ||||||||
| |||||||||
