• Facebook
• Twitter
• Reddit
• LinkedIn

Uno de los pasos en la fase de reconocimiento o colección de datos sobre un objetivo, es averiguar que IPs están asociadas con el mismo. Para ello, una forma muy usada es buscar los ASN asociados a éste, y a partir de ahí usar alguna herramienta a la que le podamos pasar dicha información y nos de las IPs asociadas.

Una web que ofrece datos bastante precisos es Electric Hurricane. De ahí podemos sacar la lista de ASNs, volcarla a un fichero y luego mandar dicho fichero a alguna herramienta como nmap, amass, etc.

Este fin de semana me entretuve un rato jugando con este modelo y decidí automatizar el proceso del volcado de ASNs de Electric Hurricane. Para ello inicialmente intenté ejectuar curl para la extracción de dichos datos, pero esto no resultó ya que la página que muestra datos ejecuta javascript para los mismos, luego intenté hacer web scrapping, esta opción tampoco funcionó y tampoco quería usar algo como Selenium, así que por último intenté usar un navegador en modo headless, y así pude grabar la página con los datos y luego a través de un script en python extraer la información. Para automatizar todo y no tener dependencias de navegador, python, etc, decidí montar todo este tinglado en Docker (sí, es otra dependencia, pero más limpia :) ).

Podéis encontrar el proyecto en github, y lo podéis usar de la siguiente manera:

docker run -it --cap-add=SYS_ADMIN tuxotron/asn-search aol

aol
AS15445
AS13084
62.51.0.0/16

Para volcarlo a un fichero sólo tienes que redirigir la salida a un fichero y luego usarlo como fuente de alguna otra herramienta.

De vez en cuando te encontrarás con el siguiente error:

[0227/012256.257103:ERROR:headless_shell.cc(481)] Failed to serialize document: Uncaught

Por lo visto es un error en Chromium con la opción headless.

De todas formas, si te da ese error, ejecuta el comando varias veces más y debería de funcionar.

No es más que un proyecto de fin de semana… Happy Hacking!

• Facebook
• Twitter
• Reddit
• LinkedIn

El pasado miércoles 6 de noviembre en La Sexta emitieron el tercer documental de la tercera temporada de Enviado Especial, en el que Jalis de la Serna nos lleva desde el norte de España hasta la costa oeste de los EEUU. En éste, Jalis se adentra en la “nube”, muestra el peligro del rastro de los datos que vamos dejando consciente e inconscientemente, pasa por un centro de desintoxicación tecnológica, se adentra en Microsoft, Google, y acaba hablando con Javier Marcos y su esposa.

Si no has visto el documental y deseas hacerlo, lo puedes ver desde aquí. Si estás fuera de Europa quizás no puedas verlo a través de ese enlace. Yo, desde EEUU, no lo puedo ver, a menos que salte por algún proxy en Europa (desde Alemania funciona).

El motivo por el que escribo esta entrada es para: agradecer a Jalis y a todo el equipo que lleva detrás: Erea, Raquel, Elena, Marcos, Armando… posiblemente se me olvida alguno, y también para añadir algunas cosas que les comenté durante la grabación, pero que al final no se pudieron poner. Entiendo que en la televisión el tiempo es oro y se miden las cosas al segundo, por no decir al milisegundo.

Cómo comenzó todo

Todo comienza cuando una mañana me levanto y tengo un mensaje de mi compañero de batalla y gran amigo Fran Ramírez diciendo que Chema Alonso (¡Qué crack!) le había dado mi información a Antena3 porque les habían preguntado por algún “hacker” en Virginia (EEUU), que hablara español.

A partir de ahí, efectivamente recibo un email y empezamos conversar, y durante mi paso por la RootedCON X, tuve la oportunidad de ir a los estudios de Antena3 en Madrid y conocer en persona a parte del equipo detrás del programa de Enviado Especial y nos comentaron (me acompañaba Cybercaronte) lo que querían hacer. Y dos meses más tardes, Jalis junto a su equipazo, apareció por Virginia.

Anécdotas

Una de las curiosidades sobre el rodaje, es que éste se hizo en dos días. En la escena en la que me voy a tomar café mientras Jalis va al centro de datos se rodó un sábado, y la parte en la que estamos en The Mall se rodó el domingo. En el documental parece que todo ocurre el mismo día, por ello me pidieron que llevara la misma ropa ambos días. Así que me hice dos camisetas iguales, una para cada día.

