jueves, noviembre 21, 2019

Kubernetes: Gestionar políticas de seguridad de red “Like a Boss” (2 de 3)

En esta segunda del artículo que comenzamos ayer Kubernetes: Gestionar la política de seguridad de red "Like a Boss", vamos a continuar con los ejemplos. En la primera parte vimos cómo configurar el entorno de trabajo con minikube y el plugin CNI Cilium, y ahora vamos a continuar con las pruebas y nuevos ejemplos.

Figura 6: Kubernetes: Gestionar políticas de seguridad de red “Like a Boss” (2 de 3)

Ya hemos comentado antes que, por defecto, la comunicación entre pods está totalmente abierta y no existe ningún tipo de restricción de bloqueo ingress o egress. Pero veamos un ejemplo práctico que seguro que queda mucho más claro. Vamos a crear un pod con mysql en el nombre de espacio default, y luego crearemos otro pod con mysql, pero lo usaremos como cliente para conectarnos al servidor de mysql.

Fichero mysql.yaml:
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: mysql
    spec:
      selector:
        matchLabels:
          app: mysql
      template:
        metadata:
          labels:
            app: mysql
        spec:
          containers:
          - image: mysql:5.6
            name: mysql
            env:
            - name: MYSQL_ROOT_PASSWORD
              value: password
            ports:
            - containerPort: 3306
              name: mysql
A este deployment le hemos añadido la etiqueta app=mysql. Esté será desplegado en el nombre de espacio default.
Nota: nunca pongas credenciales directamente de tus ficheros yaml
Para desplegar este fichero ejecutamos el siguiente comando:
kubectl apply -f mysql.yaml
Podemos monitorizar el progreso de despliegue para asegurarnos que se ha completado:
kubectl get pods -w
Ahora que tenemos corriendo nuestro mysql, vamos a ejecutar nuestro cliente para conectarnos al servidor. Para ellos vamos a coger la dirección IP del pod donde corre el servidor de bases de datos que nos interesa:
kubectl get pods -o wide
Ahora ejecutamos el cliente:
kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h IP -ppassword
Una vez que tengamos el prompt de mysql, podemos listar las bases de datos y salimos:
    show databases;
    ...
    exit
Figura 7: Se permite el tráfico entre pods dentro y fuera del espacio de nombres default

Ahora vamos a crear una política de red que deniegue todo tráfico ingress en todos los pods del nombre de espacio default. El contenido del fichero (deny-all-ingress.yaml) sería:
    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: deny-all-ingress
    spec:
      podSelector: {}
      policyTypes:
      - Ingress
Creamos la nueva política:
kubectl apply -f deny-all-ingress.yaml
Ahora intentamos de nuevo ejecutar nuestro cliente y veremos que no se podrá conectar:
kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h IP -ppassword
Matamos el proceso y borramos el pod:
    ps -ef | grep kubectl 
    kill -9 ID_PROCESO

    kubectl delete po NOMBRE_POD
Figura 8: Los pods del espacio de nombres default no permiten tráfico entrante, pero sí saliente

Añadimos una política (allow-from-client.yaml) nueva que sólo permita ingress desde los pods con la etiqueta app=client:
    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-from-client
    spec:
      podSelector:
        matchLabels:
        app: mysql
      policyTypes:
      - Ingress
      ingress:
      - from:
        - podSelector:
            matchLabels:
              app: client

Creamos la nueva política:
kubectl apply -f allow-from-client.yaml
Ahora ejecutamos de nuevo nuestro cliente, pero esta vez la añadimos la etiqueta app=client para que la política de red le deje conectar:
kubectl run -it --rm --image=mysql:5.6 --restart=Never --labels="app=client" mysql-client -- mysql -h IP -ppassword
Figura 9: El tráfico entrante haca client está bloqueado,
pero el entrante a mysql desde client está permitido

Ahora sí deberíamos poder conectarnos. En el siguiente vídeo se pueden observar todos los ejemplos de lo que hemos hablado hasta este momento.

Figura 10: Ejemplos de prueba de gestión de seguridad de red

En este momento, sólo los pods con la etiqueta app=client del espacio de nombres default, pero ¿qué ocurre si el equipo cyberhades desde su espacio de nombres cyberhade” necesitan conectarse a nuestra base de datos?. Pues lo vemos en la última parte de este artículo, donde continuaremos profundizando en todas las posibilidades que permite el uso de estas políticas de seguridad de red en entornos Kubernetes.

Happy Hacking Hackers!!!

*********************************************************************************************
Kubernetes: Gestionar políticas de seguridad de red “Like a Boss” (1 de 3)
Kubernetes: Gestionar políticas de seguridad de red “Like a Boss” (2 de 3)
- Kubernetes: Gestionar políticas de seguridad de red “Like a Boss” (3 de 3)
*********************************************************************************************

Autores:

Fran Ramírez, (@cyberhadesblog) es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps", también de "Machine Learning aplicado a la Ciberseguridad” además del blog CyberHades. Puedes contactar con Fran Ramirez en MyPublicInbox.

