2019/10/18

Generación de claves RSA y selección de los números primos. Parte 2

Por el 2019/10/18 con 0 comentarios

La idea general empleada por las implementaciones reales se basa en que verificar si un número es primo con una muy alta probabilidad es mucho más rápido que factorizar dicho número, y dado que la existencia de números primos no es infrecuente cuando los números son grandes, es decir, es fácil encontrar números primos incrementando el número candidato y probando de nuevo, los tests de primalidad son muy eficientes (sin entrar en los detalles de cómo funcionan estos tests internamente, por ejemplo, verificando si un número es compuesto mediante el teorema de Fermat12, junto a otras comprobaciones adicionales). A modo de referencia, y sin entrar en sus detalles, existen otros tests de primalidad adicionalmente al de Miller–Rabin, como Lucas (mencionado posteriormente en FIPS 186-4), Baillie-PSW, o Solovay-Strassen.

Adicionalmente, otras implementaciones basadas en el estándar FIPS 186-4 [4] (analizado posteriormente), concretamente en el apartado B.3.1 (centrado en la generación del par de claves empleadas por RSA; requisito 2(d)), una vez generados los números p y q, comprueban que la diferencia entre ambos números primos sea mayor a m bits, siendo m igual a 2 elevado a la mitad de la longitud del módulo n ("nlen") menos 100 (|p-q|>2(nlen/2)-100), para que no se trate de números primos "muy" cercanos, lo que facilitaría factorizar el módulo n13 [13]. Por otro lado, los números primos p y q empleados no pueden ser iguales, ya que si p=q sería trivial factorizar n calculando la raíz cuadrada de n (n=p*q=p2=q2), lo que permitiría conocer p y q, y por tanto poder calcular Φ(n) = (p-1)(q-1), y como resultado obtener la clave privada d = inv(e,Φ(n)).

