10 manieren om een LLM aan te vallen

De populariteit van generatieve AI blijft alleen maar toenemen. Nvidia heeft moeite om de reusachtige vraag naar AI-vaardige hardware te leveren terwijl organisaties van de kracht van LLM’s (large language models) willen profiteren. OWASP (Open Worldwide Application Security Project) ziet dat het op veel manieren mis kan gaan met de security van deze AI-toepassing.

OWASP kaart aan dat er tot nu toe geen centrale bron is om LLM-kwetsbaarheden in te zien. Organisaties gaan massaal aan de slag met LLM’s, maar lijken daarbij niet een duidelijk security-protocol te volgen. Het bestaan van dergelijke best practices zijn echter niet direct een garantie dat die nageleefd worden, zoals OWASP constateerde bij Kubernetes-kwetsbaarheden.

Tip: Dit zijn de 10 gevaarlijkste Kubernetes-kwetsbaarheden

Voor het opzetten van deze top 10 raadpleegde OWASP bijna 500 experts en kende het project meer dan 125 bijdragers. Op de longlist stonden 43 kwetsbaarheden, maar na meerdere stemrondes reduceerde men dit aantal naar 10 en werden deze vervolgens nog door andere sub-teams en de community gecontroleerd. Het onderzoeksteam bestond onder andere uit werknemers van Google, Microsoft, AWS, Cisco, Red Hat en Salesforce.

LLM01: prompt injection

De input bepaalt wat een LLM produceert. Vaak zijn deze resultaten op voorhand lastig te voorspellen. Toch kunnen ontwikkelaars de resultaten verfijnen met betere training en sleutelwerk aan de parameters. Bij publieke chatbots zoals ChatGPT en Google Bard is bekend dat ze vrij snel voorzichtig worden als je ze gedurfde vragen stelt. In een professionele context gaat het alleen om meer dan lolligheden, en kan een interne LLM bedrijfsgeheimen in huis hebben.

OWASP spreekt over directe en indirecte prompt injections. In het eerste geval karakteriseert men deze aanvalstactiek als een “jailbreak” voor een LLM: een kwaadwillende heeft in dat geval de onderliggende systemprompt ontdekt of herschreven. Daardoor kan men bij een aanval wellicht bij gevoelige data stores komen waar de LLM op rust. Het tweede scenario komt voor als een LLM via een externe bron aanspreekbaar is en de aanvaller een prompt injection uitvoert om de conversatie-context te kapen. Vervolgens opereert de LLM als een “confused deputy”, in de woorden van OWASP. Dat houdt in dat het taken kan uitvoeren die het normaal gesproken niet zou mogen doen voor een gebruiker.

Het belang van een “human-in-the-loop” is niet te onderschatten, zoals door toestemming voor bepaalde acties afhankelijk te maken van een menselijke goedkeuring. Het naleven van zero-trust principes en least-privilege toegang is eveneens broodnodig. Een LLM moet behandeld worden als een untrusted user om de invloed van een kwaadwillende zoveel mogelijk in te perken.

LLM02: onveilig omgaan met de output

Wie een LLM inzet, moet ook in de gaten houden welke componenten ermee kunnen communiceren. Zo kan een output ervan direct invloed hebben op systemen in de backend of gepriviligeerde en client-side functies aanspreken. Aangezien de input erg invloedrijk kan zijn voor een LLM, is het moeilijk om dit gevaar in te dammen. De gevolgen kunnen nogal serieus zijn, zoals privilege-escalaties en remote code execution.

OWASP borduurt voort op de maatregelen bij de eerste kwetsbaarheid: het behandelen van een LLM als een normale gebruiker is gewenst. Daarbij heeft de organisatie een ASVS (Application Security Verification Standard) die onder andere op GitHub te raadplegen is. Deze standaard omschrijft eveneens hoe output van een encode voorzien kan worden.

LLM03: data-poisoning

Trainingsdata vormt samen met de parameters van een LLM de basis voor de functionaliteit van een AI-model. Deze informatie kan binnen een organisatie verzameld worden voor bijvoorbeeld het ondersteunen van een klantenservice of het analyseren van bankgegevens. Echter maken veel partijen ook gebruik van externe gegevens. Hiertussen kan een kwaadwillende echter data plaatsen die voor kwetsbaarheden of backdoors kan zorgen als het selectieproces dit er niet uit vist. OWASP geeft aan dat het manipuleren van trainingsdata de effectiviteit van een LLM kan beperken. Ook stelt men dat externe large language models hierdoor extra riskant kunnen zijn: daar is namelijk niet te garanderen dat er geen data-poisoning heeft plaatsgevonden.

Om dit probleem te verhelpen, moeten organisaties zorgvuldig omgaan met het verifiëren van de databronnen. Daarnaast is het zaak om goed na te denken over de use-case van de LLM in kwestie: welke data is er daadwerkelijk voor nodig en moet die publiekelijk beschikbaar zijn? Ook nadat een model getraind is, kan data-poisoning nog worden opgespoord in de testfase.

LLM04: Model Denial-of-Service

Een van de meest eenvoudige manieren om een website te doen wankelen, is een DDoS-aanval. Zo ook kan een aanvaller een LLM bestoken met inputs om de hardware-resources onder druk te zetten. Wie geen stricte limieten stelt op de context window van een chatbot, kan voor exponentiële systeemeisen zorgen. Een publieke chatbot als Bing Chat kent daarom bijvoorbeeld een limiet van 30 interacties binnen de context window. Dezelfde soort eis moet gesteld worden door kleinere partijen, zeker als de beschikbare hardware lokaal beperkt is of de cloud-kosten niet de pan uit mogen rijzen. Het stellen van API-rate limits en het inzichtelijk maken van de gebruikte hardware-resources voorkomt problemen.