Otra curiosidad fue, que cuando estábamos grabando la parte en la que le enseño a Jalis los datos que había encontrado suyos, casi no podía ver la pantalla. El día estaba muy soleado, de hecho hizo bastante calor, y además de eso no llevaba mis gafas, que normalmente uso, así que no fue nada fácil el hacer esa parte :D

Parte de lo que no se vio

Durante los dos días de rodaje, grabamos muchas conversaciones que no fueron parte del documental y a algunas de las cosas que sí aparecen, me gustaría darles un poco de contexto.

Cuando hablamos de la huella digital, tenemos que tener en cuenta que esta se va formando por los datos que vamos dejando de forma consciente e inconsciente. Tenemos que tener en cuenta que cuando usamos servicios, especialmente los que son gratuitos, estamos pagando con nuestros datos, es decir, cualquier dato que ese servicio pueda registrar, acabará en alguna base de datos que será usada en algún momento para beneficio de la empresa que ofrece dicho servicio, normalmente de forma financiera. Luego, tienes que tener mucho cuidado con lo que dices y subes a internet, un dato por sí sólo puede parecer muy inofensivo, pero cuando juntamos varios de esos “datos inofensivos”, ya se pueden convertir en datos lo bastante sólidos para poder usarlos de forma dañina. En el documental se comenta, que con los datos que había descubierto sobre Jalis, podría llamar a la operadora de telefonía móvil y haciéndome pasar por él, hacer cambios en su cuenta. Esto, también se podría usar de la otra forma, yo, haciéndome pasar por un empleado llamar a Jalis y sacarle información que pudiera usar para delinquir. Mi consejo, es que nunca confíes en llamadas que recibas o emails. Si te llaman del banco, de tu operadora de telefonía, etc, preséntate en persona si puedes en una de las sucursales, y si no, ve a la página oficial de internet, busca el teléfono o la forma de contacto. Nunca sigas enlaces en emails o información dada por teléfono de una llamada que no esperabas.

Otra cosa que se comenta de forma muy breve es el tema de las cookies. Las cookies, no son necesariamente malas, y no son siempre usadas para monitorizar a un usuario, aunque desafortunadamente es quizás, aún, la forma más común usada. De hecho existen métodos más avanzados para la monitorización de usuarios.

Como dato histórico, las cookies se crearon por la necesidad de mantener lo que se llama la sesión de usuario, y esto ocurrió con la llegada del carrito de la compra (eCommerce). Para que un sitio web pudiera saber que cosas añade al carrito cada usuario, se crea un identificativo único que identifica a cada usuario, dicho identificativo se guardaba en una cookie. El hecho de que cuando te conectas a un sitio web (tu red social preferida, tu correo electrónico, etc) y sólo tengas que introducir tu contraseña una vez y puedas ir navegando por dicho sitio web sin tener que introducir dicha contraseña cada vez que hagas un click en algún enlace o botón, es porque ese sitio web ha creado una sesión única para tí, y la identificación de dicha sesión, esté posiblemente guardada en una cookie.

En el documental también se menciona brevemente el uso de Signal como medida de protección de nuestra privacidad. Signal no es más que una aplicación de mensajería como WhatsApp, por lo que el uso de Signal sólo te protege (tu privacidad) a la hora de mandar mensajes y no a la hora de navegar por internet, ni de las cosas que subimos a las redes sociales. ¿Por qué Signal y no WhatsApp, Telegram…? Bueno Signal es open source, esto quiere decir que el código la aplicación y del protocolo que usa están accesible para poder ser revisado por expertos en criptografía. Sí, WhatsApp actualmente usa el protocolo de encriptación de Signal. La diferencia es que Facebook (propietario de WhatsApp, y competidor directo de Google en el mercado de la publicidad) almacena y guarda tus mensajes en sus servidores por 30 días, Signal dice que tus mensajes no son almacenados y sólo pueden ser leídos por su destinatario, y Telegram, pues parece que encriptan tus mensajes en sus servidores, claramente estos tienen acceso a todos tus mensajes de forma clara. Al final del día, tienes que depositar tu confianza en alguien, y yo la deposito en este caso en Signal, apoyada por la organización sin ánimo de lucro Electronic Frontier Foundation (EFF), en la cual confío y apoyo su misión, de hecho soy miembro de la misma. Por cierto la gorra que llevo en el vídeo es de dicha organización.

