A principios de este año se liberó Micro-Latch, un plugin hecho por Manuel Jiménez del equipo de HackPlayers para meter Latch en los chips ESP. Este hardware es de muy bajo coste, por lo que se pueden utilizar en muchos escenarios IoT donde las restricciones económicas son altas debido a la cantidad de dispositivos que se utilizan.
Figura 1: Micro-Latch: Cómo programarlo para latchear el mundo IoT
Con dispositivos más caros, ya hemos visto muchos proyectos de Latch y el IoT (donde también se creó un plugin de Latch para Mosquito). pero Micro-Latch está pensado para entornos de bajo coste. En el blog de HackPlayers se publicaron varios artículos, incluido el código de Micro-Latch en su repositorio de GitHub, y puedes acceder a varios ejemplos de implementación con vídeo-tutoriales sobre su funcionamiento, que os dejo por aquí.
Figura 3: CodeTalk for Developers sobre Micro-Latch
Recuerda, que si quieres más ayuda sobre tus proyectos con Latch o Micro-Latch, puedes preguntar en nuestra Comunidad de ElevenPaths, donde estamos todos presentes y respondemos las dudas que te surjan. Además, si has hecho algo con Latch, nos encantaría que nos lo contaras.
Desde el primer momento en que comenzamos a trabajar en LUCA, la unidad de Big Data en Telefónica, pensamos que teníamos que continuar con todas las iniciativas que estábamos llevando con fines sociales y potenciarla, por eso creamos un equipo y un area que se llamóBig Data for Social Good. En este area se enmarcan todos los trabajos que realizamos con LUCA para ayudar a detectar catástrofes naturales o los proyectos en los que colaboramos con organizaciones como UNICEF y su Magic Box.
Figura 1: Pigram: Una servicio para publicar en Redes Sociales y enviar correos por SMS
Durante el año pasado, cuando participé en la conferencia del Data Transparency Lab en la Universidad de Columbia (Éste año la conferencia DTL 2017 tendrá lugar en Barcelona en Diciembre), pude reunirme con UNICEF en la sede que tienen en New York. Allí nos contaron como para ellos el SMS era aún una herramienta muy poderosa, ya que los Featured Phone, o gente con terminales SmartPhone pero sin planes de datos, o zonas en las que trabajaban en las que no había conexiones de datos por falta de cobertura o por una situación de emergencia, eran su día a día.
Con esa idea en mente, se me ocurrió que podíamos utilizar el SMS como pasarela al mundo de Internet y los datos, por medio de un servicio web a que hemos llamado PIGRAM que, por un lado escuchara tus mensajes SMS y que por el otro enviara tus mensajes a tus cuentas de servicio. Para hacer ello, bastaba con tener una app autorizada vía OAuth con permisos para escribir tuits, para publicar en Facebook, o para enviar correos electrónicos en tu nombre en Office365 o Gmail.
Figura 3: Proceso de aprobación de la app de Pigram en Twitter mediante OAuth
Ya habíamos trabajado con Sappo y los tokens OAuth, y cuando hicimos el trabajo de Ransomcloud aprendimos mucho sobre cómo funcionan los permisos OAuth en Gmail y Office365 como para crear ese servicio. En el caso de Twitter ya existe en la plataforma un servicio para publicar vía SMS, pero pensamos que poner todos al alcance la una misma app simplificaría la vida de los usuarios.
Figura 4: Vídeo de presentación de Pigram
Por supuesto, el servicio puede funcionar enviando SMS manualmente, pero pensamos que para los que tengan un smartphone, disponer de una app nos ayudaba por dos motivos. El primero de ellos para conseguir que los mensajes sean más largos, como por ejemplo un correo electrónico en el que se envía un asunto, un destinatario y un cuerpo de mensaje (de momento dejamos los adjuntos fuera de la primera versión). Además, podríamos añadir una capa de cifrado de forma programática a los mensajes.
¿Cómo se utiliza Pigram?
Su uso es bastante sencillo. En primer lugar nos tenemos que autenticar en la web de Pigram utilizando Mobile Connect. Para ello, es tan sencillo como introducir tu número de teléfono y recibirás un SMS con un token OTP. Lo introduces en la web de Pigram y ya te has creado una cuenta asociada a tu número de teléfono.
Figura 5: Acceso a Pigram mediante Mobile Connect
Después debes descargarte la app de Pigram en Google Play (en breve estará la versión iOS de Pigram también disponible) y una vez la tengas, escanear el código QR que hay en la web de Pigram para asociar tu app con tu cuenta del servicio.
Cuando lo hagas, te aparecerá un código TOTP de 2 minutos de duración que debes introducir en la web de Pigram para terminar el proceso de pareado de app y cuenta del servicio. Este proceso es así, porque la app lleva un generador de tokensTOTP que utilizaremos para cifrar los mensajes SMS que se envíen al servicio Pigram, para garantizar que nadie puede acceder al contenido de los mensajes en tránsito.
Figura 7: Pareado de la app de Pigram
Una vez terminada de configurar la cuenta de Pigram, lo que se debe hacer es autorizar al servicio Pigram en tus redes sociales y servicios de e-mail. De momento, en la primera versión, hemos introducido Office365, Gmail, Twitter y Facebook, pero irán creciendo en sucesivas versiones.
Figura 8: Autorización de app de Pigram en cuenta de Twitter
Para autorizarlo, tan sencillo como iniciar sesión en tu cuenta de Twitter, Facebook, Gmail y Office365 en el navegador, hacer clic en la web de Pigram para añadir el servicio, y después autorizar a la app de Pigram en las distintas cuentas.
Figura 9: Publicación de un Tweet vía Pigram app
Una vez esté hecho este proceso, ya se puede publicar en tu cuenta de Twitter o Facebook desde la app de Pigram o enviar correos desde tu cuenta Office365 o Gmail sin necesidad de tener cobertura de datos o WiFi, simplemente usando mensajes SMS.
Figura 10: Mensajes SMS cifrados usados por Pigram
En cada ocasión, recibirás información del número de mensajes SMS que se necesitan para que Pigram publique en tus cuentas, por si tuvieran algún coste para ti en tu contrato.
Figura 11: Comprobación de tweet publicado vía SMS
Versión Beta
A día de hoy Pigram está en fase de beta, solo para usuarios de España (no importa de qué compañía de telecomunicaciones sea tu contrato), vía app en Android, y solo para los cuatro servicios citados. En sucesivas versiones el servicio se irá expandiendo a todos los países de latinoamérica en los que Telefónica tiene presencia, a iOS, y a más servicios que permitan integración vía OAuth en sus IdPs.
Figura 1: ¡Seguimos saltando! Metasploit Port-Forwarding
Como mencioné en el artículo de la semana pasada, en Highon.Coffee podemos encontrar un interesante Cheatsheet, a modo de resumen de estas técnicas, pero es altamente vital que tú lo pruebes e intentes entender cómo está funcionando por debajo todo lo que has montado.
Hoy nos centraremos en dos partes que quedaban por mostrar en el artículo anterior. En este caso, partimos de un escenario en el que hay una máquina comprometida y necesitamos hacer port-forwarding. Para utilizar este forwarding utilizaremos a Meterpreter. El escenario propuesto es el siguiente:
• Máquina Kali Linux.: Seremos nosotros, con una interfaz de red con dirección IP 192.168.0.31.
• Máquina Windows XP: Sí XP, el cual nos vale como pivote. La máquina Windows XP tendrá una interfaz de red en la dirección IP 192.168.0.26 y otra interfaz conectada en la dirección IP 10.0.0.4. Esta máquina está conectada a dos redes, como se puede ver.
• Máquina Windows 7: Esta máquina tendrá configurada una dirección IP 10.0.0.3. Esta máquina tiene conectividad con la máquina Windows XP, pero no con la Kali Linux.
PoC: Usando portfwd desde Meterpreter
Antes de ejemplificar el uso de portfwd desde Meterpreter, vamos a ver un resumen de las opciones del comando portfwd:
• Add. Esta opción permite añadir una nueva regla para hacer forwarding.
• Delete. Esta opción permite eliminar una regla.
• List. Esta opción permite listar las reglas de forwarding que hay configuradas.
• Flush. Esta opción elimina las reglas que haya configuradas.
Como se ve en la imagen, el comando portfwd, aparte de las opciones, tiene argumentos. Estos argumentos son utilizados conjuntamente con las opciones explicadas anteriormente.
Figura 3: Ayuda de port-forwarding en Meterpreter
Utilizando este comando con las opciones que nos interesen podremos reenviar el tráfico a través de la máquina Windows XP, el cuál es el punto de partida en este escenario, para que llegue a la máquina Windows 7. Para ello, por ejemplo, si queremos hacer que nuestro Kali Linux utilice el puerto 3389 local, para que todo el tráfico que llegue a este puerto se reenvíe a través del pivote, en este caso la máquina Windows XP, hacia el puerto 3389 de la máquina Windows 7 o 10.0.0.3 se puede ejecutar el siguiente comando: portfwd add –l [puerto local] –p [puerto remoto] –r [dirección IP remota].
Figura 4: Creación de una ruta de puertos con portfwd
Si ejecutamos un netstat –tulpn en nuestra terminal de Kali Linux podremos ver como el puerto 3389 se encuentra a la escucha en nuestra máquina. Como se puede ver en la imagen, el puerto 3389 se ha abierto y es Ruby quién tiene el puerto mediante el proceso 1723. Es Metasploit quién gestionará ese forwarding.
Figura 5: netstat -tulpn
Si en la auditoría se necesitase pivotar para poder utilizar, por ejemplo, Pass the hash [más sobre esto en el libro de Hacking Windows] sobre la máquina Windows 7 se podría configurar la siguiente regla para poder llegar al FTP portfwd add –l 445 –p 445 –r 10.0.0.3. Además, configuramos una regla extra en el puerto 8888 local, la cual redirige al puerto 4444 de la máquina Windows 7 con el objetivo de que, si se consigue un Meterpreter de tipo bind, éste se encuentre en dicho puerto.
Figura 6: Regla para pivotar
Ahora, configuramos el módulo de psexec que se encuentra en Metasploit. Como datos de interés o a recalcar hay que resaltar que RHOST apunta a 0.0.0.0 y RPORT es 445, qué es dónde tenemos el forward. Tras configurar el módulo con un Meterpreter de tipo bind, se lanza con el usuario y hash adecuado contra la máquina Windows 7. Gracias al forwarding configurado anteriormente, pasará por la máquina Windows XP y el Meterpreter que se ejecuta en dicha máquina lo llevará hacia la máquina Windows 7.
Figura 7: Configurando el exploit pero no se consigue sesión
Como se puede ver en la imagen, no conseguimos sesión y esto es por qué el Meterpreter se ha atado al puerto 4444 de la máquina Windows 7, y el módulo handler que se ejecuta implícitamente con cada módulo de tipo exploit de Metasploit no puede alcanzar la máquina Windows 7, por esta razón se necesita una nueva regla, en este caso la que configuramos en el puerto 8888 hará el forward hacia el puerto 4444 de la máquina Windows 7.
Figura 8: Configuración del handler para recoger la sesión Meterpreter
Configuramos el módulo handler para recoger el Meterpreter que está a la escucha en la máquina Windows 7. Como se puede ver en la imagen, utilizamos el puerto 8888local para lograr la conexión con el puerto 4444 de la máquina Windows 7. El port-forwarding a través del Meterpreter colocado en Windows XP está funcionando correctamente.
Route para amplificar los puertos
Si en vez de utilizar port-forwarding queremos amplificar el camino, podemos utilizar el comando route para indicar a Metasploit como llegar a redes a las que no se pueden llegar sin el pivote o la máquina comprometida, que es la que abre el camino.
Figura 9: Ayuda del comando route
Para añadir una ruta nueva solamente hay que utilizar la instrucción route add [red] [máscara de red] [SID], dónde SID es el identificador de la sesión. Es decir, si quisiéramos enviar peticiones o tráfico a la red 10.0.0.0, en este caso, debería crear la siguiente entrada route add 10.0.0.0 255.0.0.0 [SID]. Para finalizar, vamos a dejaros un video resumen de port-forwarding desde Meterpreter para que veáis el campo que nos permite abarcar.
Figura 10: PoC Metasploit port-forwarding
Cómo se ha podido ver las técnicas de tunelización, de port-forwarding, de enrutamiento asociadas a las vulnerabilidades y exploits nos permiten abarcar una gran parte dentro de la organización a auditar. Sin duda, técnicas que deben conocer los pentesters para su día a día en los proyectos de Ethical Hacking.
Al igual que el año pasado, el Black Friday en 0xWord se extiende también al Cyber Monday, por lo que hemos habilitado un descuento - que será el último del año - para todo el día de hoy. Es una buena oportunidad para que Reyes Magos y Papás/Mamás Noeles se hagan con buen material.
Figura 1: Cyber Monday en 0xWord
Además, igual que en la última edición del Black Friday, si queréis que os haga un No Lusers dedicado para quién vaya a recibir el regalo, decidlo en las observaciones de la compra y yo os lo hago.
El código que hay que introducir es CYBERMONDAY2017 y recibiréis un 10% de descuento en todos los libros que hayáis comprado durante este Lunes 27 de Noviembre.
Hoy en día se han puesto de moda los bots en Telegram, y es verdad que puede que nos faciliten algunas tareas. Tenemos bots para consultar los horarios del Tram, para obtener la previsión meteorológica, para consultar el precio de cualquier producto en Amazon, ejecutar un ping, convertir archivos multimedia, analizar URLS maliciosas con servicios como Virus Total, administrar servidores, crear y controlar una botnet y casi cualquier cosa que nos podamos imaginar se puede encontrar por Github o en la tienda de bots StoreBot.
Figura 1: Killing Bots: How to hack your company using your Telegram Bot
Está claro, que estos bots son muy útiles, y en ocasiones divertidos y entretenidos, ya que incluso existen algunos con los que podemos jugar en los chats grupales con nuestros amigos, entre otras cosas.
Figura 2: Ejecutar un nmap remotamete vía un bot de Telegram
Cualquier usuario puede crear y/o programar un bot. Para los que no son desarrolladores, existen varias aplicaciones web para hacerlo de forma gráfica e intuitiva sin necesidad de programar, como puede ser ‘Manybot’, aunque esta opción obviamente tiene sus limitaciones.
Para los que están dispuestos a quemar sus dedos y volverse locos a base de escribir código, hay una infinidad de posibilidades, pero esto puede traer de la mano algunos problemas en cuanto a la escritura de código seguro. Sobre todo, porque muchas de estas personas despliegan los bots en sus propios ordenadores de forma local, o peor aún, empresas que los utilizan para dar soporte a sus clientes, estando estos alojados en sus propios servidores.
¿Problemas?
Sí. Hay algunos bots que para realizar sus funciones deben ejecutar comandos en el sistema en el cual están corriendo, por ejemplo, como uno de los que hemos citado anteriormente. Un bot para hacer ping debe ejecutar el comando en el servidor a partir de los parámetros que envíe el usuario que lo utilice.
Si este bot está mal programado, es decir, con una exclusiva visión de funcionalidad dejando de lado la seguridad y las buenas prácticas, cosa por desgracia muy habitual, puede ser perfectamente un vector de entrada para poder tomar el control completo del sistema en el que corre (Command Injection).
En el caso que queremos mostraros hoy, vamos a crear un escenario (entorno controlado) como el que acabamos de describir. Desgraciadamente, es un escenario perfectamente posible en un entorno real.
Caso hipotético:
A un administrador de sistemas que hace labores de todo tipo como informático en una pequeña empresa, se le encarga el desarrollo de un bot para Telegram, que servirá para dar soporte a los clientes de dicha empresa. Entre las diversas funcionalidades que se requieren, hay una que permite que los usuarios ejecuten un ping a cualquier dominio. Este sysadmin, decide programarlo en Python y hostearlo en el servidor de la propia empresa. El programa ejecutará el comando ‘ping’ a partir de los parámetros que le lleguen desde el bot. Esto es un ejemplo, puede ser cualquier otro lenguaje de programación y otra funcionalidad que ejecute algún comando a través de los parámetros enviados por el usuario.
Figura 4;: Bot ejecuta comando /ping google.es
Este administrador de sistemas, sabe lo justo de programación y no se ha leído los libros de Hacking Web Technologies ni el de Hacking Web: SQL Injection, por lo que no ha sanitizado correctamente la entrada de parámetros. Ha tenido un fallo a la hora de programar dicha funcionalidad y no ha controlado correctamente que los parámetros que recibe no sean maliciosos o malignos.
Figura 5: Fragmento de código vulnerable en desarrollo Python del bot
Para que lo descrito anteriormente sea posible, se debe ejecutar un comando en el sistema, por lo tanto, vamos a probar concatenando otro comando a continuación para comprobar si es vulnerable a Command Injection, de esta forma:
Figura 6: Inyección de un comando ls -l
Como vemos, al concatenar el comando, el mismo se ha ejecutado sin ningún problema. Y mejor, el resultado se nos muestra en pantalla perfectamente.
Recolección de información y explotación
El usuario sobre el que corre el bot no tiene privilegios, pero podemos recopilar bastante información y ejecutar diferentes comandos. Aunque tampoco nos vamos a conformar simplemente con esto, ya que estamos aquí.
Figura 7: Inyección de un comando uname -a
Concatenando el comando ‘uname –a’, vemos que corre sobre un ‘Ubuntu 14.04’ con el Kernel ‘4.4.0-31-generic’. Con buscar un poco en Google , podremos comprobar, que es vulnerable a diferentes técnicas de escalación de privilegios. Como sabéis, esto se puede hacer también con un herramienta escrita en Python llamada AutoLocalPriviligeEscalation que permite saber qué exploits son válidos para cada versión del kernel de Linux sin fortificar.
Figura 8: Podríamos inyectar la ejecución de auto_searchsploit si lo clonamos antes de su GitHub
Para tener un mayor control sobre el sistema que estamos tratando de comprometer, en vez de inyectar los comandos de elevación de privilegios a través de el bot, vamos a intentar obtener una shell en el mismo. Para ello, se nos ocurrió utilizar Netcat.
Obtención de una shell remota a través del Bot de Telegram
En nuestra máquina Kali Linux, vamos a poner netcat a la escucha de una conexión, para conectarnos desde la víctima. Con esto conseguiríamos una shell reversa, ya que la conexión sería establecida por parte del sistema vulnerado usando como vector de ataque al bot.
Figura 9: Netcat escuchando en el puerto 4444 en la máquina Kali Linux del atacante
A continuación, desde el bot, vamos a ejecutar el comando que se conectará al atacante. Pudimos comprobar que dicho comando NO requiere de privilegios.
Figura 10: Inyección de comando netcat. Si nc no está en el servidor habría que descargarlo.
También debemos redirigir STDIN y STDERR a /dev/null y añadir ‘&’ al final para que corra en segundo plano y no deje en pausa la ejecución del bot. Tras esto, podemos observar, que se ha establecido una conexión por parte de la máquina víctima.
Figura 11: Shell obtenida en la máquina Kali Linux del atacante
Una vez hemos obtenido la shell, podemos comenzar a ejecutar comandos. Como podéis ver, hemos conseguido a través de un bot vulnerable de Telegram, acceder a un sistema y obtener una shell en el mismo. Pero al estar corriendo sobre un usuario sin privilegios, tenemos grandes limitaciones.
Figura 12: Ejecución de comandos en el sistema. Aún no privilegiado
Para ello, debemos encontrar la manera de conseguir una escalación de privilegios. Como vimos anteriormente con el ‘uname –a’ podemos ver detalles del sistema como la versión del sistema operativo, versión del kernel, entre otras cosas.
Escalación de privilegios final con DirtyCow
Para escalar privilegios, podemos buscar información sobre vulnerabilidades conocidas para la versión específica del sistema que estamos atacando en este caso, un Ubuntu 14.04 usando la herramienta AutoLocalPriviligeEscalation. Con ell nos encontramos con que nuestra víctima corre una de las versiones vulnerables a ‘Dirty COW’, uno de los últimos exploits de escalación de privilegios para el kernel de Linux. Este exploit aprovecha una vulnerabilidad en el manejo de la memoria, causando un problema de condición de carrera, permitiendo así que podamos escribir en zonas de memoria, que en teoría deben ser de sólo lectura.
Figura 13: Ejemplo de explotación de DirtyCow
Descargamos el exploit desde un repositorio de Github en la máquina atacante. En nuestro caso metemos el zip en un servidor web Apache que hemos levantado. En un entorno real, un atacante podría utilizar un servidor propio, en el que almacenaría todo el malware que va a utilizar para comprometer un sistema determinado.
Figura 14: Publicación de exploit dirtycow en servidor Apache del atacante
Desde netcat, descargamos con ‘wget’ el zip en la máquina víctima y lo movemos a la carpeta /tmp, para que no esté a la vista y así evitar que la víctima pueda verlo.
La shell que nos da netcat tiene sus limitaciones. Por ejemplo, no se puede hacer un ‘ssh’ o un ‘su’, también se presentan dificultades a la hora de tratar de editar archivos y no muestra los STDERR. Por lo tanto, también tendremos problemas a la hora de obtener la shell con root, tras explotarlo. Por supuesto, pasar un dirtycow.zip por la red podría hacer saltar los controles de seguridad e IDS, así que el zip mejor pásalo con password u ofuscado de alguna otra forma en un proyecto de Ethical Hacking real.
Ahora tendríamos que descomprimirlo, compilarlo y ejecutarlo, pero como acabamos de comentar, desde la terminal de netcat no es posible alguna de esas tareas. Primero tenemos que ‘upgradear’ la shell para obtener una terminal más completa en la que poder manejarnos mejor. Tenemos diversas posibilidades para esto, pero una muy sencilla es ejecutar una línea en Python que nos saque una pseudoterminal (pty). Haciendo uso de la librería pty, simplemente tenemos que llamar al método .spawn y añadir ‘bin/bash’ para obtener la shell.
Figura 15: Upgradeando la shell
Ya podemos observar el prompt en nuestra consola. Hay más formas de hacer esto, cabe la posibilidad de que, a diferencia de en este escenario, la víctima no tenga instalado Python, por tanto, deberíamos recurrir a otros métodos.
Figura 16: Extrayendo el contenido del exploit
Ahora hay que explotar el sistema para conseguir la escalación de privilegios que tanto anhelamos y así podernos hacer con el control del mismo. Extraemos el zip previamente descargado y movido a /tmp en la máquina víctima con ‘unzip’ como se ve en la imagen superior, y luego compilarlo, como se ve en la imagen siguiente.
Figura 17: Compilando DirtyCow
Y finalmente ejecutarlo con la opción ‘-s’ para un proceso más rápido y automático porque el exploit podría dejar bloqueado el sistema. Se puede observar, que hemos obtenido privilegios de superusuario, lo que quiere decir que poseemos control absoluto del sistema.
Figura 18: Ejecución de DirtyCow
Podríamos ir dejando backdoors para poder acceder de nuevo en próximas ocasiones, pero esto ya entraría en la fase de post-explotación de un proyecto de Ethical Hacking y nosotros solamente pretendemos mostrar lo que podría llegar a ocurrir simplemente porque a un programador se le olvide (o no tenga en cuenta) la seguridad desde el diseño. El resto de posibilidades, ya queda a la imaginación de cada lector.
Notas Finales sobre la seguridad de los bots de Telegram
En Github podemos encontrar una gran cantidad de bots o módulos hechos por la comunidad, los cuales ofrecen distintas funcionalidades. Aquí hay que tener especial cuidado ya que muchos de ellos son potencialmente vulnerables, y si lo descargamos y usamos alegremente, pueden acarrear problemas como los descritos anteriormente.
Ahora imaginemos en nuestro supuesto caso, que este es el servidor central de la pequeña empresa, y en él, están almacenadas las bases de datos, documentos e información confidencial de la misma. Podríamos robar dicha información, incluso hacer un DoS en los servicios que corre, por no hablar de técnicas de ‘pivoting’ y comprometer otros equipos de la red en caso de que el servidor no se encuentre en una DMZ con unos sistemas de seguridad acorde a las necesidades.
Algunas pocas recomendaciones podrían ser:
• Controlar el tamaño de los parámetros que se pasan a través del bot. Dado que solamente es un dominio debe ser máximo uno.
• Controlar que los comandos se ejecuten solamente por los admins o personal autorizado. En Telegram cada usuario tiene un ID único, que puede usarse para evitar que otros usuarios ejecuten el mismo.
• Usar una expresión regular para verificar y comprobar, que el parámetro efectivamente es un dominio y no otra cosa.
• Usar funciones propias del lenguaje en el que se haya implementado el bot para mejorar la seguridad. En Python se puede usar shlex.quote(s).
Figura 19: JSON con las peticiones del bot
• También se nos ocurre, que si sospechas que alguien está intentando hacerte un command injection, puedes apagar el bot y revisar las últimas peticiones realizadas a través del servidor de telegram, que se guardan durante 24 horas. Para ello puede ir al navegador y escribir: https://api.telegram.org/bot[token]/getUpdates donde se debe reemplazar el token del bot en [token] y si nos fijamos recibiremos un JSON con las peticiones pendientes y datos adicionales del posible atacante.
Conclusiones de este trabajo
Es conveniente reflexionar sobre las buenas prácticas y la visión de seguridad a la hora de diseñar e implementar un software, no prestando atención exclusivamente a la parte funcional. Es un matiz que hay que tener en cuenta desde el diseño. En muchos centros de enseñanza donde se aprende a programar esto apenas se tiene en cuenta o se deja en segundo plano, trayendo de la mano una gran inconsciencia por parte de los desarrolladores a la hora de crear sus aplicaciones. Finalmente, os dejamos una PoC en vídeo de todo este proceso de explotación:
Figura 20: Killing Bots: How to hack your company using your Telegram Bot
Autores: Adrián Fernández (@adrianfa5) y Mauricio Trujillo (@fm_trujillo)
Estudiantes de Seguridad Informática y coorganizadores de @bitupalicante
Y un sábado más, aprovecho este espacio para dejaros por aquí la agenda de actividades que vamos a tener en ElevenPaths, en LUCA D3, en 0xWord y algunas áreas de Telefónica. No van a ser demasiados, porque ya se va acabando el año. Además, son de los últimos en los que yo voy a participar, ya que llegado el mes de Diciembre voy a hacer otro parón invernal en mi actividad de eventos y no estaré en nada más hasta el año que viene.
Figura 1: Nuestra agenda para la semana que viene
Comenzamos el repaso con el que será mi último evento público este año. He querido estar en él por el trabajo que realizan todos los que implican su vida profesional en servicio de otros. Foro Demos es un evento especial en el día de las fundaciones, y la lista de ponentes que se han apuntado para este día en Madrid es enorme. Juan Luís Cano, Guillermo Fesser, Ferrán Adrià, Chema Martínez, Javier Feesser, y un largo etcétera con los grandes responsables de las fundaciones en España. Será el día 28 de Noviembre en Madrid.
Ese mismo día, tendrá lugar en otra parte de Madrid, un evento para el mundo de la empresa que quiere aprovechar la transformación digital del negocio por medio del IoT. Es el IoT RevoluIoTn y lo organizamos desde Telefónica.
Figura 3: Demo de LUCA Store en MWC 2017
Una jornada con muchos ejemplos de cómo transformar el negocio con la potencia del IoT y la analítica descriptiva, predictiva y prescriptiva sobre las datos que se generan. Allí se podrán ver los servicios de LUCA Store que construye nuestra unidad de BigData sobre el mundo IoT en las tiendas.
Ya el día 29, en ElevenPaths tendremos una jornada online para los developers. Una nueva CodeTalk 4 Devs centrada en construir soluciones IoT utilizando MicroLatch, una implementación de un plugin de Latch que cabe en dispositivos de un par de dólares. Ya hablamos de MicroLatch en el blog, pero ahora podrás disfrutar de una sesión de una hora programándolo.
Y este es el calendario de esta semana. El jueves y viernes nos centramos en el Encuentro interno que tenemos en Telefónica, Después no vendrá mucho más, que ya en breve se nos echan encima las navidades... y yo tengo planes para disfrutarlas }:P
Desde las 00:00 horas del Viernes 24 de Noviembre hasta las 23:59 (hora de España), 0xWord participará en la campaña de BlackFriday, por lo que podrás adquirir todo el material de nuestro catálogo de libros con un 10% de descuento introduciendo el código de descuento que hemos creado para la ocasión.
Figura 1: BlackFriday en @0xWord: Hoy 10 de Noviembre desde las 00:00
Entre todo el material que puedes adquirir se encuentra la nueva edición del libro de Metasploit para Pentesters 4º Edición que hemos actualizado y ampliado para que incluya nuevo contenido. El libro ya ha superado los 5.000 ejemplares de venta.
Con la cercanía de las navidades, es un buen momento para ir haciendo acopio de material para que Papá Noel y los Reyes Magos traigan conocimiento y diversión a vuestros seres queridos. Todos los que queráis este día, podéis poner en las observaciones que lo queréis dedicado y yo personalmente os hago un "No Lusers" dedicado a quién queráis, para que sea un regalo único y especial.
Hace tiempo comenzamos con una campaña para conseguir que las niñas se dediquen al mundo de la tecnología. Pero desde aquella campaña de "Mamá, quiero ser hacker", hemos seguido trabajando en otras ideas para que las grandes profesionales tengan su espacio y se conviertan en referentes para todos. Yo por aquí os he ido hablando de algunas de las compañeras con las que tengo la suerte de trabajar, como son Yaiza Rubio o Sheila A. Berta, que han hecho cosas únicas en el mundo de la seguridad.
Figura 1: Mujeres referentes en el mundo STEM
Pero no queríamos quedar solo ahí, en el mundo de la seguridad, y queremos que las niñas - incluidas mi hacker y mi survivor - conozcan día a día un poco más de las pioneras en el mundo de la tecnología, así que este verano comenzamos con otras iniciativas.
Figura 2: "Mamá, quiero ser hacker". Especial día de la madre.
La primera de estas iniciativas la hemos puesto ya en marcha, y desde este mes de Noviembre podéis seguir en el blog de ElevenPaths las biografías de algunas de las mujeres que han roto barreras en el mundo STEM.
Para hacer una obra más redonda, nos decidimos a contratar a la ilustradora chilena Cata Guzmán "Cata con botas", que con su personal estilo nos hizo dibujos para cada una de las mujeres que queríamos poner en el punto de atención.
Hasta el momento la campaña ha tratado la historia de tres grandes profesionales y referentes mundiales no solo para las mujeres, sino para todos los profesionales del mundo de la tecnología, que son las que tenéis en este post.
Pero la campaña continuará, y a lo largo de los próximos meses podréis encontraros en el blog de ElevenPaths a estas grandes referentes. Además, también contaremos historias de nuestras compañeras en Telefónica y en otras empresas del mundo de la tecnología, para que las niñas se den cuenta de que este es su mundo. Solo hace falta tener pasión y ganas por la tecnología. Lo demás, no importa.
Por último, antes de que acabe el año, nuestras compañeras hackers han decidido venirse un sábado al Distrito C para dedicárselo a niñas que quieran jugar con la tecnología. Algo precioso que espero que las niñas lo disfruten tanto como yo.
Será un día de experimentos en los que jugarán con las tecnologías, hablarán con los primeros bots, y con AURA, construirán su propia tecnología y lo harán con nuestras mujeres hackers. Muy feliz por el cariño que están poniendo todos en este proyecto.
Ya hemos hablado de la tunelización de conexiones con Proxychains, pero en esta ocasión quería mostrar un ejercicio fundamental en un proyecto de Ethical Hacking. Hablar de túneles, port-forwarding y pivoting con y sin Meterpreter. Un compendio de buenas prácticas y técnicas que ayudan a poder saltar y saltar entre diferentes máquinas y servicios de la organización.
Es una técnica, como dije anteriormente fundamental, utilizada para encaminar tráfico a través de un equipo comprometido en un test de intrusión. Estés en una máquina externa o una máquina interna, puedes necesitar conducir el tráfico a través de una máquina comprometida para buscar el compromiso de otros targets internos.
Al fin y al cabo, el pivoting permite ir enrutando el tráfico de red a través de diferentes máquinas que se van comprometiendo con el objetivo de lograr conectividad y acceso a otras subredes y máquinas, generalmente, más importantes de la red. En highon.coffee tienen unos cheatsheets bastante completos. En el artículo de hoy vamos a hacer un resumen de las posibilidades que tenemos, para ejemplificar a través de una pequeña prueba de concepto.
PoC: Pivoting con túneles SSH
Lo primero es hablar de SSH Port-forwarding. El propio SSH nos permite realizar este tipo de operaciones de manera sencilla. Proponemos el siguiente escenario:
• Máquina A con la dirección IP 10.0.0.1, dónde nosotros tenemos una shell.
• Máquina B con la dirección IP 11.0.0.1, dónde nosotros tenemos una conexión a través de SSH.
• Máquina C con la dirección IP 11.0.0.2, dónde esta máquina no tiene conectividad con la máquina 10.0.0.1, pero sí con la máquina 11.0.0.1.
Podríamos utilizar la opción –L de SSH para indicar un puerto local, por ejemplo 2222, al que enviaremos el tráfico. En nuestra máquina local se abrirá el puerto 2222 y SSH estará a la escucha. Es SSH, a través de dicho puerto, el encargado de reenviar el tráfico al puerto, por ejemplo, 22 de la máquina 11.0.0.2 a través del equipo 11.0.0.1.
Vamos a verlo de forma práctica. Ejecutando la instrucción ssh –L 2222:11.0.0.2:22 [user]@11.0.0.1. Recordemos que suponemos que la máquina 10.0.0.1 y la 11.0.0.1 tienen conectividad, pero la 10.0.0.1 no tiene con la máquina 11.0.0.2.
Figura 3: Abriendo la conexión en el puerto local 2222
Una vez que el usuario tiene acceso a la máquina 11.0.0.1, se ha creado el forward a través del puerto local 2222. Ahora, si ejecutamos un netstat –tulpn en nuestro Kali Linux podemos ver los procesos que están a la escucha en la máquina. Podemos ver de forma fácil como el proceso de SSH está a la escucha en el puerto 2222.
Figura 4: SSH a la escucha en el puerto 2222
Cuando queramos conectar con la máquina que se encuentra en la dirección IP 11.0.0.2, a la que no tenemos conectividad directa, pero sí a través de la 11.0.0.1, ejecutaremos el comando ssh –p 2222 [user]@127.0.0.1. Como se ve, estamos enviando la petición SSH a nuestro puerto local 2222 y a nuestro localhost. SSH recibe esta petición y hace el reenvío a través de la conexión o sesión abierta de la máquina 11.0.0.1 y de ésta salta a la 11.0.0.2. Ahora sí llegamos a la máquina 11.0.0.2.
Figura 5: Volcado de tcpdump que muestra el tráfico entre ambas máquinas
Como se aprecia en la imagen tenemos conectividad. Lo que nos interesa es ver qué tráfico y en qué forma llega a la máquina 11.0.0.2. En la máquina 11.0.0.1 configuramos un tcpdump y vemos cómo el tráfico que se envía hacia la máquina 11.0.0.2 va con dirección IP 11.0.0.1.
Figura 6: PoC de SSH Pivoting
PoC: Metamos a Metasploit en la ecuación
Ahora vamos a meter a Metasploit en el juego. Con el túnel creado entre la máquina 10.0.0.1 y 11.0.0.1, vamos a configurar el módulo de Metasploit para que pueda enviar el exploit a través del túnel, cuando éste llegue a la máquina 11.0.0.1 se hará forward y se enviará el exploit a la máquina 11.0.0.3. Ésta es una nueva máquina que metemos en la ecuación. Esta máquina es un Windows 7 y tiene un FTP vulnerable corriendo en el puerto 21.
Tenemos que crear un nuevo túnel con la máquina 11.0.0.1, el cual podemos hacerlo con la siguiente instrucción ssh –L 2222:11.0.0.3:21 pablo@11.0.0.1. De esta forma, en nuestra máquina local se abrirá el puerto 2222 en la interfaz de red 127.0.0.1 con el proceso de SSH y éste hará el forward al puerto 21 de la máquina 11.0.0.3 aprovechando la conexión con la máquina 11.0.0.3.
Podemos configurar el módulo de Metasploit para que RHOST apunte a 0.0.0.0, es decir, cualquier interfaz de red de nuestra máquina, incluyendo localhost que es dónde está a la escucha el puerto 2222. En RPORT, debemos utilizar el puerto 2222, ya que es el que está a la escucha en nuestra máquina.
Figura 7: Configuración de LPORT y RPORT en el módulo del exploit
Cuando ejecutamos el módulo podemos ver que éste se ejecuta, pero parece que no tenemos conexión o sesión. Aunque el exploit ha tenido éxito, no obtenemos sesión debido a que el payload se ha configurado de tipo bind y éste está atado al puerto 4444 de la máquina 11.0.0.3, a la cual no tenemos conectividad. Debemos, en este caso, crear un nuevo túnel que nos redirija al puerto 4444 de la máquina 11.0.0.3.
Figura 8: Conexión de nuevo tunel
Para conectarnos, utilizamos el módulo exploit/multi/handler con el que podremos buscar al Meterpreter que nos ha devuelto la explotación de la vulnerabilidad del servidor FTP. ¿Qué había ocurrido? La vulnerabilidad había sido explotada, y Meterpreter estaba ejecutándose en el puerto 4444 a la espera de que alguien se conectara a él.
Como se ve en la imagen, de nuevo RHOST apunta a 0.0.0.0 y LHOST, en este caso, apunta al puerto 2222, que es el de nuestra máquina local. Una vez lanzamos el módulo obtenemos la nueva sesión de Meterpreter y podemos ejecutar comandos.
Figura 9: Conexión con Meterpreter
Debemos tener claro que gracias al túnel SSH entre la máquina 10.0.0.1 y la máquina 11.0.0.1 hemos podido hacer forward del tráfico dirigido al puerto 21 de la máquina 11.0.0.3, utilizando como pivote a la 11.0.0.1, y, posteriormente, hemos realizado el mismo proceso, pero con el puerto 4444, para recoger el Meterpreter.
Figura 10: PoC Pivoting con Meterpreter
Una mejora sería utilizar un Meterpreter reverse para que la máquina 11.0.0.3 pueda conectarse a nosotros si tuviera conectividad desde dentro hacia fuera. Todo el proceso se puede ver en el vídeo de la PoC que tienes aquí.
PoC: Rizando el rizo. Dos saltos y pwned en el servidor FTP
Por último, se quiere saltar por dos máquinas antes de llegar al servidor FTP. Para ello, se abre el puerto 2222 en local y se indica que es a 127.0.0.1 dónde se lanza la petición con destino puerto 2223 en la máquina remota. Una vez se tiene acceso en la máquina 11.0.0.1, se abre el puerto 2223 y se indica que las peticiones que salgan de dicha máquina vayan al puerto 21 de la máquina 11.0.0.3. Puede resultar un poco lioso, pero os dejo una imagen que puede ayudaros.
Figura 11: Ahora dos saltos en vez de uno
Ahora, lanzamos el exploit con la misma configuración que en el paso anterior. El exploit pasará por la máquina 11.0.0.1, de la 11.0.0.1 pasa a la 11.0.0.2 y de ésta a la 11.0.0.3 dónde llega ya en plano, en la petición de protocolo FTP. De la máquina 10.0.0.1 a la 11.0.0.1 y de la 11.0.0.1 a la 11.0.0.2 hay dos túneles SSH. Cuando queremos preparar los túneles para recoger el Meterpreter de tipo bind. En la imagen se puede ver cómo queda la configuración de los túneles, para la recogida del Meterpreter en el puerto 4444.
Figura 12: Túneles preparados para la recogida de la sesión Meterpreter
Para acabar, vemos cómo obtener el acceso a la máquina Windows 7, que se encuentra a dos saltos de nosotros, sin ningún tipo de conectividad con la máquina Kali Linux dónde nos encontramos.
Figura 13: Goal!
Para más adelante dejamos la funcionalidad de Metasploit de Portfwd, con la que podemos hacer este tipo de cosas más sencillas, y tras conseguir la explotación con Metasploit. Sin duda, una técnica necesaria y que debemos manejar. Y no he querido rizar el rizo, pero si quieres que estas SSH sean solo tuyas, puedes ver el artículo de configurar SSH in paranoid mode.
