← Blog

4 500 betörési kísérlet: biztonságos az AI-val írt szoftver?

4 500 betörési kísérlet: biztonságos az AI-val írt szoftver?

Esettanulmány

Szombaton késő este valaki nekiállt feltörni egy alkalmazást, amelyet AI-val építettünk az egyik ügyfelünknek, egy digitális marketingügynökségnek. Négy napon át próbálkozott, több mint 4 500 jelszót próbált ki, minden kitiltás után új álarcot vett fel, és a végén üres kézzel távozott.

Elmesélem, hogyan telt ez a négy nap, és közben válaszolok arra is, amit gyakran kérdeznek tőlünk: tényleg biztonságos az AI-val írt szoftver?

4
napig tartó támadás
4 500+
kipróbált jelszó
0
ellopott adat
1
nap alatt megerősítve

Szombat este: idegen az ajtó előtt

Az alkalmazás belső eszköz. Benne van az ügynökség összes ügyfelének hirdetési adata, és néhány gombja valódi pénzt mozgat: büdzsét emel, licitet módosít, hirdetést állít le.

Budapesti idő szerint 21:38-kor egy tengerentúlon bérelt szerver kezdett adatokat kérni az alkalmazásból, méghozzá nem a weboldalon keresztül, hanem közvetlenül az adatbázisból. Ez kevésbé ijesztő, mint amilyennek hangzik: a legtöbb mai alkalmazásnál a böngésződ közvetlenül az adatbázisból kér adatokat, ahogy egy irodaház kapuján is bárki becsengethet. Az számít, mi történik, amikor egy idegen csenget.

Vasárnap írt nekem az ügynökség tulajdonosa: a munkatársak olyan bejelentkezési és jelszó-visszaállító e-maileket kaptak, amelyeket senki nem kért. Lehet, hogy valahol lyukas a rendszer?

Mivel próbálkozott a támadó

A rendszer naplója alapján a támadó mintha egy betörő teendőlistáját követte volna.

Ez nem egy találomra próbálkozó robot volt: a próbálkozásaiban használt szavak között másodperceken belül felbukkant az ügynökség egyik saját ügyfelének, egy fizetési szolgáltatónak a neve. Valószínűleg annak a fizetési kulcsait kereste, egy olyan beszállítón keresztül, amelyről azt remélte, hogy kevésbé védett. Ezeket a kulcsokat az alkalmazás soha nem tárolta.

Miért nem jutott ki semmi

Az alkalmazás bejelentkezését és jogosultsági rendszerét AI-val építettem (itt írtam le, hogyan dolgozunk vele). Mielőtt egyetlen sor kód elkészült volna, leírtunk két szabályt.

Az első, hogy az adatbázis minden egyes adatnál megnézi, ki kérdez: nemcsak azt, hogy beléphetsz-e az épületbe, hanem azt is, hogy pont ezt az adatot láthatod-e. Egy idegenhez egyetlen adat sem tartozik, úgyhogy egy idegen üres listát kap.

A második, hogy a képernyők önmagukban nem védik meg az adatokat. Attól, hogy egy gomb nincs a képernyőn, a mögötte lévő műveletet még bárki elindíthatja egy egyszerű programmal, ezért minden lényeges szabályt magába az adatbázisba építettünk.

Négy nap alatt a támadó egyetlen adatot sem tudott elolvasni, módosítani vagy törölni, és egyetlen fiókba sem jutott be.

A rés, amelyet mi magunk találtunk meg

Hogy lássuk, mire menne egy támadó, ha be tudna jelentkezni, a szabályaink olvasgatása helyett megpróbáltuk kijátszani őket. Kiderült, hogy egy ügyfél a fiókjából néhány saját beállítását is módosítani tudta, pedig csak a saját riportjait kellene látnia, és a képernyőkön nincs is lehetőség ilyen módosításra. Senki másnak az adata nem vált láthatóvá, a támadó pedig soha nem tudott bejelentkezni, hogy ezt kipróbálhassa.

A rést még aznap délután betömtük, és írtunk egy automatikus ellenőrzést, amely minden felhasználótípussal végigpróbálja mindazt, ami az adott felhasználónak tilos, így egy ilyen rés már az élesítés előtt kibukik. A rést nem a beállítások átnézésekor vettük észre, hanem akkor, amikor megpróbáltuk azt, amit a rendszernek tiltania kellett volna.

Vasárnap: bezárjuk az ajtókat

Az munkát az AI végezte: három rendszer naplóit olvasta végig, és minden változtatást biztonságos környezetben próbált ki, minden lépést pedig én hagytam jóvá (itt írtam arról, miért számít ez). Egy nap alatt:

A robotellenőrzést 16:49-kor kapcsoltuk be, és a támadás öt percen belül elcsendesedett.