Rafael Troncoso (@tuxotron) es Senior Software Engineer en SAP Concur, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" además del blog CyberHades. Puedes contactar con Rafael Troncoso en MyPublicInbox.

miércoles, noviembre 20, 2019

Kubernetes: Gestionar políticas de seguridad de red “Like a Boss” (1 de 3)

Kubernetes se está convirtiendo no sólo en el estándar para desplegar contenedores, sino también incluso en el elemento más utilizado para gestionar infraestructuras virtualizadas. Por lo tanto, la gestión de su seguridad es algo que necesitamos tener en cuenta a la hora de instalarlo. Por este motivo, ya hablamos de las políticas de seguridad de pods en una serie tres artículos centrándonos en las características de seguridad ofrecidas por Kubernetes a la hora de restringir el despliegue de pods que no cumplan con ciertos requisitos.

Figura 1: Kubernetes: Gestionar políticas de seguridad de red “Like a Boss” (1 de 3)

La seguridad en el mundo Docker es una prioridad, por eso escribimos el libro “Docker: SecDevOps”, el cual además de servir de iniciación a este apasionante mundo de los contenedores, hablamos de buenas prácticas de seguridad así como la posición de Docker dentro del ciclo DevOps aportando el facto de seguridad (“Sec”) para finalmente obtener un cadena SecDevOps.

Figura 2: Libro Docker: SecDevOps

En estos nuevos artículos vamos a hablar de otro componente fundamental en un despliegue de Kubernetes: Las políticas de red y su seguridad. Hablando en términos generales, las políticas de red en Kubernetes son un concepto muy sencillo, pero muy potente. En pocas palabras, una política de red nos permite establecer de una forma declarativa restricciones de comunicación entre los pods de nuestro clúster.

Antes de entrar más en detalle sobre el tema, demos un muy rápido repaso a las redes en Kubernetes. Internamente existen 4 tipos comunicación por red en Kubernetes:
· Contenedor a contenedor: los contenedores que se ejecutan dentro de un pod, comparten el mismo espacio de red del pod, es decir, dichos contenedores comparten la misma IP y se pueden comunicar a través de “localhost”, por tanto, dos contenedores que se ejecuten en un mismo pod no escuchan por el mismo puerto.
· Pod a Pod: cada pod recibe su propia dirección IP y todos los pods, por defecto, se pueden comunicar entre ellos a través de NAT.
· Servicios a Pods: los servicios en Kubernetes no son más que IP virtuales (distinto segmento de la red de pods) que pueden apuntar a cero (idealmente uno como mínimo) o más pods. Los servicios actúan más como balanceadores de carga. Estas IPs no son enrutable, es decir, no responden a “pings”.
· Tráfico externo a interno: en los tres casos anteriores hemos hablado del tráfico interno del clúster. En este caso hablamos del tráfico externo hacia dentro del clúster. Esto normalmente se consigue implementando algún tipo de balanceador de carga externo que interactúe con todos los nodos del clúster.
Una de las razones por la que Kubernetes ha ganado tanta atención, es por la posibilidad de “upgrade” o ampliación, permitiendo el reemplazo de varios de sus componentes principales, como por ejemplo el motor de contenedores (por defecto usa Docker, pero se puede reemplazar), el controlador de red, etcétera. El controlador de red en Kubernetes está basado en el proyecto CNI (Container Network Interface), el cual es más que un conjunto de especificaciones y librerías, que nos permite la implementación del componente que manejaría la red dentro de Kubernetes.

Figura 3: CNI en GitHub

Por lo tanto, nosotros podríamos crear un controlador de red e instalarlo en nuestro clúster, reemplazando el que Kubernetes use por defecto. De todas formas es posible encontrar otros proyectos que usan CNI como base para la implementación de la red.

Figura 4: Ejemplo de implementación TLS dentro de Kubernetes

Esto abre la posibilidad de escribir tus propios plugins y como es lógico, muchas empresas han escrito sus propios plugins de red para Kubernetes. Por lo tanto, y aquí viene el pequeño inconvenientes, no todos los plugins se comportan de la misma manera debido a esta variedad de implementaciones personalizadas. E incluso algunos de ellos incluso no soportan las políticas de red. Por ejemplo, AWS-CNI, el plugin de Amazon para su nube AWS, aunque éste permite ser extendido para soportar dicha características.

Ejemplos con plugins CNI

En nuestro caso, para ejecutar los ejemplos que veremos a continuación usaremos de nuevo “minikube”, el cual por defecto no soporta las políticas de red, así que instalaremos un plugin CNI llamado Cilium que sí las soporta. Cilium es un proyecto Open Source y usa Linux BPF para el filtrado de paquetes de red.

