Empès accidentalment .env Secrets o claus d'AWS per a un repositori públic de GitHub: per què la supressió del fitxer no l'amaga¶

Adonar-se deu segons després de córrer git push origin main (o girar un repositori privat a Public) que el vostre compromís incloïa un text pla .env fitxer, un AWS AKIA... Clau d'accés i clau secreta, una clau d'API OpenAI/Anthropic, una banda sk_live_... testimoni de producció, un URI de base de dades PostgreSQL/MongoDB amb contrasenya o un no xifrat $HOME/.ssh/id_ed25519 La clau privada és una emergència de ciberseguretat de cinc alarmes. Les botnets automatitzades de recollida de credencials sondegen contínuament al públic Esdeveniments GitHub Firehose (api.github.com/events) i clonar les confirmacions recentment enviades en un termini d'1,5 a 4 segons del vostre git push completant. Pitjor, gairebé tots els desenvolupadors en pànic cometen exactament el mateix error fatal: suprimeixen el .env fitxer localment, afegiu .env a .gitignore, i premeu una segona confirmació titulada "remove .env" o "oops". Present una segona confirmació que s'elimina .env no amaga res: el secret de text sense format es manté llegible al 100% per sempre dins de la diferència del commit anterior (git log -p), i fins i tot si força-empènyer (git push --force) sobre la branca, la confirmació sense referència (dangling blob) segueix sent accessible públicament mitjançant el seu URL directe de GitHub i les visualitzacions de sol·licitud d'extracció a la memòria cau fins que es purgin explícitament. Si els atacants ja han utilitzat la credencial filtrada per desplegar programari de ransomware, segrestar el vostre domini DNS o bloquejar el vostre inquilí del núvol, consulteu les nostres guies complementàries sobre resposta de programari maliciós i ransomware, segrest de noms de domini, DNS caducat i presa de possessió del lloc web, i Bloqueig d'administrador de domini personalitzat de Google Workspace o Microsoft 365. Si una fuga de credencials afecta la seguretat del pacient de l'hospital, els controls físics industrials o la infraestructura d'enviament d'emergència, truqueu al vostre número d'emergència local (911 als Estats Units i al Canadà, 112 a tota la Unió Europea, 999 al Regne Unit) o consulta el nostre directori internacional de números d'emergència.

Fes això ara¶

1. REVOC, DESACTIVA I GIRA cada secret exposat a la consola del proveïdor PRIMERA (en els primers 120 segons) abans de perdre un sol segon en execució git ordres: una vegada que un secret toca un dipòsit públic de GitHub, GitLab o Bitbucket fins i tot durant 3 segons, tracteu aquesta clau com a cremada permanentment i ja en mans d'atacants automatitzats. Cap quantitat de git reset --hard, git push --force, o suprimir el dipòsit pot esborrar una clau de la base de dades d'un bot de raspador que ja va descarregar el vostre commit al segon número 2. Inicieu la sessió a la configuració d'AWS IAM, Stripe, OpenAI, consoles de bases de dades o GitHub SSH ara mateix i Desactiva/Suprimeix/Rolla la clau immediatament.
2. Auditeu els vostres registres d'auditoria i facturació al núvol (AWS CloudTrail, GCP Cloud Audit Logs, Stripe Logs) per a la finestra entre el vostre git push i la revocació de la teva clau: els robots de criptomineria automatitzats utilitzen filtracions AWS_ACCESS_KEY_ID (AKIA...) en un termini de 30 a 90 segons per activar instàncies de GPU de quota màxima (p4d.24xlarge / g5.48xlarge) a totes les regions d'AWS ocultes (ap-east-1, me-south-1, af-south-1) i creeu usuaris IAM de porta posterior o Lambda ganxos de persistència perquè romanguin dins del vostre compte d'AWS fins i tot després d'eliminar la clau filtrada.
3. ** MAI premeu ni un segon "Delete .env" commit - de fet, escrivint "delete secret" o "remove password" en un missatge de confirmació atrau robots raspadors dirigits**: milers d'scripts d'actors d'amenaça consulten específicament a GitHub cerca missatges de confirmació que continguin "remove .env", "delete key", "oops", i "remove credentials", a continuació, feu clic a una confirmació enrere a l'historial per robar la clau.
4. Reescriure localment tot l'historial del repositori Git utilitzant git filter-repo (o BFG Repo-Cleaner) per eliminar el fitxer o eliminar la cadena de contrasenya de cada commit històric, arbre i etiqueta: git filter-branch està oficialment obsolet pel projecte Git; utilitzar git filter-repo --invert-paths --path .env (per eliminar un fitxer de totes les confirmacions) o git filter-repo --replace-text expressions.txt (per substituir cadenes de contrasenyes específiques amb ***REMOVED*** dins dels fitxers de codi sense suprimir els fitxers).
5. ** Forçar totes les branques i etiquetes (git push origin --force --all), I purgueu les vistes de confirmació emmagatzemades en memòria cau del costat del servidor de GitHub (dangling commits)**: Aquest és el secret que la majoria dels desenvolupadors no coneixen: fins i tot després d'executar git filter-repo i git push --force, Els servidors de GitHub mantenen l'antic commit SHA viu a la memòria cau d'objectes (git cat-file), és a dir, qualsevol persona que hagi enregistrat la confirmació SHA de 40 caràcters des de l'API d'esdeveniments públics encara pot veure'l github.com/user/repo/commit/<OLD_SHA>. A continuació us expliquem com esborrar immediatament les memòries cau de confirmació penjants mitjançant el suport / API de GitHub o suprimint i recreant el dipòsit.
6. Instal·la un local pre-commit escàner secret (gitleaks o trufflehog) dins .git/hooks/pre-commit abans d'escriure una altra línia de codi: 10 segons gitleaks protect --staged El ganxo de precommit inspecciona cada línia en fase localment al vostre ordinador portàtil i blocs git commit abans que un secret pugui abandonar la vostra màquina.

