Zwykły użytkownik bez problemów otrzymał certyfikat SSL ważnej domeny, dzięki któremu mógłby przeprowadzać ataki typu MiTM. A to wszystko dzięki niedopatrzeniu pracowników Microsoftu i luźnym regułom weryfikacji posiadaczy certyfikatów.
Dwa dni temu Microsoft wydał biuletyn bezpieczeństwa w którym poinformował o omyłkowym wydaniu certyfikatu SSL swojej domeny nieuprawnionemu użytkownikowi. Sprytny internauta nie musiał hakować wystawcy certyfikatów – po prostu odpowiednio poprosił.
Od skrzynki do certyfikatu
Proces zakupu certyfikatu SSL dla własnej domeny został przez wiele firm uproszczony w tak dużym stopniu, że nie bierze już w nim udziału żaden człowiek – oprócz kupującego. To uproszczenie spowodowało, że posiadaczem certyfikatu domeny live.fi, obsługującej w Finlandii elementy procesu uwierzytelnienia użytkownika wszystkich usług Microsoftu został pewien przedsiębiorczy Fin.
Aby zakupić certyfikat u jednego z największych ich wystawców, w firmie Comodo, wystarczy spełnić kilka prostych warunków. Trzeba zamówić usługę, zapłacić i zweryfikować swoją tożsamość za pomocą jednej z kilku dostępnych metod. Można stworzyć odpowiedni rekord DNS, wgrać na serwer odpowiedni plik lub posiadać dostęp do skrzynki pocztowej o jednym z następujących loginów: admin, administrator, postmaster, hostmaster lub webmaster. Po wybraniu uwierzytelnienia drogą poczty elektronicznej pozostaje już tylko czekać na odpowiednią wiadomość i kliknąć w znajdujący się w niej link, by chwilę potem otrzymać swój podpisany certyfikat. Comodo nie jest tutaj wyjątkiem – podobny proces stosuje większość wystawców certyfikatów SSL. Dopiero uzyskanie certyfikatu typu „premium” wymaga okazania dokumentów firmy.
Pewien anonimowy Fin z własnej ciekawości postanowił sprawdzić, czy w serwisie Microsoftu będzie mógł założyć konto pocztowe z loginem wymienionym powyżej. Skorzystał z funkcji aliasów i z zaskoczeniem stwierdził, że otrzymał dostęp do konta [email protected]. Postanowił pociągnąć test dalej i wystąpił do Comodo o certyfikat SSL – i go otrzymał. Następnie zawiadomił lokalnego regulatora rynku (nie wiemy, po co) oraz bliżej niesprecyzowane osoby w Microsofcie. Ani od jednych, ani od drugich nie otrzymał przez wiele tygodni żadnej odpowiedzi. Pewnego dnia jednak ktoś w Microsofcie się obudził i zablokował jego konto, wyłączając możliwość korzystania z telefonu, Xboxa oraz służbowej poczty. Taką cenę za swój sukces płacą eksperymentatorzy.
Certyfikaty Comodo
A mógł atakować
Microsoft powinien podziękować Finowi nie tylko za wskazanie błędu, ale także za to, że nie skorzystał ze zdobytego przez siebie certyfikatu do niecnych celów. Z jego pomocą prawdopodobnie mógł udawać witrynę logowania Microsoftu w sposób niezauważalny dla użytkowników, siejąc sporo zamieszania. Niektóre przeglądarki chronią wybrane domeny przed podobnymi atakami dzięki mechanizmowi certificate pinning (Chrome zna na pamięć np. certyfikaty Google, Firefox zna Google, Twittera czy Dropboksa), jednak Internet Explorer nie ma takiej funkcji (trzeba dodatkowo instalować EMETa by ją zapewnić). Atak mógł zatem być skuteczny w przypadku wszystkich przeglądarek.
Powyższy przykład pokazuje, jak mało bezpieczny jest mechanizm wydawania certyfikatów SSL. Nie trzeba wcale włamywać się do wystawców, by skompromitować zabezpieczenia. Jest mało prawdopodobne, by wystawcy zmienili mechanizmy uwierzytelnienia klientów – automatyczny proces jest wygodny i tani w obsłudze. Odpowiedzialność za utrzymanie bezpieczeństwa leży zatem po stronie właścicieli domen i w listach zakazanych loginów.
Jeśli uda się Wam założyć konto admin, administrator, postmaster, hostmaster lub webmaster w cudzym serwisie, to bądźcie tacy uprzejmi i powiadomcie o tym fakcie właściciela – a potem możecie się pochwalić nam.
Komentarze
[email protected] na stronie http://t.pl.
[email protected] na http://os.pl – Tu da sie wpisac loginy wszedzie po za [email protected].
Sprawa jest ciekawa i dyskusyjna :-)
Prawdopodobnie był to certyfikat SSL typu DV, która zawiera jedynie informacje o domenie, a Comodo otrzymało potwierdzenie poprawnej weryfikacji dokonanej za pomocą jednej z metod opisanych w swoim kodeksie. Miało więc podstawy, aby wystawić ten certyfikat.
Oprócz weryfikacji mailowej Comodo umożliwia także weryfikację domeny za pomocą umieszczenia odpowiedniego pliku na serwerze HTTP. Czy jeżeli atakujący, poprzez błąd w konfiguracji po stronie Microsoftu, uzyskałby dostęp do serwera live.fi (mógłby umieścić na nim dowolny plik) to czy także obwinialibyśmy Comodo o błędne wydanie?
Przypadek ten można porównać do sytuacji w której ktoś włamuje się na naszą skrzynkę pocztową, zmienia hasło powiedzmy do serwisu Allegro i dokonuje zakupów w naszym imieniu. Czy możemy mieć wtedy pretensje do Allegro, które otrzymało poprawne dane uwierzytelniające? Być może tutaj sytuacja jest trochę inna jednak można odnaleźć małą analogię do powyższego przykładu. Zawsze, gdy ktoś inny niż my sami ma dostęp do naszej poczty może wykorzystać to do wielu nadużyć. Kwestią pozostaje tylko to, gdzie to zrobi.
To prawda, że automatyzacja wydawania certyfikatów w tym przypadku okazała się zgubna. Być może, gdyby certyfikat nie został wydany przez automat (tak naprawdę to chyba nie wiadomo czy rzeczywiście tak było) to któryś z pracowników Comodo mógłby zorientować się, że domena live.fi należy do Microsoftu i zablokować wydanie certyfikatu. Nie zauważyłem, żeby Microsoft wcześniej korzystał z certyfikatów Comodo, więc tym bardziej w Comodo powinna zapalić się czerwona lampka, że nagle do ich systemu trafia żądanie wydania certyfikatu na domenę należącą do Microsoftu (tak duże firmy z reguły mają swoich „ulubionych” wystawców, których nie zmieniają co chwila). Prawdopodobny automat nie dał szans na reakcję…
CA może też weryfikować popularność danej domeny i blokować automatyczne wydawanie certyfikatów dla tych najpopularniejszych. Problemem w tym przypadku jest jednak jest to, że o ile usługa Live i domena live.com jest w czołówce najpopularniejszych domena na świecie to już jej fiński odpowiednik niekoniecznie.
Być może sytuacja ta spowoduje rozpoczęcie szerszej dyskusji na temat tego czy obecne mechanizmy weryfikacyjne stosowane przez CAs są wystarczające. Wydaję mi się jednak, że przewidzenie każdego możliwego błędu w aplikacji, konfiguracji czy jakiegokolwiek innego niezależnego do CAs, który może doprowadzić do takich nadużyć, nie jest możliwe.