Información sobre el código seguro

Secure Code Warrior y Okta lanzan una nueva forma de asegurar los flujos de trabajo de los desarrolladores

Se espera que los desarrolladores entreguen código de calidad más rápido que nunca, pero no cabe duda de que los plazos poco realistas pueden dar lugar a una mala calidad del software y a un código vulnerable. No es de extrañar que el 67% de los desarrolladores piensen que envían código con vulnerabilidades, en parte debido a los ajustados plazos(State of Developer-Driven Security 2022). Dado que las amenazas y las infracciones siguen aumentando, la seguridad ya no puede ser una idea tardía, sino que debe integrarse en todo el ciclo de DevSecOps.

Nos complace anunciar el conector Secure Code Warrior para los flujos de trabajo de Okta, que permite a las organizaciones y a los desarrolladores escribir código seguro desde el inicio del ciclo de vida del desarrollo de software. Esta nueva colaboración entre SCW y Okta, el principal proveedor independiente de identidades, crea una comprobación de competencia en seguridad que permitirá a los responsables de AppSec estar seguros de que el equipo está escribiendo código seguro para reducir las vulnerabilidades, todo ello sin sacar a los desarrolladores de su flujo de trabajo. Además, hemos añadido el inicio de sesión único para Secure Code Warrior y Okta para que sea aún más sencillo aprovechar esta gran solución nueva.

Reducir el riesgo de introducir vulnerabilidades

Los equipos de desarrollo han confiado tradicionalmente en procesos reactivos o lentos que se encuentran más adelante en el ciclo de desarrollo, como los plugins, las herramientas de escaneo o las revisiones de código para localizar y arreglar los problemas de seguridad --aunque estos enfoques tienen muchos beneficios, simplemente crean demasiado riesgo de código vulnerable y de retrabajo futuro. En su lugar, estamos aquí para ayudar a las organizaciones a cambiar la seguridad hacia la izquierda y adoptar una postura de seguridad proactiva, no reactiva. El nuevo Secure Code Warrior Connector for Okta Workflows integra el pensamiento de seguridad en todo el ciclo de desarrollo, garantizando que cada desarrollador individual haya alcanzado las habilidades de codificación segura necesarias para que se le conceda acceso al repositorio para confirmar el código. Esta integración garantizará que los desarrolladores conozcan las últimas prácticas de seguridad a través de la atractiva plataforma de SCW y que se reduzcan algunas de las cargas de las revisiones manuales de código, liberando horas de ingeniería para enviar más funcionalidad sin sacrificar la calidad.

Los líderes de AppSec y de ingeniería aprovechan la extensa learning platform de SCW para crear evaluaciones y rutas personalizadas para asegurarse de que los desarrolladores se centran en sus necesidades de codificación segura más prioritarias y consiguen la experiencia adecuada para estar seguros de que pueden comprobar el código. Con la ayuda de la amplitud y la profundidad del contenido, más de 6500 desafíos de codificación interactivos, más de 56 lenguajes:marcos de trabajo y más de 150 categorías de vulnerabilidad, puede estar seguro de que prácticamente todas las necesidades pueden satisfacerse para su organización.

Una vez que haya creado la estrategia de aprendizaje adecuada para su equipo, las puntuaciones de assessment , así como el estado de finalización de un curso, pueden utilizarse para determinar si los desarrolladores tienen las habilidades adecuadas para construir software con un enfoque de seguridad primero. Gracias a la nueva integración con Okta, ahora puede automatizar los permisos para cada desarrollador en función de sus puntuaciones en assessment para escalar fácilmente la aprobación de cada desarrollador individual para confirmar código o identificar oportunidades para mejorar su conjunto de habilidades.

Gracias a la experiencia de aprendizaje flexible e interactiva de la plataforma SCW, los desarrolladores disfrutan constantemente mientras aprenden y pueden ver un cambio en su enfoque del aprendizaje, que pasa de ser una casilla de verificación de cumplimiento a ser convincente y valioso.

Cómo funciona

El Secure Code Warrior Connector for Okta Workflows es fácil de construir con Okta Workflows sin código de automatización de identidad y configuración de orquestación, utilizando la lógica if-then. El conector utiliza un conjunto de acciones que le ayudan a realizar tareas de flujo de trabajo sin preocuparse por las complejidades subyacentes de las llamadas a la API y la configuración.

Un diseño sencillo para asegurar el flujo de trabajo de los desarrolladores tiene este aspecto:

A continuación se presenta una visión general del diseño del flujo de trabajo completo:

‍

Repasemos los pasos:

1. Configure el ID de assessment utilizado para determinar la competencia de seguridad de un desarrollador. Además, añada los detalles de GitHub, como la organización y el repositorio, como parte de la configuración.

2. Mediante la acción denominada Check Assessment Completion For User, el flujo de trabajo comprueba si un desarrollador ha superado con éxito una determinada assessment.

‍

3. Si se ha completado el curso deseado/assessment o se ha alcanzado una puntuación determinada, entonces se utiliza el Conector GitHub para conceder el acceso al repositorio. Si no se cumple el requisito, se puede generar una notificación o desencadenar otro flujo de trabajo de Okta para tomar las medidas oportunas.

‍

Lo anterior puede diseñarse para que se ejecute como una comprobación única, periódica o continua, de modo que siga admitiendo sólo a los desarrolladores elegibles en el flujo de trabajo seguro.

Algunas de las otras posibles acciones del conector SCW son:

• Listar Assessment Intentos Para Usuario - lista todos los intentos que un usuario tiene para un determinado assessment
• Comprobar la finalización del curso para el usuario - determina si un usuario ha completado un curso específico
• Listar inscripciones de cursos para el usuario - lista todas las inscripciones que un usuario tiene para un ID de curso en particular
• Acción API personalizada: para ejecutar cualquier llamada a la API que no sea posible a través de las Acciones disponibles

Libere código seguro de alta calidad con mayor rapidez y confianza

SCW Connector ayuda a reducir el riesgo de introducir vulnerabilidades al principio del ciclo de vida del desarrollo de software. Al igual que las revisiones de código y las herramientas de escaneo, desempeña el papel de una puerta de calidad para garantizar que los desarrolladores están escribiendo código seguro desde el principio. Como resultado, se invierte menos tiempo en la revisión del código y en la corrección de problemas evitables, y el enfoque se desplaza hacia el envío de código de calidad con mayor rapidez. Además, el Conector también ayuda a promover una cultura de seguridad al animar a los desarrolladores a participar de forma proactiva en el sitio web de SCW learning platform para mantener su competencia en materia de seguridad. A medida que los desarrolladores continúan aprendiendo y mejorando su madurez en materia de seguridad, las vulnerabilidades siguen disminuyendo en el nuevo código. Esto alivia la carga de soporte de remediación del equipo de AppSec permitiéndoles centrarse más en el fortalecimiento de la postura de seguridad general de las organizaciones.

El Secure Code Warrior Connector for Okta Workflows, junto con nuestro learning platformpuede ayudar a las organizaciones a lograr su objetivo de cambiar la seguridad a la izquierda, más rápido al elevar la competencia en seguridad de los equipos de desarrollo.

Póngase en contacto con nosotros para programar una demostración o consulte la documentación para descubrir más detalles sobre la instalación y la configuración.

‍

En Secure Code Warrior, estamos innovando constantemente para mejorar la experiencia de nuestros clientes y añadir valor a través de la plataforma.

Este mes, hemos lanzado nuevas actualizaciones de la experiencia de administración de Courses , la posibilidad de obtener acceso anticipado a las nuevas características con menos tiempo de espera, y el contenido de SAP:ABAP.

Ahora los administradores pueden gestionar más fácilmente Courses con una mejor experiencia para el usuario final, gracias a una potente vista tabular con la capacidad de realizar acciones masivas en todos los idiomas y categorías de vulnerabilidad. Además, ahora puede obtener acceso anticipado a las nuevas funciones con la ayuda de un simple interruptor de activación y desactivación.

Vamos a sumergirnos y descubrir más.

Cree y gestione courses más fácilmente con nuestra nueva experiencia de creación de Courses

Ahora puede diseñar y desplegar fácilmente Courses a través de múltiples rutas de aprendizaje e idiomas mediante acciones masivas. En lugar de dedicar tiempo a replicar el proceso, puede centrarse más en el contenido y la estrategia para ayudar a sus desarrolladores a aprender de forma más eficaz.

Actualmente, las actualizaciones del flujo de creación de Courses están disponibles para los administradores de la empresa.

Ahorre tiempo diseñando Courses con una potente vista tabular y experiencia de búsqueda

La información de los cursos en todos los idiomas y categorías de vulnerabilidad es ahora accesible en una sola vista, lo que le facilita la creación de courses para diferentes equipos de desarrollo con rapidez.

