18 jun 2021

Nuevo Windows 11: Una ventana al futuro

Por el 18 jun 2021 con 0 comentarios

Muy buenas a todos! Recientemente "se filtró" una ISO de la nueva versión del Sistema Operativo de Microsoft, más concretamente se trata de Windows 11 Build 21996.1, la cual podemos levantar en una máquina virtual como de costumbre. El proceso de instalación es similar al que ya conocemos: tenemos el famoso asistente de instalación y luego se nos presentará un renovado asistente de configuración que debemos completar eligiendo las diferentes opciones que se nos proponen, para elegir cómo queremos compartir nuestra información... 
Si bien seguramente hay muchas cosas que todavía restan por pulir antes que liberen la versión definitiva y más allá de algunos cambios visuales respecto a su antecesor, en esta oportunidad queremos evaluar algunos aspectos de seguridad. En particular nos centraremos en las credenciales de usuarios.

Nuestro primer paso es recurrir a las herramientas de la colección de Impacket. Para ello haremos uso de secretsdump desde un equipo conectado a la red para obtener los hashes NTLM de los usuarios locales. Hay que tener en cuenta que para realizar esta tarea se debe contar con credenciales válidas de un usuario con privilegios que tenga permisos sobre RPC en el equipo objetivo.


Obtenemos un volcado de la SAM desde un equipo en la red mediante secretsdump


Luego procedemos a realizar pruebas en local. Lo primero que haremos será desactivar el mecanismo principal de control, el Windows Defender. Las opciones para desactivarlo se mantienen sin cambios, tanto utilizando la interfaz gráfica, como comandos de PowerShell:

> Set-MpPreference -DisableRealtimeMonitoring $true

Luego procedemos a hacer uso de la herramienta mimikatz del gran gentilkiwi. Lo primero que detectamos es que podemos acceder a la SAM sin inconvenientes y de manera habitual.

Obtenemos la SAM localmente mediante mimikatz
 
La limitación aparece cuando queremos acceder a la información del proceso lsass para obtener las credenciales que están cargadas en memoria.

Intento fallido de obtener credenciales desde proceso lsass
 
Como alternativa, podemos realizar un volcado de la memoria del proceso desde el Task Manager, para eso lo iniciamos como administrador y generamos el fichero desde el menú contextual


Generando el volcado del proceso LSASS
 
 
Pero al cargar el fichero en mimikatz mediante minidump y tratar de acceder a la información, obtenemos el mismo mensaje de error.

Otro intento fallido...
 
 
Podríamos pensar que se encuentra activada la protección sobre lsass, por lo que procedemos a cargar el driver de mimikatz para desactivar esta característica. Si bien el driver se carga sin problema y se elude la protección, no logramos acceder a la información y obtenemos el mismo error. 

Intento luego de desbloquear protección con driver

Como dato extra, podemos ver que en el registro no se encuentra la clave RunAsPPL que establece que deben protegerse las credenciales cargadas en memoria.

Registro: HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Probablemente se trata de problemas en el parseo, debido a cambios relativos a la nueva versión, esto ha ocurrido anteriormente al liberarse nuevas versiones del sistema operativo que obligan a adaptar la herramienta, podemos ver que en esta issue se menciona el problema.
 
Algo similar ocurre para los casos de lsassy y crackmapexec, ambos ejecutados desde una máquina remota conectada a la red.

Mensaje de error de signature tanto para lsassy como para CrackMapExec

En conclusión, podemos intuir que los métodos de gestión de credenciales no han sufrido cambios desde la anterior versión de Windows, tanto para los hashes en la SAM, como los que se mantienen en memoria en el proceso lsass.exe. Por el momento, no podemos hacer uso de mimikatz y otras herramientas para acceder a algunas credenciales, pero confiamos en los investigadores y desarrolladores para que puedan hacer los ajustes necesarios para que funcionen en esta nueva versión, tal como ha ocurrido con los distintos builds en ocasiones anteriores.
 
Saludos!!




Leer más
      editar

8 jun 2021

El 11 de junio celebraremos el Webinar gratuito: "Ciberseguridad en los eSports"

Por el 8 jun 2021 con 0 comentarios


El próximo 11 de junio a las 19:00h (España), tendremos el placer de organizar junto a la Federación Española de Jugadores de Videojuegos y eSports y el Consejo de la Juventud de España un webinar centrado en la ciberseguridad en los eSports. Será una mesa redonda de debate, en la que participaré junto a mi compañero Jesús Alcalde para responder las dudas de ciberseguridad del resto de miembros de la mesa, de forma abierta y cercana. Así mismo, cualquier internauta podrá preguntar a los miembros de la mesa sus dudas en la materia, y trataremos de resolverlas en directo, por lo que, ¡no os lo podéis perder! Nos encantaría que fuese un webinar dinámico, donde todos podáis participar, y por ello, FEJUVES ha puesto a vuestra disposición un formulario para que, durante esta semana, podáis enviar todas vuestras dudas y consultas sobre ciberseguridad en los eSports, para que puedan ser resueltas durante el webinar:

https://www.fejuves.es/el-11-de-junio-celebraremos-el-webinar-gratuito-ciberseguridad-en-los-esports/

Sin duda, las estafas en las compras de skins y demás contenidos digitales, los robos de cuentas de redes sociales o los ciberataques a servidores y demás dispositivos, ocuparán gran parte de las cuestiones, pero no dudéis en plantear cualquier inquietud sobre seguridad en el mundo de los videojuegos, los eSports o la generación de contenidos, y trataremos de darles respuesta con el mejor de los criterios posibles.