Una de las conversaciones que tuve con Jalis, fue sobre la importancia de encriptar nuestros datos. Está claro que si encriptamos nuestras comunicaciones, protegemos nuestra privacidad, pero también podemos proteger la de otros. Para explicar esto, le puse tres escenarios distintos, en el supuesto que fuera un periodista en un país autoritario, en el cual se está comunicando con un activista para organizar algún tipo de movimiento contra el gobierno:

• Nadie encripta: en este caso el gobierno podría espiar libremente las comunicaciones y buscar ciertas palabras o frases que enciendan las alarmas. Lo mejor que te pueda pasar es que sólo seas arrestado.

• Sólo encriptamos cuando tenemos algo que ocultar: en este caso, aunque el gobierno no pueda leer tus conversaciones, sí que podría ver cuando estás encriptando las mismas. De la misma forma, el gobierno que podría arrestar, interrogar y en el mejor de los casos, acabas en la cárcel.

• Lo encriptamos todo: si todo el mundo encripta todas sus conversaciones, el gobierno ya no tendría un patrón de descarte fácil. Para que seas perseguido en este caso te tendrías que convertir en persona de interés para el mismo, o te estés comunicando con alguien que sea una persona de interés. Para protegerte de esto ya habría que tomar otras medidas.

Por lo tanto el uso constante de la encriptación en nuestras conversaciones podría proteger a otros (activistas, grupos minoritarios, etc) de forma indirecta.

Para terminar voy a comentar otra de las conversaciones que tuve con Jalis y que no apareció en el documental. Esta fue sobre el uso de los datos como identificativo de persona. Cada vez son más los casos en los que la policía acude a empresas como Google, Facebook, Amazon, etc para la investigación de crímenes, gracias a la cantidad de datos que estos recolectan de todos sus usuarios, lo cual me parece perfecto, pero cuando los datos se convierten en tu “ADN”, me da un poco de escalofrío.

Hubo un caso en Arizona en el que la policía acudió a Google para que les dijera quién estaba en la zona de un asesinato que había occurrido. Google tiene una base de datos llamada Sensorvault donde guarda los datos de localización de los usuarios de sus servicios. De esta forma Google puede saber quien ha estado en cierto momento en que lugar y sus alrededores (Geo-fence). Esto usado en un caso de asesinato, o de cualquier otro crimen, es muy delicado, porque dicha base de datos, realmente no puede identificarte a tí como persona, sino a un dispositivo con una cuenta asociada a ti. En el caso que comentaba anteriormente, una persona (Jorge Molina) fue detenida por un crimen que no cometió. Afortunadamente, una semana después de su detención fue liberado porque la policía averiguó quién fue el asesino real. Aunque Jorge fue liberado, parte del daño ya está hecho. Esta persona posiblemente hubiera perdido su trabajo, seguramente no podrá trabajar para el gobierno en ninguna capacidad, y por supuesto el daño psicológico podría ser muy notable.

Tienes toda la historia en el enlace de arriba, pero la resumo de forma muy breve. Jorge Molina había usado el teléfono del novio de su madre para leer su correo electrónico y además le dejó su coche al novio de la madre. El novio de la madre conducía el coche de Jorge cuando cometió el asesinato y se marchó. La policía, sólo tenía datos del coche, como el color y la marca, ni si quiera tenían la matrícula. La policía, pidio a Google los datos de las personas que estaban en los alreadedores del luegar del asesinato el día en que éste ocurrió. Basado en los datos proveidos por Google, la policía dedujo que Jorge Molina estuvo en el sitio del crimen y su rastro coincidía con el rastro dejado por el asesino, o mejor dicho por el teléfono del asesino, y además el asesino conducía un coche como el de Jorge, de hecho el suyo. Simplemente basado en especulaciones ofrecidas por datos de localización, Jorge Molina acabó detenido por un supuesto asesinato que no había cometido.

Es muy importante saber cómo vamos dejando nuestro rastro y cómo esos datos se pueden usar, para bien o para mal. Proteger nuestra privacidad es algo por lo que todos deberíamos de luchar antes de que la perdamos por completo y sea demasiado tarde… ¿O es demasiado tarde?

