martes, 24 de julio de 2012

Nmap información sobre RDP

Como siempre, os comento un breve script útil en NMAP para detectar información  de cifrado y capa de seguridad sobre servidores RDP.
El piano es sencillo,  pero muy útil para preparar/argumentar ataques MITM sobre todo en auditorías internas. Os dejo el link oficial que se expresa mucho mejor que yo.
https://svn.nmap.org/nmap/scripts/rdp-enum-encryption.nse

Básicamente, por lo que alcanzo a comprender, hace lo mismo que este plug-in de nessus:


Hacking as a career...

Leyendo la fabulosa entrevista que ha hecho el compañero de http://www.seginformatica.net/2012/07/tenemos-lorenzo-martinez-por-un-ratito.html  al sr. Lorenzo Martinez de SbD me ha llamado la atención un comentario que ha hecho sobre la pregunta de como iniciarse en el mundo de la seguridad informática y he decidido escribir sobre ello. Gracias a los dos por vuestros proyectos...

Todos los que nos dedicamos, trabajamos o soñamos con la seguridad informática, seguro que coincidiréis conmigo en que muchas veces te preguntan: como puedo ser un hacker? como puedo especializarme en seguridad informática? por supuesto que no voy a hablar de "como hackear hotmail". El Sr. Cheman Alonso ya habló de eso hace unos dias. Voy a intentar expresar lo que pienso sobre este tema.
Ser hacker o un experto, o técnico en seguridad informática es algo que no se aprende en los libros, o mejor dicho, solo en los libros. Hoy en día hay en el mercado gran cantidad de certificaciones de seguridad, orientadas a aspectos puramente técnicos, otras dedicadas a la gestión, medición. No soy amigo de este tipo de certificaciones, aunque como luego comentaré, si lo soy de certificaciones de fabricantes de productos, y por eso me las saco !!!.
Os pongo un ejemplo. Te apuntas a un master en seguridad informática, o peor aun !!! te apuntas a un curso de esos que te prometen certificarte como, por ejemplo, Certified Ethical Hacker, en una semana !!!!! bien, pasas el examen, apruebas, te ponen unas pegatinas, pines y demás. Entras a trabajar a una empresa como responsable de seguridad, o como dicen los "modernos" CSO. A los 15 días sale una vulnerabilidad publicada en un blog de un chico de 16 años, que despues de tirarse todo el fin de semana castigado en su casa por no haber fregado los platos en su casa, descubre y programa, que tira "noseque" server, que además lo tienes implantado en tu empresa, y tienes la mala suerte de que algun "juacker" te encuentra, conoce el blog del chico que no friega... y te lia un pollo del 500 en tu organización. De que te sirve la certificación????.
La seguridad informática es la punta del Iceberg de los sistemas, por lo que para ser un buen profesional debes tener amplios conocimientos en:
  • Sistemas operativos. Recomiendo a los estudiantes que si quieren marcar la diferencia respecto a los 100/200/500 compañeros de facultad que se gradúan en tu ciudad que se estudien una certificación en su sistema operativo favorito. Esto no garantiza que seas un experto, NI MUCHO MENOS, eso te lo dará tu experiencia y valía, pero es un punto interesante de obtener los conocimientos necesarios para operar con estos S.O´s, y que mejor manera de la mano del fabricante.
  • Networking. Esto es como aprender a hablar, para poder escribir... Tienes que conocer de pe a pa el funcionamiento de la redes, sus protocolos, su diseño, implementación, seguridad teórica, etc. Hubo un tiempo en los que me estudiaba casi todos los RFC´s que me cain por las manos. Es de locos, y aburrido para un novicio, estudiarse el protocolo DHCP, ya que es algo muy técnico, y esta lejos de poder hackear el ordenador del vecino, que es realmente lo que nos motiva xD, pero es necesario conocer el funcionamiento, en mayor o menor medida, para poder usar las herramientas, exploit´s, conceptos etc.
  • Programación. Como os comentaba antes, la seguridad informática es la punta del iceberg de los sistemas. Nos apuntamos a nuestras carreras en la rama de sistemas porque nos gustan los sistemas, y ahora resulta que hay que saber programación... pues si !!!. No hace falta que seas un experto en .net, java, pl-sql, perl y demás, pero si al menos haber hecho el Hola mundo en todos estos lenguajes... y un poquito mas. Probar pequeños programas para nuestras rutinas diarias, y ser capaces con ello de leer un código fuente, modificar un script, crear un fuzzer para una aplicación concreta de un cliente que necesita auditar, y poder encontrar un Zero Day...
  • La comunidad en internet. Abro un punto y aparte.
Como empecé este post, leyendo la entrevista de Lorenzo Martinez en http://www.seginformatica.net me llamó la atención su comentario sobre RSS. Es VITAL mantenerte al día en el "world guay web", para saber los fallos de seguridad que aparecen en el panorama, para saber las contramedidas, para conocer los proyectos que llevan a cabo colegas de profesión, para saber que libros están marcando la diferencia, para saber que proveedores funcionan o no, etc.
En mi caso, y en el de la mayoría de los colegas, usamos pc´s en las oficinas, móviles, tabletas y demás dispositivos con acceso a internet. Como organizar esta cantidad de información para poder darle forma a todos los conocimientos que vamos obteniendo?.
Como es mi workflow de información? Me levanto, aprovecho 10 minutos en el baño para leer en mi fabuloso Ipad para leer el RSS. Cuando encuentro algún articulo interesante, teórico o práctico, que hago?? !?!?!?! estoy en el baño !!! y como lo deje pendiente para mi laboratorio...puede dar las uvas. Me mando un correo a mi mismo, con el asunto "Teoría" o "Practica".  En la oficina, y delante de mi Personal Information Manager favorito tengo habilitada una regla de correo y unas carpetas, y en cuanto me llega el correo se va a su carpetita correspondiente. Salgo a desayunar con los compañeros, y aprovecho los momentos de empanada que no me interesa la conversación para meterme en Twitter , y lo mismo, repasar los post que más me interesan, y para el correo !!! usando la misma técnica Jedi del asunto...
Cuando llego a casa, pues si tengo ganas de leer, me meto en mi Outlook, en mi carpeta de "teoría" y me leo el articulo. Si lo que quiero es ponerme con las máquinas virtuales manos a la obra, pues lo mismo, tiro de carpeta "practica". Parece una tontería, pero me ha costado cierto tiempo acostumbrarte a esta rutina de trabajo, porque si dejas para la memoria meterte en tal blog para hacer tal cosa, pues pierdes mucha información.
Otras veces me preparo en pdf ( impresora pdf...) artículos buenos que veo por la web, para tenerlos bajados en mi Ipad/Iphone, para los momentos que me voy a la playa, montaña, casa de suegros xD y no hay mucha cobertura.
Cuando leo en algún post, tweet, web o cualquier termino de estos... alguna referencia a algún sitio, persona, web, que me interesa seguir, me mando un correo a mi mismo con el asunto "para rss". así sé cuando tenga un rato, tengo añadir a mi lector de Rss tal fuente. Por qué "al rato" y no al momento, muy sencillo. La mayoría de los blog´s detectan el User-agent del dispositivo IO´s, y cambian la url del feed con un prefijo "mac" que mi lector RSS no detecta, por lo que tengo que "averiguar" la dirección del RSS en mi navegador de escritorio para poder importarlo en mi RSS...
Muchos pensareis que es una tontería todo lo que estoy diciendo, pero es mi manera de mantenerme al día, probar las cositas que salen, y no dejarme nada en el tintero. Muchas ideas se nos ocurren como he dicho en la taza del wc, de camino en coche, o en desayuno en la oficina, y por qué perderlas !!!.

