Deepak Daswani

"No pain, no gain", probablemente hayas escuchado esta frase en más de una ocasión. Una expresión recurrente que se utiliza hasta la saciedad en diferentes entornos, en una época donde el culto al cuerpo, el deporte, y el auto cuidado están más de moda que nunca. Si hace 20 años la práctica diaria de deporte estaba reservada a unos pocos, hoy en día prácticamente todo el mundo intenta dedicar todo el tiempo que puede a ejercitar su cuerpo. No sólo por este fin en sí mismo, si no también por los beneficios que ello aporta a su mente. En la actualidad nadie pone en duda las bondades que la práctica regular de algún tipo de ejercicio físico tiene para nuestra psique y para nuestra salud, a todos los niveles. Este conocido leitmotiv comenzó a asociarse en primera instancia al mundo del culturismo. Si esta expresión ha trascendido al mainstream y es tan popular a día de hoy es porque refleja a la perfección esa contradicción inherente al deporte: es necesario sufrir para obtener resultados. En esas últimas repeticiones a la hora de levantar la barra con un sinfín de discos por cada lado en un press de banca, o en las odiosas sentadillas, así como cuando aún te queda un un asalto más que aguantar en el ring. Cada uno puede pensar en el ejemplo que quiera, sea cual sea el deporte que practique, la sensación es parecida. Hay que sobrellevar esos momentos en los que uno se ve tentado a abandonar, a dejarlo para mañana o para otro día. Esos momentos en los que sacamos fuerzas de flaqueza y sufrimos lo indecible, son los que hacen que todo valga la pena. No pain, no gain. Obvia decir que todo esto tiene sentido siempre que ese sufrimiento esté dentro de unos límites saludables. Ya sabemos de sobra que los extremos son malos, pero lo cierto es que la frase tiene ese punto motivador e inspiracional porque apela a la épica, al sacrificio, al esfuerzo, constancia y al coraje. Esos valores tan asociados al deporte que nos hacen vibrar y estremecernos, incluso cuando no somos nosotros los que lo practicamos, si no que lo disfrutamos desde el sofá viendo a esos profesionales bendecidos por los dioses. Son valores que en realidad aplican a cualquier ámbito de la vida, como por ejemplo el profesional. Sobre todo en una disciplina tan compleja como lo es el hacking en particular. Si hay algo de lo que sabemos los que nos dedicamos a esto es que sin esfuerzo, no hay recompensa (ahí va una versión española de la frase). Que hay que dedicar muchísimas horas a leer, experimentar, errar, volver a leer, volver a experimentar y volver a errar un número indeterminado de veces hasta lograr nuestro propósito, o no. Ya que, en este terreno, contamos con la complejidad añadida de que el sufrimiento no garantiza los resultados. Aquí, en muchas ocasiones, podría haber mucho de “pain”, pero poco de “gain”. A veces, hemos de invertir horas y horas en seguir un camino que puede conducir a un laberinto sin salida. Los llamados rabitt holes. Igualmente, todas las horas que se dediquen a estudiar e investigar siempre aportan algo y no caen en saco roto, en ocasiones el sufrimiento no se ajusta a la ganancia. No compensa en términos de coste-beneficio. Afortunadamente asociado a la figura de un hacker va siempre la pasión que a uno le mueve por resolver un reto, superar un obstáculo, romper los límites que la tecnología nos ofrece o satisfacer nuestra ansia de conocimiento. Ya que sin dicha pasión, sería imposible reunir las dosis de paciencia, perserverancia y constancia que se requieren para esta filosofía del “Try Harder” (archiconocido lema del OSCP). El mundo cambia y evoluciona constantemente. Y si no, que nos lo digan a nosotros después de este 2020. Como decía Heráclito, todo fluye a cada momento. En el mundo de la seguridad, como no podía ser de otra manera, también cambian cosas constantemente. De hecho, la aproximación ha cambiado desde hace casi ya una década. Cuando antes se intentaba evitar a toda costa que los incidentes se produjeran, con el paso del tiempo se ha asumido que esto no es posible. Ello ha derivado en la necesidad de crear un plan de respuesta a incidentes, de cara a que las organizaciones sepan cómo reaccionar cuando un incidente se produzca. Asumiendo que en algún momento esto va a pasar, sí o sí. Proceso de “Incident Response” del SANS En los últimos años hemos sido más consciente que nunca de la fragilidad en este sentido. No exigimos que ningún sistema ni organización sea perfecto y esté siempre al 100% en términos de integridad, confidencialidad y disponibilidad. Nos hemos acostumbrado a ver que todo tipo de organizaciones, sea cual sea su tamaño, pueden ser víctimas de ransomware, brechas de datos o cualquier tipo de incidentes. A día de hoy, no se juzga a las empresas por sufrir incidentes, sino por cómo reaccionan ante los mismos. Tenemos diversos ejemplos curiosos de cómo la confianza de los usuarios puede variar de un extremo a otro ante problemas de seguridad. Compañías tecnológicas que un día están al alza y otro a la baja, o lo contrario. Blackberry jamás volvió a recuperarse de aquella caída que sufrieron sus usuarios en 2011. Se enfrentó con ello a un daño reputacional irreparable, que coincidió con la penetración en el mercado de Apple y Android. Hay veces que la red te da una segunda oportunidad, y otras que no. Durante los primeros meses de confinamiento allá por marzo del pasado 2020, usuarios y organizaciones comenzaron a convertirse en beta testers de las diferentes alternativas de videollamada disponibles en el mercado, por motivos evidentes. Una de las que generó más atención y acogida fue Zoom. Precisamente a raíz de esto, comenzaron a descubrirse y conocerse diversas vulnerabilidades que ponían en riesgo la seguridad y la privacidad de los usuarios. Hasta tal punto que el CEO de la compañía tuvo que emitir un comunicado para acallar las críticas y pedir la confianza de los usuarios. Un gesto como este, es entendido si se acompaña de un trabajo en la senda de la mejora continua En este sentido, Zoom logró recuperarse y a día de hoy continúa siendo ampliamente utilizada como aplicación a la hora de realizar videollamadas personales, corporativas o eventos. Otra aplicación mundialmente conocida, que hasta ahora ha ocupado el trono en lo que a sistemas de mensajería instantánea se refiere, WhatsApp, ha sido noticia por sus problemas de seguridad a lo largo de la historia. Desde comenzar por tan siquiera cifrar las conversaciones, pasando por utilizar correctamente el cifrado pero exponiendo el número de teléfono de los usuarios (lo que motivó mi herramienta WhatsApp Discover allá por 2014) hasta terminar modificando completamente su protocolo y adoptando el cifrado punto a punto de Moxie Marlinspike en 2016. Hasta la fecha, mediante mejoras y actualizaciones, WhatsApp ha ido reponiéndose de todos y cada uno de los problemas, manteniendo la confianza de los usuarios. Sin embargo, es ahora cuando parece que quizá se le hayan acabado las oportunidades. No a causa de un problema de seguridad. En este caso, a raíz de una decisión voluntaria que afecta a la privacidad de los usuarios. Un cambio en los términos de condiciones que ha generado muchísimo revuelo en las últimas semanas, y que ha provocado un éxodo de más de 25 millones de usuarios a Telegram en tan sólo cuestión de unos días. Veremos cómo afecta finalmente esto a lo largo del tiempo. Lo que parece que está claro, es que en esta vida nada es permanente. Mucho menos el éxito de un modelo, tecnología o la continuidad de negocio. De hecho, lo acontecido en el pasado 2020 ha traído consecuencias graves en muchos sectores, donde profesionales independientes, pymes y grandes multinacionales afrontan la necesidad de adaptarse al nuevo escenario y reinventarse para seguir buscando su queso. Para muchos que con mucho esfuerzo habían podido alcanzar un equilibrio o una posición en el mercado, quizá la nueva normalidad que ahora vivimos, haya vuelto a colocarles en la casilla de salida. Terrible e injusto, pero cierto. Por fortuna o por desgracia, no nos queda otra que ser resilientes, seguir aprendiendo de nuestros errores y trabajando cada día por diferentes objetivos. Por contribuir a una sociedad digital más segura, diseñando sistemas y tecnologías más seguros, así como por lograr nuestras metas profesionales y personales, individuales y colectivas. Y esto, sólo podremos hacerlo a base de mucho sacrificio, esfuerzo, perseverancia, y constancia. Con épica o sin ella, pero dando cada día lo mejor de nosotros mismos. No pain, no gain y a hackear este 2021.