En fin, una experiencia inolvidable y al final fuimos felices y comimos barbacoa :)

• Facebook
• Twitter
• Reddit
• LinkedIn

Como posiblemente ya sabrás kubectl es la herramienta de línea de comandos oficial para interactuar con Kubernetes. Desde ésta puedes hacer prácticamente cualquier cosa en Kubernetes siempre y cuando, obviamente, tengas permiso para ello. Además de todas las posibilidades que esta herramienta ofrece, también tienes la posibilidad de expandirla a través del sistema de plugins.

Un plugin para kubectl no es más que un fichero que cumpla las siguientes tres características:

• Que sea ejecutable (binario o script)
• Que se encuentre en el PATH del sistema
• Que el nombre del fichero empierce por kubectl- (¡guión incluído!)

Los sistema de plugins en kubectl se implementó en la versión 1.8.0 como versión alpha, y luego hubo una reescritura de esta característica en la versión 1.12.0, cuya versión es la mínima recomendada.

Vamos a escribir nuestro primer plugin. Para ello vamos a escribirlo en bash. Así que creemos un fichero llamada kubectl-hello con el siguiente contenido:

#!/bin/bash

echo "Hello, Hello!"

Prefijando el nombre del fichero con kubectl-, cumplimos con uno de los requisitos. Otro de los requisitos es que el fichero sea ejecutable. En nuestro caso:

chmod +x kubectl-hello

El último requisito es que el fichero se encuentre en el PATH del sistema. Para ello puedes copiar el fichero a cualquier directorio que ya se encuentre en el PATH, o en nuestro caso lo que voy a hacer es añadir el directorio donde tengo creado el fichero al PATH. En mi caso el directorio donde he creado el plugin es ~/tmp/kplugin. Por lo tanto (esta acción sólo sobrevive a la sesión desde donde la ejecutes. Si quieres que dicha acción sea permanente tendrás que añadirla a tu ~/.bashrc, ~/.zshrc, o algún otro fichero):

export PATH=$PATH:~/tmp/kplugin

Una vez tenemos hecho esto, podemos ejecutar nuestro script:

kubectl hello
Hello, Hello!

Este comando lo podemos ejecutar desde cualquier parte del sistema, siempre y cuando kubectl esté instalado correctamente.

Vamos a crear ahora un plugin que sea un poco más útil. En este caso vamos a crear otro script (en bash de nuevo), pero éste va a hacer uso del propio comando kubectl para crear un fichero de configuración que pueda ser usado con el propio kubectl. Algunas veces queremos automatizar alguna tarea desde un servidor, por ejemplo desde un pipeline CI/CD, donde usemos kubectl para hacer algo en un clúster de Kubernetes. Por ejemplo la actualización o despliegue de un servcio. Para que el servidor de automatización sea capaz de poder comunicarse con Kubernetes a través de kubectl, éste necesita ciertos datos (dirección del clúster, credenciales, etc) en un fichero de configuración para dicha comunicación. Este fichero de configuración es el que nuestro plugin va a generar.

El contenido de nuestro fichero es el siguiente:

#!/bin/bash

set -e

usage="
USAGE: 
  kubectl kubeconf-generator -a SERVICE_ACCOUNT -n NAMESPACE
"

while getopts a:n: option
do
case "${option}"
in
a) SA=${OPTARG};;
n) NAMESPACE=${OPTARG};;
esac
done

[[ -z "$SA" ]] && { echo "Service account is required" ; echo "$usage" ; exit 1; }
[[ -z "$NAMESPACE" ]] && { echo "Namespace is required" ; echo "$usage" ; exit 1; }

# Get secret name
SECRET_NAME=($(kubectl get sa $SA -n $NAMESPACE -o jsonpath='{.secrets[0].name}'))
  
# Get secret value
SECRET=$(kubectl get secret $SECRET_NAME -n $NAMESPACE -o jsonpath='{.data.token}' | base64 -D)

# Get cluster server name
SERVER=$(kubectl config view --minify -o json | jq -r '.clusters[].cluster.server')
# Get cluster name
CLUSTER_NAME=$(kubectl config view --minify -o json | jq -r '.clusters[].name')

# Get cluster certs
CERTS=$(kubectl config view --raw --minify -o json | jq -r '.clusters[].cluster."certificate-authority-data"')

