Mensajes

Y por otro lado "la NSA lo mira todo"

Bueno este es mi tema... PRISM, Bullrun, Dual ECDRBG y un largo etc. La NSA revisa los estándares criptográficos propuestos por el NIST, dónde el NIST cumple el FIPS. Los expertos académicos revisaron y siguen revisando dichos estándares y cada año proponen cambios sobre los mismos. Os recuerdo que en los años 90 la criptrografía estaba regulada de forma mundial por la NSA, y si tu proyecto utilizaba dichas primitivas y estabas fuera de USA, tenías que rebajar tu tamaño de clave al específicado en las suites EXPORT (más o menos la mitad de la clave en bits).

Que no inspeccionen nuestra información privada y confidencial, no quiere decir que sean capaces de hacerlo. Primero tienen que romper la crypto o bien PKI, pero si ellos se aseguran de revisar y aprobar los estándares, no sé que dificultad encontrarán para este propósito. Un ejemplo es https://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography

Y bueno me podría tirar horas y horas hablando. Pasaros por el foro de crypto que hace tiempo arget y yo debatimos este maravilloso tema de forma técnica sin saltarnos nada.

Para terminar y dejarlo bien claro, esta fue la respuesta del NIST sobre las críticas de aquellos que decían que permitieron a la NSA introducir una vulnerabilidad en ECDRBG:

"NIST works to publish the strongest cryptographic standards possible" and that it uses "a transparent, public process to rigorously vet our recommended standards".[21] The agency stated that "there has been some confusion about the standards development process and the role of different organizations in it...The National Security Agency (NSA) participates in the NIST cryptography process because of its recognized expertise. NIST is also required by statute to consult with the NSA."[22] Recognizing the concerns expressed, the agency reopened the public comment period for the SP800-90 publications, promising that "if vulnerabilities are found in these or any other NIST standards, we will work with the cryptographic community to address them as quickly as possible".

Saludos!

He leído un rato el PDF del artículo original y bueno dejo mi opinión al respecto:

Este tipo de amenazas no son nuevas, siempre ha existido un tipo de malware que reside en el hardware, siendo así indetectable de lado del OS, puesto que las suites de seguridad auditan la seguridad de los OS no del hardware subyacente. No es lo mismo infectar un driver del sistema que el firmware de la placa base, la diferencia es que el driver sería detectado y el firmware no.

Debido a esto, los desarrolladores de firmware para BIOS idearon UEFI pensando en la seguridad e incluyeron Secure Boot. Al iniciar el sistema, antes de cargar el OS, si Secure Boot esta activo, la interfaz UEFI verificará mediante public key crypto si el archivo de arranque del OS fue modificado. Si la verificación es correcta pasará a cargar el archivo de arranque del OS y ya se carga el kernel del OS (Windows por ejemplo). Luego el OS verifica uno a uno la integridad de cada uno de los drivers del kernel.

Como vemos arriba, el eslabón más débil es el archivo de arranque (bootloader), el cual si es infectado el atacante puede saltarse las verificaciones pudiendo patchear un kernel driver y poder manipular cualquier extensión del OS, a esto se le conoce como rootkit, típicamente en MBR o GPT con Secure Boot desactivado.

La trama no acaba aquí, se han dado vulnerabilidades en ciertas versiones UEFI dónde el atacante es capaz de cambiar la clave pública insertando la suya propia, por lo tanto sólo tendría que crear un nuevo bootloader y firmarlo con su privada.

Vale, ahora que los desarrolladores de malware saben que UEFI con Secure Boot les parará los pies, se han dado cuenta de que flasheando el firmware de otros dispositivos, como discos HDD/SSD, consiguen que su código resida ahí, puesto que no se hacen checkeos de integridad del firmware de ningún dispositivo.

Resumiendo, hasta ahora los únicos checkeos de integridad que se realizan son los descritos arriba, checkeo de integridad del bootloader si Secure Boot está activo, y checkeo de integridad de los drivers del sistema una vez que el bootloader ha sido ejecutado.

