Seguridad de Android: proteja sus compilaciones de Gradle de los malos | de Ed Holloway George | julio 2023

El origeno el origen de una dependencia se verifica a través de la firma utilizada para firmar los artefactos. Esta firma se genera mediante un par de claves públicas y privadas que utiliza el autor de la biblioteca al cargar la biblioteca en un repositorio de Maven. Para permitir que esta verificación se realice en sus compilaciones de Gradle, modifique la tarea anterior de Gradle de la siguiente manera: /gradlew –write-verification-metadata sha256,pgp someTaskNameCuando está habilitado, se agrega un conjunto de elementos clave confiables a su archivo de metadatos, que representan claves públicas confiables para dependencias específicas.< Configuration>verdaderoverdadero Estas claves públicas confiables se almacenan localmente y se prueban con los archivos de firma .asc PGP que también existen en el repositorio de Maven para la dependencia dada. Cuando la dependencia se recupera del repositorio, estos archivos y las claves asociadas se utilizan para autenticar al autor de un artefacto específico.⚠️ TENGA EN CUENTA: Aunque configurar esta verificación de suma de verificación/firma es bastante simple, debe iniciar el proceso para garantizar una seguridad absoluta. plena fe en las dependencias preexistentes que importó. Si la suma de verificación de cada dependencia no se compara primero con un valor en el que confíe, este proceso es inútil. Este proceso también se aplica a situaciones en las que actualiza la dependencia. Si bien esta no es una experiencia perfecta, si se hace correctamente, puede garantizar la integridad de sus dependencias. La documentación de Gradle sobre la comprobación de dependencias detalla estos dos métodos. Es un excelente lugar para obtener mucha más información sobre cómo asegurar sus dependencias, ¡y una lectura obligada para cualquier desarrollador preocupado por la seguridad! 😎

Filtrado de repositorios

Otro enfoque para usar las dependencias de manera más segura es usar el filtrado del repositorio. Este es el proceso de crear reglas de permitir/denegar para repositorios específicos en torno a las dependencias a las que pueden llamar. Las API disponibles para esto brindan a los desarrolladores mucha libertad para crear reglas simples o más complejas y se pueden implementar con relativa facilidad modificando su bloque de repositorio existente. En el siguiente ejemplo, permitimos que todas las dependencias con el grupo com.example y la dependencia específica com.example:foo se recuperen de JitPack mientras excluimos todas las dependencias de dev.spght.*³repositories {maven {url «https://jitpack.io»content {// F etch dependenciesincludeGroup «com.example»includeModule(«com.example», «foo»)// Exclude dependenciesexcludeGroup ByRegex(«dev\\.spght\\..*»)}}}Al definir sus reglas correctamente (es decir, de forma mutuamente excluyente), puede garantizar completamente que las dependencias se descargarán de la fuente deseada. Sin embargo, cabe señalar que, si bien esto puede conducir a un cierto nivel de confianza, este enfoque no no verifica que las propias dependencias sean legítimas como la suma de verificación o los controles de firma discutidos anteriormente. Por lo tanto, asegúrese de considerar usar el filtrado de repositorios en combinación con otros métodos. 🙏

Revisión de la envoltura de Gradle

Gradle Wrapper es una herramienta que usamos a menudo y sin pensar. Para la mayoría de nosotros, el script de Gradlew en nuestros proyectos es generalmente el punto de entrada que usamos para realizar ciertas tareas relacionadas con nuestros proyectos, tales como: B. ejecutar pruebas, crear artefactos y todo lo demás. Es posible que no le prestemos atención, pero detrás de escena, el Wrapper juega un papel importante para garantizar que la «versión correcta» de Gradle se descargue y se ejecute para su proyecto. Parte de este proceso es ejecutar gradle-wrapper.jar , un ejecutable de Java que probablemente se registrará en su control de versiones. Dado que este archivo se ejecuta con frecuencia, ciertamente representa un riesgo potencial para la seguridad si se modifica con malas intenciones. De hecho, a fines de 2022, se observó por primera vez un ataque a la cadena de suministro dirigido al archivo Wrapper .jar dentro de la base de código de un servidor de Minecraft increíblemente popular. Un complemento malicioso de Minecraft, junto con el contenedor JAR ejecutable, era responsable de acceder a los datos del usuario y otorgar a ciertos usuarios acceso de administrador/raíz al juego, así como a la pila de tecnología subyacente utilizada para la implementación. Con esto en mente, Gradle ha lanzado una acción de GitHub que se puede usar como parte de su canalización de compilación para verificar que el JAR de Wrapper sea legítimo. Utiliza las sumas de verificación de contenedor conocidas para garantizar que el contenedor no haya sido manipulado y también es lo suficientemente inteligente como para verificar archivos llamados gradle-wrapper.jar con variantes de homoglifos (es decir, cuando un atacante usa un carácter Unicode similar a un carácter ASCII para engañar a los desarrolladores para que usen el archivo incorrecto). Sin embargo, si no está usando GitHub para CI y necesita una solución que pueda ejecutar tanto de forma local como remota, también he creado un script simple para verificar los JARS del contenedor. Desafortunadamente, no existe una solución oficial para verificar el script de Gradlew, sin embargo, hay un problema de GitHub como una solicitud de función. Podría valer la pena vigilar… 👀

Comprobando la distribución de Gradle

Finalmente, también es posible verificar la distribución real de Gradle que está descargando el contenedor. Es posible que haya visto la propiedad distributionUrl en su archivo $PROJ_ROOT/gradle/wrapper/gradle-wrapper.properties, que contiene la URL de la distribución de Gradle para obtener. Sin embargo, ¿cómo podemos garantizar que lo que se descarga es legítimo? Agregar una propiedad DistributionSha256Sum a este archivo con una suma de verificación SHA256 comparará la suma de verificación de este archivo con la cadena en la propiedad proporcionada cuando se descargue la distribución. Estas sumas de verificación de distribución son conocidas y, por lo tanto, se pueden agregar fácilmente a su proyecto. También es posible agregar dinámicamente la propiedad distributionSha256Sum cuando actualiza su contenedor de Gradle mediante el indicador gradle-distribution-sha256-sum./gradlew wrapper –gradle-version=7.5 \–gradle-distribution-sha256-sum=cb87f222c… Si descarga algo que no coincide con la suma de verificación de distribuciónSha256Sum de su compilación, fallará y podrá iniciar la investigación. Nunca se sabe, ¡quizás algún día esto te salve! Uf, eso es todo. Gracias por seguir hasta el final 😅 En resumen, aunque un ataque a la cadena de suministro en sus herramientas de Gradle no es tan común como otras formas de ataque, sigue siendo un vector de ataque viable que ha demostrado ser común. Los mecanismos proporcionados por Gradle para prevenir tales ataques son lo suficientemente simples como para integrarse en cualquier proyecto con relativa rapidez. Crucemos los dedos, esta publicación lo ayudará a tomar una decisión más informada y tal vez considere agregar uno o más de estos a su proyecto. Para obtener más información, consulte spght.dev/talks y mi charla «How to Stop the Gradle Snatchers: Protect Your Builds from Bad Guys» en Droidcon. ¡Mantente a salvo ahí fuera! 💪 Como siempre, ¡gracias por leer! Espero que hayas encontrado esta publicación interesante. Comuníquese conmigo para recibir comentarios en @Sp4ghettiCode y no olvide aplaudir, dar me gusta, compartir, etiquetar, etc.