Què pot anar malament amb CI/CD pipelines?

Integració contínua i lliurament continu (CI/CD) pipelineEls sistemes són la base de qualsevol organització de programari que crea programari de manera "moderna". L'automatització proporciona un gran poder, però la majoria dels desenvolupadors no s'adonen de la responsabilitat que comporta.

ReveladorSí, prenem CI/CD seguretat seriosament i tenir un fort control sobre els mantenidors del codi, revisar commits abans de les fusions; treballs i pipelinesón mantinguts per personal sènior, que s'ocupen de no filtrar secrets a la pipelines. I l'eina va ser instal·lada per personal que en sap del tema. Què pot sortir malament?

Benvolgut desenvolupador, CI/CD els sistemes són complexos. La seva àmplia superfície d'atac va atreure actors malignes. Millor ser cautelós i no confiar mai massa.

La configuració predeterminada de vegades es manté i esdevé la millor amiga dels pirates informàtics. Hi poden haver defectes crítics a CI/CD pipeline fonts, en la configuració del sistema o al voltant del procés i el context del pipeline i com es desencadena.

En aquesta publicació ens posarem en la pell dels mals actors. Imagineu-vos que estiguéssim llegint les reflexions de M3M3N70 (Memento Mori?) i Fúria del Pantà en algun lloc de la dark web, probablement en un idioma no occidental, però mai no us perdeu que el mal s'estén per tot el món.

En els bons vells temps era tan fàcil…

M3M3N70Tornant als vells temps, el nostre negoci era taaaan fàcil... Els zero-day eren fàcils d'aconseguir, les aplicacions eren molt obertes amb vulnerabilitats fàcils d'explotar i podíem moure'ns lateralment en un tres i no res.

Fúria del PantàMerda! Alguns són uns idiotes, però les coses han canviat. Els grans s'han endut molta ànima per aquesta merda d'AppSec.

M3M3N70Sí. Però els nous ximples són els desenvolupadors. Per a nosaltres, ha estat més fàcil optar per les eines que fan servir aquests nois. La CI, en particular, és una mina d'or! Tokens d'accés al núvol, SCM credencials, contrasenyes de la base de dades de producció, claus privades SSH, credencials d'altres usuaris de CI... Saltar de les coses avorrides del desenvolupament a la part real va ser força trivial.

Automatització per a la construcció, prova i desplegament de programari amb un CI/CD L'eina sovint necessita passar secrets a les ordres per passos. I sovint es filtren, amb conseqüències infames.

Pipelinenecessiten secrets que de vegades es filtren

M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.

Potser els bons vells temps eren trobar a la història de Git un .env fitxer (el desenvolupador s'ha oblidat d'afegir-lo a .gitignore):

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=wJalrXUtn...
AWS_REGION=us-east-1
APP_FOLDER=...
S3BUCKET=...

que s'ha utilitzat en un flux de treball de GitHub .github/deploy.yaml que contenia alguna cosa semblant a això:

jobs:
  build:
    name: Automated build and deployment into AWS
    runs-on: 	ubuntu-22.04
    steps:
      # Load environment from .env file
      - id: dotenv
        uses: falti/dotenv-action@v1.0.2
        
      - name: Configure AWS Credentials
        uses:
        with:
          args: --acl public-read --follow-symlinks --delete 
          aws-access-key-id: $
          aws-secret-access-key: $
          aws-region: $
      
      # ... build steps skipped ...
      
      -  name: Upload compiled code for deployment
         working-directory: $/packaged_app
         run: aws s3 cp my-app.zip s3://$ 
         
      - name: Deploy the app
        run: aws deploy create-deployment ...

M3M3N70: ostres! Aquestes claus d'AWS funcionaven! Primer vam provar un canvi inofensiu a l'aplicació i després vam afegir la pressió, ja que semblava que no se n'adonaven. Bingo! Quina campanya...

El malfactor simplement va utilitzar les claus d'AWS per carregar una aplicació modificada amb programari maliciós i després va executar l'ordre de desplegament amb aquestes credencials. Els secrets filtrats, juntament amb la informació continguda a la pipeline«Quina campanya!» probablement vol dir que Memento va causar estralls a la pobra víctima.

