Onko epäonnistunut VPN-kättely todella downgrade-hyökkäys?

Virheeseen päättyvä kättely tuntuu hyökkäykseltä, kunnes katsoo viestiä, ja useimmiten kyse on aritmetiikasta: ei yhteistä tarjousta, vanhentunut varmenne tai paketti, joka ei koskaan saapunut. Downgrade-hyökkäys on jotain tiettyä: vastustaja työntää molemmat päät heikompaan käytökseen kuin ne olisivat valinneet, ja se jättää erilaiset jäljet. Jokaisen epäonnistumisen pitäminen pahantahtoisuutena lähettää etsimään uhria, jota ei ehkä ole, kun taas todellisen downgraden pitäminen konfiguraatiovirheenä jättää heikomman tuloksen paikoilleen. Nämä kaksi virhettä maksavat eri tavalla, ja vain toinen on halpa korjata.

Mitä downgrade-hyökkäys oikeastaan muuttaa

Tavoite ei ole murtaa salausta eikä arvata avainta. Tavoite on vaikuttaa neuvotteluun niin, että molemmat osapuolet päätyvät vanhempaan versioon tai heikompaan algoritmiin, jonka hyökkääjä hallitsee, tai saada toinen osapuoli uskomaan, että toinen tukee vain sitä.

Muuttuu sopimus, ei todentaminen. Jos hyökkääjä voi muuttaa tarjousta havaitsematta, osapuolet voivat silti suorittaa kättelyn loppuun ja todentaa toisensa, mutta hyökkääjän suosimilla parametreilla. Siksi kiinnostava kysymys on, onko itse neuvottelu eheyssuojauksen piirissä.

Miksi itse neuvottelu on todennettava

TLS 1.3 tekee tämän suojauksen eksplisiittiseksi. Asiakas, joka tarjosi uudempaa versiota, voi havaita palvelimen, joka on hiljaa pudonnut taaksepäin, koska palvelimen satunnaisarvo kantaa kiinteää kuviota sen neuvotellessa 1.2 tai alempaa, ja asiakkaan on keskeytettävä sen nähdessään. Koko transkripti on myös loppuviestien peittämä, joten muutos missä tahansa neuvottelussa epäonnistuu myöhemmin sen sijaan, että menisi hiljaa läpi.

Vanhemmilla protokollaversioilla oli heikommat tarinat, ja juuri siksi varautumissäännöt ovat tärkeitä. TLS 1.0 -päätepiste samassa kokoonpanossa ei ole downgrade-hyökkäys; se on sallittu tulos, jonka itse valitsit sallia. Ero on siinä, tuliko heikompi tulos suojatusta päätöksestä vai suojaamattomasta polusta, johon välittäjä saattoi vaikuttaa. Kun sen muotoilee näin, useimmat tapaukset ratkeavat konfiguraatiokysymykseksi.

IKEv2 käyttäytyy eri tavalla mutta nojaa samaan ideaan. Tarjous kulkee vaihdossa, joka myöhemmin todentaa molemmat osapuolet, joten algoritmit uudelleen kirjoittava välilaite rikkoo todentamisen sen sijaan että ohjaisi sitä. OpenVPN:n ohjauskanava suojaa neuvottelunsa TLS:llä ja käyttää sitten tätä kanavaa datakanavan salauksista sopimiseen, ja siksi juuri ohjauskanavan lokirivi on kiinnostava.

Määritetty yhteensopivuus ei ole hyökkäys

Ylläpitäjä voi tarkoituksella sallia vanhempia valintoja dokumentoidun asiakkaan tukemiseksi, ja päätös näkyy konfiguraatiossa. Hyökkääjä ei voi luoda sitä konfiguraatiota; hän voi vain hyödyntää polkua, joka sallii hänen vaikuttaa tarjoukseen.

Vaarallinen korjaus on se, joka poistaa todisteen erosta. Kaikkien vanhojen valintojen käyttöönotto, varmenteen tarkistuksen poistaminen tai minkä tahansa salauksen hyväksyminen virheen häivyttämiseksi laajentaa sitä, mihin päätepiste suostuu, ja poistaa tarkistukset, jotka olisivat raportoineet heikomman tuloksen.

Jos sinun on pidettävä yksi vanha valinta, nimeä syy ja asiakas konfiguraation kommenttiin ja rajaa valinta sitten profiiliin, joka sitä tarvitsee. Yhteen kuuntelijaan rajattu yhteensopivuuspoikkeus on auditoitavissa; maailmanlaajuisesti sovellettu on vain heikompi oletusarvo, jota kukaan ei muista valinneensa.

Lue epäonnistuminen ennen kuin nimeät syyn

Säilytä tarkka virhemerkkijono, asiakkaan ja palvelimen versiot sekä aika ennen mitään muutosta. Luokittele sitten: olivatko osapuolet eri mieltä tarjouksesta, pettikö pakettipolku vai hylkäsikö toinen osapuoli parametrin, jonka oli aiemmin hyväksynyt?

Tarjouksen ero nimeää yleensä syylliset versiot tai algoritmit ja epäonnistuu joka kerta samassa kohdassa. Reititys- tai MTU-ongelma pysähtyy tai aikakatkaisee, ja se vaihtelee usein verkon mukaan. Vanhentunut varmenne tuottaa tarkistusvirheen eikä neuvotteluvirhettä.

Mikään tästä ei ole todiste hyökkääjästä. Pahantahtoisen syyn osoittaminen ensimmäisellä epäonnistumisella on virhe, koska se kätkee deterministisen virheen, joka epäonnistuu uudelleen huomenna.

Vahvista, mitä todella valittiin

Lue korjauksen jälkeen neuvoteltu tulos sen sijaan, että luottaisit yhteyden nousuun. Yhteys, joka onnistuu siksi, että tarkistus poistettiin, on tulos, jota yritit välttää. Seuraavat kaksi komentoa näyttävät valitun version ja salauksen TLS:n edessä olevalle päätepisteelle sekä ohjauskanavan rivin OpenVPN palvelimen lokista.

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

Vertaa tulosta konfiguraatioon, jonka tarkoitit, älä siihen, mikä nyt yhdistää. Jos valittu versio on sallittua vähimmäistasoa vanhempi, profiili tai varautumislista on paikka, josta etsiä, ja vastaus on korjata se lista sen sijaan, että julistaisit hyökkäyksen ja rakentaisit kaiken sen ympärille uudelleen.