LLM05: supply chain-kwetsbaarheden

Kwetsbaarheden in de supply chain kunnen allerlei effecten hebben voor LLM’s, van security-lekken tot bevooroordeelde outputs van het model. Normaal gesproken gaat het veiligstellen van de supply chain om het controleren van software-componenten, maar bij LLM’s kan dit complexer zijn. Dit omdat vooraf getrainde modellen of third-party trainingsdata kwetsbaar kunnen zijn voor bijvoorbeeld data-poisoning. Het probleem kan ook andersom gaan: wie een externe API aanspreekt voor een AI-model, heeft wellicht niet in de voorwaarden gelezen dat de eigen data inzetbaar kan zijn voor verdere training.

LLM06: het vrijgeven van gevoelige data

Hoe goed een LLM ook getraind en getest is, het kan zo zijn dat een generatief AI-model op een onverwachte manier informatie door kan spelen. Een toevallige prompt kan opeens gevoelige data of algoritmes prijsgeven, zelfs als de eindgebruiker geen kwaadwillende gedachtes erop nahoudt. OWASP raadt aan om consumenten van LLM-applicaties bewust te maken van een veilige omgang met AI-modellen.

Tip: ‘Medewerkers Samsung lekken geheimen aan ChatGPT’

De oplossing ligt volgens OWASP bij de trainingsdata. Daar dienen geen gebruikersgegevens of ongewenste gevoelige data in te zitten. Gebruikers dienen aan te kunnen geven dat hun data niet gebruikt mag worden voor verdere training. Zo ontstaat er wat OWASP omschrijft als een “two-way trust boundary”, waarbij zowel client als LLM een inherent vertrouwen heeft in de ander. Toch is een fout niet altijd te voorkomen bij deze technologie, laat de organisatie weten.

LLM07: onveilig plugin-ontwerp

Aanvallers kunnen via een LLM-plugin ongewenste acties uitvoeren. Dit is mogelijk omdat een LLM bepaalt wanneer het een plugin raadpleegt, waardoor het essentieel is dat deze plugins slechts een beperkte toegang kunnen verkrijgen. Developers dienen plugins daarom zoveel mogelijk in te perken als het gaat om inputs. Ook moet men ervoor zorgen dat er voldoende verificatiemethoden toegepast zijn.

LLM08: te veel vrijheid

Een LLM-systeem kan erg effectief zijn als het toegang heeft tot andere systeem. Zo kan een AI-assistent in opdracht van een gebruiker in een andere applicatie duiken om iets uit te zoeken. Wie bij het opzetten van deze functionaliteit onoplettend is, kan de LLM toestaan om ongewenste acties uit te voeren. Deze vorm van ‘agency’ of autonomie kan bijvoorbeeld ruimte geven om shell commands uit te voeren of om een database te updaten, zoals een gewone gebruker van de andere app zou kunnen. Met te veel permissies kan dit grote gevolgen hebben. Vandaar dat OWASP stelt dat een LLM zoveel mogelijk aan banden gelegd moet worden. Wederom is het nuttig om iemand in real-time te laten kijken wat een AI-model precies uitvoert, zoals ook doodgewone gebruikers worden gecontroleerd in een IT-omgeving.

Ook moet een LLM niet zomaar zelf kunnen bepalen waar het toegang toe heeft, maar moet het voorbij bestaande verificatiestappen komen om van een applicatie gebruik te maken. Een voorbeeld van OWASP is dat een kwaadwillende via de e-mailsystemen van een andere gebruiker spam kan versturen, omdat het zonder verdere verificatie toegang had en geen inperkingen kende op de functionaliteit.

LLM09: te grote afhankelijkheid

LLM’s kunnen veel, maar zijn zoals gezegd in staat om fouten te maken. Ze ‘denken’ niet en zijn uiteindelijk een zeer complexe voorspelmachine. Dit houdt in dat er in een professionele context erg voorzichtig mee omgegaan moet worden. LLM’s kunnen in veel gevallen programmeercode produceren, maar ook daar geldt dat er onjuiste of gevaarlijke inhoud in kan zitten. Het is een bekend probleem dat deze AI-modellen de mist in kunnen gaan, waardoor het belangrijk is dat organisaties regelmatig controleren of de output naar wens is. Het opvallende aan deze kwetsbaarheid is dat de aanval niet kwaadwillend is: een nietsvermoedende developer kan programmeercode inzetten die men niet genoeg had bekeken om de fouten op te pikken.

LLM10: diefstal

Steeds meer bedrijven zetten LLM’s in die ze in veel gevallen zelf (verder) hebben ontwikkeld. Niet alleen de trainingsdata, maar ook het model zelf kan enorm waardevol zijn. Net als andere digitaal beschikbare IP is het van groot belang om deze informatie te beschermen. Zoals ook voor andere data geldt, moeten interne gebruikers zo min mogelijk toegang hebben tot een LLM. Binnen een zero-trust omgeving kan een AI-model zoveel mogelijk afgeschermd zijn voor een ontevreden werknemer of een kwaadwillende indringer.

Echter is het ook mogelijk om via de outputs een deel van een AI-model te openbaren. OWASP omschrijft een voorbeeld waarbij een aanvaller een groot aantal gerichte prompts aanlevert, waardoor de werkzaamheid van een LLM enigszins aan reverse engineering onderhevig is. Toch stellen de onderzoekers dat een geheel model niet zomaar op deze manier te ontrafelen is.

Lees ook: Liquid neural networks: hoe een worm de problemen van AI oplost