martes, 16 de enero de 2018

Proteger tus datos con un RAID 1

Hace un tiempo, os hablé brevemente sobre los sistemas RAIDs. Implementarlos en tu organización es algo fundamental si quieres garantizar la disponibilidad y la integridad de los datos de tus clientes. No obstante, no todos los sistemas RAIDs son igual de válidos para garantizar la disponibilidad de los datos. Yo hoy os planteo el RAID 1 Mirroring[en espejo].



Os voy a explicar cómo montar un sistema RAID en vuestro propio laboratorio de pruebas mediante software, haciendo uso de VirtualBox, y es que si se piensa, un Raid no es más que un grupo de discos, por lo que solamente tendríamos que disponer de varios discos.


Desde VirtualBox puedes irte al almacenamiento y añadir nuevos discos duros. Yo voy a añadir 4, aunque con 2 para el RAID 1 bastaría.


Si nos vamos al administrador de discos, veremos como tenemos "el panorama" antes de realizar y montar nuestro sistema RAID 1 casero. Pero esto nos lo tenemos que imaginar con música de fondo.



Ahora que vamos a aprender a montar un RAID 1 de manera fácil, sencilla y para toda la familia, es hora de que nos pongamos manos a la obra. Los materiales son los que todos tenéis por casa: Un Windows 7, 4 discos duros, uranio enriquecido, un Falcon Heavy y mejunje Art Attack.


Tras eso, tendremos que seleccionar dos discos cualesquiera [por ejemplo el disco 1 y2] y montaremos un nuevo volumen reflejado {un RAID 1, que es el RAID en espejo} al hacer click en el botón derecho y seleccionar esta opción.


Si hemos hecho click en el disco 1, tendremos que agregar el disco 2[o cualquier otro] y viceversa.


Ahora tendremos que asignar un nombre al volumen. Como esto es algo que hice para clase, le pondré ese nombre.


Al pulsar en Siguiente, nos percataremos de que algo ha ocurrido. Veremos que tanto el Disco 1 como el Disco 2 tienen el mismo nombre de volumen.


Y ahora viene la hora de la magia. Vamos a crear dos documentos de texto en el volumen del RAID. Creamos un volumen para que lo podamos usar de manera gráfica, ya que de lo contrario nos sería imposible crear documentos en él.


A continuación vamos a fastidiar y a joder el sistema. En teoría, un RAID 1, hace copias redundantes de los datos entre todos los discos que pertenecen al RAID, por lo que si un disco cae, tendríamos que tener los mismos datos en los demás discos. A ver si es verdad. Vamos a romper el volumen y comprobar que los datos están en los 2 discos.


Y...¡MAGIA! Tenemos los mismos datos en los dos discos. El RAID 1 cumple con su función y además se demuestra que lo que os conté en la entrada donde especifiqué los fundamentos teóricos, demuestro que es verdad lo que conté.

¿Hackeamos el Mundo?





lunes, 15 de enero de 2018

Como hackear unas elecciones. El caso del Referéndum catalán [Parte III: 1 de Octubre]

******************************************************************************
*******************************************************************************

Eran las 8 de la mañana, la votación comenzaba. Con el trabajo que se dieron lo informáticos no relacionados con el Gobierno, todo parecía que iba a salir bien-informáticamente hablando-. Parecía que nada iba a suceder, pues después de 1 mes de innumerables ataques informáticos, era el día de la votación y tenían los medios para votar ¿Qué podría salir mal?


Se abría la votación y...muchos de los colegios electorales estaban sin Internet. La Red Telemática Educativa de Cataluña que conectaba colegios y gestionaba Telefónica estaba caída, había dejado de funcionar.



No, no fueron hackers rusos los responsables de los ataques. Eso fue lo que se trató de vender, pero no fue así. Pero encima, a las 8:30 horas de la mañana del 1 de octubre, los operadores españoles ya bloqueaban la web de la votación. Esto iba de mal en peor.

Aunque claro, lo que bloquean es el nombre de dominio, haciendo que ese nombre de dominio no se asocie con ninguna dirección IP, pero sí que podrían usar la web de la votación si se accedía por su IP en lugar de su nombre de dominio. Esa dirección IP tenía que aportarse a todas las mesas electorales, que son las que se encargaban de registrar quién votaba de manera informática. No obstante, aquí se abre otro problema, y es que en el momento en el que se enviase la dirección IP, la atacarían para que no esté operativa y detener así la votación ¿Cómo decir a qué IP conectarse si la IP tenía que ser secreto? Un IP para toda Cataluña, la cosa se pone interesante.

La solución fue utilizar un proxy repartido por todo el mundo. El primero de ellos estaba alojados en Amazon y la juez se dio prisa para pedir que se bloquease esa dirección IP. La Justicia es lenta para lo que quiere. A pesar de esto, se cree que el requerimiento no llegó a tiempo.

