Ze zeggen dat programmeren het dichtst bij magie komt dat we vandaag de dag hebben. En weet u wat? Ze hebben gelijk. Een paar regels code die voor een leek niets meer lijken dan onzin – en u kunt er complete werelden mee creëren. Hoe kan dat anders zijn dan magie?
Aan de andere kant kunnen een paar andere regels code de meest ingewikkelde beveiligingssystemen creëren. Maar hoe ingewikkelder ze zijn, hoe harder ze vallen. Daar komen de bedreigingen voor softwarebeveiliging om de hoek kijken. Bedreigingen zoals security misconfiguration maken systemen, groot en klein, kwetsbaar voor allerlei cyberaanvallen.
Is security misconfiguration echter de meest dringende bedreiging? En wat houdt deze, eerlijk gezegd, wat vage term überhaupt in? Lees verder om erachter te komen.
Security misconfiguration: uitleg, voorbeelden, preventie
Een vangnetterm (tot op zekere hoogte) dekt security misconfiguration beveiligingscontroles die onveilig zijn achtergelaten of verkeerd zijn geconfigureerd, waardoor de gegevens en soms het hele systeem in gevaar komen. Simpel gezegd, elk technisch probleem in een component dat voortkomt uit de configuratie-instellingen van de app en niet uit slechte code, kan worden geclassificeerd als een kwetsbaarheid voor security misconfiguration.
Verkeerde standaardinstellingen, slordig gedocumenteerde configuratiewijzigingen, onjuiste machtigingen, noem maar op – ze vallen allemaal onder deze paraplu.
De meest voorkomende fouten komen meestal voort uit de simpelste vergissingen (zoals de onderstaande voorbeelden). Maar er is niets simpels aan de gevolgen die organisaties vaak ondervinden door deze fouten. Van blootstelling van gevoelige gegevens tot volledige overname van servers, webpagina’s en applicaties, security misconfiguration heeft in het verleden enorme schade toegebracht aan talloze bedrijven. En gezien de nummer 5 positie op de OWASP top 10 van webapplicatiebeveiligingsrisico’s die deze bedreiging vorig jaar behaalde, zal deze niet verdwijnen. U kunt dus hopen dat het u mist, of u kunt meer leren over security misconfiguration, inclusief hoe u het kunt voorkomen en beheren.
Klinkt goed? Laten we dan beginnen.
Hoe security misconfiguration ontstaat
Zoals we eerder hebben geleerd, zijn er complexere en ongebruikelijke redenen voor kwetsbaarheden door security misconfiguration, maar er zijn ook enkele ongelooflijk eenvoudige en veelvoorkomende. De laatstgenoemde omvatten:
Debugging ingeschakeld
De meeste bedrijven werken met aparte omgevingen. Stel u voor: u schakelt debugging in een ontwikkelomgeving in om het debugproces te versnellen. Niets ongewoons, toch?
Maar het is ook niets ongewoons om te vergeten deze kleine functie uit te schakelen voordat de productiefase aanbreekt. Aanvallers hoeven dus alleen maar de gedetailleerde foutmeldingen te activeren die interne gegevens bevatten, en voilà, ze zijn BINNEN.
Standaard credentials
Een triviale zorg vaker wel dan niet, maar standaard credentials kunnen soms ook serieuze schade aanrichten. En negen van de tien keer is security misconfiguration de schuldige.
U ziet, standaard credentials worden meestal geleverd bij een groot aantal ingebouwde oplossingen. Deze zijn te vinden in webapps, verschillende netwerkapparaten, vrijwel alles dat authenticatie vereist. En als u ze niet wijzigt nadat u klaar bent met de installatie, opent u de deuren wijd open. En, wie had gedacht, de eerste mensen die door deze deuren lopen, zijn meestal hackers.
Verkeerd geconfigureerde permissies
Nalatigheid. Het is altijd nalatigheid. Maar ja, zelfs de beste ontwikkelaars vergeten soms de juiste machtigingen in te stellen voor blootgestelde (ook publieke) mappen, beheerdersconsoles en dashboards. Dus zelfs de minst bekwame hackers hebben probleemloos toegang tot deze ongeautoriseerde bestanden.
Nu denkt u misschien dat het probleem hier een broken access control exploit is, maar dat is niet het geval. Nee, BAC is het resultaat, maar de schuldige hier is een security misconfiguration probleem. Het was aanwezig voordat de module een webapp-functie bereikte, het is gewoon dat u het meestal pas in dat stadium ontdekt.
Cloud misconfiguratie
Cloud is een prachtig iets. Dankzij cloudopslag en bestandsdeling kunnen kleine bedrijven en machtige ondernemingen in een paar minuten hele datacenters opzetten, allemaal zonder zich zorgen te maken dat ze mogelijk niet over de benodigde middelen beschikken.
Maar met grote vrijheid komt grote… u kent de clou wel. Meer dan dat, de bedrijven die deze oplossingen gebruiken, moeten het gedeelde verantwoordelijkheidsmodel volgen. Dat wil zeggen, wat er in de cloud gebeurt blijft in de cloud is de verantwoordelijkheid van de klant, niet die van de eigenaren van de clouddienst.
Wat dat ook betekent is dat, of u het nu leuk vindt of niet, de inbreuken die plaatsvinden als gevolg van security misconfig in de cloud zullen blijven opduiken. Om u een snel voorbeeld te geven van een kwetsbaarheid door security misconfiguration: alleen al de Amazon S3 misconfiguraties leverden meer dan 400.000 Google-resultaten op, waaronder beveiligingsinbreuken van de grootste namen in het spel.
Hardware misconfiguratie
Aan de andere kant kunnen netwerk- en diverse beveiligingsapparaten ook verkeerd worden geconfigureerd, wat zowel later als direct problemen veroorzaakt.
Wat vrij frequent voorkomt, is dat netwerkingenieurs een beetje laks zijn met de configuraties van netwerkapparaten. En, we begrijpen het, het oplossen van netwerkproblemen kan een sleur zijn. Maar dat is geen reden om de volgende beveiligingsconfiguratie te vergeten.
Want als u dat niet doet (of als u het halfslachtig doet), hebben aanvallers mogelijk de kans om toegang te krijgen tot interne assets, reverse shells zonder beperkingen uit te voeren, en meer. Bovendien kunnen verkeerd geconfigureerde oplossingen zoals IPS, SIEM en IDS verdere beveiligingskwetsbaarheden creëren. Om er één te noemen: als u vergeet een bind shell in te stellen tijdens de interventie, zullen hackers geen moeite hebben om uw webpagina te bezoedelen.
En dit is nog maar het topje van de ijsberg. Kwetsbaarheden door security misconfiguration ontstaan ook door:
- Het inschakelen van onnodige (meestal standaard) functies zoals nutteloze services, accounts, privileges, poorten, pagina’s, noem maar op
- Werken met onveilige headers en mappen of deze instellen op onveilige waarden
- Het negeren van de beveiligingsinstellingen (wat ook betekent dat u ze NIET op veilige waarden instelt) in de app servers, app frameworks, bibliotheken, databases, etc.
- Het gebruik van kwetsbare en/of verouderde componenten (wat, trouwens, direct na security misconfiguration komt op de bovengenoemde top 10 webapplicatiebeveiligingsrisico’s van OWASP)
- Het niet implementeren van adequate beveiligingsmaatregelen over de hele app-stack (vrijwel elk deel ervan)
- En, last but not least, het niet uitschakelen van standaardaccounts met standaardwachtwoorden (ja, geloof het of niet, dat gebeurt ENORM veel).
Klinkt het toch een beetje vaag? Laten we een paar voorbeelden van aanvalsscenario’s door misconfiguratie bekijken.
Mogelijke aanvalsscenario’s
De app server wordt geleverd met voorbeeldapplicaties die niet van de productieserver zijn verwijderd. Vaak bevatten deze voorbeeldapplicaties bekende beveiligingsfouten, beveiligingsfouten die aanvallers kunnen misbruiken om uw nieuwe server te compromitteren. Stel dat een van deze apps een beheerdersconsole is met ingeschakelde standaardaccounts. In dat geval hoeven hackers alleen maar die console te benaderen met een standaardwachtwoord en, dat is alles, hij is nu de *kapitein*.
De directory listing is niet uitgeschakeld. Opnieuw een niet ongewoon scenario, hoe ongelukkig het ook is. Hackers onderzoeken servers als eerste op deze kwetsbaarheid. Dus, stel dat ze ontdekken dat ze eenvoudig directories kunnen opsommen. Een beetje ingewikkelder, maar ervaren aanvallers zullen dan geen moeite hebben om de gecompileerde Java-klassen te vinden en te downloaden. Vanaf daar kunnen ze deze klassen decompileren en reverse-engineeren om de servercode te bekijken. Op dit punt is het vinden van een kritieke toegangscontrolefout in de app een kwestie van *wanneer*, niet van *of*.
De app server is geconfigureerd om gedetailleerde foutmeldingen (zoals stack traces) aan gebruikers terug te geven. In dit scenario kunt u allerlei onderliggende kwetsbaarheden blootstellen. Gevoelige informatie, zeker, maar ook de componentversies met bekende kwetsbaarheden. Als ze dat ontdekken, is er geen limiet aan wat hackers mogelijk met uw server kunnen doen. En, zoals u kunt raden, alles wat ze hoeven te doen (en waarschijnlijk zullen doen) is deze gedetailleerde foutmeldingen aanvragen, wat kinderspel is.
De *cloud* heeft standaard deelpermissies openstaan (en beschikbaar voor iedereen die aardig genoeg is om te vragen) door andere gebruikers van de dienst. Herinnert u zich het gedeelde verantwoordelijkheidsmodel dat we eerder noemden? Ja, die. Het betekent dat het soms niet eens u hoeft te zijn. Het is voldoende dat een van uw *cloudburen* vergeet de standaardpermissies uit te schakelen en, door ze te gebruiken, cybercriminelen uw gevoelige gegevens binnen deze cloudopslagdienst kunnen benaderen. Afhankelijk van deze permissies kunnen hackers mogelijk zelfs hoog niveau toegang tot het systeem krijgen.
Denkt u dat dit slechts hypothetische situaties zijn die in het echte leven niet voorkomen? Denk nog eens na.
Echte voorbeelden van security misconfiguration
Kwetsbaarheden door security misconfiguration zijn zo oud als beveiligingsmaatregelen zelf, dus we hebben in het verleden talloze voorbeelden gezien. Hier zijn er een paar:
Het NASA/Jira-incident
Je zou denken dat een van de meest technologisch geavanceerde en vooruitstrevende bedrijven ter wereld het beter zou weten. Helaas deden ze dat niet.
Het kostte slechts één nederige beveiligingsenthousiast om een security misconfiguration te identificeren in het grootste (en misschien wel meest gehate) samenwerkingstool dat er is – Jira. Dit ene moment van standaard autorisatie misconfiguratie liet meerdere Fortune 500-bedrijven, waaronder NASA, kwetsbaar achter. Via deze kwetsbaarheid konden derden toegang krijgen tot interne gebruikersgegevens, waaronder namen, e-mailadressen, projectdetails en andere gevoelige informatie.
Wat gebeurde er? Toen Jira dashboards en filters voor individuele problemen of hele projecten ontwikkelde, werden de zichtbaarheidsinstellingen standaard ingesteld op Alle gebruikers en Iedereen. Uiteraard zouden zaken als roadmap-taken idealiter binnen de organisatie gedeeld moeten worden, maar het “geliefde” Jira deelde ze met het publiek.
Belangrijkste les: Zorg ervoor dat u de configuraties voor het delen van bestanden controleert in elke SaaS die u gebruikt om blootstelling van vertrouwelijke gegevens te voorkomen.
Amazon S3-fouten
Amazon’s Simple Storage Service, ook wel bekend als Amazon S3, is vaker door hackers misbruikt dan wie kan tellen. Van de verkeerd geconfigureerde S3-bucket die 50.000 patiëntgegevens in de VS onthulde tot de buckets die meer dan 80 Amerikaanse gemeenten blootlegden, de aanvallers spaarden niemand.
Zelfs de United States Army Intelligence and Security Command heeft in het verleden verschillende gevoelige bestanden gelekt als gevolg van Amazon S3, waaronder OVA (Oracle Virtual Appliance) volumes met delen gemarkeerd als top *secret*.
Belangrijkste les: Het feit dat honderden bedrijven (waaronder militaire en overheidsinstanties) vertrouwen op Amazon S3, betekent niet dat het veilig is. In feite, kijkend naar de tientallen beveiligingsincidenten in het verleden, moet u de autorisatie van de service zorgvuldig controleren als u besluit deze te gebruiken.
Hoe security misconfiguration te voorkomen
Herinnert u zich hoe security misconfigurations ontstaan? Ja, dat is wat u moet vermijden. Met andere woorden:
Schakel Debugging Uit. Wanneer u de app van de ontwikkelingsfase naar de productiefase verplaatst, zorg er dan voor dat u alle debugfuncties in de gehele configuratie dubbel controleert. Dat klopt, ze moeten ALLEMAAL uitgeschakeld zijn.
Wijzig Standaard credentials. Het eerste wat u moet doen zodra u een stuk software hebt geïnstalleerd, is de standaard credentials wijzigen. Sterker nog, we raden aan om dit een verplichte gewoonte te maken binnen uw bedrijf.
Beperk Toegang tot Beheerpanelen & Consoles. De tweede verplichte praktijk die u bedrijfswijd moet implementeren, is het uitschakelen van toegang tot beheertools vóór de implementatie. Uiteraard mogen alleen die gebruikers die ze nodig hebben er toegang toe hebben. Zorg er ook voor dat u deze praktijk naleeft met systematische audits.
Schakel Directory Listing Uit & Verifieer Directory Machtigingen. De geïmplementeerde app mag geen directory listing toestaan, simpelweg. Bovendien moet u ervoor zorgen dat de machtigingen op afzonderlijke mappen en bestanden correct zijn ingesteld.
Handhaaf Herhaalbare Beveiligingsmaatregelen. Wanneer deze correct is geconfigureerd, maakt een herhaalbaar beveiligingsproces het implementeren van andere omgevingen (die ook correct zijn afgesloten) snel en eenvoudig. Zorg er dus voor dat de ontwikkelings-, QA- en productieomgevingen identiek zijn geconfigureerd, met verschillende credentials voor elke omgeving. Automatiseer het en u kunt moeiteloos nieuwe veilige omgevingen opzetten.
Gebruik een Gesegmenteerde App Architectuur. Een gesegmenteerde app architectuur zorgt voor een effectieve en, nog belangrijker, veilige scheiding tussen zijn componenten en tenants. Naast segmentatie moet de architectuur containerisatie en/of cloud security groups (ACL’s) bevatten.
Houd het Platform Schoon. Verwijder alle onnodige functies, componenten, documentatie en voorbeelden. Naast dat ze in wezen nutteloos zijn (vandaar het ‘onnodige’ deel), vormen ze ook een beveiligingsrisico. Verwijder ook alle frameworks die u niet gebruikt. Idealiter had u ze in de eerste plaats niet moeten installeren.
Laten we samenvatten
Security misconfiguration is een overkoepelende term voor elke onveilige of verkeerd geconfigureerde beveiligingscontrole. Wanneer deze wordt misbruikt, stelt het hackers in staat toegang te krijgen tot vertrouwelijke informatie of de controle over de gehele webpagina, server of app over te nemen. De impact van security misconfiguration heeft in het verleden talloze giganten lamgelegd. Zorg er dus voor dat u zich op dit onderwerp voorlicht en volg de tips voor het voorkomen van security misconfiguration die we hierboven hebben besproken. Veilige reis en moge de kansen altijd in uw voordeel zijn.
Configureer het correct: de ultieme cheat sheet voor het voorkomen van security misconfiguration