El primer paso será arrancar nuestro clúster con minikube (usaremos la versión 1.5.2 y la versión 1.16.2 de Kubernetes). Para ello, le tenemos que decir a “minikube” que vamos a usar un plugin de red basado en CNI. Además, le dedicaremos a nuestro clúster 4Gb de memoria:
minikube start --network-plugin=cni --memory=4096
Una vez esté el clúster arriba, montamos el sistema de ficheros BPF:
minikube ssh -- sudo mount bpffs -t bpf /sys/fs/bpf
Finalmente instalamos Cilium (asumimos que tienes instalado kubectl):
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml
El proceso puede tardar varios minutos. Puedes observar la creación de los componentes con el siguiente comando:
kubectl -n kube-system get pods --watch
Aquí podéis ver un vídeo con todos esos pasos.


Figura 5: Instalacion de Cilium en minikube

Como con el resto de los objetos en Kubernetes, las políticas de red pueden ser definidas en ficheros YAML. Siguiendo el mismo criterio que el resto, tenemos tres atributos que son requeridos a la hora definir nuestro fichero manifiesto:
    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
        name: test-network-policy
        namespace: default
    ...
    ...
En este caso apiVersion y kind serían siempre el mismo, pero el atributo metadata varía, ya que ahí es dónde especificas el nombre de la política, el nombre de espacio, etcétera. Las políticas de red se definen a nivel del nombre de espacio, así que puedes crear políticas con el mismo nombre, siempre y cuando pertenezcan a distintos espacios de nombre. Veamos un ejemplo más completo:
    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
        name: test-network-policy
        namespace: default
    spec:
        podSelector:
            matchLabels:
                role: db
        policyTypes:
        - Ingress
        - Egress
        ingress:
        - from:
          - ipBlock:
              cidr: 172.17.0.0/16
              except:
             - 172.17.1.0/24
          - namespaceSelector:
              matchLabels:
                project: myproject
          - podSelector:
              matchLabels:
                role: frontend
          ports:
          - protocol: TCP
            port: 6379
        egress:
        - to:
            - ipBlock:
                cidr: 10.0.0.0/24
            ports:
            - protocol: TCP
              port: 5978
Vamos a explicar especificación de este ejemplo (toda la parte que se encuentra por debajo de spec).
· podSelector: se especifica la selección de pods a los que la política de red será aplicada. Si el podSelector se define como vacío {}, la política se aplica a todos los pods. 
· policyTypes: actualmente acepta dos valores Ingress (tráfico de entrada) y Egress (tráfico de salida). Si no se especifica este atributo, el valor por defecto es Ingress.
· ingress: puede incluir una lista de reglas asociadas a puertos. Se permitirá el tráfico de entrada que venga de alguna de las fuentes especificadas, al puerto o los puertos definidos. 
En el ejemplo anterior, permitimos que los pods del espacio de nombre default con la etiqueta role=db (spec.podSelector.matchLabels) se puedan conectar los pods cuya IP se encuentren en el rango 172.17.0.0/16 (spec.ingress.from.ipBlock.cidr), excepto los que se encuentren en el rango 172.17.1.0/24 (spec.ingress.from.ipBlock.except). 
También se pueden conectar los pods que pertenezcan al espacio de nombres que contengan la etiqueta project=myproject (spec.ingress.from.namespaceSelector) y aquellos pods, sin importar el espacio de nombres, que tengan la etiqueta role=frontend (spec.ingress.from.podSelector). Estas restricciones se aplican sólo al puerto 6379/TCP (spec.ingress.from.ports...).
· egress: aquí igualmente se puede incluir una lista con varias reglas que restrinja hacia dónde se puede conectar nuestro pod. Siguiendo el ejemplo anterior, el pod o pods en el nombre de espacio default con la etiqueta role=db, sólo se puede conectar a pods en el rango de IP 10.0.0.0/24 (spec.egress.to.ipBlock) y al puerto 5978/TCP (spec.egress.to.ports…). El resto de las conexiones estarían cortadas.
Como se ha visto en el ejemplo anterior existen cuatro formas de seleccionar los pods en las reglas de ingress y egress:
· podSelector 
· namespaceSelector 
· podSelector y namespaceSelector 
· ipBlock
Y aquí dejamos esta primera parte. En la siguiente continuaremos profundizando en todas las posibilidades que permite el uso de estas políticas de seguridad de red en entornos Kubernetes.

Happy Hacking Hackers!!!

*********************************************************************************************
Kubernetes: Gestionar políticas de seguridad de red “Like a Boss” (1 de 3)
Kubernetes: Gestionar políticas de seguridad de red “Like a Boss” (2 de 3)
- Kubernetes: Gestionar políticas de seguridad de red “Like a Boss” (3 de 3)
*********************************************************************************************

Autores:

Fran Ramírez, (@cyberhadesblog) es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps", también de "Machine Learning aplicado a la Ciberseguridad” además del blog CyberHades. Puedes contactar con Fran Ramirez en MyPublicInbox.

Rafael Troncoso (@tuxotron) es Senior Software Engineer en SAP Concur, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" además del blog CyberHades. Puedes contactar con Rafael Troncoso en MyPublicInbox.

martes, noviembre 19, 2019

Ideas locas en HoneyCON: Metasploit, Dirty Business Card & Air Profiling (2 de 2)

