FAQ de es.comp.hackers! Imprescindible!!! - Sección 9: Hacking

9.0) ¿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.

9.1) ¿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∞

Adicionalmente tenemos el siguiente texto:

BOLETIN N° 9 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 cónsola 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.

3-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.

9.2) ¿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.

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

---

ataques 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.

---