Egy ponton az AI jelentette, hogy a támadás leállt. Megkérdeztem, honnan tudja, és amikor a naplók hosszabb szakaszát is átnéztük, kiderült, hogy a támadó még mindig próbálkozik. Ezt a kérdést neked kell feltenned, mert egyetlen AI sem teszi meg helyetted.

Vasárnap éjjel és hétfő: a visszatérés

Három órával később a támadó visszatért, ezúttal egy robottal, amely egy valódi böngészőt irányított. Megnyitotta a bejelentkező oldalunkat, átment a robotellenőrzésen, és az éjszaka folyamán 3 629 alkalommal próbált jelszóval bejutni, a próbálkozások nagyjából 80%-a pedig átjutott az ellenőrzésen. Egyik sem járt sikerrel, mert már nem volt jelszó, amelyet ki lehetett volna találni.

Hétfőn a naplókból kiderült, hogyan csinálta. Aki átmegy a robotellenőrzésen, az a bejelentkező oldalunktól rövid időre szóló igazolást kap arról, hogy ember, és jelszót csak ezzel lehet kipróbálni. A robot egyszerűen újra és újra megnyitotta az oldalunkat, és így folyamatosan friss igazoláshoz jutott. Vasárnap még értelmetlennek tartottam a kitiltást, hiszen a kitiltott támadó egyszerűen bérel egy másik címet. Most viszont lett értelme: a tárhelyszolgáltatója teljes hálózatát kitiltottuk a weboldalunkról, így a robot nem tudta többé megnyitni az oldalt, és nem jutott új igazoláshoz. A szolgáltatójának pedig jeleztük, hogy a szerverről támadás érkezik.

Kedd, 04:25: az utolsó próbálkozás

Hajnal előtt két irányból jött vissza: az eredeti szerveréről és egy újról, egy fizetős VPN-szolgáltatás mögül. Mind a 168 kérést, amellyel a szombaton feltérképezett adatokat kérte, azonnal elutasította a rendszer, és a 25 jelszótippből egy sem jutott át a robotellenőrzésen. Az oldalunkat már nem tudta megnyitni, így igazolást sem kapott.

Szóval biztonságos az AI-val írt szoftver?

Nem ez a jó kérdés. Az alkalmazás mögött álló népszerű adatbázis-szolgáltatás évekig alapértelmezés szerint hozzáférést adott a névtelen látogatóknak az újonnan létrehozott adatokhoz, hacsak az alkalmazás készítője be nem kapcsolta az adatonkénti ellenőrzést. Idén változtat ezen, de a korábban létrehozott adatoknál megmarad a régi beállítás.

Ezért azokban az ismert esetekben, amikor egy AI-val épített app teljes adatbázisa kiszivárog, ritkán a rossz kód a hibás, sokkal inkább egy nyitva hagyott ajtó, mert az alkalmazás készítőjének senki nem szólt, hogy be kell zárnia. Az AI gyönyörű alkalmazást épít neked nyitott hátsó ajtóval, ha a hátsó ajtót soha nem hozod szóba, és lehet ugyanezt tenné egy kezdő fejlesztő is. Ezt az alkalmazást azok a szabályok tartották biztonságban, amelyeket még az első sor kód előtt leírtunk, és amelyeket összevetettünk azzal, ami ténylegesen történt:

  1. Minden adatnál nézd meg, ki kérdez, az első naptól kezdve.
  2. Ne hidd, hogy a képernyők megvédik az adataidat. Lesz, aki közvetlenül az adatbázisodból próbál adatokat kérni.
  3. Az idegen ne kapjon semmit, még egy üres szobát sem.
  4. Ne tárold, amit el lehet lopni. Ha nincs jelszó, nincs mit kitalálni.
  5. Tesztelj úgy, hogy megpróbálod kijátszani a szabályokat. Lépj be minden felhasználótípussal, és próbáld megtenni mindazt, ami az adott felhasználónak tilos.
  6. Soha ne bízz egyetlen zárban. A robotellenőrzésünket kijátszották, de a támadó ettől még nem jutott be.
  7. Olvasd el a naplókat, mielőtt valamit értelmetlennek neveznél. A tiltás, amelyet előbb még értelmetlennek tartottam leállította a tippelgetést.

Az AI-val gyorsabban épült meg az alkalmazás, és a támadás után is gyorsabban tettük rendbe: hetek helyett órák alatt. De az alkalmazás attól maradt biztonságos, hogy tudtuk, mit kérjünk az AI-tól. Az AI-val írt szoftver biztonsága azon múlik, hogy a készítője tudja-e, milyen védelmet kérjen tőle.

Ha AI-val építesz, vagy építtettél valamit, és nem vagy biztos benne, mi van a bejárati ajtó mögött, szívesen megnézzük. Szolgáltatásainkról itt olvashatsz.


Ez a cikk az Andronia blogján jelent meg. Az Andronia magyar vállalkozásoknak segít AI automatizálással növekedni. Szolgáltatásainkról itt olvashatsz.

↑ tetejére