Los globos de Google para llevar Internet a todo el mundo estarán listos el próximo año

El interesante proyecto de Google conocido como Project Loon sigue quemando etapas y está mucho más cerca su puesta en marcha definitiva. Según las palabras del director del proyecto, existirá una flota estable de globos en el hemisferio sur para poder ofrecer acceso a Internet a todos los habitantes de estas zonas.

En junio de 2013 se desvelaba la existencia de este proyecto del departamento Google X, para llevar Internet a los lugares más inaccesibles del planeta mediante globos aerostáticos situados a 18.000 metros de altura. La prueba piloto, que resultó un éxito, se realizó en Nueva Zelanda con 50 personas intentando conectar con alguno de los 30 globos desplegados.

Más tarde, en octubre del pasado año, tuvimos más detalles sobre los globos, que son capaces de proveer acceso a Internet a velocidades 3G e incluso más rápidas. Google encontró algunos problemas para controlar la trayectoria, por lo que sus siguientes pasos se centraron en mejorar el hardware y las radios.



Lo último que habíamos sabido es que consiguieron dar una vuelta al mundo en sólo 22 días, 11 días menos de lo esperado por Google. El gigante de Mountain View afirma que son capaces de permanecer en el aire unos 100 días, aunque durante ese viaje se encontraron también con algunos inconvenientes que fueron capaces de resolver “sobre la marcha”.

Ahora conocemos, de boca de Astro Teller, responsable de Google X, los siguientes planes de Project Loon. La meta es conseguir demostrar que se puede ofrecer acceso inalámbrico a millones de personas que no pueden acceder a la red hoy en día. Para ello, Google necesita una amplia flota de globos volando en la circunferencia del planeta de forma constante para que la gente en tierra pueda captar la señal en todo momento.

El próximo año tendremos una flota de globos semipermanente en forma de anillo en algún lugar del hemisferio sur, para que sus habitantes puedan tener Internet en cualquier lugar. Los globos proporcionarán señal inalámbrica utilizando el mismo estándar que la telefonía 4G LTE con velocidades de 22 Mbps en antenas fijas y 5 Mbps en terminales móviles.


Fuente

Múltiples vulnerabilidades en servicios looking-glass de Internet

Para quien no lo conozca HackerOne es una plataforma para hospedar programas de recompensas por bugs de seguridad (bug bounty programs). Dentro de la misma dos gigantes como Microsoft y Facebook patrocinan elInternet Bug Bounty que paga por vulnerabilidades descubiertas en las tecnologías principales de Internet como DNS, BGP, SSL, etc. y en general cualquier fallo que afecte globalmente a muchos sitios o proveedores.

Recientemente han premiado con 5.000$ a Luca Bruno (kaeso) por un estudio llevado a cabo en mayo de 2014 para analizar la seguridad de los servicios denominados looking-glasses que ofrecen muchos AS (Autonomous Systems) para diversas pruebas de conectividad en Internet. Las razones que han llevado a identificarlos como fuente potencial de problemas son las siguientes:


- son scripts web directamente conectados a routers (telnet/ssh) del backbone (BGP)
- muchos de ellos han sido programados en los 90s o 00s sin tener en cuenta la seguridad
- muchos de ellos no han sido actualizados en años
- en muchos AS se ha desplegado software de código abierto 

Es decir, ataques con éxito contra scripts PHP/Perl escritos hace una década pueden permitir el acceso a la consola de los routers. Una vez dentro, un atacante podría escalar privilegios y ejecutar comandos causando estragos en la red: desde fuga de información sensible, hasta DoS o cambios de enrutamiento BGP hacia sitios maliciosos.

El resultado de este estudio a derivado en la identificación de diversos fallos que se categorizan de la siguiente manera:

- configuración insegura por defecto provocando la exposición de direcciones IP, credenciales y claves privadas SSH => entrada directa a los routers 
- débil sanitización de entrada de comandos => inyección de comandos arbitrarios en routers 
- corrupción remota de memoria  => RCE en servidores looking-glass, explotable para obtener las credenciales de credenciales 
- XSS reflection => robar las cookies de otros paneles de administración de red bajo el mismo origen

Y en particular, han conseguido nada más y nada menos 6 CVEs, cada uno con los detalles y la línea de tiempo correspondientes:

- XSS en Cougar-LG - http://www.s3.eurecom.fr/cve/CVE-2014-3926.txt
- inyección de comandos en routers mediante mrlg4php -http://www.s3.eurecom.fr/cve/CVE-2014-3927.txt
- credenciales expuestas en Cougar-LG - http://www.s3.eurecom.fr/cve/CVE-2014-3928.txt
- claves SSH expuestas en Cougar-LG - http://www.s3.eurecom.fr/cve/CVE-2014-3929.txt
- credenciales expuestas en Cistron-LG - http://www.s3.eurecom.fr/cve/CVE-2014-3930.txt
- corrupción remota de memoria en binario SUID - http://www.s3.eurecom.fr/cve/CVE-2014-3931.txt


Más información en: https://hackerone.com/reports/16330

8 servicios proxy gratuitos para evitar restricciones y mantener el anonimato y la privacidad

Hace tiempo hablábamos de algunos servicios VPN gratuitos que nos permitían evadir ciertas restricciones de navegación web y mantener la privacidad y el anonimato. Sin embargo, otra alternativa que no podemos obviar es el uso de proxies web, algo más inseguro pero mucho más rápido, primero porque el proxy es un intermediario que sólo enmascara y enruta tráfico (sin dedicar recursos al cifrado) y segundo y sobretodo porque podemos usarlos sin necesidad de instalar nada, simplemente mediante el navegador web. 

En el blog de EFYTimes podemos encontrar una lista con ocho de los mejores servicios proxy gratuitos:

1. Proxy.org
Proxy.org es la guía pragmática del usuario para mantener la privacidad en línea y la navegación web anónima.

2. Proxify
Proxify es un proxy web que modifica cada página web que visites para que todos sus recursos (como enlaces, imágenes y formularios) apunten a Proxify.

3. XRoxy.com
Ofrece acceso gratuito a una base de datos de proxies abiertos que se actualiza con frecuencia a través de una interfaz de usuario flexible que permite ordenar la lista de proxies por tipo, nivel de anonimato, número de puerto, latencia de la conexión, etc.

4. Ninja Cloak
Ninja Cloak es un servicio web proxy gratuito que permite navegar por sitios web de manera anónima e incluso desde detrás de un firewall con los puertos bloqueados.

5. Anonymiser
Ya sea que en casa o en una Wi-Fi pública, Anonymiser Universal mantiene tus actividades online seguras y de manera privada.

6. BlewPass
BlewPass ayuda a evitar los filtros de Internet y firewalls impuestos por la escuela, el trabajo o un país. Manténte a salvo y seguro mientras navegas a través de sus servidores.

7. Dont Filter
Dontfilter.us es un desbloqueador web anónimo y una herramienta de privacidad online. Con este servicio se puede acceder a todos los sitios web que el administrador y/o el país correspondiente no quieren que estés mirando.

8. HideMyAss
Es un servicio web proxy gratuito que permite navegar de forma anónima, ocultar la dirección IP, ocultar el historial de Internet y proteger tu identidad en línea.

Retromalware: Detecta y Controla NetBus con Metasploit

En el año 1998 el mundo de la informática conoció el troyano NetBus. Esta pequeña aplicación fue lanzada como una herramienta de administración remota de máquinas, aunque existían algunas versiones más oscuras que eran utilizadas por atacantes para troyanizar máquinas. Yo dediqué tiempo a jugar con NetBus cuando iba al tercer grado de media, allá por el año 2001, pero eso es otra historia. En verano me dio por trastear y sacar del baúl de los recuerdos a software que hoy en día tienen poca aplicación, ya que son desbordados por otras herramientas con mucho más poder, pero apareció de nuevo el NetBus. 

Figura 1: NetBus 1.70

Decidí echarle un ojo, y ver cómo los creadores de malware de la época hacían para transmitir la información y las órdenes desde un cliente a un servidor. Hay que recordar que el malware de aquella época seguía una arquitectura cliente-servidor clásica. Cuando mandaban el fichero patch.exe (servidor de NetBus) a una víctima ésta disponía de una dirección IP, la cual era una dirección pública. Esto hacía que cualquier usuario pudiera tener conectividad directa con dicha máquina. Después aparecieron los routers y la idea tuvo que cambiarse y ser el “bicho.exe” el que haga la conexión reversa a la máquina del atacante. 