La documentación oficial de la certificación CriptoCert Certified Crypto Analyst (https://www.criptocert.com/#cert-analyst) profundiza en otros aspectos del algoritmo RSA, incluyendo la existencia de Claves Privadas Parejas (CPP) y Claves Públicas Parejas y sus cálculos asociados, los números o mensajes no cifrables, el Teorema Chino del Resto (TCR), etc. En relación con las preguntas que nos ocupan, es interesante conocer que si ambos números primos p y q son seguros, sólo existirá una Clave Privada Pareja (el valor mínimo posible y más recomendable desde un punto de vista criptográfico).

Un breve artículo introductorio centrado en la elección de los números primos utilizados en la criptografía de clave pública es "Prime Numbers in Public Key Cryptography" [5], de Gerald Crow, publicado en 2003 en la SANS Reading Room, que describe ciertas propiedades asociadas a los números primos, ciertos tipos de números primos como los de Mersenne (2n-1) o el concepto de números primos relativos o coprimos1 (o números primos entre sí), y algunos teoremas relacionados, como el pequeño teorema de Fermat, que permite excluir si un número es o no primo, o el teorema de Euler.

La tesis "The properties of RSA key generation process in software libraries" de Matúš Nemec (Masaryk University - Faculty of Informatics) [1], publicada en 201614, realiza un análisis muy completo y exhaustivo de las diferentes aproximaciones y algoritmos empleados por las implementaciones de múltiples librerías criptográficas a la hora de generar las claves del algoritmo RSA (comparándolas con los requisitos definidos por estándares internacionales, como NIST FIPS 186-4, detallado posteriormente, ANSI X9.31 y X9.44, IEEE 1363-2000, RSAES-OAEP y otros), la selección de los números primos p y q asociados, y los tests de primalidad empleados para su verificación. La tesis profundiza en las peculiaridades de las distintas implementaciones analizadas, comparándolas entre sí, y en algunas optimizaciones existentes que intentan, por ejemplo, minimizar el número de invocaciones al generador de números (pseudo)aleatorios. Adicionalmente, describe trabajos previos, potenciales ataques sobre las claves RSA, algoritmos y métodos de factorización, e identifica propiedades comunes a claves débiles. Como conclusión, algunas implementaciones aumentan su eficiencia en el proceso de generación de las claves sacrificando unos pocos bits de entropía, pero sin un impacto significativo en la seguridad de las claves generadas.

En el caso de OpenSSL, la tesis indica (en el apartado 4.2) lo comentado anteriormente tras realizar un breve análisis de su código fuente, es decir, que hace uso de una búsqueda incremental basada en la división del número candidato por algunos números primos pequeños (ya que llegar hasta la raíz cuadrada del número candidato no es práctico, por la cantidad de cálculos requeridos), teniendo en cuenta que los cálculos de división se realizan tanto para p como para p/2 (para emplear primos seguros). Sin embargo, los tests de primalidad no se realizan sobre p/2, lo que parece un bug, hecho que permite identificar claves RSA generadas por OpenSSL (v1.0.2g). La tesis también detalla el uso de OpenSSL con el módulo de compatibilidad FIPS.

Dentro de los estándares internacionales de referencia más relevantes para la generación de claves RSA, con carácter público y oficial, se encuentra la publicación del NIST conocida como FIPS 186-4, "Digital Signature Standard (DSS)", de julio de 2013 [4], y asociada a la firma digital (la certificación CriptoCert Certified Crypto Analyst cubre esta temática en el módulo 9, tal como se puede consultar en su temario: https://www.criptocert.com/CriptoCert_Analyst.html). En concreto, la sección 5.1 de FIPS 186-4, y especialmente el apéndice B.3.1, detallan los requisitos formales y más restrictivos (en comparación a otras implementaciones) para la generación del par de claves RSA y de la selección de los números primos p y q, y las relaciones entre estos, en base a FIPS 186-4 (referenciadas como IFC, Integer Factorization Cryptography). En resumen, se debe hacer uso de un generador de números aleatorios, o bits, de confianza, y los números primos p y q de 1.024 bits deben ser primos provables o probables  (en inglés), o satisfacer un conjunto de condiciones (primos con condiciones), asociadas a factores primos denominados primos auxiliares, que deben cumplir también unos requisitos de longitud mínima (> 140 bits) y máxima (su sumatorio debe ser, según si son provables, <494 bits, o probables, <1.007 bits). El estándar también define los requisitos del exponente público e y del exponente privado d, y su relación respecto a los valores de p y q. La generación de números primos provables y probables, y de primos de ambos tipos con condiciones, se describe en los apéndices B.3.2, B.3.3, B.3.4, B.3.5 y B.3.6 respectivamente (en base a los requisitos de A.1 y A.2), empleando una semilla aleatoria o tests de primalidad probabilísticos (según el apéndice C.3). Los tests de primalidad probabilísticos referenciados en FIPS 184-6 son Miller-Rabin (C.3.1), una versión mejorada de éste (C.3.2), y Lucas (C.3.3), sugiriéndose la utilización de un número mínimo de iteraciones de Miller-Rabin (según la longitud en bits de p y q y la probabilidad de error que se considera aceptable), o para más certeza (por ejemplo en DSA frente a RSA), su uso combinado, aplicando un test de Lucas adicional. El motivo es que no se conocen valores de números no primos que satisfagan el número de iteraciones del test Miller-Rabin indicadas, y también satisfagan el test de Lucas. En el caso de RSA, y como referencia, el número de iteraciones del test Miller-Rabin es de 5 siendo p y q números primos de 1.024 bits (con una probabilidad de error de 2-112).

Los dos números primos p y q son habitualmente generados aleatoriamente con una longitud de 1.024 bits y posteriormente se comprueba su primalidad (tal y como se ha descrito anteriormente). Algunas implementaciones, incluyendo OpenSSL, generan un número aleatorio de 1.024 bits, asegurándose de que es un número impar (es decir, su bit menos significativo debe ser 1) y, por tanto, potencialmente primo. Adicionalmente se aseguran de que su bit más significativo también es 1 (el número comienza por 1 en binario) para estar seguros de que el número es de 1.024 bits, y no de 1.023 bits, asegurándose así también de que el módulo n será de 2.048 bits (o al menos de 2.047 bits16). Respondiendo a la pregunta {P2}, teóricamente no necesariamente ambos números p y q deben ser de 1.024 bits, para que su producto n sea de 2.048 bits, sino que uno de ellos podría ser algo más pequeño (por ejemplo, p de 1.020 bits), y el otro algo más grande (por ejemplo, q de 1.028 bits), siendo el producto n de ambos también de 2.048 bits. El conocer de antemano la longitud (1.024 bits) de ambos números primos p y q no facilita los ataques por factorización del módulo n. Lo importante es que el módulo n sea de 2.048 bits. De hecho ocurriría lo contrario, si uno de los dos números primos p o q fuera significativamente más pequeño, se facilitarían los ataques de factorización, que se centrarían en ese número más pequeño o débil. Se debe tener en cuenta que se está trabajando con números de gran tamaño y que la cantidad de números primos de 1.024 bits que existe es muy elevada. Además, por el teorema de Dirichlet, los números primos están uniformemente distribuidos en el módulo n.

Una vez elegidos los números primos p y q, es posible calcular n, junto a Φ(n), y se pueden por tanto generar las claves pública y privada, e y d, o (e,n) y (d,n). Se podría pensar que dado que los datos que se cifran con la clave pública se pueden descifrar con la clave privada, y teniendo en cuenta que ambas claves permiten realizar operaciones matemáticas inversas, una vez generadas ambas claves, se podría indistintamente seleccionar inicialmente cualquiera de ellas para que actuase como la clave pública y/o como la clave privada, siendo la otra clave su inversa. Es decir, cuando un software con soporte para RSA, como por ejemplo OpenSSL, genera las dos claves, se podría pensar que es posible elegir indistintamente una u otra como clave pública o privada, aunque en realidad no es así. Planteado de otra forma, se podría pensar que el exponente público e (de la clave pública) y el exponente privado d (de la clave privada) son de un tamaño en bits similar, tal y como ocurría con p y q.

En realidad, y respondiendo a la pregunta {P4}, se recomienda elegir un valor de clave pública e pequeño en relación con el módulo n [0], ya que esto asegura que el valor de la clave privada d será muy grande, y potencialmente más segura, al dificultarse su obtención mediante fuerza bruta. En la práctica, se toma como valor único y conocido del exponente público e el número 65.537, conocido como número 4 de Fermat o F4.

Tomando los dos números primos p y q de 1.024 bits, y el módulo n de 2.048 bits, al igual que Φ(n), y dado que d = inv (e, Φ(n)) y que e es el valor 65.537 (compuesto por 17 bits), por concepto de inversos, el valor de d será como mínimo de 2.031 bits (2.048-17 bits).

Adicionalmente, el número 4 de Fermat, empleado en e, presenta propiedades muy interesantes para las operaciones de cifrado de RSA. Debido a que el número 65.537 sólo tiene dos bits con valor 1 (y 15 bits con valor 0), 0x10001 en hexadecimal, al aplicar el algoritmo de exponenciación rápida en las operaciones de cifrado, donde e actúa de exponente, C = Me mod n, debido a que está compuesto de muchos ceros , permite agilizar las operaciones de cálculo [0], mejorando la eficiencia del proceso de cifrado de RSA. Por tanto, las operaciones de cifrado con la clave pública e en RSA son mucho más eficientes y rápidas que las operaciones de descifrado con la clave privada d.

En resumen, la clave pública basada en el exponente público e es de reducido tamaño, los 17 bits del número 4 de Fermat, mientras que la clave privada basada en el exponente privado d tiene un tamaño cercano al módulo n (2.048 bits).

Para agilizar las costosas operaciones de exponenciación con números grandes involucradas en el proceso de descifrado de RSA empleando la clave privada d se hace uso del Teorema del Resto Chino (TRC), descrito en detalle en la documentación de la certificación CriptoCert Certified Crypto Analyst. El destinatario de un mensaje cifrado, al disponer tanto de d, como de los números primos p y q, podrá realizar los cálculos de aritmética modular en los grupos de p y q, de 1.024 bits, en lugar de en el grupo del módulo n, de 2.048 bits, reduciendo el tiempo de cómputo (en unas 4 veces [0]). Como se verá posteriormente de forma práctica, OpenSSL proporciona ciertos valores adicionales a la hora de generar las claves RSA que permiten hacer uso del TRC en el proceso de descifrado

Comentarios

13 Si los números primos p y q son "muy" cercanos, sería trivial factorizar n simplemente obteniendo su raíz cuadrada y buscando números impares, por arriba y por debajo de ese valor, que fuesen primos.
14 El autor de la tesis estuvo involucrado en el descubrimiento y publicación de la vulnerabilidad ROCA [18] en el año 2017.
15 En teoría de números, los números primos provables son aquellos que se ha calculado que son primos mediante algoritmos que permiten comprobar que no son números compuestos (garantizan que son primos), mientras que los números primos probables son aquellos que han pasado tests de primalidad probabilísticos y que muy probablemente (pero no con total certeza) son primos [1].
16 Posteriormente se describirá como OpenSSL se asegura en realidad de que los dos primeros bits de los números primos p y q tienen el valor 1, por lo que el módulo n será del tamaño esperado, 2.048 bits.
17 Técnicamente se indica que F4 tiene un peso de Hamming bajo: https://en.wikipedia.org/wiki/Hamming_weight

Referencias:


Artículo cortesía de Raúl Siles (raul@criptocert.com) - CriptoCert - www.criptocert.com

Agradecimientos: Jorge Ramió (jorge@criptocert.com) y Alfonso Muñoz (alfonso@criptocert.com)


Leer más
    email this       edit

2019/10/17

Generación de claves RSA y selección de los números primos. Parte 1

Por el 2019/10/17 con 0 comentarios
Artículo cortesía de Raúl Siles (raul@criptocert.com) - CriptoCert - www.criptocert.com

Agradecimientos: Jorge Ramió (jorge@criptocert.com) y Alfonso Muñoz (alfonso@criptocert.com)

¿Cómo se generan y/o eligen los dos números primos p y q empleados en RSA a la hora de generar el par de claves, pública y privada?... y otras cuestiones interesantes asociadas a la generación de las claves en RSA ;-)

Otras preguntas relacionadas que también surgieron, y que es lógico que se plantee cualquier mente inquieta y ávida de sabiduría son, ¿al generar un par de claves RSA de 2.048 bits, la longitud de los número primos p y q es exactamente de 1.024 bits para cada uno, o puede haber ligeras variaciones en su longitud, sin que sean necesariamente números exactamente de la misma longitud? {P2}, ¿cómo se generan y/o eligen los números primos p y q empleados en RSA por parte de un software de referencia en la industria como, por ejemplo, OpenSSL? {P3} y, por último, ¿una vez generadas las dos claves, pública y privada, se podría elegir indistintamente una u otra para jugar el papel de clave pública o privada? {P4}

A continuación vamos a intentar responder a todas estas preguntas y a proporcionar referencias adicionales para quienes estén interesados en profundizar aún más en las respuestas asociadas.
De manera breve e introductoria (para más información se recomienda la lectura del libro "Cifrado de las comunicaciones digitales. De la cifra clásica al algoritmo RSA" de Jorge Ramió y Alfonso Muñoz, cuya 2ª edición ha sido publicada en 2019 [0]), el algoritmo de cifra asimétrico RSA permite tanto cifrar la información (proporcionando confidencialidad), como firmarla (proporcionando autenticidad e integridad). Centrándonos en las operaciones de cifrado, es posible cifrar un mensaje M mediante la clave pública del destinatario (n,e) empleando la siguiente operación de exponenciación en aritmética modular, así como descifrar el mensaje cifrado C mediante la clave privada del destinatario (n,d) para obtener de nuevo el mensaje M original:

Cifrado: C = Me mod nDescifrado: M = Cd mod n
Imagen del certificado digital de la web de CriptoCert (https://www.criptocert.com), con módulo de 2.048 bits, obtenido mediante Firefox en macOS.

La fortaleza de RSA reside en la dificultad computacional de factorizar un número compuesto muy grande, es decir, el módulo n, compuesto por el producto de los dos números primos p y q.

Sin profundizar en los detalles matemáticos, una vez se dispone de p y q, y por tanto de n, se calcularán el resto de valores (e y d) en base a ciertas fórmulas matemáticas como, por ejemplo, el indicador de Euler del módulo n, f(n) = (p-1)(q-1), un valor trampa secreto que permite elegir el exponente público e en el rango 2 < e < f(n), coprimo1 con f(n). Como detalle adicional, el indicador de Euler f(n) proporciona el orden, es decir, la cantidad de números enteros positivos menores o iguales a n y coprimos con n, es decir, el tamaño del "grupo de cifra" definido por el módulo n. Teóricamente, cada usuario elegirá un valor de e para su clave pública asegurándose de que existe un inverso multiplicativo2, es decir, un valor d para poder disponer de una clave privada asociada:
d = inv(e,f(n)) o d = e-1 mod f(n).
En resumen, a la hora de generar sus claves RSA, cada usuario elige dos números primos p y q y los mantiene en secreto, obtiene el módulo n=p*q, que es público, genera la clave pública e, o (n,e), y calcula el indicador de Euler f(n) que actúa como valor trampa secreto para poder calcular la clave privada asociada d, o (n,d)3. El hacer públicos los valores e y n no pone en peligro la clave privada d, ya que para calcular d es necesario conocer el valor secreto trampa f(n), es decir, los números primos p y q.

La pregunta inicial planteada {P1} centrada en cómo se eligen los números primos p y q es común y se ha repetido en foros y grupos de discusión de criptología a lo largo de los años. Conocer los detalles para elegir p y q correctamente es fundamental para cualquier desarrollador que quiera hacer uso de RSA en su software sin emplear librerías criptográficas o software de terceros, o que aun haciendo uso de éstas, quiera verificar que se hace un uso correcto de RSA. Tal como se describe en la nota 4.51 del capítulo 4 del libro "Handbook of Applied Cryptography" de A. Menezes, P. vanOorschot, y S. Vanstone, publicado en 1996 [2], y como se resume en [3], el algoritmo genérico empleado para la obtención de los números primos p y q en RSA es el siguiente:
  1. Generar un número impar p (condición necesaria para que potencialmente sea un número primo4) aleatorio de 'n' bits, siendo 'n' = 1.024 bits para las claves RSA de 2.048 bits comúnmente empleadas hoy en día. Si el número generado no es impar, se le suma 1.
  2. Comprobar si p es un número primo. Para llevar a cabo esta comprobación se pueden emplear diferentes métodos de verificación denominados tests de primalidad, descritos posteriormente.
  3. Si p no es primo, se puede tomar p = p+2 (búsqueda incremental) y volver a realizar la verificación del paso 2, o tomar un nuevo valor de p aleatorio (paso 1) y realizar de nuevo la verificación del paso 2.
Los tests de primalidad [9] utilizados actualmente para números grandes (de cientos o miles de bits) son test probabilísticos5, es decir, comprueban con una muy alta probabilidad si un número grande es primo o no. Para ello tienen en cuenta ciertas propiedades conocidas que cumplen los números primos en base a la teoría de números. Si se ejecutan varias veces sobre un mismo número candidato con distintos valores semilla de entrada, y todas las ejecuciones ratifican que el número parece ser primo, se dispondrá de un mayor nivel de certeza. A un mayor número de ejecuciones del test, mayor certeza de que el número candidato realmente es primo.

El test de primalidad más comúnmente empleado en la actualidad para verificar si un número es primo es el de Miller-Rabin6. Este tipo de tests son bastante rápidos de calcular y, de media, a la hora de comprobar si un número de 1.024 bits es primo, sólo tienen que verificar unos cientos de candidatos posibles, ya que la densidad de números primos en un rango de números cualquiera es bastante elevada (definida por aproximadamente 1/ln(n)). El teorema de los números primos [6] refleja que la distancia entre números primos, por ejemplo de 1.024 bits, es aproximadamente 1.024*ln(2), es decir, 710. Dado que sólo hay que comprobar los números impares como posibles números primos, la verificación o test de primalidad necesitaría comprobar unos 355 candidatos (710/2) antes de encontrar el siguiente número primo de manera incremental. Como referencia, la probabilidad de que Miller-Rabin detecte si un número es primo en una ejecución o ronda es del 75% [7], por lo que tras 64 ejecuciones, la probabilidad de error es muy pequeña, del orden de 2-128.

En el caso de OpenSSL [7], respondiendo a la pregunta {P3}, es posible consultar su código fuente7 [8] para ver que hace uso de numerosos tests, encontrándose referencias a un primer filtrado mediante un algoritmo determinista de criba rápida (cuyo código está basado en la implementación y código de PGP [8]), donde se divide al número candidato por algunos números primos pequeños (los primeros 2.048 números primos8, para descartar rápidamente si el candidato es primo o no), y si el número candidato pasa ese filtro, se emplean principalmente varias ejecuciones9 del test de Miller-Rabin y de su versión mejorada (mencionada posteriormente en el estándar FIPS 186-4, C.3.1 y C.3.2), así como finalmente ciertas comprobaciones para hacer uso de números primos seguros (en inglés, safe primes), es decir, donde (p-1)/2 también es un número primo10 [10]. La utilización de primos seguros puede mitigar ciertos ataques cuando estos números son utilizados con el algoritmo de intercambio de clave de Diffie-Hellman, así como minimizar el número de Claves Privadas Parejas (CPP) asociadas a las claves RSA

A modo de curiosidad, ciertas versiones de OpenSSL para claves con un reducido número de bits (128 bits), no utilizadas en la práctica actualmente, no verifican adecuadamente los números primos p y q empleados para la generación de las claves, lo que da lugar a claves RSA incorrectas, tal como se detalla en el artículo publicado en 2018 por Jorge Ramió: "¿Son correctas las claves RSA que generamos con Win64 OpenSSL1.1.0g? Intentando cifrar con RSA cuando p y q no son primos" [14].

Algunos estándares de la industria para la generación de claves RSA robustas, como ANSI X9.3111
, requerían que los números primos p y q empleados fuesen además primos fuertes (en inglés, strong primes), es decir, en teoría de números, un número primo que está más cerca del siguiente número primo que del número primo que le precede. En criptografía, un primo fuerte cumple ciertas condiciones relacionadas con el número primo que le precede y con el siguiente número primo [11]. El uso de primos fuertes en RSA se recomendó para minimizar los ataques de factorización mediante el algoritmo de Pollard p-1, aunque no protegen frente a otros métodos de factorización del módulo n, como Lenstra (basado en curvas elípticas) o la criba numérica o NFS (Number Field Sieve, o GNFS, General Number Field Sieve), por lo que algunos criptógrafos como Ron Rivest desaconsejaron su utilización ya en 2001 [12], debido también al mayor tiempo de búsqueda necesario para encontrar estos números primos y los limitados beneficios que aportan. En la actualidad, las implementaciones hacen uso de primos fuertes sólo si deben cumplir una certificación que lo impone como requisito (por ejemplo, IEEE 1363).

A modo de curiosidad, el record público actual de factorización de un módulo n de RSA es de 768 bits, conseguido mediante el método NFS a finales del año 2009 y documentado en "Factorization of a 768-bit RSA modulus" [19], asociado al RSA Factoring Challenge [20] (desafío que fue retirado previamente, en el año 2007).


Comentarios

1 Los números coprimos son números enteros (positivos), por ejemplo, a y b, que no tienen ningún factor primo en común, es decir, que su único divisor común es el 1. Dos números son coprimos si su máximo común divisor (MCD) es igual a 1 (mcd [a, b] = 1).
2 mcd [e, f(n)] = 1 (es decir, e y f(n) son números coprimos)
3 La clave privada d se calcula mediante el algoritmo extendido de Euclides.
4 Todos los números primos (números enteros positivos) mayores que 2 son impares.
5 A diferencia de las comprobaciones o tests determinísticos, como la criba de Eratóstenes, mucho más lento de calcular, o como el test AKS: https://es.wikipedia.org/wiki/Test_de_primalidad_AKS
6 Complementariamente, existen algoritmos para la generación de números primos, como el algoritmo de Maurer (apartado 4.4.4 [2]), empleado para la generación de primos provables: https://pdfs.semanticscholar.org/3df0/e64897ebbed46a6d034196f9b3962ca45b07.pdf
7 La versión actual de OpenSSL disponible en GitHub en el momento de elaboración del presente artículo era la 3.0.0-dev, mientras que la versión estable principal era la 1.1.1c.
9 El número de ejecuciones o iteraciones del test de primalidad de Miller-Rabin depende de la longitud en bits del número primo (tal y como también establece el estándar FIPS 186-4, descrito posteriormente).
10 Un número primo seguro se define habitualmente como un número de la forma 2p+1, donde p también es primo como, por ejemplo, 23 = 2*11+1, al ser 11 también un número primo.

Referencias:

Leer más
    email this       edit

2019/10/16

La ardilla, una de las mejores armas para las auditorías a entornos OT

Por el 2019/10/16 con 0 comentarios
Buenas a todos, las auditorías de seguridad sobre entornos OT son un "rara avis" dentro del mundo cyber, o al menos, lo eran, porque cada vez más, los clientes se aventuran a dejarnos entrar en sus entornos más críticos, para ayudarles a entender los riesgos a los que se encuentran expuestos en lo que para muchos de ellos es el core de sus negocios.

Con el paso de los años, desde Zerolynx nos hemos hecho con un set de herramientas software y hardware adaptadas a la realidad de estos entornos, que aunque tienen claras diferencias con el mundo IT que tradicionalmente veníamos trabajando, nos sorprende con numerosas similitudes. El mundo RTU va dejando paso a TCP/IP y los lazos que unen IT y OT empiezan a estrecharse, con los riesgos que supone todo ello si las segmentaciones no son las adecuadas.

De entornos OT os hablaremos largo y tendido en Flu Project, puesto que es uno de los campos en el que más nos estamos especializando, y trataremos diferentes topics como protocolos, clientes y herramientas, sistemas de protección perimetral, etc. etc. Pero hoy, os hablaremos de la herramienta que más útil nos está resultando en este tipo de auditorías, y sorprendentemente, la más económica y simple de todo nuestro arsenal, me estoy refiriendo a la popular ardilla de Hak5.

Esta sencilla herramienta, diseñada para realizar ataques de tipo MitM, es un gran recurso para poder capturar tramas industriales, de forma totalmente sigilosa y pasiva, para poder estudiar estos entornos antes de pasar a las fases activas de ataque.

En nuestro caso, tenemos configurado un sencillo script que con Tcpdump, realiza un volcado limpio de red, sin ningún otro tratamiento, para posteriormente realizar un análisis completo en las máquinas del laboratorio.

Pero, es importante tener varios aspectos en cuenta en este tipo de entornos:
  1. Para conectar la ardilla, hay que desconectar el cable de red del PLC, HMI, Switch, etc. ¡Mucho cuidado en entornos de producción! Es recomendable pactar una ventana horaria con el operador o responsable de planta, para realizar su conexión y posterior desconexión.
  2. La ardilla requiere de alimentación eléctrica. Utilizad un enchufe. Aunque hay baterías para móviles muy potentes, un microcorte, y la captura puede irse al traste :)
  3. No utilicéis pendrives para almacenar la información. Siempre requerid al cliente un pequeño análisis de volumetrías de red y utilizad discos duros con los TB suficientes. Yo siempre suelo hacer un x2 a lo que nos indican los clientes.
  4. Y finalmente, tened en cuenta que la ardilla es lo que es. No es un switch "industrial", y puede provocar ralentizaciones y cortes. Para sistemas grandes, es posible que precisemos utilizar otro tipo de tecnologías, o directamente, sentarnos con el equipo de OT del cliente para que nos brinden una captura de red con sus herramientas habituales de inspección. Es importante empatizar con la situación y entender que decirle a un cliente que vamos a conectar "no se que aparato", en una granja de aerogeneradores, fábrica, subestación, etc. que reporta miles de euros por minuto, puede ocasionarle cuanto menos, incertidumbre :) y sus cuestiones o dudas estarán totalmente justificadas.