Para que te flasheen el firmware del disco duro el atacante necesita distribuir un kernel driver, por lo tanto necesita privilegios dentro de tu sistema. Para ello el atacante junto a dicha distribución debe de adjuntar también un exploit de elevación de privilegios para poder subir al kernel. Un HIPS, y no digo Anti-Virus, sino detector de intrusos, puede detectar dichas ejecucciones, recomiendo un HIPS a todo el mundo que se preocupa realmente por su seguridad.

Saludos!

Es SHA-1 pues longitud 40, por lo tanto 20 bytes, 160 bits. La password es sezer123 según https://crackstation.net/ .

Saludos!

Buenas,

los .p12 suelen traer un certificado root CA con su respectiva private key, supongo que cifrada. Así mismo los .p12 van cifrados con algoritmos simétricos al cual se les aplica una función hash o MAC. Apenas das información al respecto, puede que logres descifrar las pass del .p12 pero quizá te topes con la private key cifrada.

De hecho para crackear 4 letras y números,  en el peor de los casos sería 36⁸ =  .2.821109907×10¹²

En el caso general debes de hacer una permutación con repetición de longitud 8 con 4 letras y 4 numeros repetidos. En total son 70. Ahora por cada una de las 70 se aplican 26⁴.10⁴ variaciones.

En total tendrías 70. 26⁴.10⁴  palabras de longitud 8.

Solo falta hacer un programa que dado un charset o alfabeto se base en dicha lógica combinatorial para generar las secuencias. Utiliza listas ligadas y ganarás.

Saludos!

Buenas.

Adoro docker, me alegro de que se use por aquí. Para elevar privilegios o ponerte como root en el dockerfile utiliza la sentencia USER. Ejemplo:

....
USER root
apt-get install ....
USER elUserDeAntes

Por lo tanto actuas como root y cambias al user que tenía el control anteriormente. Ya nos contarás.

Saludos!

Este ataque tiene historia, antes de ser comentado en la BlackHat, nuestro querídismo Lenstra ya lo había propuesto en un paper del año 96 lo único que teorizándolo. Como bien sabemos a los chicos de la BlackHat les encanta el lema de "exploiting everywhere" por lo tanto se trabajaron este nuevo paper y demostraron lo que Lenstra teorizó, explotando unos cuantas sesiones TLS y explicando más o menos en que consisten los fallos.

El paper de la BlackHat está en el post inicial, 3ª línea.
El paper de Lenstra es : https://infoscience.epfl.ch/record/164524/files/nscan20.PDF

Los de BlackHat nos dan las siguientes premisas para que un fallo suceda en la computación del Residue Number System con isomorfismo a Z/nZ:

- La librería de precisión aritmética múltiple utilizada en la implementación de RSA tiene un defecto que produce malos resultados. Revisar CVE-2014-357.
- Puede haber una race condition de acceso a datos entre hilos no sincronizados, por lo tanto ya sabemos que sucede aquí (nefasto).
- Fallos en la unidad aritmético lógica de la CPU de forma determinista en base a http://iacr.org/archive/crypto2008/51570222/51570222.pdf o dependiendo de unas condiciones de entorno.
- http://eprint.iacr.org/2002/076.pdf
- Otros módulos del PC como la cache o la RAM han sido alterados, cambiando los valores del Reduced Number System.

Saludos!

Buenas,

intentaré dar una explicación detallada del por que del problema, además de su aplicación matemática y resolución. A través de los conceptos aquí descritos sereís capaces de poder factorizar el módulo semiprimo RSA.

El paper en cuestión es : https://people.redhat.com/~fweimer/rsa-crt-leaks.pdf

Lo primero, voy a completar la sentencia del problema inicial, puesto que en primera instancia parece simple, pero han de darse unas condiciones de fallo en el sistema para poder realizar la factorización. Completo citando el abstracto del paper:

All that needed is the generation of a faulty digital signature from server, an event that can be observed when occurring certain conditions such as

Como vemos el servidor tiene que generar una firma digital de forma errónea, evento que puede suceder cuando se dan ciertas condiciones como errores de hardware, sobrecarga de módulos, inundación etc. Además la implementación de RSA debe de contar con la optimización CRT.

¿Qué es la optimización CRT?