Fase 1: Detectando un NetBus

Echando un ojo con un Wireshark a la interacción entre el cliente y servidor en una red me llamó la atención la facilidad con la que NetBus se identificaba. 

Figura 2: Tráfico de conexión a un servidor NetBus

En la imagen se ve como el cliente, en este caso una versión 1.60, realiza la conexión con el servidor (three-way handshake) y el servidor “escupe” un segmento con datos. Parece que el servidor muestra el banner, como si de otro servicio normal se tratase. Con Wireshark podemos ver que nos dice la versión a la que nos hemos conectado. 

Figura 3: Versión de NetBus en el paquete de datos de conexión

Al ver esto, y viendo que el verano por el norte no ha sido muy productivo a lo que horas de sol se refiere, me puse a trastear con Ruby. Muchos saben que desde el libro de Metasploit para pentesters un servidor anda con ganas de ir haciendo más y más cosas para el framework, aunque no todo lo que me gustaría debido al poco tiempo libre. Para pasar el rato decidí codificar un script en Ruby para, dándole una dirección IP, detectar un NetBus y su versión.

Figura 4: Código en Ruby para detectar versión de NetBus

En el código, muy sencillo, se puede ver como se abre un socket contra unaDirección IP y un Puerto que, en la versión 1.60 de NetBus es el 6000, es por el que se gestiona. Tras abrir el socket esperamos a recibir un “\r” que es el delimitador que utiliza NetBus, algo que también se puede obtener del mensaje mostrado conWireshark anteriormente. En él se puede ver que cada comando o información enviada acaba con un “\r”, en hexadecimal 0d. 

Fase 2: Implementando el comando GetInfo de NetBus

Si lo que recibimos por el socket encaja con la expresión regular definida para localizar un banner de NetBus se imprime por pantalla la versión. Como se puede imaginar esto es algo bastante rápido de montar, y el sol seguía sin salir por el norte así que decidí ir un poco más allá. 

El cliente de NetBus tiene diversos botones que permitían al atacante hacer maldades sobre sus víctimas. Pero, como ya hemos visto antes, la comunicación era trivial, el texto plano es la clave. Al probar el botón de Get Info, el cliente obtiene algo de información de la máquina remota, por ejemplo el Usuario con el que se está conectado en el sistema operativo, la ruta dónde se encuentra el patch.exe o el número de clientes conectados. Si observamos la trama en Wireshark veremos que el comando no puede ser más sencillo “Get Info”, escrito a través del socket, eso sí, que no se nos olvidé el 0d al final, o lo que es lo mismo “\r”. 

Figura 5: Trama de red del comando "Get Info" en NetBus

Tras ver esto quise interactuar con el bicho a través del script, era como meterle mano al juguete que tenía de pequeño. El código al final era algo así: 

Figura 6: Código para lanzar un Get Info desde Ruby

Es sencillo, si el socket está abierto se manda por él el texto GetInfo con el delimitador 0d al final y esperamos a que patch.exe nos proporcione la información. Una vez recibida, la damos un poco de format sustituyendo los ";" y "|" por saltos de línea y después se muestra.

Fase 3: Controlando NetBus con un módulo de Metasploit

Seguí investigando y jugando un poco con el troyano e implementé también la posibilidad de enviar texto a la víctima, recopilar información sobre el disco duro, por ejemplo listar todos los archivos y carpetas, y la posibilidad de ejecutar unmessage box en remoto, así que me cree un menú con las opciones de control del troyano que quería implementar y empecé con este proyecto personal de verano para crear un programa en Ruby para controlar NetBus que podéis descargar desde aquí, aunque como salió el sol por el norte y decidí que las vacaciones eran para coger algo de color y lo dejé para el siguiente día. 

Figura 7: Panel de control para NetBus

¿Segundo día y también llueve? En efecto, llover y mucho llover por el norte en mis días por allí, por lo que decidí llevar mi pequeño script al mundo Metasploit. Mi idea era hacer un módulo auxiliary, mi prueba de concepto, más didáctico que efectivo en una auditoría, aunque módulos en Metasploit que detectan malware o que detectan paneles de gestión existen. Si visualizamos la rutamodules/auxiliary/scanner/misc podemos encontrar los módulos en Ruby que comentaba. Apoyándome en un módulo scanner el cual ya nos proporciona la posibilidad de escanear rangos de direcciones IP quise implementar la funcionalidad que tenía en mi script anterior. 