Cuando comencéis a estudiar las capturas de red, lo primero que os sorprenderá es lo claro "que está todo". Los protocolos Modbus, MMS, etc. suelen ir en texto claro, sin cifrar, y sin apenas codificación, por lo que os será relativamente sencillo interpretar los datos que están siendo enviados. 



Sin embargo, lo que os costará, es entender que son los diferentes números e instrucciones enviados desde los HMI a los PLCs, los datos recuperados, etc. Es habitual que se utilicen tecnologías propietarias, que haya poca documentación y que el conocimiento dependa directamente de los ingenieros. No desesperéis. Este tipo de entornos están orientados a la disponibilidad y los tiempos de respuesta son cruciales, pero la integridad, confidencialidad y trazabilidad nunca han sido los ejes sobre los que han vertebrado los procesos de ingeniería, por lo que en muchas ocasiones os sangrarán los ojos con lo que veréis. Es algo que el tiempo irá cambiando poco a poco, o al menos, eso esperamos los que nos dedicamos al mundillo de la ciberseguridad.

Saludos!


Leer más
    email this       edit

2019/10/15

Monitorizando phishings mediante el API de PhishStats

Por el 2019/10/15 con 0 comentarios
Buenas a todos, hace algunos meses, publicamos desde Flu Project un artículo sobre PhishStats, la popular plataforma online que nos permite monitorizar phishings a través de un sencillo buscador. A las pocas semanas, recibimos un email de agradecimiento del equipo de profesionales que se encuentran detrás de la plataforma, y nos hablaron sobre el lanzamiento de su API oficial, la cual fue presentada el pasado 10 de septiembre de 2019 a través de su cuenta de Twitter.