Finalmente, nos gustaría contaros que tendremos numerosas sorpresas en la mesa, con varias  incorporaciones muy interesantes e influyentes del sector, que iremos desvelando a lo largo de esta semana. 

¡Estad muy atentos a nuestras redes sociales!


Leer más
      editar

2 jun 2021

¿Cómo proteger tu cuenta de Twitter? MyPublicInbox colabora con ESET en la creación de un asistente

Por el 2 jun 2021 con 0 comentarios

La configuración de la privacidad y de la seguridad en una red social puede ser, en algunos casos, un dolor de muelas para un usuario. Cada vez las redes sociales ofrecen mayores funcionalidades, así como mayores posibilidades tecnológicas. Debido a esto, es importante conocer las posibilidades de privacidad y seguridad que tienen éstas. Si nos centramos en Twitter podemos encontrar un gran número de opciones que permiten que podamos ser "encontrables" por nuestro email o teléfono, que podamos proporcionar nuestra localización, que podamos ser suplantables por no tener la verificación de la cuenta, disponer de un segundo factor de autenticación en la cuenta y un largo etcétera de situaciones y cosas.

En MyPublicInbox han creado un nuevo servicio, en colaboración con ESET, para que todos los usuarios de la plataforma puedan utilizarlo. Ya seas un perfil público o un contactado puedes acceder al servicio. La opción se encuentra en la parte superior derecha del sitio web, en la zona de tu perfil, y encontrarás la frase "Securiza tu Twitter". El wizzard para securizar Twitter tiene un coste de 100 tempos. El servicio dura un mes y se puede ejecutar las veces que se quiera. 

¿Cómo funciona?

Cuando se quiere utilizar el servicio se pide que se autorice a una app de MyPublicInbox. Esta app revisará diferentes aspectos relacionados con la privacidad y seguridad del usuario. Cuando pasan unos segundos y se verifican ciertas acciones, el resultado proporciona el nivel de seguridad de tu cuenta, en función de lo que el wizzard haya podido comprobar. 


El resultado tiene un aspecto informativo que ayuda a entender los riesgos que podemos tener en nuestra cuenta de Twitter. Lo interesante es que, además, el wizzard proporciona consejos, aparte de indicarnos que cosas deberíamos mejorar. En resumen, un sencillo wizzard que revisa las opciones de seguridad y privacidad y que permite a los usuarios entender las cosas que pueden mejorar para fortificar su cuenta, en este caso en Twitter. Seguramente, con el paso del tiempo, se encontrará en más redes sociales. Buena idea de la gente de MyPublicInbox.
Leer más
      editar

1 jun 2021

WLMS.exe: el amante de los reinicios

Por el 1 jun 2021 con 0 comentarios

 ¡Muy buenas a todos!

Hoy os venimos a hablar de WLMS, mejor conocido como Windows License Monitoring Service, el servicio de Windows que permite gestionar las licencias de evaluación de las ISOs proporcionadas por Microsoft en su repositorio oficial.

Fig 1: Si tienes este registro... te han tongado con tu Windows.

¿Cómo funciona WLMS?

WLMS es un servicio presente en los sistemas Windows de evaluación encargado de gestionar la validez de las licencias de prueba. Este servicio es el encargado de controlar que dicha licencia expire dentro de los plazos establecidos y, en caso de hacerlo, realiza determinadas acciones, como añadir un cartelito indicando que la licencia ha expirado o programar un reinicio del sistema automáticamente cada hora.

Fig 2: Si solo notificara esto, hasta sería gracioso.

Ahora bien, la limitación de funcionalidades o la aparición de carteles informativos no suelen ser problemas para este tipo de máquinas virtuales, ya que, normalmente, el principal uso de estos entornos suele ser la realización de tests y despliegues de prueba. Sin embargo, la aparición de un reinicio forzado cada hora... ¿es necesario?

Fig 3: ¿Licencia inactiva? Pues te reinicio.

¿Cómo evitamos los reinicios?

Aunque en la documentación de Microsoft WLMS no exista (o, al menos, nosotros no hemos sido capaces de localizarlo), existen varios artículos donde comentan cómo funciona y posibles maneras de parar su funcionamiento. Obviamente, la manera más sencilla es la más óptima: deshabilitar el servicio.

Para ello, tenemos que tener en consideración los siguientes puntos:

  • El servicio WLMS se ejecuta con integridad de SYSTEM, por lo que necesitaremos dicha integridad para modificar los permisos y las características del mismo.
  • El servicio está definido de tal manera que, cuando exista un fallo en su ejecución, el equipo se reiniciará automáticamente. 
  • Aunque el servicio se desactive, es probable que el equipo se reinicie solo una última vez. A partir de ese reinicio, no debería volver a reiniciarse solo.
Fig 4: El servicio "intocable".

¿Cómo cambiamos las características de este servicio?

Como hemos comentado, necesitamos integridad de SYSTEM para poder modificar las propiedades del servicio. Para conseguir dicha integridad, tenemos varios mecanismos (como se detalla en este post). Nosotros, optaremos por la versión cómoda: Process Hacker. 

Fig 5: Process Hacker + Run as: Cmd as System.

Mediante Process Hacker, podremos obtener una consola con integridad de SYSTEM y, desde ella, podremos abrir el proceso services.msc para modificar los permisos de WLMS.

