Nog een code die in een kwaadaardige bedreiging veranderde

1 min. leestijd

Share

Onlangs verscheen er een voorbeeld van slecht geschreven code in de security community toen een programmeur de code van 7Zip evolueerde. Dit deed hij om te zien of de code aan zijn behoeften zou voldoen. 7Zip is gratis open source-software voor (de)compressie van ZIP- en GZIP-formaten.

Bij het beoordelen van de open source code merkte hij op dat er een zwakke random generator gebruikt werd, die een IV maakt om bestanden te versleutelen. Dit verlaagt de effectiviteit van het gebruikte encryption algoritme aanzienlijk en kan resulteren in een eenvoudiger pad om beveiligde bestanden te decoderen.

IV of ´Initialization-Vector´ wordt gebruikt om het coderingsproces te starten. Dit moet willekeurig en onvoorspelbaar zijn. In dit geval was de IV beperkt tot 8 bytes in plaats van de 16 die normaal vereist zijn voor sterke encryption (AES).

De slechte code werd ontdekt omdat de bron van het programma voor iedereen beschikbaar was, zogenaamde ´open source´ code. Je zou kunnen stellen dat een commerciële partij deze 'slechte' code niet zou durven uitrollen, laat staan dat het zijn broncode zou onthullen.

Naar mijn bescheiden mening maskeert gesloten code alleen het echte achterliggende probleem.

In dit geval wordt 7Zip gebruikt in verschillende open en gesloten (commerciële) software producten om bestanden te decoderen en te inspecteren. 7Zip kan bijvoorbeeld worden ingesloten in je Antivirus-scanner (of een ander product), waardoor deze software en dus jouw gegevens mogelijk in gevaar gebracht kunnen worden.

NPM Hijacking

Stel je voor dat je zelf de eigenaar bent van een mooi stukje code om een probleem op te lossen, en je dit online gepubliceerd hebt om anderen te helpen. Je hebt alleen geen tijd meer om de code te onderhouden. Wat zou je dan doen?

Decode verwijderen terwijl je weet dat veel anderen op die code vertrouwen? Of zou je de code gewoon aan een andere betrouwbaar ogend persoon overhandigen?

In dit geval heeft de eigenaar en maintainer van de code, dominictarr, voor de laatste optie gekozen. Hij heeft de code geschreven dat door veel NPM-gebruikers is toegepast.

Helaas besloot de nieuwe beheerder van de code om dominic direct uit zijn code opslag (repository) te verwijderen (wat enerzijds begrijpelijk is, maar de manier waarop zou betwistbaar kunnen zijn), om vervolgens door te gaan met het 'injecteren' van onduidelijke en kwaadaardige code. Een paar dagen later werd deze geïnjecteerde code volledig verwijderd.

Om te controleren of je door dit stuk code wordt beïnvloed, suggereerde een van de gebruikers om de volgende opdracht uit te voeren:

Wat betekent dit voor jou?

Het belangrijkste leerpunt van deze (en voorgaande vergelijkbare) incidenten is dat het niet de slechte code voorbeelden zelf zijn die de oorzaak vormen van dergelijke problemen, maar het gebrek aan bewustzijn over het bestaan van deze slechte code en, dat die code in jouw software gebruikt zou kunnen zijn zonder dat je er zelf weet van hebt.

"Slechte code" zoals deze zou zich dus zodoende vanaf het begin in je applicatie kunnen bevinden, simpelweg omdat je het gemist kan hebben bij het reviewen van de broncode voordat je besloot om deze in je eigen of reeds gelanceerde software te gebruiken.

Een aantal aandachtspunten en misvattingen voor het gebruiken van 'goede’ open-sourcecode:

"Ik gebruik open source-code in mijn producten. Dus wat moet ik doen aan dit probleem?"

  • Code-evaluaties moeten deel uitmaken van het proces van wie dan ook die eigen software ontwikkelt. Review daarnaast de stukjes code die door anderen geschreven zijn waar jouw software op vertrouwt. Het gebruik van open source is fantastisch, omdat het je de mogelijkheid biedt om de code op zijn minst te herzien en zodoende te bepalen of het aan jouw behoeften voldoet, om de code te testen door stukjes code te bekijken of zelfs te herschrijven wanneer jij dat belangrijk of noodzakelijk acht. Zorg er zodoende voor dat de code overeenkomt met de richtlijnen voor informatiebeveiliging binnen jouw organisatie.
  • Mirror repository's en implementeer version-pinning om jezelf te beschermen tegen (on-)opzettelijke code-injecties zoals geschetst in het voorbeeld, wanneer je een nieuwe versie ontwikkelt en deze in 'the wild' implementeert. Het vastzetten van handmatige versies lijkt misschien verleidelijk omdat het bijna geen extra kosten met zich meebrengt, maar dit kan behoorlijk ingewikkeld worden om te onderhouden en kan nog meer risico's opleveren.
  • Onderhoud een sterke relatie met leveranciers die deel uitmaken van jouw kernprocessen. Dit heeft betrekking op de betrokkenheid tussen de klant en verkoper of de klant en een open source community. Zoals de bovenstaande NPM-casus aantoonde, kan het ontbreken van een financieel belang voor de open source-ontwikkelaar ertoe leiden dat de oorspronkelijke beheerder de code 'unmaintained' achter laat. Dat terwijl jij er wel nog steeds op vertrouwt. Iemand motiveren om zijn eigen (en open source) codering kritisch te bekijken, helpt dan ook om de algehele kwaliteit te verbeteren en kan de ontwikkeling van jouw eigen producten vergemakkelijken, doordat de beheerder logica blijft toevoegen of belangrijke problemen via nieuwe patches op blijft lossen.

“Ik gebruik closed software dus ben ik toch veilig?”

Helaas niet

Je hebt alleen iemand anders gevonden een deel van de schuld op af te schuiven. Closed source software biedt geen standaard tools aan om de code zelf te reviewen. Ondertussen kan het wel zo zijn dat je product nog steeds beschikbaar is ondanks de breach. Hierdoor kan (zelfs gevoelige) data gelekt zijn. Het hebben van een bedrijf dat software voor je maakt vrijwaart je dan ook niet van enige (financiële) schade die kan optreden als gevolg van zo'n kwaadwillige code. Jij bent de gegevensverwerker. Dat betekent dat je jezelf in dit scenario niet achter je leverancier kan verschuilen en daar de schuld op af kan schuiven.

Met open source code kan je in zo'n geval besluiten om je eigen code te patchen om bepaalde risico's te minimaliseren, zónder dat je moet wachten op een uitgebrachte patch van of door een andere partij. Want als je hierop wacht, accepteer je tevens de tijdelijk ontstane risico's.

"Ik gebruik alleen cloudproducten, dus er is niets om mij zorgen over te maken ..."

Wist je dat de meeste Cloud- en SaaS-producten ontwikkeld zijn op basis van open source en dat closed source tooling duizenden regels code bevat..? Dat houdt in dat er in de beschreven situaties een overtreding kan plaatsvinden.

Het 'goede' van cloudproducten is dat je zeker niet de enige bent die in zo'n wordt getroffen. Wanneer je de overeenkomst voor gegevensverwerking tussen jou en de cloud- / SaaS-provider hebt, ben je tot op zekere hoogte verlost van een bepaald niveau van verantwoordelijkheid, en dus ook enige financiële impact die kan ontstaan door deze schadelijke code. Toch ben je in de ogen van eindgebruikers nog steeds de partij die klantengegevens lekt. Als je het probleem dus niet op tijd en onduidelijk communiceert richting klanten, kan dit uiteindelijk alsnog een averechts effect hebben en reputatieschade opleveren.

Met andere woorden: Be Aware

Accepteer dat er 'bad code' is en bereid je voor op hacks, social engineering of ontevreden (ex-) werknemers. Een van deze scenario's kan op een gegeven moment voorkomen. Beperk dan ook de beperken, door te plannen, communicatie scenario's uit te werken en door stappen te definiëren om forensic data te beveiligen.

Het begint allemaal met bewustzijn. Dus laten ons je helpen om goed voorbereid en bewust te zijn. Plan bijvoorbeeld een trainingssessie in of registreer jezelf voor een van onze Security Awareness-trainingen, een Cyber Security Assessment of Nomios Security Cleanups.

Meld je aan voor onze nieuwsbrief

Ontvang het laatste security nieuws, inzichten en markttrends in jouw inbox.

Artikelen

Meer updates