P

rzy okazji wygasania certyfikatu na stronie zacząłem się zastanawiać, czy skorzystać z Let’s Encrypt, czy może z CloudFlare? CF to serwis oferujący “darmową” ochronę webaplikacji, CDN oraz szyfrowanie SSL (jeśli używa się go poprawnie). Zastanawiało mnie ile klientów / domen korzysta z tego serwisu? Oto, co udało mi się ustalić.

1. Architektura rozwiązania:

Podczas komunikacji z dowolną stroną korzystającą z CF wysyłany jest nagłówek HTTP w postaci "Server: cloudflare-nginx". Niestety przy tym podejściu byśmy musieli poznać wszystkie lub większość domen w Internecie i odpytać ich port(y) do komunikacji HTTP(S) w celu poszukiwania tego nagłówka. Zbyt dużo czasu i zasobów. Skoro Cloudflare działa na zasadzie przepuszczania ruchu klientów przez swoje serwery – to one stanowią źródło wiedzy i prawdy. Większość odpowiedzi można znaleźć tutaj. Skoro firma obawia się, że zostanie wyczerpana pula adresów IPv4 dla certyfikatów SSL oznaczać to może, że klienci posiadający tą samą charakterystykę zostaną upakowani na wspólne adresy IP. Wiele certyfikatów na jednym adresie IP można umieścić za pomocą: SNI (ang. Server Name Indication) natomiast wiele domen w jednym certyfikacje za pomocą SAN (ang. Subject Alternative Names). CF tak właśnie rozwiązało problem ograniczonej adresacji, co potwierdza to sam support. Zacznijmy więc enumerację klientów. Wybieramy dowolny serwis, sprawdzamy jego adres IP, a następnie sieć do jakiej należy. Resztę informacji zbierze automat:

#!/bin/bash

for i in `prips 104.16.0.0/12`
do
  echo $i - `echo | timeout 2 openssl s_client -showcerts -connect $i:443 \
  -servername sni 2>/dev/null | openssl x509 -text | grep DNS` >> ssl_domains.log
  sleep 1
done

W tym momencie należy powrócić do słowa “charakterystyka”. Aby zamknąć wielu klientów w grupy należy ich najlepiej podzielić wedle planu, jaki wybrali / wykupili. Grupa 1 – klienci z darmowym planem, czyli korzystający z SNI. Grupa 2 – klienci, którzy wybrali wariant pro, czyli korzystający z SAN. Grupa 3 – klienci business oraz enterprise, czyli posiadający własne certyfikaty nie podpisane przez firmę Comodo. Oprócz tego w ramach każdej grupy klienci muszą być dodatkowo podzieleni według okresu czasu przez, jaki dany certyfikat będzie ważny. Zacznijmy od ostatniej grupy (3). W pliku ssl_domains.log będą to wszystkie wpisy posiadające format:

104.16.44.0 - DNS:*.domena.org, DNS:domena.org

Grupa pro (2) w polu SAN ma już rozpoznawalną domenę serwisu CF:

104.16.45.0 - DNS:sslXXXXXX.cloudflaressl.com, DNS:*.domena.com, DNS:domena.com

Grupa free (1), która korzysta z SNI również posiada specyficzną domenę CF:

104.16.46.0 - DNS:sniXXXXXX.cloudflaressl.com, DNS:*.domena.com, DNS:domena.com

Z SNI jest, jak z hostami wirtualnymi – powinny tylko zwracać treść, o którą rzeczywiście pyta klient inaczej “wykrzykujemy nazwiska sąsiadów” lub “niepotrzebnie łapiemy wszystkie rzucone kamienie”, które nie zawsze są adresowane w naszą stronę. Wprawione oko zauważy, że powyższy skrypt zawsze wysyła niepoprawną negocjację dla SNI. W przypadku adresów IP dla grupy 3 i 2 nagłówek SNI i tak jest ignorowany oraz zwracany jest certyfikat. Adresy, które rzeczywiście obsługują SNI powinny nie odpowiedzieć na takie żądanie lub powinny odpowiedzieć standardowym certyfikatem. Dla 142 adresów IP certyfikaty i tak zostały zwrócone mimo, że został podany niepoprawny adres w nagłówku:

# openssl s_client -servername sni -tlsextdebug -connect 104.16.47.0:443 2>/dev/null
CONNECTED(00000003)
TLS server extension "server name" (id=0), len=0
TLS server extension "renegotiation info" (id=65281), len=1
0001 - 
TLS server extension "EC point formats" (id=11), len=4
0000 - 03 00 01 02                                       ....
TLS server extension "session ticket" (id=35), len=0
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL Multi-Domain/CN=sniXXX.cloudflaressl.com

Jednak bardzo wiele adresów zwróciło błąd typu:

CONNECTED(00000003)
---
no peer certificate available
---

Czy oznacza to, że jednak dane dla tych adresów są nieosiągalne? Nie koniecznie. Wystarczy przesłać tylko odpowiednią domenę w SNI, aby dobrać się do sąsiadów. Poza tym adresy IP są tutaj tylko abstrakcją. Jeśli odpytamy dowolny adres, który wcześniej zwrócił nam certyfikaty dla grupy 3 o certyfikat domeny SNI – otrzymamy poprawną odpowiedź. Analogicznie jest z serwowaniem treści. Jeśli ustawimy sobie domenę “A” na adres IP domeny “B” statycznym wpisem w /etc/hosts lub na serwerze DNS – otrzymamy treść domeny “A”.

2. Obchodzenie architektury:

CF bazuje na przykryciu serwerami proxy chronionych stron. Wymaga również przekierowania obsługi domeny na własne serwery DNS. Jak uzyskać prawdziwy adres, z którego serwowana jest prawdziwa strona? Jeśli wcześniej strona działała na pierwotnym serwerze i dopiero później została przekierowana to możliwe, że zostawiła ślad w historii DNS. Sprawa się komplikuje, jeśli domena od początku zostaje zaparkowana na CloudFlare. Wtedy należy rozejrzeć się za jakimiś powiązanymi subdomenami, rekordami SPF itp. które możliwe, że będą skierowane na źródłowy serwer.

3. Podsumowanie:

Przedstawiona analiza nie ukazuje żadnej realnej podatności. Bardziej możemy ją zaliczyć do wywiadu gospodarczego, w którym możemy dopasować proporcję komercyjnych klientów (przychodów) do darmowych ze względu na ich “jednoznaczną” charakterystykę (+/- domeny, które nie zostały usunięte z panelu, a już nie wskazują na CF). Gdyby jednak okazało się, że istnieje osobna luka umożliwiająca zaatakowanie usługobiorców – to lista domen wyciągnięta poprzez informacje zostawiane w certyfikatach SSL jest bezcenna. Chociaż profil klienta daje jednoznaczną informację o ochronie jaką (nie)posiada.

Więcej informacji: Why You Shouldn’t Trust CloudFlare’s ‘Flexible SSL’ and How to Bypass It With BetterCap, RealIP of CloudFlare, Uncovering bad guys hiding behind CloudFlare , OpenSSL w linii poleceń