Aquí estamos, otro año más. Aún con la resaca del champán y las uvas de nochevieja, dispuestos a comenzar este 2020 que no sabemos lo que nos deparará en materia de seguridad. Una buena manera de abordar el comienzo de cada año es hacer balance de lo que ha sucedido en el ciclo de 365 días que ya toca a su fin. Y es que este 2019 que ya dejamos atrás ha sido un año bastante movido en lo que a noticias de seguridad se refiere. Incidentes por ransomware en grandes empresas que han generado bastante revuelo mediático, vulnerabilidades sonadas como BlueKeep, y como no podía faltar, muchísimos sucesos relativos a fugas de información y data breaches. Precisamente a estos últimos, son los que vamos a dedicar un repaso en este post. En el pasado 2019, según el estudio realizado por la firma “Risk Based Security”, hasta el último trimestre se habían registrado 5.183 incidentes de brechas de datos, que exponían aproximadamente 8.000 millones de registros. Esto supone un 33% más de incidentes que a la misma altura de año en 2018 y supera con creces la cifra del total de brechas de datos en 2017. Brechas de seguridad reportadas en 2019 (Risk Based Security) Entre las organizaciones afectadas las hay de todo tipo: compañías del sector sanitario, financiero, entidades públicas e incluso gigantes tecnológicos. Prácticamente cualquier tipo de organización que podamos imaginar habrá sufrido una brecha de datos el pasado año. De hecho, un aspecto a señalar es que gran parte de los incidentes notorios que se han conocido no han venido dados por ataques complejos o sofisticados ni explotación de vulnerabilidades zero day, sino más bien por fallos de seguridad que implican malas prácticas respecto a autenticación, laxos o nulos controles de acceso, servidores expuestos con información sensible o acceso a información sin necesidad de contraseña. Llama bastante la atención, sobre todo cuando hablamos además en algunos casos de empresas multinacionales de entidad y conocidas de la industria tecnológica. Comencemos pues a repasar de manera cronológica las brechas de seguridad más relevantes que conformarían el “Hall of Shame” del pasado 2019. ¿Cómo empezó el año? Enero arrancaría con el mediático incidente que afectó a la conocida cadena de hoteles Marriott. La compañía anunció una brecha que afectaba a alrededor de 383 millones de huéspedes. En el mismo mes, investigadores de Check Point descubrieron una vulnerabilidad que permitía a un atacante robar información personal de los usuarios del popular juego Fortnite y que podría afectar a alrededor de 200 millones de gamers. También se descubrió un leak de un servidor de ElasticSearch que exponía información de un casino online con datos privados de apuestas de más de 108 millones de jugadores. Pero sin duda alguna, la noticia del mes de enero en materia de seguridad y en concreto de brechas de datos fue la de Collection 1, conocida hasta la fecha como la mayor filtración de datos de la historia. Una colección de leaks formada por 12.000 archivos que constituían 87 GB y que residía en los servidores de MEGA. Incluía información de 773 millones de direcciones de que pertenecían a cuentas de usuario de diferentes servicios conocidos , ya que aglutinaban más de 2.000 bases de datos. Fue descubierta por Troy Hunt y cargada a su famoso portal “Have I Been Pwned?”. Collection 1, acuñada en enero como la mayor filtración de datos de la historia En febrero salió a la venta en la Dark Web una colección de cuentas de 16 servicios entre los que se incluían Dubsmash, Armor Games, Whitepages o MyFitnessPal que sumaban en total la friolera de 620 millones de registros. En el mes de marzo conocimos la noticia de que las cuentas de cientos de millones de usuarios de Facebook e Instagram se almacenaban en texto plano en algunos de sus servidores, por lo que los empleados de la compañía podrían haber tenido acceso a las mismas. Una de las brechas de datos más importantes del año se descubrió también en dicho mes. El conocido servicio de validación Verficiations.io dejó al descubierto una base de datos MongoDB de 150GB que contenía más de 808 millones de registros. Leak de Verifications.io descubierto por Bob Diachenko ¿Qué sucedió en el segundo trimestre? En abril le volvió a tocar el turno a Facebook. Esta vez por almacenar en un servidor de Amazon información públicamente accesible de user IDs, nombres, likes y comentarios de más de 540 millones de usuarios. También en este mes, una entidad pública del Gobierno de la India dejó al descubierto información médica de más de 12,5 millones de mujeres embarazadas. Información expuesta en la India de 12,5 millones de mujeres embarazadas En mayo el protagonismo en materia de brechas de datos fue para la compañía First American Financial, una importante empresa que forma parte del Fortune 500 y que exponía información de 885 millones de registros de transacciones relacionadas a hipotecas y préstamos. No era necesario estar autenticado. Bastaba con cambiar un dígito en el link de acceso para poder acceder a los registros. Un ejemplo de los millones de registros con información sensible expuestos en la web de First American Financial ¿Y en los meses de verano? Llegamos al mes de junio, donde también hubo incidentes en este sentido. Información expuesta por parte de AMCA de 20 millones de estadounidenses que incluía nombres, números de seguridad social, direcciones, fechas de nacimiento e información de tarjetas de crédito. El mes de julio fue para Capital One, que reportó una brecha de seguridad que afectaba a 100 millones de ciudadanos americanos y 6 millones de canadienses. En agosto conocimos la noticia de que la compañía MoviePass había expuesto una base de datos sin cifrar, lo que dejaba al descubierto la numeración de tarjetas de crédito de 161 millones de usuarios. En Inglaterra, un leak masivo exponía información biométrica que pertenecía a la policía metropolitana, bancos y otras compañías. Información de la brecha de Zynga en el portal “Have I been pwned?” Algunos casos de finales de año Septiembre nos trajo otros incidentes relevantes. El más grave fue el de la compañía Zynga anunció una brecha que afectaba a 218 millones de usuarios de los conocidos juegos “Draw Something” o “Words with Friends”. Bob Diachenko, investigador responsable de varias de las brechas comentadas hasta ahora, descubrió en octubre junto a otro investigador un servidor desprotegido de Elasticsearch, que incluía 1.200 millones de registros de datos personales de usuarios. Bases de datos en servidor de Elastic Search que aglutinaban 1.200 millones de registros Facebook volvió a salir a la palestra en el mes de noviembre. En esta ocasión por dar acceso inapropiado a 100 desarrolladores a datos a los que no deberían haber podido acceder. ¿Qué podemos sacar en claro? Como podemos observar, ha sido un año bastante impactante. Entre los incidentes comentados podemos registrar 10 casos donde se han expuesto más de 100 millones de registros. Es muchísima la información comprometida y, a día de hoy, prácticamente nada nos sorprende. Leemos noticias de incidentes en las que se exponen y filtran cantidades ingentes de información, y con el paso de los años nos hemos acostumbrado a ello. Como señalamos además al comienzo de este post y hemos ido viendo a lo largo de este repaso, prácticamente todos estos incidentes no han llevado consigo la explotación de una vulnerabilidad compleja o desconocida. En la mayoría de los casos se trata de bases de datos desprotegidas en servidores expuestos públicamente, o acceso a información en repositorios y sitios webs de entidades que está disponible sin necesidad de autenticación o contraseña. Paradójico que en el momento en el que nos encontramos, donde la ciberseguridad está en boga y la regulación presiona a las organizaciones con sanciones económicas por este tipo de incidentes, sigan sucediéndose brechas de datos con tanta asiduidad. Un ejemplo más de que es muy complicado proteger todos los flancos de una organización y de que la seguridad 100% es imposible de alcanzar. No sólo hace falta actualizar sistemas y parchear vulnerabilidades sino también monitorizar todos los activos expuestos y conocer el nivel de profundidad de nuestra exposición digital. En este sentido, soluciones como Faast o Cyberthreats pueden ser de ayuda para prevenir y detectar este tipo de incidentes. Desde el punto de vista de los usuarios, es importante intentar estar al día de todos estos incidentes así como de las comunicaciones que las entidades realizan tras una brecha de este tipo para apresurarnos a fortificar la seguridad de nuestras cuentas, así como huir de la reutilización de contraseñas. Comenzamos este 2020 expectantes, en aras de ver si la evolución en número de brechas de seguridad sigue al alza o si conseguimos una reducción en el número de millones de registros expuestos. Lo sabremos dentro de 12 meses.

