
Psychic Signatures: lo que necesita saber
El 19 de abril de 2022, Neil Madden reveló una vulnerabilidad in Oracle Java 15 a 18 and OpenJDK 15, 17 and 18. La vulnerabilidad reside en la criptografía de las firmas ECDSA, que permite a un atacante eludir por completo las comprobaciones de estas firmas.
Es fácil ver los titulares sobre esta vulnerabilidad y pasarlos por alto, dada la naturaleza poco clara de las firmas de la ECDSA. Sin embargo, las firmas de la ECDSA en realidad desempeñan un papel clave en la protección de los sistemas de Internet para tareas críticas como la autenticación.
Antes de profundizar en los detalles, si quieres experimentar cómo los piratas informáticos explotan Psychic Signatures de forma práctica. Salta directamente a nuestro laboratorio gratuito - Misiones para probarlo tú mismo.
What is the problem with ECDSA?
Es posible que no haya oído hablar de la ECDSA antes. Es la abreviatura del algoritmo de firma digital de curva elíptica, que es un tipo de criptografía que utiliza las propiedades matemáticas de las curvas elípticas y ofrece una de las medidas de seguridad criptográficas más sólidas del sector en la actualidad.
Esto significa que se usa para muchas funciones importantes, como:
- La firma de certificados SSL
- Pretones de manos durante las comunicaciones cifradas
- SAML
- Firmas de JWT
- OpenID Connect Firmes
Esto significa que la ECDSA es una parte clave de muchas de las funciones más delicadas para proteger los sistemas que existen. La capacidad de eludir las verificaciones de firmas podría ser bastante devastadora.
¿Cómo se explota la vulnerabilidad?
Desafortunadamente, las matemáticas del ECDSA son algo complicadas. Pero lo más importante que hay que saber es que una firma del ECDSA contiene dos datos: Por lo tanto, y s.
Estos números se utilizan para calcular la validez de la firma. El valor r es el «resultado» (lado izquierdo) de un cálculo que utiliza ambos r y s en el lado derecho de la ecuación. Dado que multiplicar por 0 es una mala idea, la especificación ECDSA indica explícitamente que si el valor de r o s siempre es 0, deben descartarse.
Pero la implementación de ECDSA en Java olvidó tener esto en cuenta. Por lo tanto, aceptará la firma de ambos r y s es 0, lo que siempre será cierto. Podemos demostrarlo con un ejemplo de un JWT, mostrando lo fácil que es. ¿Usando https://token.dev/, podemos generar un token con el algoritmo ES256, similar a lo que generaría una aplicación:

Recuerde que un JWT se divide en 3 partes:
- Encabezado (en azul)
- Carga útil (en verde)
- Firma (en rojo)
Ahora, si quisiéramos saltarnos la verificación de firmas, ¿cómo lo haríamos? La firma especifica los valores de r Y sí, y está codificado en formato DER.

Cambiemos nuestro JWT para usar esta nueva firma. Tenga en cuenta que en los JWT, el signo igual no está incluido.

Ahora, nuestra firma tiene r y s establecido en 0 y, en las versiones vulnerables de Java, la comprobación de firmas ahora se realizará correctamente para cualquier carga útil que especifique.
¿Quién se ve afectado y cómo mitigarlo?
La vulnerabilidad afecta tanto a Oracle Java como a OpenJDK. Entre ellas se incluyen:
Oracle Java SE (y versiones anteriores no compatibles):
- 18
- 17,02
Oracle Enterprise Edition GraalVM:
- 22,0,02
- 213,1
OpenJDK:
- 18
- 17,02
- 15,06
- 13,0,10
- 11,0,14
- 8u322
- 7u331
Ambos Oráculo y OpenJDK han publicado avisos y parches para el problema que se pueden aplicar de inmediato.
Prácticas prácticas para defenderse de esta vulnerabilidad
En Secure Code Warrior, nos esforzamos por proporcionar a los desarrolladores la información más relevante y los ejercicios prácticos para las vulnerabilidades críticas, ya sea una más reciente, como Psychic Signatures, o algo que existe desde hace años.
Creemos que, para mantener realmente a raya el riesgo, es necesario permitir a los desarrolladores comprender el mecanismo de defensa y escribir código seguro desde el principio. Por eso, hemos creado una guía paso a paso sobre esta vulnerabilidad (y muchas otras) para ti y para los equipos afectados.
En el tutorial, podrás seguir las instrucciones para aprovechar la firma física en JWTS y ver el impacto en una aplicación que funciona en tiempo real.
Pruébalo ahora.