Ahora bien, un poco de chicha: a riesgo de olvidarme de alguno, en mi blog tengo unos links hacia los Blogs/web´s en castellano que sigo. En ingles os recomiendo estos, que me he molestado en publicar en formato RSS para que solo tengáis que agregarlos.
Como siempre, gracias por leerme, y si considerais que debéis estar en mis links en castellano, o queréis recomendarme algún blog de algún "loco por la seguridad" como nosotros, adelante !!!.












































Google +

miércoles, 18 de julio de 2012

Firewall para WEB, WAF !!!! cositas...

Todos, o "casi todos" tenemos un firewall en nuestras empresas... algunos tenemos un IDS como el cerdito rosita, para detectar comportamientos anómalos en nuestra red. Si tenemos un servidor web, casi seguro que tendremos el firewall abierto en el puerto 80 y el 443, entonces que !!! El IDS suele estar configurado para procesar los paquetes de nuestra red, pero suele ser lento el proceso de lectura de HTTP, y un poco mas si va sobre SSL.
Como protegemos nuestras web´s de los tán conocidos ataques de SqlI, XSS y demás?, Pues con un firewall specífico de aplicaciones web :-)  ( aquí el que no encuentra solución  a sus problemas es porque no quiere, no lee, o no paga xD ).
Pueden ser Hardware o Software, desplegada como un dispositivo de red, o un modulo en el propio servidor ( famoso modsecurity para Apache).
Las principales funciones de un WAF, para mi son:
  • Unificación de log´s entre varios servidores.
  • Bloqueo de url´s origen o incluso Ip´s.
  • Protección clásica mediante reglas de los típicos ataques web ( la palabra Select debe estar permitida en url´s en tu aplicación????'  o UNION ????   ).
  • Parcheado virtual de servidores, definiendo en el WAF las reglas de filtrado, en vez de parchear directamente el core del servidor o modulo.
Como en anteriores post sobre este tipo de dispositivos, recomiendo que si tenemos un WAF como punto de entrada a nuestros servidores web, si cae la tenemos liada... para eso se recomienda montar una infraestructura en cluster, o al menos sobre un servidor don bypass automático y dos tarjetas de red, para que en caso de caida, no se interrumpa el servicio web ( aunque si el servicio que lo protege).

BASICO que le peguéis un repaso a Web Application Firewall Evaluation Criteria para tener un vistazo rápido al panorama WAF.
Otra charla muy buena, de la mano de OWASP sobre el asunto está disponible just here. Del mismo autor que la herramienta Wafwoof.
Ubicación en Backtrack y la compleja linea de comandos de uso:















Como siempre, soy un loco de NMAP, y si nmap me lo da, por qué no usarlo?

nmap -p80 --script http-waf-detect dominio/ip.









Otro día nos podemos meter a instalar alguno, con las típicas reglas que se recomiendan, y probamos a hackearlo xD.

Gracias por leerme, como siempre.

Balanceo de carga, conceptos y hacking Part II

Ayer intenté comentar lo poco que se sobre los balanceadores de carga, intentando aclarar unos cuantos conceptos interesantes, bajo mi punto de vista, para saber que es lo que pasa cuando instalamos nuestros NLB.
Hoy voy a intentar documentar las herramientas que se suelen usar en los test de intrusión, en las fases de enumaración de objetivos.
Dentro del marco de un trabajo de pentest, es interesante comprobar si los servidores objetivo están detrás de un NLB, ya que podemos tener varios servers, alguno de ellos sin pachear. Una idea interesante sería auditar los servicios web de un objetivo un dia antes del ciclo de actualizaciones mensuales, en el caso de Microsoft, y unas horas después de la aparición de la actualización.
Al lio. En nuestras Backtrack encontramos un script llamado Load Balancin Detector, ubicada en :
/pentest/enumeration/web/lbd/. Lanzamos el script con el dominio a analizar, y tenemos el resultado.







Otra herramienta muy interesante para contrastar la información es Halberd. La instalación es muy sencilla, tal y como indica la web del propietario, simplemente nos bajamos el tar.gz, lo descomprimimos e instalamos con: python setup.py install. el comando básico es : Halberd "dominio".


Tal y como comentábamos en el anterior, hay muchas maneras de detectar la presencia de un NLB. Esta herramienta realiza estas comprobaciones en base a:
  • Hora que muestra el servidor, que debe ser distinta entre peticiones lanzadas al mismo tiempo.
  • Cabeceras MIME.
  • Generando tráfico, para obligar al NLB a balancear la carga.
  • Enviando peticiones de URL´s aleatorias, para comparar los resultados.
  • Detección de cache´s del servidor bajo entornos proxy como Squid.
  • Leyendo cookies o campos MIME que puedan identificar IP´s públicas reales.
Las opciones personalizadas, que recomiendo repasar al menos, son estas.

Buscando un poco de información al respecto por la world wide encontré este magnifico articulo del señor @z0mbiehunt3r/ sobre un script que ha desarrollado para este mismo propósito. Sin duda os recomiendo repasar el articulo y darle cera al asunto.
Para poder correrlo en mi máquina backtrack, he tenido que:
apt-get install python-git python-pip
pip install argparse

***Tengo que dar las gracias al Sr. cazador de zombies por el soporte que me ha dado a la hora de resolver unas librerias, ya que mis conocimientos sobre el lado oscuro estan mas oscuros que nunca. GRACIAS DE CORAZON***

Espero que os guste y comentéis vuestras impresiones. Gracias por leerme.






martes, 17 de julio de 2012

Balanceo de carga, conceptos y hacking... Part I.

Cuantos servidores mantienen el dominio Microsoft.com? creéis que es un solo servidor, con millones de gigas de ram, para dar servicio a todos sus visitantes? cada vez que se les queda pequeño, lo tiran y compran otro? Imagino que harán un desarrollo horizontal, en el que en vez de crecer de gigas de ram, por ejemplo, se añade un servidor mas. Debe haber una máquina que gestiones las conexiones, y que diga, esta para ti, esta para el otro... Hay muchos tipos de balanceo, que voy a intentar explicar. Hay que tener en cuanta un aspecto básico a la hora de implementar un balanceador. Si tenemos 10 servidores web, Apache, y montamos un LBN para gestionar las peticiones de manera eficiente, y se nos cae el balanceador, tiramos por tierra nuestra gestión TI ya que ni para uno, ni para otro. Hay que montar una contingencia para el caso de caídas del balanceador.
El típico modo de balanceo siempre ha sido Round And Robin DNS, lo que hace es que lanza las peticiones una vez a un servidor, otras veces a otro. El problema de este método es que si bien reparte peticiones, no reparte cargas. Por ejemplo, petición A se encamina a server A, la siguiente petición B se encamina a server B. La siguiente petición C irá a server A, pero que pasa si la conexión A requiere mucho proceso en el servidor, o mucho tráfico, y la petición B, en el momento de realizar la petición C, ya ha sido terminada?.
Como gestiona los NBL los servidores que tienen detrás a su cargo. Pues sencillo, si como siempre has estudiado teoría de redes, como siempre recomiendo.
En capa 2 del nivel OSI el NBL envía solicitudes ARP o consulta en su tabla para determinar las Mac´s-ip de los dispositivos. En capa 3 del nivel OSI el NBL hace una solicitud ICMP para comprobar si está vivo el servidor. En capa 4 del nivel OSI el NBL hace un TCP syn al puerto deseado en la petición, por ejemplo al puerto 80 de un servidor interno, o como es interno, y en nuestra casa podemos hacer lo que queramos, el que sea. Espera un TCP syn ACK.
Hay appliance o sotwares NBL que realizan estas comprobaciones en nivel OSI capa 7, por ejemplo hacer una peticion HTTP para comprobar la disponibilidad del server en base a su respuesta. Lo mismo para balanceadores FTP. Cuantas mas pruebas de salud realicemos, mas lento ira el balanceador, por lo que se recomienda realizar todas las comprobaciones, en otro server, y que este le pasa la información de "disponible o no disponible". por ejemplo, tener un servidor linux configurado con unos scripts que realicen las comprobaciones, y que devuelva unos cuantos códigos de estado al balanceador es una buena idea. Estas "integraciones" casi siempre son posibles si realizamos el NBL por software, ya que si lo realizamos con un Hardware pues dependemos del fabricante...
Mas cosas interesantes, sesiones !!. Pongamos por ejemplo, una compra de cualquier comercio on-line. No solo se establece una conexión TCP simple, sino que son numerosas, y a distintos sitios ( como por ejemplo al pagar, conectarnos a la pasarela de pago mediante una conexion segura con puerto TCP distinto). Hay que tratar el concepto de transacción, ya que no nos vale con tener una conexión TCP única, sino el conjunto de conexiónes. Todo debe ir con el mismo session ID. A este concepto se le llama Session Persistence ( El NBL debe saber el usuario en cuestion, y cuando empieza/acaba el conjunto de transacciones). Según el NBL, se puede identificar el Session Persistence de dos maneras, una mucho mas efectiva y costosa (computación) que la otra. Mediante Ip/puerto de origen el NBL puede redirigir todas las conexiones hacia el mismo servidor, hasta tener un TCP FIN o reset. Esta manera en sencilla, pero puede ser poco efectiva, por ejemplo, si el cliente del NBL es un proxy. Otra manera de establecer la persistencia es mediante Cookie. Cookie de lectura es mas sencilla de implementar, porque el NBL solo "leerá" la cookie, que previamente debe identificar el servidor web ( meter en la cookie que emite, un campo con el identificador interno del server, para que el NBL sepa con quien trabajar esa conexion).
Ahora viene la complejidad del asunto, hemos repasado los aspectos básicos de los NBL, a modo introductorio. Ahora toca ver los fabricantes de NBL como implementan estas soluciones, si mediante "siguiente,siguiente, siguiente" o lo que sea. Bien, como montaríamos un cluster de firewalls balanceados? Recuero que en anteriores post hablamos de los Firewall´s statefull, que guardan el estado de las conexiones, etc, pues montar un NBL de firewall´s TELA MARINERAAAAAAAAAA. Pero ya sabeis que en entornos complejos, no se van a quedar sin firewall porque tengan que actualizarlo, o porque se ha roto...
Os dejo tranquilos por hoy con los NBL, y mañana os comentaré las herramientas que tengo en mi lista para detectar si nuestros objetivos están bajo un NBL o de que tipo es.
Gracias por leerme !!!!

viernes, 13 de julio de 2012

Vpn´s ??? eso que e lo que e !!!

Todos usamos este termino, cuyas siglas significan Virtual Private Network. Todos sabemos mas o menos que son, pero por "debajo" se emplean muchos términos que a veces no están tan claros. No todas las VPN son iguales, en cuanto a rendimiento y sobre todo seguridad. Hay muchos tipos de protocolos de autenticación, encriptación, encapsulamiento, etc. Si bien este post no es muy técnico ( acaso en este blog hay alguno? xD ) ni tan siquiera está enfocado al aspecto de la seguridad, guarda cierta relación con el proposito del blog.
Empezamos definiendo una VPN como una conexión de redes, generalmente dos redes privadas ( casa-trabajo, trabajo-trabajo, proveedor-trabajo...) por un medio público que generalmente es Internet. A veces las VPN son conexiones punto a punto entre segmentos de red, y otro tipo de "deployment´s" de las mentes oscuras de los informáticos de sistemas. Una definición mas formal: VPN-WIKI.
El principal concepto en el que se basan las VPN es el tunneling. El proceso de encapsular un tipo de paquete, dentro de otro, para el transporte del primero, el cual se encarga de negociar el esquema de cifrado y autenticación del transporte. Por ejemplo, si queremos usar un servicio FTP, este protocolo carece de seguridad respecto al viaje de paquetes por la red (cifrado) y el mecanismo de autenticación es en texto claro ( debil ante ataques Man In The Middle).
Para montar una VPN, calificándola según los elementos que la proporcionan, se pueden dividir en 3:
  • VPN basada en Hardware. Suelen ser las soluciones más rápidas, ya que se aprovecha toda la capacidad del sistema hardware en proporcionar el acceso VPN, y no en tareas comunes de cualquier sistema operativo.
  • VPN basada en Firewall. Puede que sean un poco mas lenta que las soluciones basadas en Hardware exclusivo para VPN, pero tienen la ventaja de aprovechar el resto de funciones del firewall como son el NAT, aislado de redes etc.
  • VPN basada en Software. Estas soluciones suelen ser las más peligrosas, ya que hay que controlar la seguridad del propio servicio VPN, así como la seguridad del sistema operativo que la soporta. Sin duda es más económica.
El protocolo propio de las VPN es PPP, Point To Point Protocole. El flujo básico de este protocolo es el siguiente:


La autenticación necesaria tal y como la vemos en el esquema, la proporcionan los protocolos:
  • PAP. Password Authenticaction Protocol.
  • CHAP. Challenge Handshake Authentication Protocol.
  • MS-CHAP v1 ( Microsoft Challenge Handshake Authentication Protocol).
  • EAP. Extensible Authentication Protocol.
  • EAP-TLS. Transport Layer Security.

Como empezábamos el post, los protocolos de Tunneling son los siguiente ( yo de toda la vida pensé que la T de tunneling era de Transfer... según autores):
  • PPTP. Point To Point Tunneling Protocol.
  • L2TP. Layer 2 Tunneling Protocol.
  • SSTP.- Secure Socket Tunneling Protocol. Después de haberte empapado con el RFC, cabe destacar que la mayoría de organizaciones implementan este tipo de soluciones, las tipicas "vpn sobre https" ya que permite conectar clientes mediante un navegador, sin la necesidad de instalación previa de clientes IPSEC por ejemplo. Particularmente me parece mucho menos seguro, ya que trabaja con capa 4 de red, y no con capa 2 como los otros dos protocolos, por lo que no es fiable al 100% en entornos en los que es posible realizar un ataque MITM.
Hemos hablado de protocolo de autenticación, y de túnel, pero y el cifrado?
Todos conocemos SSL y SSH, protocolos de cifrado CAPA 4.
En entornos altamente protegidos no es ni siguiera imaginable que el administrador se conecte desde su casa por ssh a la empresa, por eso mismo, porque actúa en capa 4, y por lo tanto es vulnerable a ataques MITM. Una desventaja frente a la utilización de VPN´s es que las aplicaciones tienen que estar preparadas para trabajar con este cifrado. Por ejemplo, si en nuestra intranet no tenemos https para sharepoint, por decir algo, para usar SSL entre nuestra casa y la intranet, debemos usar https, y preparar el servidor web para ello. Muchos administradores configuran, sobre todo Apache´s, con https, sin tener ni idea de como montar un Certificate Server, y usan las opciones por defecto para crear estos certificados...
La solución Microsoft para el cifrado dentro de las conexiones VPN es Ipsec ( tambíen para el cifrado interno en nuestra red)
Las recomendaciones de seguridad a la hora de analizar los protocolos a implementar son muy importantes. El protocolo mas seguro respecto a la autenticación es sin duda EAP-tls,sobre tarjetas, pero esto requiere la implantación de PKI, ya sabeis, entidad emisora de certificados y esas cosas que tanto nos gustan a los que sufrimos en nuestras carnes algún proceso de certificación de fabricante. Si se decide usar cualquier otro protocolo basado en contraseñas, debe ser importante la política de seguridad de las mismas ( caducidad, bloqueo, complejidad, etc).

Creo que hasta aquí, no he comentado nada nuevo, que los estudiosos en la materia no conocieran desde hace 10 años o más.
Sin embargo, desde hace relativamente poco... se emplean protocolos de cuarentena. Estas tecnologías verifican que los clientes cumplen con los requisitos de seguridad marcados por la organización ( políticas de firewall, actualización, definición de virus, etc).
Los trés que mas suenan son:
  • NAP. Network Acces Protection. Microsoft.
  • NAC. Network Admision Control. Cisco.
  • TNC. Trusted Network Connect.
Seguro que después de indagar en los distintos protocolos, esas cosas que tanto nos gustan, pues todos pensamos en implementar la solución mas robusta, mas segura, mas compleja... pero cuando el comercial se quiera conectar desde un punto público en otro país, y no tenga el cliente ipsec, por ejemplo, pués ya no nos vale el despliegue. Es habitual entre nosotros, los informáticos (sobre todo los que no trabajan en clientes finales) proporcionar las soluciones tecnológicas mas punteras del momento, olvidándonos de que la informática casi siempre es un medio, no un fin. Ninguna empresa cobra mas por tener una mejor VPN, pero si puede ser que cobre mas, si el comercial puede realizar su labor whereverhego.
Los aspectos que creo que hay que considerar a la hora de diseñar una correcta estrategia de implantación son:
  • Volumen. Número de usuarios o delegaciones que se van a conectar, hoy, y a corto y medio plazo.
  • Requisitos de conectividad: Usuarios móviles, delegaciones, partners, etc.
    • Acceso Remoto. Facilidad de conexión.
    • Intranet. Lan to Lan. Típicas delegaciones. Disponibilidad de servicios.
    • Extranet. Lan de empresa con lan de proveedor. Isolation o aislado de servicios publicados.
    • Internos. Vpn a redes wi-fi o segmentos altamente securizados.
  • Costes. Que decir sobre esto. Cisco es el número uno mundial, como puede ser Ferrari en los coches, pero un Bmw no está mal para ir los fines de semana a la playa...y Seat también vale...
  • Recursos. Hay disponible 24 horas al día alguien para dar soporte al partner? Si usamos tecnologías propietarias y poco compatibles, todos los usuarios las cumplen?.
  • Auditoría y control. Podemos garantizar que todos los clientes cumplen nuestras políticas? Tenemos habilitados los mecanismos de control, por ejemplo log´s, para detectar fallos e intentos de accesos fraudulentos.
  • Despliegue. Va a saber mi gerente, que vive a 300 Km. configurar el cliente VPN?
  • Medio público. Tenemos una subida de Internet suficiente? Tenemos que habilitar Quality Of Services para algún servicio o usuario?.
  • Tolerancia a fallos. Una vez que el comercial se acostumbre a rellenar el CRM desde casa, si se cae el sistema un dia, NO VA A IR A LA OFICINA POR CULPA DEL INFORMATICO...
Otro término que se emplea, sobre todo en sistemas ventana, relacionado con la conexión de redes y servicios es VNC.  La autenticación que emplea VNC es en texto claro, como cualquier servicio clásico tipo FTP, Telnet, http etc. En algunos entornos, la longitud de clave máxima está limitada a 8 caracteres...
El cifrado empleado en las comunicaciones es DES, pero la clave siempre es la misma, existiendo numerosas herramientas para la extracción de la misma.

Según el entorno y fabricante, entran en juego numerosas servicios y protocolos añadidos, como es el caso de Radius en los antiguos servidores RAS de Microsoft. No voy a entrar en detalles de la correcta implantación de todos estos protocolos comentados aquí, pero si que voy a puntualizar los aspectos a tener en cuenta, para hacer esto BIEN, dentro de entornos ventana:
El role para instalar todos estos servicios en windows 2008 r2 es: Network Polici and Access Services (Npas).

Espero que esta mini guia te sirva para aclarar algunos conceptos a la hora de implementar una solución remota. En cada link podrás obtener información en detalle de cada aspecto.
Ahora a montar todos servidores vnc abiertos de pe a pa en los routers de jazztel :-).