A estas alturas, es probable que muchos de nosotros tengamos claro los diferentes tipos de riesgos que involucran el uso de redes inalámbricas. Tanto desde el punto de vista de gestionar la seguridad de nuestra red doméstica o corporativa, como a la hora de conectarnos a una red ajena. Sabemos desde que el cifrado WEP presentaba vulnerabilidades fáciles de explotar con herramientas de botón gordo, lo que daba lugar a que durante muchos años algún vecino intentara robarte la Wifi. Posteriormente aparecieron WPA como pre-estándar y WPA2, considerado como estándar seguro durante muchísimos años. De hecho más allá de los ataques mediante WPS, para comprometer este tipo de redes no quedaba otra que utilizar un ataque de diccionario una vez capturado el handshake como mostraban mis compañeros del equipo de CSAs en este talk sobre “Seguridad en redes Wifi” de la temporada pasada. https://www.youtube.com/watch?v=Auf6foriw2k En octubre de 2017, Mathy Vanhoef descubrió las famosas vulnerabilidades Krack Attacks, de las que hablamos ya en su día al mencionar la llegada inminente de WPA3. Sin embargo, respecto a redes WiFi Públicas como las que se nos brindan en aeropuertos, hoteles, centros comerciales, etc. Debemos tener una consideración especial a la hora de hablar de seguridad, este tipo de redes públicas suelen ofrecerse por lo general abiertas (sin cifrado) para facilitar la conexión por parte de los clientes. Esto ya abre la puerta a ataques de monitorización pasiva del tráfico que cualquier usuario pueda transferir en texto plano. Algo que también podría hacerse si en lugar de estar abierta utiliza cualquier estándar de cifrado (WEP,WPA,WPA2), ya que todos los clientes en teoría disponen abiertamente de la clave para conectarse a la red, al ser una red pública. Aunque esto añadiría un nivel más de seguridad, pues para poder monitorizar el tráfico de un cliente en una red WPA2 es necesario capturar los paquetes del 4-way handshake inicial. De lo contrario no sería posible, aunque para ello se pueden enviar paquetes de deautenticación al cliente y forzarle a reconectar. En cualquier modo, pese a que es posible está claro que una red abierta sin cifrado facilita mucho la labor. La gestión de la seguridad en este tipo de redes se suele hacer mediante un portal captivo, que administra los usuarios y otros aspectos dependiendo del modelo de explotación de la red (gratuita o de pago mediante diferentes planes de datos). Existen muchos ejemplos de estos portales, y los que viajamos a menudo estamos acostumbrados a lidiar con muchos de ellos para poder obtener conectividad en aeropuertos u hoteles, así como también en aviones. Es cada vez más habitual que las compañías aéreas ofrezcan conexión Wifi a sus pasajeros para tener acceso a Internet. En algunos casos de manera gratuita y en otras con diferentes tarifas para conseguir mayor velocidad de transferencia o cantidad de tráfico. Incluso hay compañías que ofrecen redes Wifi sin acceso a Internet pero que permiten acceder a una serie de contenidos de entretenimiento tales como películas, series, música, o hablar con otros pasajeros... Debido a la frecuencia de viajes que me toca hacer al año, he viajado en numerosos vuelos en los que he podido probar este tipo de redes. Generalmente en casi todos los casos, el dispositivo que implementa la red suele incluir medidas de seguridad como el aislamiento para evitar que un cliente pueda tener conectividad con otro equipo dentro de la LAN. Se restringe la comunicación con cualquier dispositivo que no sea el punto de acceso (que hace también de gateway) a nivel de red y también se suele bloquear el tráfico ARP siendo dicho punto de acceso el que responde a todas las peticiones ARP con su propia dirección MAC. Esto no sólo cierra la puerta a ataques man in the middle mediante arpspoof sino que también impide que se puedan identificar el resto de clientes conectados. Sin embargo, no todos tienen implementada las protecciones debida como pueden ver en la imagen 1, que corresponde a un viaje que he realizado en una aerolínea que ofrecia WiFi a sus clientes. En este caso, ha llamado la atención que el portal cautivo no se encontraba utilizando HTTPS a pesar de requerir datos al usuario para lograr acceso a dicha conexión gratuita. Imagen 1: Clientes conectados a la red Wifi del avión durante el vuelo. A raíz de analizar la dirección MAC de los clientes conectados, podría identificarse la marca de los dispositivos en algunos casos e inferir dependiendo de cada caso si se trataba de dispositivos móviles u ordenadores de escritorio, así como distinguir entre dispositivos por marcas tales como Samsung, Apple o BQ. Lo complejo de esto, es que no sólo sería posible identificar los dispositivos que responden a peticiones ARP, sino que se dispone de total conectividad en la LAN que implementa el punto de acceso, lo cual permitiría incluso escanear los puertos de cada dispositivo. Imagen 2: Dispositivo iOS con puertos TCP 62078 y 9080 abiertos y accesibles. De ahí en más, ya conocemos lo que podría suceder analizando los puertos abiertos y los servicios que corren. En el ejemplo de la imagen 2 y 3 se podía conocer de antemano que el dispositivo con la IP 10.178.2.95 podría ser un iPhone o un iPad, al tener abierto el puerto TCP 62078 que los dispositivos iOS utilizan para la sincronización con iTunes, y el 9080 que se corresponde con un servidor web arrancado por la aplicación de Netflix. Por lo que podemos inferir a estas alturas, que ese dispositivo es un iPad o iPhone, cuyo dueño está utilizando la popular aplicación para ver una película o serie durante el vuelo. Imagen 3: Servidor Web en puerto 9080 respondiendo “status=ok”. Esto así quizá pueda no decir mucho, pero bastaría con levantarse y dar un paseo en el avión hacia el aseo para identificar un pasajero que esté utilizando su app de Netflix en un iPhone o un iPad para asociarlo al dispositivo que hemos identificado en la dirección IP 10.178.2.95 y del que también disponemos de su dirección MAC. Esto permitiría realizar un profiling completo de un posible objetivo para ataques dirigidos. De hecho, a raíz de la dirección MAC podríamos identificar la presencia del pasajero al que habremos visto en cualquier red inalámbrica a la que se conecte en el futuro tan sólo monitorizando el tráfico desde fuera incluso si no disponemos de acceso a la misma. Un info-leak más en toda regla como los que recopilaban Chema Alonso y Martina Matarí a la hora de hablar de ataques Corporate Fake News APT en su charla durante el pasado SID. Por otra parte, cabe recordar que dispondríamos de todo el tiempo que dure el vuelo para mediante ingeniería social utilizando técnicas conocidas como por ejemplo shoulder surfing durante varios paseos hacia el aseo, poder recopilar toda la información posible del pasajero y generar mayor conocimiento acerca del objetivo. Además de la ventaja inherente a las redes Wifi abiertas, de siempre poder monitorizar el tráfico generado por dicho usuario, pero en este caso sabiendo ya a quién pertenece dicho tráfico. Todo lo que no fuera cifrado podría ser identificado, pero incluso accediendo al tráfico cifrado y analizando los endpoints podríamos saber los servicios y aplicaciones que utiliza durante el vuelo (Whatsapp, Telegram, Spotify,…) Todo esto nos daría una base de conocimiento importante en esta labor de profiling. Imagen 4: Paseo con Shoulder Surfing durante uno de mis innumerables vuelos. Todo ello sin olvidar que al margen de la posibilidad de recolectar información para generar inteligencia, al disponer de conectividad total con cualquier cliente en la red, podría ser posible tanto acceder a servicios no fortificados, como explotar vulnerabilidades que pudiéramos identificar para comprometer la seguridad de los mismos. Aún son muchos los equipos de usuarios que se pueden encontrar sin actualizar con el puerto 445 abierto, vulnerables a los famosos EternalBlue y DoublePulsar. Como hemos venido diciendo, muchas redes Wifi que solemos encontrar en aviones o entornos de este tipo habilitan medidas de seguridad que nos protegen de posibles ataques directos por partes del resto de clientes, al margen de la monitorización pasiva de tráfico. No obstante, siempre es posible encontrar un escenario como el expuesto donde podamos ser más vulnerables. Además, en este caso el utilizar una VPN para nuestro tráfico hacia el exterior seguiría sin resolver algunos de los problemas comentados. Por ello, conviene tener en cuenta todos los aspectos señalados, mantener siempre actualizado nuestro dispositivo y no descuidar nunca la seguridad a la hora de conectarnos a cualquier red ajena.