La vulnerabilidad de Psychic Signature reside en la criptografía de las firmas ECDSA, que protege los sistemas para tareas críticas como la autenticación. Con esta vulnerabilidad, los piratas informáticos pueden eludir cualquier comprobación de firmas. Explicamos qué es y cómo mitigarla en este post.

Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Vorführung buchen

El 19 de abril de 2022, Neil Madden reveló una vulnerabilidad in Oracle Java 15 a 18 and OpenJDK 15, 17 and 18. La vulnerabilidad reside en la criptografía de las firmas ECDSA, que permite a un atacante eludir por completo las comprobaciones de estas firmas.
Es fácil ver los titulares sobre esta vulnerabilidad y pasarlos por alto, dada la naturaleza poco clara de las firmas de la ECDSA. Sin embargo, las firmas de la ECDSA en realidad desempeñan un papel clave en la protección de los sistemas de Internet para tareas críticas como la autenticación.
Antes de profundizar en los detalles, si quieres experimentar cómo los piratas informáticos explotan Psychic Signatures de forma práctica. Salta directamente a nuestro laboratorio gratuito - Misiones para probarlo tú mismo.
What is the problem with ECDSA?
Es posible que no haya oído hablar de la ECDSA antes. Es la abreviatura del algoritmo de firma digital de curva elíptica, que es un tipo de criptografía que utiliza las propiedades matemáticas de las curvas elípticas y ofrece una de las medidas de seguridad criptográficas más sólidas del sector en la actualidad.
Esto significa que se usa para muchas funciones importantes, como:
- La firma de certificados SSL
- Pretones de manos durante las comunicaciones cifradas
- SAML
- Firmas de JWT
- OpenID Connect Firmes
Esto significa que la ECDSA es una parte clave de muchas de las funciones más delicadas para proteger los sistemas que existen. La capacidad de eludir las verificaciones de firmas podría ser bastante devastadora.
¿Cómo se explota la vulnerabilidad?
Desafortunadamente, las matemáticas del ECDSA son algo complicadas. Pero lo más importante que hay que saber es que una firma del ECDSA contiene dos datos: Por lo tanto, y s.
Estos números se utilizan para calcular la validez de la firma. El valor r es el «resultado» (lado izquierdo) de un cálculo que utiliza ambos r y s en el lado derecho de la ecuación. Dado que multiplicar por 0 es una mala idea, la especificación ECDSA indica explícitamente que si el valor de r o s siempre es 0, deben descartarse.
Pero la implementación de ECDSA en Java olvidó tener esto en cuenta. Por lo tanto, aceptará la firma de ambos r y s es 0, lo que siempre será cierto. Podemos demostrarlo con un ejemplo de un JWT, mostrando lo fácil que es. ¿Usando https://token.dev/, podemos generar un token con el algoritmo ES256, similar a lo que generaría una aplicación:

Recuerde que un JWT se divide en 3 partes:
- Encabezado (en azul)
- Carga útil (en verde)
- Firma (en rojo)
Ahora, si quisiéramos saltarnos la verificación de firmas, ¿cómo lo haríamos? La firma especifica los valores de r Y sí, y está codificado en formato DER.

Cambiemos nuestro JWT para usar esta nueva firma. Tenga en cuenta que en los JWT, el signo igual no está incluido.