cat << EOM
apiVersion: v1
kind: Config
users:
- name: $SA
  user:
    token: $SECRET
clusters:
- cluster:
    certificate-authority-data: $CERTS
    server: $SERVER
  name: $CLUSTER_NAME
contexts:
- context:
    cluster: $CLUSTER_NAME
    user: $SAS
  name: svcs-acct-context
current-context: svcs-acct-context
EOM

Este script usa además de kubectl, la herramienta jp. Si no la tienes instalada tendrás que instalarla.

Cómo se puede observar este plugin espera dos parámetros, una cuenta de servicio y el espacio de nombres de dicha cuenta. El fichero de configuración generado, cuando sea usado, interactuará con el clúster con dicha cuenta de servicio, por lo que estará limitado a los permisos de la misma.

Vamos a crearnos un fichero llamado kubectl-kubeconf_generator con el contenido mostrado anteriormente. Fíjate bien que hemos usado el guión necesario después de kubectl y un carácter de subrayado en la segunda parte del nombre. Hablaremos de este detalle más tarde. Por ahora vamos a ejecutar nuestro plugin sin parámetros:

kubectl kubeconf_generator
Service account is required

USAGE:
  kubectl-kubeconf_generator -a SERVICE_ACCOUNT -n NAMESPACE

Ahora pasemos los parámetros. En este caso necesitas tener acceso a un clúster de Kubernetes. En nuestro ejemplo usaremos minikube (asegúrate que está arrancado):

kubectl kubeconf_generator -a default -n default
apiVersion: v1
kind: Config
users:
- name: default
  user:
    token: REDACTADO
clusters:
- cluster:
    certificate-authority-data: null
    server: https://192.168.99.110:8443
  name: minikube
contexts:
- context:
    cluster: minikube
    user:
  name: svcs-acct-context
current-context: svcs-acct-context

Ese fichero de configuración nos permitirá acceder a nuestro clúster (minikube), con la cuenta de servicio default del espacio de nombres default. Este no es el tema de esta entrada, así que lo dejamos aquí.

Volvamos al tema del nombre del plugin. En nuestro último ejemplo nombramos el fichero kubectl-kubeconf_generator, de esta forma kubectl reconoce el plugin como kubeconf_generator o kubeconf-generator, es decir podemos llamar a nuestro plugin de estas dos formas:

kubectl kubeconf_generator -a default -n default
...

o kubectl kubeconf-generator -a default -n default …

Ambas formas funcionan. Ahora, si renombramos nuestro plugin a kubectl-kubeconf-generator, con guión en la segunda separación, para llamarlo desde kubectl lo haremos con un espacio entre los nombres:

kubectl kubeconf generator -a default -n default
...

Siguiendo este patrón podemos crear subcomandos. Por ejemplo podríamos crear dos plugins, uno que genere la configuración en formato yaml y otro en json, de esta forma los nombraríamos:

kubectl-kubeconf-generator-yaml
kubectl-kubeconf-generator-json

Así podríamos llamarlos desde kubectl:

kubectl kubeconf generator json ...
...
kubectl kubeconf generator yaml ...
...

Esto es simplemente un ejemplo para mostrar esta particularidad de cómo kubectl trata el tema de los nombres. Si quieres tener un plugin que permita crear la salida en distintos formatos, lo suyo sería hacerlo a través de un parámetro, y posiblente, usando el parámetro -o para que sea consistente con kubectl.

Para ir terminando, una limitación que existe, es que no puedes sobreescribir un subcomando de kubectl, por ejemplo, kubectl tiene el subcomando version, por lo que si creas un plugin que se llame kubectl-version, cuando invoques kubectl version, se ejecutará el subcomando de kubectl y no tu plugin. También existen una serie de reglas a la hora de resolver conflictos de nombres entre plugins, en las que no vamos a tratar en esta entrada, pero puedes consultarlas en la documentación a través del enlace que tienes al principio de la entrada.

Por último mencionar que kubectl nos ofrece el subcomando plugin list, el cual nos permite ver los plugins que tenemos en el sistema.

kubectl plugin list
The following compatible plugins are available:

/Users/tuxotron/tmp/kplugin/kubectl-hello
/Users/tuxotron/tmp/kplugin/kubectl-kubeconf-generator

En otra entrada hablaremos de cómo manejar los plugins de una forma más limpia y ordenada.