Retomamos el post anterior, en el cual realizamos la introducción a las vulnerabilidades FakesApp publicadas por los investigadores de Check Point y descubrimos el proceso para poder instalar la extensión WhatsApp Decodery descifrar correctamente el tráfico de WhatsApp. En este punto, si quisiésemos replicar el ataque, el proceso a seguir sería: cambiar la cadena de texto entrante de un mensaje descifrado por la que queremos, modificar varios parámetros, cifrar el mensaje de nuevo, copiarlo a la extensión en base64, decodificarlo y por último, enviarlo. Veamos el proceso para comprobar qué sucede. El siguiente mensaje pertenece a una conversación que mantenía con mi padre durante el rato que preparaba las capturas para este post: De cara a probar la vulnerabilidad, sustituyo el mensaje para indicar que el producto que “menos” se vende (en vez del que "más") es la telefonía móvil. Según los investigadores, antes de cifrarlo, es necesario modificar el valor ID a cualquier otro que no exista en la base de datos, así como también el messageTimeStamp. Una vez hecho esto, basa con seleccionar “Encrypt” y trasladar este paquete cifrado a la pestaña de “Intercept” donde tenemos parado el mensaje original entrante para sustituir una cadena por otra. Una vez que tenemos el mensaje modificado en base64 seleccionado, basta con copiarlo en la pestaña de “Intercept", y presionar posteriormente “Ctrl-Shift-B” para volver a decodificarlo de base64. Ahora solo queda presionar el botón “Forward” para enviar el mensaje modificado a nuestra sesión de WhatsApp Web. Cabe aclarar que en algunas ocasiones y a pesar de seguir los pasos indicados, el mensaje modificado puede no llegar a visualizarse en la sesión web. Como podemos observar, el mensaje modificado no se llega a visualizar en la conversación de WhatsApp Web, por lo que no fue posible replicar el ataque. No obstante, en otros casos sí que ha sido posible reproducirlo tal como se puede ver en la siguiente captura, durante una prueba, donde he conseguido modificar un mensaje enviado por mi amigo David con emoticonos, sustituyéndolo por un texto. Tal y como se muestra en la imagen, en el mensaje que le envío, la cita incluye la cadena de texto “guapo” que él jamás llegó a enviar. Fue el segundo mensaje con emoticonos el que modifiqué en mi sesión de WhatsApp Web tras realizar el proceso comentado, como se puede ver en la siguiente imagen. En este punto, bastó responder en la sesión de WhatsApp Web para que tanto él como yo, viéramos ese texto en la cita, consiguiendo reproducir palabras que él no había escrito y replicar así el ataque FakesApp. Conclusiones finales Como hemos visto, en algunos casos es posible reproducir en tiempo real el ataque FakesApp pero en otros no. Por otra parte, se trata de un proceso relativamente complejo que ha de ser llevado a cabo en un corto instante de tiempo. Aun así, es igualmente interesante conocer el proceso en aras de poder utilizar esta extensión para descifrar mensajes y analizar el protocolo de comunicación de WhatsApp. A su vez, a la hora de analizar el tráfico de Whatsapp Web, además del tráfico cifrado que hemos podido descifrar, es posible ver que se transmiten algunos paquetes en texto claro, que no tienen que ver con las conversaciones pero sí con temas de signaling. Del tráfico que se visualiza en la imagen anterior, se puede deducir que el usuario está manteniendo una conversación con el contacto que se muestra en el parámetro “id” y que dicho contacto está en ese momento en estado “composing”, equivalente a cuando visualizamos el estado “escribiendo…”. Esto abriría las puertas a que un atacante pudiese obtener información acerca de las personas con las que mantiene conversaciones un usuario (con sus números de teléfono), así como otra información que pudiese obtener de estos paquetes. Todo ello, claro está, en entornos donde sea posible realizar un ataque man in the middle que además permita intercepción de HTTPS. Como hemos visto, las vulnerabilidades FakesApp no tienen impacto sobre la confidencialidad de las conversaciones, aunque sí que pueden generar cierto caos en algunos escenarios, sobre todo combinadas con ingeniería social. No obstante, su explotación requiere de ciertas condiciones y los mensajes que se quieran modificar han de ser interceptados y manipulados en tiempo real. No obstante, no deja de ser un trabajo de investigación exhaustivo y muy interesante, que puede ayudar a seguir profundizando en el conocimiento de detalles técnicos acerca de uno de los sistemas de mensajería instantánea más utilizados en el planeta. También te puede interesar: » Analizando el impacto de las vulnerabilidades FakesApp y descifrando el tráfico de WhatsApp Web con “Whatsapp Decoder” (Parte 1/2)

