Na nosa publicación anterior sobre CI/CD Pipelines, nós vimos como piratear un CI/CD escenario que presuntamente estaba protexido.
Lembremos o noso punto na publicación anterior: comezamos con algúns pipeline que era vulnerable a Envelenado indirectamente Pipeline Execución (I-PPE) e, para solucionalo, decidimos dividir o pipeline en dous:
- O 1o pipeline (Compilación de CI), segura para D-PPE e I-PPE, revisaría o código PR, faría a compilación e xeraría un artefacto.
- O 2nd pipeline (CI de proba), tamén seguro para D-PPE e I-PPE revisaría o código base (para evitar a modificación do script do shell) e executaría os scripts orixinais contra o artefacto.
- Para sincronizar o CI de proba pipeline para executar DESPOIS do CI de compilación pipeline, usamos execución_do_fluxo_de_traballo gatillo.
Chamámoslle a isto Escenario nº 3.
Aínda que, como mencionamos nesa publicación, existen outras solucións, decidimos implementar esta "solución" por razóns pedagóxicas, para poder afondar nas vulnerabilidades de CI/CD pipelines.
Despois, vimos como piratear este escenario mediante envelenando o artefactoIsto é o que chamamos Envelenamento por artefactos, é dicir, a capacidade de modificar (piratear) o pipeline lóxica mediante a modificación dunha pipeline artefacto.
Cal é o problema con esta estratexia? Vimos que o problema xorde cando calquera usuario «crea» un novo pipeline.
Se un usuario abre unha PR que contén un novo pipeline, GitHub executará iso pipeline (dados algúns termos, como vimos) na publicación).
O usuario pode entón crear un novo pipeline co mesmo nome que Build CI!! Si, é sorprendente, pero GitHub permíteche crear dous pipelines co mesmo nome!!
Cando o usuario abre unha PR con estes cambios, o "novo" pipeline executarase (subindo un artefacto envelenado) e o CI de implementación pipeline executarase despois diso, o que resultará en que o script de shell "modificado" sobrescriba o script de shell "orixinal" situado no pipeline espazo de traballo. Polo tanto, esta «solución» non evita a vulnerabilidade I-PPE (como podemos ver a continuación)
Cales son os problemas? Polo menos, hai un par de cuestións:
- En primeiro lugar, Como asegurarse de que o proceso de construción non foi manipulado? Neste escenario, o usuario malicioso puido modificar o proceso de compilación previsto usando o seu pipeline para crear un artefacto envelenado.
- En segundo lugar, Como podemos avaliar a procedencia dun artefacto?
Estas preguntas lánzanos aos brazos do Certificacións de software dominio!!
Certificacións de software
An certificación é unha peza de datos representando proba dun eventoNo mundo real, xeralmente chamámoslles a estes certificacións.
Por exemplo, cando un laboratorio analiza o teu sangue, os datos sobre a proba rexístranse e certifícanse. Os resultados da análise de sangue son verificable rastrexable.
Máis preto do noso dominio das TI, poderías adiviñar cal sería unha tradución deste proceso, por exemplo, a un proceso de compilación.
A información sobre o entorno e as ferramentas do servidor de compilación, os materiais (o código fonte) e os produtos/artefactos (o código binario) formarían parte desa atestación.
Obviamente, a atestación debe ser xerada por un atestador autorizado (autenticado e non repudiable) para proporcionar credibilidade.
Probablemente, algúns de vostedes estean pensando... e cal é o diferenza entre sinaturas e atestacións?
Sinaturas de código e certificados
A un alto nivel, unha sinatura créase usando un par de chaves e un artefacto. O par de chaves consta dunha chave pública e unha chave privada.
O usuario asina un artefacto usando a clave privada e outros poden verificar a sinatura usando a clave pública. A clave privada debe manterse en segredo, pero a clave pública distribúese amplamente.
As sinaturas pódense usar para demostrar que o titular da clave privada a usou para asinar o artefacto.
Sinaturas non probes
- O usuario intención para asinar o artefacto (poderían ter sido enganados), ou
- A intención do usuario de realizar calquera afirmación específica sobre o artefacto
con Atestados, en lugar de asinar un artefacto directamente, os usuarios crean algún tipo de documento Que capta a súa intención detrás de asinar o artefacto e calquera reclamacións específicas que se realiza como parte desta sinatura.
Marco de atestación integral
O marco máis común é o Marco de atestación integral
- define un standard formato para as certificacións que vinculan os suxeitos, os artefactos que se describen, a metadatos autenticados sobre o artefacto
- proporciona un conxunto de predicados predefinidos para comunicar metadatos autenticados en todas as cadeas de subministración de software
Vexamos algúns detalles sobre o formato de atestación.
An Atestado é un documento asinado dixitalmente que contén Declaracións.
o Afirmación é a capa intermedia da atestación, vinculándoa a un determinado tema e identificando inequivocamente os tipos de Predicado:
- tema: A referencia criptograficamente segura ao artefacto (xeralmente mediante un hash) e
- Predicados: un conxunto específico reivindicacións sobre ese artefacto denomínase Declaración. Estas afirmacións pódense usar para expresar (e despois probar) calquera cousa que se che ocorra! Poden representar a aprobación manual, a procedencia do artefacto, os resultados de probas automatizadas, unha pista de auditoría ou moito máis!
Cando esta declaración está asinada criptograficamente, denomínase Atestado
Deste xeito, por exemplo, Alicia crea unha declaración sobre un artefacto e asínaa coa súa clave privada, creando unha atestación.
- Bob pode entón verificar a sinatura nesa atestación, permitíndolle confiar nas afirmacións dentro.
Bob pode entón usar esas afirmacións decidir se se permite ou non o uso deste artefacto.
Poderían as atestacións axudar a resolver o envelenamento por artefactos?
Despois desta introdución ás atestacións, volvamos ao noso problema. Como poden axudarnos as atestacións a resolver o noso problema, é dicir, a evitar o envelenamento por artefactos?
O usuario malicioso foi capaz de crear un artefacto eludindo o mecanismo "oficial", é dicir, usando o seu pipeline para xerar o artefacto.
Sería incrible se puidésemos demostrar que os artefactos que se están descargando foron construídos coa licenza oficial pipelines. Este é só un exemplo do que poderiamos chamar «puntos de manipulación», pero podería haber moitos outros.
Como se pode ver na imaxe superior, os puntos de manipulación son múltiples. Deste xeito, o consumidor pipeline (A proba de CI no noso exemplo) debe avaliar o integridade do proceso de construción así como o integridade do propio artefacto.
No noso exemplo, o artefacto envelenado foi creado introducindo un novo artefacto (envelenado) pipeline que altera o proceso de compilación. Pero o usuario malicioso podería ter sido capaz de:
- modificar o código despois de ser retirado do SCM para xerar un binario malicioso
- substituír o binario correcto producido pola compilación por calquera outro binario malicioso
- comprometer o Rexistro de Artefactos e subir un artefacto envelenado construído doutro xeito
- etc.
Como podes ver, pode haber varios puntos de "manipulación".
Que é importante aquí? Obviamente, para protexer todos eses puntos de "manipulación". Pero, ao final, o máis importante é que o "consumidor" do artefacto poida avaliar a integridade do artefacto e decidir se segue adiante ou non con el.
Podemos avaliar a integridade dun artefacto de dous xeitos.
Unha delas é avaliando o orixe do artefacto.
Ao xerar un Declaración de procedencia, proporcionamos metadatos útiles (debidamente autenticados e non repudiados) sobre o artefacto. Nos seguintes exemplos, empregaremos Sal de xixénico (Capa de atestacións de software para a confianza), o compoñente para xerar, rexistrar e verificar atestacións de software.
No código anterior, podes ver que hai un paso que constrúe o ficheiro war e un segundo paso que xera o Declaración de procedenciaPara facelo, o pipeline usa a clave privada e tamén inclúe a clave pública na atestación.
Nos bastidores, Xygeni's sal O comando almacena a atestación nun libro de libros (tamén coñecido como rexistro de atestacións, rexistro no noso caso, pero podes usar calquera outro). Feito isto, o consumidor pipeline pode incluír Xygeni Motor de verificación para verificar a procedencia do artefacto e avaliar a súa integridade.
O proceso de verificación avalía:
- o O artefacto sha256sum é válido (é dicir, existe unha atestación sobre ese «asunto»), e
- o a atestación está debidamente autenticada (xerouse usando a clave privada axeitada)
Este proceso de verificación pode avaliar entón que tanto o artefacto como a atestación sexan válidos.
Pero, como lembrarás, no noso caso, o artefacto foi xerado por un "malicioso" pipeline (é dicir, non o orixinal por unha modificación pipeline). Entón debemos seguir adiante e comprobar outro aspecto: que o artefacto foi xerado polo "orixinal" pipeline, non calquera outra.
Para facelo, só tes que incluír unha liña sinxela para comprobar esa condición, por exemplo:
Esta comprobación adicional fallará se o artefacto non fose xerado pola nosa "segura" pipeline.
Se o artefacto foi xerado polo noso orixinal pipeline (cicd_top10_3_salt/.github/workflows/build.yml), o comando grep terá éxito; se non, fallará, rompendo o pipeline e abortando calquera paso posterior.
O "construtor" pipeline é só un punto de manipulación para comprobar pero, como se mencionou anteriormente, hai outros puntos de manipulación que deberiamos comprobar.
Por exemplo, a Que ocorre se o código fonte foi manipulado despois da comprobación do repositorio e antes do comando de compilación? Neste caso, o código a construír non é o mesmo que o almacenado no SCM.
Comprobar este punto de manipulación é tan sinxelo como comprobar os hashes do material en cada paso.
Conclusións
En resumo, unha Atestación de software é unha aserción feita sobre un anaco de software, é dicir, unha declaración autenticada (metadatos) sobre un artefacto de software ou unha colección de artefactos de software.
As atestacións de software son unha xeneralización da sinatura de código/artefactos brutos. A atestación é un documento asinado (nun formato determinado, normalmente baseado en JSON) que asocia metadatos cun artefacto. Representan evidencias que vinculan as entradas (materiais) e as saídas (artefactos producidos) en cada paso de compilación.
As atestacións proporcionan un rexistro verificable dos pasos realizados para construír os artefactos de software finais, incluíndo os materiais de entrada para cada paso e os comandos de construción executados.
En conclusión, as atestacións de software son un gran mecanismo para comprobar moitos aspectos de integridade diferentes do noso proceso de compilación.
Remataches a serie? Non te preocupes! Podes volver a 'Envelenado Pipeline Execución (EPI)' ou calquera outra publicación que esperte de novo o teu interese!
Estade atentos, afondaremos nas certificacións de software e build security en futuras entradas do blog.