Una de las aplicaciones del Chinese Remainder Theorem (CRT) es optimizar el coste computacional que conllevan las operaciones en el grupo multiplicativo modulo pq, concretamente las exponenciales modulares. La optimización se realiza computando los residuos sobre los módulos primos (por separado) y aplicando CRT sobre dichos residuos y módulos primos para así obtener el residuo en el módulo principal pq. El taller sobre el CRT lo podeís consultar aquí: https://foro.elhacker.net/criptografia/taller_chinese_remainder_theorem-t452361.0.html

Por lo tanto la optimización por CRT divide las operaciones en dos grupos multiplicativos módulo p y q (por separado) y luego reagrupa en pq mediante CRT. Este concepto se llama Residue Number System https://en.wikipedia.org/wiki/Residue_number_system .

Ahora abordemos la vulnerabilidad planteada en el paper:

Es bien sabido que al hablar de Perfect-Forward Secrecy nos referimos a las suites criptográficas que cuentan con algorítmos ephemeral, es decir, aquellos que en cada negociación TLS utilizan una clave asimétrica distinta, por lo tanto si un atacante rompiera una clave el mismo sólo tendría acceso a la clave simétrica (AES, TDES..) de esa sesión, pero no a las demás claves simétricas de sesiones distintas. En cambio si rompes RSA podrás descifrar todas las claves de sesión capturadas. Esta es el concepto del porque del esfuerzo para migrar a suites que incluyan Perfect-Forward Secrecy.

Hay una gran diferencia entre una sesión TLS negociada sólo con RSA+simétrica o con RSA+ECHDE/DHE+simétrica.

Veamos que sucedería si el servidor malfuncionara a la hora de realizar una sesión TLS utilizando una suite con Perfect-Forward Secrecy:

Con las suites que incluyen Perfect-Forward Secrecy (Ephemeral crypto) sucede un nuevo evento llamado ServerKeyExchange, donde el servidor envía su clave pública y una firma digital sobre la misma, que es un hash firmado por la clave pública RSA del certificado.

Si a la hora de computar la firma digital sobre los dos grupos multiplicativos modulares en p y q, fallará al hacerlo en p y lo hiciera bien en q, tendríamos un escenario con la siguiente información:

y_p = x'^d (mod p)
y_q = x^d (mod q)

Por lo que vemos que x' y x son distintas y deberían de ser iguales (para cumplir el CRT y la firma digital), por lo tanto se ha cometido un error al denotar x'.

Si pasamos mediante CRT y_p e y_q a y_n tendríamos la representación final:

y_n = y_p*q*[q]^-1_p + y_q*p*[p]^-1_q (mod pq)

donde [q]^-1_p es la modular multiplicativa inversa de q en p es decir q^-1 = q^p-2 (mod p)
y [p]^-1_q es la modular multiplicativa inversa de p en q es decir p^-1 = p^q-2 (mod q)

Vease que la modular multiplicativa inversa con módulo primo siempre tendrá exponente p-2 ya que el exponente se obtiene mediante:

phi(p)-1 y como p es primo, phi(p) = p - 1 por lo tanto phi(p) - 1 = p - 2

y_n = x''^d (mod pq)

Notése que x'' no es x, y debería de ser x en un escenario sin fallos (cumpliendo el CRT). Esto quiere decir la verificación de la firma digital nunca será x, ya que hemos utilizado dos x distintas, por lo tanto el destinatario fallará al validarla, pero el atacante (NOSOTROS) tendríamos la siguiente información:

x'' = y_n^e (mod pq)

gcd(x'' - x, n) = q, por lo que q es un múltiplo de x'' - x. Fijaos en la ecuación del CRT para verificar la multiplicidad.

Un ejemplo en C#, el código de abajo selecciona dos primos p,q y computa la clave privada d, el exponente público e y la clave pública n (p*q).

Después selecciona dos valores x y x''. Recordad que para que funcione RSA con la optimización CRT los valores de x han de ser iguales (principio del CRT), por lo tanto mi código se aprovecha de la vulnerabilidad descrita en este post.

Lo siguiente que hará el code es computar el CRT de y_p e y_q y dejarlo en la variable CRT para así factorizar el módulo pq mediante el gcd del módulo pq con el descifrado de CRT menos x. El resto del gcd es el factor primo q del módulo.