Arbre de decisions: contenció immediata, rotació i purga de l'historial de Git¶

Executeu aquest flux de treball en un ordre cronològic estricte (Revocar PRIMERA -> Persistència de l'auditoria SEGON -> Purga l'historial de Git TERCER):

flowchart TD
    Start["Secret enviat al repositori públic (.env, clau AWS/GCP, contrasenya de base de dades, clau Stripe/OpenAI o clau SSH privada)"] --> Step1["MINUTS 0 A 2 (PRIORITAT 1): revocar/enrotllar totes les claus exposades a la consola del proveïdor immediatament"]

    Step1 --> SecretType{"Quin tipus de credencial hi havia dins del commit?"}

    SecretType -->|"Clau d'infraestructura al núvol (AWS AKIA, compte de servei GCP JSON, Azure SP)"| CloudAudit["MINUT 2 A 10: comproveu CloudTrail/Registres d'activitats -> Termina les instàncies informiques/EC2 no autorizades a totes les regions -> Suprimeix usuaris/rols/sessions STS d'IAM no autoritzats"]

    SecretType -->|"URI / Contrasenya de la base de dades (Postgres, MySQL, MongoDB, Redis, Supabase)"| DBAudit["MINUT 2 A 10: Gireu la contrasenya d'usuari de la base de dades + Suprimeix les connexions actives (pg_terminate_backend) + Bloqueja el grup de seguretat del tallafoc només a les IP de la llista blanca"]

    SecretType -->|"Token API o clau SSH (Stripe, OpenAI, GitHub PAT, Slack, clau SSH privada)"| TokenAudit["MINUT 2 A 10: enrotlla la clau de l'API al tauler/Elimina la clau pública SSH de $HOME/.ssh/authorized_keys i la configuració de GitHub -> Auditoria dels registres d'ús recent de l'API"]

    CloudAudit --> RepoVisibility{"MINUT 10 A 20: Com voleu purgar el dipòsit de GitHub?"}
    DBAudit --> RepoVisibility
    TokenAudit --> RepoVisibility

    RepoVisibility -->|"Esborrat de memòria cau al 100% més ràpid (no hi ha cap problema crític/historial d'estrelles per conservar)"| NukeRepo["1. Suprimiu el repositori sencer a la configuració de GitHub. 2. Executeu git filter-repo localment per netejar l'historial. 3. Creeu un nou repositori i un historial de neteja automàtica (destrueix a l'instant tots els SHA de commits a la memòria cau)"]

    RepoVisibility -->|"Cal conservar les estrelles, els problemes, les relacions públiques i les bifurcacions existents"| RewriteRepo["1. Executeu git filter-repo (--invert-paths o --replace-text). 2. Executeu git push --force --all & --tags. 3. Poseu-vos en contacte amb el suport de GitHub/portal d'assistència per purgar la memòria cau SHA de la confirmació penjant"]