Después, continuando con la primera parte de este artículo, me toca hablar de la tercera y última parte de las cosas que vimos en la pasada HoneyCON llegó el momento de hablar del proyecto de Air Profiling, del que hace ya tiempo que hablamos por aquí en el blog, y que nació como un proyecto de nuestro popular hackathon llamado "Equinox".

Figura 8: Ideas locas en HoneyCON: Metasploit, Dirty Business Card & Air Profiling
(2 de 2)

La idea de este proyecto es la de capturar tráfico de red Wi-Fi y poder analizarlo en busca de hábitos, gustos, leaks, y toda información que pueda ayudar a clasificar qué hace el usuario con el smartphone. Con la información se puede saber dónde tiene una cuenta bancaria porque tiene instalada la app de un banco, si invierte en criptomonedas, cuál es su operador móvil, cuál es el modelo de su dispositivo móvil y la versión del sistema operativo.


Figura 9: Equinox Otoño 2015 en ElevenPaths

Se puede saber si está llevando vida saludable porque tiene aplicaciones que miden las calorías de los alimentos, si está interesado en el los idiomas porque tiene aplicaciones que le enseñan a aprender otras lenguas, etcétera. Es decir, perfilar a las personas en función de las apps que tiene instaladas en su smartphone ya que cada app que un usuario tiene instalada puede decirnos cosas sobre él, sobre sus hábitos, sus gustos, sus intereses y cosas importantes como, por ejemplo, lo del banco.

Figura 10: Links de una app en el Big Data Tacyt

Perfilar las apps por las URLs, es algo que podemos hacer de forma muy afinada, porque con Tacyt tenemos un BigData con todas las apps abiertas, y sabemos a qué URLs se conecta cada una de ellas. Averiguar qué app es la que se está utilizando, con un grado de confianza alto es algo posible, y en la serie de Dorking & Pentesting con Tacyt se hacen muchos ejemplos de localizar apps por Links incluidos en las apps.


Figura 11: Conferencia de Dorking & Pentesting con Tacyt de Chema Alonso

Saber qué apps tiene un dispositivo móvil, no solo es útil para conocer los hábitos de los usuarios, sino para conocer también por donde se puede atacar a una persona. Por medio de Grenlim Apps en APTs o vulnerabilidades conocidas en las apps. Pero de eso ya hablaremos más adelante.

Figura 12: Trafico de la app móvil de "Mario Kart Tour" capturado en la Wi-Fi

Air Profiling ya es un viejo conocido, al menos de manera interna. Todo comenzó en el año 2015, como ya he dicho al principio, en un Equinox de ElevenPaths. En aquella edición Ioseba Palop y yo presentamos esta idea al hackhaton y obtuvimos un premio del jurado por ser una idea innovadora, mientras pensábamos en nuestras herramientas para hacer Ethical Hacking.

Figura 13: Libro de Ethical Hacking

En el año 2017 se convierte en un TFM de dos estudiantes de la Universidad Europea. Dirigí dicho TFM. El proyecto fue realizado por Guillermo Román y Javier Gutiérrez. El resultado final del TFM lo disfrutamos en un Code Talk de ElevenPaths recientemente. Es un proyecto que puede valer para diferentes casos y usos.


Figura 14: Codettalk for Developers "Air Profiling"

En el año 2019 nos planteamos poner el proyecto bonito para que la gente entienda lo que se puede hacer con la captura de tráfico en cualquier red WiFi que no esté bajo tu control. ¿En qué podemos basarnos para conocer al usuario? Realmente, hay muchos parámetros. En esta ocasión, o en la versión 2019 del proyecto, se ha utilizado principalmente:
1. Cabeceras HTTP, en especial User-Agent, para conocer versión del sistema operativo y versión del dispositivo móvil en algunos casos. 
2. Certificado. Nombres de dominio de los certificados. Conocer que certificado utilizan las apps y saber dónde realizarán la petición. Con esto se puede clasificar aplicaciones y dominios que consultan. Podemos conocer la identidad de una aplicación. 
3. Peticiones DNS. Similar al anterior. Podemos buscar una relación unívoca entre dominio y app.
En muchas ocasiones, las apps utilizan dominios únicos que su aplicación web. Es decir, un banco puede utilizar api.bank.com para la app móvil, mientras que puede utilizar el recurso www.bank.com para su versión web. Este tipo de cosas es importante tenerlas en cuenta, ya que nos permite encontrar de forma unívoca la app instalada. Si esto no ocurre, hay que encontrar otras formas de diferenciar, quizá a través del User-Agent que utiliza el navegador y la app móvil, si utilizase.

Figura 15: Resultado obtenido por el proyecto Air Profiling con el análisis de un smartphone

Es importante poder separar casos, ya que, si el usuario navega con el navegador, no solo la web móvil legítima, si no que también la consulta de publicidad podría llevarnos a equívocos.

Capturando el tráfico

