Code-injectie
Bijna dagelijks worden nieuwe kwetsbaarheden in software gevonden. De impact van een kwetsbaarheid is afhankelijk van twee dingen: het gemak waarmee de kwetsbaarheid uitgebuit kan worden en het schade die een aanvaller ermee kan aanrichten als dat gelukt is.
De meest gebruikte methode hierbij is code-injectie. De aanvaller gebruikt daarbij speciaal geconstrueerde code als invoer, bijvoorbeeld via een tekstveld waarin een gebruiker normaal gesproken iets typt. Als de software inderdaad kwetsbaar blijkt te zijn, hoopt de aanvaller op een onbedoeld neveneffect: de software doet als het ware de deur voor de aanvaller open, zodat de aanvaller eigen code kan laten uitvoeren en gegevens kan stelen om uiteindelijk geld mee te verdienen.
Omdat ook Pandosearch potentieel gevoelig is voor code-injectie, hebben we ons hier al sinds de allereerste versies tegen gewapend. Zoals gezegd zit het belangrijkste potentiële probleem bij de invoer die bij een applicatie binnenkomt. Pandosearch moet onbekende invoer verwerken op twee manieren: tijdens het crawlen van websites (het verzamelen van de informatie die wij indexeren) en tijdens het bevragen van onze API (het verwerken van zoekvragen). Bij beide processen kan Pandosearch te maken krijgen met kwaadaardige code.
Crawlen van websites
Tijdens het crawlen van een website hanteren wij een aantal maatregelen om te voorkomen dat potentieel gevaarlijke code in Pandosearch wordt opgeslagen. Zo limiteren wij ons altijd tot het enkel indexeren van content die van het met de klant afgesproken domein komt, ook al staan er verwijzingen op een webpagina naar een ander domein.
Stel dat Pandosearch de domeinnaam www.pandosearch-klant.com indexeert, en we komen daar links tegen naar www.potentiele-aanvaller.com, dan zullen wij die links niet volgen, opvragen of opslaan. Wij garanderen zo dat we enkel de data van de originele website verwerken – data die onder het beheer en verantwoordelijkheid van onze klant op internet gepubliceerd is.
Daarnaast verwijderen we zoveel mogelijk niet-essentiële data voordat wij overgaan tot het indexeren van een website. Denk aan plaatjes, uitklapmenu’s, repeterende headers en footer en zeker ook alle JavaScript code. Standaard verwijderen we alles behalve “schone” tekst, alleen in specifieke gevallen maken we hier uitzonderingen op. Zo houden we alleen het minimaal noodzakelijke over om de website goed doorzoekbaar te maken en houden we kwaadaardige code uit onze interne opslag.
Bevragen van onze API
Onze Pandosearch API is ons contact met de buitenwereld. De webserver van onze klant of de browser van de websitebezoeker vraagt via onze API suggesties en zoekresultaten om die vervolgens te tonen aan websitebezoekers.
Zo’n verzoek aan de Pandosearch API gaat via een klantspecifiek webadres (URL) waar parameters aan mee kunnen worden gegeven. Die parameters bestaan uit de zoekterm die de websitebezoeker heeft ingetypt, samen met enkele aanvullende opties. Het zijn deze parameters die een potentieel risico vormen. Ze zijn immers niet onder onze controle, want wij bepalen niet wat een bezoeker intypt. Een aanvaller kan daarom ook via deze weg proberen om kwaadaardige code aan de API te leveren in die parameters, in de hoop dat Pandosearch die code verkeerd verwerkt waardoor de aanvaller toegang krijgt tot onze systemen.
In de Pandosearch rapportages in onze beheeromgeving is ook terug te zien dat er soms pogingen van aanvallers zijn. Dit gebeurt al dan niet met behulp van geautomatiseerde “hacksoftware” die allerlei rare tekens, codefragmenten of grote getallen bij Pandosearch aanlevert als zoekopdracht. Heel vervelend natuurlijk, maar inmiddels helaas dagelijkse kost voor bijna elke softwareleverancier.
Inputvalidatie: het belangrijkste wapen
Ons belangrijkste wapen om dergelijke aanvallen onschadelijk te maken is inputvalidatie. Wij beoordelen élke aangeleverde parameter op inhoud en doen dat voor zowel de zoektermen als de overige zoekparameters.
De eerste stap is het ontsmetten. We weten dat wij alleen zoekparameters verwachten die bestaan uit reguliere letter- en cijfertekens en interpunctie. Alle mogelijke exotische tekens, zoals accolades, kleiner-dan en groter-dan tekens en stuurcodes worden tijdens het ontsmetten verwijderd uit de invoer. Hiermee voorkomen we al een heleboel, omdat kwaadaardige code vaak juist dat soort tekens bevat.
De technische gebruikers van Pandosearch kunnen dit ook in onze antwoorden terugzien: in onze API resultaten vermelden wij wát we precies hebben overgehouden na de ontsmetting.
Hoe dit werkt kunnen we laten zien met een voorbeeld met de kenmerken van de log4j exploit, die ook gebruik maakt van accolades. Als je via de Pandosearch API zoekt op de volgende potentieel kwaadaardige zoekterm:
${malicious-code protocol://uri}
Dan blijft daar na ontsmetting het volgende van over:
malicious-code protocol uri
Hiermee is de kwaadaardige code dusdanig ontsmet dat er van kwaadaardige code geen sprake meer is.
Voor de overige zoekparameters voeren we hierna nog een tweede stap uit: we controleren of het een ons bekende of een logische waarde is. Zo is het bijvoorbeeld mogelijk om middels de size zoekparameter aan te geven hoeveel zoekresultaten Pandosearch moet teruggeven. In het geval dat wij iets anders dan een getal ontvangen voor size negeren wij dit compleet en gebruiken we de standaardwaarde. In het geval van size is dit 10 tenzij dit anders is geconfigureerd.
Een andere mogelijke zoekparameter is bijvoorbeeld het filteren met een facetwaarde. Voordat wij proberen te filteren, checken we eerst in de configuratie of dit wel een geconfigureerd facet is. Zo niet, dan negeren wij die zoekparameter en gebruiken we die niet om de zoekvraag te beïnvloeden.
Praktijkervaringen
Dat we al dit technische opschoonwerk doen is mooi, maar werkt het ook in de praktijk? Tot nu toe blijkt dat Pandosearch is gewapend tegen de meest gebruikelijke manieren van aanvallers om kwetsbaarheden in software uit te buiten. Een paar voorbeelden:
- In de afgelopen jaren is Pandosearch succesvol door de beveiligingstests gekomen van diverse grote klanten met strenge eisen aan informatiebeveiliging.
- In diezelfde periode heeft Pandosearch nog geen enkele keer te maken gehad met een beveiligingsincident waarop acuut actie nodig was van onze kant.
- Recentelijk heeft een gerenommeerd beveiligingsbureau op verzoek van één van onze klanten meerdaagse aanvallen georchestreerd op Pandosearch. Uit hun tests kwam ook de conclusie dat Pandosearch geen onaanvaardbare beveiligingsrisico’s neemt.
Conclusie
Al met al kunnen wij op dit moment gelukkig zeggen dat wij geen last hebben van de recent bekend worden Log4jk kwetsbaarheid. Ook in bredere zin blijkt vooralsnog in de praktijk dat Pandosearch afdoende beveiligd is. We zeggen “vooralsnog”, want we weten ook dat er continu nieuwe kwetsbaarheden ontstaan en dat 100% veiligheid een illusie is. Waakzaamheid blijft dus geboden en informatiebeveiliging heeft om die reden ook structureel onze aandacht.
Tot zover voor nu. Mocht je na het lezen van dit artikel voor je specifieke situatie vragen hebben of heb je het vermoeden dat wij iets over het hoofd zien, laat het ons vooral weten via support@pandosearch.com.