Fig 6: Abrimos services.msc como System.

Una vez tengamos el servicio de WLMS abierto, podremos modificar sus propiedades: deshabilitar el servicio y, por si acaso, quitar las acciones en caso de fallo del servicio.

Fig 7: Configuración final del servicio tras su modificación.

Si todo ha ido bien, tras reiniciar nuestra máquina (o esperar a que se reinicie sola), nuestro equipo de pruebas no volverá a reiniciarse solo nunca más, aunque la licencia haya expirado.

Fig 8: Más de 1 hora encendida y sin licencia...

Para terminar, si por un casual tenéis un laboratorio de pruebas con un Directorio Activo desplegado y todas vuestras máquinas son de evaluación, podéis desplegar una GPO que deshabilite dicho servicio en todo el parque, facilitando el proceso y evitando el uso de programas externos como Process Hacker o PsExec.

Fig 9: GPO para deshabilitar el servicio.

Nota: con la GPO solo se deshabilita el servicio, no se cambian las propiedades del mismo en caso de fallo... aunque si el servicio no se ejecuta, no debería haber fallos de ejecución, ¿no?

Fig 10: Aunque yo lo cambiaría de todas formas...

Happy Juanking!

Leer más
      editar

27 may 2021

ISA y la Ciberseguridad

Por el 27 may 2021 con 0 comentarios

ISA (la Sociedad Internacional de Automatización, www.isa.org) es una asociación profesional sin ánimo de lucro, que se dedica a establecer estándares internacionales para aquellos que utilizan la ingeniería y la tecnología, para tratar de mejorar la gestión, la seguridad y la ciberseguridad de los sistemas de automatización y control, utilizados en la industria y las infraestructuras críticas.  Fue fundada en 1945, y desde entonces ofrece educación y formación; publica libros y artículos técnicos; organiza conferencias y exposiciones; ofrece programas de creación de redes y desarrollo profesional para sus 40.000 miembros y 400.000 clientes de todo el mundo y ahora, ha creado un nuevo HUB para ciberseguridad, la ISA Global Cybersecurity Alliance.

https://isaautomation.isa.org/cybersecurity-alliance/



Esta organización nace con la idea de unificar el conocimiento, para evitar que cada uno haga la guerra por su lado, y dejemos de trabajar de manera aislada en la resolución de los problemas. Todos sabemos que es importante que los expertos del sector trabajemos con nuestros clientes para hacerlos mejorar, pero esto no siempre es suficiente, ni para ellos, ni para la sociedad. Al fin y al cabo, la  idea que persigue esta asociación es que pasemos lo antes posible a trabajar todos juntos (asociaciones, clientes, profesionales independientes y empresas) de una manera abierta y colaborativa, para que podamos llegar a dar una respuesta unificada a todos los retos que están por venir en el sector. Y es que, en definitiva, el propósito de la ISAGCA es ayudar a las empresas y a la comunidad industrial a adelantarse a las amenazas, buscando fomentar un entorno sostenible, seguro y resistente para que todos los segmentos de la industria prosperen y crezcan. Y, desde mi punto de vista, esto es clave, ya que como sociedad dependemos de nuestro tejido industrial. 

Por lo que parece, se lo están tomando en serio, porque uno de sus primeros documentos es el interesante "The top 7 operational technology patch management best practices" del que os hablaremos en un próximo post. 

Un saludo.


Leer más
      editar

25 may 2021

La niña que quería ser hacker y la importancia de la lectura

Por el 25 may 2021 con 0 comentarios

Si revisamos la historia de la informática podemos observar cómo el papel de la mujer ha sido fundamental en muchos aspectos. Sin duda, si pensamos en la mujer en la historia de la informática aparecen nombres como Grace Hooper, Ada Lovelace o Katherine Johnson. Grace Hooper fue la primera programadora que utilizó el Mark I, Ada Lovelace se la reconoce por varias cosas, pero en particular por la aparición del primer algoritmo y Katherine Johnson tuvo gran importancia en los vuelos de la NASA gracias a sus cálculos. 

No hay duda del papel importante de la mujer en la ciencia y en la informática, hoy queremos hablaros de otras personas, más cercanas a nosotros que han logrado romper barreras y desempeñar un papel importante en su campo. Leyendo el cuento sobre Soledad Antelada, uno se da cuenta de que no es un cuento de que es la vida real. Un ejemplo para muchas otras niñas que quieren ser hacker. 

En este cuento, real como la vida misma, hay factores importantes como es la lectura. La lectura nos atrapa en un mundo real o ficticio que nos abre la mente para ver que podemos llegar dónde nosotros nos propongamos. La lectura nos da las armas para volar, imaginar, soñar, construir, pensar por nosotros mismos, nos da todo lo necesario para cruzar los límites, para realizar las acciones que construyan la base de lo que realmente queremos. Por ello, la lectura es importante desde pequeño. 

¿En qué consiste este cuento (historia real)? Una niña nacida en Argentina, que crece en España y un día decide dar el salto en busca de su sueño. Viajar a San Francisco (o volver a cruzar el atlántico) con el objetivo de aprender y convertirse en una mujer hacker. Luchando por su sueño, aunque la gente pensase que su sueño era una locura. Rompió las barreras y los pensamientos de muchos. Persiguió y logró su sueño.

Del cuento de Soledad, me quedo con la frase:

 " —Nunca dejes que nadie te quite un sueño porque ellos no se atreverían a intentarlo."

