30 junio 2009

¿Anonimato con un proxy? tal vez no

Todos conocemos que existen distintos tipos de proxy web cuando buscamos anonimato en la red. Distinguiendo entre nombres como "anónimo", "altamente anónimo" o incluso "élite".

Su denominación varía según la información que es enviada al servidor remoto en forma de cabeceras HTTP. Entre estas cabeceras es común encontrar:
  • X_FORWARDED_FOR: esta cabecera no está definida en el RFC de HTTP, ha sido creada por el proxy cache "Squid" con el objetivo de enviar la dirección IP del cliente al servidor Web. Dada su popularidad es se le ha dado relevancia y actualmente es soportada por la mayoría de aplicaciones. A tener en cuenta que es transmitida por el cliente y por lo tanto puede ser modificada, por lo que ningún control de acceso debería confiar en esta información, al igual que ocurre con otras cabeceras como User-Agent o Referer. No es común que los servidores a los que accedemos almacenen esta información en vez de la dirección IP del proxy, pero puede ocurrir, lo que significa que no somos tan anónimos como nos imaginamos.

  • VIA: Definida en el RFC como obligatoria cuando es usado un servidor proxy indica el camino que ha seguido la petición desde su origen al destino, identificando los protocolos que se han seguido. El objetivo principal de esta cabecera es evitar bucles infinitos.
Una vez hemos configurado el proxy en nuestro navegador, se puede conocer si estas cabeceras están siendo utilizadas accediendo a una página web del tipo "Cual es mi IP", que nos mostrará si utilizamos proxy o no y las direcciones IP que es capaz de detectar. Otra opción es hacer nuestro propio script donde se muestren las cabeceras enviadas con algo tan simple como:
<?php
foreach($_SERVER as $h=>$v)
if(ereg('HTTP_(.+)',$h,$hp))
echo "<li>$h = $v</li>\n";
header('Content-type: text/html');
?>
Pero estas cabeceras HTTP no son la única forma de conocer la dirección IP real de un cliente u otra información de interés, estos datos puede ser filtrados mediante otras técnicas, entre ellas:
  1. Peticiones DNS del cliente web, que solicita la dirección IP de un subdominio monitorizado, de esta forma el servidor DNS de ese dominio será capaz de averiguar el servidor DNS que utiliza el cliente y por lo tanto compañía y localización.
  2. Peticiones DNS desde applet Java, utilizando la socket API se solicita la resolución DNS de un subdominio, si este no es el mismo que el que sirve el applet, se genera una excepción de seguridad y no produce resultado, aunque la petición de DNS es enviada y al igual que en el punto anterior, se podría conocer los servidores DNS del cliente.
  3. Envío de paquetes UDP en applet Java, mediante el envío de un paquete UDP al servidor que sirve el applet es posible conocer la dirección IP de origen, este método no funciona con las últimas versiones de Java y requiere que el destino sea el propio que sirve el applet.
  4. Acceso a IP y hostname mediante la API de socket de Java, que permite obtener el nombre del sistema y su dirección IP mediante un applet, esta información puede revelar la IP interna del equipo (en caso de NAT) o uso de proxy.
  5. Mediante un paquete TCP en Flash, que revela la dirección IP de origen y que no utilizará la configuración proxy que tenga el navegador.
  6. Con Microsoft Office, si este está configurado para que abra directamente los documentos y estos contienen imágenes serán descargados sin utilizar el proxy.
  7. Utilizando plugin de Quicktime, que mediante un parámetro permite solicitar que la conexión se haga directamente contra el servidor remoto evitando el uso de proxy.
  8. Con el protocolo "itms://" de iTunes, en caso de tener instalado este software, si se accede a una dirección del tipo "itms" esta conexión se realiza sin utilizar la configuración del proxy del navegador.
Todas estas técnicas las ha implantado HD Moore en el sitio: http://decloak.net/. Esta aplicación online permite realizar un test sobre nuestro navegador una vez hemos configurado el proxy tratando de conseguir la dirección IP real de nuestro equipo.

Además permite la descarga del código fuente del applet de los puntos 2 y 3 y el flash del punto 5.

Algunas compañías que trabajan con comercio electrónico ya están haciendo uso de estas técnicas para evitar fraudes y conocer el origen real de los ataques que reciben.

Si lo que queremos es evitar esta identificación, solo cabe utilizar un navegador sin ningún tipo de complemente instalado, como son Java, Flash, iTunes u Office, eliminar la conexión directa con Internet, es decir, que nuestro sistema no pueda salir a Internet sin utilizar un proxy y utilizar servidores DNS públicos como OpenDNS.

Leer más...

29 junio 2009

FFhardener 1.1

Después del lanzamiento de la versión 1.0 de FFHardener que, tal vez, resultaba demasiado espartana y complicada de usar, le hemos comprado un buen traje, un corte de pelo en LLongueras y liberamos la versión 1.1 (esperamos que este cambio de look guste a los compañeros de Genbeta, Bitelia o Visual Beta).

El objetivo ha sido simplificar su uso, eliminando la tediosa labor de localizar el profile que emplea Firefox y, en el caso de Windows, darle una pequeña GUI para hacerlo mas intuitivo (cortesía de Carlos Juega).

La funcionalidad se mantiene intacta:
  • Mejoras a nivel criptográfico
  • Mejoras a nivel privacidad
  • Mayor seguridad en el uso de JavaScript
Nos estamos planteando añadir funcionalidad que no sea 100 % específica de temas relacionados con seguridad, leasé gestión de memoria, gestión de pestañas y otros tweaks similares (estamos abiertos a sugerencias y enlaces)

Podéis visitar la web del proyecto aquí
Leer más...

28 junio 2009

Podcast de Seguridad

¿Problemas de vista cansada? ¿Tienes los ojos rojos de leer tantos feeds a lo largo de la semana que ni el Vispring puede ayudarte?

Este domingo te daremos un respiro y dejaremos que relajes la vista. Por ello os proponemos unos Podcast de seguridad para que os entretengáis un rato y además agudicéis el oído.

El Guardián, el programa de radio de seguridad tecnológica te ofrece un resumen con las noticias más importantes de seguridad, que incluye una sección de software libre y alertas de seguridad con información actualizada sobre virus, troyanos y otras amenazas.

El CERT también nos ofrece su sección de podcast donde los líderes empresariales nos presentan los principios generales cuando se disponen a poner en marcha un plan de seguridad en su empresa o asegurarse que su programa de seguridad que tienen implantado está funcionando correctamente.

Desde el pasado mes de febrero el SANS Internet Storm Center (ISC) se ha unido a la emisión de podcast. El mes pasado ofreció información actual sobre amenazas de seguridad para entender mejor estos ataques y propuso medios para luchar contra ellos.

Desde New York City Off The Hook, una radio que lleva emitiéndose más de 20 años, asociada a la revista 2600 The Hacker Quarterly, este podcast es todo un clásico.

Por último otro en nuestra lengua, Yaocelotl.org donde podréis encontrar conceptos básicos de Ethical Hacking y te explicarán la metodología Hacking, las fases que sigue un hacker para realizar un ataque, marco legal, fase de escaneo...
Leer más...

27 junio 2009

Algunas lecturas interesantes para el fin de semana

Se acercan días de asueto y como para la mayoría de la gente que esta metida 'hasta las cejas' en temas técnicos seguro que vacaciones significa 'hago lo mismo pero a ratos veo la playa', vamos a proponer unas cuantas lecturas del SANS interesantes:

Incident Handlers Guide to SQL Injection Worms: bajo este título se encuentra un documento que explica en bastante profundidad la anatomía y forma de este tipo de amenazas, que si bien nunca han tenido un auge muy significativo, si resultan interesantes a nivel técnico.

Building an Automated Behavioral Malware Analysis Environment using Open Source Software: El análisis de Malware bien sea por hobby o por dedicación profesional, es una labor realmente apasionante. En este documento proponen un escenario basado en herramientas opensource

Inside a Phish: Mucho hemos hablado sobre phishing por aquí y pocas veces se puede encontrar documentación precisa de los 'internals' del asunto, este artículo escrito por gente que ha lidiado con esos temas de forma profesional, puede resultar muy revelador.

Espero os resulten interesantes
Leer más...

26 junio 2009

La Telebasura

Mucho estrés en nuestras vidas, de aquí para allá todo el día, por fín llega el viernes y hoy lo mejor será vegetar en el sofá. Veamos la programación de una cadena aleatoria, por ejemplo, Bydefault3...si si, está en vuestro TDT, ¿no os suena? Tiene programas muy conocidos durante todo el día: "Reflejo Privado" por la mañana, por el mediodia la serie revelación "Los HijosSimp", por las tardes "¿Quién quiere ser MilEurista?" y por las noches "¿Dónde estás pulmón?". Ahora si ¿verdad?.

Entonces pues nada, a mi como el teletexto me sigue saliendo como muy feo (cambiaré de televisión a ver), utilizaré internet para ver la programación, que para eso está:

http://www.google.es/search?hl=es&q=bydefault3tv+programacion&meta=&aq=f&oq=



Me dirijo al primer enlace mismamente y me encuentro un selector de fechas, vamos a consultar el 26 de junio...


Hay dos opciones al encontrarnos con esto: O el día 1 próximo que coincida en viernes sea el fin del mundo, o directamente que esta guía de programación no funcione. Me fijo en la dirección y me encuentro un 2004, algo no me cuadra, así que retrocedo un poco de profundidad en esta web y me encuentro una "vuelta al pasado":


Juraría que esta no es realmente la página actual de la cadena, además con otra búsqueda en google podremos llegar a la de ahora y es como más bonita, dinámica, con más presencia de su serie de moda "Mates o Lengua". Volvemos a tener dos posibilidades con este hecho: O todo se trate de una campaña promocional por la serie que emiten actualmente...como se llamaba...esa que también era del pasado...¡ah si! La de "Me Asomo A La Ventana Es", o simplemente que en el servidor siguen quedando restos de funcionalidades anteriores, que por una cosa u otra se ha visto conveniente conservar.

Síndrome de diógenes informático podríamos llamarlo, a muchos nos da por guardar doce tipos de teclados debajo de la cama, y otros deciden conservar copias de sus anteriores versiones de la web en el servidor como si de un disco duro se tratase. Ahora veréis más claro el título de este post, y por qué se llama Telebasura.

Ya sé que la mayoría me diréis que exagero, que tampoco es tan grave seguir conservando algo así. El problema viene cuando lo conservado falla demasiado, y ofrece información que no debería:


¿Pero esto qué es? Cambio de tecnología en el servidor web, que casualmente es distinta a la que sostenía la anterior versión de la web y claro, ese tipo de lenguaje ya no se interpreta, si no que se muestra como cualquier fichero normal. ¿Realmente seguimos pensando que es necesario conservar esta versión, que encima no aporta funcionalidades y es obsoleta casi al 90%? No hace falta invertir mucho en seguridad para concienciarnos de algo así, OWASP (proyecto libre, gratis, free, espíritu wiki, disponible para todos, repito, sin costes) tiene varias secciones con recomendaciones enfocadas a no mantener en el servidor ni ficheros de backup, ni de antiguas funcionalidades que ya no sean necesarias.

Imaginemos que en la versión anterior teníamos una vulnerabilidad media-alta, de la que porfín podríamos olvidarnos al hacer pública la nueva versión de la web (Security through obscurity, o traducido al castellano "bah, si nadie lo va a ver"), ya que es más fácil que comernos la cabeza para poder solucionarla. Exageremos un poco, que a veces es necesario para poder verlo más claro: Si a mi me hacen un transplante de un órgano que me falla, me ponen uno bueno, pero me siguen dejando el malo...vaya la que se organiza ahí dentro.

Mejor un cine, ¿no?

P.D. : Los cuadritos negros de las capturas son fallos de mi tarjeta gráfica, disculpen las molestias.
P.D 2: Ningún trix se ha visto dañado mientras se escribía este post.
Leer más...

25 junio 2009

Teletienda: productos para hacker.

¿Cansado de tu monótono trabajo? ¿pensando en convertirte en un hacker ético? ¿quieres formar parte de la comunidad underground? ¡¡Ahora ya puedes hacerlo con este Kit que proponemos y que podrás pagar en cómodas cuotas de 99,9€!!. No. Lo sentimos pero desgraciadamente no tenemos tienda online y no vendemos nada.

Por si os puede servir para adquirir o solicitar nuevo equipamiento, hemos recopilado una pequeña lista con lo que consideramos el hardware ideal para realizar tests de intrusión y otras actividades propias de un profesional en seguridad. Muchas de ellas opcionales y aquí, cada uno se haga la suya propia :-)

  1. Portátil: por supuesto es el elemento más importante y vamos a remarcar algunos puntos a tener en cuenta antes de seleccionar cual comprar:
    • Wifi: importante que la tarjeta integrada tenga compatibilidad con herramientas como Aircrack.
    • Smartcard: poco a poco se hace más uso de las tarjetas inteligente como el propio dni electrónico, por este motivo es esencial que nuestro portátil tenga lector de smartcards, ya sea integrado o externo.
    • ExpressCard, será necesario para ampliar el portátil con otra tarjeta wireless, un modem 3G o cualquier otro accesorio que pueda ser necesario.
    • USBs: no, 2 USB no son suficientes, 3 son justos y con 4 empezamos a entendernos.
    • Tarjeta Gráfica: Si pensabas que no encontrarías excusa para pedir una tarjeta gráfica potente, nosotros tenemos una. Usando la GPU de las placas con soporte CUDA se es posible optimizar el rendimiento en algunas aplicaciones de fuerza bruta. Recomendado GeForce 8800 en adelante, como un buen quakero.
    • Bluetooth: imprescindible para conectar con el móvil, un GPS, hacer análisis de seguridad de bluetooth y algunas cuantas miles de cosas más.
    • Bateria adicional: sobre todo será necesaria para los análisis de seguridad wireless, donde pocas veces podremos conectar el portátil a una toma de corriente eléctrica.
    • Hyper-V: hoy en día ejecutar máquinas virtuales es lo más común, si nuestro equipo soporta esta tecnología garantizaremos el mejor rendimiento en virtualización.
    • TPM: interesante para usar algunas soluciones como BitLocker.
    • Módulo 3G/HSDPA: si tiene el módulo para este modem, nos ahorraremos usar el móvil o un modem externo, ganando algo en comodidad. Las tarifas más interesantes son de Yoigo y Simyo.
    • Compatibilidad: no estaría de más comprobar que no existen "problemillas" de compatibilidad con Linux.

  2. Antena Wifi: si estás pensando que aún puedes salir a auditar con tu antena pringles, la respuesta es NO al igual que no deberías usar hombreras. Puedes comprar una antena wireless que sirva para mejorar la ganancia de tu adaptador, como por ejemplo, una antena Yagi

  3. Tarjeta adicional Wireless: a la que puedas conectar la antena, hay tarjetas USB que tienen integradas potentes antenas y son desmontables para utilizar otras externas. Un chipset que permite jugar cómodamente es RTL8187L o Atheros. Si tenemos presupuesto (mucho), AirPcap es la tarjeta mejor soportada en Windows para todo tipo de herramientas.

  4. GPS: ya sea USB o Bluetooth, es muy útil para mapear puntos de acceso en grandes localizaciones durante una auditoría wifi. Sirf suele dar buenos resultados.

  5. Cadena de seguridad: si vamos a dejar solo el portátil en nuestra ausencia, este tiene que tener un buen cierre, que nos asegure que cuando volvamos el portátil siga donde lo dejamos.

  6. Filtro de privacidad: para evitar el famoso "sniffing over hombro" tan habitual entre compañeros y mirones que se sientan a nuestro lado en el avión.