Fase 1: minut 0 a 2: full de trucs de revocació immediata pel proveïdor¶

No obriu un terminal per lluitar git rebase mentre les teves claus de producció encara estiguin actives. Feu clic directament al proveïdor afectat a continuació i elimineu primer la credencial:

Fase 2: del minut 2 al 10: comprovació de si els atacants ja han creat una porta posterior (AWS / Contenció del núvol)¶

Si t'has filtrat .env El fitxer contenia una clau d'accés AWS (AKIA...), Google Cloud Service Account JSON o Azure Service Principal, suprimir la clau filtrada és només la meitat de la batalla. Heu de verificar que un bot automatitzat no va utilitzar aquests 90 segons per establir la persistència dins del vostre compte al núvol:

L'auditoria forense post-fuga d'AWS de 6 punts¶

1. ** Comprovar AWS CloudTrail -> Event history per a totes les trucades a l'API fetes per la filtració Access Key ID**:
2. Obriu AWS CloudTrail Console -> Historial d'esdeveniments.
3. Canvia el menú desplegable de cerca de Només lectura a Access key ID i enganxeu el filtrat AKIA... corda.
4. Mireu tots els esdeveniments registrats des del minut que vau executar git push. Busqueu específicament: CreateUser, CreateAccessKey, AttachUserPolicy, CreateRole, AssumeRole, GetSessionToken, RunInstances (EC2), RequestSpotInstances, CreateFunction (Lambda), o SendEmail (Spam SES).
5. Revocar qualsevol temporal actiu STS sessions generades per aquest usuari:
6. Fins i tot després d'haver suprimit un AKIA... clau d'accés, si l'atacant ha trucat sts:GetSessionToken abans de suprimir la clau, el seu ** temporalASIA... El testimoni de sessió continua sent vàlid fins a 36 hores.**
7. Per matar tots els temporals actius STS fitxes per a aquest usuari IAM immediatament, aneu a IAM -> Users -> [Leaked User] -> Permissions -> Add inline policy i feu clic a Revoke sessions (que adjunta un explícit Deny * política per a qualsevol testimoni emès on aws:TokenIssueTime és abans que ara).
8. ** Comprovar IAM -> Users i IAM -> Roles per als comptes de backdoor de nova creació**:
9. Ordena tots els usuaris d'IAM per hora de creació. Suprimeix qualsevol usuari desconegut (admin-backup, sys-monitor, support-bot) i verificar el Trust relationships pestanya a les vostres funcions IAM per assegurar-vos que l'atacant no ha afegit el seu propi ID de compte AWS extern ("Principal": {"AWS": "arn:aws:iam::999999999999:root"}) com a director de confiança.
10. ** Ús AWS Resource Explorer o EC2 Global View per comprovar TOTES les 30 regions d'AWS per trobar criptominers ocults**:
11. Els atacants rarament inicien instàncies de criptomineria us-east-1 on els veureu al vostre tauler. En canvi, es llancen p4d, g5, o c6i.32xlarge casos en ap-southeast-3 (Jakarta), me-central-1 (Emirats Àrabs Units), il-central-1 (Tel Aviv) o sa-east-1 (São Paulo).
12. Obert EC2 Console -> EC2 Global View (que escaneja totes les regions habilitades en una única taula) i Termina qualsevol instància no autoritzada immediatament.
13. Obriu un cas de facturació d'AWS Support immediatament si les instàncies delinqüents van generar una factura:
14. Si un bot va girar $8,000 d'instàncies de GPU EC2 abans de finalitzar-les, no us espanteu: un cop hàgiu assegurat el compte, heu suprimit la clau, heu activat l'arrel/IAM MFA, i va treure la clau de GitHub, obriu un Compte AWS i cas d'assistència de facturació on s'explica l'empenta accidental de GitHub i els passos de correcció. AWS atorga habitualment un crèdit únic de condonació de la facturació de bona voluntat per filtracions accidentals de claus de GitHub un cop el seu equip de seguretat verifica que el dipòsit està net.