El API de PhishStats se encuentra ya disponible bajo la siguiente URL:


Su uso es realmente sencillo, tal y como podéis ver en su documentación oficial:


Podéis consultar, por ejemplo, los phishings realizados sobre URLs que contengan el término Microsoft, con una petición como la siguiente:




O por una dirección IP, con una query como la siguiente:




No requiere de autenticación y su uso es gratuito, así que no dudéis en probarla.

Saludos!
Leer más
    email this       edit

2019/10/14

Trucos para campañas ofensivas (UAC)

Por el 2019/10/14 con 1 comentario
Buenas a todos, en el post de hoy queríamos hablaros de un sencillo truco que podréis utilizar en vuestras campañas ofensivas.
 
Habitualmente, si una víctima intenta ejecutar un binario no firmado que requiere de permisos de administración, será avisado a través de UAC con un mensaje similar al siguiente:


Como podemos observar, UAC nos avisa de que se trata de un binario no firmado. El siguiente gráfico nos muestra, a grandes rasgos, el código de colores utilizado por Windows en los avisos de UAC. Las siguientes pantallas provienen de un Windows Server 2008 R2, aunque nos sirven como referencia:



La documentación más actualizada de UAC para Windows 10 la podéis consultar en el siguiente enlace. En cualquier caso, lo que nos interesa es el código amarillo, un aviso de que el binario no está firmado o que ha sido firmado por un Publisher desconocido. ¿Cómo evitar esta situación?