Desde luego más difícil de encontrar es el portátil, sobre todo porque el que dispone de unas opciones no dispone de otras, además que en general tendremos que utilizar el que provea la compañía de una marca concreta.
Leer más...

24 junio 2009

¿Construimos Software Seguro?

¿Por qué encontramos tantos fallos de seguridad en los desarrollos una vez éstos han subido a producción? Pensemos por un momento en las aplicaciones de Internet y en la cantidad de veces que se han reportado vulnerabilidades que permitían acceder a las bases de datos de los clientes por culpa de fallos en los desarrollos. La seguridad juega un papel muy importante en estos productos y no se le presta la atención que merece.

Conozco casos donde los desarrolladores reportan la ausencia de requisitos de seguridad a sus responsables y las excusas por parte del equipo de diseño siempre suelen ser las mismas: no hay tiempo, los plazos son escasos, no hay presupuesto. Pero luego a quienes se apunta con el dedo cuando empiezan a aparecer los bugs, es a los desarrolladores.

¿No sería mejor empezar a pensar en seguridad desde que comienza el ciclo de vida del software y no después de subir el producto a producción, cuando los costes se vean aumentados por la necesidad de tener que aplicar parches y más parches?.

Las organizaciones deben definir una serie de prioridades y la mayoría de las veces la seguridad no suele ser de alta prioridad. A menudo, no es rentable hacer un sistema tan seguro como sea posible, ya que el riesgo es bajo y el coste es alto.

Cuando recibimos los estudios de viabilidad de los clientes, revisamos en busca de requisitos de seguridad pero éstos son escasos y en muchas ocasiones inexistentes. Si los analistas son buenos éstos se encargan de incluir algunos, pero como las estimaciones de los proyectos suelen ser en la mayoría de los casos muy ajustadas, tienden a omitirlos.

El software está en la raíz de la mayoría de los problemas de seguridad informática, si éste no se comporta de forma adecuada surgirán problemas de integridad, disponibilidad, confidencialidad... Los bugs y vulnerabilidades son la causa de un mal diseño y una mala implementación. Debemos empezar a concienciarnos: la seguridad debe estar presente en todas las fases del ciclo de vida de un producto.


En el inicio, durante la fase de análisis se debe realizar un análisis de impacto y pensar en las amenazas y vulnerabilidades a las que puede verse afectado nuestro producto, para ello debemos incorporar modelos de amenazas. Además todo arquitecto debe recoger: las políticas, los riesgos y las normas jurídicas.

En la fase de diseño se debe realizar un análisis de riesgos, el cual debe ser realizado por expertos en seguridad quienes son capaces de reconocer en que situaciones se producen los ataques más comunes. Durante la fase de implementación, si los programadores necesitan formación en seguridad, se les debe de proporcionar dicha formación.

En el plan de pruebas funcionales, también debe estar presente la seguridad ya que pueden surgir nuevas salvaguardas a incluir. Se deben incluir pruebas de seguridad, test de intrusión, pruebas de carga, pruebas de denegación de servicio y planes de mitigación de riesgos. En estos casos podemos utilizar herramientas para el análisis de vulnerabilidades como:

Además debemos incluir una buena auditoría, ya que es una parte esencial en la seguridad del software.

Pero todas estas medidas no se harán efectivas si no están incluidas en el Gobierno de TI, es decir, si no hay concienciación en materias de seguridad desde las altas esferas.

Es extraordinariamente rentable invertir en seguridad en las etapas iniciales del proyecto, podemos hablar de ahorros del 20% (Secure Business Quarterly)

En definitiva, se recomienda establecer los controles desde que se establecen los requisitos. Os recomiendo la lectura de Systems Security Engineering Capability Maturity Model (SSE-CMM) y dar un paseo por OWASP.
Leer más...

23 junio 2009

How To 'amordazar un País' By Irán

Se está hablando mucho sobre lo que está sucediendo en Iran y el papel tan importante que está cobrando Internet.

También en numerosas ocasiones se ha hablado de 'super censura', es decir, aquella que realiza un Estado contra la globalidad de sus ciudadanos mediante elementos de filtrado, pero pocas veces se han tenido datos medianamente fiables sobre los mecanismos de filtrado y el proceso.

El caso de Irán, ha sido diferente, la gente de Arbor networks ha liberado un estudio sobre que protocolos y servicios fueron filtrados y el 'timing' según iban aconteciendo los sucesos.

Gracias a que varios ISPs de Irán forman parte del 'Internet Observatory' se han podido obtener unas métricas sumamente interesantes.

Hay que destacar que en Irán, las comunicaciones vía Internet al exterior pasan por la 'Data communication Company of Iran' que actúa a modo de super-gateway.

Dicho esto, pasemos al análisis de la información:

En primera instancia, como se puede observar en el gráfico de Arbor sobre el tráfico con destino al puerto 80/tcp (http-web), se produce un muy apreciable pico de intensidad justo antes de las elecciones y luego, tras las elecciones, se produce un corte total, para re-aparecer en niveles sensiblemente inferiores, lo que da idea de que ya había entrado en funcionamiento el bloqueo a ciertas webs.

Uno de los puntos mas interesantes es el que concierne al tráfico en formato Adobe Flash, no olvidemos que Flash es el core de sitios como Youtube, Vimeo y que casi todos los portales informativos cuelgan la información visual en ese formato. Según se puede ver en el gráfico, el tráfico de datos en formato flash tiene un super-pico el día antes de las elecciones (La gente de Arbor especula con el hecho de que posiblemente fuera gente en busca de información que se estuviera emitiendo en portales informativos internacionales) y luego, abruptamente, tras las elecciones, cae a niveles ínfimos, lógicamente la tijera iraní ya estaba a pleno rendimiento

Por último, Arbor publica un interesante gráfico sobre el 'top' de protocolos bloqueados por el firewall iraní:
Y aquí es donde yo me llevo una sorpresa, el protocolo mas bloqueado es el SSH. Visto así, en crudo, me choca bastante, y me explico: cualquiera que conozca y haya jugado con SSH conoce sus capacidades para hacer 'el Houdini' y sus excelentes aptitudes para hacer túneles VPN, lo que a mi particularmente me sorprende es lo sumamente extendido que debe estar este sistema entre la disidencia Iraní, porque es lógico pensar que el método se llevaba usando desde hace mucho tiempo para 'mover información', y como se puede ver por los hechos post-elecciones, el gobierno tenía muy claro que eso estaba sucediendo y como actuar.

En definitiva muy interesante el estudio de Arbor.

[+] El artículo original en inglés se puede leer aquí
Leer más...

Microsoft Security Essentials

Los chicos de Redmond nos presentan la primera release gratuita de su nuevo producto de seguridad, Microsoft Security Essentials (MSE), al que muchos conoceréis por el codename Morro.