El sitio 'No Me Cuentes Cuentos' es un proyecto de relatos infantiles protagonizados por 100 mujeres españolas, cuyas vidas han sido inspiradoras para otras muchas. Si entráis a ver el sitio, fijaros que los hay en formato Podcast. 

No hace mucho hablaba en una reunión con Beatriz Cerrolaza, CEO de MyPublicInbox, y con algunas personas más. La reflexión de Beatriz sobre por qué ella quiso dedicarse a la tecnología y cómo el disponer de referencias femeninas ayuda, sin duda, a potenciar y normalizar, lo que nosotros vemos normal, acertada reflexión. Por supuesto, disponer de lectura para ayudar a todos esos niños y niñas que quieren ser hackers, también lo hace. El papel de libros como Mara Turing y sus aventuras firmadas por Javier Padilla acercan el mundo de la tecnología a todas las edades. 


A continuación, os dejamos un par de minutos con Javi Padilla, creador del universo Mara Turing, donde cuenta como es la vida del programador o no programador, así como es el universo de Mara y su futuro. Además, después del premio logrado por el primer libro del universo Mara Turing, vemos que pueden llegar su versión cómic y su versión en inglés. Sin duda, un relato interesante para que, tanto niñas como niños, quieran adentrarse en el fascinante mundo de la tecnología y, ¿Por qué no? En el fascinante mundo del hacking. 


¿Cómo empezar en Ciberseguridad? Lo primero y más importante es detectar qué es lo que te gusta. Cuando uno es niño o niña puede querer muchas cosas, no saber bien qué es lo que te gusta, por eso es bueno leer, introducirse en los mundos reales y de fantasía que nos hagan saber qué queremos. 

Hace unos años tuve la suerte de poder contar mi experiencia en una charla motivacional en el Cybercamp de Málaga en 2018. No sabía bien cómo afrontar la charla, por lo que simplemente conté mi experiencia y mi punto de vista de lo que había vivido. Si tienes 12, 14 o 16, seas niña o niño, haz lo que siempre quieras hacer, que nada rompa tu sueño y si te sirve esta charla me harás el más feliz del mundo. Solo demuestra tu pasión. 


Si quieres saber más sobre mujeres hacker en el mundo, os dejamos por aquí una serie de artículos interesantes y que seguro te harán ver otras referentes. Recuerda que los referentes andan por todos lados, que cualquiera puede inspirarte, cualquiera puede sumar, pero si alguien intenta restar déjalo fuera. 

Por último, quería hablar de otro proyecto inspirador en el que tuve la suerte de poder impartir una charla. El proyecto Radia. Radia tiene abierto el plazo para la segunda edición de becas. No lo dudes. Radia es una programa de formación en tecnologías digitales que pretende mejorar la empleabilidad en un mercado laboral que demanda profesionales con competencias digitales y equipos profesionales diversos. El objetivo es favorecer la inclusión de mujeres con discapacidad en entornos de trabajo digital y aumentar así el número de mujeres profesionales en los ámbitos tecnológicos. Aquí las lecturas también son importantes, ya que aparte de utilizar charlas como vehículo de intrusión en un campo como la ciberseguridad, la inteligencia artificial o el desarrollo de aplicaciones, se disponen de recursos tecnológicos innovadores para atraer a las mujeres gracias a la lectura. 
Leer más
      editar

24 may 2021

InfiniDrive: Almacenamiento ilimitado y gratuito con Amazon Prime

Por el 24 may 2021 con 0 comentarios

Todo empezó cuando vi que con una suscripción a Amazon Prime tenemos disponibles 5GB de almacenamiento Amazon Drive e ilimitado para imágenes. A primera vista, el servicio de Amazon no ofrece demasiado espacio en su nube, comparado con sus competidores directos. 

Fuente: ADSLZone.net

Tal como puede verse en la imagen, el espacio que nos ofrece Amazon con su suscripción no es nada del otro mundo, pero hay una gran diferencia, sobre todo a nivel de almacenamiento de imágenes. En Google Photos tenemos, hasta Junio de 2021 almacenamiento ilimitado de imágenes, pero implementa compresión con pérdida.

Google Photos comprime las imágenes que subimos. Tiene también soporte de subida y visualización para el formato de imágenes HEIF, introducido por primera vez por Apple en iOS 11. Aunque no podemos asegurar que sea este el formato que utiliza el servicio de forma nativa, probablemente haga uso de él para el almacenamiento de imágenes. De hecho, aunque corregido a día de hoy, hace algún tiempo podían subirse imágenes desde un dispositivo iOS, que por defecto utiliza HEIC en sus capturas y sobre el que Google Photos no aplicaba ningún tipo de compresión, por lo que es lógico pensar que no lo hacían porque era el formato que ellos ya consideraban comprimido en su propio servicio.
"No tengo pruebas, pero tampoco dudas."
HEIC: Un archivo HEIC es una imagen rasterizada guardada en  HEIF, un formato de contenedor de medios con compresión con pérdida que se usa comúnmente para almacenar imágenes. Puede contener una sola imagen, una colección de imágenes, ráfagas o secuencias de imágenes, junto a metadatos que describen cada imagen. De hecho, los fondos dinámicos de macOS, funcionan gracias a este interesante formato de contenedores. Podéis obtener más información sobre ello en el GitHub de Marcin Czachurski.