Ahora otro problema, para conectarse al proxy se necesita Internet, y como he dicho antes, a las 8 Internet se había caído. La solución a esto es tan sencilla como utilizar los móviles y compartir wifi con los ordenadores de las mesas. Según me he podido informar, se cedieron muchos ordenadores, tablets o móviles, además de las peticiones que se hacían desde las mesas para que pusieran en modo avión sus teléfonos móviles para evitar problemas en la red.

El proxy salió a la luz y, al parecer, se utilizó forocohes para realizar desde ahí ataques de denagación de servicio. Caía el servicio, se volvía a levantar y desde forocoches se volvía a filtrar las direccions IP y las atacaban. Era un pilla pilla constante.

Pero ¿Cómo se enteraba tan rápidamente forocoches de las direcciones IP? Muchos expertos  de la Fundación Quirium aseguran que se debía a que muchos usuarios publicaban las direcciones IP de forma inocente en Twitter con la intención de dar a conocer las direcciones IP de los equipos de la votación. La otra opción es que las operadoras detectasen el tráficos de las aplicaciones de las mesas electorales y conforme detectaban las IPs, bloqueaban. La última opción es la de posibles infiltrados en las mesas electorales, algo que se sabe que pasó, que un estudiante consiguió hacerse  pasar por vocal de una mesa y pedir las credenciales de su mesa ficticia y registrar el voto de personas, siempre y cuando esa persona no hubiese votado ya.

La forma en la que consiguió esto fue muy inteligente, pues aprovechó que había desconcierto y que muchas mesas no tenían IP o sus servicios caían y llamaba a un número de teléfono que se asignaba a las mesas para que llamasen en caso de fallo. Se ve que ese número se filtró por Twitter, el joven llamó diciendo algo como:

"Buenas, soy del colegio X, no me permite entrar a la web para registrar las votaciones ¿Me podríais asignar unas nuevas credenciales o restaurarme las antiguas?"



Esto lo decía porque la web donde se registraba quién votaba, se requería del identificador de la mesa y la clave de la mesa. El chaval iba preguntando por esos datos y finalmente se los dieron, por lo que pudo crear una mesa electoral falsa y registrar las personas que votaban sin tener ni un solo ciudadano delante. Pero ojo, aquí hay varios matices a tener en cuenta:

  1. Solamente podía registrar la persona que votaba si esa persona NO HABÍA VOTADO ANTES. Nada de la propaganda esa que se distribuyó de que la gente votaba dos veces. No, solamente podía registrar el voto si la persona no había votado.
  2. Como he dicho, registraba el voto en base al DNI [Que no es complicado obtener DNIs haciendo búsquedas con dorks en Google], pero nada de qué votaba cada persona. Registraba la persona que votaba, no lo que votaba, por lo que sería estúpido que un independentista se aprovechase de este fallo para registrar votantes, pues registraría que Pepe ha votado, pero no se registraría su voto, por lo que saldrían perdiendo.
¿Vosotros os imagináis la siguiente situación?

Imaginad que yo soy independentista y como sé de seguridad, me aprovecho de esto para crear una mesa falsa y registrar los votos de mi familia. Por poner nombres, registro el mío, el de mi madre {la llamaré mamaota}, el de mi padre {papaote} y el de mi hermana {hermanita}. Hago esto creyendo que además de la persona que vota, registro también su voto como un "Sí" y así cuando ellos vayan a votar, se les registre el voto aún así y sea un voto doble por cada miembro de mi familia.

Pero eso no pasaría ya que, para empezar, la web permitía registrar el votante si el votante no había votado ya. Pongámonos que registro el voto de mi familia, pues bien, cuando ellos quieran votar, les dirá el sistema que ya han votado.

Anonymous no tardó en aparecer y mostró su enfado con los ataques que se estaban realizando desde Forocoches atacando a la web.


Y contra todo pronóstico, se pudo votar. Una idea pudo frente a la autoridad. Una idea pudo frente a la represión. Porque eso es lo que pasa cuando tratas de educar o gobernar en base al miedo, cuando se termina el miedo se termina el respeto, pues no se ha enseñado a respetar, se ha enseñado a callar.

¿Hackeamos el Mundo?

domingo, 14 de enero de 2018

Manu derrotó a Trinitarios: Por qué la seguridad es esencial [Post-explotación]

*********************************************************************************
********************************************************************************


Tras 5 artículos en los que he hablado sobre cómo hackear o cómo se podría hackear al colegio Trinitarios siguiendo los pasos que se suelen seguir en una auditoria de seguridad, creo que lo mejor es elaborar unas conclusiones que podría corresponderse con la elaboración del informe donde se informa de todos los fallos encontrados durante estas fases. No obstante, no voy a elaborar un informe en sí, solamente decir por qué ha pasado lo que ha pasado o por qué podría pasar lo que ha pasado, ya que en la fase de explotación tuve que especular e imaginar algunos aspectos para no cometer un delito.