MSE ha sido diseñado para buscar y aniquilar el malware de tu ordenador en tiempo real y se actualiza a diario.

Se mantiene en segundo plano hasta que localiza software sospechoso y es entonces cuando chequea contra los servidores de MS y permite o no la ejecución de dicho software. Además Microsoft mantiene una base de datos de software confiable por lo que no bloquea dichos elementos.

Yo lo encontré donde las descargas son MEGA...




A partir de hoy será posible descargarlo de manera oficial y estará disponible para XP, Vista y 7.

MSE es una herramienta antivirus y antispyware, por ello necesitaremos de firewalls y programas antispam (entre otros) para añadir más protección a nuestro ordenador.
Leer más...

22 junio 2009

Hackeos Memorables: Metasploit

Estoy seguro que todos los profesionales y aficionados a la seguridad informática, hemos oido hablar (o convenientemente utilizado alguna vez), de Metasploit, el framework de herramientas de seguridad o en realidad su colección de exploits ya preparados. Resulta cuanto menos paradójico que la propia ubicación que alberga la imagen web de Metasploit haya sido víctima de un ataque (en realidad un DoS).

Así fue, allá por Junio del 2008, el servidor web para las descargas de Metasploit, dejó de responder. En su lugar se podía ver una web que decía en modo jocoso: "hacked by sunwear ! just for fun".

¿Cómo sucedió? Según HD Moore, el creador de Metasploit, el servidor en concreto nunca llegó a ser comprometido de forma directa. Es decir, que los paquetes no fueron alterados ni troyanizados como se llegó a sospechar inicialmente. Para llegar a efectuar el DoS, los atacantes lograron penetrar en otra máquina de la misma red (en el mismo ISP). De esta manera, fueron capaces de generar un ataque de ARP Spoofing contra todos los servidores de esa subred, incluido el de Metasploit, de manera que envenenaban su caché ARP a la hora de definir el gateway por defecto. Así, todas las peticiones, no sólo hacia Metasploit, sino hacia todos los servidores que estaban en la misma red, se redirigían a una página china con el contenido de "Hacked by Sunwear!" mediante un Man in The Middle que se encargaba de hacer el defacement.

Según explica HD Moore, el problema se solucionó añadiendo de forma estática una entrada con la correspondencia IP/MAC reales del gateway por defecto y por supuesto notificando al ISP del problema.

Mis dudas ante este incidente son: ¿cómo logró HD Moore entrar en su máquina de forma remota si su servidor resolvía mal la ruta de vuelta? Es decir, a todos los que hemos tenido que administrar máquinas remotamente nos ha pasado alguna vez (me incluyo), a la hora de hacer alguna labor de cambio de dirección IP o de gateway, o de instalación de software cortafuegos, etc,... que hemos perdido la conectividad con la máquina en remoto. Las únicas soluciones para acceder a tu máquina es ir en modo consola y conseguir de nuevo la conectividad con tu red para poder seguir trabajando remotamente con la máquina, esto es pidiendo a la gente del ISP que te añada la entrada ARP válida. Otra opción posible es que HD Moore tuviera acceso a un switch KVM y que desde ahí pudiera estar ya dentro de la red interna. De esta manera, el ARP spoofing no le afectaría y podría hacer las modificaciones oportunas en su servidor.


Leer más...

21 junio 2009

El Iphone, ese oscuro objeto de deseo que genera partidarios y detractores a partes iguales, que normalmente es noticia en otros blogs mas gadgeros, hoy tiene sus minutos en SbD por culpa de una vulnerabilidad que podría llegar a costar bastante dinero a la potencial victima.

Según ha sido publicado, el navegador Safari que incorpora el teléfono tiene problemas con ciertos tags HTML específicos para navegadores en teléfonos móviles.

En concreto, Safari soporta dos tags 'peliagudos' cuanto menos: sms: y tel: que, como es fácil deducir, se emplean para insertar vínculos en paginas web con la finalidad de que el usuario pueda enviar un sms o hacer una llamada cómodamente. Sin duda otro claro ejemplo donde una funcionalidad atractiva, tiene implicaciones en el campo de la seguridad.

El comportamiento habitual o esperado del tag tel: es que, al hacer clic desde el navegador web, se genere un popup donde se le presente al usuario información explicándole que va a realizar una llamada y deba aceptar si la hace o no.

El problema que han localizado la gente de trifinite estriba en que, usando convenientemente Javascript para formatear una pagina web, es posible hacer que el teléfono haga una llamada sin consentimiento por parte del usuario, abriendo de esa forma la ventana a que alguien fuerce a un usuario a hacer una llamada a un numero 'especial' que tenga sobre-coste (típicamente en España un 905).

Los detalles técnicos de la noticia los podéis leer aquí y yo me enteré gracias al siempre activo ANELKAOS
Leer más...

20 junio 2009

Listas de correo de seguridad.

Este resumen no está disponible. Haz clic en este enlace para ver la entrada.
Leer más...

19 junio 2009

Un vistazo a WarVox

En un artículo anterior, Alejandro realizó una pequeña revisión del estado del arte de las herramientas de wardialing.. en cierta forma como previo a este articulo, en el cual voy a realizar una pequeña introducción a WarVOX, una herramienta de wardialing novedosa que permite, mediante VoIP, realizar una identificación/clasificación de líneas de teléfono que expongan servicios de datos.

Así mismo, creo importante reseñar que dado el tipo de herramienta de que hablamos, a lo largo de articulo me centraré más en la faceta de “servicios de datos” de un wardialing.. pero no debe obviarse que en un buen wardialing, no se comprueban únicamente los servicios de datos, centralitas que permitan cursar llamadas, servicios de buzón de voz, o incluso la ingeniería social, son otras facetas que forman parte del wardialing y de las que quizás hablemos en el futuro.

El Problema de la VoIP.

Antes de empezar con WarVOX, creo pertinente una pequeña explicación de los problemas de la VoIP de cara al wardialing que justifique el por qué la VoIP no ha sido tradicionalmente una tecnología habitual en los proyectos de wardialing.

Como muchos sabréis, lo que la gente llama habitualmente “VoIP” es en realidad una amalgama de protocolos destinados a transmitir telefonía tradicional por medio de redes de datos (en particular de redes IP).

De cara a su funcionamiento, la práctica totalidad de los protocolos de VoIP existentes (h.323, SIP, IAX, SS7oIP, etc.) diferencian claramente la información de señalización, de la información “de voz” o sonido.

Se entiende por señalización, la información que intercambian los dos extremos de una comunicación VoIP para intercambiarse los diferentes eventos que se producen durante el inicio, mantenimiento y cierre de una llamada, es decir, “petición de nueva llamada de este número a este otro”, “el usuario ha marcado el digito #7 en su terminal”, “el extremo remoto está ocupado”, etc. todo eso son mensajes de señalización que ambos extremos intercambian para realizar la gestión de la llamada. De cara a la señalización cada estándar de VoIP tiene sus propios protocolos, tipos de mensajes, etc.

Por otro lado, además de la señalización, esta lo que realmente importa al usuario, el sonido.. o “la voz” como suele decirse tradicionalmente. Así pues, en VoIP, (al igual que en otros sistemas de telefonía digital tradicionales como ISDN), el sonido evidentemente viaja en forma digital codificado mediante algoritmo de compresión de sonido, (o codec).

Sin embargo, a diferencia de otros medios de telefonía digital, en VoIP, los códec que suelen emplearse tienen como objetivo principal reducir al máximo el ancho de banda necesario para transmitir una llamada, permitiendo así maximizar el número de llamadas concurrentes que se pueden realizar.

