"Illetéktelenek az Oktatási Hivatal rendszerében tárolt adatokat hoztak nyilvánosságra"

HUP cikkturkáló

Az Oktatási Hivatal Tehetségkapu portálját (https://www.tehetsegkapu.hu/) rosszindulatú támadás érte. Az elkövető megszerezte, majd ezt követően közzétette a portál regisztrált felhasználóinak nevét és e-mail-címét. Jelszó vagy egyéb személyes adat nem került ki a rendszerből. A támadás a kompetenciamérés aktív időszaka alatt történt, de a digitális országos mérést és a benne résztvevő tanulók adatait nem érintette, a mérések továbbra is zökkenőmentesen zajlanak. A támadás módjának feltárása és az elhárítás folyamatban van, az Oktatási Hivatal elnöke a szükséges hatósági és rendőrségi bejelentéseket haladéktalanul megteszi és az érintetteket értesíti.

(forrás)

  • 1157 megtekintés

( zeller | 2025. 03. 29., szo – 10:23 )

A tehetség a kapuhoz megvolt, a biztonságos fejlesztéshez nem igazán...

( Zs | 2025. 03. 29., szo – 11:38 )

Az elkövető megszerezte a felhasználók nevét és e-mail címét. Miért gondoljuk, hogy mást nem? Oké, ha a jelszó kódoltan van, az védheti a jelszót - na de az egyéb személyes adattal mi van? Azt miért is nem sikerült megszerezni, ha már a DB-ben járt?

Az, hogy a DB-ből (melyikből? melyik sémából?) kinyert adatokat, még nem jelenti azt, hogy "mindenhez is" hozzá tudott férni. Jobb körökben a loginhoz szükséges adatok, illetve a jogosultsági információk az ezekkel védett adatoktól szeparáltan vannak kezelve: másik DB, de minimum másik séma - pont azért, hogy egy ilyen támadást követően ne "mindent is" lehessen azonnal elvinni. Persze ha van gyenge, akár bruteforce, akár szivárványtáblával visszanyerhető jelszó az elvitt adathalmazban, _és_ ha van 2FA, akkor annak a shared secret-je is ott volt tárolva, akkor azzal az identitással már képes a támadó a rendszert adott user jogaival használni, illetve támadni.

Mondjuk ilyen mértékben szeparáltan kezelt AAA adatokat nemsok helyen láttam :-( (Minimum három séma/db: egyikben a login 1. faktora, másikban meghatározott eljáráson keresztül a 2FA aktuális kódja kérdezhető le (select jog nincs, csak execute az adott eljárásra), harmadikban (meg a többiben) a védett adatok.

Igen, ezt nem egyszerű megvalósítani, sokkal több meló, mint egybe behányni mindent, és mindent a portál php/java/lóf@szj0ska kódjából kezelni...

Igazad van abban, hogy biztonságosabbá tehető a rendszer és ha külön DB a 2FA adat, külön DB a pwd, külön db az egyéb, akkor lehet, hogy valóban csak az usr+e-mail címet tudták megszerezi. (Már ha nem sikerült tovább jutni.)
Ugyanakkor

  • ennek azért kicsit nagyobb az erőforrás igénye, magasabb a bonyolultsága, így több a hibalehetősége is. Nem mondom, hogy nem létezhet ilyen rendszer, szinte biztos, hogy van is - de nem ez a tipikus,
  • ahol a biztonságra ennyit adnak, ott vélelmezem, hogy a legelső védelmi vonal is erősen védett, tehát a betörőnknek illett volna ott elakadnia, azaz már az usr+e-mail megszerzésnek se lett volna szabad összejönnie.

Az usernév/jelszó párost _is_ lehet úgy védeni, hogy a webes szutyok csak egy sémát lát, amiben van n darab eljárás (új regisztrációhoz, regisztráció törléséhez, illetve user/pw ellenőrzéséhez, stb.) _és_ ezek futnak le az adatokat tartalmazó DB-ben/sémában - azaz maga a kód nem a webes alkalmazásban, hanem a DB-ben van, és a védett adatokhoz csak ezeken keresztül, kontrolláltan, meghatározott funkciókkal lehet hozzáférni. Ezt persze a bootcamp-ez meg önképzőkörös kódf0sóknak nem tanítják, de ugye nem nekik kéne a rendszer felépítését kitalálni... (Ja, hogy architect-ek is vannak bootcamp+önképzőkör szintű előélettel...?)

 

Ezt persze a bootcamp-ez meg önképzőkörös kódf0sóknak nem tanítják

Én általában bármmikor vevő vagyok egy kis szükségtelen fölényeskedésre, de a kódfosók tanulják csak nyugodtan az oauth2-t, ezeket a házibarkács auth gányolámegoldásokat meg hagyják meg nyugodtan az Igazi Mérnököknek.