Gracias a la nueva vista tabular, puedes ver fácilmente una visión general del contenido de un vistazo o profundizar en los detalles. El contenido del curso también es más fácil de navegar ahora, ya que está agrupado por categorías de idioma y vulnerabilidad con detalles adicionales, como los tipos de actividad, la dificultad y más en cada nivel de grupo.

Incluso puedes limitar los detalles en los que te quieres centrar utilizando la función de búsqueda o aplicando filtros. Además, los datos de la tabla pueden exportarse a otra aplicación o analizarse más a fondo exportando todas las filas o las filtradas a un archivo CSV.

‍

Haga más con menos clics con las acciones masivas

Puede realizar cambios masivos en el curso desde un solo lugar en lugar de aplicar los cambios en todos los idiomas. Las acciones masivas ahorrarán tiempo a los administradores y les permitirán centrarse en lo que importa: diseñar la experiencia correcta del curso para los desarrolladores.

Las nuevas acciones a granel incluyen:

• Añadir un enfoque del curso, como el OWASP Top 10 o categorías específicas de vulnerabilidad para todos los idiomas
• Añada idiomas a un curso y actualice el contenido rápidamente
• Copiar, bloquear o desbloquear módulos para las filas seleccionadas o para todas las filas
• Eliminar idiomas o módulos del curso
• Configurar un mensaje de bienvenida y de fin de curso de una sola vez para todos los idiomas

‍

Final de curso assessment pathways

Ahora puede adaptar el final del curso assessment para cada idioma y gestionarlo desde una única vista.

Puede crear fácilmente itinerarios personalizados en assessment , basados en el idioma y el tipo de curso, para medir y evaluar las habilidades al finalizar el curso.

Obtenga acceso anticipado a las nuevas funciones

‍

En el pasado, si querías saber qué nuevas funciones iban a aparecer y probarlas antes de su disponibilidad general, tenías que hablar con tus gestores de éxito de clientes y esperar a que nuestro equipo activara las funciones para ti.

Ahora tienes el control sobre cuándo y qué función activar para tu equipo con un simple interruptor en la pestaña de Administración. Ya no es necesario esperar.

Simplemente vaya a Administración > Más > Acceso anticipado para probarlo.

Esta funcionalidad se utilizará para más funciones, especialmente aquellas que impliquen cambios significativos en la experiencia del usuario, permitiéndole controlar mejor su experiencia.

¿Tienes curiosidad por saber qué características están disponibles para el acceso anticipado? Consulta algunas de las opciones actuales:

> Una vista de la página de inicio mejorada para una experiencia más unificada

> Courses actualizaciones:

1. Modo de vista previa del estado
2. Acciones masivas sobre el contenido del curso
3. Mensaje global de bienvenida
4. Mejoras en las actividades de fin de curso

Actualmente, las opciones de Acceso Temprano están disponibles para los administradores de las empresas.

Asegure las aplicaciones ABAP con los nuevos contenidos de formación

Ahora los desarrolladores que codifican en ABAP pueden unirse a la diversión de una formación de codificación segura muy atractiva y relevante. La nueva formación ayudará a los desarrolladores a mejorar sus habilidades de codificación segura y a reducir las vulnerabilidades del código ABAP.

Con Secure Code Warrior desafíos de codificación y Missions (laboratorios prácticos), puede ofrecer un programa que cubra:

1. Formación a ritmo propio que los desarrolladores pueden disfrutar en el momento que lo necesiten
2. Vías de aprendizaje específicas que se ajustan al cumplimiento de la normativa, a los marcos de seguridad o a los niveles de competencia de los desarrolladores
3. Divertidos concursos de codificación
4. Evaluaciones seguras de las competencias de codificación

Lea más sobre nuestro contenido de formación ABAP aquí.

------

¿Estás interesado en probar Secure Code Warrior pero aún no tienes una cuenta? Regístrese para obtener una cuenta de prueba gratuita hoy mismo para empezar.

Con esto terminamos las nuevas capacidades de este mes. Sigue a Secure Code Warrior en Twitter para estar al tanto de las últimas novedades y mejoras.

¡Hoy, nos complace anunciar que el contenido de la formación SAP:ABAP está disponible en Secure Code Warrior! Puede asegurarse de que sus equipos de desarrollo de ABAP reciban el apoyo que necesitan para enviar código de calidad más rápidamente, con menos reajustes y menos vulnerabilidades mediante:

• Formación autodidacta
• Vías de aprendizaje específicas
• Divertidos concursos de codificación
• Evaluaciones seguras de las competencias de codificación
• Informes personalizados sobre los puntos fuertes y débiles de las habilidades de codificación segura

