Wat we leerden over secretsbeveiliging op AppSec Village op DEF CON 32

Als je in de VS opgroeid hebt, zijn er goede kansen dat je een herinnering hebt aan het bezoeken van een zomercamp. Zelfs als je zelf geen deel uitmaakte van een zomercamp, is de ervaring van het vertrekken van thuis, het leren van diverse kunst en ambachten, het ontmoeten van nieuwe beste vrienden en deelname aan onvergeeflijke avonturen ingebed in de populaire cultuur en de media. Elke augustus vindt het grootste hackerzomercamp ter wereld plaats in de warmte van Las Vegas. Dit jaar was het de dertigste editie van DEF CON.

DEF CON is moeilijk te verklaren zonder het zelf te hebben ervaren. Ja, er zijn sprekend tracks, officiële workshops en meerdere capture-the-flags (CTFs), maar er is veel meer. Geen andere congresbeurs bevat zoveel sub-conferenties en community-geleide evenementen. Zelfs deelnemers die al jarenlang aanwezig zijn zeggen dat ze nog steeds niet allemaal de dingen ervaren hebben die aanbieden.

Er is geen officiële aantal uitgegeven door de organisatoren, maar voorheen zijn er evenementen geweest die van 25.000-30.000 deelnemers telden. Elke deelnemer brengt er een liefde voor technologie en veel kennis mee om te delen. De gangen zijn vol met mensen die hardware hacken, software schrijven, muziek maken, stickers delen en alleBEF CON-ervaringen verlevendigen.

De Dorpen

Er waren 33 dorpen tijdens DEF CON 32 ingesloten. Deze omvatten een brede diversiteit van interesses, van ruimtevaarthacking, Social Engineering, en misinformatie tot Rode Team en AppSec. Elke dorp is onafhankelijk georganiseerd en biedt een unieke set van talks, workshops en hands-on activiteiten aan deelnemers om contact te houden met het specifieke gebied van hun focus.

AppSec Dorp was een waardevol ruimte binnen de grote hackings en veiligheidsgemeenschap die zich richt op het verdedigen van de applicaties die onze hele leven draaien. Uw auteur was een van de gelukkige mensen die meewerkten bij het organiseren en uitvoeren van AppSec Dorp 2024.

Spot de Geheimen 

Terug bij AppSec Dorp op de RSA Conference 2024, onthulde GitGuardian ons Spot de Geheimen, een kaartspel dat de ervaring simuleert van handmatige codereview om vaste tekst-inloggegevens te vinden. Spelers worden gevraagd om te racen om alle verborgen API-sleutels, wachtwoorden en andere vaste tekstgeheimen te vinden die aanvallers kunnen gebruiken om verdere toegang te krijgen tot een collectie codevoorbeelden, Jira tickets, logbestanden en Slack berichten.

Spot de Geheimen op AppSec Dorp, aangepast om rekening te houden met de fotorules van DEF CON

Bij DEF CON kwamen over 2 dagen meer dan 120 mensen langs ons POD in AppSec Village om deze oefening zelf mee te beleven. We had zelfs een leaderboard waar de snelste spelers, die de minst fouten maakten, speciale swag prijzen wonnen.

De Meest Voorkomende Veiligheidsvragen Over Geheime Informatie

Als mensen begonnen te onderzoeken de kaarten met code, kregen we een breed scala aan vragen. We denken dat het nuttig zou zijn om sommige van de vragen te delen, vooral als u nog de antwoorden daarop niet heeft gehoord.

Hier zijn de 11 meest voorkomende vragen die we hoorden en onze antwoorden.

1. Wat Is Een Commit precies?

Een commit is een eenheid van werk in Git, de versiebeheersysteem dat door meer dan 97% van de ontwikkelaars ter wereld wordt gebruikt. Het is een snapshot van het bestandssysteem op een bepaald moment in de tijd, die alle werkzaamheden van de ontwikkelaar beslaat sinds de laatste commit. Als je commits op elkaar volgt, krijg je de Git-geschiedenis, die je toestaat elke stap door de geschiedenis van de codebase te bekijken. Eén van de geheimen veiligheidseisen van Git is dat de geschiedenis een gedeelde permanente record is. Als een geheim wordt toegevoegd aan een commit en verwijderd in de volgende commit, blijft de commit met het geheim bewaard.

2. Hoe kun je vaststellen of iets een geheim is?

Een geheim is elke verificatie ondersteuning die direct toegang geeft tot een systeem of gegevens. Dit kan de vorm van API- sleutels, wachtwoorden, certificaten en tokens aannemen, om enige voorbeelden te noemen. Een deel van de reden dat ze moeilijk te ontdekken zijn, is dat ze op veel manieren binnen de code en vanaf de commandoregel worden gebruikt. Bijvoorbeeld, kan binnen een configureeringsbestand een specifieke variabele zijn ingesteld voor een API-sleutel. Maar voor systemen zoals Slack is de API-token ingebed in de URL zelf, wat betekent dat u het systeem moet kennen om te weten dat het een geheim is.