Para la captura de tráfico se utilizó una Raspberry Pi a la que se instala un hostapd, para hacer de punto de acceso WiFi. Además, hay que instalar el paquete dnsmasq y disponer de DNS y DHCP en la propia Raspberry Pi. Por último, también hay que añadir el tshark, la versión de línea de comandos de Wireshark.

Figura 16: Reglas en iptables en la Raspberry Pi

Con esta última herramienta lo que haremos es capturar el tráfico cuando lo pasemos desde la interfaz wlan0 (WiFi) a eht0 (salida a Internet). Por último, debemos crear unas reglas de iptables que permita el flujo de tráfico y habilitar también el forward en la máquina.

Ahora quiero agradecer la mención y las palabras

Llevamos años haciendo muchas cosas, porque nos gusta, porque queremos, porque es nuestro trabajo, porque lo disfrutamos. Hay muchos porqués que podríamos seguir diciendo, aunque muchas veces sea a costa de tener menos tiempo con los que más queremos. Sea como sea, HoneyCON dio una serie de menciones honoríficas y solo puedo agradecerles desde aquí, dicha mención.

Figura 17: Mención Honorifica de HoneyCON

Es un orgullo para mí haber recibido la mención y estar año tras año con ellos. Como ya les dije, el placer siempre es mío. Y solo puedo decir: gracias. Otra de las cosas que me llamó la atención fue como Raúl Renales habló de mí a la prensa. Hablar de ilusión cuando uno realiza cualquier cosa es importante. Ver como Raúl habla de uno, pues me hace pensar que estos años he podido aprender, crecer, pero, sobre todo, seguir teniendo la misma pasión e ilusión por hacer esto. Gracias por las palabras amigo.

Figura 18: Entrevista a Raúl Renales

Sin más, decir que pasó la V Edición de HoneyCON, la organización estuvo genial en todos los ámbitos de un congreso. Y decir que habrá muchas "Honeys", porque el trabajo que siguen haciendo en Guadalajara es muy grande. A por la VI.

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Telefónica.

lunes, noviembre 18, 2019

Ideas locas en HoneyCON: Metasploit, Dirty Business Card & Air Profiling (1 de 2)

Llegó la semana del 4 de noviembre y llegó la V Edición de Honey CON. Decir 5 años es decir palabras mayores. Es un hito en todo congreso y la gente de Honey lo celebrarían por todo lo alto. Su propuesta fue hacer que durase nada más y nada menos que seis días el congreso. Del lunes 4 al sábado 9 de noviembre, y ahí estuvimos nosotros para participar en la agenda.

Figura 1: Ideas locas en HoneyCON: Metasploit, Dirty Business Card & Air Profiling
(1 de 2)

El viernes 8 de noviembre tenía una charla sobre los proyectos que hacíamos en el departamento de Ideas Locas del área CDO de Telefónica. El título de la charla era el de “Pequeñas locas ideas: Air Profiling & Dirty Business Card” y quería mostrar cómo surgieron estos proyectos, cómo se fueron realizando, dónde pueden llegar y ejemplificarlas para que los asistentes vieran la prueba de concepto.

HoneyCON: Metasploit, Dirty Business Card & Air Profiling

Además, el sábado 9 de noviembre tenía un taller sobre "pivoting" de 2 horas. En un entorno distendido estuvimos practicando los saltos y el uso de máquinas a través de diferentes formas de pivotar. Ya he hablado alguna que otra vez sobre esto en artículos como “¡Salta conmigo! Metasploit, Meterpreter, SSH, Port-Forwarding, Túneles & Exploits” y "¡Seguimos saltando! Metasploit Port-Forwarding".

Figura 2: Libro de Metasploit para pentesters 4ª Edición y
Hacking con Metasploit: Advanced Pentesting de 0xWord

El objetivo de ambos proyectos es el de crear inteligencia a partir del análisis y relación de datos obtenidos de diferentes fuentes. A continuación, vamos a describir los dos proyectos que fueron la parte importante en el devenir de la charla.

En primer lugar: Business Card

La primera parte de la charla se dedicó al Dirty Business Card. En esta parte se explicó que el origen de datos es una simple tarjeta de visita que cualquiera puede tener en su bolsillo o que cualquiera puede entregar en una visita a una empresa o cualquier sitio.

Figura 3: Demo de lectura vía OCR de tarjetas de visita

Tras mostrar una tarjeta de visita, a modo de ejemplo, y explicar que con la versión móvil se podría tomar una imagen o foto de la tarjeta de visita y el motor OCR de Dirty Business Card podría reconocer el nombre, el teléfono, el nombre de usuario y el email. Estos son los 4 datos de entrada para el sistema y empezar a aplicar los módulos OSINT de búsqueda y relación de datos.

¿Qué objetivo nos marcamos con el proyecto a priori? 