Fase 3: per què falla la supressió del fitxer en un nou commit i com reescriure correctament l'historial amb git filter-repo¶

1. Per què git rm .env && git commit -m "delete .env" és completament inútil¶

Git és un sistema de fitxers que només s'adreça al contingut (Directed Acyclic Graph / DAG de commits, arbres i objectes blob): - Suposem ** Compromís A1B2C3** afegit .env (Blob 998877). - Suposem que 2 minuts després corres git rm .env, afegir .env a .gitignore, i premeu Comprom D4E5F6. - Mentre algú navega per la llista de fitxers actual a la vostra pàgina d'inici de GitHub no ho veurà .env, ** Compromís A1B2C3 i Blob 998877 encara formen part al 100% del repositori.** Qualsevol que executi git clone descàrregues Blob 998877, qualsevol persona que faci clic a la pestanya "Commits" a GitHub pot fer clic A1B2C3 per llegir el teu .env fitxer en text sense format i eines automatitzades (trufflehog git https://github.com/user/repo) escaneja cada confirmació històrica en 2 segons.

2. Pas a pas: esborrar un fitxer o una cadena secreta a tot l'historial git filter-repo¶

El projecte Git i GitHub recomanen oficialment git-filter-repo (que substitueix el lent i propens a errors git filter-branch i és encara més flexible que BFG Repo-Cleaner).

1. ** Instal·lar git-filter-repo** (Taga 5 segons):

   # On macOS (Homebrew):
   brew install git-filter-repo
   
   # On Linux / Windows (via pip / apt):
   pip3 install git-filter-repo
   

2. Feu una còpia de seguretat de la carpeta del dipòsit local abans de reescriure l'historial:

   cp -r $HOME/projects/my-repo $HOME/projects/my-repo-backup
   cd $HOME/projects/my-repo
   

   (Nota: si ja has mogut el teu vàlid .env arxivar, assegureu-vos que n'hi ha una còpia neta .env es guarda a /tmp/.env.safe fora del repo, perquè git filter-repo esborrarà .env del vostre directori de treball també.)
3. ** Trieu l'opció A (esborrar un camí de fitxer sencer com .env o id_rsa) O Opció B (Redactar cadenes secretes específiques dins dels fitxers de codi)**:
4. Opció A: elimina completament .env (o config/secrets.json) de tots els compromisos de la història:

   git filter-repo --invert-paths --path .env --force
   

   (Per què --invert-paths? Sense --invert-paths, git filter-repo --path .env es manté NOMÉS .env i esborra tota la resta. Combinant --invert-paths --path .env diu a Git que ho guardi tot EXCEPTE .env a totes les confirmacions, branques i etiquetes.)
5. Opció B: conserva el fitxer de codi (app.py / config.js), però elimina la cadena secreta codificada de cada versió històrica: Creeu un fitxer de text /tmp/secrets-to-scrub.txt que conté una cadena secreta (o regex) per línia:

   AKIAIOSFODNN7EXAMPLE==>REDACTED_AWS_KEY
   sk_live_51NzExampleSecretKey999==>REDACTED_STRIPE_KEY
   regex:postgres:\/\/non_at_chars@==>postgres://REDACTED_DB_CREDENTIALS@
   

   Ara corre git filter-repo --replace-text:

   git filter-repo --replace-text /tmp/secrets-to-scrub.txt --force
   shred -u /tmp/secrets-to-scrub.txt 2>/dev/null || rm -P /tmp/secrets-to-scrub.txt
   

6. Afegir .env a .gitignore perquè no ho tornis a comprometre d'aquí a 5 minuts:

   echo ".env" >> .gitignore
   echo "*.pem" >> .gitignore
   git add .gitignore
   git commit -m "chore: update gitignore rules"
   

7. ** Torna a afegir el teu comandament GitHub (git filter-repo elimina intencionadament origin com a control de seguretat) i forçar totes les branques i les etiquetes**:

   git remote add origin git@github.com:YOUR_USERNAME/YOUR_REPO.git
   git push origin --force --all
   git push origin --force --tags
   

Fase 4: la trampa oculta de la memòria cau de GitHub (Dangling Commits) i Com purgar-lo¶

Aquí hi ha una realitat forense crítica documentada a Documents oficials de GitHub (Eliminació de dades sensibles d'un dipòsit): - Quan corres git filter-repo i git push origin --force --all, cada commit del vostre dipòsit rep un nou hash SHA-1 de 40 caràcters i el vostre main el punter de branca es mou al nou historial net. - TANTÓ, el servidor d'emmagatzematge Git de backend de GitHub NO recull immediatament les escombraries (git gc --prune=now) l'antiga confirmació SHA sense referència. - Això vol dir que si el bot d'un atacant va registrar l'antic commit hash (p. ex., a1b2c3d4...) de l'API pública d'esdeveniments de GitHub quan vau empènyer per primera vegada, ** encara es poden obrir https://github.com/YOUR_USERNAME/YOUR_REPO/commit/a1b2c3d4... en qualsevol navegador web i visualitzeu el vostre .env fitxer fins i tot DESPRÉS d'haver forçat l'historial de neteja.** Pitjor, si el secret apareixia dins d'una Solicitud d'extracció, refs/pull/12/head manté aquest compromís permanentment accessible.

Com destruir les confirmacions en memòria cau/pendant als servidors de GitHub ara mateix:¶

1. Mètode 1 (netejada instantània, 100% completa: millor si el repo no té problemes/PR/estrelles crítics):
2. Aneu al vostre repositori a GitHub -> Settings -> Desplaceu-vos cap a la part inferior (Danger Zone) -> Feu clic Delete this repository.
3. Creeu un repositori nou amb exactament el mateix nom a GitHub i feu-ne una neteja git filter-repo repositori local a ell (git push -u origin main).
4. Suprimir el repositori a GitHub ** trenca immediatament totes les vistes web públiques dels SHA de commits emmagatzemats en memòria cau antics** (404 Not Found).
5. Mètode 2 (Preservar estrelles, problemes i PR - Ús de suport de GitHub / Purga de memòria cau):
6. Primer, agafeu el hash SHA exacte de 40 caràcters de l'antic commit que contenia el secret (comproveu git reflog a la vostra carpeta de còpia de seguretat o als vostres correus electrònics de notificació de GitHub).
7. Obre ** Suport de GitHub (support.github.com)** i utilitzeu el flux de treball automatitzat Elimina les dades sensibles / Purga les vistes de confirmació de la memòria cau (fa referència a l'URL del dipòsit i als SHA(s) de confirmació pendents exactes). L'eina automatitzada de GitHub Support executa un servidor immediat git gc purga de memòria cau que invalida les vistes web a la memòria cau i els objectes sense referència sense suprimir el vostre dipòsit.
8. Notifiqui a tots els companys/col·laboradors git clone fresc (MAI git pull)*:
9. Digues a tots els desenvolupadors del teu equip: "NO executis git pull i empeny." Si un company de feina que va treure el mal commit abans corre git pull (que fusiona l'antic historial brut amb el nou historial reescrit) i empènyer, empènyeran els suprimits .env tornar a confirmar a GitHub. Cada col·laborador ha d'esborrar la seva carpeta local i executar-ne una nova git clone, o córrer git fetch origin && git reset --hard origin/main.

Fase 5: Prevenció de futures fuites per sempre (Gitleaks Pre-commit Hook i GitHub Push Protection)¶

Preneu 60 segons ara mateix perquè sigui matemàticament impossible tornar a cometre un secret accidentalment:

1. Activeu GitHub gratuït "Push Protection for Yourself" a tot el vostre compte de GitHub:
2. Vés a GitHub Settings (la configuració del vostre perfil personal, a dalt a la dreta) -> Code security and analysis (o Code security).
3. Desplaça't fins a Secret scanning -> Habilita Push protection for yourself.
4. Amb això activat, sempre que corres git push des de qualsevol ordinador a qualsevol repositori públic o privat, el servidor de GitHub inspecciona el vostre fitxer de paquets entrant abans d'acceptar l'empenta: si detecta una clau AWS, una clau OpenAI, una clau Stripe, una clau SSH privada o un testimoni Slack, GitHub rebutja el git push directament al teu terminal abans que el commit es publiqui.
5. ** Instal·lar gitleaks com a local pre-commit enganxa el teu portàtil**:

   # Install gitleaks:
   brew install gitleaks   # (or download binary on Linux/Windows)
   
   # Add a pre-commit hook inside your repository (.git/hooks/pre-commit):
   cat << 'EOF' > .git/hooks/pre-commit
   # /usr/bin/env bash
   gitleaks protect --verbose --redact --staged
   if test $? -ne 0; then
     echo "COMMIT BLOCKED BY GITLEAKS: High-entropy secret or API key detected in staged changes."
     exit 1
   fi
   EOF
   chmod +x .git/hooks/pre-commit
   

Números d'emergència regionals i protocols de l'agència¶

Si una inserció accidental de credencials de GitHub provoca una intrusió no autoritzada en dades personals regulades (PII / PHI), els sistemes sanitaris o la infraestructura governamental, segueixen els protocols obligatoris de notificació d'incompliments:

• Estats Units i Canadà:
• Seguretat de la vida d'emergència / interrupció d'infraestructura crítica: marqueu 911 si una incompliment de la infraestructura afecta les operacions de l'hospital o els controls de seguretat física.
• Agència de Ciberseguretat i Seguretat de les Infraestructures (CISA) i FBI (IC3): si els atacants van utilitzar claus del núvol filtrades per exfiltrar dades o desplegar programari maliciós d'extorsió, informeu-ho a CISA (1-844-Say-CISA / cisa.gov/report) i el FBI Internet Crime Complaint Center (ic3.gov).
• Notificació d'incompliment de dades de SEC, FTC i Fiscal General de l'Estat: si els registres d'accés a la base de dades/CloudTrail mostren que una adreça IP no autoritzada ha accedit a les dades personals del client (PII) o registres sanitaris (HIPAA ePHI) abans que es revoqués la clau filtrada, consulteu immediatament un assessor legal sobre els terminis de notificació d'incompliment de dades de l'estat i els informes federals HHS OCR/FTC Safeguards Rule.
• Centre Canadien per a la Ciberseguretat: truqueu 1-833-CYBER-88 (1-833-292-3788) o informar de les infraccions de privadesa a PIPEDA a l'Oficina del Comissionat de Privadesa del Canadà (OPC).
• Regne Unit:
• Serveis d'emergència: Marqueu 999 (o 101 / Frau d'acció 0300 123 2040 i el Centre Nacional de Ciberseguretat / NCSC a les ncsc.gov.uk).
• Oficina del Comissari d'Informació (ICO - Finestra de 72 hores del RGPD del Regne Unit): si una credencial filtrada permetia l'accés no autoritzat a les dades personals dels residents del Regne Unit, l'article 33 del RGPD del Regne Unit exigeix informar les infraccions de dades personals notificables a l'ICO (0303 123 1113) dins de les 72 hores després de tenir coneixement de l'incompliment.
• Unió Europea:
• Serveis d'emergència: Marqueu 112 a tots els estats membres de la UE.
• Informació d'incidents de l'article 33 del RGPD i la Directiva NIS2: les organitzacions subjectes al RGPD de la UE han d'avaluar si l'exposició de la credencial va provocar una violació de la confidencialitat de les dades personals (notificació de 72 hores a l'autoritat nacional de protecció de dades/ DPA), mentre que entitats essencials/importants sota la UE NIS2 La Directiva s'enfronta a un data límit de notificació anticipada de 24 hores al seu nacional CSIRT (BSI a Alemanya, ANSSI a França, ACN a Itàlia) per a incidents cibernètics significatius.
• Austràlia i Nova Zelanda:
• Serveis d'emergència: Marqueu 000 a Austràlia o 111 a Nova Zelanda.
• Centre de seguretat cibernètica australià (ACSC) i infraccions de dades notificables (OAIC): Truca 1300 CYBER1 (1300 292 371) per a la resposta a incidents i avaluar les obligacions de notificació de l'Oficina del Comissionat d'Informació d'Austràlia (OAIC) Incompliments de dades notificables (NDB) o la Llei de privadesa de Nova Zelanda de 2020 (Privacy Commissioner).
• Índia i Àsia-Pacífic:
• Serveis d'emergència: Marqueu 112 a l'Índia (o 1930 per ciberdelinqüència).
• Directiva obligatòria d'informes de 6 hores CERT-In (Índia): sota Equip de resposta d'emergència informàtica de l'Índia (CERT-In) indicacions (No. 20(3)/2022-CERT-In), s'ha d'informar a ** de l'accés no autoritzat a sistemes informàtics/núvols o de fuites de dades que afecten organitzacions a l'Índia.incident@cert-in.org.in dins de les 6 hores** des de la detecció.

Preguntes freqüents¶

Vaig eliminar el .env fitxer i vaig empènyer una nova confirmació 30 segons després del meu error; encara he de girar les meves claus API i contrasenyes de base de dades?¶

Sí, 100 per cent: gireu cada tecla immediatament sense excepció. Els estudis acadèmics de ciberseguretat i la telemetria de GitHub Secret Scanning confirmen que els robots automatitzats de recollida de credencials supervisen el flux públic d'esdeveniments de GitHub (api.github.com/events) en temps real i descarregueu els nous commits introduïts 1,5 a 5 segons. Pitjor, empènyer una segona confirmació que s'elimina .env deixa tot el text pla .env fitxer permanentment dins de la diferència de l'historial del primer commit, i molts robots cerquen específicament commits que suprimeixen .env fitxers. Un cop s'ha enviat un secret a un dipòsit públic fins i tot durant 1 segon, es veu compromès per sempre; revocar i girar la credencial al tauler del proveïdor és l'únic que us protegeix.

Què passaria si el dipòsit fos un repositori PRIVAT de GitHub quan vaig comprometre el .env fitxer i només vull netejar-lo abans de fer públic el repo la setmana vinent?¶

Si el dipòsit era 100 per cent privat tot el temps (i cap aplicació CI/CD de tercers no fiables no tenia accés), els robots de raspador de l'API pública de GitHub Events tenen no encara has vist el teu secret. Tanmateix, NO esborreu simplement `.env` en una nova confirmació i, a continuació, canvieu el repo de privat a públic. En el moment en què canvieu un dipòsit privat a Públic, és gràfic de compromís històric complet es fa públic, i els robots escanegen immediatament tots els commits antics al nou repo públic. Abans de fer públic un repo privat, o bé: (1) Executeu git filter-repo --invert-paths --path .env per eliminar el fitxer de totes les confirmacions històriques (i girar les tecles de totes maneres per a la millor pràctica), O (2) Copieu els fitxers actuals nets en una carpeta nova, executeu git init per obtenir un historial inicial net d'1 commit i publiqueu aquest repositori nou.

Per què AWS va adjuntar automàticament una política anomenada AWSCompromisedKeyQuarantineV2 al meu usuari d'IAM, i per què encara se'm factura?¶

Perquè AWS s'associa directament amb GitHub Secret Scanning, sempre que un AKIA... La clau apareix en una confirmació pública de GitHub, el sistema de seguretat automatitzat d'AWS la detecta en qüestió de minuts, obre un bitllet de suport i adjunta la política gestionada. AWSCompromisedKeyQuarantineV2 (o V3) a aquest usuari d'IAM. Aquesta política de quarantena bloqueja accions perilloses evidents com el llançament de noves ec2:RunInstances o suprimint els compartiments S3 - però NO finalitza les instàncies EC2 que l'atacant ja va llançar durant els primers 60 segons abans que s'adjunti la política, ni elimina els usuaris d'IAM de la porta posterior o temporals. STS sessions que l'atacant ja ha creat. Encara heu de suprimir manualment la clau filtrada, comproveu Vista global EC2 a totes les regions per acabar amb les instàncies delinqüents i comprovar-ho CloudTrail per a canvis d'IAM no autoritzats.

Quina diferència hi ha entre git filter-repo i BFG Repo-Cleaner, i per què no hauria de fer servir git filter-branch?¶

git filter-branch és un script d'intèrpret d'ordres antic integrat a les primeres versions de Git que és extremadament lent en repositoris grans, fàcil de configurar malament (deixant les referències de còpia de seguretat a refs/original/ que encara contenen els vostres secrets.), i ara imprimeix un avís oficial d'abandonament de Git dient-vos que no l'utilitzeu. Tots dos git-filter-repo (escrit en Python i aprovat oficialment pels principals responsables de Git i GitHub) i BFG Repo-Cleaner (escrit en Java/Scala) s'executa de 10 a 100 vegades més ràpid i reescriu clarament tots els commits, arbres i etiquetes. git-filter-repo generalment es prefereix avui perquè modifica fins i tot la vostra confirmació de sortida actual (`HEAD`) sense requerir prèviament un compromís previ separat.

Com pot algú encara veure el meu commit suprimit a GitHub després d'executar-me git filter-repo i git push --force?¶

A Git, `git push --force` només actualitza el punter de referència de branca (`refs/heads/main`) per assenyalar la vostra nova cadena de confirmació reescrita; ho fa no suprimiu immediatament els antics objectes de confirmació sense referència ("pendants") emmagatzemats als servidors de fons de GitHub. Si un bot va registrar el hash SHA de 40 caràcters del vostre commit original quan va arribar a l'API d'esdeveniments públics, navegant directament a https://github.com/owner/repo/commit/<40-char-SHA> encara carregarà aquesta confirmació orfe des de la memòria cau d'objectes de GitHub fins que s'executi la recollida d'escombraries. Tampoc per eliminar immediatament aquesta vista en memòria cau suprimiu el dipòsit de GitHub i torneu-lo a crear des del vostre dipòsit local net, o envieu el SHA de confirmació penjant Suport de GitHub (`support.github.com`) per a una purga immediata de la memòria cau del costat del servidor.

Què passa si algú ja ha fet clic a "Forquilla" al meu repositori públic abans de fer-ho? git filter-repo?¶

Per això El pas 1 sempre és revocar i girar les credencials al tauler del proveïdor: corrent git filter-repo i forçar la força al vostre propi dipòsit NO reescriu les confirmacions dins del fork independent d'una altra persona del vostre repositori (tret que suprimiu tot el vostre repositori principal i contacteu amb l'assistència de GitHub pel que fa a les dades sensibles a les bifurcacions). Un cop hagueu revocat les claus AWS/API i heu girat les contrasenyes de la base de dades, qualsevol còpia de l'antiga .env El fitxer situat dins d'una base de dades de bifurcació o bot de tercers es converteix en una cadena de caràcters inútils i morts que ja no poden accedir a la vostra infraestructura.

Guies relacionades¶

• Ransomware i programari maliciós: contenció i recuperació immediata
• Segrest de noms de domini, DNS caducat i presa de possessió del lloc web
• Bloqueig de l'administració de dominis personalitzats de Google Workspace o Microsoft 365 i rescat de DNS
• Phishing i comptes compromesos: bloqueig d'emergència
• rm -rf accidental o Shift-Delete a Linux, macOS o Windows: torna a muntar de només lectura immediata
• Números d'emergència per països

Fonts i orientació oficial¶

• Documentació oficial de seguretat de GitHub (docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository): Eliminació de dades sensibles d'un repositori (git filter-repo, BFG Repo-Cleaner, Purga de memòria cau de confirmació penjant i Protecció push d'escaneig secret).
• Serveis web d'Amazon (AWS) Guia de resposta a incidents de seguretat (docs.aws.amazon.com/security/): Resposta a les claus d'accés AWS IAM exposades (AWSCompromisedKeyQuarantineV2, Revocació temporal STS Sessions via aws:TokenIssueTime, i CloudTrail Auditoria Forense).
• Institut Nacional d'Estàndards i Tecnologia (NIST) (Estats Units): Publicació especial 800-61 Rev. 2: Guia de gestió d'incidents de seguretat informàtica i SP 800-57: Recomanació per a la gestió de claus (revocació de credencials compromesa i rotació criptogràfica).
• Projecte de seguretat d'aplicacions web obertes (OWASP): Full de trucs de gestió de secrets (prevenció de credencials codificades en dur, exploració secreta prèvia a la confirmació amb Gitleaks/TruffleHogi Injecció secreta en temps d'execució efímer).
• Agència de Ciberseguretat i Seguretat de les Infraestructures (CISA) (Estats Units): * Arquitectura de referència tècnica de seguretat al núvol i Guia de jocs de correcció de credencials compromeses*.