Veel systemen gebruiken in hun gebruikersinterface URL’s lange, unieke nummers, die zeer sterk op inline tokens lijken. Bijvoorbeeld, Figma-URL’s zouden lijken een base64-编码字符串 in de pad te bevatten. Echter, als u een willekeurige Figma-koppeling volgt, zult u een login-scherm tegenkomen, want u moet een geauthenticeerd gebruiker zijn om met die pagina verbinding te maken. Aangezien het geen automatische toegang tot het systeem geeft maar slechts de paginlocatie identificeert, zal een aanvalster zonder voet bij Figma de “Geen toegang” foutmelding terugkrijgen en verdergaan. Dit is een andere reden om tooling te omarmen om geheimen te identificeren, aangezien er platforms zijn die snel kunnen onderscheiden tussen een URL die een autorisatiesleutel bevat en een die er maar uitziet alsof dat zou kunnen.

3. Wat betekent Valide zijn?

Geldig, in ons gebruik, betekend dat een bepaalde getuigschap nog steeds werkt om toegang tot het gerelateerde systeem of gegevens te verlenen. Als een aanvaller deze vindt, kan hij direct gebruik maken van een geldig geheim. Terwijl ongeldige geheimen een aanvaller kunnen vertellen over de algemene architectuur en de met elkaar verbonden systemen, bieden alleen geldige geheimen hem een directe toegang tot deze resources. Dit soort laterale bewegingen kan moeilijk worden gedetecteerd.

4. Hoe moet ik weten welke geheimen de juiste zijn om naar te zoeken?

De beste antwoord is om elk geldig geheim te vinden en te verwijderen. Echter, zoals Spot the Secrets aantoont, is dit een moeilijk te lossen probleem zonder de juiste tools. Handmatige codereviews of tools die uitsluitend op eenvoudige patronen matchen, kunnen ertoe leiden dat u tijd besteedt aan het herstellen van reeds gevalideerde geheimen in plaats van te focusen op geldige gegevens. Verlopen sleutels zijn geen echte bedreiging, dus besteden u de inspanningen om ze te elimineren een lagere prioriteit dan de geldige inloggegevens die u ontdekt.

5. Wat is het verschil tussen een geheim en slechte geschreven code?

Aanvallers lezen waarschijnlijk niet uw code de meeste keren; ze scannen voor specifieke manieren om zo snel mogelijk breedere toegang te krijgen. Slechte geschreven code kan veel vulnerabiliteiten bevatten die een aanvaller kan gebruiken, vooral rondom Infrastructure as Code-configuratie. Echter, om deze fouten uit te kunnen profiteren, vereist een aanvaller tijd om de fout te begrijpen en een specifieke aanval uit te voeren tegen zulke problemen in plaats van alleen maar gebruik te maken van platte tekstgegevens.

Variabelen en gebruikersnamen kunnen deel uitmaken van een geavanceerder aanval. Bijvoorbeeld, gebruikersnamen en e-mails die in de code gevonden worden kunnen gebruikt worden in wachtwoord Spray-aanvallen of krachtige aanvallen, maar die zijn veel gemakkelijker vast te stellen dan direct gebruik van geheime gegevens en tijdrovend voor de aanvaller.

6. Maar Wat Doe Ik er Met als Ik Een Geheim Vind?

Eerst stopt u en ademt uit. Het gebeurt aan de besten onder ons, dus word niet te verdrietig als u een vrijgegeven geheim vindt. Het is goed om met spoed te handelen, maar panikeer niet en annuleer een gevonden geheim zonder te weten wat er zal gebeuren. Dat kan eenheid van andere problemen veroorzaken.

We raden aan de volgende weg te volgen:

1. Begrijp wat het geheim openbaat.
2. Bepaal hoe belangrijk elke geassocieerde gegevens of systeem is.
3. Controleer uw logboeken voor ongeautoriseerd gebruik van het geheim.
4. Bepaal of welke gegevens of service toegang is vrijgegeven.
5. Bekijk wat er zal misgaan als u het geheim wijzigt.
6. Wijzig het geheim en sla de nieuwe authenticatieve gegevens veilig op.
7. Opgelost of welke broken workflows of productie-uitvoeringen.
8. Beschouw de incident en maak een actieplan om verdere geheimlekage te voorkomen.

Lees meer over de herstelproces in het artikel, “Wat te Doen als U Een Geheim Uitlaat: Hoe U Kalm Blijft en Reageert op een Incident.”

7. Mijn Team Schrijft altijd de Git-geschiedenis Over als Een Geheim wordt Ontdekt. Is Dat Alles wat We Moeten Doen?