Hace unos meses, unos investigadores de Check Point publicaron información sobre una serie de vulnerabilidades que habían descubierto en WhatsApp, a las que acuñaron bajo el nombre de “FakesApp”. Hemos visto en el pasado otras vulnerabilidades que generaron revuelo, tanto para WhatsApp como para otros sistemas de mensajería. Según los investigadores de CheckPoint, las vulnerabilidades descubiertas permitían interceptar y manipular los mensajes que se enviaban, tanto en conversaciones privadas como en grupos. Esto abría la puerta a diferentes tipos de ataques orientados a intentar distribuir fakes news o información falsa utilizando este popular sistema de mensajería. En el post original donde exponían su trabajo, describían tres posibles escenarios de ataque que mostraban cómo combinando las vulnerabilidades descubiertas y la ingeniería social se puede engañar a los usuarios y hacerles llegar contenido falso. Los mensajes que se podían manipular eran los que se recibían en una sesión WhatsApp Web, al ser transferidos del móvil al navegador. En este momento, el atacante podría interceptar los mensajes que recibía para modificar el contenido enviado por el remitente en su propia sesión de WhatsApp Web. La vulnerabilidad estaba en que, si el atacante respondía al remitente tras haber modificado su mensaje y utilizaba la función de “quote” (la de citar el mensaje en la respuesta), al recibir dicha respuesta el remitente vería en la cita el texto modificado por el atacante, en lugar del que él envió. En esencia, el atacante conseguiría poner palabras en boca del remitente que jamás pronunció. Esto podría generar confusión y algún quebradero de cabeza, aunque el remitente fuera consciente de que él jamás envió el mensaje que aparece como suyo en la cita de la respuesta. Vídeo explicativo del procedimiento anterior: El tema se complica un poco más a la hora de tratarse de grupos. En este caso, utilizando la misma técnica el atacante podría, modificando la cita de cualquier remitente en una respuesta, crear confusión entre el resto de miembros del grupo. Aunque estos pudieran ver el mensaje original repasando el histórico de la conversación, al leer los últimos mensajes como usualmente se suele hacer, verían en la cita el texto modificado por el atacante. Además de esto, podría suplantar la identidad del remitente por la de un miembro inexistente en el grupo, modificando la cadena de texto que lo identifica. Existe otra variante más de explotación de esta vulnerabilidad en la que se puede enviar un mensaje en privado a un miembro del grupo para que éste crea que se manda a todo el grupo en conjunto, de manera que cuando este responda a dicho mensaje, este último será visible para todos los participantes en la conversación. Lo que es necesario señalar es que el atacante en ningún momento puede modificar el mensaje original en la base de datos de WhatsApp, puesto que los mensajes se reciben en el dispositivo móvil primero y luego en la sesión de WhatsApp Web. De hecho, para poder realizar estos ataques, a la hora de manipular los mensajes, no sólo habrá que modificar el texto en cuestión, sino también el identificador del mensaje por uno que no exista en la base de datos. En el post original, los investigadores de Check Point afirmaban que llegaron a sus hallazgos a raíz de analizar con detalle el cifrado punto a punto de WhatsApp. Al tratar de hacer ingeniería inversa del algoritmo de WhatsApp para descifrar los datos, llegaron a la conclusión de que se utilizaban los “Protocol buffers”. Convirtiendo los datos de protobuf2 a Json eran capaces de visualizar los parámetros que se enviaban y manipularlos para poder comprobar la seguridad de WhatsApp. A raíz de esto los investigadores desarrollaron una extensión llamada “WhatsApp Decoder” para el conocido proxy Burp que permitiese a cualquiera poder realizar el mismo proceso. Extensión “Whatsapp Decoder” para Burp Para realizar este ataque se debe instalar la extensión desarrollada por los investigadores, obtener las claves de sesión y algún otro parámetro, interceptar el tráfico en tiempo real, descifrarlo, decodificarlo, modificarlo, volverlo a codificar, cifrar y enviarlo de nuevo, además en tiempo real. Por ello, he considerado interesante replicar el proceso para entender cómo se cifran y descifran los paquetes, identificar los diferentes parámetros y profundizar en el conocimiento del protocolo de comunicación. Instalando y configurando la extensión El primer paso es descargar la extensión del repositorio y seguir las instrucciones de instalación respecto a dependencias. Como la extensión ha sido desarrollada en Python, es necesario instalar previamente Jython siguiendo las instrucciones de la documentación oficial de Burp. Una vez hecho esto estaremos en disposición de añadir la extensión a nuestro proxy. A continuación, es necesario obtener las claves pública y privada de la comunicación con WhatsApp Web. Esto hay que realizarlo previamente a la generación del código QR que nos muestra la versión web de WhatsApp. Para ello, hay que utilizar el depurador del navegador e introducir un breakpoint en un punto específico. Obteniendo clave pública y privada previa a generación del código QR Además de las claves pública y privada, es necesario obtener el parámetro “secret” que se transfiere al establecerse la comunicación entre nuestro dispositivo móvil y la sesión de WhatsApp Web. Para acometer este paso, es necesario configurar previamente el navegador para redirigir todo el tráfico HTTP y HTTPS a través del proxy Burp. Posteriormente, procedemos a escanear el código QR con el dispositivo móvil y una vez que la sesión web se haya iniciado correctamente, en la pestaña de Burp correspondiente a los websockets podremos encontrar la información que necesitamos. Captura del objeto “ref” con el parámetro “secret” al establecer la sesión El parámetro “secret” se transfiere en el objeto “ref”. Además de este, podemos encontrar otros parámetros relevantes como los tokens de cliente, servidor y navegador, así como visualizar el número de teléfono del usuario que se transmite en el parámetro “wid”, la versión de WhatsApp que utiliza, el porcentaje de batería del que dispone, la marca y modelo de dispositivo o el nombre con el que se muestra a sus contactos. En este punto, ya disponemos de la información necesaria para poder configurar la extensión de Burp y descifrar el tráfico de WhatsApp. Debemos de copiar el objeto “ref” en el primer cuadro de texto asegurándonos de que contiene el parámetro “secret”, así como las claves pública y privada recabadas en el paso anterior en los cuadros de texto restantes. Configurando la extensión de Burp para descifrar el tráfico de WhatsApp El siguiente paso es arrancar el script “parser.py” que se incluye en la carpeta “helper” al descargar el código de la extensión del repositorio de GitHub. Una vez arrancado el script y configurada correctamente la extensión, toca pulsar el botón “Connect” y comprobar que se visualiza el mensaje “Ok” en verde. Arrancando el script “parser.py” y conectando la extensión A partir de aquí, si todo ha ido bien y hemos seguido correctamente los pasos, ya estamos en disposición de descifrar correctamente el tráfico de WhatsApp, tanto el entrante como el saliente. Veamos cómo funciona. Descifrando el tráfico de WhatsApp Para poder descifrar y manipular el tráfico de WhatsApp, es necesario ir a la pestaña del Proxy en Burp y activar la opción “Intercept” de cara a capturar los paquetes. Se transmiten diferentes tipos de paquetes. Algunos van sin cifrar y hacen referencia a diferentes aspectos de la sesión de WhatsApp (comentaremos algún ejemplo más adelante). Nos centraremos ahora en los que corresponden a mensajes de conversaciones, que evidentemente acaparan más interés y son los que abren la puerta a los ataques comentados anteriormente. Cuando recibimos un mensaje entrante, podremos identificarlo porque además de estar cifrado es ininteligible. Capturando un mensaje cifrado entrante en Whatsapp Web Para poder descifrar el mensaje mediante la extensión, previamente hay que convertir el contenido a base64 seleccionándolo en la ventana y presionando la combinación de teclas “Ctrl-B”. Convirtiendo el contenido del mensaje cifrado a base64 Una vez convertido a base64 basta con copiar esta cadena de texto en la extensión, y presionar el botón “Decrypt” tras haber habilitado previamente el botón “Incoming” para especificar que estamos analizando tráfico entrante. Descifrando un mensaje entrante en Whatsapp Web Como se puede ver, una vez se descifra el mensaje es posible ver en claro todos los parámetros: El valor del parámetro “conversation” corresponde al contenido en sí del mensaje, que en este caso es “jajajaja”. El parámetro “fromMe” indica si el mensaje ha sido enviado por el usuario. En este caso está false porque se trata de un mensaje entrante El “remotejid” es el parámetro que contiene la información del usuario emisor. En este caso incluye el número de teléfono del contacto que envía el mensaje. El “id” corresponde al identificador único del mensaje que coincide con el que se almacena en la base de datos del dispositivo móvil. En este caso, hemos descifrado un mensaje de un chat individual. En el caso de tratarse de un chat de grupo, aparecería además el parámetro “participant” que indicaría el miembro del grupo que ha enviado el mensaje. En la siguiente entrega veremos cómo utilizar la extensión “Whatsapp Decoder” para replicar el ataque de FakesApp y ver lo que sucede en diferentes escenarios. También te puede interesar: » Analizando el impacto de las vulnerabilidades FakesApp y descifrando el tráfico de WhatsApp Web con “Whatsapp Decoder” (Parte 2/2)