La fase de footprinting es una fase muy importante, pues cuanta menos información se pueda obtener de una organización o sus trabajadores, mejor para la organización. Imaginad que con una búsqueda en en Google doy con un login de la organización, busco el manual de dicho servicio de login y me encuentro con su contraseña por defecto, la pruebo en el login que he encontrado y ¡Eureka! he conseguido entrar. Esto se ha logrado con el footprinting y con la información encontrada sumada a algunas debilidades.


Esta parte es, posiblemente, la más importante, pues ya podrías elaborar el plan de cómo atacar, ya podríamos elaborar el vector de ataque con la información obtenida en la fase anterior.


Con esta fase ya tenemos que tener cuidado pues podríamos estar cometiendo un delito, pero en esencia "es lo mismo", tendríamos que basarnos en la información anterior, de ahí la importancia de las dos fases anteriores.


Aquí es ya conocimiento puro y duro y saber aplicar la información que se ha obtenido, ya sea con el footprinting, fingerprinting y el análisis de vulnerabilidades siendo esta última fase de gran importancia, pues tú tratarás de explotar las vulnerabilidades que se hayan podido encontrar en el análisis anterior, aunque no deberíamos limitarnos a eso, tendríamos que tratar de encontrar vulnerabilidades, aunque no sean 0-zay, pero que el análisis no haya encontrado.


Esta fase es, al menos para mi, bastante compleja, pues dependen de varios factores, ya no sólo de la máquina que ya has conseguido atacar. Por ejemplo, puedes usar el Pass the hash siempre y cuando dos máquinas tengan el mismo administrador con la misma password, algo que es frecuente, pero que puede no darse, por lo que tendrías que buscar otras formas de lograr acceso a otras máquinas, y eso no es siempre tan fácil.

Y en esencia ha sido sólo eso, una auditoria es un proceso muy complejo y encima tratar de hacerlo atractivo. Es complejo pero cuando sale, es algo maravilloso y muy divertido {aunque para la empresa no lo sea tanto}.

¿Hackeamos el Mundo?


sábado, 13 de enero de 2018

Tengo una página en Facebook

No soy un usuario frecuente de Facebook, pero este año quiero usar más esta plataforma, pues tiene un importante potencial. Así pues he decidido crearme una página de Facebook donde iré publicando cada entrada y algunos adelantos.



Aquí os dejo mi página de Facebook para que si queréis estar al tanto de qué entradas serán las próximas en salir, podáis verlo a modo de "trailer".

¿Hackeamos el Mundo?

viernes, 12 de enero de 2018

Acceder mediante una dork al archivo /etc/shadow y descifrar las contraseñas

En sistemas Linux, las passwords de todos los usuarios se almacenan en el documento /etc/shadow. Acceder a ese archivo podría resultar realmente peligroso pues, además de conocer los usuarios existentes en un sistema{que no es poco}, se podría conocer su password, lo que lo hace potencialmente peligroso.



Como parece algo tan peligroso, parece lógico que dejarlo por ahí a la vista de todos y todas, sería algo que sólo se le ocurriría a una cabeza alocada. Pues bueno, esto les ocurre a muchos administradores de sistemas.



La dork es bastante sencilla y podremos conseguir 72 resultados. No todos los resultados arrojan una lista con los usuarios y sus contraseñas, pero sí que hay algunos que muestran información muy interesante.


Hay algún que otro sitio web que muestra esta información de usuarios y contraseñas, y aquí viene la segunda parte que se debería realizar una vez que obtenemos esta información, y es que si nos fijamos en el usuario root, la línea que nos sale es

root:$1$XPo5vyFS$iJPfS62vFNO09QUIUknpm.:14360:0:99999:7:::

No obstante,la parte con la que nos vamos a quedar va a ser root:$1$XPo5vyFS$iJPfS62vFNO09QUIUknpm. La primera parte hace referencia al usuario, root en este caso. En esta linea el limitador es :, es decir, que los dos puntos separan el usuario de la contraseña. Sabiendo esto, vemos que la contraseña tiene una forma un poco extraña.

La contraseña está cifrada y con un salt, algo que ya os comenté en la entrada Fucking to your bullshit code y que hace unos días comenté por qué sería recomendable usarlo en entornos como unas elecciones. Así pues, tenemos la siguiente contraseña shadow hasheada con una salt.

$1$XPo5vyFS$iJPfS62vFNO09QUIUknpm.

Si destripamos cada parte de la contraseña, tendremos lo siguiente:

  • $1$ nos dice que tenemos en frente un cifrado en MD5.
  • XPo5vyFS. Es el SALT que se usa para generar el hash MD5.
  • iJPfS62vFNO09QUIUknpm. Es el hash salteado de la contraseña.