Exploit-db sin interneteeee....

Una de las cosas que probamos en los pentest es romperlo todo !!! xD y para ello usamos la clásica exploit-db para buscar las versiones de los servicios encontrados, y encontrar algún bug conocido o exploit.
Hay veces en los que puede ser que no dispongamos de acceso a internet en clientes, o que no queramos levantar ninguna alarma en el proxy, o simplemente que nos gusta mas que el interfaz web. Para ello tenemos en las backtrack, o en cualquier distro. que instalemos, la base de datos completa de exploit´s.
Para hacer una consulta, basta con ir a la ubicación del fichero, que en BT es:
/pentest/exploits/exploit-db/  y lanzar: ./searchsploit explorer o cualquier otro término sobre el cual queramos hacer la busqueda. una vez localizado, podemos usar a nuestro gato para ver el contenido, bien sea un script, un txt con los pasos, etc.
Es importante tener en cuenta que si hace 6 meses, o 6 años que instalamos la distro, dudo mucho que por arte de magía se haya actualizado el repositorio de Scripts.
Hace un tiempo encontré este Script que os pego, que ubicado en el lugar correcto, y dándole los permisos de ejecución correctos, descargará y descomprimirá la base de datos entera, todas las veces que os haga falta !!!!.




#!/bin/bash
# Mauro Risonho de Paula Assumpção a.k.a firebits
# firebits@backtrack.com.br
# 03-31-2011 11:08 PM Brazil