La idea era clara, sacar el máximo de información a través de estos 4 datos de entrada. Podemos enumerar, si profundizamos un poco más, lo que queremos sacar:
1. Cualquier dato directo relacionado con lo que expone tu tarjeta. 
2. Gustos a través del descubrimiento de otros datos. 
3. Hábitos a través del descubrimiento de relaciones y datos. 
4. Información/Leaks relacionados con una persona. 
5. ¿Cosas que no quieres que se sepan?
Cuando se creó Dirty Business Card, se pensó en un modelo modular que sea fácilmente escalable y que tuviera independencia en la ejecución de otros módulos.

Figura 4: Algunos módulos de Dirty Business Card

Que cada módulo se lanzara por separado y, si alguno tuviera dependencia de otros, reducir el tiempo de ejecución de todos lo máximo posible. Y así estamos haciendo crecer el proyecto.

¿Qué podemos sacar con el nombre de una persona que aparece en una tarjeta de visita?
1. Obtener datos sobre tu persona que hay en Internet.
Estudios
2. Redes sociales.
Instagram  
Follamigos
3. Relacionar teléfonos. 
4. Direcciones físicas. 
5. Trabajos anteriores. 
6. Y más cosas.
¿Qué podemos sacar con el número de teléfono de una persona que aparece en una tarjeta de visita?
1. Obtener información de tu operador. 
2. Última portabilidad. 
3. Quién es el propietario del número. 
4. Tu alta en algunas plataformas y redes sociales. 
5. Y más cosas
¿Qué podemos sacar con el correo electrónico que aparece en una tarjeta de visita?
1. Saber dónde estás dado de alta. 
2. Saber si tu contraseña está en alguna brecha de seguridad. 
3. Conocer tu contraseña si ésta está en alguna brecha. 
4. Conocer otros emails tuyos. 
5. Saber si estás en sitios que no quisieras que se supiesen. 
6. Y más cosas.
¿Y con el usuario? 

Saber si estás dado de alto en plataforma/redes sociales, relacionar otras identidades contigo, etcétera.  De esto, ya hablaron mucho Yaiza RubioFelix Brezo con su OSR-Framewok.


Figura 5: Charla de Yaiza Rubio y Felix Brezo sobre OSR-Framework

A muchos le pudo sorprender todas las acciones y situaciones que se pueden dar en la red y que pueden ser obtenidas a través de los datos de la tarjeta de visita. Tras esto llegó el momento de la demo. 


Figura 6: Ejemplo de Dirty Business Card

Mi compañero Lucas se ofreció para que hiciéramos parte de la demo con sus datos. Su nombre y su usuario fueron utilizados, junto a un número de teléfono y un email ficticio. Los 19 módulos de los que consta Dirty Business Card empezaron a trabajar y empezamos a ver un timeline de los estudios, de los trabajos, de sus fugas de identidades digitales, de sitios que había visitado recientemente, y no tan recientemente, sus redes sociales, dónde no tenía redes sociales, algunos hábitos, etcétera.


Figura 7: CodeTalk de Dirty Business Card

Para que veáis algo parecido, el propio Lucas lo cuenta en el Code Talk de Dirty Business Card que se hizo recientemente. Y como curiosidad, si vais a ver alguna charla de nuestro amigo Kevin Mitnick, seguramente encontréis esta demo en su presentación. Y ya puedes leer aquí la segunda y última parte de este artículo.

Referencias:

- Dirty Business Card: ¿Cuánto de sucia está tu tarjeta de visita?
- The Dirt: Dirty Business Card Curricula Module
- El "leak del login" y de "Recuperar la contraseña"
- Tu tarjeta de visita filtra tu Instagram... o viceversa
- Un leak en people que weaponiza tu leaks y publica tu teléfono en Internet
- CodeTalk for Developers: Dirty Business Card

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Telefónica.

sábado, noviembre 16, 2019

Las cosas en las que nos hemos involucrado para la semana que viene

Este año 2019 está siendo intenso, largo, y de hacer mil y una cosa, pero está lejos de haberse terminado, y aún quedan muchas más cosas que hacer antes de tomarse el merecido descanso de fin de año. Así que, vamos subiendo la escalera una semana más de este año que ya se nos va. Esta es la agenda de actividades donde vamos a estar. Toma nota por si te encaja algo.

Figura 1: Las cosas en las que nos hemos involucrado para la semana que viene

La semana comienza con el II Congreso Internacional de Inteligencia Artificial que tiene lugar en Alicante. El evento reunirá a 1.200 asistentes, cientos de expertos, empresas, universidades e instituciones para hablar de proyectos, ideas, oportunidades y tendencias en Inteligencia Artificial. Está abierto al público en general y se escucharán directamente de los expertos muchos ejemplos reales de esta tecnología en la sociedad. Y en él estará presente nuestra compañera Elena Gil, CEO de LUCA, nuestra unidad de BigData & AI para empresas. 

Figura 2: II Congreso Internacional de IA en Alicante

Al día siguiente, el Ministerio de Economía y Empresa de España junto con el Mobile World Capital buscan, con su evento Digital Future Society, unir a gobiernos, empresas, académicos y miembros de la sociedad civil para que estos logren comprender los desafíos que propone la transformación digital. Nosotros participaremos dando soporte al evento, que durará dos días, desde Telefónica.