Por poner un ejemplo... en telefonía digital tradicional (lo que hacen las Telcos de toda la vida), un primario EuroISDN E-1 dispone de 30 canales de 64kb/s cada uno, lo cual permite la transmisión de 30 llamadas concurrentes. Sin embargo, el mismo primario puede ser configurado para la transmisión de datos mediante protocolo TCP/IP, en cuyo caso el primario ofrece un ancho de banda total de 2Mb/s. Sobre este canal de 2Mb/s el operador puede, utilizando VoIP cursar con facilidad más de 80 llamadas concurrentes… Está claro, que se maximiza el ROI de una línea.. ¿no?

Esta reducción tan drástica del ancho de banda necesario para transmitir el sonido, radica en que los codecs que se emplean en VoIP están diseñados para “simplificar, normalizar y limpiar” el sonido previamente a su compresión, mediante técnicas de filtrado de bajos, supresión o cancelación de eco, reducción de ruido, etc. En gran medida, son estos mecanismos de “normalización” los que permiten al códec reducir la cantidad de información a comprimir y así alcanzar su objetivo de reducir al máximo el ancho de banda necesario.

Dado que el sonido que han de transmitir es la voz de dos personas comunicándose, se da por sentado que no es necesario que se realice una compresión sin perdidas (“lossless compression”) del sonido, sino que más bien, se emplean algoritmos de compresión que ofrezcan cierta calidad, pero asumiendo que pueda perderse parte de la calidad original del sonido (“lossy compression”). Un ejemplo de estos _codecs_ empleados en VoIP, es GSM, el cual se emplea desde mucho antes en las redes de telefonía móvil, las cuales desde sus orígenes tienen que enfrentarse a lo limitado de la transferencia de información por medios inalámbricos.

Este funcionamiento “lossy” podemos verlo de forma similar en otros codces más habituales en la informática de consumo como son el “MPEG-1 Layer3” (MP3) o DivX realizan, solo que su diseño se especializa, en lugar de en sonido telefónico, en compresión de sonido de cierta calidad (mp3) o en compresión de video de alta resolución (DivX). Maravillas de la tecnología.. ;)

Sin embargo, el empleo de estos codecs tan eficientes, presenta un grave problema cuando se pretende realizar un wardialing. O de forma más generalista, presentan un grave problema cuando se pretenden transmitir datos como parte del sonido de una llamada VoIP, pues estos codecs son generalmente incompatibles con la forma en la cual un modem tradicional codifica la información para su transmisión mediante una línea RTB.

La transmisión de datos vía modem, se diseño para su funcionamiento en líneas analógicas RTB. En dichas líneas analógicas, la información se codifica en función a una serie de estándares (v.32, v.34, v.90, T.30, etc.) los cuales se basan en hacer un uso intensivo de las frecuencias sonoras disponibles (300~3100Hz), pero, por desgracia, este “uso intensivo” supera con creces las capacidades de retención de información que los _codecs_ de VoIP habituales ofrecen. Recordemos, que el propósito en la VoIP (de ahí la V) es la transmisión de Voz.. ;)

En definitiva, y después de este pequeño “rollo”, la idea se resume en lo siguiente: en la mayor parte de los casos, es imposible, o al menos inusable, la transmisión de datos de un “modem” por medio de VoIP. Así pues, dado que en un wardialing lo que se pretende es identificar y atacar servicios de datos como servidores de Acceso RAS, Servidores de Terminales, sistemas de control industrial, x.25, etc. tratar de emplear VoIP para conectar a estos sistemas seria un intento fútil..

Una nota más sobre VoIP y los Modems ;)

Como reseña adicional, para los que estén pensando “pero, si, si que se pueden transmitir datos en VoIP.. yo lo he hecho.. porque.. blah.. blah.. blah”.. Bueno, aquí viene el “disclamer” para todos vosotros.. ;)

Si, efectivamente, no es imposible transmitir datos en VoIP, ya que los mismos codecs que se emplean en líneas TDM/ISDN tradicionales para la transmisión de sonido (g.711u y g.711a) se pueden emplear en VoIP. Y si, con estos codecs, la información transmitida por un modem podrá alcanzar su destino sin perdidas..

Sin embargo, pese a esto, este es un escenario improbable, ya que estos codecs ofrecen ratios de compresión nulos en comparación a la telefonía digital tradicional, por lo tanto, los operadores de VoIP accesibles en internet no suelen tener disponibles dichos codecs (aunque algún operador despistado existe.. creedme.. ;) )

Así mismo, y para el escenario que nos ocupa, tratar de mantener muchas llamadas concurrentes a través de Internet empleando estos g.711 consumirá un ancho de banda considerable, además de introducir latencias muy superiores a las de los otros codecs, resultando una configuración poco práctica en la mayor parte de los escenarios.

La solución: Que es y que no es WarVOX

Sin embargo, WarVOX es una curiosa herramienta, cuyo objetivo es ayudar en una de las fases más largas de un proceso de wardialing..la Identificación de posibles objetivos

En un buen proyecto de wardialing, se le pide al cliente que informe de todos los números de todas las líneas de teléfono que tiene contratadas. Se pretende poder entregarle en retorno un inventario donde, no solo se le informe de posibles servicios vulnerables, sino además proveer al cliente de un inventario de todos los servicios de datos que expone su corporación por medio de líneas telefónicas… pensemos que una empresa de cierta envergadura suele disponer de muchísimas líneas de teléfono, en localizaciones dispersas y que además dada esta dispersión no todas están bajo el control directo de los departamentos de IT, Seguridad, etc.

Por este motivo, muchas veces, el servicio de wardialing brinda al cliente la oportunidad de saber a ciencia cierta si hay más líneas “exponiendo servicios” de las que él mismo tiene contempladas… Quién sabe, siempre puede haber algún “listillo” que coloca un modem por ahí para poder acceder al ordenador de la oficina desde casa..

Como paso previo en el wardialing, lo normal, es realizar una batería automatizada de llamadas a todos los números de teléfono a investigar para identificar en que líneas hay algún tipo de “servicio de datos” y cuáles son líneas de Voz, centralitas con operadora automática, etc., pero por desgracia, dada la ingente cantidad de números de teléfono que el cliente puede entregarnos, el proceso de identificación puede durar bastante, especialmente en función a la cantidad de líneas de teléfono y módems de que dispongamos, así como implicar unos costes en la factura telefónica importantes.

Este es el principal problema que WarVOX intenta solventar: permitir reducir el tiempo y costo necesario para realizar la identificación y clasificación de los números de teléfono a investigar.

¿Cómo? Sencillo, empleando las facilidades (y precios) que los operadores de telefonía a través de internet nos brindan mediante VoIP.

Con WarVOX, podemos introducir una lista (o una serie de rangos) a analizar, para que la herramienta llame a dichos números por medio de VoIP y nos proporcione una lista reducida de números “interesantes” sobre los cuales profundizar en un análisis más manual.

Gracias a su funcionamiento mediante VoIP, WarVOX nos permite reducir drásticamente los tiempos de análisis paralelizando las llamadas, pues al no necesitar líneas de teléfono, podemos hacer uso de toda la capacidad que el/los operadores en internet nos ofrecen..

Así mismo, dado que los operadores a través de internet ofrecen precios mucho más competitivos que los operadores tradicionales, podremos ahórranos una buena parte del dinero y/o realizar análisis más exhaustivos.

Como funciona WarVOX

Bueno, y si antes nos has dado la chapa con que si los codecs no permiten transmitir datos y no sé qué otras cosas aburridísimas.. ¿Cómo puede ser que WarVOX hace esto que nos estas contando?

