MEGJEGYZÉS: cikkünk vendégszerzője Módly Márk, a Hardcore IT Solutions szakértője. A cikkben foglaltak nem feltétlenül tükrözik a HWSW szerkesztőségének véleményét. Felhívjuk a figyelmet, hogy bármilyen egyedi kód vagy kódrészlet jogosulatlan megszerzése, módosítása vagy terjesztése törvénybe ütköző cselekedet lehet!

Az egész valahogy így kezdődött:

Ebben a cikkben az elmúlt évek egyik legnagyobb hazai kiberbiztonsági incidense kapcsán, a bulvár feltételezéseket mellőzve a már közkézen forgó üzenetek és forráskód alapján vonunk le a fentiekben láthatónál jóval konkrétabb tanulságokat, melyek nemcsak az érintett KRÉTA rendszer jelenlegi és leendő fejlesztői/dolgozói számára lehetnek hasznosak, hanem a többi, Magyarországon készülő szoftver biztonságosabbá tételét is szolgálják. 

A rendszer megtörése

A támadás kivitelezése egy fertőzött linket tartalmazó üzeneten keresztül kezdődött az elmondások alapján. A hollywoodi filmek túldramatizált jeleneteiből kiindulva hajlamosak vagyunk azt hinni, hogy a rendszerek/cégek ellen irányuló támadások többsége az informatikai rendszerek közvetlen kihasználásával kezdődik. Ez önmagában azonban nem feltétlenül helytálló elképzelés.

CI/CD-vel folytatódik az AWS hazai online meetup-sorozata! A sorozat december 12-i, ötödik állomásán bemutatjuk az AWS CodeCatalyst platformot, és a nyílt forráskódú Daggert is.

A világhálón található szoftverek robotok által folyamatosan támadás alatt állnak, azonban amikor célzott támadásról beszélünk (azaz egy bizonyos cég adatait vagy információit szeretnénk megszerezni), akkor a helyzet nem ilyen egyértelmű. Sokkal kevésbé detektálható egy ember hibája a vezető beosztásúak között, mint egy teljes szoftver alapú invázió. Ezt a támadást egyébként a “nagyhalakra” történő vadászat, azaz “whaling” néven szokták emlegetni. A beszámolók alapján itt is ez volt a belépési pont a céges környezetbe.

1. tanulság

Sokszor (mindig?) az emberek a leggyengébb láncszemek egy cég életében. Mindenképpen érdemes támogató rendszereket létesíteni; nem csak telepített, de jól beállított vírusvédelem és nem utolsósorban az alkalmazottak képzése a bizalomra alapuló támadások felismerésére és azonnali jelentésére!

A kiszivárgott beszélgetések alapján több más jellegű probléma is volt a szervezet belső működésével. A következő mondat amilyen ártalmatlannak tűnik, olyan mély működésbeli/rendszerszintű hiányosságokat takarhat:

Valaki olyan adminisztrátori hozzáféréssel végzett el egy változtatást, amelyhez vele együtt csak négyen ismerik a jelszót.*

forrás: Telex.hu

A fent említett jelenség, a “fiókmegosztás”, sokszor keseríti meg a cégek életét. Ismerjük a mondást, miszerint “közös lónak túros a háta”. A közös fiókokkal hasonló a helyzet. Mivel egyszerre többen lehettek, akik elvégezték a “változtatást”, nincs gazdája az okozott problémának, és még kinyomozni is nehezebb, hogy egy adott támadás honnan ered.

2. tanulság

A belső rendszerszintű problémák az első adandó alkalommal megnehezítik az incidens továbbgyűrűzésének megállítását. A jogosultságkezelési problémák, mint a fiókmegosztás, lehetetlenné teszik sok esetben, hogy egy rendszert vagy felhasználóit részlegesen leállítsunk, letiltsunk.

A fent említett két tanulság mellett még lehetne hasonló szisztematikusan rosszul működő folyamatokra rávilágítani, mint hogy egyes felhasználók jogosultságai miért terjedtek ki gyakorlatilag minden funkcionalitás elvégzésére, vagy az incidensek kezelésének módja mennyire tisztázatlan volt, de ezen aspektusok spekulációt tartalmaznának a működésre vonatkozólag, ettől azonban szeretnénk elzárkózni.

A kiszivárgott kód érdekességei

Ha nagyon távolról szeretnénk indulni, akkor érdemes szemügyre vennünk a 2016-os amerikai választásokon történteket és az azzal kapcsolatban kiadott Mueller-jelentést. Ezen riport szerint külső erők is támadták az amerikai választási rendszer integritását. A dokumentum a támadás technikáját is ismerteti, ami nem más mint az:

SQL INJEKCIÓ

Az interneten könnyűszerrel, egy Google-kereséssel fellelhető kódrészletek tanúsága szerint a KRÉTA fejlesztői ennek kivédésére több megoldást is próbáltak implementálni, azonban kérdéses, hogy ezek milyen sikerrel tudják venni az akadályokat. A több helyen is nevetség tárgyaként létrehozott képernyőképek ráadásul arra engednek következtetni, hogy a probléma megléte ismert volt a fejlesztők számára.

Elképzelhető, hogy az egyedi esetek miatt készült így a kód, vagy az informatikai világban hírhedt módon történelmileg alakult így. 

Mindenesetre ha a fejlesztőknek nem volt lehetősége megismerkedni a helyes megoldással, akkor nem is igazán elvárható, hogy a megfelelő szoftvert szállítsák le egy éles rendszer készítésénél. 

A modernebb fejlesztés folyamán (objektumorientált környezetben szinte mindenhol) biztonságosan megírt segédszoftvereket használunk. Ezeket objektum-relációs mappelés vagy ORM néven szoktuk emlegetni. Egy ilyen megoldás lenne C# környezetben a .NET Entity Framework is.

3. tanulság

Ha a szoftverünk vagy a fejlesztő gárdánk “lemarad” tudásban az “új” technológiákról (prepared statement, ORM), akkor olyan problémákra kell valószínűleg hibás egyedi megoldást fejleszteni, melyekre a biztonságos megoldás már több mint 10 éve ismert.

Az XSS támadást remélhetően megelőző kódrészleten és a csúnya szavak listáján kívül nagy visszhangot vert a fejlesztői közösségben a jelszavak kezelése a rendszeren belül. Ugyan elhangzott, hogy a forráskód egy tesztelésre szánt rendszer sorait és konfigurációját tartalmazza csak, azonban a jelszavak és kulcsok beégetett mivolta nyugtalanító. A kiadott fájlok között ugyanis megtalálhatóak a működő éles rendszerben található kulcsok is.

Szerencsére ezek jelszóval védettek, de létezik szoftver azoknak a visszafejtésére. (Ennek fényében különösen aggasztó, hogy a rendszer fejlesztői és üzemeltetői nem léptek kapcsolatba a megfelelő hatóságokkal, mert így a kulcsok visszavonása is kérdéses, hogy időben megtörténhetett-e.)

Mindenesetre elmondható, hogy egy modernebb fejlesztési környezetben nem ebben a formában javasolt a konfigurációk és abban a kulcsok, jelszavak kezelése. Ennek megfelelően a kapcsolódó rendszerek felülvizsgálata is javasolt, tekintve, hogy a kikerült fájlok lehetőséget nyújthattak akár más helyeken üzemeltetett rendszerek kihasználására is.

4. tanulság

Ha ugyanabban a (verziókezelő) rendszerben, vagy forráskódba égetve tároljuk az alkalmazás működéséhez szükséges konfigurációkat és kulcsokat, akkor a fejlesztőktől kezdve, akár a támadói kezekbe is kerülhetnek az éles rendszer titkai, melyek más rendszer kompromittálódásához is vezethetnek.

A fentebb tárgyalt hibákon felül még vannak olyan elemek, melyek több ponton is kérdéseket vetnek fel a rendszer megtörését követendő szükséges lépésekkel kapcsolatban. A támadók ugyan nem közöltek személyes adatokat, de azok a birtokukba jutottak. Itt fontos megjegyezni, hogy ugyan a fejlesztők ismertek bizonyos szintű biztonságot a felhasználói jelszavakkal kapcsolatban, mégis a rendszerben olyan függvények használata történik, melyek már sok éve nem javasoltak jelszótárolásra (MD5, SHA1). Ennek megfelelően, hogy a lehető legtöbb olvasónk és ismerőseik biztonságban tudhassák további fiókjaikat, szeretnénk az alábbi tanácsot adni minden KRÉTA-felhasználónak (tanárok, diákok, szülők).

 Mindenki, aki regisztrálva volt az eKréta rendszerbe valaha is, változtassa meg a jelszavát, és amennyiben ezt a jelszót bárhol máshol is használták, ott is cseréljék le.

Az KRÉTA esete remélhetőleg rávilágít a teljes szoftverfejlesztési folyamat és számítógépes világ egyik égető problémájára. A jó hír, hogy az összes itt fellelhető hibára van megoldás, és ezek beépíthetőek a különböző folyamatokba, a cégek életébe, a fejlesztők tudásába.

Ezért foglalkozunk hosszú ideje a fejlesztők képzésével és a problémák megelőzésével.