W centrum certyfikacji SSL.com odkryto lukę w systemie weryfikacji własności domeny, która umożliwiała uzyskanie certyfikatu TLS dla dowolnej domeny, pod warunkiem podania atakującemu adresu email. Do uzyskania certyfikatu TLS wystarczył dostęp do emaila z docelową domeną. Na przykład, luka ta umożliwiała uzyskanie certyfikatu TLS dla domen używanych w publicznych usługach emailowych, takich jak gmail.com, yandex.ru, yahoo.com, outlook.com i icloud.com.
Luka ta dawała również przestępcom możliwość przeprowadzania celowych ataków na pracowników znanych firm i uczestników dużych projektów w celu zdobycia dostępu do ich emaili i uzyskania certyfikatów TLS dla znanych. domenów. Na przykład, włamanie do pracownika Google, mającego email name@google.com, umożliwiało uzyskanie certyfikatu dla domeny google.com.
Luka została spowodowana błędem w implementacji systemu weryfikacji własności domeny przez potwierdzenie za pośrednictwem emaila. Aby uzyskać potwierdzenie przez email, należy dodać do strefy DNS domeny, dla której żądany jest certyfikat, rekord DNS TXT „_validation-contactemail”. Na przykład, „_validation-contactemail.test.com DNS TXT name@example.com”. Po zainicjowaniu weryfikacji domeny na email name@example.com zostanie wysłany kod potwierdzający, którego wprowadzenie potwierdza własność domeny „test.com” i umożliwia uzyskanie certyfikatu TLS dla „test.com”.
Istotą luki jest to, że oprócz domeny „test.com”, dla której żądany był certyfikat, znak potwierdzenia własności był również wystawiany dla domeny „example.com”, używanej w emailu. Badacz, który wykrył problem, zademonstrował uzyskanie działającego certyfikatu TLS dla domeny aliyun.com, używanej w usłudze webmail chińskiej firmy Alibaba. W trakcie testowego ataku badacz zarejestrował domenę weryfikacyjną „d2b4eee07de5efcb8598f0586cbf2690.test.dcv-inspector.com” w serwisie „dcv-inspector.com” i zażądał dla niej certyfikatu TLS, dodając zapis DNS: _validation-contactemail.d2b4eee07de5efcb8598f0586cbf2690.test.dcv-inspector.com DNS TXT myusername@aliyun.com
Po tym poprosił na stronie SSL.com o certyfikat TLS dla domeny d2b4eee07de5efcb8598f0586cbf2690.test.dcv-inspector.com i wybrał potwierdzenie przez e-mail. Centrum certyfikacji SSL.com wysłało kod weryfikacyjny na myusername@aliyun.com, a po wprowadzeniu tego kodu dodało do listy zweryfikowanych domen nie tylko „d2b4eee07de5efcb8598f0586cbf2690.test.dcv-inspector.com”, ale również „aliyun.com”. Po tym badacz pomyślnie uzyskał certyfikat TLS dla domeny „aliyun.com”, której posiadanie zostało potwierdzone.
Centrum certyfikacji SSL.com usunęło problem i zidentyfikowało 11 certyfikatów, przy wydawaniu których zastosowano podatny schemat weryfikacji z użyciem zewnętrznej domeny w e-mailu. Domniemywa się, że w przypadkach, które zidentyfikowano, nie widać oznak działalności złośliwej, a spośród 11 dotychczas cofnięty został tylko jeden certyfikat, który został uzyskany przez badacza dla strony aliyun.com. W pozostałych certyfikatach występowały domeny medinet.ca, help.gurusoft.com.sg, banners.betvictor.com, production-boomi.3day.com, kisales.com oraz medc.kisales.com. Raport o incydencie firma SSL.com zamierza opublikować do 2 maja.
Źródło: opennet.ru