Hace aproximadamente un año, precisamente por estas fechas, el panorama de la seguridad se veía sacudido por un descubrimiento de envergadura. Mathy Vanhoef, un investigador belga cuyo nombre pasará a los anales de la historia, revelaba al mundo una serie de vulnerabilidades descubiertas sobre el protocolo WPA2, que ponían en entredicho la seguridad de todas las redes inalámbricas del planeta. Hablamos de los Key Reinstallation Attacks, más conocidos por el acrónimo “Krack Attacks”. Se trata de una serie de vulnerabilidades que afectaban a la implementación del 4-way handshake, el mecanismo utilizado durante el proceso de autenticación en una red con WPA2. El handshake garantiza que tanto cliente como punto de acceso conocen la contraseña de acceso a la red y establecen una comunicación segura mediante la generación de una clave de sesión. Durante 14 años, este handshake había permanecido ajeno a ningún tipo de ataque, además de haber sido formalmente probado como seguro. Los Krack Attacks, sin embargo, vinieron a demostrar que tanto el 4-way como otros handshakes eran vulnerables a un ataque de reinstalación de clave. Mediante la manipulación y repetición de paquetes, un atacante puede forzar a un cliente a reinstalar una clave ya en uso. Al reinstalar dicha clave, se reinician los contadores nonce y el replay counter que se utilizan para evitar que dos paquetes sean cifrados con la misma “keystream”. Esto quiere decir que dependiendo de las circunstancias un atacante podría descifrar utilizando estadística algunos paquetes de datos de manera arbitraria, así como en otros casos inyectar también tráfico malicioso. Por otra parte, este ataque es realmente devastador para algunas versiones de Android. En estos casos, los dispositivos al reinstalar la clave la inicializan a cero, por lo que no hace falta romper los paquetes por estadística, sino que al reinstalar una “All-zero-Key” es posible descifrar todos los datos transmitidos por el dispositivo en cuestión. Como ya hemos comentado, además del 4-way había otros handhsakes afectados. Si tienes interés de profundizar acerca de los Krack Attacks y su implicación, puedes ver el vídeo de la charla que impartí en las XI Jornadas del CCN-CERT que incluye una demo en directo de la vulnerabilidad. Pese a que efectuar el ataque en un escenario real no es trivial pues requiere de ciertas condiciones como la implementación de un channel-based MITM, los Krack Attacks cuestionaron la continuidad del protocolo WPA2, que había sido considerado como un estándar seguro durante más de una década. Todo esto motivó que desde la Wifi Alliance se anunciase a principios del presente año la llegada de nuevas mejoras que garantizaran la seguridad de las comunicaciones inalámbricas de los usuarios. Esto se traduce en la llegada del WPA3, cuya especificación ha visto la luz el pasado mes de junio y que hemos comentado en nuestro #11PathsTalks de hace unos pocos días. WPA-3 Certified Program Lo primero que debemos de aclarar para evitar cualquier tipo de confusión, es que e l WPA3 no es un nuevo estándar o protocolo. En su lugar, se trata de un programa de certificación que especifica los estándares y protocolos que un producto debe soportar. Si dicho producto implementa correctamente estos estándares, podrá llevar la etiqueta de “Wi-Fi Certified WPA3”. Básicamente, esta etiqueta indica que un dispositivo ha pasado una completa batería de pruebas y cumple una serie de requisitos, que lo hacen compatible con otros dispositivos que también hayan obtenido la certificación WPA3. La seguridad en WPA3 continúa con dos modos de operación: WPA3-Personal para redes domésticas y WPA3-Enterprise para entornos corporativos que requieran de mayor seguridad. ¿Cuáles son entonces las funcionalidades que un dispositivo WPA3 debe soportar? En el comunicado de prensa inicial de la Wifi Alliance de enero se anunciaban cuatro importantes mejoras entre redes personal y enterprise como parte de la certificación WPA3: La primera de ellas y de la que más se ha oído hablar, es la de ofrecer protección robusta a ataques de diccionario incluso cuando los usuarios elijan contraseñas débiles. Otra destinada a simplificar la configuración de seguridad a la hora de añadir a una red dispositivos nuevos con interfaz de visualización limitada o que directamente no dispongan de ella. La tercera dirigida a reforzar la privacidad de los usuarios que navegan en redes abiertas mediante técnicas de cifrado individualizado de los datos. La cuarta y última, que también ha sido comentada es la del incremento del tamaño de clave a 192 bits. Una vez publicada la especificación final en junio, veamos en qué han quedado estas mejoras y cómo se han implementado. WPA3-Personal: Protección robusta contra contraseñas débiles Para ofrecer esta funcionalidad, en WPA-3 personal las redes domésticas protegidas por una contraseña, que hasta hora han utilizado autenticación Pre-Shared Key (PSK) pasarán a utilizar el Simultaneous Authentication of Equals (SAE) handshake. Se trata de una variante del handshake Dragonfly definido en el RFC 7664. Entre otras mejoras, este handshake es resistente a ataques de diccionario offline. En las redes WPA3-personal que utilizan SAE, la única manera de que un atacante obtenga la contraseña es mediante repetidos intentos reales de autenticación en los cuales sólo es posible probar una contraseña por iteración. Con la introducción de este handshake se ha incrementado considerablemente la seguridad en este aspecto, en contraste con las redes WPA2 que sí que eran vulnerables a ataques offline de diccionario. Otra de las grandes diferencias con respecto al WPA2 es que el uso de este handshake garantiza que, si en algún momento un atacante obtiene la contraseña de la red, no es posible utilizarla para descifrar el tráfico previamente capturado. En una red con WPA2 sí que era posible obtener la clave de sesión a partir de la contraseña de la red capturando los paquetes del handshake, y descifrar el tráfico antiguo. Por último, y como ya se ha comentado, gracias al uso de este handshake resistente a ataques de diccionario, los usuarios podrán establecer contraseñas sencillas de recordar que no tengan necesariamente que cumplir los habituales requisitos en cuanto a longitud y complejidad. Protected Management Frames y WPA3-Personal Transition Mode Otra de las características técnicas que traerá consigo WPA3 es el uso obligatorio de los Protected Management Frames (PMF). Ofrecen protección para tramas de gestión unicast y multicast. Los PMF ya eran opcionales en WPA2 y desde el principio del presente año es obligatoria su implementación en dicho estándar. Entre otras ventajas, este tipo de tramas ofrecen protección contra ataques de de-autenticación. Por otra parte, cuando los usuarios empiecen a adoptar WPA3 en sus redes personales, pueden aprovecharse de la funcionalidad WPA3-Personal Transition Mode, definida en la especificación del WPA3. Este modo de transición permite una migración gradual en una red a WPA3-Personal manteniendo la interoperabilidad con dispositivos WPA2-Personal para de este modo no interrumpir el servicio a los usuarios. Para ello, un punto de acceso WPA3-Personal en modo transición habilita WPA2-Personal y WPA3-Personal simultáneamente para poder dar servicio a dispositivos tanto WPA2 como WPA3 con la misma passphrase. Los dispositivos que soporten ambos modos se conectarán utilizando el método que ofrece mayor seguridad, esto es el WPA3 cuando esté disponible. Para poder garantizar la interoperabilidad con aquellos dispositivos que no soporten aún PMF, el modo de transición WPA3 configura la red de tal modo que el uso de este tipo de tramas es opcional en lugar de obligatorio. Wi-fi Easy Connect: Configuración sencilla de seguridad para nuevos dispositivos La funcionalidad que la Wifi-Alliance anunciaba respecto a la configuración sencilla para añadir a una red nuevos dispositivos de forma segura estará certificada por el programa Wi-fi Certified Easy Connect. Con él se pretende reducir la complejidad y mejorar la experiencia de usuario a la vez que incorporar los más altos estándares de seguridad. Para poder configurar un dispositivo, bastará con escanear el código QR del producto para habilitar su uso en una red Wifi. Esto será posible mediante el protocolo DPP (Device Proivisioning Protocol) desarrollado por la Wi-fi Alliance. El dispositivo seleccionado se considera con el rol configurador y el resto con el de suscriptores. El usuario establece una conexión segura con un dispositivo suscriptor escaneando el código QR del dispositivo configurador o introduciendo una cadena asociada con dicho dispositivo. Esto pone en marcha el protocolo y automáticamente aprovisiona al suscriptor con las credenciales necesarias para acceder a la red. Para la autenticación segura se utiliza criptografía de clave pública. Wi-fi Enhanced Open: Garantizar la privacidad en redes abiertas Mediante el programa de certificación Wi-Fi Certified Enhanced Open, se proporciona protección contra la monitorización pasiva de tráfico por parte de terceros en una red abierta, sin la necesidad de requerir una contraseña o pasos adicionales para unirse a la red. Se basa en el uso de OWE (Opportunistic Wireless Encryption) definido en el RFC 8110, y proporciona mecanismos de cifrado para proveer a cada usuario con un cifrado individual que protege el intercambio de datos entre el dispositivo y la red inalámbrica. WPA3-Enterprise: Tamaño de clave de 192 bits En WPA3-Enterprise no se modifica ni reemplaza ninguno de los protocolos definidos en el WPA2-Enterprise. En su lugar, simplemente se definen políticas para proporcionar mayor consistencia en la aplicación de dichos protocolos. Entre dichas políticas, tenemos que, para entornos sensibles, la versión Enterprise de WPA3 permite utilizar un tamaño de clave de 192 bits. Pero esto es algo opcional. Aclaración: Wi-Fi Easy Connect y Wi-Fi Enhanced Open no son parte de WPA3 Tras haber hecho este recorrido, podemos comprobar que en efecto la Wi-Fi Alliance ha implementado mecanismos para proveer a los usuarios con las funcionalidades anunciadas en enero. Sin embargo, esto nos puede llevar a cierta confusión entre los usuarios. Ya que pese a que en algunas publicaciones y blogs se enumeren estas medidas de seguridad a la hora de hablar de WPA3, lo cierto es que no todas estas funcionalidades y mejoras forman parte del WPA3. Al igual que como ya hemos especificado, el WPA3 no es nuevo estándar, sino un programa de certificación. Si leemos con atención los párrafos anteriores, veremos que además del WPA3-Personal y WPA3- Enterprise se mencionan Wi-fi Easy Connect y Wi-fi Enhanced Open. Estos dos últimos, como bien hemos señalado, son a su vez dos programas de certificación apartes del “Wi-fi Certified WPA-3”. Es decir, que un dispositivo que esté certificado en WPA3 no tiene por qué también implementar las medidas de seguridad recogidas por los otros dos programas. Esta es precisamente una de las cosas que lamenta Mathy Vanhoef en un post de su blog que titula “WPA3: A missed opportunity” en el que explica que, pese a que desde la Wifi Alliance se anunciaban cuatro nuevas e importantes mejoras, finalmente sólo una de ellas (el handshake basado en dragonfly) ha resultado ser obligatoria en WPA3. Ya que el resto forman parte de otros programas y el uso del WPA3-Enterprise para un tamaño de clave de 192 bits es opcional, no obligatorio. Es por ello que Vanhoef considera que se ha perdido una oportunidad única de mejorar considerablemente la seguridad de los usuarios, puesto que no será obligatorio implementar todas las medidas descritas. Por otra parte, pese a que se trate de programas de certificación diferentes, en la práctica podría ser posible que los fabricantes decidan implementar también las funcionalidades especificadas en Wi-fi Easy Connect y Wi-fi Enhanced Open a la hora de industrializar productos certificados bajo WPA3. Sin duda alguna, sería lo deseable. Veremos qué sucede. Recuerden que pueden escribirnos con preguntas o sugerencias en nuestra comunidad con la intención de crecer juntos compartiendo información, herramientas y puntos de vista. Deepak Daswani CSA - Chief Security Ambassador @dipudaswani Deepak.Daswani@global.11paths.com