Właściwa weryfikacja dostępu do domeny jest głównym zadaniem urzędów certyfikacji podczas wydawania certyfikatów SSL. Niestety, w ostatnich dniach po raz kolejny mogliśmy przeczytać o błędzie, którego konsekwencją było unieważnienie prawie 9000 certyfikatów.

Jak było?

GoDaddy, bo tym razem o tym urzędzie certyfikacji mowa, 10 stycznia 2017 –  poprzez swoją stronę internetową – poinformował o odkryciu i jednocześnie o załataniu błędu przez który zmuszeni byli unieważnić wiele certyfikatów SSL wystawionych w ciągu ubiegłego półrocza. Błąd mógł prowadzić do nieautoryzowanego uzyskania certyfikatów SSL, stąd decyzja o unieważnienach.

Chronologia zdarzeń wyglądała następująco:

29 lipca 2016 –  GoDaddy instaluje nową wersję oprogramowania, która wprowadza poprawki do procesu wydawania certyfikatów. Niestety aktualizacja zawiera także błąd o którym jest ten wpis, a którego GoDaddy nie jest świadome.

3 stycznia 2017 – Microsoft mailowo zgłasza do GoDaddy informację o błędzie. Microsoft dowiedział się o błędzie od swojego klienta.

6 stycznia 2017 – GoDaddy odczytuje zgłoszenie i rozpoczyna analizę błędu. Od momentu zgłoszenia do momentu podjęcia jakichkolwiek działań minęły 3 dni, ale GoDaddy jest tutaj w pełni usprawiedliwione, ponieważ Microsoft nie zgłosił błędu zgodnie z wytycznymi zapisanymi w Kodeksie Postępowania Certyfikacyjnego (Certificate Practice Statement).

6 stycznia 2017 – GoDaddy instaluje poprawkę, która usuwa błąd.

7 stycznia 2017 – GoDaddy orientuje się, że błąd istniał w systemie od momentu zainstalowania aktualizacji z 29 lipca 2016.

9 stycznia 2017 – GoDaddy określa, że około 2% z wszystkich wydanych w tym czasie certyfikatów tj. od 29 lipca 2016 do 6 stycznia 2017 mogło zostać zainfekowane przez błąd. Daje to aż 8850 potencjalnie nieautoryzowanych wydań certyfikatów SSL.

10 stycznia 2017 – GoDaddy unieważnia 8,951 certyfikatów (do wspomnianych 8850 doszły 101, które zostały wydane na podstawie wcześniej zapamiętanych nieprawidłowych weryfikacji domen).

Dlaczego użyłem słowa potencjalnie pisząc o nieautoryzowanych wydaniach? Chociażby dlatego, że nie wiadomo ile z wydanych certyfikatów rzeczywiście zostało wydanych dla osób nieposiadających kontroli nad daną domeną (które celowo lub przypadkowo wykorzystały błąd), a ile po prostu dostało certyfikat dla swojej domeny z tym że bez właściwej weryfikacji.

Szczegóły błędu

Podatność dotyczyła weryfikacji dostępu do domeny za pomocą umieszczenia pliku o danej nazwie w danym miejscu na serwerze. W celu weryfikacji domeny GoDaddy prosiło klientów o umieszczenie pliku losowa_wartosc.html w głównym katalogu danego serwera. System automatycznie sprawdzał czy dany plik istnieje i jeżeli tak, uznawał domenę za zweryfikowaną.

Problem dotyczył tego jak wykonywane było owo sprawdzenie. Zwykle sprawdzany jest kod odpowiedzi HTTP (pożądany kod to 200 – OK) i następnie, jako minimum, to czy zgadza się jego nazwa. I tak też było do lipcowej aktualizacji. Niestety nowa wersja oprogramowania pomijała sprawdzanie kodu odpowiedzi HTTP.

Jak można było wykorzystać taką podatność? Wystarczyło skonfigurować serwer w ten sposób, żeby w momencie odpytania o nieistniejący plik (serwer odpowiada wtedy kodem HTTP 404 – Not Found) dodatkowo w treści odpowiedzi (Message Body) zwracany był żądany, nieistniejący URL. Wtedy aplikacja GoDaddy odnajdywała żądaną nazwę pliku (losowa_wartosc.html) i było dla niej wystarczające do uznania domeny za zweryfikowaną.

Procesy weryfikacji do poprawki

Błędów w weryfikacji domen podczas wystawiania certyfikatów SSL w ubiegłym roku nie brakowało. Sytuacji stara się zaradzić CA/Browser Forum, które dość gruntownie przepisało zasady weryfikacji domen dla certyfikatów SSL. Zmiany powinny zostać zaimplementowane przez urzędy certyfikacji do 1 marca 2017 i powinny pozwolić na uniknięcie podobnych przypadków – do tego opisanego tutaj – w przyszłości.