En cambio, Amazon Drive, no aplica ningún tipo de compresión a las imágenes que subimos, de hecho, incluso mantiene el nombre original del fichero y sus metadatos EXIF. Esto hizo que se me encendiese la bombilla de ideas, y me hice la pregunta que siempre me lleva a acabar realizando una PoC.
¿Y si pudiera convertirse cualquier archivo en una imagen?
Os presento a Infinidrive: https://github.com/nicomda/InfiniDrive

El origen

Una de las técnicas de esteganografía en imágenes más utilizadas es LSB (Less Significant Bit). Podemos ocultar información en el último, o incluso últimos bit de color de cada pixel de una imagen.


En la imagen de arriba, podéis ver el funcionamiento básico de la técnica LSB, pero para la funcionalidad que quería implementar, era impensable desperdiciar los 7 bits restantes de cada uno de los bytes de color de la imagen, ya que se necesitarían muchas más imágenes para guardar la misma cantidad de información. Así que, comencé a investigar sobre librerías de imágenes en Python que me permitiesen generar imágenes a partir de un array de bytes, de esta forma, solventamos dos de los problemas que se nos presentan.
  • No necesitamos una imagen inicial en la que codificar datos. Son los propios datos los que generan la imagen al completo.
  • Podemos utilizar la totalidad de los bits de color, para almacenar datos.
Una vez  que descubrí que Pillow permitía generar imágenes a partir de bytes, solo necesitaba leer cualquier tipo de fichero en "RAW binary" para poder convertirlo en imágenes PNG. Elegí este formato ya que es un formato de imagen que utiliza un algoritmo de compresión sin pérdida llamado Deflate, que es una combinación entre LZ77 y codificación Huffman, así ahorramos algo más de espacio. Sin embargo, quedaban algunas cosas que resolver.

El particionado
«Comience pequeño, piense en grande. No te preocupes por muchas cosas a la vez. Para empezar, tome un puñado de cosas simples y luego progrese a otras más complejas. Piensa no solo en el mañana, sino en el futuro. Pon un toque en el universo». Steve Jobs
Aunque inicialmente podríamos haber decidido generar una única imagen, es una idea horrible. No habría problema para archivos pequeños, pero como estaba intentando conseguir almacenamiento ilimitado sería bastante extraño subir una imagen que ocupe 5GB. Por ello, decidí establecer un tamaño máximo de imagen configurable. El número de bytes que caben en una imagen RGB de un tamaño determinado podemos calcularlo fácilmente.
tamaño_imagen_en_bytes = px_altura * px_anchura * 3_bytes_de_color

En una imagen de 2000x2000 píxeles RGB, caben 12.000.000 bytes. Es decir, 12MB. Usaremos este ejemplo para explicarlo de forma más sencilla, aunque como ya he dicho, el tamaño de la imagen que se genera es modificable.

De esta forma durante la codificación se leen bytes del archivo hasta llegar al tamaño máximo establecido. En ese momento, se llama a una función que genera una imagen a partir del array de bytes y la guarda en un directorio, con un nombre correlativo, para facilitar la tarea posterior de restauración del archivo original a partir de las imágenes creadas. Esta tarea se ejecuta en bucle hasta que se llega al final del archivo. 

Metadatos y relleno

Hay que tener algo más en cuenta, y es que probablemente, en la última imagen quedará espacio sin utilizar, pues sería prácticamente imposible que el archivo que queremos codificar, ocupe en bytes exactamente un múltiplo de 12MB. Así que debe establecerse algún tipo de padding que podamos eliminar de forma posterior para poder generar la imagen completa. Por lo que, se han utilizado bytes "\x00" para rellenar el resto de la imagen hasta estar completa.
Además, durante el proceso se me ocurrió la posibilidad de utilizar metadatos para almacenar dos cosas.
  • El nombre y la extensión original del archivo a partir del cual se generaron las imágenes
  • El tamaño original del archivo previo a ser partido. (A continuación entenderéis el porqué de esto)
La recomposición

Cuando subimos la carpeta con todas las imágenes que conforman nuestro archivo codificado, el propio Amazon Photos nos avisa con un pop-up de si queremos crear un álbum para esas fotos. Agradezco al equipo de desarrollo del servicio haber implementado esta funcionalidad, ya que nos facilita bastante el proceso de descarga, pues así podemos descargar un ZIP con nuestro archivo codificado al completo.

Con el archivo de nuevo en nuestro equipo, llamamos al programa con la opción de "merge" y especificamos la carpeta. En ese momento, comienza el proceso de recomposición de las imágenes, extrayendo la información en RAW del RGB. Primero se extraen los metadatos para conocer el nombre del archivo. Y a partir de ese momento, el software extrae los bytes imagen a imagen hasta que llega a la última, donde como ya explicamos, existe un padding.

De ahí el segundo parámetro que extraemos desde los metadatos. Es obvio, que el archivo final ha de tener exactamente los mismos bytes que el original, sobre todo si queremos que la aplicación sea funcional para todo tipo de ficheros, incluyendo binarios y ejecutables. Así que, si con la fórmula de arriba sabemos cuantos bytes de información existen en las imágenes, podemos asumir lo siguiente.
bytes_última_imagen_hasta_padding = (num_imágenes * tamaño_imagen_en_bytes) - tamaño_archivo_original 

Esto nos da la información que necesitamos para saber cuantos bytes existen en la última imagen previos al comienzo del relleno con "\x00".

Una vez que el archivo se restaura, podemos utilizar cualquier utilidad para calcular el checksum, en este caso usamos sha256sum para comprobar la integridad del archivo tras el proceso.