Figura 3: Digital Future Society

También el día 19, por la mañana, tendrá lugar la entrega de los Premios Comprendedor 2019, en Madrid. En esta ocasión yo solo me pasaré como asistente, pero tiene muy buena pinta y quiero conocer de primera mano los proyectos ganadores. Puedes registrarte para asistir en la web.

Figura 4: Premios Comprendedor 2019 en Madrid

Por la tarde del día 19 tenemos un evento muy especial, ya que llega al Espacio de la Fundación Telefónica en Madrid el Tour de la Amistad que aunque está lleno puedes ver por Internet siguiendo la retransmisión en vídeo. Las estrellas de la literatura británica, Jojo Moyes, Kate Mosse, Ken Follett y Lee Child, visitarán durante el mes de noviembre varias ciudades europeas para conocer a sus lectores. En pleno debate político sobre el Brexit, los autores estarán visitando París, Berlín, Milán y Madrid con un mensaje de amistad y unión en un momento en el que la confusión y el distanciamiento están irrumpiendo en nuestro continente.

Figura 5: El Tour de la Amistad

Y por la noche, en el Late Motiv de Canal #0 participarán nuestros amigos de Despistaos que vienen a presentarnos la campaña de Todos Somos Despistaos y el tema que han hecho para ella, Grita Fuerte Mi Nombre, así que no te lo puedes perder.


Figura 6: Todos Somos Despistaos

El día 20 me han puesto un evento muy especial, ya que abrimos las puertas en la unidad CDO para que os podamos contar qué hacemos y cómo lo hacemos si quieres venirte a trabajar con nosotros. Mis compañeros, con mucho arte le han llamado "Behind The Gorro", así que si eres estudiante y quieres conocer qué y cómo hackeamos cosas, puedes venir a vernos.

Figura 7: Behind the Gorro

El mismo día 20 una sesión online por Youtube. Una nueva Code Talk For Developers para que os contemos cómo programar y utilizar en vuestros proyectos nuestro Stack SMS SDK. ¿Conoces StackSMS? Es una arquitectura que hemos desarrollado desde el equipo de ElevenPaths, incluido su propio SDK, que permite implementar un protocolo de comunicaciones capaz de utilizar la red GSM (Sistema Global de Comunicaciones Móvil) y, en concreto, los mensajes SMS. Esto nos va a permitir poder tener conectividad cuando la conexión a Internet no esté presente, pero también nos ofrece un nuevo canal para comunicarnos con cualquier dispositivo sin tener que depender de las comunicaciones habituales por Internet.

Figura 8: Code Talk for Developers Stack SMS

Y el día 20, otro evento de los grandes. Se trata de Big Things. El evento tecnológico, organizado en Madrid por la empresa española Paradigma, conocido previamente como Big Data Spain cambia su nombre a Big Things debido a la diversidad de sus contenidos actuales. Es uno de los encuentros más importantes a nivel europeo en temas de análisis de datos, IA y transformación digital y busca adaptarse a la evolución de las tecnologías como Machine Learning, IoT o blockchain, entre otras.

Figura 9: Big Things

El 20 de noviembre me toca a mí dar una charla sobre cómo utilizamos las tecnologías de Big Data & AI en Telefónica para hacer posible las Living Apps que acabamos de anunciar y el día 21 de noviembre, Elena Gil, CEO de LUCA participará en el evento hablando sobre cómo ayudar a las empresas a adoptar la IA bajo una perspectiva de las telecomunicaciones.

Figura 10: Webinar gratuito de Raspberry Pi Kali Linux

Aún todavía, por la tarde-noche de ese miércoles 20, tenemos otro seminario por Internet. En este caso un seminario gratuito por Internet para utilizar Raspberry Pi y Kali Linux en proyectos de Ethical Hacking. El seminario toca muchos de los temas que tocamos en el libro de Pentesting con Kali Linux de 0xWord, así que si tienes el libro y haces este seminario gratuito, te pones al día para empezar en el mundo del pentesting.

Figura 11: Pentesting con Kali Linux 2º Edición (Actualizado)

Y para el 22 de Noviembre, tenemos el comiendo del Curso Online de Hacking con Python en The Security Sentinel. Este curso te proporciona los conocimientos necesarios a nivel conceptual y práctico para que puedas programar en Python para el desarrollo de Auditorías de Pentesting basadas en este lenguaje. Es un curso de 90 horas de duración sobre programación en Python pero orientado a personas que quieran enfocar su carrera profesional como pentesters. No es necesario tener conocimientos previos del lenguaje ni de programación.

Figura 12: Curso Online de Hacking con Python

Con este curso, podrás realizar, sin problemas, auditorías de seguridad con su correspondiente informe. Este curso se ha definido en un 75% de práctica y 25% de teoría, lo que te facilitará mucho el aprendizaje y el aprovechamiento máximo de conocimientos. Tienes toda la info en la web del curso. Además, todos los alumnos recibirán el libro de Hacking con Python de 0xWord.