echo "================================"
echo "Updating exploits by Exploit-db"
echo "by firebits - firebits@backtrack.com.br"
echo "================================"
wget http://www.exploit-db.com/archive.tar.bz2
tar -xvvf archive.tar.bz2
rm -R archive.tar.bz2
echo "================================"
echo "Done. Exploits updated!!!"
echo "================================"

jueves, 12 de julio de 2012

Nmap básico.

No te ha pasado nunca, que escaneas una ip, con cualquier de nuestras herramientas fabulosas, y dura 1 segundo? No encuentra Host vivos, ni puertos ni naaaaaa de naaaaaaaaa. El otro día hablábamos de las vulnerabilidades en general, y quedó claro que una parte muy importante es la de las técnicas de escaneo. Dependiendo del firewall/ router, sistemas de detección de intrusos y demás, tendremos unos resultados u otros.
Hace unos años, la mayoría de los routers se denominaban Packet Filters, en los que se filtraba en base al origen y el destino. Mucho ha llovido, y en la actualidad casi todos se denominan Stateful Firewall, es decir, que tienen una base de datos de estado de las conexiones, para gestionar conexiones “a medio” flag´s sin el orden adecuado, etc.

Espero que te hayas leido de pe a pa este clásico de las redes: http://www.intercambiosvirtuales.org/libros-manuales/redes-de-computadoras-andrew-s