Bien! Aclaremos este importante punto.. A diferencia de las herramientas de wardialing tradicional, WarVOX no “conecta” al otro extremo e interpreta los “datos” como seria habitual.. Por el contrario, WarVOX lo que hace es grabar durante un tiempo determinado el sonido que “genera el otro extremo” tras descolgar, para más tarde analizarlo mediante transformaciones de Fourier y otros análisis matemáticos en busca de indicios de que el sonido corresponde a un modem, fax u otro servicio de datos.

Así mismo, las grabaciones realizadas, así como las diferentes graficas de las transformaciones de Fourier de los análisis las tendremos disponibles para realizar análisis posteriores complementarios a los análisis automáticos que realiza la herramienta.

Mediante dicha técnica, WarVOX nos permite reducir rápidamente la cantidad de números de teléfono sobre los cuales centrar nuestra atención. Esto es.. números que ahora sí, utilizando un modem tradicional podemos “marcar” para investigar que se esconde tras la portadora remota.. ;)

Como usar WarVOX

Se trata de una herramienta Open Source, desarrollada en ruby por HD Moore (si, el de Metasploit), mediante el framework Ruby On Rails tan popular en proyectos OSS últimamente.

Así mismo, pese a que pueda funcionar en otros SO, lo más razonable es instalarla en Linux, para lo cual, deberéis descargarla de su página oficial (http://warvox.org/), en la cual también están disponibles las instrucciones de instalación para Ubuntu.

Desde el punto de vista de su manejo, la herramienta (una vez arrancada) se maneja vía web, bien conectando localmente, o si la arrancamos con la opción (--address 0.0.0.0) de forma remota. Como decía, el manejo es mediante HTTP gracias a un servidor embebido (el de mongrel de RoR) que escucha por defecto en el puerto 7777.



Así mismo, el software dispone de un fichero de configuración (/etc/warvox.conf) en el cual deberán configurarse las credenciales para poder acceder vía web.

Una vez dentro, deberemos configurar nuestro proveedor VoIP en el enlace “Providers” dispuesto a tal efecto. WarVOX soporta únicamente proveedores que ofrezcan servicios basados en IAX. Lo cierto es que en EEUU son bastantes los que dan dicho servicio, pero en el caso de operadores nacionales la lista es más corta.. Pero bueno, no desesperéis, si se disponen de conocimientos de de asterisk, es perfectamente posible configurar un servidor asterisk para que haga de intermediador entre AIX y SIP, nosotros lo hemos probado y funciona perfectamente..



Tras configurar el/los proveedores, podemos comenzar el “escaneo”.. pinchando en el enlace de “Jobs” podremos configurar un nuevo trabajo.. Ahí será necesario introducir los rangos/mascaras de números a marcar, o bien subirlos mediante un fichero.

Nótese (en rojo) que el software nos permite especificar el número de origen a utilizar en las llamadas.. Esto es algo que pocos proveedores de internet nos dejarán hacer, pero que en determinados escenarios puede ser muy útil al cliente para identificar las llamadas que hemos realizado nosotros y diferenciarlas de posibles ataques “reales”.



Tras introducir un “Job” WarVOX comenzará a realizar llamadas.. una vez terminado el trabajo, podremos observar los resultados desde el enlace “Results”





Una vez revisados los resultados de la ejecución del trabajo, pinchando en “View Analysis” podemos acceder al análisis detallado de la grabación realizada a cada destino. Así como podemos reproducir la grabación para valorar por nosotros mismos si al otro lado “hay portadora”.



Y como suele decirse.. “ya está”.. muy sencillito, verdad? Por supuesto, ahora es cuando comienza la fase en la que el “humano” aporta valor.. ya tenemos una lista de objetivos a los que “atacar” con nuestras artes oscuras, pues manos a la obra.. ;)

¿Qué mejoraríamos?

Como toda herramienta, WarVOX no es perfecta.. y si bien, en las pruebas que hemos realizado lo que ha hecho, lo ha hecho “bastante bien”, siempre existen cosas a mejorar y voy a permitirme apuntar algunas, por si alguien quiere “meterle mano” ;)

· Soporte de otros protocolos de VoIP.. ¿Alguien ha dicho SIP?

· Dada la a veces inestable forma de trabajar de los operadores de VoIP se echa en falta algo más de información de detalle indicando “porque una llamada no pudo cursarse”.

· De cara a evitar tener que hacer segundas batidas sobre todos los números, poder configurar un numero de reintentos de llamada cuando un número estaba ocupado, sería una buena ayuda.

· La instalación en entornos “no Ubuntu” es algo laboriosa.. Si, lo sé Ubuntu es la moda, los mas freaks de los mas freaks usan Ubuntu y los que no usan Ubuntu son lammah (o peor aún usan LFS).. pero en definitiva, instalarlo en una RedHat Enterprise 5.2 ha requerido tiempo extra debido a las variopintas dependencias que el software tiene..

· Finalmente, en la página de detalle del análisis de un trabajo, hemos notado que las gráficas de señal y espectro son cacheadas por el navegador (tanto FF como IE) y es necesario dar a F5 una o dos veces al cambiar de un análisis a otro.. Esto puede resultar muy confuso al principio.. si finalmente es un Bug en RoR o en WarVOX.. creo que será necesario reportarlo..

Como punto final.. y para que se vea que yo también pongo mi granito de arena.. el software “sox” (una de las dependencias de WarVOX) que viene de serie con RHEL 5.* era demasiado antiguo para WarVOX y producía un error debido a un que este invocaba “sox” pasando parámetros inválidos. Pues bien, dado que hablamos de una herramienta OSS, para arreglarlo decidí hacer un mínimo “patch” que permite mediante un parámetro de configuración funcionar WarVOX con la susodicha versión de “sox”.. y por lo tanto me sirvo anexarlo a continuación por si es de utilidad a alguien..

diff -Nru warvox-1.0.1-tmp/etc/warvox.conf warvox-1.0.1/etc/warvox.conf
--- warvox-1.0.1-tmp/etc/warvox.conf 2009-05-15 05:13:57.000000000 +0200
+++ warvox-1.0.1/etc/warvox.conf 2009-06-17 23:33:28.000000000 +0200
@@ -38,3 +38,5 @@
# Configure the dial blacklist location
#
blacklist: %BASE%/etc/blacklist.txt
+
+old_sox_version: true
diff -Nru warvox-1.0.1-tmp/lib/warvox/config.rb warvox-1.0.1/lib/warvox/config.rb
--- warvox-1.0.1-tmp/lib/warvox/config.rb 2009-05-15 05:13:56.000000000 +0200
+++ warvox-1.0.1/lib/warvox/config.rb 2009-06-17 23:41:48.000000000 +0200
@@ -39,6 +39,14 @@
File.expand_path(info['data_path'].gsub('%BASE%', WarVOX::Base))
end

+ def self.old_sox_version
+ info = YAML.load_file(WarVOX::Conf)
+ return false if not info
+ return false if not info['old_sox_version']
+ return true if info['old_sox_version'].to_s == "true"
+ false
+ end
+
def self.analysis_threads
info = YAML.load_file(WarVOX::Conf)
return 1 if not info
diff -Nru warvox-1.0.1-tmp/lib/warvox/jobs/analysis.rb warvox-1.0.1/lib/warvox/jobs/analysis.rb
--- warvox-1.0.1-tmp/lib/warvox/jobs/analysis.rb 2009-05-15 05:13:56.000000000 +0200
+++ warvox-1.0.1/lib/warvox/jobs/analysis.rb 2009-06-17 23:40:16.000000000 +0200
@@ -294,7 +294,9 @@
frefile.path