Figura 13: Libro de Hacking con Python

Y el sábado 23, para los que sois de Vitoria o cerca. Podéis disfrutar de Despistaos en la sala Mitika, así que no os olvidéis de pillar antes vuestras entradas. Si vais a asistir, seguro que podéis conseguir alguna firma de Dani, Krespo  - que se ha currado unos artógrafos chulos con la letra de Mi accidente preferido - , Lazaro o Pablo.  Aquí podéis comprar las entradas para el concierto de Despistaos en Vitoria.

Figura 14: Comprar entradas para Despistaos en Vitoria

Y esto es todo lo que tenemos para la semana que viene, pero que como podéis ver hay mucha variedad. Desde seminarios online a conciertos, pasando por eventos en Madrid, Alicante, Barcelona, Vitoria. Hacking, Big Data, AI, etc. Para no aburrirte.

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

viernes, noviembre 15, 2019

Todos Somos Despistaos: "Grita fuerte mi nombre" #TodosSomosDespistaos @despistaos @fundaciontef

Durante el mes de Julio, el grupo Despistaos nos juntó a un grupo de personas con una idea. Hablar de fracaso escolar y cómo lo percibieron ellos en sus carnes. No. No es que fueran malos estudiantes. Daniel Marco y Krespo fueron estudiantes normales, pero desde luego lo que estudiaban en la escuela y por lo que les medía la sociedad en aquellos años para decidir si eran "buenos" estudiantes o "fracasos escolares", no tenía nada que ver con su profesión del futuro.

Figura 1: Todos Somos Despistaos: "Grita fuerte mi nombre"

Con idea de colaborar para que los niños de hoy en día no sean medidos por sus calificaciones escolares, juntaron a un grupo de amigos que tienen de todo menos profesiones que se estudian en el colegio: Músicos, Magos, Actores, Locutores de Radio, Dibujantes de Cómics, Hackers, etcétera.  Entre ellos Eloy Azorín, Javi Nieves, Salvador Larroca, Elsa Punset, Jorge Luengo, Nikotxan, y un montón más.


Figura 2: Todos Somos Despistaos

Personas que han triunfado en la vida después de haber tenido que pasar por una etapa en la escuela en la que la medición del fracaso eran las notas del examen de matemáticas, lengua o ciencias.


El vídeo de la campaña que se ha utilizado como lanzamiento tiene a Lazaro, el batería de la banda, como protagonista, ya que lo que se cuenta en esos 45 segundos bien podría ser el resumen de su vida. Un sueño de ser batería de una banda empedrado por muchos suspensos en matemáticas con cuadernos de ejercicios de matemáticas para el verano.


Figura 4: Entrevista a Elsa Punset

Yo reconozco que no tuve una profesión "normal" cuando empecé mi etapa profesional, pero siempre fui un buen estudiante. Me gusta aprender cosas, y en mi etapa escolar mi problema no fue el fracaso, sino tener que superar otras situaciones feas de la vida. Todos tenemos nuestros retos. Así que cuando Despistaos me contó esta idea suya me sumé a participar, contando cosas de mi experiencia como niño y como papaete.


Pero todas las entrevistas que nos hicieron, a todos los que participamos en esta campaña para dar voz a los que tuvieron una profesión no muy habitual y, como dice la letra de la canción, "que se convierta en un himno la voz de los que no se esconden", las vais a tener disponibles hoy mismo en la web que la Fundación Telefónica ha creado para esta iniciativa en Todos Somos Despistaos.


Figura 6: Entrevista a Jorge Luengo

Despistaos ha lanzado una campaña, junto con la Fundación Telefónica, para concienciar a la sociedad de que las notas de un niño no definen si va a ser un fracasado en la vida o no. Que hasta que las personas encuentran su verdadero potencial en la vida - ya sea la música, el arte, la radio, la televisión, la magia o el humor - ninguno somos fracasados. En todo caso, todos somos "despistaos". 


Figura 7: Despistaos videoclip de "Grita fuerte mi nombre" grabado por José Amesti

Así, han hecho un temazo que se llama "Grita fuerte mi nombre", y con el que donan dinero para que la Fundación Telefónica ayude en programas de lucha contra el fracaso escolar y potenciación de habilidades no académicas para niños. Una iniciativa preciosa con la que colaboras solo con escuchar y compartir la canción, y, por supuesto, difundir el mensaje.


Figura 8: Grita Fuerte mi Nombre en Spotify

Os dejo la canción que está disponible en Spotify, y a partir de ahora podréis disfrutar la canción en los próximos conciertos de Despistaos, que ahora mismo están comenzando la gira y tenéis todas las fechas de las ciudades por las que van a pasar en su página web: Conciertos de Despistaos.

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Entrada destacada

MyPublicInbox: Perfiles destacados por categorías #MyPublicInbox @mypublicinbox1

Cuando se conceptualizó la plataforma de MyPublicInbox se pensó en un entorno que permitiera que los perfiles públicos recibieran comunica...

Entradas populares