Pero por si acaso, voy a intentar aclarar unos conceptos sencillos, pero el protocolo TCP y UDP ( por no decir otros) te lo debes saber entero ¡!

Datagrama


0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Puerto de origen
Puerto de destino
Número de secuencia
Número de acuse de recibo
Margen
de datos
Reservado
URG
ACK
PSH
RST
SYN
FIN

Ventana






Suma de control
Puntero urgente
Opciones
Relleno
Datos


Significado de los diferentes campos:
  • Puerto de origen (16 bits): Puerto relacionado con la aplicación en curso en la máquina origen
  • Puerto de destino (16 bits): Puerto relacionado con la aplicación en curso en la máquina destino
  • Número de secuencia (32 bits): Cuando el indicador SYN está fijado en 0, el número de secuencia es el de la primera palabra del segmento actual.
    Cuando SYN está fijado en 1, el número de secuencia es igual al número de secuencia inicial utilizado para sincronizar los números de secuencia (ISN).
  • Número de acuse de recibo (32 bits): El número de acuse de recibo, también llamado número de descargo se relaciona con el número (secuencia) del último segmento esperado y no el número del último segmento recibido.
  • Margen de datos (4 bits): Esto permite ubicar el inicio de los datos en el paquete. Aquí, el margen es fundamental porque el campo opción es de tamaño variable.
  • Reservado (6 bits): Un campo que actualmente no está en uso pero se proporciona para el uso futuro.
  • Indicadores (6x1 bit): Los indicadores representan información adicional:
    • URG: Si este indicador está fijado en 1, el paquete se debe procesar en forma urgente.
    • ACK: Si este indicador está fijado en 1, el paquete es un acuse de recibo.
    • PSH (PUSH): Si este indicador está fijado en 1, el paquete opera de acuerdo con el método PUSH.
    • RST: Si este indicador está fijado en 1, se restablece la conexión.
    • SYN: El indicador SYN de TCP indica un pedido para establecer una conexión.
    • FIN: Si este indicador está fijado en 1, se interrumpe la conexión.
  • Ventana (16 bits): Campo que permite saber la cantidad de bytes que el receptor desea recibir sin acuse de recibo.
  • Suma de control (CRC): La suma de control se realiza tomando la suma del campo de datos del encabezado para poder verificar la integridad del encabezado.
  • Puntero urgente (16 bits): Indica el número de secuencia después del cual la información se torna urgente.
  • Opciones (tamaño variable): Diversas opciones
  • Relleno: Espacio restante después de que las opciones se rellenan con ceros para tener una longitud que sea múltiplo de 32 bits.