En un escenario real el cliente tendría los valores de las variables, CRT, e, x y n, el resto de operaciones las calcula el server, vamos que es 100% aplicable en un escenario real.

Código (csharp) [Seleccionar] Expandir


static void Main()
       {
           using (RSACryptoServiceProvider csp = new RSACryptoServiceProvider(512))
           {
               RSAParameters rsaparams = csp.ExportParameters(true);
               p = FromBigEndian(rsaparams.P);
               BigInteger n = FromBigEndian(rsaparams.Modulus);
               BigInteger d = FromBigEndian(rsaparams.D);
               BigInteger e = FromBigEndian(rsaparams.Exponent);
               BigInteger q = FromBigEndian(rsaparams.Q);
               if (p < q)
               {
                   BigInteger swap = q;
                   q = p;
                   p = swap;
               }
               BigInteger x = BigInteger.Parse("126858358328568235238789");
               BigInteger xpr = BigInteger.Parse("87281629769238657836258");
               BigInteger yp = BigInteger.ModPow(xpr, d, p);
               BigInteger yq = BigInteger.ModPow(x, d, q);
               BigInteger invqp = BigInteger.ModPow(q, p - 2, p);
               BigInteger invpq = BigInteger.ModPow(p, q - 2, q);
               BigInteger CRT = BigInteger.Remainder(yp * q * invqp + yq * p * invpq, n);
               //El cliente dispone del valor CRT, e, n y x pues los entrega el server
               BigInteger gcd = BigInteger.GreatestCommonDivisor(BigInteger.ModPow(CRT,e,n) - x, n);
               Console.WriteLine("q is {0} = " , gcd);
           }
       }


Estaré encantado de responder cualquier pregunta.

Saludos!

Échale un vistazo a https://en.wikipedia.org/wiki/Substitution_cipher . Normalmente el plaintext y el ciphertext en algoritmos de Sustitución suelen tener la misma longitud, a no ser que se les introduzca un padding, cosa que sucede en los algoritmos de cifrado por bloque.

Si nos dieses un pelín más de info podríamos ayudarte,

Saludos!

Buenas Kaxper

Bienvenido al maravillosos mundo de la OOP (prog. orientada a objetos), dónde mínimo hay que leer sobre patrones de diseño, jerarquía y estructura de clases, herencia multiple, clases abstractas, interfaces, overrides, overload, herencia virtual etc

Si tienes una clase que es única, por ejemplo con métodos estáticos, lo mejor es que implementes el patrón Singleton en la misma, por lo tanto a la hora de utilizar un método de dicha clase tendrías: Clase.GetMiClase().MétodoStatic() y ya habrías convertido dichos métodos estáticos en el paradigma de OOP.

Si quieres desde un Thread llamar a un método de una clase instanciada puedes referenciar un puntero a un miembro de dicha clase y llamarlo desde la rutina del Thread, sin necesidad de aislar la lógica de una clase, por lo tanto queda mejor estructurado.

Separar tu módelo de programación en múltiples clases, sin escribir código, sólo la lógica (funciones/clases/dependencias), te será de gran ayuda a la hora de visualizar como quedará el proyecto, además solucionará los problemas de herencia que puedas llegar a tener, pues lo mejor de programar es tener una vision temprana del proyecto, sino tocará reescribir o morir programando.

Creo que C++ y también maneja elementos privados y publicos no?

Así es, soporta herencia privada, pública, protected y virtual.

Saludos!

hola amigos tengo otra duda y es que en la versión de windows 8.1 tenia el proceso rundll32 ejecutándose desde que encendía la maquina y ahora que me actualice a windows 10 también lo tengo ejecutándose

pregunto si es normal o si no para meterle mano y averiguar que es lo que sucede


saludos Flamer

Métele mano. RunDll32 es un proceso auxiliar y confiable por el sistema, por lo tanto ideal para cargar código malicioso. Puede llegar a ser normal verlo ejecutarse en el inicio, o cuando abres algo auxiliar, pero verlo constantemente corriendo huele mal. Intenta hacerle un dump de las dependencias que tiene en runtime y si puedes deducir el comportamiento de su rutina de ejecucción mucho mejor.

Saludos!