@_qaz_qaz nos propone una alternativa. Ejecutar cmd.exe con permisos de administración, ya que UAC lo detectará como un binario firmado por Microsoft y lanzará nuestro proceso desde el proceso de cmd.exe ya ejecutado:

A través de este sencillo truco, podemos conseguir que la ventana de ejecución sea azul, o lo que es lo mismo, que se trate de un binario firmado, y que el campo Publisher aparezca como "Verified publisher: Microsoft Windows". A través de este mecanismo, podremos conseguir aumentar la probabilidad de que la víctima ejecute nuestra muestra:


Por supuesto, esta tarea se puede replicar con cualquier LOLBIN, y no sólo con cmd. ¿Cuál es vuestro favorito?

Leer más
    email this       edit

2019/10/11

CryptonDie: un ransomware con fines educativos



¡Hola a todos!

Desde hace algunos años, el crecimiento del ransomware es notable. Este tipo de amenazas crece de forma exponencial y son una amenaza importante para todo tipo de empresas. Hace pocos días, la firma especializada en soluciones de seguridad McAfee, informaba de que el crecimiento de las muestras de ransomware durante el primer trimestre del 2019 había sido del 118%. 

El ransomware es la amenaza de mayor crecimiento. Según un informe institucional del gobierno de los Estados Unidos, desde 2016 existe un promedio de 4.000 ataques de ransomware diarios en todo el mundo. Por lo tanto, es importante estudiar más en profundidad el funcionamiento de este tipo de amenazas, y para ello, una opción muy interesante podría ser la herramienta cryptonDie

CryptonDie es un ransomware de código abierto que ha sido desarrollado con fines de estudio, que utiliza un algoritmo de cifrado AES (Advanced Encryption Standard). Se puede acceder al repositorio de GitHub del proyecto desde el siguiente enlace.

Para empezar a utilizar la herramienta, es importante instalar los siguientes elementos:
pip3 install -r requirements.txt

Posteriormente debemos iniciar el servidor web:
cd cryptondie/discovery
python3 service_discovery.py

Una vez realizados los pasos anteriores, el modo de uso de la herramienta es muy sencillo, tal y cómo podéis ver a continuación:


En próximos artículos veremos más detalles sobre este ransom educativo y analizaremos su funcionamiento interno.

Disfruten de la herramienta ;)

Leer más
    email this       edit