A bank és az informatikai biztonság – esettanulmány

Nemrég egy olvasónk – aki egyébként magasan képzett informatikai szakember – hívta fel arra a figyelmünket, hogy bankjánál, ahol üzleti ügyeit is intézi, az internetes szolgáltatások között van egy olyan, ahol szerinte biztonsági hiányosság tapasztalható.

A szóban forgó szolgáltatás a magyarországi UniCredit clickFX nevű online deviza kereskedési rendszere, mely vállalati ügyfelek számára kínál megoldást. A használatához Java futtatókörnyezet (Java Runtime Environment – JRE) szükséges, melyről viszont már a szolgáltatás kezdőlapján megtudjuk, hogy: „…a clickFX rendszer a Java 7.x verzióival nem működik, kérjük az alkalmazáshoz a Java, oldalunkról letölthető verzióját használják.”

Amennyiben az ügyfél mégis egy, a megadottnál frissebb JRE-t futtató gépről próbálkozik, akkor a következő figyelmeztetést kapja:

JRE

Úgy véltem, hogy a felhasználói panasz megalapozott, két okból is. Ha egy vállalati ügyfél naprakészen tartja a rendszerét, a gépét – márpedig a mai, fenyegetettségektől hemzsegő netes világban ez alapelvárás –, akkor minimum azzal a kényelmetlenséggel kell szembenéznie, hogy downgrade-elnie kell a JRE-t, hogy a szolgáltatást használhassa. De a másik probléma szerintem súlyosabb: a Javát – ahogy a szoftvereket általában – többek között azért is frissítik, hogy a biztonsági réseket befoltozzák, és egy korábbi verzió bizonyosan tartalmaz már ismert sérülékenységeket. A UniCredit által telepítésre felajánlott verzió a JRE 6u35 2012 augusztusában jelent meg, most már az idén októberben megjelent 7u45 a legfrissebb, az eltelt több mint egy évben húsznál több frissítés jelent meg, melyek többek között kritikus, például távoli kódfuttatást lehetővé tévő biztonsági réseket tömtek be. Vagyis úgy ítéltem meg, hogy a régi JRE megkövetelése igenis hordoz biztonsági kockázatokat, ezért hivatalos választ kértem a banktól, hogy szerintük nem kockázatos-e ez a gyakorlat, illetve mikor fogják frissíteni a rendszert.

Nesze semmi, fogd meg jól

Ma megkaptam a kommunikációs felelőstől a választ, melyet először teljes egészében szeretnék idézni:

Az UniCredit Bank clickFX rendszere mindenekelőtt vállalati ügyfeleink speciális pénzügyi igényekkel rendelkező köre számára ajánlott szolgáltatás. Funkciójából adódóan nem alkalmas direkt haszonszerzést célzó támadások kivitelezésére, mivel a rendszeren keresztül ügylet kizárólag az ügyfél bankunknál vezetett, az ügyletben érintett devizapárnak megfelelő devizanemű számlái javára és terhére köthető. A rendszert több elemből álló védelem veszi körül, melyben az egyik legfontosabb védelmi kör, hogy titkosított HTTPS-kapcsolaton keresztül kommunikál, szigorú jelszópolitikával rendelkezik, az üzletkötések monitorozása pedig folyamatos. Egyébként természetesen nem csupán a clickFX-felhasználóinknak, hanem a bankügyeiket interneten intéző valamennyi ügyfelünknek mindenképpen javasoljuk a tűzfal, valamint kémprogramok elleni és vírusvédelmi aktuális szoftver használatát, hiszen ezek ma már közismerten nélkülözhetetlen biztonsági elemek.

A rendszer frissítése a fentiekből is következően tehát nem biztonsági hiányosság okán, hanem az újabb Java-verziók használata érdekében szerepel a fejlesztési terveinkben, a prioritások szerinti besorolás jelenleg folyik.

Az első nagy feladat a szöveg értelmezése, ez nekem is csak többedszerre sikerült. Amikor végre igen, akkor természetesen az IT-körökben is gyakran használt angol szó jutott eszembe, mely b-vel kezdódik és it-tel ér véget.

A sebezhetőség az sebezhetőség

Sem a minket megkereső olvasó, sem én nem állítottam, hogy közvetlen haszonszerzésre nyújt lehetőséget egy JRE-sebezhetőség, azt viszont magától értetődőnek vettem, hogy a banknál is tudják: a biztonsági rendszer annyit ér, amennyit a leggyengébb láncszeme. A sebezhetőségekre vadászó kiberbűnözők, a crackerek magasan képzett informatikusok: nekik a legtöbb esetben elég, hogy egy hajszálnyi résen át bejussanak egy rendszerbe, onnan már meglehetős nagy találékonysággal képesek továbblépni. Ehhez felhasználnak technikai, de nagyon sok esetben social engineering megoldásokat is – ha már egy kicsit belelátnak, akkor keresnek jelszavakat, e-mail címeket, egyéb azonosító adatokat, illetve új sebezhetőségeket, hogy még mélyebbre jussanak be. Ez sajnos nagyon gyakran sikerül is nekik.

Ebből következik, hogy a bank levélében felsorolt szolgáltatói, illetve felhasználói biztonsági intézkedések az égvilágon semmint nem érnek, ha a JRE régi verziójának sebezhetőségét egy cracker sikeresen használja ki.

Összességében még mindig úgy látom, hogy az a hozzáállás, mely szerint a rendszer frissítése „az újabb Java-verziók használata érdekében szerepel a fejlesztési terveinkben, a prioritások szerinti besorolás jelenleg folyik”, nem feltétlenül elfogadható. Ha az átlagfelhasználótól is elvárás ma már, hogy saját biztonsága érdekében mindig a szoftverek legújabb verzióját használja, akkor ez miért nem evidens egy különösen érzékeny, a crackerek körében kedvelt célpontnál, egy banknál?

Azóta történt

Előzmények