Ahora, nuestra firma tiene r y s establecido en 0 y, en las versiones vulnerables de Java, la comprobación de firmas ahora se realizará correctamente para cualquier carga útil que especifique.
¿Quién se ve afectado y cómo mitigarlo?
La vulnerabilidad afecta tanto a Oracle Java como a OpenJDK. Entre ellas se incluyen:
Oracle Java SE (y versiones anteriores no compatibles):
- 18
- 17,02
Oracle Enterprise Edition GraalVM:
- 22,0,02
- 213,1
OpenJDK:
- 18
- 17,02
- 15,06
- 13,0,10
- 11,0,14
- 8u322
- 7u331
Ambos Oráculo y OpenJDK han publicado avisos y parches para el problema que se pueden aplicar de inmediato.
Prácticas prácticas para defenderse de esta vulnerabilidad
En Secure Code Warrior, nos esforzamos por proporcionar a los desarrolladores la información más relevante y los ejercicios prácticos para las vulnerabilidades críticas, ya sea una más reciente, como Psychic Signatures, o algo que existe desde hace años.
Creemos que, para mantener realmente a raya el riesgo, es necesario permitir a los desarrolladores comprender el mecanismo de defensa y escribir código seguro desde el principio. Por eso, hemos creado una guía paso a paso sobre esta vulnerabilidad (y muchas otras) para ti y para los equipos afectados.
En el tutorial, podrás seguir las instrucciones para aprovechar la firma física en JWTS y ver el impacto en una aplicación que funciona en tiempo real.
Pruébalo ahora.

El 19 de abril de 2022, Neil Madden reveló una vulnerabilidad in Oracle Java 15 a 18 and OpenJDK 15, 17 and 18. La vulnerabilidad reside en la criptografía de las firmas ECDSA, que permite a un atacante eludir por completo las comprobaciones de estas firmas.
Es fácil ver los titulares sobre esta vulnerabilidad y pasarlos por alto, dada la naturaleza poco clara de las firmas de la ECDSA. Sin embargo, las firmas de la ECDSA en realidad desempeñan un papel clave en la protección de los sistemas de Internet para tareas críticas como la autenticación.
Antes de profundizar en los detalles, si quieres experimentar cómo los piratas informáticos explotan Psychic Signatures de forma práctica. Salta directamente a nuestro laboratorio gratuito - Misiones para probarlo tú mismo.
What is the problem with ECDSA?
Es posible que no haya oído hablar de la ECDSA antes. Es la abreviatura del algoritmo de firma digital de curva elíptica, que es un tipo de criptografía que utiliza las propiedades matemáticas de las curvas elípticas y ofrece una de las medidas de seguridad criptográficas más sólidas del sector en la actualidad.
Esto significa que se usa para muchas funciones importantes, como:
- La firma de certificados SSL
- Pretones de manos durante las comunicaciones cifradas
- SAML
- Firmas de JWT
- OpenID Connect Firmes
Esto significa que la ECDSA es una parte clave de muchas de las funciones más delicadas para proteger los sistemas que existen. La capacidad de eludir las verificaciones de firmas podría ser bastante devastadora.
¿Cómo se explota la vulnerabilidad?
Desafortunadamente, las matemáticas del ECDSA son algo complicadas. Pero lo más importante que hay que saber es que una firma del ECDSA contiene dos datos: Por lo tanto, y s.
Estos números se utilizan para calcular la validez de la firma. El valor r es el «resultado» (lado izquierdo) de un cálculo que utiliza ambos r y s en el lado derecho de la ecuación. Dado que multiplicar por 0 es una mala idea, la especificación ECDSA indica explícitamente que si el valor de r o s siempre es 0, deben descartarse.
Pero la implementación de ECDSA en Java olvidó tener esto en cuenta. Por lo tanto, aceptará la firma de ambos r y s es 0, lo que siempre será cierto. Podemos demostrarlo con un ejemplo de un JWT, mostrando lo fácil que es. ¿Usando https://token.dev/, podemos generar un token con el algoritmo ES256, similar a lo que generaría una aplicación:

Recuerde que un JWT se divide en 3 partes:
- Encabezado (en azul)
- Carga útil (en verde)
- Firma (en rojo)
Ahora, si quisiéramos saltarnos la verificación de firmas, ¿cómo lo haríamos? La firma especifica los valores de r Y sí, y está codificado en formato DER.