Conocer bien esto es importante para tratar de realizar el proceso inverso, ya que si sabemos cómo se genera el hash salteado, podremos disponer una lista con posibles contraseñas, realizarle el hash salteado a cada palabra y compararlas con la contraseña hasheada que sacamos del documento /etc/shadow y si coinciden, que nos diga qué palabra es la que coincide y conoceremos ya la contraseña.



Esto lo podemos hacer con John The Ripper que ya viene por defecto en Kali Linux o con un script en shell script que nos creemos. Yo lo he probado con un script en shellscript que me he creado, pero ya aviso que tarda mucho tiempo a pesar de tener un documento llamado wordlist con varias contraseñas, entre ellas una que yo mismo hasheé. Yo lo dejé toda la noche y se tiró más de 2 horas.

Como veis es relativamente sencillo poder obtener la contraseña de un usuario en sistemas Linux. Esto puede ser muy interesante en entornos de post-explotación como en el caso del Hackeo a Trinitarios en los que enviamos el shellcode por carpeta compartida en red, aunque si la empresa en cuestión tuviese un FTP montado en un Linux, esta forma de obtener contraseñas es algo ideal para entrar como administrador al FTP o incluso como admin al servidor web.

¿Hackeamos el Mundo?



jueves, 11 de enero de 2018

Meltdown & Spectre: Lo de siempre, mucho ruido pero pocas nueces

El pasado 3 de enero se descubrió el primer gran fallo de seguridad del año 2018. Un fallo en los procesadores de Intel y AMD sobre todo. Se creó mucho ruido y yo la verdad es que tenía poco que decir, pues se trataba de, en principio, un fallo a nivel Hardware y yo de hardware no tengo ni puta idea, pero cuando por la noche sacaron los papers y me animé a tratar de informarme, no me resultó muy difícil de entender y aunque no conozca ni sea un experto en Hardware, voy a tratar de explicarlo de la manera más sencilla posible.


Antes de nada, os recomiendo leer los papers donde se hablan de los fallos de seguridad en cuestión, ya que son muy sencillos de leer. Si yo, sin tener ni idea, me he enterado más o menos, cualquiera puede asimilarlo y digerirlo bastante bien. Aquí os dejo el paper donde se explica Meltdown y aquí os dejo el paper donde se explica Spectre. Reitero que son fáciles de leer y que son 16 páginas donde se explica todo muy bien. Dicho esto, voy a tratar de explicar cada fallo y tratar de explicar sus repercusiones.

Ambos ataques se aprovechan de unas determinadas configuraciones de los procesadores modernos. Este fallo es algo bastante peligroso, y más si tenemos en cuenta que la seguridad de los sistemas de ordenadores dependen, en esencia, del aislamiento de la memoria. En el paper de Meltdown ponen un ejemplo muy clarificador. El ejemplo que se pone es el de que las direcciones Kernel están marcadas como no accesibles y están protegidas del posible acceso de los usuarios.

Ambos ataques se basan en la característica de los procesadores de la ejecución out-of-order {fuera de orden}, lo que permitiría leer localizaciones arbitrarias de memorias Kernel, incluidas, por ejemplo, información personal y contraseñas.

Un procesador no se limita a ejecutar una orden detrás de otra, ya que tienen una gran capacidad de cómputo, y tener que esperar siempre a la entrada de un dato o de un fragmento de código, haría que muchas veces estuviese sin hacer nada, por lo que para no quedarse en reposo, tiene que haer otras tareas como tratar de predecir la siguiente línea de código que se va a ejecutar.


Por poner un ejemplo. Imaginad que está leyendo un código shellscript y lee la línea que os muestro en la anterior imagen. Pues para no quedarse parado, tratará de predecir la siguiente línea, ya que sino desaprovecharía su potencial y rapidez. Así pues, "sabe" que después de un for en shellscript, suele venir un do.


Y sigue un algoritmo muy sencillo. Si acierta, sigue como si nada y ha ganado tiempo, sino acierta, descarta lo que ha hecho. Fácil y para toda la familia.

El problema -si se puede calificar como tal- reside que al intentar realizar esa predicción, deja "una huella", tanto si aciertan como si fallan. Y aquí vienen nuestros dos protagonistas. Tengo que decir, que me parece que son muy complejas de explotar, aunque puede que me lo parezca porque no soy un experto en temas Hardware. No obstante, sea o no sea complejo de explotar, es una vulnerabilidad y existe ese riesgo.

Meltdown

Esta parece ser la vulnerabilidad más grave y, en principio, sólo afecta a Intel. El ataque está explicado a partir del punto 5 del paper donde se describe el ataque.