Cuando conseguí que la aplicación funcionase, me surgieron bastantes preguntas relativas a ciberseguridad. Es posible subir cualquier tipo de archivo, pero para no violar los términos de uso, simplemente hicimos comprobaciones con un Eicar para ver que, una vez codificado en imagen, ni software antivirus habituales, ni aparentemente Amazon, son capaces de detectar un potencial malware.

Con esta pequeña aplicación, al final, estamos subiendo "imágenes" a Amazon Photos, y como tal, el espacio es ilimitado. También es posible crear links públicos para compartir nuestros archivos a cualquier persona.


Espero que os sirva de utilidad, y recordad, cuando creéis cosas, nunca olvidéis vuestro "Y si...?".

@Nicomda
Leer más
      editar

21 may 2021

TOP 15 de Amenzas de ENISA - DDoS

Por el 21 may 2021 con 0 comentarios

Bienvenidos a un nuevo artículo más de la serie de amenazas de ENISA, en este caso, dedicado a las Denegaciones de Servicio Distribuidas.


 

Ya sabemos todos que una Denegación de Servicio es cualquier escenario en el que un atacante es capaz de atacar la disponibilidad de un activo o servicio, consiguiendo desde degradar el acceso hasta inutilizarlo por completo. Aunque normalmente pensamos en los ataques que desbordan la red de la víctima, también son conocidas otras variantes como:

  1. Aquellos que están dirigidos a saturar las capacidades de cómputo del sistema, mediante la invocación continuada de funciones que hagan uso intensivo de la CPU, de memoria o del espacio en disco.
  2. Los que directamente explotan unaa vulnerabilidad software que provoca el bloqueo o cierre del proceso, por ejemplo, mediante algún tipo de desbordamiento.

Cuando hablamos de ataques de Denegación de Servicio Distribuido, normalmente hacemos referencia a ataques volumétricos, en los que se utilizan grandes cantidades de nodos de Internet para lanzar cantidades masivas de información contra la víctima. Esto se puede conseguir tanto de forma directa, como mediante ataques de reflexión, o incluso apoyándose en técnicas de amplificación, en las que el atacante es capaz de provocar el envío de enormes cantidades de información sobre un activo a través de peticiones más pequeñas específicamente dirigidas contra otros activos. En este sentido, investigadores de akamai llegaron a investigar incidentes en los que se logró amplificar hasta un 15.000% el envío original de datos.

Como ya se lleva tiempo avisando, y pudimos comprobar con los ataques relacionados con Mirai, las vulnerabilidades en dispositivos conectados IoT, han permitido crear enormes botnets que se utilizan, entre otras cosas, para lanzar este tipo de ataques. En este sentido, se menciona a China, Brasil e Irán como los países con la mayor cantidad de dispositivos infectados. En el estudio también se menciona como la gran mayoría de ataques están basados en SYN-Flood, aunque además, casi siempre se usan más de dos vectores de ataque para garantizar el éxito. Curiosamente la mayoría de estos incidentes no duran más de 10 minutos, aunque el ataque de mayor duración en la fecha del estudio duró más de 20 días.

Un caso bastante curioso fue el de un ataque que fue capaz de tumbar un ISP de Sudáfrica mediante la técnica del “Carpet Bombing”. En este ataque se consiguió degradar el servicio usando ataques de amplificación aprovechándose de servidores DNS y CLDAP que no estaban parcheados, redirigiendo el tráfico de forma masiva a IPs de los clientes del proveedor. Normalmente los routers edge del ISP suelen estar bien protegidos contra ataques de DDoS, por lo que en ataques directos habrían descartado todo el tráfico basura. En su lugar se lanza tráfico de forma masiva a muchos clientes en las diferentes redes del ISP, y aunque este tráfico no es suficiente por si sólo para afectar las conexiones individuales de los clientes, al final este genera más tráfico reflejado a lo largo de toda la red, y en conjunto, antes o después la red del ISP se ve saturada. Al no ser un ataque directo contra los routers edge, las medidas de seguridad para prevenir el DDoS no entran en juego, y básicamente son inundados. El resultado para los clientes del ISP es, a efectos prácticos, fue acabar desconectado de Internet.

Por curiosidad, el ataque más grande hasta la fecha, del que se defendió con éxito Amazon, fue un ataque que llegó a los 2.3Tbps. Si queréis más información de este y otros importantes ataques, podéis leer este artículo sobre los mayores DDoS de la historia.

¿Y qué podemos hacer, según ENISA, para protegernos de este tipo de ataques?

  • Por un lado, tener claro qué servicios y recursos son críticos para priorizar las medidas defensivas en aquellos puntos que puedan ser saturados, y tener diseñado un plan de respuesta para estos escenarios.
  • Existen multitud de servicios de protección contra DDoS que pueden ser evaluados según necesidad. 
  • La publicación de servicios a través de CDNs puede ser útil para absorver los intentos de ataque volumétricos.
  • Obviamente, los proveedores de acceso a Internet y proveedores Cloud, por su posición en la red, tienen un gran capacidad a la hora de proteger de DDoS. Tener un canal de comunicación rápido y directo con ellos puede ser de gran utilidad.
  • Tener una buena postura de seguridad, realizando revisiones periódicas, asegurando de que configuramos de forma óptima cada sistema y servicio, y utilizando técnicas como el uso de servidores de caché, descartar tráfico no legítimo, etc.
  • Analizar nuestro propio entorno desde dentro hasta fuera, desde los activos críticos en el interior de la red, hasta la presencia y exposición en Internet, con el objetivo de detectar puntos de fallo, posibles riesgos y amenazas, etc.