El que ens diu Memento aquí és que un cop es produeix una filtració secreta, com les claus d'accés d'AWS a l'exemple, cal revocar el secret (girar les claus anteriors) immediatamentSempre hi ha un finestra d'exposició entre les fuites commit i la invalidació secreta; Reescriure l'historial de Git és difícil (fins i tot l'estat autoritari més dur va intentar aquesta reescriptura de la història, sense èxit) i probablement ineficaç (els nostres amics podrien haver clonat abans del repositori amb la filtració secreta commit). Gireu les claus immediatament i pregueu mentre llegiu els registres d'activitat del compte objectiu durant la finestra d'exposició!

Probablement les organitzacions haurien de prohibir l'ús de secrets a llarg termini CI/CD pipelines, i substituïu-les per credencials temporals. A l'exemple anterior amb claus d'AWS a les accions de GitHub, és més segur utilitzar un Proveïdor d'OpenID Connect (OIDC) per obtenir credencials de curta durada necessàries per a les accions.

Fúria del PantàHas tingut molta sort! Filtrar scripts amb claus codificades era una pràctica habitual antigament, fins i tot en contenidors S3 d'accés públic. Només calia recórrer els objectes del contenidor i fer grepping per trobar coses interessants.

De vegades, l'àrea utilitzada per a la implementació (un cub d'AWS S3 en aquest exemple) estava oberta per a la lectura per part de persones externes, a causa d'un defecte de configuració (que no es va detectar). Què Fúria del Pantà utilitzat era alguna cosa així:

aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
  aws s3 cp s3://<bucket_name>/FNAME - | \
  grep '<regex_pattern>'"

El cub probablement es va crear en una plantilla de provisionament que es podia escanejar automàticament per detectar errors de seguretat.

La configuració per defecte de l'eina era una joguina per a nosaltres

Per donar exemples concrets, parlem de Jenkins, una de les eines de CI més populars.

Fúria del Pantà: Recordes aquella casella de selecció "Activa la seguretat" a Jenkins i quantes organitzacions van triar no activar-la per comoditat? I aquelles "Qualsevol pot fer qualsevol cosa"combinacions de permisos per defecte? I aquells molestos complements de Jenkins, com ara Complement OAuth de GitHubEl tècnic que ho va configurar va seleccionar tant "Atorga permisos de READ a tots els usuaris autenticats" com "Utilitza permisos de repositori de GitHub", donant-nos accés a tots els seus projectes.

(Disculpa, Jenkins, per posar-te com a exemple 😉)

Mantingueu-vos adeptes (fins i tot addictes) als principis de seguretat. Un és el Segur per defecte principi: els controls han d'utilitzar per defecte la configuració més segura possible. La seguretat s'ha d'integrar CI/CD eines i pipelinedes de zero, en lloc de ser una idea de darrer moment. Però la facilitat d'ús i la comoditat sovint xoquen amb la seguretat.

Per al cas de Jenkins, l'autenticació integrada és massa fràgil: no utilitzeu mai els mecanismes d'autenticació integrats a JenkinsMillor optar per un mecanisme de tercers (SAML, LDAP, Google...), amb un complement d'estratègia d'autorització basada en rols ("RBAC"). I tenir molta precaució amb el admin compte.

Tingueu cura de com funciona la feina i pipeline es gestionen els fitxers a Jenkins. El mateix amb Complement de configuració com a codi i els seus fitxers de configuració, que s'apliquen a la configuració de Jenkins.

Passant de l'autoallotjament CI/CD sistemes SaaS basats en el núvol elimina alguns riscos potencials que permeten el moviment lateral dins de la xarxa de l'organització, però n'afegeix d'altres, com ara haver d'obrir connexions externes entre els sistemes interns existents i els externalitzats CI/CD eina.

Les organitzacions haurien d'exercircisla deguda cura en l'enduriment de la CI/CD sistema, començant per la configuració més restrictiva i obrint-lo gradualment amb els permisos mínims necessaris per al pipeline passos.

Configuració de la seguretat a CI/CD Les eines podrien ser una tasca complexa. Moltes tenen complements o extensions que tenen la majoria de vulnerabilitats i s'han d'actualitzar.

Els escàners de configuració incorrecta de seguretat per a eines tan complexes o els punts de referència poden ser útils.

Injectant codi a pipeline ordres per diversió i benefici

M3M3N70Has utilitzat mai Untrusted Code Checkouts, que són accions i scripts vulnerables a la injecció d'ordres?

Aquesta secció mostra que el pipeline en si mateix podria tenir errors de codificació que permeten als malfactors injectar l'execució de codi arbitrari al pipeline sense canviar el pipeline font mateixaPer exemple, utilitzant una RP

