Volver al Web de Duiops

Portada - Hacking

Hacking


Atrás ] Siguiente ]

¿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:

SET ALLOW UNENCRYPTED PASSWORDS=ON

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
------------ ----------------- ----------------------------
SETSPASS.NLM SUPERVISOR 3.x
SETSPWD.NLM SUPERVISOR 3.x, 4.x y 5
SETPWD.NLM cualquiera 3.x, 4.x y 5

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
HEAD / HTTP/1.0
{presionar ENTER un par de veces}

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:

  • Detener escaneos
  • Ayudar a proteger a otros (aunque nosotros estemos seguros, otros no lo están)
  • Informar a los administradores del sistema o la red
  • Recibir confirmación del ataque (a veces algo parece un ataque y resulta que no lo es)
  • Incrementar las precauciones y el monitoreo por parte de todos los involucrados

Los tipos de incidentes a reportar pueden ser (lista no excluyente):

Aataques DoS (Denial of Service)

  • Intentos de reconfigurar nuestro sistema (envenenamiento del DNS, cambio de las tablas de ruteo, intento de reconfiguración de nuestras interfaces de red mediante SNMP, etc.)
  • Intentos de obtener información sobre nuestra topología de red y la configuración de nuestras interfaces
  • Intentos de login en cuentas locales
  • Intento de acceso a archivos no accesibles al público
  • Intento de uso de servicios privados
  • Intento de almacenar archivos en nuestro disco duro
  • Intento de colgar nuestros sistemas
  • Intento de explotar vulnerabilidades conocidas y específicas

Usualmente los incidentes se reportarán a:

  • Root, postmaster, o abuse en el sitio atacante
  • Coordinador de las direcciones de red (puede averiguarse en ARIN para América, RIPE para Europa, APNIC para Asia y la región del Pacífico, y en NIRPNET para sitios .mil)
  • Abuse en nuestro ISP
  • CERT o por email a cert@cert.org
  • El proveedor de nuestro sistema operativo (de tratarse de la explotación de una falla del mismo, la mejor de las suertes con Microsoft)

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):

  • Nuestra dirección de email
  • Nuestro número de teléfono, de considerarse apropiado
  • Nuestra dirección IP, hostname, y nombre del dominio
  • La dirección IP y hostname del atacante, si están disponibles
  • La fecha y hora del incidente (aclarando nuestra zona horaria respecto del GMT)
  • Una descripción del ataque
  • Una explicación de cómo detectamos el ataque
  • Logs del sistema demostrando el incidente
  • Una descripción del formato de los logs del sistema
  • Referencias en Internet relativas al ataque utilizado (por ejemplo ID en el CERT, ID en BugTraq, etc.)

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

Atrás ] Siguiente ]

 

>>> Volver a la portada de underground & seguridad

Contenidos

Hacking, cracking y otras definiciones
Seguridad de sistemas
¿Qué se necesita para ser un hacker?
Firewalls
Virus y Antivirus
Troyanos y Antitroyanos
Spyware
Servicios
IP y conexiones de red
Hacking
Estándares de la red
Web
Correo Electrónico
Grupos de noticias
Passwords
Criptografía y Esteganografía
Norton Ghost
Arquitecturas y sistemas operativos
Referencias en Internet

Artículos

Soy un hacker. Mi presentación
Vocabulario 1.0
Hacker vs. Cracker
Vocabulario 2.0
Troyanos
Parties
Ordenadores en el cine

 

Apúntate a la lista de correo del Web de Duiops

 



© 1997-2009 Duiops (
http://www.duiops.net)
Prohibida la reproducción parcial o total de los textos o las imágenes

Para comentarios, usa las direcciones e-mail de contacto