Usando esta técnica, se podría acceder desde un proceso con bajos privilegios a la zona reservada en el mismo para el Kernel, lo que podría conllevar a que dicho proceso tuviese acceso a tu memoria física. Una de las cosas más interesantes sería la de volcar cualquier región de la RAM para extraer información confidencial.

Hay que tener varias cosas en cuenta aquí. La primera es que realizaron la explotación de la vulnerabilidad en ordenadores personales y en máquinas virtuales destinadas a la nube y, como he hecho alusión, se montaba un escenario en el que el atacante no tenía privilegios y trataron de, a partir de ahí, ganar privilegios dentro del sistema con esta técnica. Lo segundo es que los autores, asumieron que los sistemas están protegidos completamente por el estado del arte del software basado en técnicas de defensa ASRL Y KASRL, al igual que características de la CPU como SMAP, entro otras técnicas. Y lo más importante, para asegurarse que habían escalado privilegios por la explotación de esta técnica y no por cualquier otra vulnerabilidad en el software del sistema operativo, usaron Software Libre y así cerciorarse.


Aquí os dejo la tabla de las pruebas que realizaron los autores, aunque si queréis información más detalla, en su paper lo explican todo muy bien, facilitando mucho el entendimiento. Antes de continuar, me gustaría detenerme en algo, que cuando se lo estaba explicando a mi pareja, me percaté que a lo mejor no todo el mundo entiende. Cuando se refieren a proceso, se refieren a un programa en ejecución y uno de esos programas podría ser Google Chrome, Office o cualquier otro programa{proceso} que te descargues en tu ordenador, por lo que si soy un atacante, me daré prisa en desarrollar un programa que se aproveche de esta vulnerabilidad y esperar que la gente se lo descargue.

Es ahí, donde yo puedo encontrar esta técnica como más sencilla de realizar, pues usarlo en entornos de malware como los que ya he comentado a lo largo de este año en el blog-De este año pasado, me refiero-.


Esto lo autores lo han llevado a la práctica con una PoC en la que han realizado un volcado de la RAM mostrando las cabeceras HTTP en un Ubuntu 16.10 con Intel i7-6700K.


También han realizado un volcado de la RAM del mismo sistema anteriormente mencionado con Firefox 56, mostrando las contraseñas guardadas en el navegador.


Sergio de los Santos, informó en su cuenta de Twitter, que existía una forma de mitigar que Chrome sea una vía de explotación, que no resuelve el problema, pero que al menos no es una solución tan drástica como la que propone el US-CERT de cambiar la CPU. Os dejo su tweet.


Hasta el momento, me consta de que Microsoft ya ha lanzado el parche para Windows 10, el cual lo han llamado KB4056892. Además os dejo un Tweet con un GIF donde se muestra cómo se podría obtener una password.


El turno de Spectre

Spectre sí que afecta a todo tipo de procesadores, aunque es una vulnerabilidad mucho más difícil de explotar. Esta vez no basta con un ataque basados en esquemas de malware en el equipo. Yo no he conocido -a día de 4 de enero- que haya salido ningún parche para Spectre, aunque, en teoría, deberían ir saliendo parches con el paso del tiempo. Como no conozco mucho más acerca del tema de Spectre-sólo lo leído en los papers- no quiero caer en decir cosas que no son y desinformar. Aunque ahora que me sacáis el tema de la desinformación.

Los medios. Sensacionalistas difusores de desinformación



Me gustaría preguntar a todos los periodistas que han hablado sobre los fallos de seguridad si le han dedicado unas horillas para leerse los artículos y saber de qué va el tema en lugar de hablar y provocar miedo. Este 2018 voy a ser aún más crítico con los medios de comunicación. Si no queréis leer, al menos preguntad a gente que sepa del tema, llamad a los autores, pero no habléis por lo que leéis en Twitter. Haced vuestro trabajo que para algo os pagan, para informar, no para desinformar y hacer que la gente se lleve las manos a la cabeza sin razón. Si aún después de leer los artículos y/o preguntar a expertos seguís sin entenderlo, decid "hasta aquí sabemos, hasta aquí nos hemos informado". Pero no, es mucho mejor crear morbo, con titulares poco apropiados y con artículos que no explican nada. Haced vuestro trabajo y dejad de decir estupideces, que el dinero que ganáis es de gente trabajadora, dejad de robarnos, no hacéis vuestro trabajo.

Si eres un periodista, apunta esto, abre bien los ojos. El usuario medio NO VA A NOTAR ESE 30% MENOS DE RENDIMIENTO. Meltdown, el "más fácil de explotar" corre bajo procesos que realizan múltiples cambios al modo Kernel. Esos procesos no son ni juegos, ni ofimática, ni programas de edición de fotografía o vídeo/audio. Se han realizado pruebas tras aplicar las pruebas y muestran una pérdida del rendimiento en equipos personales que roza el 0%. No obstante, los que sí se ven afectados son esas máquinas virtuales de las que hablé al principio y "data centers"{casos de cloud como Amazon o Microsoft con Azure}. Aquí, en estos entornos, la seguridad sí tiene que ser máxima para garantizar la integridad de los datos de los usuarios. Si eres un usuario medio, simplemente ten actualizado tu sistema operativo y aplica los parches que salgan para tu sistema y en serio, tienes más peligro de ser hackeado por un Phishing que por Meltdown{Y la probabilidad de ser afectado por Spectre ya ni te digo, es muy baja}.