# Generate a MP3 audio file
- system("sox -s -2 -r 8000 -t raw -c 1 #{rawfile.path} #{bname}.wav")
+ sox_arg = WarVOX::Config.old_sox_version == true ? "-w" : "-2";
+ # print("XXX %s" % sox_arg)
+ system("sox -s %s -r 8000 -t raw -c 1 #{rawfile.path} #{bname}.wav" % sox_arg)
system("lame #{bname}.wav #{bname}.mp3 >/dev/null 2>&1")
File.unlink("#{bname}.wav")
File.unlink(rawfile.path)


Conclusión

Tras hacerle una pequeña batería de pruebas realizando llamadas a diferentes números, fijos “normales”, servidores RAS, servicios de control remoto vía GSM, etc. Lo cierto es que el índice de resultados que ha ofrecido la herramienta es bastante aceptable (cerca del 90%), las pocas pegas que podemos tener son mas en relación al diagnostico o a la instalación que al funcionamiento en sí.. que en general es, no solo fácil, sino práctico.

Ale, pues ya sabéis, después de este articulo interminable, ahora lo que toca es que todos “sus” pongáis a hacer wardialing a diestro y siniestro.. uh.. digo… no.. solo a donde tengáis permiso para hacerlo!!!

- Pablo Ruiz (pablo_@_netway_org)
Leer más...

18 junio 2009

Evita la censura de VoIP con VoiceGuard

Hace poco hablábamos de los diferentes tipos de censura establecidos por los gobiernos de varios países (incluso de cómo saltarse algunas de ellas (1) y (2)). Sin embargo, aún no hemos tenido en cuenta servicios cada vez más comunes como la Voz sobre IP (VoIP).

En este caso no sólo es un país (Emiratos Árabes en este caso), quien impone lo que se debe y/o lo que no se debe utilizar, sino determinados ISPs (por ejemplo Clearwire) que proveen el mismo tipo de servicios pero de pago, a diferencia de los gratuitos ofrecidos por aplicaciones como Yahoo Messenger, MSN o el archiconocido Skype.

Para promocionar sus propios servicios, y dado que la VoIP requiere funcionar en tiempo real, dichos ISPs ralentizan esos protocolos (haciendo QoS) incorporando retrasos en las comunicaciones y haciéndolas inservibles. En caso de Emiratos Árabes directamente está prohibido este tipo de tráfico (en fin, siempre nos quedarán los PDF como hacíamos para Arabia Saudí).

Para bypassear estas restricciones surgen iniciativas como Voiceguard que, basándose en encapsular el tráfico en otro tipo de protocolo evitar los consabidos bloqueos o delays en la conexión. Para ello, lo que se hace es incorporar un dispositivo en nuestra red (o un software en un PC genérico, o usar teléfonos propios) antes del router, que transforma los paquetes SIP o RTP en paquetes de otro protocolo permitido como DNS o TFTP. Además permite cifrar el tráfico según la política de seguridad elegida. Al funcionar a nivel de enlace (es decir que no es un software que se instale en el terminal del usuario), es compatible con cualquier tipo de teléfono IP. El tráfico que no es VoIP simplemente lo deja pasar de forma transparente hacia el router.

Evidentemente hay que contratar un servicio de centralita, donde se enrrutan estos paquetes a su destino final, dónde existirá otro dispositivo compatible con Voiceguard que deshará el encapsulamiento.

Bajo estas líneas os dejo un esquema de cómo se generan los túneles.


Leer más...

17 junio 2009

Bypasseando mod_security mediante HPP

Días atrás analizamos los nuevos conceptos de ataque web basados en lo que se llama HPP (HTTP Parameter Pollution). Dicho nuevo tipo de ataque se podía producir a la hora de "jugar" asignando diferentes valores a una misma variable en una petición web.

Recientemente, ha publicado un paper Lavakumar Kuppan, en el cuál demuestra las aplicaciones de este ataque un paso más allá de lo que comentamos en su momento desde aquí (en los comentarios del referido post hicimos una breve explicación de cómo podría utilizarse este tipo de ataque para vulnerar determinados Web Application Firewalls).

En el caso analizado por Lavakumar Kuppan, se explica de una forma bastante clara, el comportamiento de un servidor web IIS con aplicaciones .ASP y .ASP.NET corriendo en él, así como el efecto de aplicar este ataque asignando valores diferentes a una misma variable,. En el post anterior veíamos que IIS encadenaba los diferentes valores mediante comas. Dependiendo del tipo de la función .ASP que se utilice para interpretar los valores: Request.Params, Request.QueryString y Request.Form y depende además de si es ASP o ASP.NET para que el valor final de la variable sea lo que viene en la URI (de un GET o un POST), lo establecido en una Cookie o en el cuerpo de una petición POST.

En el caso de Lavakumar, utiliza mod_security configurado "by default" para proteger la aplicación web. El WAF lo que hace es analizar cada variable de forma independiente y busca ataques en cada parámetro. En el caso de un ataque HPP, se analizan las variables de una en una,.. y si sueltas no resultan un ataque, lo permitirán pasar.

El problema viene cuando el IIS ensambla todas esas variables (con el mismo nombre)... de manera que pueda unir diferentes valores de manera que queden cosas como "select name, password from users" poniendo un valor "select name" y otro "password from users" en una variable del mismo nombre. Se puede llegar a pensar que es poco potente este ataque puesto que un valor "password from users" algún WAF podría llegar a bloquearla y ya está. No podemos pasar cada palabra en una instancia de variable porque quedarían cosas como "select,name,password,from,users" -> lo cual sería completamente inútil puesto que sintácticamente fallaría en su procesamiento.

Uno de los grandes aportes del análisis de Lavakumar es la utilización de los caracteres para introducir comentarios en código SQL. Presupone, que un IIS suele llevar como servidor de base de datos de backend un Microsoft SQL Server, de manera que para poner algo "entre comentarios" (no procesable por el motor de base de datos) se utiliza estructuras como esta: /*esto es un comentario*/. Además el comportamiento del servidor de base de datos ante un comentario es sustituirlo por un espacio.

¿Cómo aprovechamos esto? Muy sencillo, aquellos campos donde necesitemos espacios pondremos caracteres de inicio y fin de comentario, así:

http://www.miweb.com/index.aspx?a=select/*&a=*/name&a=password/*&a=*/from/*&a=*/users

será interpretado finalmente como "select name,password from users" habiendo vulnerado las comprobaciones de seguridad "por defecto" de mod_security.

Para mitigar este tipo de ataque habría que configurar mod_security para no permitir muchas ocurrencias de la misma variable en una sola petición web.
Leer más...

16 junio 2009

TwitPwn, o como dejar sin vacaciones a un grupo de desarrolladores

TwitPwn es un blog conducido por el investigador israelí Aviv Raff, que participó en la iniciativa "Month Of Browser Bugs" promovida por H.D. Moore, y que planteaba ir posteando en el blog citado, día a día, una vulnerabilidad asociada a cualquier navegador web. La iniciativa concluyó con éxito, dejando tras de sí 31 vulnerabilidades, unas más importantes que otras, pero al fin y al cabo, cumplieron con lo prometido.

