Tekoäly kysyi lupaa yhteen tiedostoon – kirjoitti toiseen

Tietoturvayhtiö Wiz kertoi heinäkuussa tutkimuksesta, jossa kuusi suosittua koodiavustajaa saatiin kirjoittamaan tiedostoihin projektikansion ulkopuolelle. Tutkijat antoivat ilmiölle nimen GhostApproval.

Kiinnostavin yksityiskohta ei ole itse kirjoitusoperaatio vaan se, mitä käyttäjä näki sillä hetkellä. Claude Coden testissä agentin oma päättely totesi suoraan, että tiedosto project_settings.json on todellisuudessa zsh-asetustiedosto. Käyttäjälle näytetty vahvistusikkuna kysyi silti vain, tehdäänkö tämä muokkaus tiedostoon project_settings.json.

Malli siis tunnisti kohteen. Luottamusraja rikkoutui käyttöliittymässä, siinä kapeassa kohdassa, jossa ohjelma kertoo ihmiselle mitä se aikoo tehdä.

Näin hyökkäys etenee vaihe vaiheelta

Ketju alkaa koodivarastosta. Hyökkääjä julkaisee GitHub:iin projektin, joka näyttää tavalliselta avoimen lähdekoodin työkalulta.

Varastoon on piilotettu symbolinen linkki, eräänlainen tiedostojärjestelmän pikakuvake. Kansiossa näkyy tiedosto nimeltä project_settings.json, mutta se ei sisällä mitään omaa: se osoittaa toiseen tiedostoon käyttäjän kotihakemistossa.

Kehittäjä kloonaa projektin ja pyytää avustajaa auttamaan käyttöönotossa. Avustaja lukee README-tiedoston, jossa on ohje muokata asetustiedostoa. Ohje on hyökkääjän kirjoittama, ja agentti noudattaa sitä samalla painoarvolla kuin käyttäjän omaa pyyntöä.

Agentti pyytää luvan muokkaukseen. Ikkunassa lukee viaton tiedostonimi. Käyttäjä hyväksyy, ja kirjoitus menee linkin päässä olevaan todelliseen kohteeseen.

Pahimmassa tapauksessa kohde on ~/.ssh/authorized_keys. Se on lista julkisista avaimista, joilla koneelle saa kirjautua ilman salasanaa. Yksi lisätty rivi tarkoittaa, että hyökkääjä voi avata etäyhteyden kehittäjän koneelle silloin kun haluaa. Pääsy ei katoa salasanan vaihdolla eikä selaimen välimuistin tyhjennyksellä.

Windsurf kirjoitti ennen kuin ehti kysyä

Toteutustavat erosivat toisistaan. Cursor näytti käyttäjälle linkin polun, mutta Hyväksy-napin painalluksen jälkeen taustajärjestelmä purki linkin ja kirjoitti todelliseen kohteeseen. Googlen Antigravity näytti niin ikään linkin polun eikä puretun kohteen nimeä.

Windsurfin tapaus oli laadullisesti eri. Siinä agentti kirjoitti muutokset levylle jo ennen kuin Hyväksy- ja Hylkää-napit ilmestyivät ruudulle. Vahvistusikkuna toimi kumoustoimintona, ei portin lukkona. Hyökkäys oli siinä vaiheessa jo onnistunut riippumatta siitä, kumpaa nappia käyttäjä painoi.

Wizin suositus valmistajille on suoraviivainen: polku pitää purkaa kanoniseen muotoon ennen kuin se näytetään ihmiselle, työtilan ulkopuolelle osuvasta kohteesta pitää varoittaa erikseen, eikä levylle saa kirjoittaa mitään ennen nimenomaista lupaa.

Ero aiempiin agenttiaukkoihin

AI Suomi on kertonut aiemmin kahdesta samankaltaiselta kuulostavasta tapauksesta, mutta vika on eri kohdassa. Juttu madosta tekoälyavustajan asetuksissa käsitteli haitallista koodia, joka jäi elämään avustajan omassa konfiguraatiossa. Tapauksessa, jossa yksi kommentti riitti vuotamaan Googlen agentin avaimet, kyse oli kehotehyökkäyksestä: malli itse huijattiin toimimaan käyttäjää vastaan.

GhostApprovalissa mallia ei huijattu. Se luki tilanteen oikein ja sanoi sen ääneen omassa päättelyssään. Vika oli siinä, että ihmiselle näytetty tieto ei vastannut ohjelman todellista aikomusta. Sitä ei korjata paremmalla mallilla vaan paremmalla käyttöliittymällä.

Mitä kannattaa tehdä nyt

Kehittäjän kone on nykyään harvoin pelkkä kehittäjän kone. Siellä on tuotantoympäristön tunnuksia, pilvipalvelun avaimia ja pääsy yrityksen koodivarastoihin. Kun agentti saa luvan kirjoittaa tiedostoihin, se perii käytännössä samat oikeudet kuin käyttäjä itse. Yhden ihmisen hätiköity hyväksyntä riittää siirtämään hyökkääjän yrityksen sisäverkkoon, eikä kyse ole enää yhdestä työasemasta.

Ohje on kolmiosainen. Päivitä avustajat uusimpiin versioihin ja tarkista erityisesti Windsurfin ja Augmentin tilanne, koska niissä korjaus oli kesken. Aja tuntemattomat koodivarastot kontissa tai virtuaalikoneessa, jolloin kotihakemistoa ei ole olemassa siinä muodossa, jossa hyökkääjä sitä odottaa. Ja jos organisaatiossa on tietoturvavastaava, ota tiedoston ~/.ssh/authorized_keys muutokset valvontaan: sen sisällön pitäisi muuttua harvoin ja aina tunnetusta syystä.

Löydös siirtää myös agenttien testauksen painopistettä. Turvallisuutta on tähän asti arvioitu kysymällä, saako mallin puhumaan tai toimimaan väärin. Wizin tapaus osoittaa, että tarkastuslistalle kuuluu myös se, mitä ruudulla lukee sillä sekunnilla, kun ihminen painaa hyväksy.