El mayor "problema" para Intel va a ser que en lugar de dominar como dominaba en los data centers, ahora va a tener mayor competencia, una competencia sana que les va a hacer mejorar. Intel se va a recuperar, lo que no me explico es por qué los periodistas siguen alarmando a la sociedad tras cada incidente de seguridad ¿No se cansan de equivocarse? Siempre crean un estado de alarma innecesario por no informarse como se deben ¿Tan estúpidos son?

¿Hackeamos el Mundo?

miércoles, 10 de enero de 2018

Cómo hackear unas elecciones. El caso del Referéndum catalán [Parte II:Septiembre]

******************************************************************************
*******************************************************************************

Tras la entrada anterior a esta en la que os conté un poco la historia de Cataluña, no me queda otra que comenzar con la parte de Seguridad Informática y de qué y cómo se hizo lo que se hizo, tanto por una parte como por otra. Aunque no quiero empezar sin antes criticar duramente a todos esos "expertos en Seguridad Informática" que se han callado sobre el tema cuando hay mucho que decir, tanto por un lado como por otro. Mi total desprecio a todos los que han callado sabiendo sobre el tema. A los que, por otro lado, habéis hablado, mi enhorabuena.


Iré por partes, comentando todo lo ocurrido siguiendo un eje cronológico que pueda aclarar a todo el mundo qué se hizo y, sobre todo, cómo. Empecemos por Septiembre.

El 13 de septiembre, alrededor de las 19,00 horas, se cerraba la web sobre el referéndum. El cierre lo realizó la Guardia Civil con una orden judicial del Juzgado de instrucción número 13 de Barcelona que estaba investigando el caso. Así pues, a las 19,00 horas del 13 de septiembre referendum.cat estaba cerrada.



Se consiguió que la web de referéndum en lugar de estar como se muestra en la imagen anterior, luciese así.


¿Y esto cómo de pudo hacer? Puede ser la pregunta de muchos. Pues la verdad es que es bastante sencillo con una orden judicial, ya que la Guardia Civil tenía permiso de un Juez para hacer lo que les diese la gana con la web en cuestión con tal de cerrarla. Por el código a introducir, la verdad es que es muy sencillo.