Un primer exemple d'un flux de treball desafortunat de GitHub:

# INSECURE. Provided as an example only.
on:
  pull_request_target #1

jobs:
  build:
    name: Build and test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: $ #2

      - uses: actions/setup-node@v1
      - run: |
          npm install #3
          npm build
      # ... more steps ...

combinant pull_request_target L'activació del flux de treball amb una comprovació explícita d'una PR no fiable és una pràctica perillosa que pot conduir a un compromís del repositori. En l'exemple, la combinació desafortunada de:

• pull_request_target esdeveniment, que per defecte té permís d'escriptura al repositori de destinació i als secrets del repositori de destinació, fins i tot des de forks externs, i s'executa en el context del repositori de destinació del PR,
• Revisa el codi PR des del codi font, repositori no fiable,
• activar qualsevol script que pugui operar sobre continguts controlats per relacions públiques, com en el cas de npm installi
• no utilitzar una condició per desencadenar pull_request_target l'esdeveniment només s'executarà si s'assigna algun tipus d'etiqueta "aquesta PR ha estat verificada" a la PR (els usuaris externs no poden assignar etiquetes a la PR).

Un segon exemple pren informació no fiable (d'un problema, comentari o pull request) com a font per als arguments passats a un pipeline comanda mitjançant expressions. Això és el pipeline versió de la vulnerabilitat d'injecció de comandes del sistema operatiu.

- name: Check title
  run: |
    title="$"
    if [[ ! $title =~ ^.*:\ .*$ ]]; then
      echo "Bad issue title"
      exit 1
    fi

L'operació d'execució genera un script de shell temporal basat en la plantilla, amb $ substituït, fent-lo vulnerable a la injecció d'ordres de shell. Un atacant amb un compte fals de GitHub podria crear un problema amb un títol a"; bad_code_goes_here;#, i bum! 

Fúria del Pantà: Oh, aquests nois estaven obrint la porta a la injecció de comandes simplement obrint un problema…

Hi havia vulnerabilitats d'execució de codi a les accions de GitHub, com ara comentari de gajira, ara corregit. Si us plau, llegiu "Entrada no fiable en fluxos de treball de GitHub" per a més detalls.

La moral de la història: Mai no comprovis ni creïs PRs de fonts no fiables sense revisar-les primer. "No fiable" aquí, tret que es compleixi una autenticació draconiana de la procedència, podria significar qualsevol compte de desenvolupador potencialment segrestat.

Implementació involuntària de programari maliciós aquí!

Desplegament continu és el clímax de l'automatització, però aquest clímax podria ser frustrat per la manca de controls d'aprovació adequats a la pipeline flux.

Els riscos d'una implementació totalment automatitzada des de l'origen commit als sistemes de producció inclouen la possibilitat que es desplegui codi maliciós en entorns de producció sense ser detectat, així com la possibilitat que errors en el procés de desplegament causin interrupcions o interrupcions del servei.

Per mitigar aquests riscos, sovint es recomana que les organitzacions implementin una "pausa dura" en el seu procés de desplegament, que requereix aprovació humana abans que les versions es despleguin als entorns finals.

Estan tancant les portes.

Fúria del PantàAquelles alegres contrasenyes predeterminades a CI/CD s'estan esborrant les eines. Accedir a /var/lib/jenkins/secrets/initialAdminPassword ara és una via morta. Moltes eines ara proporcionen 2FA, que la Covid va popularitzar, i fins i tot el mico de programació més mandrós l'està utilitzant!

M3M3N70Estem lluitant contra l'autenticació a dos factors, però no és tan fàcil. És difícil fer spear-phishing a aquests individus, ja que "Scatter Swine" ho va fer amb TwilioAmb les claus WebAuthn és molt més difícil. Almenys, podem intentar-ho. robar galetes per evitar l'MFA, però cal entrar a la caixa del desenvolupador.

L'autenticació multifactor és un bon pas en la direcció correcta per limitar el risc de filtracions de secrets d'autenticació. La majoria de les eines DevOps modernes admeten MFA. I les claus d'autenticació sota WebAuthn / U2F (vegeu Projecte FIDO2) són potser la millor opció per a l'MFA en DevOps, si es gestionen correctament.

Fúria del PantàEls de DevOps s'estan despertant. Porten la maleïda cosa del "mínim privilegi" a la sang. I ja no són micos de programació. Ara els revisors ens enxampen amb les mans al plat.

De fet, pipelineara són una mica més robustos que fa un parell d'anys, amb accions i scripts febles eliminats, i amb passos addicionals de proves de seguretat que fins i tot han detectat els nostres droppers amagats de manera discreta. commits i paquets que vam segrestar.

Pregunta per al lector: és un negoci arriscat el procés de crear el programari des dels codis font i implementar-lo en producció? Podeu veure el vostre DevOps en l'etapa de bons temps de sempre pels dolents?

Recomanacions finals

Per on començar CI/CD pipelines?

La primera recomanació és senzilla: amb cura revisar pipelines (ells són crític recursos) per a problemes de seguretat. Les revisions són costoses però necessàries i s'han de fer correctament. Els revisors han de saber què han de mirar. Cal comprovar cada pas per detectar defectes.

Potser una combinació de revisors experts armats amb escàners automatitzats de codi maliciós podria ajudar.

La segona recomanació és formar desenvolupadors que escriuen pipelinei mantenir-los en seguretat. Coses a tenir en compte:

• Com gestionar correctament l'autenticació amb serveis interns i al núvol, evitant la molèstia de gestionar credencials a llarg termini.
• Com limitar pipelines al conjunt exacte de recursos als quals necessita accedir. El principi del mínim privilegi torna a brillar.
• Com escriure els passos per fer pipelines reproduïble com la fixació de versions i evitant vulnerabilitats d'injecció de comandes.
• Com aprovar desplegaments des de la perspectiva de seguretat (són altres!): quina seguretat standards'haurien de coincidir i com afegir els controls/portes corresponents al pipelines.

Una tercera recomanació és configurar el CI/CD sistema amb la deguda curaAutenticació forta, sense contrasenyes predeterminades ni configuracions insegures, privilegis mínims... Aneu amb compte amb les vulnerabilitats dels complements i les extensions instal·lades. Això podria ser el tema central de les properes publicacions, estigueu atents.

La quarta recomanació és aprofitar el CI/CD pipelines per a l'automatització de la seguretat. Anàlisi del codi font (SAST), anàlisi de la composició de la font (SCA), l'anàlisi de fuites de secrets, les eines antimalware, els escàners de seguretat de contenidors o els detectors automatitzats en temps d'execució (DAST i malware) es poden executar rutinàriament al pipelineI la vostra organització pot fer complir standardsobre la cobertura de l'escaneig de seguretat a CI/CD.

Recordeu que aquestes eines no eliminen la revisió experta de l'equació, ja que en cas contrari podríeu tenir una falsa sensació de seguretat.

Si ets expert en els deu millors de l'OWASP, un bon projecte recent és el OWASP Top 10 CI/CD Risc de seguretat.

Nota d'exempció de responsabilitat

(1) Els exemples d'aquesta publicació utilitzen GitHub com a SCM, AWS com a proveïdor de núvol i GitHub Actions o Jenkins com a CI/CD eina. No són més febles / més segures que les seves alternatives. Sense mala intenció de premsa! Aquestes eines són potents i s'han d'utilitzar adequadament.

(2) M3M3N70 i Fúria del Pantà són personatges de ficció. Qualsevol semblança amb persones o grups, vius o morts, és mera coincidència... o no?

Per llegir més

• Haymore, A. et al. 10 històries del món real de com hem fet concessions CI/CD pipelines ”Grup NCC, gener de 2022.
• configure-aws-credentials Acció de GitHub i Configuració d'OpenID Connect a Amazon Web Services per obtenir més informació sobre com executar ordres d'AWS per a la implementació en fluxos de treball de GitHub.
• Lobacevski J. "Mantenir les accions i els fluxos de treball de GitHub segurs. Part 1: Prevenir les sol·licituds pwn"Laboratori de seguretat de GitLab, desembre de 2020.
• Lobacevski J. "Mantenir les accions i els fluxos de treball de GitHub segurs. Part 2: Entrada no fiable"Laboratori de seguretat de GitLab, gener de 2021.
• OWASP. Els 10 millors de l'OWASP CI/CD Riscos de seguretat”Juliol de 2022.
• Saltzer J. i Schroeder M. "La protecció de la informació en sistemes informàtics"Abril de 1975. Els principis de seguretat van evolucionar amb la tecnologia, però 47 anys després, la majoria de les idees de seguretat i seguretat continuen vigents.
• NCSC del Regne Unit. "Assegureu la compilació i el desplegament" pipeline"Centre Nacional de Ciberseguretat del Regne Unit, febrer de 2019.