Nel centro di certificazione SSL.com è stata identificata una vulnerabilità nel sistema di verifica della proprietà del dominio, che consentiva di ottenere un certificato TLS per qualsiasi dominio fornendo un'email all'attaccante. Per ottenere il certificato TLS era sufficiente accedere all'email associata al dominio obiettivo. Ad esempio, la vulnerabilità consentiva di ottenere un certificato TLS per domini utilizzati in servizi email pubblici come gmail.com, yandex.ru, yahoo.com, outlook.com e icloud.com.
La vulnerabilità consentiva inoltre agli aggressori di effettuare attacchi mirati ai dipendenti di aziende note e ai partecipanti a grandi progetti per ottenere accesso alle loro email e ottenere certificati TLS per nomi noti dei domini. Ad esempio, hackerare un dipendente di Google con email name@google.com consentiva di ottenere un certificato per il dominio google.com.
La vulnerabilità era causata da un errore nell'implementazione del sistema di verifica della proprietà del dominio tramite conferma via email. Per ottenere la conferma via email, è necessario aggiungere nella zona DNS del dominio per cui si richiede il certificato, un record DNS TXT «_validation-contactemail». Ad esempio, «_validation-contactemail.test.com DNS TXT name@example.com». Dopo l'inizio della verifica del dominio, a name@example.com verrà inviato un codice di conferma, la cui immissione conferma la proprietà del dominio «test.com» e consente di ottenere un certificato TLS per «test.com».
Il problema della vulnerabilità è che, oltre al dominio «test.com» per il quale è stato richiesto il certificato, l'indicatore di conferma della proprietà veniva impostato anche per il dominio «example.com», utilizzato nell'email. Il ricercatore che ha scoperto il problema ha dimostrato di aver ottenuto un certificato TLS funzionante per il dominio aliyun.com, utilizzato nel servizio webmail dalla compagnia cinese Alibaba. Durante un attacco di prova, il ricercatore ha registrato un dominio di controllo «d2b4eee07de5efcb8598f0586cbf2690.test.dcv-inspector.com» nel servizio «dcv-inspector.com» e ha richiesto per esso un certificato TLS, aggiungendo il record DNS: _validation-contactemail.d2b4eee07de5efcb8598f0586cbf2690.test.dcv-inspector.com DNS TXT myusername@aliyun.com
Dopo di ciò, ha richiesto sul sito SSL.com un certificato TLS per il dominio d2b4eee07de5efcb8598f0586cbf2690.test.dcv-inspector.com e ha scelto la conferma tramite email. L'autorità di certificazione SSL.com ha inviato un codice di verifica a myusername@aliyun.com e, dopo aver inserito questo codice, ha aggiunto alla lista dei domini verificati non solo "d2b4eee07de5efcb8598f0586cbf2690.test.dcv-inspector.com", ma anche "aliyun.com". Successivamente, il ricercatore ha ottenuto con successo un certificato TLS per il dominio "aliyun.com", la cui proprietà è stata confermata.
L'autorità di certificazione SSL.com ha risolto il problema e ha identificato 11 certificati, per i quali era stata utilizzata una vulnerabile schema di verifica con dominio esterno via email. Presumibilmente, nei casi identificati non ci sono segni di attività dannosa e dei 11, fino ad ora è stato revocato solo un certificato, quello ottenuto dal ricercatore per il sito aliyun.com. Negli altri certificati figuravano i domini medinet.ca, help.gurusoft.com.sg, banners.betvictor.com, production-boomi.3day.com, kisales.com e medc.kisales.com. Il report sull'incidente sarà pubblicato dalla società SSL.com entro il 2 maggio.
Fonte: opennet.ru