Como veis es programación web muy básica donde se aplica html y javascript, ya que a donde se va a redirigir es una web con una foto. Esa web es una web que la Guardia Civil dispone para casos en los que debe cerrar la aplicación web. El punto fuerte del código es el apartado del script [INCISO: En el código me he equivocado al tomar la captura. La parte equivocada es la de "<script...> y es que en el tipe es /javascript y no /javasript; me he comido la c. Sorry]. Ahí no se hace otra cosa que en el <h1> dar un name determinado para que posteriormente en la variable 'name' recojamos los elementos con id "causa" y los atributos name. A continuación crea una variable vacía que se completará más adelante. Ahora viene "Un menTOCAMOS TODOS LOS PALOS, INCLUIDOS LOS DEL FLAMENCO
ú" que se crea con switch en el que en función del valor recogido en name="" mostrará una cosa u otra. En nuestro caso como el name es igual a "WEB_INTERVENIDA" nos redirigirá a la web localhost/intervenida.html {localhost porque lo estoy haciendo en un entorno de pruebas}. El documento intervenida.html solamente contiene la imagen que pone siempre la Guardia Civil cuando interviene una web.


No es nada del otro mundo, no hace falta ser un genio para intervenir páginas webs trabajando en la Policía, ya que para esto debes tener una orden judicial que te de acceso a los servidores de la web. Una vez que se tiene acceso no hay problema en cambiar el código de la web por el que os he mostrado. Podéis probar vosotros mismos con los códigos que os dejo y disponer de este entorno de pruebas en vuestro laboratorio.

Por lo visto, la primera web del referéndum era de lo peor desde el punto de vista de la seguridad. Tal y como aseguran algunos expertos, es un ejemplo de todo lo que no hay que hacer, pues era un wordpress con pluggins desactualizados que permitía inyectar código, y todos sabemos lo que eso significa.



Pero la gente que quería votar, no se quedó de brazos cruzados, crearon una segunda y tercera web que se replicaron. Carles Puigdemont [Presidente de Cataluña] compartió varios tweets donde daba información y daba a conocer las webs en cuestión. Estaba siendo un duro pulso.




La Guardia Civil contraatacaba interviniendo Fundació puntCAT y obligó a cerrar todos los dominios .cat que tuviesen que ver con el referéndum. Eso era 1 semana después, el 20 de septiembre. Nos acercamos a la fecha de la votación [1 de octubre] y la gente que quería votar parecía que iba perdiendo.

El día 22 de septiembre, llegaba algo bastante gordo. La Guardia Civil entró en casa de Dani Morales, un chico valenciano que solamente había compartido una lista de enlaces de las webs replicadas sobre el referéndum. Sí, ya sé que podéis pensar que este chico es un delincuente muy peligroso, que comete delitos tan graves como compartir una lista de webs, unos delitos que hace que los millones que robó Urdangarin o Bárcenas se queden en minucias. Como no quedaba muy democrático decir que entraban en su casa por no opinar lo mismo que la jueza que dio el visto bueno dijeron algo como "Este además de ser independentista, toma drogas, buscad en su casa drogas en sus discos duros y su teléfono móvil". Aún después de esto, aún se decía que "demasiados buenos han sido, que la intención erra borrar su huella de Internet". Vamos, un asesinato virtual. Bravo.


Por cierto, un apunte a los periodistas que dijeron que este chico era un Hacker. El chico es un Hacktivista, no un hacker. Con el trabajo que costó que la Rae diga que Hacker no siempre es un cibercriminal, no lo volváis a estropear.

También se detuvieron a otros jóvenes que duplicaron las webs proreferéndum. Los jóvenes se negaron a declarar. También se cerró dichas webs e incluso la web de la Asamblea Nacional Catalana.


Tal y como declara el OONI [Open Observatory of Network Interference] se han contabilizado al menos 25 sitios webs intervenidos que tenían que ver con el Referéndum catalán.



OONI asegura que estos bloqueos cibernéticos, se realizaron por varios ISPs como Euskaltel o Telefónica España.


Se concreta que Telefónica lo que realizó fue bloquear el protocolo HTTP para que en lugar de la web de inicio del referéndum, se mostrase la imagen de que la web había sido incautada por la Policía.

¿Cómo tratar de parar la represión?

Esta parte me parece muy ingeniosa y, a pesar de algunos matices, considero que el esfuerzo realizado fue realmente alto. Esto no sé si lo ven los que más mandan, pero me gustaría que se viese cómo la gente hacía lo posible por, simplemente votar.




El Presidente Puigdemont estaba haciendo lo imposible para que todo el mundo pudiese estar informado a cerca del referéndum. Tal era el esfuerzo que hasta subió a su cuenta de Twitter un manual sobre cómo conectarse a un Proxy.


Tal era el ruido mediático que Julian Assange consiguió que el co-fundador de The Pirate Bay, Peter Sunde. Mucho ruido para algo que se ha podido solucionar fácilmente y, sobre todo, sin represión.

Pero el bloqueo no era solamente en Internet, también se bloqueó las comunicaciones postales, por lo que no se pudieron enviar las notificaciones sobre la votación. De nuevo Internet entraba en juego. El día 21 de septiembre, en la cuenta de Twitter del Presidente Catalán, se publicó la web que se llamaba "¿Dónde votar?", pero al día siguiente ya había una orden judicial para cerrarla. Y decían que la Justicia era lenta [a lo mejor lo son para lo que quieren]. Por supuesto, como se estaba haciendo con las otras webs, la web ¿Dónde votar? se replicó en Twitter, Whatsapp, Telegram, Facebook e incluso en una aplicación de Android, que ¡Adivinad qué! El Tribunal ordenó a Google eliminar.


Si a día de hoy nos vamos a la web ¿Dónde votar? Lo que nos encontraremos será algo como lo siguiente.


Pero aquí ya había una sutileza, esta web no era tan fácil de cerrar, ya que estaba alojada en una red distribuida, sin un punto central que se pudiera intervenir. Pero al final, el 25 de septiembre, Telefónica cerró esa puerta a gateway.ipfs.io. Esta web, además de estar alojada en una red distribuida, fue elaborada para ser replicada con facilidad. No obstante, a pesar de esta gran idea, la web disponía de algunos fallos graves de seguridad que, en cierto modo entiendo, ya que se estaba haciendo todo con prisas por los cierres anteriores.

El caso es que cuando se duplicaba la web, se duplicaba TODA LA WEB, incluida la Base de Datos que, en lugar de estar bajo un MongoDB o cualquier otro gestor, estaba en claro. Esa Base de datos, por la propia naturaleza de la web ¿Dónde Votar? asociaba a cada ciudadano con el lugar al que debía acudir a votar el 1 de octubre.

Hay que decir que cada entrada a la Base de Datos se identifica con un hash generado con los siguientes datos:


  1. 5 últimos dígitos del DNI
  2. Letra del NIF
  3. Fecha de nacimiento
  4. Código Postal.
Dicho hash se genera mediante una serie de interacciones de SHA256 sobre esos 4 datos. Ese hash se genera sin salt, y esto es un problema del que hablé en "Fucking your bullshit code". Si a eso le añadimos que el código postal y la fecha de nacimiento es predecible y se repite, facilita el ataque por comparación de hashes. Además, aunque falten las 3 primeras cifras del DNI, sigue incluyendo la letra, y la letra sale tras una serie de operaciones que cualquier niño de Primaria sabe hacer, que se realizan con los números del DNI. Como faltan 3 dígitos, hay 10 posibles número en cada hueco [de 0 a 9], por lo que sabemos que es una combinatoria con repetición, así que aplicando la fórmula, obtenemos lo siguiente.


Vemos que hay 220 posibles combinaciones, lo que para un ataque de fuerza bruta, no es mucho, y más si pensamos que las primeras son combinaciones de las que podemos prescindir como 000, 001,002,etc. Por lo que se nos quedan muchas menos combinaciones y si ya encima reducimos posibilidades por localización, nos pueden quedar, como mucho, 50 posibles DNIs.


Así que si usamos la Teoría de Grafos, veremos que, a poco que cada nodo duplique las webs 2 veces, veremos que ya en la tercera capa, tendríamos las webs duplicadas 7 veces, con los datos de esa gente ampliamente duplicados. No obstante, entiendo que lo que buscan no es seguridad, pues era una lucha socio-política y como en todas las luchas de este tipo {a los hechos históricos me remito} tienden a suprimir seguridad a favor de la libertad. Si se tiene que dejar una hornacina en la seguridad por luchar por la libertad ¿Quiénes somo nosotros para criticarlo? Y en caso de creemos con la superioridad moral de poder criticar ¿Por qué no criticamos con la misma dureza a todas las webs que comentan los mismos fallos de seguridad? ¿Por qué se aprovechan estos fallos para criticar una idea social influida por la clase política?

Búsqueda de nuevos caminos para evitar toxicidad informativa

Las redes sociales se estaban llenando de propaganda y de toxicidad informativa por ambos lados, así que el grupo independentista buscó nuevos caminos para filtrar noticias que venían de medios cuya intención era manipular a la opinión pública. Un ejemplo es cómo las manifestaciones a favor del referéndum se cortaban en el momento, y una manifestación franquista en Madrid el día de antes de la consulta, nadie quiso mirar ni ponerlo en primera plana en los periódicos, vaya a ser que la gente se de cuenta de lo que está pasando en su queridísimo país.

Con el miedo en el cuerpo de los grupos proreferéndum a ser espiados por el Gobierno español, tomaron camino a la red social Telegram para evitar las noticias sensacionalistas. Aún así, hubo mucha gente que seguía usando los Grupos de Whatsapp.



Hubo mucha confusión pues las redes sociales y servicios de mensajería como Whatsapp seguían repletas con artículos, recogidas de firmas y sobre todo, mentiras sistemáticas. Pero esto parecía que estaba funcionando perfectamente para el Estado español, pues se acercaba la consulta y seguía el debate sobre llevar o no la papeleta de casa.

Así pues, se creo una sociedad virtual hasta que el 30 de septiembre, se anunciaba que era muy posible que la Guardia Civil cortase Internet de toda Cataluña. Hay gente que dice que eso no sería posible, pero es que no les hacía falta cortar Internet, con modificar archivos de resolución DNS para que les llevase a webs que o no existen o no son de la consulta, les bastaría. No corta pero sí que "modifica" Internet.

Y ya por la tarde del 30 de septiembre, parecía que la Guardia Civil había ganado al entrar en el centro de Telecomunicaciones de Cataluña y requisar todo el sistema informático con toda la información sobre la consulta, incluída una base de datos de catalanes en el exterior.

Trabajando por la noche

Pero la gente quería votar y así hicieron todo lo posible por lograr votar si querían permanecer o no en España. Lo que se hizo fue que un grupo de informáticos que no pertenecían al Gobierno pero que eran proreferéndum, realizaron una web que estaría alojada en registrameses.com, alojado en Amazon y con la protegidos con CloudFare. La web lo que hacía es permitir la votación por Internet de forma que el responsable de la mesa de turno introducía tu DNI y se votaba. Aquí ya hubo polémica con esta web, pero eso ya os lo comentaré en la tercera parte de esta serie de entradas, pues entramos en octubre, en el día de la consulta.

¿Hackeamos el Mundo?
Related Posts Plugin for WordPress, Blogger...

Entrada destacada

BOUM!! "ARRANS" DE SUELO

WE ARE SEX BOB-OMB!!! ONE, TWO, THREE!!!...Así empiezan las canciones el grupo de mi cómic favorito, Scott Pilgrim. Scott Pilgrim es un gran...