Una alarmante técnica de ataque a la cadena de suministro de software permite a los hackers engañar a los desarrolladores para que utilicen código potencialmente malicioso.
Al aprovechar la capacidad de suplantar y falsificar los metadatos de las confirmaciones en GitHub, un atacante puede engañar a los usuarios y atraerlos para que usen repositorios envenenados.
Justo ahora es un buen momento para verificar que, sin saberlo, eres colaborador en un repositorio sospechoso o si estás utilizando el código de un usuario que no es tan confiable como crees.
INTRODUCCIÓN
Es más probable que los desarrolladores que buscan un proyecto de código abierto elijan uno que esté activo y con mantenimiento, y es más probable que confíen en los desarrolladores veteranos con un historial de actividad en los últimos años. GitHub facilita la evaluación al proporcionar gran parte de estos metadatos. Desafortunadamente, algunos de estos puntos de datos se pueden falsificar fácilmente.
DETALLES
Uno de los componentes básicos del sistema de control de versiones de Git son las confirmaciones. La documentación de GitHub describe las confirmaciones de la siguiente manera:
Como esto señala, además de los datos en sí, que son los cambios en el código, las confirmaciones también incluyen metadatos. Estos metadatos vienen en forma de marca de tiempo y la identidad del creador. El tema es que ambos se pueden falsificar.
FECHA DE COMISIÓN FALSIFICADA
Como se mencionó, cada confirmación en GitHub se adjunta con su propia marca de tiempo que indica cuándo se confirmó. Sin embargo, esta marca de tiempo se puede manipular fácilmente, lo que significa que podemos hacer que las confirmaciones parezcan realizadas en un momento diferente al momento en que realmente se confirmaron. Para lograr eso, todo lo que tenemos que hacer es alterar dos variables de entorno en la máquina local con el comando "git set".
Confirmar algunos cambios con estas variables de entorno y enviarlos a GitHub dará como resultado lo siguiente:
En este ejemplo, vale la pena mencionar que la marca de tiempo falsa es anterior a la creación tanto del usuario que la envió como del repositorio con el que se comprometió.
¿QUÉ PODEMOS HACER CON ESTO?
Debido a esta falta de verificación de las marcas de tiempo, un usuario malintencionado puede parecer creíble al hacer que parezca que ha estado extremadamente activo durante mucho tiempo.
Una medida destacada de la actividad del usu<ario en GitHub es el gráfico de actividad" que se presenta en la página de perfil del usuario. Este gráfico es esencialmente un mapa de calor que muestra la actividad del usuario a lo largo del tiempo. Por lo tanto, si podemos fabricar compromisos con cualquier marca de tiempo que queramos, podemos llenar este gráfico con actividades falsificadas.
Si continuamos con nuestro ejemplo anterior, fake commit en abril de 2010, podemos ver que el gráfico de actividad es el siguiente
:
En este punto, no hay nada que nos impida generar automáticamente compromisos falsos y llenar nuestro gráfico de 2010 para que se vea como queramos.
Dado que el gráfico de actividad muestra la actividad en repositorios públicos y privados, es imposible desacreditar estas confirmaciones falsas y, por lo tanto, esta técnica engañosa también puede ser difícil de detectar.
AGREGAR COLABORADORES FALSIFICADOS
De manera similar, también es posible falsificar la identidad del autor de la confirmación y atribuir una confirmación a una cuenta de usuario real existente en GitHub. Por ejemplo, podríamos usar la reputación de uno de los principales contribuyentes en GitHub y enviar una confirmación en su nombre.
La suplantación de compromisos para que parezca que los hizo cualquier usuario que elijamos es relativamente simple:
1 - Averigüe la dirección de correo electrónico del usuario
Aunque GitHub ofrece formas de evitar que el correo electrónico de un usuario quede expuesto, requieren que el desarrollador opte por estas funciones y, en su mayoría, no se utilizan. Para averiguar el correo electrónico del usuario, podemos seguir manualmente los pasos a continuación o incluso automatizarlos.
Buscando una confirmación auténtica del usuario siguiendo este patrón de URL: <a href="https://github.com/<username>/<repo_name>/commit/https://github.com/<username>/<repo_name>/commit/<commit_hash>
Agregando la cadena ".patch" al final de la URL, así:
<ahref="https://github.com/<username>/<repo_name>/commit/https://github.com/<username>/<repo_name>/commit/<commit_hash>.patch
Buscando esta dirección arrojará un resultado similar al que se muestra a continuación, que incluirá la dirección de correo electrónico del usuario.
2 - Configurando el nombre de usuario y el correo electrónico en git CLI
3 - Confirmar cambios
¿QUÉ PODEMOS HACER CON ESTO?
Como lo mostró Aqua hace unas semanas, el administrador de paquetes de NPM permitió a los propietarios de paquetes agregar a su paquete cualquier colaborador que quisieran y, al hacerlo, mejorar la reputación y credibilidad de su proyecto.
Al falsificar la identidad del autor de la confirmación, esto también se puede hacer para los repositorios de GitHub. Para hacer que su proyecto parezca confiable, los atacantes pueden usar esta técnica una o varias veces y llenar la sección de colaboradores de su repositorio con colaboradores confiables conocidos, lo que a su vez hace que el proyecto parezca confiable.
Lo que hace que esta suplantación de identidad sea aún más alarmante es el hecho de que el usuario que está siendo falsificado no recibe una notificación y no sabrá que se está utilizando su nombre.
COMISIONES VERIFICADAS
Para mitigar el riesgo de contribuyentes falsificados descrito anteriormente, GitHub introdujo "Commit Signature Verification". Esta función permite a los usuarios firmar criptográficamente sus compromisos para que su contribución pueda verificarse como propia y no como un impostor. Sin embargo, esta función sólo verifica las firmas en sí y no su existencia. Si no se firma una confirmación, no se marcará de ninguna manera.
Para aumentar la efectividad de esta característica en la alerta de confirmaciones no verificadas, es posible habilitar el "modo vigilante" que mostrará el estado de verificación de todas sus confirmaciones, incluidas las que no se firmaron en absoluto. De esta manera, es más fácil detectar intentos de esta suplantación.
CONCLUSIÓN
En este blog, el equipo de Checkmarx SCS detalló dos formas en que los actores de amenazas pueden aprovechar las características de GitHub para engañar a los desarrolladores para que usen repositorios con código potencialmente malicioso.
Los metadatos en GitHub ayudan a los desarrolladores a tomar decisiones sobre el uso de ciertos repositorios.
Por lo tanto, los metadatos falsos pueden engañar a los desarrolladores para que usen código que no habrían usado a sabiendas y pueden incluir código malicioso.
La falta de validación de la identidad del autor de la confirmación y la marca de tiempo de la confirmación es un problema en sí mismo, pero también permite que los actores malintencionados la aprovechen para ganar credibilidad ante sus usuarios y repositorios.
GitHub ofrece una solución para verificar la identidad de los autores, pero requiere la participación activa de los desarrolladores y puede ampliarse para incluir más medidas de protección.
Alentamos a los desarrolladores a firmar sus compromisos y habilitar el modo vigilante en su usuario, pasos que ayudarán a que el ecosistema sea seguro.
Acerca del autor
AVIAD GERSHON
Aviad es un ingeniero de investigación experimentado en Checkmarx y tiene una pasión por la ciencia detrás del aprendizaje automático y el aprendizaje profundo. Antes de Checkmarx, fue investigador de seguridad en Dustico, analista de amenazas cibernéticas en el CERT nacional israelí y fundador de Synolo, una aplicación basada en el aprendizaje profundo para ayudar a los acuicultores. Aviad es voluntario de un campamento de verano y tiene un B.Sc. en Física y Filosofía de la Universidad Hebrea.
COMISIONES NO VERIFICADAS: ¿ESTÁS CONFIANDO EN EL CÓDIGO DE HACKERS SIN SABERLO?
Una alarmante técnica de ataque a la cadena de suministro de software permite a los hackers engañar a los desarrolladores para que utilicen código potencialmente malicioso.
Al aprovechar la capacidad de suplantar y falsificar los metadatos de las confirmaciones en GitHub, un atacante puede engañar a los usuarios y atraerlos para que usen repositorios envenenados.
Justo ahora es un buen momento para verificar que, sin saberlo, eres colaborador en un repositorio sospechoso o si estás utilizando el código de un usuario que no es tan confiable como crees.
INTRODUCCIÓN
Es más probable que los desarrolladores que buscan un proyecto de código abierto elijan uno que esté activo y con mantenimiento, y es más probable que confíen en los desarrolladores veteranos con un historial de actividad en los últimos años. GitHub facilita la evaluación al proporcionar gran parte de estos metadatos. Desafortunadamente, algunos de estos puntos de datos se pueden falsificar fácilmente.
DETALLES
Uno de los componentes básicos del sistema de control de versiones de Git son las confirmaciones. La documentación de GitHub describe las confirmaciones de la siguiente manera:
Como esto señala, además de los datos en sí, que son los cambios en el código, las confirmaciones también incluyen metadatos. Estos metadatos vienen en forma de marca de tiempo y la identidad del creador. El tema es que ambos se pueden falsificar.
FECHA DE COMISIÓN FALSIFICADA
Como se mencionó, cada confirmación en GitHub se adjunta con su propia marca de tiempo que indica cuándo se confirmó. Sin embargo, esta marca de tiempo se puede manipular fácilmente, lo que significa que podemos hacer que las confirmaciones parezcan realizadas en un momento diferente al momento en que realmente se confirmaron. Para lograr eso, todo lo que tenemos que hacer es alterar dos variables de entorno en la máquina local con el comando "git set".
Confirmar algunos cambios con estas variables de entorno y enviarlos a GitHub dará como resultado lo siguiente:
En este ejemplo, vale la pena mencionar que la marca de tiempo falsa es anterior a la creación tanto del usuario que la envió como del repositorio con el que se comprometió.
¿QUÉ PODEMOS HACER CON ESTO?
Debido a esta falta de verificación de las marcas de tiempo, un usuario malintencionado puede parecer creíble al hacer que parezca que ha estado extremadamente activo durante mucho tiempo.
Una medida destacada de la actividad del usu<ario en GitHub es el gráfico de actividad" que se presenta en la página de perfil del usuario. Este gráfico es esencialmente un mapa de calor que muestra la actividad del usuario a lo largo del tiempo. Por lo tanto, si podemos fabricar compromisos con cualquier marca de tiempo que queramos, podemos llenar este gráfico con actividades falsificadas.
Si continuamos con nuestro ejemplo anterior, fake commit en abril de 2010, podemos ver que el gráfico de actividad es el siguiente
:
En este punto, no hay nada que nos impida generar automáticamente compromisos falsos y llenar nuestro gráfico de 2010 para que se vea como queramos.
Dado que el gráfico de actividad muestra la actividad en repositorios públicos y privados, es imposible desacreditar estas confirmaciones falsas y, por lo tanto, esta técnica engañosa también puede ser difícil de detectar.
AGREGAR COLABORADORES FALSIFICADOS
De manera similar, también es posible falsificar la identidad del autor de la confirmación y atribuir una confirmación a una cuenta de usuario real existente en GitHub. Por ejemplo, podríamos usar la reputación de uno de los principales contribuyentes en GitHub y enviar una confirmación en su nombre.
La suplantación de compromisos para que parezca que los hizo cualquier usuario que elijamos es relativamente simple:
1 - Averigüe la dirección de correo electrónico del usuario
Aunque GitHub ofrece formas de evitar que el correo electrónico de un usuario quede expuesto, requieren que el desarrollador opte por estas funciones y, en su mayoría, no se utilizan. Para averiguar el correo electrónico del usuario, podemos seguir manualmente los pasos a continuación o incluso automatizarlos.
Buscando una confirmación auténtica del usuario siguiendo este patrón de URL: <a href="https://github.com/<username>/<repo_name>/commit/https://github.com/<username>/<repo_name>/commit/<commit_hash>
Agregando la cadena ".patch" al final de la URL, así:
<ahref="https://github.com/<username>/<repo_name>/commit/https://github.com/<username>/<repo_name>/commit/<commit_hash>.patch
Buscando esta dirección arrojará un resultado similar al que se muestra a continuación, que incluirá la dirección de correo electrónico del usuario.
2 - Configurando el nombre de usuario y el correo electrónico en git CLI
3 - Confirmar cambios
¿QUÉ PODEMOS HACER CON ESTO?
Como lo mostró Aqua hace unas semanas, el administrador de paquetes de NPM permitió a los propietarios de paquetes agregar a su paquete cualquier colaborador que quisieran y, al hacerlo, mejorar la reputación y credibilidad de su proyecto.
Al falsificar la identidad del autor de la confirmación, esto también se puede hacer para los repositorios de GitHub. Para hacer que su proyecto parezca confiable, los atacantes pueden usar esta técnica una o varias veces y llenar la sección de colaboradores de su repositorio con colaboradores confiables conocidos, lo que a su vez hace que el proyecto parezca confiable.
Lo que hace que esta suplantación de identidad sea aún más alarmante es el hecho de que el usuario que está siendo falsificado no recibe una notificación y no sabrá que se está utilizando su nombre.
COMISIONES VERIFICADAS
Para mitigar el riesgo de contribuyentes falsificados descrito anteriormente, GitHub introdujo "Commit Signature Verification". Esta función permite a los usuarios firmar criptográficamente sus compromisos para que su contribución pueda verificarse como propia y no como un impostor. Sin embargo, esta función sólo verifica las firmas en sí y no su existencia. Si no se firma una confirmación, no se marcará de ninguna manera.
Para aumentar la efectividad de esta característica en la alerta de confirmaciones no verificadas, es posible habilitar el "modo vigilante" que mostrará el estado de verificación de todas sus confirmaciones, incluidas las que no se firmaron en absoluto. De esta manera, es más fácil detectar intentos de esta suplantación.
CONCLUSIÓN
En este blog, el equipo de Checkmarx SCS detalló dos formas en que los actores de amenazas pueden aprovechar las características de GitHub para engañar a los desarrolladores para que usen repositorios con código potencialmente malicioso.
Los metadatos en GitHub ayudan a los desarrolladores a tomar decisiones sobre el uso de ciertos repositorios.
Por lo tanto, los metadatos falsos pueden engañar a los desarrolladores para que usen código que no habrían usado a sabiendas y pueden incluir código malicioso.
La falta de validación de la identidad del autor de la confirmación y la marca de tiempo de la confirmación es un problema en sí mismo, pero también permite que los actores malintencionados la aprovechen para ganar credibilidad ante sus usuarios y repositorios.
GitHub ofrece una solución para verificar la identidad de los autores, pero requiere la participación activa de los desarrolladores y puede ampliarse para incluir más medidas de protección.
Alentamos a los desarrolladores a firmar sus compromisos y habilitar el modo vigilante en su usuario, pasos que ayudarán a que el ecosistema sea seguro.
Acerca del autor
AVIAD GERSHON
Aviad es un ingeniero de investigación experimentado en Checkmarx y tiene una pasión por la ciencia detrás del aprendizaje automático y el aprendizaje profundo. Antes de Checkmarx, fue investigador de seguridad en Dustico, analista de amenazas cibernéticas en el CERT nacional israelí y fundador de Synolo, una aplicación basada en el aprendizaje profundo para ayudar a los acuicultores. Aviad es voluntario de un campamento de verano y tiene un B.Sc. en Física y Filosofía de la Universidad Hebrea.