Figura 8: Módulo NetBus Detector para Metasploit

Es importante observar los mixins que se incluyen con Tcp, scanner y report. Unmixin es una llamada a un método que es proporcionado por otra clase y que simplifica las tareas que realizamos. Por ejemplo, en el caso de Tcp se nos proporciona connect() y disconnect(). Con la primera se crea un socket contra el puerto y dirección IP que toque, recordemos que un módulo scanner coge rangos de direcciones IP y mediante un bucle se van recorriendo estas direcciones IP. El mixin disconnect() nos permite cerrar el socket. Más adelante en este artículo se muestra una zona de código dónde se pueden visualizar tanto el connect() como eldisconnect(). La función initialize que todo módulo debe incluir permite inicializar el módulo cuando éste es cargado en el framework. Podemos ver que existen ciertos atributos que se configuran a modo informativo sobre el nombre del módulo, autor, tipo de licencia, etcétera. Esta información puede ser visualizada en msfconsole a través del comando info.

Figura 9: NetBus Detector cómo módulo MetasPloit

Por último, la función initialize tiene una llamada importante que esregister_options. Con este método podemos incluir o sobreescribir nuevos atributos o parámetros del módulo. En este caso se indica que el parámetro RPORT por defecto tiene el valor 6000, que como hemos podido ver es un puerto en el que NetBus trabaja. Si decides implementar tus módulos utilizarás esta llamada en algún momento.

Al final la otra función que debe tener un módulo de Metasploit de tipo auxiliary es la de run_host. En esta función se le pasa el target_host, que simplemente será la dirección IP que toque ser escaneada. En otras palabras, como es un módulo auxiliary y de tipo scanner, de forma trasparente al programador el framework le proporciona un bucle que va ejecutando esta función, siendo en cada iteración un target_host distinto. También otra opción viable es la utilización de un número mayor de THREADS, ya que por defecto es 1. Esto también es trasparente al programador gracias al framework, por lo que podemos lanzar distintos hilos que el programador no tendrá que realizar la gestión ni de esto, ni de la llamada arun_host con distintos valores.

Figura 10: Código del módulo auxiliary de NetBus Detector

Como se puede ver en la definición de la función run_host se abre un socket a través del mixin connect. Una vez abierto el socket se espera que patch.exe, el bicho de NetBus nos envíe su versión. Tras esto se imprime la por pantalla que se ha encontrado en una dirección IP una versión de NetBus. En este punto se podría utilizar una expresión regular para asegurarnos que lo encontrado es lo que buscábamos. En el momento que se encuentra una dirección IP infectada se muestra un menú al usuario para que interactúe con él. A modo de prueba de concepto se han implementado algunas funcionalidades para manejar el troyano. 

Figura 11: El panel de opciones de NetBus Detector para controlar NetBus desde Metasploit

A continuación podemos ver cómo se puede lanzar un message box sobre la máquina infectada. Realmente se ha implementado un mini cliente de NetBus en esta prueba de concepto. Posteriormente se muestra la captura dónde se recibe lo que ha pulsado el usuario víctima.

Figura 12: Un mensaje enviado con NetBus Detector desde Metasploit

Por último, quiero mostraros una función interesante como es el listado de ficheros que se encuentran en el disco de la víctima. Tras analizar con Wireshark cómo realiza esta operación paso a comentarla. El cliente legítimo manda un “GetFiles” a través del socket abierto en el puerto 6000, el servidor nos contesta con“DiskDone” y nos indica un tamaño en bytes de lo que ocupa toda la información (textual) que recibiremos. Después de esto, el cliente legítimo abre un segundosocket al puerto 12346 y es dónde tras abrir la conexión se recibe toda la información del disco duro. 

Figura 13: Datos de DiskDone

Tienes disponible el código en mi github NetBus Detector para poder trastear con ello un rato y poder evolucionarlo. Si quieres aprender más sobre Metasploit y un poco del desarrollo en el framework los invitó a leer "mi libro" de Metasploit para pentesters.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor del libro "Metasploit para Pentesters"