Como siempre, recordad que en numerosas ocasiones este tipo de ataques se utilizan para desviar los ojos del equipo defensor, y así poder atacar, esta vez de forma bastante más sútil, en otro punto de la red ;)

¡Nos vemos en la próxima, saludos!

Leer más
      editar

19 may 2021

Obteniendo información de direcciones de email durante un #OSINT

Por el 19 may 2021 con 0 comentarios

Meowy buenas!

Aunque somos conscientes de la gran cantidad de repositorios que centralizan diferentes tipos de herramientas (como OSINT Framework, Archive.org, osint.link, OSINT Techniques, o Ciberpatrulla, entre otros, además de un sinfín más en Github), que nos hacen la vida más fácil a la hora de echar mano de herramientas según la información que queramos obtener, con el tiempo tendemos a crearnos nuestro propio listado de las herramientas que nos dan mejores resultados.

En estas herramientas, para las investigaciones a través de OSINT, una de las fuentes más ¿jugosas? son las direcciones de email y lo que éstas nos pueden aportar sobre un usuario, y por ello en este post vamos a comentar varias plataformas y proyectos que pueden ayudarnos a conseguirla (ya sea de nuestro target, de nosotros mismos para conocer cómo de expuestos nos encontramos, o incluso para concienciar a personas que despreocupan su privacidad porque que no tienen "nada que esconder" o no son "nadie importante").

 
[Un usuario al ver públicas sus fotos del verano pasado en la playa]

Disclaimer: Para mostrar el funcionamiento y el resultado del uso de las siguientes herramientas, y a la vez no mostrar información sensible con las evidencias de uso de las herramientas, los datos personales han sido sanitizados.

https://tools.epieos.com/holehe.php

En primer lugar, esta plataforma te indica no sólo si un email se encuentra activo, sino que lista un conjunto de servicios que tiene asociados a esa cuenta de email.


 

https://tools.epieos.com/google-account.php

Es especialmente útil de cara a los comentarios y las publicaciones realizadas a través de una cuenta de email. En este resultado nos muestra la foto de perfil, ID de la cuenta de google, y la última actividad del usuario en la cuenta, pero lo más interesante son los enlaces que proporciona a continuación de Maps y Photos.

El enlace de Maps hace referencia a la actividad pública que ha registrado el usuario (en cuanto a contenido multimedia, lugares y comentarios publicados). En cuanto a las fotos de google, muestra los álbumes de fotos públicos del usuario, pero esta funcionalidad da algún que otro error 403 y 404, también según la configuración de privacidad del usuario


 

https://www.emailsherlock.com/

En el caso de esta web, comprueba el email introducido con diferentes redes sociales y, en el caso de encontrar coincidencias, muestra la información del usuario asociado.

 


https://github.com/alpkeskin/mosint

Entre los resultados que muestra esta herramienta (comprobación con leaks, posibles teléfonos asociados, dumps en pastebin, ...), la parte más interesante es que contrasta con diferentes plataformas si el email introducido se encuentra en uso en diferentes redes sociales y plataformas, indicando si se ha podido verificar dicha comprobación, y si el email se encuentra registrado (avaliable) en dicho servicio, es decir, nos dice si el email se encuentra registrado (como en el caso de la imagen, hace referencia a Spotify).



Espero que os haya gustado y/o resultado útil esta pequeña introducción a estas herramientas :)

Y a modo de reflexión. ¿Cuál es tu herramienta favorita para obtener información de un email?

Muchos maullidos!

M

Leer más
      editar

17 may 2021

Consejos de ciberseguridad en el desarrollo de software

Por el 17 may 2021 con 0 comentarios

Buenas a todos! Hoy os traigo una serie de consejos a seguir sobre seguridad aplicada al desarrollo de software.




1. Mantener el software y las dependencias actualizadas

Una gran parte de las páginas web son vulnerables a través de exploits, publicados (o no) a través de CVE (Common Vulnerabilities and Exposures).


Ilustración: Y mira que npm nos avisa..

Podéis consultar si vuestro software y versión tienen algún tipo de CVE publicado a través de este enlace.

Existen multitud de páginas web donde consultar exploits de todo tipo de software y las cuales, son realmente útiles para posibles atacantes.

Breve inciso: Utilizad las menores dependencias posibles.

2. Forzar el acceso al website a través de HTTPS

Como muchos sabréis, HTTPS realiza un cifrado en dos direcciones para las comunicaciones entre el servidor y los clientes enviando los datos a través de SSL/TLS.


Pero.. ¿Esto qué significa?

Básicamente, que es más seguro, puesto que los datos que viajan hacia y desde la web van cifrados. Tenemos varias publicaciones creadas por @mikiminoru sobre las suites de TLS/SSL donde explica de forma extensa la importancia de una configuración correcta, como comprobar las vulnerabilidades y las recomendaciones para cada caso.



Pero.. ¿Esto quiere decir que un sitio web al que accedemos a través de HTTPS es seguro?

Para nada, es un error bastante común pensar que una web que utiliza HTTPS es segura y NO ES ASÍ puesto que la comunicación está cifrada, pero no sabemos si la web en sí está realizando un uso fraudulento de tus datos.
Además, en caso de ser una web fiable, pueden estar cometiendo errores de configuración.


Vale, entonces, si es seguro.. ¿No tendría que hacer nada más?