Helaas, nee. Hoewel we de stap voor het opschonen van Git graag vinden in het herstelproces, is het in feite de laatste stap en wordt door veel organisaties optioneel gezien. We raden aan dat alle geheime waarden die ooit in platte tekst zijn blootgesteld worden geroerd (zie de bovenstaande link voor advies over het herstelproces).

8. Ik verwijderd gewoon de repository uit de openbaarheid. Is dat niet genoeg?

Honestlijker gezegd, zou dit ons gegeven willen doen geloven, maar voor ons allemaal teleurstellend genoeg is het zo, dat zodra het openbaar is op GitHub, altijd als ge compromiseerde moet worden beschouwd. GitGuardian controleert elke nieuwe commit en elk isPublic gebeurende gebeurtenis die plaatsvindt over de openbare GitHub API.

Dit is hoe we ons jaarlijkse State of Secrets Sprawl rapport bouwen en de basis vormt voor de GitGuardian Public Monitoring offering. Terwijl onze bedoelingen zijn om de auteurs ervan te melden dat ze iets potentiëel gevaarlijks deden, zijn we niet de enige acteurs die deze openbare API monitoren. U moet altijd aannemen dat er een kopie is van elke code of bestanden die u ooit openbaar hebt gezet, gemaakt door iemand die u niet kent, en op een andere plek bewaard die u niets van weet. We raden altijd aan dat elke potentieel blootgestelde geheime waarde wordt geroerd.

9. Waarom is een foutief positief een probleem?

In ons Spot the Secrets oefening vragen we de gebruikers om alle geheimen te vinden die zijn geplaatst in 100 mogelijke commits, Jira, Slack en Log kaarten, waarbij er een tijdspenalty wordt opgelegd voor elk foutief positief. Elke kaart waar de speler denkt dat een kaart een geheim bevat terwijl dat niet het geval is, zal een boete van 10 seconden per fout krijgen.

Terwijl het in het beperkte bereik van de oefening lijkt dat voorzichtigheid en het markeren van zaken die geen geheimen bevatten een goed idee zijn, is de praktijk in de reële wereld een waardevolle tijd verspillen, zowel voor u, de melder, als voor elke persoon die verantwoordelijk is voor het werken aan een oplossing.

Elke tool of proces dat te veel falso positieven rapporteert leidt tot waarschuwingsvermoeiheid. Gebruikers worden overspoeld met waarschuwingen en beginnen ze te negeren. Dit leidt tot wantrouwen in de tooling en onregelmatig gebruik. Het kan ook de herstelproces verstoppen en betekenen dat sommige rapporteerde ware positieve geheimen niet op tijd worden opgelost.

10. Wat te maken heeft de bestandsnaam met het identificeren van een geheim?

Simpel gezegd: context. Generieke geheimen zijn vooral moeilijk te vinden door alleen maar patronen te matchen. Als er een langteken in een markdown-bestand staat, zijn onze bevindingen erop duidend dat het waarschijnlijk een voorbeeldwachtwoord is, dus hoeft u het waarschijnlijk niet aan te treffen. Als hetzelfde teken echter na de tekst password= verschijnt in een bestand genaamd project.env, dan is de kans groter dat u echt een geheim in handen heeft.

De bestandsnaam is maar een van de elementen die we meenemen bij Pre- en Post Validation in de GitGuardian Secrets Detection Engine en is een van de factoren die helpen we falso positieven te elimineren binnen de platform FP remover.

11. Doen mensen echt handmatige codereviews om geheimen te vinden?

Ja. Een volledige 27% van de IT-decisiemakers die we onderzocht hebben, zegt dat ze op handmatige codereviews vertrouwen om geheimenuitdagingen op te lossen, hoewel 75% van hen beweert dat ze een geheimlek hebben gehad.

Spot the Secrets is ontworpen om de problemen te tonen die zijn verbonden met de afhankelijkheid van mensen om deze problemen te identificeren. Machine zijn veel beter in patronen matchen door duizenden of miljoenen regels code.

Leren samen is precies waarom DEF CON over gaat

We hebben veel andere lessen geleerd bij DEF CON, inclusief het blijven hydrateren, minstens een paar uur slapen per nacht halen en ons binnen blijven bij temperaturen vanaf 110°F/43°C.

Er waren zoveel uitstekende talks op het programma; we kunnen niet wachten tot de video’s beschikbaar zijn om op te frissen over de inhoud die we gemist hebben terwijl we mensen hielpen te leren over Secrets Sprawl. Onderweg hebben we veel geleerd over hoe security mensen, ontwikkelaars en mensen in het algemeen deze problemen zien en over oplossingen denken. GitGuardian hoopt deze lessen op te nemen om het oplossen van dit probleem voor iedereen gemakkelijker en toegankelijker te maken.

Als je nooit eerder overging om naar DEF CON te gaan, raden we het bijnaamlijk aan, voor geen enkele andere reden dan om deel te nemen aan de AppSec Village en om uw stam te vinden op hacker-zomercamp.