Twee securityontwikkelaars aan de universiteit van Tel Aviv hebben een wijziging voor de Linux-kernel ontwikkeld waarmee dat besturingssysteem het gedrag van serverapplicaties keurt. Indien een applicatie zich verdacht gedraagt, wordt deze automatisch stopgezet.
Een securityonderzoeker aan de universiteit van Tel Aviv heeft onder begeleiding van de Israelische professor Avishai Wool een monitoring-programma ontwikkeld voor Linux. Het is een aanpassing in de kernel van het besturingssysteem wat daardoor het gedrag van applicaties in de gaten kan houden. Dit moet beveiliging verbeteren door buffer overflows en code injection-aanvallen te onderscheppen. Deze aanpak heeft wel het risico van valse negatieven, dus onterechte identificatie van malware.
Het programma heet Korset en is in wezen een model dat voorspelt hoe serverapplicaties zich dienen te gedragen. Afwijkingen van die norm zouden neerkomen op handelingen van kwaadaardige code en die software wordt dan automatisch stopgezet. Korset maakt vooraf een overzicht van de te beschermen applicatie waarin het gedrag daarvan wordt vastgelegd. De ondersteuning voor applicaties is nu echter nog vrij beperkt. Een vroege proefversie van Korset is gratis beschikbaar onder de opensourcelicentie GPLv3.
Wapenwedloop
Wool is mede-oprichter en cto (chief technical officer) van beveiligingsbedrijf AlgoSec. Hij stelt dat reguliere antivirussoftware het onderspit delft in de huidige wapenwedloop tussen beveilgingssoftware en malware. Leveranciers van antimalware halen met hun detectienetwerken volgens hem alleen de reguliere plagen binnen.
Ze lopen dan ook nog achter de feiten aan met het bijwerken van hun beveiligingssoftware voor die gedetecteerde kwaadaardige code, aldus Wool. Ondertussen wordt malware steeds meer doelgericht en minder zichtbaar. Dit als direct gevolg van de criminalisering van de cracker-scene. Zogeheten zero-day exploitcode voor net ontdekte beveiligingsgaten is daarmee niet goed – of zelfs geheel niet – te weren.
Niet meer reactief
De door Wool en student Ohad Ben-Cohen ontwikkelde software gooit het over een andere boeg. De twee willen beveiliging niet langer baseren op reactief gebruik van een zwarte lijst. Hun wijziging voor de Linux-kernel laat die kern van het opensourcebesturingssysteem proactief abnormaal gedrag herkennen. Wanneer een serverapplicatie plots andere handelingen dan normaal uitvoert, kan de 'beveiligingsbewaker' ingrijpen.
Korset wordt toegelicht in een white paper (pdf) van Wool en Ben-Cohen. Die white paper is in juli dit jaar gepresenteerd op de conferentie Linux Symposium in Canada. De twee hebben ook een presentatie (pdf) gegeven op de beveiligingsconferentie BlackHat die in augustus plaatsvond in Las Vegas. Op die bijeenkomst zijn meer opvallende beveiligingsbevindingen uiteengezet, waaronder het lek in internetbasisprotocol DNS (domain name system).
Vroeger was er ook een applicatie die Windows NT splitste in 2 ‘states’. Een productie status, waarin veel functies uitgeschakeld waren en een beheer status. Het omschakelen van beheer naar productie werd via een mooi gecontrolleerd beheer process georganiseerd.
Het lijkt me logisch dat we uiteindelijk veel meer naar Whitelisting achtige methodes moeten, zoals hierboven beschreven.
Een goed beveiligingsbeginsel is “niets mag, tenzij …”. Een andere zegwijze is “need to”: alleen als je voor de uitoefening van je functie iets moet weten, iets moet hebben of ergens moet wezen, slechts dan krijg je dat (informatie, een middel of fysieke of logische toegang). Zo is het ook met informatiesystemen die een specifieke functie in de ICT-infrastructuur vervullen, zoals een databaseserver. Leg de functie van bedrijfskritische systemen vast en houd in productie vast aan deze specifieke functie. Gaat een informatiesysteem van ontwikkeling via testen en acceptatie in productie, ontdoe het dan van alles wat niet vereist is voor productie: compilers, source code, testdata, tools, et cetera. Onderzoek wat het typische gedrag is van het systeem zoals dat systeem bedoeld is, leg dit vast en sta geen ander gedrag toe. White listing dus … sta alleen het te verwachten gedrag toe en verder niets. Voor meer generieke, minder vitale systemen ligt het anders. De starheid van whitelisting kan je aardig in de weg zitten. Meer toestaan (geen controle op gedrag of blacklisting) kan, maar zal een hogere kans op ellende (malware) geven. Maar ja, daar zijn het dan ook minder bedrijfskritische systemen voor. Het aardige bij dit alles is dat software je hier bij kan helpen. Voor menselijk gedrag ligt het anders … Verder kan een risicobeschouwing uitkomst bieden bij het bepalen wat je te doen staat.
Het klopt dat scannen van een blacklist (zoals antivirussoftware dat doet) steeds minder de oplossing is.
Korset is een interessante benadering, hoewel het natuurlijk toch een beetje gek is dat een applicatie een bestand bij zich draagt waarin staat beschreven in welke volgorde de applicatie systeemaanroepen zal doen. Zo’n bestand kan ook veranderd worden, en moet dus ook weer worden beschermd. Beveiliging wordt dan nog weer een stapje complexer.
Ook lijkt het risico mij aanwezig dat een grote applicatie zoals een tekstverwerker of een browser zoveel mogelijke volgordes van system calls bevat dat alles eigenlijk wel ergens als mogelijk pad voorkomt. Mijn gevoel zegt dat er dan toch wel exploitcode te schrijven is die overeenkomt met een geldig pad ergens in het bestand met “geldig gedrag”.
Overigens zijn er ook fundamentelere oplossingen van whitelisting in ontwikkeling – zelf vind ik Bitfrost (van One Laptop Per Child) erg interessant. Daarbij vraagt het OS bij een nieuwe applicatie aan de gebruiker welke rechten die applicatie nodig heeft. Patience hoeft bijvoorbeeld geen bestanden te kunnen lezen, heeft geen netwerktoegang nodig, en hoeft niet bij je webcam te kunnen. Als de app die rechten dan ook niet heeft dan is ‘ie ook niet meer interessant als aanvalsvector.
Bewaking op gedrag is niet zo uitzonderlijk en gebeurt al. Het is alleen erg afhankelijk van de applicatie of het toepasbaar is. Neem bijvoorbeeld productie automatiseringssystemen, het gedrag van de gebruiker bij een normale operationele status van een fabriek verschilt geheel van het gedrag als er ingegrepen moet worden vanwege een productieprobleem. Je wilt in die situatie niet dat security functies dit afwijkend gebruiker en systeem gedrag gaan zien als een potentieel security incident. Ik neem aan dat soortgelijke situaties ook in andere omgevingen een rol speelt, waardoor de toepassing van deze technologie heel voorzichtig moet gebeuren.
Op het eerste gezicht lijkt het een prima idee om het gedrag van serverapplicatiecode te valideren voordat het wordt uitgevoerd. De consequentie, die Korset verbindt aan het niet voldoen aan de validatie, namelijk het downbrengen van de applicatie lijkt me in eerste instantie vrij rigoureus. Een (elke!) wijziging in de applicatie kan een denial-of-service situatie teweegbrengen en dan is het maar afhankelijk van het belang van de applicatie hoe ernstig de onbeschikbaarheid kan zijn?
Bovendien is de vraag: welke applicaties zou je door een gedragsmonitor willen laten monitoren? End-user applicaties? Infrastructurele applicaties? En afhankelijk van beantwoording van deze vraag, de volgende: waartegen zou je je willen beschermen? Als ik kijk naar infrastructurele applicaties, dan denk ik vooral aan bescherming tegen vormen van externe malware als bijvoorbeeld rootkits. Zou een dergelijke monitor als Korset dan het meest ideale zijn? Ik betwijfel het. Je kunt natuurlijk ook gebruik maken van hashing technieken om de applicatiecode te valideren.
Aan de andere kant: als ik kijk naar serverapplicaties, gericht op gebruikersomgevingen, lijkt het me meer voor de hand liggen om te kijken naar zaken als eisen die gesteld worden aan het schrijven van code (b.v. standaardisatie) en documentatie, test- en acceptatiecriteria, gebruik van OTAP-omgevingen etc. ctc.
In beide gevallen zit je zowiezo met upgrades en/of patches die natuurlijk de code zef, en mogelijk ook het gedrag, van de applicatie veranderen.
Uiteindelijk zal monitoring onderdeel uit gaan maken van een stelsel aan beveiligingsmaatregelen.
De aanpak om naar dynamisch gedrag te kijken werkt. Dit werd in de beginjaren van het antivirustijdperk al gebruikt om malware te detecteren. Het is in onbruik geraakt vanwege de overlast voor gebruikers en beheerders, omdat de repressie vaak een totale acceptatie of een totale blokkade was.
Deze overlast lijkt ook hier het geval te zijn. Een ‘overtredende’ applicatie wordt afgebroken. Dit is ook het lot van zg. false positives, die gevallen waar het gedrag verdacht lijkt, maar wel toegelaten is. In de inregeling moet dit als goed gedrag aangeleerd worden. Iedere wijziging in het applicatielandschap zal dit soort effecten hebben en potentieel voor verstoringen zorgen waar gebruikers last van hebben en beheerders een hele klus aan hebben om te bepalen wat de false positives zijn. Vooraf testen is niet mogelijk, het kan bv. een effect zijn van de vallende beurskoersen dat doorwerkt. Het genereren van false positives zou ook gebruikt kunnen worden in een denial-of-service aanval.
Het (mede)beschouwen van dynamisch gedrag is goed, we moeten daarbij af van het zwart/wit denken en bij de detectie ook een risicoindicatie ‘grijstint’ meegeven met een variabele repressie, die niet meteen reageert met het afbreken van een applicatie.
Ik heb bij dit soort oplossingen altijd een grote terughoudendheid.
Ten eerste gezien de hoeveelheid patches en software aanpassingen die de ‘onveilige’ applicaties nodig hebben en daardoor de belasting van het patchmanagement proces lijkt mij deze oplossing moeilijk uitvoerbaar en beheersbaar. Bij elke patch start het inleren van deze applicatie opnieuw.
Ten tweede is het de vraag of ik wel zo blij moet zijn dat er een nieuwe ‘buggy’ applicatie andere ‘buggy’ applicaties gaat besturen en zelfs in staat is om deze down te brengen (te stoppen). Het zou zomaar eens als een nieuwe DDOS gebruikt kunnen worden door een kwaadwillende.
Ik zou me heil toch zoeken in andere oplossingen.
Het is overduidelijk dat we voor de beveiliging van systemen steeds meer moeten zoeken naar andere oplossingen dan het al oude zoeken op malware aan de hand van een signature database (traditionele virusscanning). Met de hedendaagse snelheid waarmee nieuwe malware varianten worden gemaakt, is het onmogelijk deze te blokkeren op basis van een signature database die x maal per dag wordt ge?pdate.
Met dit in het achterhoofd, is het idee achter Korset op zich interessant. Korset echter zien als een volwassen security oplossing is in mijn ogen niet correct. Daarvoor biedt Korset te weinig dekking (met het huidige model worden alleen code injection vulnerabilities afgevangen) en werkt het monitoren alleen voor applicaties waarvan een Control Flow Graph aanwezig is. Applicaties (en dus ook virussen) die geen Call Flow Graph hebben, worden niet gemonitord door de Korset agent.
Tevens kan een malware schrijver ook bogus system calls aanroepen, waardoor zijn aanval in lijn is met de aanwezige Call Flow Graph en hij ongestoord zijn aanval kan uitvoeren.
Uiteindelijk is het duidelijk dat op korte termijn de traditionele beveiliging op basis van signatures (zoals gebruikt in Anti Virus en IDS oplossingen) zal verdwijnen en er veel meer van een “hybride” security oplossing gebruikt gemaakt zal gaan worden. Hierbij worden meerdere technologien (white- en/of blacklisting van applicaties op basis van een reputatiescore, gedragsmonitoring, etc) gecombineerd om een zo goed mogelijke beveiliging te garanderen.
Intelligentie in software roepen we al decennia. En eerlijk gezegd ben ik teleurgesteld in wat ik werkelijk zie in de markt. De intelligentie gaat vaak niet verder dan een eenvoudige beslissingsboom die vaak statisch is vastgelegd of in ieder geval na enige tijd niet meer aangepast wordt. Als we gedrag op basis daarvan beoordelen dan gaat de monitor meer en meer verkeerde beslissingen nemen en wordt dan al snel als lastig ervaren en uiteindelijk op non-actief gezet.
Anders zou het zijn als we ?cht intelligent aan de gang gaan. Heuristische software die trends en natuurlijke gedragsveranderingen herkent en daarmee om weet te gaan. Dat klinkt aardig maar een groot gevaar schuilt juist in die intelligentie. Er zullen dan maar weinigen zijn die direct de beslissingen van zo’n monitor doorzien en kunnen beoordelen (de criteria worden tenslotte dynamisch aangepast en eventueel uitgebeid). Daardoor is het gevaar aanwezig dat we te lang de monitor z’n gang laten gaan zonder dat we zeker weten of die inderdaad goede beslissingen neemt.Een intelligente monitor op de monitor is echt geen domme gedachte.
Dus, ja gedragsmonitoring zou handig kunnen zijn, maar de toepasbare intelligentie die daarbij nodig is om het goed te doen is nog ver te zoeken.