новые a Matrix decentralizált üzenetküldő platform infrastruktúrájának feltöréséről, amelyről reggel. A problémás kapcsolat, amelyen keresztül a támadók behatoltak, a Jenkins folyamatos integrációs rendszere volt, amelyet március 13-án törtek fel. Ekkor a Jenkins szerveren az egyik rendszergazda SSH-ügynök által átirányított bejelentkezését elfogták, és április 4-én a támadók más infrastruktúra-szerverekhez is hozzáfértek.
A második támadás során a matrix.org webhelyet egy másik szerverre (matrixnotorg.github.io) irányították át a DNS-paraméterek megváltoztatásával, az első támadás során elfogott Cloudflare tartalomszolgáltató API kulcsának használatával. Amikor az első feltörés után újraépítették a szerverek tartalmát, a Matrix rendszergazdái csak új személyes kulcsokat frissítettek, és elmulasztották a kulcs frissítését a Cloudflare-hez.
A második támadás során a Matrix szerverek érintetlenek maradtak, a változtatások csak a DNS-ben található címek cseréjére korlátozódtak. Ha a felhasználó az első támadás után már megváltoztatta a jelszavát, akkor nincs szükség másodszori módosítására. De ha a jelszót még nem változtatták meg, akkor a lehető leghamarabb frissíteni kell, mivel az adatbázis jelszókivonatokkal való kiszivárgása megerősítést nyert. A jelenlegi terv szerint a következő bejelentkezéskor kötelező jelszó-visszaállítási folyamatot kezdeményeznek.
A jelszavak kiszivárogtatása mellett az is megerősítést nyert, hogy a Debian Synapse tárolójában és a Riot/Web kiadásokban lévő csomagok digitális aláírásának generálására használt GPG kulcsok kerültek a támadók kezébe. A kulcsok jelszóval védettek voltak. A kulcsokat jelenleg már visszavonták. Április 4-én elkapták a kulcsokat, azóta nem adtak ki Synapse frissítést, viszont megjelent a Riot/Web kliens 1.0.7 (előzetes ellenőrzés azt mutatta, hogy nem sérült).
A támadó egy sor jelentést tett közzé a GitHubon a támadás részleteivel és a védelem növelésére vonatkozó tippekkel, de ezeket törölték. Az archivált jelentések azonban .
Például a támadó arról számolt be, hogy a Mátrix fejlesztőinek meg kell tenniük kéttényezős hitelesítés, vagy legalábbis nem használ SSH-ügynök átirányítást („ForwardAgent igen”), akkor az infrastruktúrába való behatolás blokkolva lenne. A támadás eszkalációját úgy is meg lehetne állítani, ha a fejlesztőknek csak a szükséges jogosultságokat adnák meg minden szerveren.
Ezenkívül kritizálták azt a gyakorlatot, hogy a digitális aláírás létrehozásához szükséges kulcsokat éles szervereken tárolják, ezért külön izolált gazdagépet kell kijelölni erre a célra. Még mindig támad , hogy ha a Matrix fejlesztői rendszeresen auditálták volna a naplókat és elemezték volna az anomáliákat, már korán észrevették volna a feltörés nyomait (a CI feltörést egy hónapig nem észlelték). Még egy probléma az összes konfigurációs fájl tárolása a Gitben, ami lehetővé tette más gazdagépek beállításainak kiértékelését, ha valamelyiket feltörték. Hozzáférés SSH-n keresztül az infrastruktúra-kiszolgálókhoz biztonságos belső hálózatra korlátozva, amely lehetővé tette, hogy bármilyen külső címről csatlakozhassanak hozzájuk.
Forrásopennet.ru
[En]новые a Matrix decentralizált üzenetküldő platform infrastruktúrájának feltöréséről, amelyről reggel. A problémás kapcsolat, amelyen keresztül a támadók behatoltak, a Jenkins folyamatos integrációs rendszere volt, amelyet március 13-án törtek fel. Ekkor a Jenkins szerveren az egyik rendszergazda SSH-ügynök által átirányított bejelentkezését elfogták, és április 4-én a támadók más infrastruktúra-szerverekhez is hozzáfértek.
A második támadás során a matrix.org webhelyet egy másik szerverre (matrixnotorg.github.io) irányították át a DNS-paraméterek megváltoztatásával, az első támadás során elfogott Cloudflare tartalomszolgáltató API kulcsának használatával. Amikor az első feltörés után újraépítették a szerverek tartalmát, a Matrix rendszergazdái csak új személyes kulcsokat frissítettek, és elmulasztották a kulcs frissítését a Cloudflare-hez.
A második támadás során a Matrix szerverek érintetlenek maradtak, a változtatások csak a DNS-ben található címek cseréjére korlátozódtak. Ha a felhasználó az első támadás után már megváltoztatta a jelszavát, akkor nincs szükség másodszori módosítására. De ha a jelszót még nem változtatták meg, akkor a lehető leghamarabb frissíteni kell, mivel az adatbázis jelszókivonatokkal való kiszivárgása megerősítést nyert. A jelenlegi terv szerint a következő bejelentkezéskor kötelező jelszó-visszaállítási folyamatot kezdeményeznek.
A jelszavak kiszivárogtatása mellett az is megerősítést nyert, hogy a Debian Synapse tárolójában és a Riot/Web kiadásokban lévő csomagok digitális aláírásának generálására használt GPG kulcsok kerültek a támadók kezébe. A kulcsok jelszóval védettek voltak. A kulcsokat jelenleg már visszavonták. Április 4-én elkapták a kulcsokat, azóta nem adtak ki Synapse frissítést, viszont megjelent a Riot/Web kliens 1.0.7 (előzetes ellenőrzés azt mutatta, hogy nem sérült).
A támadó egy sor jelentést tett közzé a GitHubon a támadás részleteivel és a védelem növelésére vonatkozó tippekkel, de ezeket törölték. Az archivált jelentések azonban .
Például a támadó arról számolt be, hogy a Mátrix fejlesztőinek meg kell tenniük kéttényezős hitelesítés, vagy legalábbis nem használ SSH-ügynök átirányítást („ForwardAgent igen”), akkor az infrastruktúrába való behatolás blokkolva lenne. A támadás eszkalációját úgy is meg lehetne állítani, ha a fejlesztőknek csak a szükséges jogosultságokat adnák meg minden szerveren.
Ezenkívül kritizálták azt a gyakorlatot, hogy a digitális aláírás létrehozásához szükséges kulcsokat éles szervereken tárolják, ezért külön izolált gazdagépet kell kijelölni erre a célra. Még mindig támad , hogy ha a Matrix fejlesztői rendszeresen auditálták volna a naplókat és elemezték volna az anomáliákat, már korán észrevették volna a feltörés nyomait (a CI feltörést egy hónapig nem észlelték). Még egy probléma az összes konfigurációs fájl tárolása a Gitben, ami lehetővé tette más gazdagépek beállításainak kiértékelését, ha valamelyiket feltörték. Hozzáférés SSH-n keresztül az infrastruktúra-kiszolgálókhoz biztonságos belső hálózatra korlátozva, amely lehetővé tette, hogy bármilyen külső címről csatlakozhassanak hozzájuk.
Forrás: opennet.ru
[:]