ABAP (Advanced Bía Application Programming) es el lenguaje principal para que más de 19.000 empresas codifiquen sus aplicaciones empresariales sobre las plataformas SAP. En total, estas empresas generan hasta el 87% del comercio mundial total, que asciende a 46 billones de dólares. Por lo tanto, asegurar ABAP es más importante ahora que nunca.

En Secure Code Warrior, nos esforzamos por permitir a los desarrolladores asegurar todas las aplicaciones críticas para el negocio, incluidas las escritas en lenguajes de nicho como ABAP y otras más comunes como Java.

‍

‍

Si ya eres cliente, ahora puedes acceder al contenido en Formación, Courses, y Tournaments. No dudes en hablar con tu Customer Success Manager si tienes alguna duda 🙂 .

Cómo Secure Code Warrior ayuda a asegurar las aplicaciones ABAP críticas para el negocio

Dado que ABAP es un lenguaje de nicho, rara vez se incluye en las plataformas de formación. Por eso, cuando las empresas intentan formar a sus desarrolladores, lo hacen a través de programas excesivamente caros e ineficientes, como los talleres puntuales.

Con Secure Code Warrior, obtendrá una solución de formación continua y eficaz.

Nuestro contenido de formación se entrega en el formato preferido por los desarrolladores: fragmentos de código y muestras. Así que puede estar seguro de que utilizarán y disfrutarán del contenido.

Además, con la profundidad y amplitud de nuestro contenido y sistema de aprendizaje por niveles, los desarrolladores de ABAP obtienen el apoyo continuo que necesitan para avanzar progresivamente en sus habilidades de codificación segura. Esta experiencia de aprendizaje progresivo asegura que los desarrolladores formen la memoria muscular y practiquen lo que aprenden en sus proyectos.

‍

Aprender a identificar la vulnerabilidad y los patrones de código seguro a través de desafíos de codificación

‍

Sabemos que los desarrolladores trabajan mejor en entornos con los que están familiarizados. Por eso presentamos nuestros retos de codificación en una interfaz similar a la de un editor de código.

Los desarrolladores pueden navegar a través de los archivos y las líneas de código para localizar, identificar y corregir las vulnerabilidades de ABAP en las bases de código en funcionamiento. Durante la formación, los desarrolladores aprenden a reconocer los patrones de código vulnerables y las correcciones adecuadas, lo que se traduce en una detección más temprana de la vulnerabilidad y un tiempo de corrección más rápido.

ABAP es la más reciente adición a nuestra oferta de idiomas, las mismas ventajas están disponibles para los otros 57 idiomas (y contando) que cubrimos en la plataforma.

He visto que la corrección de vulnerabilidades se produce como resultado directo del despliegue de la formación de Secure Code Warrior® porque mis desarrolladores dirán cosas como "Recuerdo que aprendí 'esto' en la formación de Secure Code Warrior®, así que estoy creando un ticket para abordar el problema de seguridad aquí".

Nicole Smith, Jefa de Seguridad, Komodo Health

Conviértase en un desarrollador experto en seguridad a través de simulaciones de inmersión en el mundo real

‍

Una vez que los desarrolladores de ABAP se familiaricen con las prácticas básicas de codificación segura. Pueden desafiarse a sí mismos para ser campeones de seguridad jugando Missions.

Missions son nuestros campos de juego simulados para que los desarrolladores exploten una vulnerabilidad específica. Al ser testigos de cómo un exploit afecta a una aplicación que funciona en tiempo real, pueden practicar habilidades de codificación segura ofensiva y llevarlas de vuelta para proteger sus proyectos.

Pruebe los retos de codificación ABAP

Con el contenido más reciente para ABAP, puede ofrecer un programa de formación progresivo para los desarrolladores de forma fácil y eficaz.

Los actuales clientes de Secure Code Warrior pueden acceder al contenido de la formación a través de Formación, Courses, Tournament, y Assessment modos de juego.

Si su equipo aún no ha adoptado nuestra solución, ¿por qué no prueba hoy mismo nuestros retos de codificación ABAP?

ABAP es uno de los muchos lenguajes disponibles

Ofrecemos contenidos de formación para otros 57 lenguajes, incluidos los más populares(Java y C++) y las estrellas emergentes(GO y Typescript). Consulta nuestra lista completa de lenguajes compatibles y prueba hoy mismo los retos de codificación en el marco que hayas elegido.

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

‍