Tényleg downgrade-támadás egy meghiúsult VPN-kézfogás?

A hibával végződő kézfogás támadásnak tűnik, amíg meg nem nézi az üzenetet, és legtöbbször aritmetika: nincs közös ajánlat, lejárt tanúsítvány vagy csomag, amely soha nem érkezett meg. A downgrade-támadás konkrét dolog: a támadó mindkét felet a választottnál gyengébb viselkedés felé tereli, és más nyomokat hagy. Minden kudarcot rosszindulatnak tekintve olyan áldozatot keres, aki talán nem is létezik, míg egy valódi downgrade-et konfigurációs hibának tekintve a gyengébb eredmény a helyén marad. A két hiba különbözőképpen kerül, és csak az egyik javítható olcsón.

Mit változtat meg valójában a downgrade-támadás

A cél nem a titkosítás feltörése és nem a kulcs kitalálása. A cél a tárgyalás befolyásolása, hogy mindkét fél egy régebbi verzióra vagy gyengébb algoritmusra álljon rá, amelyet a támadó kezelni tud, vagy hogy az egyik fél azt higgye, a másik csak azt támogatja.

A megállapodás változik, nem a hitelesítés. Ha a támadó észrevétlenül módosíthatja az ajánlatot, a felek továbbra is befejezhetik a kézfogást és továbbra is hitelesíthetik egymást, de a támadó által előnyben részesített paraméterekkel. Ezért az érdekes kérdés az, hogy magát a tárgyalást lefedi-e az integritásvédelem.

Miért kell magát a tárgyalást hitelesíteni

A TLS 1.3 ezt a védelmet kifejezetté teszi. Az újabb verziót felajánló kliens észlelheti a csendben visszalépő szervert, mert a szerver véletlen értéke rögzített mintát hordoz, amikor 1.2-re vagy alacsonyabbra tárgyal, és a kliensnek meg kell szakítania, amikor ezt látja. A teljes átiratot a záró üzenetek is lefedik, így a tárgyalás bármely pontján végzett módosítás később meghiúsul, nem megy át csendben.

A régebbi protokollverzióknak gyengébb történeteik voltak, és pont ezért számítanak a visszalépési szabályok. Egy TLS 1.0 végpont ugyanabban a konfigurációban nem downgrade-támadás; ez egy engedélyezett kimenet, amelyet Ön döntött úgy, hogy engedélyez. A különbség az, hogy a gyengébb eredmény védett döntésből vagy olyan védelem nélküli útból származott-e, amelyet egy közvetítő befolyásolhatott. Ha így fogalmazza meg, a legtöbb esemény konfigurációs kérdéssé válik.

Az IKEv2 másképp viselkedik, de ugyanazon az ötleten nyugszik. Az ajánlat olyan cserében utazik, amely később mindkét felet hitelesíti, így az algoritmusokat átíró köztes eszköz megtöri a hitelesítést ahelyett, hogy irányítaná. Az OpenVPN vezérlőcsatornája TLS-sel védi a tárgyalását, majd ezt a csatornát használja az adatcsatorna titkosításainak egyeztetésére, ezért az érdekes sor a vezérlőcsatorna naplósora.

A beállított kompatibilitás nem támadás

A rendszergazda szándékosan engedélyezhet régebbi választásokat egy dokumentált kliens támogatásához, és ez a döntés látható a konfigurációban. A támadó nem hozhatja létre ezt a konfigurációt; csak olyan utat használhat ki, amely lehetővé teszi számára az ajánlat befolyásolását.

A veszélyes javítás az, amely eltávolítja a különbség bizonyítékát. Minden örökölt beállítás engedélyezése, a tanúsítvány-ellenőrzés kikapcsolása vagy bármely titkosítás elfogadása, hogy a hiba eltűnjön, kiszélesíti, mire lesz hajlandó a végpont, és eltávolítja azokat az ellenőrzéseket, amelyek jelezték volna a gyengébb eredményt.

Ha meg kell tartania egy régi beállítást, nevezze meg az okot és a klienst a konfigurációs megjegyzésben, majd korlátozza a beállítást arra a profilra, amelynek szüksége van rá. Az egy hallgatóra korlátozott kompatibilitási kivétel auditálható; a globálisan alkalmazott csak egy gyengébb alapértelmezés, amelyre senki nem emlékszik, hogy választotta.

Olvassa el a kudarcot, mielőtt okot nevez meg

Bármilyen változtatás előtt őrizze meg a pontos hibaüzenetet, a kliens és a szerver verzióit és az időpontot. Utána sorolja be: a felek nem értettek egyet az ajánlatban, a csomagútvonal hibázott, vagy az egyik fél elutasított egy korábban elfogadott paramétert?

Az ajánlat eltérése általában megnevezi a hibás verziókat vagy algoritmusokat, és minden alkalommal ugyanabban a pontban hibázik. Az útvonal- vagy MTU-probléma elakad vagy időtúllépésbe fut, és gyakran hálózatfüggő. A lejárt tanúsítvány ellenőrzési hibát ad, nem tárgyalási hibát.

Ezek egyike sem bizonyíték támadóra. Az első kudarcnál rosszindulatú okot tulajdonítani a hiba, mert elrejti a determinisztikus hibát, amely holnap újra meghiúsul.

Erősítse meg, mit választottak valójában

Bármilyen javítás után olvassa el a kialkudott eredményt, ahelyett hogy megbízna abban, hogy a kapcsolat felállt. Az a kapcsolat, amely azért sikeres, mert eltávolították az ellenőrzést, az az eredmény, amelyet el akart kerülni. A következő két parancs a TLS elé tett végpont választott verzióját és titkosítását mutatja, valamint a vezérlőcsatorna sorát egy OpenVPN szerver naplójából.

openssl s_client -connect 198.51.100.30:443 -servername vpn.example.net -brief </dev/null
grep -iE 'Control Channel|Data Channel' /var/log/openvpn.log | tail -5

Hasonlítsa össze az eredményt a szándékolt konfigurációval, ne azzal, ami most csatlakozik. Ha a választott verzió régebbi az engedélyezett minimumnál, a profil vagy a visszalépési lista az, ahol keresni kell, és a válasz az, hogy javítsa azt a listát, ne pedig támadást kiáltson ki és építsen újjá mindent körülötte.