Åben Chroma-databaser: En ny angrebsflade for AI-apps
Chroma er en open source vektorbutik - en database designet til at lade LLM chatbotter søge efter relevant information, når de besvarer en brugers spørgsmål - og en af mange teknologier, der har set en vækst i adoptionen med den nylige AI-boom. Ligesom mange databaser kan Chroma konfigureres af slutbrugere til at mangle autentificerings- og autorisationsmekanismer. Når databaser uden autentificering udsættes for internettet, kan anonyme brugere læse og endda opdatere dataene i databasen, hvilket potentielt kan kompromittere fortroligheden, tilgængeligheden og integriteten af dataene.
Selvom Chroma-databaser, der er eksponeret for internettet, er meget mindre almindelige end ældre slags databaser, vokser deres antal, og de kan potentielt være en kilde til betydelige datalækager i den nærmeste fremtid. I en undersøgelse af 1170 Chroma-databaser eksponeret for internettet fandt vi 406, eller omkring en tredjedel, der eksponerede en eller anden form for data. Den mest bemærkelsesværdige af disse lækkede nogle personligt identificerbare oplysninger (PII) fra Canva Creators, som vi har skrevet om her.
Hvad er Chroma-database?
Forestil dig, at du opsætter en chatbot til hjemmesiden for dit hotel eller din restaurant. Du ville bruge en LLM til at fuldføre prompten, men du ville også have brug for et lager af data, der er unikt for din virksomhed, til ting som åbningstider, faciliteter, din adresse og andre oplysninger, der er nødvendige for en besøgende på hjemmesiden.
Inden for Chroma tager denne type information form af "dokumenter", som typisk er enkle strenge, der indeholder relevant information til chatbotten. En af strengene kan være noget som "Vores åbningstider er fra 9 til 22, 7 dage om ugen." Når nogen spørger din chatbot, hvad jeres åbningstider er, ville ChromaDB finde det dokument, da det mest præcist matcher forespørgslen, og derefter køre det tilbage gennem LLM for at få svaret til at lyde samtalende. Den endelige bruger kan modtage noget som "Vi har åbent hver dag fra 9 til 22, og vi ser frem til dit besøg!"
Distribution af Chroma-databaser uden godkendelse
Da vi undersøgte internettet i april 2025, var der 1170 internet-tilgængelige Chroma-databaser. For at afgøre, om nogen data var eksponeret, brugte vi metoden .list_collections for hver IP-adresse, og derefter .get_collection for at hente data fra hver samling. I dette tilfælde returnerede 406 databaser en eller anden form for data, mens omkring to tredjedele returnerede en autentifikationsfejl eller ikke indeholdt nogen data.

Hver database kan have flere "samlinger", som er logisk adskilte, ja, samlinger af dokumenter. Antallet af samlinger pr. database giver en heuristik for, om de bliver aktivt brugt, og i hvilken grad. Den mest anvendte database havde 4.315 samlinger, hvilket bestemt udgør en form for intensiv brug. Mange af de databaser, der er konfigureret til at tillade anonym adgang, havde ingen meningsfulde data, men 60% af databaserne havde mere end en samling, hvilket indikerer en vis modificering ud over standard-samlingen, og 32% havde fem eller flere samlinger.

Geografisk distribution af Chroma-databaser
Geolokaliseringen af IP-adresser, der hoster internet-eksponerede Chroma-databaser, giver os en idé om, hvilke regioner der er mest udsatte for konsekvenserne af fejlkonstruktioner. Mens nogle AI-teknologier viser en stort forbrug i Kina, bruges Chroma hovedsageligt i USA og Europa, med en bemærkelsesværdig tilstedeværelse i Indien også. For bedre at repræsentere det lange hale af europæiske nationer ud over de 20 mest almindelige lande, har vi inkluderet en samlet tælling for EU som helhed.

Risici forbundet med uautentificeret Chroma-database
Datainformation lækage
Af de 406 åbne Chroma-instanser, vi undersøgte, fandt vi, at de fleste blev brugt til grundlæggende udforskning og ikke indeholdt meget af unik data. Men ligesom med enhver netværksbaseret teknologi, fandt vi også Chroma-servere, der syntes at indeholde reelle data, der driver chatbot LLM'er et sted på internettet.
En almindelig anvendelse af ChromaDB ser ud til at være at levere data vedrørende lejligheds- og hoteludlejninger i og omkring Indien. Et antal servere indeholdt information om ejendomme og deres faciliteter, som er ting, en besøgende på websitet sandsynligvis ville spørge om. Denne anvendelsessituation giver mening for Chroma og lækker ikke følsomme data, men databaserne bør have en eller anden sikkerhed, der forhindrer angribere i at få adgang til dataene direkte.
En anden server syntes at tilhøre en e-handels SEO-tjeneste. Databaseejeren havde fyldt den med kundesupport chatlogs, tilsyneladende som en måde at øge viden hos LLM chatbotten. Ved at tilføje nogens tidligere samtale om almindelige spørgsmål, ville botten nu have den tidligere erfaring at trække på, når den svarede på fremtidige spørgsmål. Dette rejser selvfølgelig bekymringer om, at hvis der var blevet tilføjet følsomme kundedata til Chroma, kunne de blive set af fremtidige brugere af chatbotten. Faktisk har vi set dette præcise tilfælde - at forsøge at forbedre en support bot ved at fodre den med ægte brugertickets - resultere i et læk af PII for LlamaIndex, en anden AI-teknologi.
Skriveevne
Ifølge Chromas dokumentation om sikkerhed er autentifikation som standard deaktiveret. "Som standard kræver Chroma ikke autentifikation. Du skal aktivere det manuelt. Hvis du implementerer Chroma i et offentligt tilgængeligt miljø, er det meget anbefalet at aktivere autentifikation."
At få adgang til de tilgængelige data er kun en bekymring. En anden ville være, at en ondsindet bruger kunne ændre eller forgifte de data, der er tilgængelige for en chatbot. Det er let at forestille sig en række situationer, hvor en produktionschatbot med en uauthentificeret og åben ChromaDB-instans kunne levere forkert eller endda farlig information til en chatbot-bruger.
For at illustrere, hvordan en angriber med ubegrænset adgang til en Chroma-database kunne misbruge den, har vi lavet en demonstration, hvor vi uploader misvisende dokumenter, fjerner korrekte dokumenter og erstatter dokumenter med dem, der leder brugere til angriberens kontrollerede ressourcer.
Konklusion
Som vi lærte, mens vi brugte Chromas demo-notesbog, er det virkelig en cool teknologi til at hente dokumenter til brug i AI-drevne apps. Med over tusind internet-tilgængelige instanser ser det også ud til at have sund vedtagelse og vækst. Men brugere skal være opmærksomme på, hvordan de konfigurerer deres databaser sikkert, især da det mangler autentificering som standard. (Som en parentes, tog Elasticsearch engang den samme beslutning - at udelade autentificering på princippet om, at ansvaret tilhører webapplikationslaget snarere end databasen - og ændrede det senere på grund af hyppigheden af datalækager fra Elasticsearch.) Udover at sikre, at nogle mekanismer forhindrer anonyme brugere i at få adgang til databasen, bør brugerne også overveje at sanere data med PII eller anden fortrolig information for at minimere konsekvenserne i tilfælde af et lækage eller brud.