Una vez nos hemos empapados de los RFC´s y demás literatura, ya estamos en condiciones de seguir.
El número uno de los scanners de red, como todos imaginais es NMAP. El poder granular todos los aspectos del scanneo, es uno de los motivos por el que recomiendo usar NMAP en vez de otros scanner “integrados” que no solo scanean puertos, sino que scanean vulnerabilidades, pero que no permiten el grado de configuración que esta herramienta nos ofrece.
Otra razon de peso es la facilidad para instalar en cualquier entorno que queramos auditar, sin necesidad de entornos ventanas, recursos, librerías y demás.

Parámetros para el descubrimiento de objetivos de NMAP extraido de su ayuda oficial:

Las siguientes opciones controlan el descubrimiento de sistemas.
-sL (Sondeo de lista)
El sondeo de lista es un tipo de descubrimiento de sistemas que tan solo lista cada equipo de la/s red/es especificada/s, sin enviar paquetes de ningún tipo a los objetivos. Por omisión, Nmap va a realizar una resolución inversa DNS en los equipos, para obtener sus nombres. Es sorprendente cuanta información útil se puede obtener del nombre de un sistema. Por ejemplo fw.chi.playboy.com es el cortafuegos de la oficina en Chicago de Playboy Enterprises. Adicionalmente, al final, Nmap reporta el número total de direcciones IP. El sondeo de lista es una buena forma de asegurarse de que tenemos las direcciones IP correctas de nuestros objetivos. Si se encontraran nombres de dominio que no reconoces, vale la pena investigar un poco más, para evitar realizar un análisis de la red de la empresa equivocada.
Ya que la idea es simplemente emitir un listado de los sistemas objetivo, las opciones de mayor nivel de funcionalidad como análisis de puertos, detección de sistema operativo, o análisis ping no pueden combinarse con este sondeo. Si desea deshabilitar el análisis ping aún realizando dicha funcionalidad de mayor nivel, compruebe la documentación de la opción -P0.
-sP (Sondeo ping)
Esta opción le indica a Nmap que únicamente realice descubrimiento de sistemas mediante un sondeo ping, y que luego emita un listado de los equipos que respondieron al mismo. No se realizan más sondeos (como un análisis de puertos o detección de sistema operativo). A diferencia del sondeo de lista, el análisis ping es intrusivo, ya que envía paquetes a los objetivos, pero es usualmente utilizado con el mismo propósito. Permite un reconocimiento liviano de la red objetivo sin llamar mucho la atención. El saber cuántos equipos se encuentran activos es de mayor valor para los atacantes que el listado de cada una de las IP y nombres proporcionado por el sondeo de lista.
De la misma forma, los administradores de sistemas suelen encontrar valiosa esta opción. Puede ser fácilmente utilizada para contabilizar las máquinas disponibles en una red, o monitorizar servidores. A esto se lo suele llamar barrido ping, y es más fiable que hacer ping a la dirección de broadcast, ya que algunos equipos no responden a ese tipo de consultas.
La opción -sP envía una solicitud de eco ICMP y un paquete TCP al puerto 80 por omisión. Cuando un usuario sin privilegios ejecuta Nmap se envía un paquete SYN (utilizando la llamada connect()) al puerto 80 del objetivo. Cuando un usuario privilegiado intenta analizar objetivos en la red Ethernet local se utilizan solicitudes ARP (-PR) a no ser que se especifique la opción --send-ip.
La opción -sP puede combinarse con cualquiera de las opciones de sondas de descubrimiento (las opciones -P*, excepto -P0) para disponer de mayor flexibilidad. Si se utilizan cualquiera de las opciones de sondas de descubrimiento y número de puerto, se ignoran las sondas por omisión (ACK y solicitud de eco ICMP). Se recomienda utilizar estas técnicas si hay un cortafuegos con un filtrado estricto entre el sistema que ejecuta Nmap y la red objetivo. Si no se hace así pueden llegar a pasarse por alto ciertos equipos, ya que el cortafuegos anularía las sondas o las respuestas a las mismas.
-P0 (No realizar ping)
Con esta opción, Nmap no realiza la etapa de descubrimiento. Bajo circunstancias normales, Nmap utiliza dicha etapa para determinar qué máquinas se encuentran activas para hacer un análisis más agresivo. Por omisión, Nmap sólo realiza ese tipo de sondeos, como análisis de puertos, detección de versión o de sistema operativo contra los equipos que se están «vivos». Si se deshabilita el descubrimiento de sistemas con la opción -P0 entonces Nmap utilizará las funciones de análisis solicitadas contra todas las direcciones IP especificadas. Por lo tanto, si se especifica una red del tamaño de una clase B cuyo espacio de direccionamiento es de 16 bits, en la línea de órdenes, se analizará cada una de las 65.536 direcciones IP. El segundo carácter en la opción -P0 es un cero, y no la letra O. Al igual que con el sondeo de lista, se evita el descubrimiento apropiado de sistemas, pero, en vez de detenerse y emitir un listado de objetivos, Nmap continúa y realiza las funciones solicitadas como si cada IP objetivo se encontrara activa.
-PS [lista de puertos] (Ping TCP SYN)
Esta opción envía un paquete TCP vacío con la bandera SYN puesta. El puerto destino por omisión es el 80 (se puede configurar en tiempo de compilación cambiando el valor de DEFAULT_TCP_PROBE_PORT en nmap.h), pero se puede añadir un puerto alternativo como parámetro. También se puede especificar una lista de puertos separados por comas (p.ej. -PS22,23,25,80,113,1050,35000). Si hace esto se enviarán sondas en paralelo a cada uno de los puertos.
La bandera SYN indica al sistema remoto que quiere establecer una conexión. Normalmente, si el puerto destino está cerrado se recibirá un paquete RST (de «reset»). Si el puerto está abierto entonces el objetivo responderá con el segundo paso del saludo en tres pasos TCP respondiendo con un paquete TCP SYN/ACK. El sistema donde se ejecuta Nmap romperá la conexión que se está estableciendo enviando un paquete RST en lugar de enviar el paquete ACK que completaría el saludo TCP. Nmap no envía este paquete, sino que lo envía el núcleo del sistema donde se ejecuta Nmap respondiendo al paquete SYN/ACK que no esperaba.
A Nmap no le importa si el puerto está abierto o cerrado. Si, tal y como se acaba de describir, llega una respuesta RST ó SYN/ACK entonces Nmap sabrá que el sistema está disponible y responde.
En sistemas UNIX, generalmente sólo el usuario privilegiado root puede enviar paquetes TCP crudos. Los usuarios no privilegiados tienen una forma de evitar esta restricción utilizando la llamada al sistema «connect()» contra el puerto destino. Esto hace que se envíe el paquete SYN al sistema, para establecer la conexión. Si la llamada «connect()» devuelve un resultado de éxito rápidamente o un fallo ECONNREFUSED entonces se puede deducir que la pila TCP que tiene bajo ésta ha recibido un SYN/ACK o un RST y que puede marcar el sistema como disponible. El sistema se puede marcar como no disponible si el intento de conexión se mantiene parado hasta que vence un temporizador. Esta es también la forma en la que se gestiona esto en conexiones IPv6 ya que Nmap aún no puede crear paquetes IPv6 crudos.
-PA [lista de puertos] (Ping TCP ACK)
El ping TCP ACK es muy parecido al ping SYN que se acaba de tratar. La diferencia es que en este caso se envía un paquete con la bandera ACK en lugar de la SYN. Este paquete indica que se han recibido datos en una conexión TCP establecida, pero se envían sabiendo que la conexión no existe. En este caso los sistemas deberían responder con un paquete RST, lo que sirve para determinar que están vivos.
La opción -PA utiliza el mismo puerto por omisión que la sonda SYN (el puerto 80) y también puede tomar una lista de puertos destino en el mismo formato. Si un usuario sin privilegios intenta hacer esto, o se especifica un objetivo IPv6, se utiliza el procedimiento descrito anteriormente. Aunque en este caso el procedimiento no es perfecto porque la llamada «connect()» enviará un paquete SYN en lugar de un ACK.
Se ofrecen tanto mecanismos de sondeo con ping SYN y ACK para maximizar las posibilidades de atravesar cortafuegos. Muchos administradores configuran los enrutadores y algunos cortafuegos sencillos para que se bloqueen los paquetes SYN salvo para aquellos destinados a los servicios públicos, como pudieran ser el servidor web o el servidor de correo de la organización. Esto evita que se realicen otras conexiones entrantes al mismo tiempo que permite a los usuarios realizar conexiones salientes a Internet. Este acercamiento de filtrado sin estados toma pocos recursos de los cortafuegos/enrutadores y está ampliamente soportado por filtros hardware y software. El programa de cortafuegos Netfilter/iptables de Linux ofrece la opción --syn para implementar este acercamiento sin estados. Cuando se han implementado reglas de filtrado como éstas es posible que se bloqueen las sondas ping SYN (-PS) cuando éstas se envíen a un puerto cerrado. Sin embargo, en estos casos, las sondas ACK podrían saltarse las reglas y llegar a su destino.
Otros tipos de cortafuegos comunes utilizan reglas con estados que descartan paquetes no esperados. Esta funcionalidad se encontraba antes fundamentalmente en los cortafuegos de gama alta pero se ha hecho cada vez más común. El sistema Netfilter/iptables de Linux soporta esta posibilidad a través de la opción --state, que hace categorías de paquetes en base a su estado de conexión. En estos sistemas es más probable que funcione una sonda SYN, dado que los paquetes ACK no esperados se reconocen como falsos y se descartan. Una solución a este dilema es enviar sondas SYN y ACK especificando tanto la opción -PS como -PA.
-PU [lista de puertos] (Ping UDP)
El ping UDP es otra opción para descubrir sistemas. Esta opción envía un paquete UDP vacío (salvo que se especifique --data-length) a los puertos indicados. La lista de puertos se debe dar en el mismo formato que se ha indicado anteriormente para las opciones -PS y -PA . Si no se especifica ningún puerto se utiliza el puerto 31338 por omisión. Se puede configurar este puerto por omisión en el momento de compilar cambiando DEFAULT_UDP_PROBE_PORT en nmap.h. Se utiliza un puerto alto y poco común por omisión porque no es deseable enviar este sondeo a otro tipo de puertos.
La sonda UDP debería generar un paquete ICMP de puerto no alcanzable si da contra un puerto cerrado en el equipo objetivo. Si llega éste entonces Nmap puede identificar ese sistema como vivo y alcanzable. Otros errores ICMP, como el de sistema o red inalcanzables o TTL excedido indican un sistema que está muerto o que no es alcanzable. Si no llega ninguna respuesta también se entiende que el sistema no está disponible. Si se alcanza un puerto abierto la mayoría de los servicios simplemente descartarán el paquete vacío y no devolverán ninguna respuesta. Ésta es la razón por la que se utiliza el puerto por omisión 31338 ya que es poco probable que esté utilizándose. Algunos servicios, como chargen, responderán con un paquete UDP vacío lo que ayuda a Nmap a determinar que el sistema está disponible.
La principal ventaja de este tipo de sondeos es que atraviesan cortafuegos y filtros que sólo analizan TCP. Yo, por ejemplo, una vez fui propietario de un encaminador de banda ancha inalámbrico BEFW11S4. El interfaz externo de este dispositivo filtraba por omisión todos los puertos TCP, pero las sondas UDP podían generar mensajes de puerto no alcanzable y permitían detectar al dispositivo.
-PE; -PP; -PM (Tipos de ping ICMP)
Nmap puede enviar los paquetes estándar que envía el programa ping además de los tipos de descubrimiento de equipos con TCP y UDP. Nmap envía paquetes ICMP tipo 7 («echo request») a las direcciones IP objetivos y espera recibir un tipo 0 («Echo Reply») de los sistemas que estén disponibles. Lamentablemente para los exploradores de redes, muchos sistemas y cortafuegos ahora bloquean esos paquetes en lugar de responder como requiere el estándar RFC 1122. Por ésta razón los sondeos que sólo utilizan el protocolo ICMP no son muy fiables para analizar sistemas desconocidos en Internet. Aunque pueda ser una forma eficiente y práctica de hacerlo para administradores que tengan que monitorizar una red interna. Utilice la opción -PE para activar este comportamiento de solicitud de eco.
Nmap no hace sólo ésto, aunque la solicitud eco es la consulta estándar de ping ICMP. El estándar ICMP (RFC 792) también específica solicitudes de huellas de tiempo, de información y de máscara de red, que corresponden con los códigos 13, 15 y 17 respectivamente. Aunque el objetivo de estas solicitudes es obtener la máscara de red o fecha actual de un sistema también pueden utilizarse para descubrir sistemas. Un sistema que responde es por que está vivo y disponible. Nmap no implementa los paquetes de solicitud de información en sí, ya que no están muy soportados. El estándar RFC 1122 insiste en que “un equipo NO DEBE implementar estos mensajes”. Las consultas de huella de tiempo y máscara de red se pueden enviar con las opciones -PP y -PM, respectivamente. Si se recibe una respuesta de huella de tiempo (código ICMP 14) o de máscara de red (código 18) entonces es que el sistema está disponible. Estas dos consultas pueden ser útiles cuando los administradores bloquean los paquetes de consulta eco explícitamente pero se olvidan de que se pueden utilizar otras consultas ICMP con el mismo fin.
-PR (Ping ARP)
Una de las formas de uso más comunes de Nmap es el sondeo de una red de área local Ethernet. En la mayoría de las redes locales hay muchas direcciones IP sin usar en un momento determinado. Esto es así especialmente en las que utilizan rangos de direcciones privadas definidas en el RFC1918. Cuando Nmap intenta enviar un paquete IP crudo, como pudiera ser una solicitud de eco ICMP, el sistema operativo debe determinar primero la dirección (ARP) correspondiente a la IP objetivo para poder dirigirse a ella en la trama Ethernet. Esto es habitualmente un proceso lento y problemático, dado que los sistemas operativos no se escribieron pensando en que tendrían que hacer millones de consultas ARP contra sistemas no disponibles en un corto periodo de tiempo.
El sondeo ARP hace que sea Nmap y su algoritmo optimizado el que se encargue de las solicitudes ARP. Si recibe una respuesta, no se tiene ni que preocupar de los paquetes basados en IP dado que ya sabe que el sistema está vivo. Esto hace que el sondeo ARP sea mucho más rápido y fiable que los sondeos basados en IP. Por ello se utiliza por omisión cuando se analizan sistemas Ethernet si Nmap detecta que están en la red local. Nmap utiliza ARP para objetivos en la misma red local aún cuando se utilicen distintos tipos de ping (como -PE o -PS). Si no quiere hacer un sondeo ARP tiene que especificar la opción --send-ip.
-n (No realizar resolución de nombres)
Le indica a Nmap que nunca debe realizar resolución DNS inversa de las direcciones IP activas que encuentre. Ya que DNS es generalmente lento, esto acelera un poco las cosas.
-R (Realizar resolución de nombres con todos los objetivos)
Le indica a Nmap que deberá realizar siempre la resolución DNS inversa de las direcciones IP objetivo. Normalmente se realiza esto sólo si se descubre que el objetivo se encuentra vivo.
--system-dns (Utilizar resolución DNS del sistema)
Por omisión, Nmap resuelve direcciones IP por si mismo enviando las consultas directamente a los servidores de nombres configurados en el sistema, y luego espera las respuestas. Varias solicitudes (generalmente docenas) son realizadas en paralelo para mejorar el rendimiento. Especifica esta opción si desea que sí utilice la resolución del sistema (una IP por vez utilizando la llamada getnameinfo()). Este método es más lento y raramente útil, a no ser que hubiera un error en el código DNS de Nmap (por favor, notifíquelo si ese fuera el caso). Éste es el método por omisión para los sondeos IPv6.
--dns-servers <servidor1[,servidor2],...> (Servidores a utilizar para las consultas DNS)
Nmap generalmente determina los servidores DNS de su archivo resolv.conf (UNIX) o del registro (Win32). Puede utilizar esta opción para especificar sus propios servidores. Esta opción no se utiliza si utiliza la opción --system-dns o está realizando un sondeo IPv6. La resolución a través de más de un servidor de DNS es generalmente mas rapida que la consulta de uno solo.

realmente este post se queda a medio, pero es que lo tenía hace tiempo en borrador y me molesta xD.