miércoles, 30 de mayo de 2012

SNMP. Security Not My Problem

Como todos sabéis, SNMP desde sus inicios, fué un protocolo orientado a la administración de dispositivos de red, en la capa de aplicación, muy muy inseguro.
Hoy os voy a comentar un ataque sencillo, y viejo, de allá por el 2009.
No pongo las referencias, que son muy fáciles de encontrar, para no alentar a los chavales a hackearle el router del vecino, pero me parece interesante comentar la jugada.
El dispositivo que presenta la vulnerabilidad por defecto de serie, y que no quiere decir que este "ataque" sea solo para ese tipo, sino que conocemos parámetros exactos, es el famoso Zyxell Prestige serie 660 hw. ¿Cuanta gente tiene este en casa? ¿Cuantos clientes lo usan para pequeños negocios?. El impacto de este "bug" es y fué increíble, y a no ser que tu vecina del sexto sepa actualizar firmware´s y tocar configuraciones del mismo, seguirá vigente durante bastante tiempo.
El problema radica en la configuración por defecto de las claves de las comunidades, publicas y privadas, y de la exposición a la boca wan del puerto 160 udp . Una vez identificado el router en cuestión, lanzamos un nmap básico hacia los puertos simpáticos 21,23 y 80. sabes  qué son? Como veis, aparte de "fardar" con mi nuevo nmap 6. los puertos se encuentran Filtered. La gracia del asunto es que conociendo los OID´s, que serían los parametros para listar e incluso escribir configuraciones, con una herramienta como braa para realizar consultas SNMP,instalada en backtrack, la cosa está sencilla.
Lanzamos las query´s de escritura contra el router. De esta  manera, estamos abriendo los puertos del router.



Como podeis apreciar, el nmap me los muestra como abiertos.
Esto qué quiere decir? que si tenemos un router de telefónica, que no han auditado, y que lleva este fallo de seguridad tan gordo, dudo mucho que hayan cambiado la clave por defecto para su administración, bien sea por Telnet, o por la comodísima web del dispositivo.
La prueba realizada sobre este "amigo" fué exitosa, telnet ip clave por defecto 1234 y ... cocinaaaaaaaaaaaa. Viendo las tablas de asignación del DHCP podemos saber que host están por la red, desde la opción de mantenimiento podemos hacer un ping hacia un host interno. Redirigir mediante NAT el tráfico de los puertos más "simpaticos" hacia los host internos sería una buena acción. Cambiar el DNS por un fake dns apuntando a un metasploit/set , sería lo mas precioso del mundo. Pero nosotros somos buenos, y no queremos hacer daño. Llamaremos a nuestra vecina del sexto, y le aconsejaremos:
22. SNMP Configuration

  *  Nos aparece esto


                          Menu 22 - SNMP Configuration

                  SNMP:
                    Get Community= public
                    Set Community= public
                    Trusted Host= 0.0.0.0
                    Trap:
                      Community= public
                      Destination= 0.0.0.0


                    Press ENTER to Confirm or ESC to Cancel:

* Deberiamos cambiar la password GET y SET por algo menos obvio.
* Ademas podemos asignar como Trusted Host a algun PC de la LAN interna
   para que solo este PC (con la IP que especifiquemos pueda obtener/modificar
   valores usando SNMP.
* Trap: Si configuramos una ip destino, el router enviara a este destino
   informacion de gestion relativa a interfaces, velocidad, etc. Podemos
   usar MRTG para recolectar informacion. Por supuesto hay que cambiar la
   Community!!!

lunes, 21 de mayo de 2012

WebHttrack...copiar es como estudiar xD

 Cuando nos ponemos a auditar una aplicación web, nada mejor que trabajar en un entorno local, que estar constantemente preguntando a la web, generando tráfico, trabajar a horas en los que los administradores están un poco mas pendientes, pueden realizarse cambios mientras que estamos auditando.
Esta herramienta, WebHttrack nos realiza una copia exacta de la aplicación, para poder estudiar los scripts, probar, etc.
Las teclas del piano para la instalacion son muy sencillas, en windows son "click,click,click" y en entornos debian igual de sencillo: apt-get install webhttrack, y para el GUI apt-get install httrack. comando webhttrack para arrancar la herramienta.
Debemos crear un directorio, e indicarselo en la configuración del proyecto, donde se guardaran los tesoros ocultos xD.
Las configuraciones son muy sencillas, os recomiendo que al estar en castellano, repaseis una a uno. Tambien sería interesante usar un proxy. Cambiar el user-agent tambien es muy interesante.
 

sábado, 19 de mayo de 2012

VULNERABILIDADES...TEORIA

¿Qué es una vulnerabilidad? ¿De qué tipo pueden ser?. Definimos una vulnerabilidad como un error en un componente informático, que puede provocar una brecha de seguridad en un sistema. Hay muchos tipos, y no todas son mal diseño. Podríamos clasificarlas en:
  • Implementación.- Mala estrategia a la hora de implementar un sistema. Por ejemplo, si en una empresa se le asigna un usuario y contraseña temporal a un empleado cuando entra, y esta siempre es primera letra de nombre, y primer apellido, la configuración no está mal. Llega el usuario, la cambia cuando se sienta el primer día y listo. Para mi, es una mala implementación de un componente bien configurado.
  • Configuración.- Esto es lo que yo llamo mal instalada. Algún técnico instala un componente físico o lógico, mal, por ejemplo, dejar un directorio web con permisos de escritura cuando no debería. Estos casos, bajo mi humilde experiencia, son MUY comunes.
  • Dispositivo.- Por ejemplo, un Iphone que permite hacer llamadas incluso estando bloqueado con código. Una tarjeta de red en un servidor web que no admite mas de 300 conexiones concurrentes...
  • Protocolo.- Por ejemplo WEP. Es un protocolo sobrádamente demostrado que es inseguro.
  • Aplicación.- Cualquier fallo en una página web, o aplicación normal.
Como todos sabeis, y sino para eso estamos, hay muchos programas automaticos y semi-automaticos para realizar scanner´s de vulnerabilidades. Ya conoceis los nombres, y no es objeto ahora detallar ni publicitar ninguno, pero si que es cierto, que un scanner es la cuarta pata de cualquier sistema de seguridad. Los otros tres top-values son: anti virus, firewall y un buen IDS. Con el anti virus proveemos seguridad en el end-point( aunque los hay de gateway, de correo etc). Con el firewall definimos que es el end-point xD hasta donde pueden y podemos llegar etc. Con el IDS tenemos una solución pro-activa, que analiza el comportamiento de los sistemas con los procesadores, para alertarnos de determinadas amenazas.
Sin un buen scanner de vulnerabilidades, como sabemos que tenemos todo esto en marcha? bien configurado?.

Muchas empresas lejos de adoptar "el scanneo" como parte del proceso de seguridad, contratan a empresas para recibir un informe, bonito y habitualmente caro, y quedarse tranquilos de que son inviolables ( algunos casos solo para recibir un sello de certificación). Recomiendo adoptar esta técnica como parte del proceso, y realizarla:
  • Periodicidad determinada por la empresa.
  • Al instalar/modificar elementos del sistema.
  • Al actualizar dispositivos.
Tradicionalmente se han dividido los tipos de scaneos en dos, Internos y externos. Pudiendo ampliarse esta definición a "scaneo de aplicaciones web" ya que las técnicas concretas para analizar fallos son totalmente distintas en un entorno de aplicación web, que en un scanner interno/externo.
Dentro del scaneo de vulnerabilidades, se puede hacer otra distinción respecto al conocimiento que tiene el auditor sobre el sistema, denominando "Analisis caja negra" al análisis realizado por el auditor sin ofrecerle a penas información del objetivo, y "Análisis caja blanca"  en el que se es especifican datos concretos para poder profundizar y obtener mejores resultados.
Soy partidario de realizar los dos. Realizar un test a ciegas, y con los resultados obtenidos decidir que sistemas son objeto del siguiente estudio, otorgar mas información, y realizar un test de caja blanca.

Retomando el tema del software automático/semi. decir que es un arma de doble filo, ya que el mismo aplicativo usa el auditor para ayudar, que el hacker para hackear. Es VITAL conocer todas las reglas, plugins, configuraciones del software, para realizar un test en condiciones. Por poner un ejemplo, si en un firewall bloqueo el trafico ICMP ( ping) desde el exterior, y un atacante usa este protocolo, para saber si un HOST esta vivo o no, automáticamente el scanner detendrá el "ataque" si está activada esa regla ( habitual en configuraciones por defecto de scanner de vulnerabilidades).Mejor un TCP PING a puertos por debajo del 1024 no?.
Entonces, una vez que tenemos los host a auditar, tenemos el método para determinar si están vivos o no, configuramos el método de escaneo de puertos ( no voy a entrar en detalle, lo haré en próximas entregas) y por último, iremos seleccionando UNO  a UNO los scripts, plugins, conguraciones que queremos testear, con el fin de saber que estamos haciendo ( evitar D.O.S. , falsos positivos, profundizar en el plugin,etc).

Otro día seguimos con las vulnerabilidades.


lunes, 14 de mayo de 2012

XSS, una talla de ropa para modelos? parte I

    Voy a intentar recopilar un poco los conceptos básicos sobre Xss, que tanto vemos en todas las listas de fallos, y que espero nadie confunda con una nueva talla para modelos anoréxicas ( yo sin embargo gasto en casi todo la xxxxl xD). El objetivo del comentario es el de explicar de manera sencilla que son estos fallos, y de las consecuencias o vectores de ataque habituales.

      Según OWASP, el Xss es la vulnerabilidad mas presente en todas las aplicaciones.
¿Por qué no es Css? Sencillo, por no confundir con las hojas de estilo.
El concepto es easy. En un campo de entrada en una Web (busqueda,url,  variables, logins,etc) se realiza una entrada no válida o no esperada, para aprovechar ese comportamiento "indeseado".
Una de las cosas que debemos tener en cuenta, tanto si atacas o si no quieres ser atacado, es filtrar los caracteres "raros", usando un condicionante para expresiones regulares, para protegerse, y usando una codificación para atacar, por ejemplo inyectando parametros en hexadecimal ( suele estar ya muy controlado).
En cada tipo intentaré documentar los ataques y evasivas.
Me excuso un poco de publicar este contenido tan newbie ( como yo) y que lleva desde principios de siglo ( me encanta usar esta expresión) pero que hoy en día, como empieza el post, es el objetivo principal de ataques sobre aplicaciones web.

Reflected Cross Site Scripting (OWASP-DV-001)

El XSS no persistente, es una inyección de código simple, que se presenta en el navegador cliente, y suele usarse para redirigir a otra web, que infecte al cliente. También se usa para robar cookies, historial de visitas, etc, si sabes programar scripts, el límite es el cielo. Añado que un script que se recargue, y que no deje al usuario interactuar con el navegador, a no ser que mate el proceso, es una forma de ataque DOS (si encima tenia pestañas con información útil, lo fríes).

Ejemplo en claro
http://www.webvictima.com/index.php?user=<script>alert(document.cookie);</script>

ejemplo quitando <> y en hexadecimal
%3C%2Fscript%3

Como es normal, vosotros que sois expertos informáticos leéis la URL y sospecháis, pero y si es un link con un acortador tupo tiny, en un tweet o Factbook?

Stored Cross Site Scripting (OWASP-DV-002)

Misma inyección de código, pero con la característica que se ejecuta en todos los navegadores de todos los clientes que acceden a la url. Por qué? Sencillo, guardando los parámetros en el servidor. En que aplicaciones web vamos a poder ESCRIBIR en el servidor ( imaginamos que los admins de los servidores web tienen controlada la escritura directa, ya que para que querríamos usar XSS pudiendo “delete *” ) pues por ejemplo en post sobre foros, información de perfiles, carritos de compra, aplicaciones que permiten configurar rutas de carpetas…
Por ejemplo, en un comentario de un articulo de una web suelen estar controladas las etiquetas HTML, pero si empezamos así: “><script>document.alert(XSS)</script>  posiblemente el navegador lea esto: <input type="text" name="comentario" id="anotaciones" value="”><script>document.alert(XSS)</script>

Otra manera menos cantosa, inyectando un iframe oculto: ”><iframe frameborder=0 height=0 width=0

Vectores posibles, muchos, pero secuestrar las sesiones de todos los navegadores para hacer redes zombies, o simplemente aumentar las visitas de un sitio… los que te imagines.

DOM Cross Site Scripting (OWASP-DV-003)


El DOM Xss es una inyección de código que no devuelve unos datos en el navegador, sino que inyecta parámetros ( javascript muy vulnerable, como ya saben) para que actúen sobre elementos DOM. Por ejemplo así:
/index.html#user=<script>alert(document.cookie)<script>

Cambiamos el? por #

Qué pasa? Que el navegador ejecuta el script, sin que haya transito hacia el Server, por lo que es complejo  mitigar por partes de los sysadmin, a no ser que hagan test ( si no viajan peticiones, no pueden analizarlas)

Cross Site Request Forgery (CSRF)

También denominado XSRF. En todos los tutoriales compara Csrf con Xss diciendo que, en el segundo caso, el fallo reside en la confianza que tiene el usuario sobre un sitio Web (si todos los días entras a la Web de un banco, si alguien mete un formulario o redirección a login, confías en tu Web) mientras que en Csrf, es la web la que confía en las acciones de un usuario.
Básicamente, el atacante publica un código, embebido en un fragmento HTML por ejemplo en un foro, que al ser ejecutado por la víctima, ejecuta dicho código con sus privilegios dentro del aplicativo. Puede ser que en este ejemplo, de un foro, tanto el atacante como la víctima tengan los mismos permisos para publicar, pero quizás sea mucho más dañino usar el nombre de la víctima para publicar información…

Las recomendaciones generales para el usuario sobre como mitigar el impacto son:
Cerrar la sesión y no cerrar la ventana al salir de aplicaciones. No guardar las contraseñas para ninguna aplicación, por mucho que la usemos. No usar el mismo navegador para ver porno ( hay porno en Internet?) y en otra pestaña la web del banco o la empresa.
Respecto a los desarrolladores, usar la cookie de sesión, enfuscada, en todas las peticiones a las url´s. por ejemplo, si tenemos un sitio tal que así www.miempresa.com/nominas/mi nómina.aspx  sería muy fácil para un atacante conocer la estructura, y redirigir al atacante hacia esa web, y a su vez redirigir el resultado hacia el atacante. Si en la url aparecería la validación de sesión enfuscada, el atacante tendría mas problemas para conocer la estructura de ficheros a enviar.
Un ejemplo bien explicado por parte de Ms. http://msdn.microsoft.com/en-us/security/Video/bb977433
En la próxima entrega, intentaré hablar mas sobre estos fallos, y :
Cross Frame Scripting, Cross Zone, Cross Agent,Cross Referer y demás.
gracias !!!

Os recomiendo que no pase ni un minuto desde que leéis esto, a que leais:



Como probar estas técnicas sin ir a la cárcel, pues hay muchos sitios y proyectos, pero encuentro muy interesante y fácil de instalar en entornos ventana: http://sourceforge.net/projects/mutillidae/

miércoles, 2 de mayo de 2012

Nessus 5 Default Policies

Algunos tip´s sobre Nessus, que seguro todos habéis leído antes de instalar y lanzar vuestros ataques...

Políticas por defecto en Nessus.


Nombre de la directiva Descripción
External Network Scan Esta directiva está ajustada para analizar hosts con conexiones externas, que normalmente presentan menor cantidad de servicios para la red. En esta directiva se habilitan los plugins relacionados con vulnerabilidades de aplicaciones web conocidas (CGI Abuses y CGI Abuses: familias de plugins XSS). Además, para cada destino se analizan los 65.535 puertos.
Internal Network Scan Esta directiva está ajustada para ofrecer un mejor rendimiento, teniendo en cuenta que se puede usar para analizar redes internas grandes con muchos hosts, varios servicios expuestos y sistemas incrustados, como las impresoras. Los plugins "CGI Abuse" no están habilitados, y se analiza un conjunto estándar de puertos, no los 65.535.


Web App Tests Si desea analizar sus sistemas e indicar que Nessus detecte vulnerabilidades conocidas y desconocidas en sus aplicaciones web, esta es la directiva de análisis adecuada para usted. En esta directiva está habilitada la capacidad de "pruebas de exploración de vulnerabilidades mediante datos aleatorios" de Nessus, que hará que Nessus recorra todos los sitios web descubiertos y busque las vulnerabilidades que se encuentren en cada parámetro, incluidos XSS, SQL, inserción de comandos y varios más.
Prepare for PCI DSS audits Esta directiva habilita las comprobaciones de compatibilidad PCI DSS incorporadas que comparan los resultados de los análisis con los estándares de PCI, y genera un informe sobre su posición de compatibilidad. Es muy importante destacar que un análisis de compatibilidad de resultado correcto no garantiza la compatibilidad ni una infraestructura segura. Las organizaciones que se preparen para una evaluación de PCI DSS pueden usar esta directiva a fin de preparar su red y sus sistemas para tener compatibilidad.



Cuando creamos una política nueva, debemos tener en cuenta estos aspectos.


Save Knowledge Base El analizador Nessus puede guardar la información del análisis en la base de conocimiento del servidor Nessus para usarla posteriormente. Esto incluye los puertos abiertos, los plugins generados correctamente, los servicios descubiertos, etc.
Safe Checks Safe Checks deshabilitará todos los plugins que puedan producir efectos adversos en el host remoto.
Silent Dependencies Si esta opción está marcada, la lista de dependencias no se incluirá en el informe. Si desea incluirla, desmarque la casilla.
Log Scan Details to Server Guarda detalles adicionales del análisis en el registro del servidor Nessus (nessusd.messages), incluido el inicio de los plugins, el final de los plugins o si se elimina un plugin. El registro resultante se puede emplear para confirmar que se usaron plugins específicos y que se analizaron hosts específicos.
Stop Host Scan on Disconnect Si se marca la opción, Nessus dejará de realizar análisis si detecta que el host no responde. Esto puede producirse si los usuarios apagan su equipo durante un análisis, o si un host deja de responder después de que un plugin de denegación de servicio o un mecanismo de seguridad (por ejemplo, IDS) haya comenzado a bloquear el tráfico a un servidor. Continuar con los análisis en estos equipos producirá un tráfico innecesario en toda la red y demorará el análisis.
Avoid Sequential Scans De manera predeterminada, Nessus analiza una lista de direcciones IP en orden secuencial. Si la opción está marcada, Nessus analizará la lista de hosts en orden aleatorio. Normalmente, esto resulta de utilidad para ayudar a distribuir el tráfico de la red que se dirige a una subred en particular durante análisis extensos.
Consider Unscanned Ports as Closed Si no se analiza un puerto con un analizador de puertos seleccionado (por ejemplo, debido a que se encuentra fuera del intervalo especificado), Nessus considerará que está cerrado.


Tipos de escaneo:


TCP Scan Use el analizador TCP incorporado de Nessus para identificar los puertos TCP abiertos en los destinos. Este analizador está optimizado y posee algunas características de ajuste automático.

UDP Scan Esta opción activa el analizador UDP incorporado de Nessus para identificar los puertos UDP abiertos en los destinos.
SYN Scan Use el analizador SYN incorporado de Nessus para identificar los puertos TCP abiertos en los destinos. Los análisis SYN constituyen un método de análisis de puertos usado con frecuencia, y generalmente se consideran un poco menos intrusivos que los análisis TCP. El analizador envía un paquete SYN al puerto, espera la respuesta SYN-ACK y determina el estado del puerto de acuerdo con la respuesta o la ausencia de esta.
SNMP Scan Ordena a Nessus que analice los destinos en busca de un servicio SNMP. Nessus estimará la configuración SNMP correspondiente durante un análisis. Si el usuario proporciona la configuración en "Preferences", esto permitirá que Nessus pruebe mejor el host remoto y produzca resultados de auditoría más detallados. Por ejemplo, existen muchas comprobaciones para enrutadores de Cisco que determinan las vulnerabilidades existentes examinando la versión de la cadena SNMP devuelta. Esta información es necesaria para estas auditorías.
Netstat SSH Scan Esta opción usa netstat para comprobar la existencia de puertos abiertos desde el equipo local. Depende de la disponibilidad del comando netstat mediante una conexión SSH con el destino. Este análisis está destinado a sistemas basados en Unix y requiere credenciales de autenticación.
Netstat WMI Scan Esta opción usa netstat para comprobar la existencia de puertos abiertos desde el equipo local. Depende de la disponibilidad del comando netstat mediante una conexión WMI con el destino. Este análisis está destinado a sistemas basados en Windows y requiere credenciales de autenticación.
Ping Host Esta opción permite que se efectúen pings a hosts remotos en varios puertos para determinar si están activos.

Rendimiento:


Max Checks Per Host Esta opción limita la cantidad máxima de comprobaciones que realizará un analizador Nessus respecto de un único host en una sola vez.
Max Hosts Per Scan Esta opción limita la cantidad máxima de hosts que examinará un analizador Nessus al mismo tiempo.
Network Receive Timeout (seconds) Se encuentra establecido en cinco segundos de forma predeterminada. Es el tiempo que esperará Nessus para obtener una respuesta del host, a menos que se especifique lo contrario en un plugin. Si realiza un análisis con una conexión lenta, es recomendable que ajuste esta opción en una cantidad de segundos mayor.
Max Simultaneous TCP Sessions Per Host Esta opción limita la cantidad máxima de sesiones TCP establecidas para un único host.
Max Simultaneous TCP Sessions Per Scan Esta opción limita la cantidad máxima de sesiones TCP establecidas para todo el análisis, independientemente de la cantidad de hosts que se analicen.