Cambiemos nuestro JWT para usar esta nueva firma. Tenga en cuenta que en los JWT, el signo igual no está incluido.

Ahora, nuestra firma tiene r y s establecido en 0 y, en las versiones vulnerables de Java, la comprobación de firmas ahora se realizará correctamente para cualquier carga útil que especifique.
¿Quién se ve afectado y cómo mitigarlo?
La vulnerabilidad afecta tanto a Oracle Java como a OpenJDK. Entre ellas se incluyen:
Oracle Java SE (y versiones anteriores no compatibles):
- 18
- 17,02
Oracle Enterprise Edition GraalVM:
- 22,0,02
- 213,1
OpenJDK:
- 18
- 17,02
- 15,06
- 13,0,10
- 11,0,14
- 8u322
- 7u331
Ambos Oráculo y OpenJDK han publicado avisos y parches para el problema que se pueden aplicar de inmediato.
Prácticas prácticas para defenderse de esta vulnerabilidad
En Secure Code Warrior, nos esforzamos por proporcionar a los desarrolladores la información más relevante y los ejercicios prácticos para las vulnerabilidades críticas, ya sea una más reciente, como Psychic Signatures, o algo que existe desde hace años.
Creemos que, para mantener realmente a raya el riesgo, es necesario permitir a los desarrolladores comprender el mecanismo de defensa y escribir código seguro desde el principio. Por eso, hemos creado una guía paso a paso sobre esta vulnerabilidad (y muchas otras) para ti y para los equipos afectados.
En el tutorial, podrás seguir las instrucciones para aprovechar la firma física en JWTS y ver el impacto en una aplicación que funciona en tiempo real.
Pruébalo ahora.

Klicken Sie auf den untenstehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht anzeigenEine Vorführung buchenEl 19 de abril de 2022, Neil Madden reveló una vulnerabilidad in Oracle Java 15 a 18 and OpenJDK 15, 17 and 18. La vulnerabilidad reside en la criptografía de las firmas ECDSA, que permite a un atacante eludir por completo las comprobaciones de estas firmas.
Es fácil ver los titulares sobre esta vulnerabilidad y pasarlos por alto, dada la naturaleza poco clara de las firmas de la ECDSA. Sin embargo, las firmas de la ECDSA en realidad desempeñan un papel clave en la protección de los sistemas de Internet para tareas críticas como la autenticación.
Antes de profundizar en los detalles, si quieres experimentar cómo los piratas informáticos explotan Psychic Signatures de forma práctica. Salta directamente a nuestro laboratorio gratuito - Misiones para probarlo tú mismo.
What is the problem with ECDSA?
Es posible que no haya oído hablar de la ECDSA antes. Es la abreviatura del algoritmo de firma digital de curva elíptica, que es un tipo de criptografía que utiliza las propiedades matemáticas de las curvas elípticas y ofrece una de las medidas de seguridad criptográficas más sólidas del sector en la actualidad.
Esto significa que se usa para muchas funciones importantes, como:
- La firma de certificados SSL
- Pretones de manos durante las comunicaciones cifradas
- SAML
- Firmas de JWT
- OpenID Connect Firmes
Esto significa que la ECDSA es una parte clave de muchas de las funciones más delicadas para proteger los sistemas que existen. La capacidad de eludir las verificaciones de firmas podría ser bastante devastadora.
¿Cómo se explota la vulnerabilidad?
Desafortunadamente, las matemáticas del ECDSA son algo complicadas. Pero lo más importante que hay que saber es que una firma del ECDSA contiene dos datos: Por lo tanto, y s.
Estos números se utilizan para calcular la validez de la firma. El valor r es el «resultado» (lado izquierdo) de un cálculo que utiliza ambos r y s en el lado derecho de la ecuación. Dado que multiplicar por 0 es una mala idea, la especificación ECDSA indica explícitamente que si el valor de r o s siempre es 0, deben descartarse.
Pero la implementación de ECDSA en Java olvidó tener esto en cuenta. Por lo tanto, aceptará la firma de ambos r y s es 0, lo que siempre será cierto. Podemos demostrarlo con un ejemplo de un JWT, mostrando lo fácil que es. ¿Usando https://token.dev/, podemos generar un token con el algoritmo ES256, similar a lo que generaría una aplicación:

Recuerde que un JWT se divide en 3 partes:
- Encabezado (en azul)
- Carga útil (en verde)
- Firma (en rojo)
Ahora, si quisiéramos saltarnos la verificación de firmas, ¿cómo lo haríamos? La firma especifica los valores de r Y sí, y está codificado en formato DER.

Cambiemos nuestro JWT para usar esta nueva firma. Tenga en cuenta que en los JWT, el signo igual no está incluido.

Ahora, nuestra firma tiene r y s establecido en 0 y, en las versiones vulnerables de Java, la comprobación de firmas ahora se realizará correctamente para cualquier carga útil que especifique.
¿Quién se ve afectado y cómo mitigarlo?
La vulnerabilidad afecta tanto a Oracle Java como a OpenJDK. Entre ellas se incluyen:
Oracle Java SE (y versiones anteriores no compatibles):
- 18
- 17,02
Oracle Enterprise Edition GraalVM:
- 22,0,02
- 213,1
OpenJDK:
- 18
- 17,02
- 15,06
- 13,0,10
- 11,0,14
- 8u322
- 7u331
Ambos Oráculo y OpenJDK han publicado avisos y parches para el problema que se pueden aplicar de inmediato.
Prácticas prácticas para defenderse de esta vulnerabilidad
En Secure Code Warrior, nos esforzamos por proporcionar a los desarrolladores la información más relevante y los ejercicios prácticos para las vulnerabilidades críticas, ya sea una más reciente, como Psychic Signatures, o algo que existe desde hace años.
Creemos que, para mantener realmente a raya el riesgo, es necesario permitir a los desarrolladores comprender el mecanismo de defensa y escribir código seguro desde el principio. Por eso, hemos creado una guía paso a paso sobre esta vulnerabilidad (y muchas otras) para ti y para los equipos afectados.
En el tutorial, podrás seguir las instrucciones para aprovechar la firma física en JWTS y ver el impacto en una aplicación que funciona en tiempo real.
Pruébalo ahora.
Inhaltsverzeichnis

Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Vorführung buchenHerunterladenRessourcen für den Einstieg
Themen und Inhalte der Schulung zum Thema sicherer Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sich an die sich wandelnde Landschaft der Softwareentwicklung anzupassen und dabei Ihre Rolle zu berücksichtigen. Es werden Themen angeboten, die von KI bis hin zu XQuery-Injektion reichen und sich an verschiedene Positionen richten, von Architekten und Ingenieuren bis hin zu Produktmanagern und Qualitätskontrolleuren. Verschaffen Sie sich einen Überblick über unser Angebot an Inhalten nach Thema und Funktion.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen für den Einstieg
Cybermon ist zurück: Die KI-Missionen von Beat the Boss sind jetzt auf Abruf verfügbar.
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über bei SCW verfügbar. Implementieren Sie fortschrittliche KI- und LLM-Sicherheitsherausforderungen, um die sichere Entwicklung von KI in großem Maßstab zu stärken.
Erläuterung des Gesetzes zur Cyberresilienz: Was bedeutet es für die Entwicklung sicherer Software?
Entdecken Sie, was das EU-Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams mit sicheren Designpraktiken, der Vermeidung von Schwachstellen und der Entwicklung von Fähigkeiten für Entwickler darauf vorbereiten können.
SCW feiert sein 11-jähriges Bestehen: eine Lektion in Echtzeit über Anpassungsfähigkeit und kontinuierliche Verbesserung
2025 war ein großartiges Jahr für KI, Cybersicherheit und SCW. Ich gehe mit ruhiger Zuversicht und dem Optimismus, den nur harte und lohnende Arbeit mit sich bringen kann, auf das Jahr 2026 zu.




%20(1).avif)
.avif)
