Zo dan, dat is een flink complexe en bovenal lange naam voor een kwetsbaarheid. Toch staat deze op nummer 9 in de OWASP top-10. Het ‘grappige’ aan deze kwetsbaarheid is dat hij qua technische complexiteit heel erg simpel is maar toch nagenoeg overal voorkomt. Hoe dat in elkaar steekt dat lees je uiteraard deze week weer in de blog. Heb je de voorgaande edities van onze OWASP top 10 blog gemist? Die vind je hier. Volgende week alweer de allerlaatste!
Wanneer de organisatie waar u voor werkt aangevallen wordt dan hoop u onbewust misschien wel ‘laat het zo’n complexe, briljante aanval zijn dat wij het nooit hadden kunnen detecteren’. Op die manier is het voor de organisatie namelijk mogelijk om wat imagoschade te voorkomen. Stel je voor dat de hacker een nieuwe zero-day kwetsbaarheid heeft gevonden of een exploit heeft gemaakt die nog nooit iemand heeft gezien. Dat zou wel zo fijn zijn want dan lag het in ieder geval niet aan u of aan de IT-afdeling. Het is echter veel waarschijnlijker dat de aanvaller gebruik heeft gemaakt van bekende kwetsbaarheden die mogelijk al maanden of zelfs jaren in het systemen aanwezig zijn. Aanvallers voeren geautomatiseerde scripts uit om webapplicaties te onderzoeken op bekende kwetsbaarheden om vervolgens de ontdekte zwakheden te exploiteren.
Ik zei het toch, deze week wordt het technisch niet zo heel complex. Dit heeft alles te maken met het feit dat de aanvaller liever lui dan moe is en gewoon profiteert van achterstallig onderhoud. Vooral als ze gemakkelijk beveiligingsfouten kunnen vinden binnen een van uw applicaties of de afhankelijkheden van applicaties. Het gebruik van componenten met bekende kwetsbaarheden was de oorzaak van enkele van de meest significante inbreuken tot nu toe, en de lange termijn status op de OWASP Top 10- lijst weerspiegelt dit. De kwetsbaarheid ‘compontents with known vulnerabilities’ staat namelijk al geruime tijd op die lijst.
Hoe kan het dan zo zijn dat deze kwetsbaarheid zo simpel is en toch zo moeizaam te verhelpen? Op de vraag ‘Wat is Using Components with Known Vulnerabilities?’ is eigenlijk een heel simpel antwoord te geven. De dreiging komt bij de organisatie niet voort uit een onbekende zwakte maar uit de complexiteit van de webapplicatie zelf. Veel mensen denken dat apps over unieke code beschikken en handmatig door een genie in elkaar zijn gezet. Sorry, maar nee. De meeste code in een moderne webapplicatie is niet origineel of intern gebouwd. Het is een losse verzameling van door derden gebouwde en verpakte onderdelen die aan elkaar zijn geplaveid: API’s, microservices, bibliotheken, open source en legacy-code.
Om de boel functioneel te houden zitten er ook nog verschillende sub componenten in die onderhouden moeten worden. De meeste beveiligingsfouten in apps ontstaan dus door afhankelijkheden van ondersteunende software met bekende problemen. Soms worden deze over het hoofd worden gezien, als risico geaccepteerd of gewoon niet goed onderhouden. Een klein bruggetje naar enkele van de vorige blogs, vaak zijn deze kwetsbaarheden die dan worden gevonden gerelateerd aan Cross Site Scripting en SQL-Injecties. Het probleem met deze kwetsbaarheid is dat mensen het nog niet zijn als iets waar voor opgepast moet worden. Men ziet een app en denkt ‘wauw een app’ dit is vast grondig getest en de maker weet precies wat hij heeft gedaan. Wederom fout. Zie het als een tweedehands auto. Aan de buitenkant ziet het er wel ok uit en toen je eens tegen de banden schopte was het ook nog prima. Van de motor heb je echter geen verstand dus maar niet naar gekeken. Nu sta je stil langs de A15. Datzelfde kan dus gebeuren met je hele systeem als je niet weet wat voor een code er allemaal draait en aanwezig is.
Het antwoord op die vraag is heel erg simpel en u voelt het al aankomen. Besteed tijd en aandacht aan een kwetsbaarheidsbeheerproces en vergaar gedetailleerd inzicht in welke webapplicaties u gebruikt. Pas dan kunt u iets zeggen over mogelijke kwetsbaarheden. Zie het als een map. Zonder dat je weet waar je heen wilt heeft het geen zin een route uit te tekenen. Het oplossen van dit veelvoorkomende probleem begint dus bij inventarisatie. Welke functies hebben de web applicaties binnen uw organisatie? Praten ze met elkaar? Zo ja, hoe dan? En van welke bibliotheken zijn ze afhankelijk? Het is onmogelijk om grootschalige beveiligingsverbeteringen aan te brengen in een webapplicatie zonder een basiskennis van wat het doet en hoe informatie er doorheen stroomt.
Nu u de verwachte functionaliteit van die toepassing kent, moet u het vet bijsnijden. U moet ongebruikte afhankelijkheden, onnodige functies, niet-verwezen bestanden en documentatie verwijderen . Dit verkleint het aanvalsoppervlak van uw applicatie, maar het maakt het onderhoud van uw applicatie ook gemakkelijker. Daarna moet u uw applicaties blijven monitoren op end-of-life (EOL) -software en niet-onderhouden frameworks en bibliotheken. Eenmaal gedetecteerd, moeten deze afhankelijkheden zo snel mogelijk worden verwijderd. Nu al het overtollige vet is verwijderd, moet een proces worden ontwikkeld om de componenten die verouderd zijn of waarvan bekend is dat ze kwetsbaar zijn, bij te werken. Tot slot dient u dit veilig en schoon te houden. Dit betekent dat u moet voorkomen dat kwetsbare componenten in de web applicatie worden geïntegreerd. Wanneer u nieuwe afhankelijkheden toevoegt, moet u deze alleen via officiële bronnen via beveiligde kanalen aanschaffen. Nieuwe componenten mogen alleen worden opgenomen als ze echt een functie bieden die niet wordt ondersteund door iets anders binnen de applicatie.
Als u deze stappen volgt dan beschikt u over een gedegen proces om componenten met bekende kwetsbaarheden uit uw applicatie te verwijderen. Een bijkomend voordeel is dat u nu tevens inzichtelijk heeft wat er allemaal draait binnen uw organisatie en wat het doet. Die kennis is waardevoller dan u misschien nu zou denken. Heeft u dit nu zitten lezen en twijfelt u nu aan de hygiëne van uw organisatie op dat gebied? Neem dan eens contact op met ons. Wij ontvangen graag uw mailtje op [email protected] of uw telefoontje op 036 760 0451.
Automated page speed optimizations for fast site performance