Por supuesto que sí, es solo una capa de protección adicional, para tener una página web segura debes seguir todos los puntos de este post y muchos más que seguiremos explicando en futuras publicaciones.


3. Injection

En este punto, trataremos de explicar en general las posibles vulnerabilidades a través de injection, en este caso hablaremos de las siguientes: SQL, NoSQL, XML, ORM queries.

Consejos principales:

  • Validación de inputs.

  • Escapar y "limpiar" todas las variables recibidas del usuario. (Escape, Sanetize)

  • Uso de procesos almacenados cuando sea posible.

  • Uso de consultas parametrizadas.

  • Hacer cumplir el Principio de mínimo privilegio.

  • WAF

SQL Injection  'or' '1' = '1

sqlQuery='SELECT * FROM custTable WHERE User='' OR 1=1-- ' AND PASS=' + password

Los ataques de inyección SQL pueden realizarse en consultas SQL poco seguras.
Podéis ver información ampliada sobre esto en el siguiente enlace: SQL Injection Prevention Cheat Sheet

NoSQL

Así es, las consultas NoSQL a pesar de ser "más seguras", no se libran de ser atacadas.
Podéis consultar diferentes formas de inyección NoSQL en este enlace, además de diferentes formas de evitarlos.

XML Parsers

Existen diferentes formas de explotar la inyección sobre XML, varias de ellas son mencionadas aquí.

ORM Queries

Efectivamente, las consultas a través de ORM  (Object-relational mapping) tampoco son completamente seguras. Sobre todo, si se hace un mal uso de ellas 😉
Podéis ver varios ejemplos genéricos en el siguiente enlace Testing for ORM Injection.


4. XSS o Cross Site Scripting

Este tipo de ataques son similares a los ataques de inyección, pero en este caso, el objetivo del atacante no es la base de datos, sino los usuarios que se conectan a la página.

A veces, con fin de conseguir información de usuario y otras, para realizar redirecciones a páginas fraudulentas.

Ejemplo: En un input escribir <script type =’text / javascript’> alert (‘Test XSS’); </ script>

Aquí está el enlace con ejemplo de su uso y como protegernos.

5. Autenticación

Según OWASP la política de contraseñas seguras debe ser la siguiente:

  • Mínimo 8 caracteres.

  • NO establecer un máximo de caracteres para las contraseñas.

  • NO partir contraseñas. (Cifrar en SHA256 y a continuación en Bcrypt)

  • Permitir el uso de todo tipo de caracteres incluidos unicode y espacios en blanco.

  • Asegurar la rotación de contraseñas cuando sean filtradas o en el momento en que se encuentre una vulnerabilidad.

  • Mostrar un "Strength-meter" o "Medidor de fuerza" para que el usuario sepa en todo momento la seguridad de su contraseña.

Además, existen errores a nivel de implementación de software que pueden ser subsanados para asegurar a los usuarios y la plataforma:

  • Implementar un mecanismo seguro de recuperación de contraseñas.


  • Comparar los hashes con funciones seguras. (EJ: password_verify() en PHP)

  • Trasmitir las contraseñas a través de un protocolo seguro. (TLS u otros)

  • Solicitar de nuevo el acceso para acciones más críticas.

  • Solicitar 2FA para acciones más críticas. Podéis ver un ejemplo aquí de fraude por la no utilización de 2FA publicado por mi compañero Daniel González.

  • Transacciones autorizadas. Hay varios métodos de implementar esto, por lo que os dejo el siguiente enlace para que veáis algunos ejemplos.

  • Control de los errores de autenticación.
    Este punto, básicamente, se trata de proporcionar errores genéricos, donde no aparezcan datos sensibles de ser explotados o utilizados para extraer datos.

    Algunos ejemplos de errores demasiado descriptivos y que deberían ser generalizados:

    • The user ID or password was incorrect.
    • The account does not exist.
    • The account is locked or disabled.
    • The account exists but password doesn’t match.
           Ejemplo de errores genéricos:
    • Invalid user or password.
    • If that email address is in our database, we will send you an email to reset your password.
    • A link to activate your account has been emailed to the address provided.

  • Protección ante ataques automatizados. (Brute force, Credentials Stuffing, Password Spraying)

    Vamos a nombrar diferentes formas de protegernos contra estos ataques:

  • Uso de protocolos de autenticación no basados en contraseñas

  • Promover el uso de software de gestión de contraseñas. EJ: KeePass

  • Monitorización

    Como sabréis, una parte muy importante de la seguridad es la monitorización, por ello, es más que indispensable la revisión de los posibles ataques, cuentas bloqueadas etc y la aplicación de políticas de seguridad basadas en los resultados.

6. Auditoria

Todos estos conceptos son aplicables por un equipo técnico cualificado y especializado en ciberseguridad y desarrollo.

A pesar de existir todos estos métodos, la única forma de tener una plataforma y entorno seguro, es realizando una auditoria completa a toda la infraestructura y aplicando los correspondientes métodos de "aseguramiento" en cada uno de los nodos afectados.

Esperamos que toda esta información os sea de gran ayuda en vuestros proyectos y tengamos, en un futuro, sitios más seguros. Y recordad, si precisáis de una compañía externa que revise la seguridad de vuestras aplicaciones, no dejéis de contactarnos en nuestro correo info@zerolynx.com. Mis compañeros del laboratorio cyber estarán encantados de atenderos.

Saludos!


Leer más
      editar
>