Pues bien, Aviv vuelve a la carga, con algo que yo creo que se extenderá más debido al objetivo que se ha marcado: Ha declarado Julio como el mes de los bugs en twitter, el "Month Of Twitter Bugs" (nombre en clave MoTB), y anuncia que cada día irá publicando vulnerabilidades referentes a este servicio de microblogging, más concretamente con su API, y que es usada por muchísimos otros servicios. Esos son precisamente sus objetivos. Por aquí, ya hemos tratado varias veces el tema de la seguridad en twitter, y bueno, sobran las palabras.

El señor Raff acepta más bugs, pero él ya ha dejado claro que tiene los suficientes como para llenar completamente el mes.

Señores developers de twitter, señores developers de servicios que usan la API de twitter, y sobretodo (porque a los anteriores, se les avisará con 24 horas de antelación a la publicación de los fallos), señores del público general que usan este sistema: añadan el feed de TwitPwn a su lector de feeds preferido, por si acaso les toca alguna de las vulnerabilidades muy cerca...

ACTUALIZACIÓN: Vamos a realizar un seguimiento de TwitPWN en nuestro Twitter, comentaremos los bugs que se vayan reportando y tambien via Twitter intentaremos resolver las dudas que nos planteeís.
Leer más...

Hackeos memorables: Chaos Computer Club

Noviembre, año 2004. Todos los inscritos al congreso chaos computer club reciben un correo electrónico de la organización, en el que se disculpan por "haberla pifiado" con los datos de registro, ya que un grupo de colegas españoles ha roto la seguridad de sus sistemas accediendo a esta información y publicándola en Internet.

Dear Camp attendee,

we are sorry to say that we fucked up handling your data provided for
the organization of the Chaos Communication Camp correctly. When the
registration system was shut down after the camp in 2003, an unencrypted
backup copy of the registration data was unfortunately left on the machine.

The server has been used for hosting another TWiki installation after
the camp, but the organization crew left planet earth due to
extraterrestrial commitments and more or less forgot about its existence.

Our spanish colleagues succesfully broke into this machine, exploiting a
newly found bug in the TWiki software, and published part of the stuff.
This includes personal registration data as well as crypt passwords for
Wiki users. While the passwords are not available in clear text, they
are susceptible to a dictionary attack. Therefore, these passwords must
be considered compromised, so we urge anybody who used the same password
for camp registration or TWiki and any other system to take appropriate
measures.

Please carefully check the data provided at
http://www.digitalsec.net/stuff/fun/CCC/ccc_and_cccs.txt.

We contacted the crowd at digitalsec.net and asked them to remove all
personal data from their publicly available documentation. They reacted
very kindly and dropped read permissions for the database dump. We
apologize for the inconvenience and promise to do our best to avoid
such bullshit in the future. Thank you for your attention and do not
forget to apply appropriate security measures.


sigh,

the CCC Crew


En 2004 digitalsec o !dSR (http://www.digitalsec.net, ahora no disponible), es (era?) uno de los grupos españoles que apoyan el proyecto mayhem (pr0j3ct m4yh3m), o por lo menos algunos de sus miembros. Este proyecto tiene por misión ridiculizar a los whitehats, todos los que quieran ganar dinero con la industria de la seguridad y todo aquella que la rodea mediante la penetración de sus sistemas, ya sea a grandes compañías del sector, de personalidades con cierto nombre internacional o de grupos de hacking como en este caso.

Mediante la modificación del perfil Benjamin Schweizer, miembro del CCC, !dSR publicaba la intrusión que había cometido con todo tipo de detalles en un archivo que aún puede ser consultado: ccc_hack.ccc_and_cccs.txt. Posiblemente el txt que más WTF provocó ese año en el Chaos Computer Club.



dn: cn=emerson,ou=accounts,o=ccc,c=de
userpassword: {crypt}77nsflOsZCfKE
cn: emerson
email: emerson@packetstormsecurity.org
realname: Emerson Tan
equipcomputer: 0
departuretime: -1
engeltype: kitchen
telephone: +44 781 456 8265
accommodation: camping
transporttype: spaceship
equipwavelan: 0
village: hackcenter
birthyear: 1975


En este documento se muestran datos de todos los colores: configuración de la VPN, bastantes credenciales del sistema, y lo más doloroso: un backup del LDAP que contenía los usuarios del los participantes en el congreso, sus correos y su contraseña.

Según se supo más adelante, digitalsec había conseguido un 0day del software TWiki, que corría sobre los sistemas del CCC, que les permitía ejecución remota de comandos.

Hans Ulrich del CCC, tras realizar un forense a los sistemas publicó la vulnerabilidad atribuyéndosela como suya. No fué hasta ese momento que Román Medina reaccionó y explico en un amplio correo (para variar) que el la había descubierto unos meses antes y publicado el exploit en un reducido grupo de personas de donde se habría filtrado. Incluso el propio autor de TWiki confirmó que Román le había notificado la vulnerabilidad unos días antes.

El bug se encontraba en el buscador de la aplicación, el cual componía un comando ejecutado mediante "``" con los datos introducidos por el usuarios sin previa validación.

doesnotexist1'; (uname -a; id) | sed 's/\(.*\)/__BEGIN__\1__END__.txt/'; fgrep -i -l -- 'doesnotexist2

Nadie se libra y este caso, como muchos otros, le hace a uno reflexionar cuantos sitios habrán sido penetrados por hackers y cuantas vulnerabilidades no públicas existirán...

Hace frio ahí fuera.

Leer más...

15 junio 2009

Vídeo Vigilancia WEB de zonas sensibles

En el mundo real estamos muy acostumbrados a ver cámaras de seguridad ahí donde existen controles de acceso, cualquiera que trabaje en una empresa relativamente grande no le extrañará ver que junto a la puerta / torno de acceso existe una cámara apuntando hacia ahí.

Hace poco conocí una web llamada Clicktale que me dejó absolutamente asombrado, esta web permite 'grabar' las acciones que se hagan en una web y tener un vídeo disponible para su posterior revisión. ¿Magia? No, Javascript.

Es bastante impresionante como exprimen ciertas funciones de Javascript para conseguir sacar una película de los movimientos de un visitante sin ayuda de plugins externos o hacer que el visitante se baje nada (y que además funciona en todos los navegadores y sistemas operativos). Realmente para hacerse una idea de lo que digo recomiendo probar la demo gratuita de la web, es bastante impresionante.

Clicktale orienta ese servicio para investigar y sacar patrones de uso de una web en base a donde van los movimientos de ratón o que partes se visitan antes, pero creo que el concepto puede ser también interesante para monitorizar partes administrativas de cualquier web. En concreto estoy pensando en aquellas partes donde se accede para gestionar el website, zonas de edición de contenidos, webmails o similar.

Aunque probablemente la mayoría de los ataques a un website se realizan empleando herramientas para tal efecto (hablamos de Paros, Burp, WebScarab ...) es verdad que normalmente la primera toma de contacto se realiza de forma manual, alguien localiza un formulario y manualmente prueba la sempiterna comilla simple ' o los típicos admin / admin, una vez superada esa fase, se pasa a las herramientas específicas.

Adaptar esos formularios web para que sean 'video vigilados' mediante Clicktale es tan sencillo como insertar un par de lineas JavaScript dentro del html de la web, de esa forma podremos tener para nuestro disfrute y solaz fabulosos vídeos donde queda registrada la actividad como si fuera un sistema de vídeo vigilancia tradicional. En el panel de gestión de Clicktale -evidentemente- aparece también asociada la IP que generó esa actividad y el tiempo que estuvo frente al formulario.

Otra potencial idea puede ser la monitorización de Honeypots

Hemos creado un pequeño vídeo del panel de gestión visionando la captura de lo que podría ser un intento de acceso no autorizado (muy recomendable verlo a pantalla completa)

Leer más...