Audyt bezpieczeństwa poczty ProtonMail

9 lipca, 2021

Niedawno na blogu ProtonMail, szwajcarskiego dostawcy prywatnej poczty, został udostępniony raport z testów penetracyjnych wykonanych przez polską firmę Securitum. To świetna okazja, aby zapoznać się z przykładowymi metodami ataków oraz przekonać się, czy bezpieczeństwo tej poczty rzeczywiście jest na wysokim poziomie.

Testy obejmowały trzy domeny:

  • protonmail.com (zarządzanie kontem)
  • protonmail.com (poczta)
  • protonmail.com (kalendarz)

Zastosowano podejścia „blackbox” i „whitebox”. Pierwsze z nich zakłada, że audytor nie ma bezpośredniej wiedzy o infrastrukturze, w sensie, że zlecający nie przekazał żadnych szczegółów. W tym przypadku samodzielnie należy przeprowadzić rekonesans. Whitebox z kolei to po prostu przeciwieństwo blackbox — pentester zna środowisko, otrzymał np. dostęp do kodów źródłowych czy pełnej dokumentacji.

Znaleziono jedną podatność o klasyfikacji medium i cztery o klasyfikacji low. Poza tym wypisano siedem czynników, które nie są podatnością, ale nie są też dobrymi praktykami.

Graficzne przedstawienie ilości znalezionych błędów w usłudze poczty ProtonMail.
Graficzne przedstawienie ilości znalezionych błędów w usłudze poczty ProtonMail.

Podatności w aplikacji webowej (blackbox)

 Najpoważniejsza podatność to reflected XSS. Jak opisano, polega ona na wysłaniu do ofiary „zaszytego” w pliku graficznym kodu HTML lub JavaScript. Po otwarciu wiadomości kod zostaje wykonany.

Testerzy dodali załącznik z rozszerzeniem GIF, który zawierał następujący kod:

GIF89a/*<svg/onload=alert(document.domain)>*//;

Po załadowaniu (onload) ma wyświetlić się komunikat (alert) wypisujący aktualną domenę (document.domain). Załącznik dodano jako obraz inline, czyli bezpośrednio widoczny w wiadomości. Następnie przechwycono żądanie wysyłane do serwera ProtonMail (np. w Burp Suite) i zmieniono typ MIME na text/html. „Ofiara” otrzymała wiadomość, ale myśląc, że jest pusta, postanowiła otworzyć „zdjęcie” w nowej karcie. W tym momencie wykonał się kod JS.

Popularny efekt wykonania ataku XSS.
Popularny efekt wykonania ataku XSS.

Okazuje się, że nie trzeba przechwytywać i modyfikować żądania, bo wystarczyło dodać (nawet jako zwykły załącznik) plik SVG zawierający:

				
					<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
 <polygon id="triangle" points="0,0 0,50 50,0" fill="#009900" stroke="#004400"/>
 <script type="text/javascript">
 alert(document.domain);
 </script>
</svg>%

				
			

Ofiara wybiera podgląd zdjęcia (to nowa funkcja w ProtonMail) i np. zachęcona otwarciem w nowej karcie otrzymuje wykonany kod.

W rekomendacjach zalecono utworzenie nowej domeny dedykowanej dla załączników oraz walidację typu MIME. Domeny do dziś nie utworzono, załączniki wciąż są serwowane z mail.protonmail.com (jako typ BLOB). Spróbowałem natomiast wysłać plik SVG i jego podgląd nie jest już możliwy.

svg onload protonmail
Zabezpieczenie polegające na konieczności pobrania pliku zamiast podglądu w przeglądarce.

Atak brute-force w ProtonMail

Kolejna podatność to możliwość przeprowadzenia ataku brute-force na użytkowników Yahoo w funkcji importu kontaktów. ProtonMail nie limituje ilości błędnych prób zalogowania, więc poprzez API można próbować właściwie do skutku. Trzeba po prostu manipulować wartością Code.

W ramach testów badacze założyli nowe konto na Yahoo z hasłem o długości szesnastu znaków składającego się wyłącznie z małych liter. Wystarczyło 350 requestów do API, hasło zostało złamane, a konto wciąż umożliwiało dostęp dla atakującego.

Dalszy błąd to pozwolenie na słabe hasła. Jedynym wymogiem jest 8 znaków. Spróbowałem założyć nowe konto o haśle 12345678. Udało się, więc błąd wciąż nie został wyeliminowany. Podobnie z ustawieniem nowego hasła. Również z powodzeniem zmieniłem je na 09876543.

brute force protonmail haslo
Stare hasło i ustawione nowe.

ProtonMail to specyficzna usługa i np. zmiana hasła powoduje nieodwracalne usunięcie wiadomości, co nieco zmniejsza wagę podatności. Natomiast hasło 12345678 można szybko złamać. Zalecono zwiększenie wymogów dotyczących długości i jakości hasła.

Następna podatność to wysyłanie nadmiarowych informacji w nagłówkach HTTP. Pentesterom udało się uzyskać informacje o używaniu Squid (caching proxy) i Sentry (monitoring aplikacji). Wystarczy usunąć te informacje z konfiguracji serwera.

Pozostałe błędy w ProtonMail (zwykłe zalecenia)

Spoofing nazwy nadawcy i odbiorcy. ProtonMail zapisuje co pewien czas szkice wiadomości. Ich fragment wygląda tak:

{"Message":{"ToList":[{"Name":"secaudit2","Address":"[email protected]","ContactID":"7XAh-IlodEfSOXGiTQ2LsA1L9F93oFy3nmTo6VyMa5OTJkqluHDpCBnZTqgQ49fOgt74-MvmuGEpBt0K6L2WzQ=="}],"CCList":[{"Name":"secaudit6","Address":"[email protected]","ContactID":"w3Gqwxi4k5f-dBBQAOWY4qKPCLACH0HbotPj_B9laC2hqSsQnWecsSdrPRsm9kR8WeM78xfbds4xFB30EE8zQ=="}],"BCCList":[],"Subject":"test","Attachments":[],"MIMEType":"text/html","RightToLeft":0,"Flags":0,"Sender":{"Name":"securityauditor1","Address":"[email protected]"}

Trzeba przechwycić takie żądanie i zmodyfikować odpowiednie wartości Name. To możliwości phishingu i „przekierowania” wiadomości ofiary. Zalecono wprowadzenie mechanizmu zapobiegającego spoofingowi.

Interakcja z zewnętrzną usługą. W przypadku błędu w działaniu, do Sentry zostaje wysłana informacja o tym. Można przechwycić żądanie i podmienić nazwy plików. Co więcej, kiedy w używanym oprogramowaniu zostanie wykryta podatność, można użyć tej metody do ataku. Zaleca się zablokowanie zewnętrznych adresów w Sentry i innym podobnym oprogramowaniu.

Niewłaściwa konfiguracja Content-Security Policy, który co prawda działa, ale pozwala wykonanie kodu JS. Definicja style-src zawiera flagę unsafe-inline, więc jeśli ktoś znajdzie podatność XSS w tym miejscu, prawdopodobnie wykorzysta ją z powodzeniem. Jeśli flaga unsafe-inline nie jest niezbędna, powinna zostać usunięta.

Aktywny nagłówek X-XSS-Protection. To „zabezpieczenie” nie jest już wspierane przez aktualne przeglądarki (zastąpione przez CSP). Jeśli klienci ProtonMail nie używają Internet Explorer, to zaleca się usunięcie X-XSS-Protection.

HTML Injection. Pierwszy znaleziony błąd w usłudze kalendarza. Podczas tworzenia wydarzenia wystarczy dodać wybrane znaczniki HTML, przechwycić żądanie, zmienić typ MIME na text/html, a przeglądarka je zinterpretuje. Aczkolwiek zdalna zawartość nie jest domyślnie automatycznie pobierana, więc atakujący nie pozna np. adresu IP ofiary. Zalecono użycie DOMPurify i walidację typu MIME.

Potencjalny XSS poprzez mechanizm drag&drop. Bardzo ciekawe, bo okazuje się, że edytor WYSIWYG używany przez ProtonMail zapewnia ochronę przez XSS w wyniku copy&paste, ale już nie w wyniku drag&drop. Pomimo tego realny atak nie jest możliwy, bo działa Content-Security Policy.

Podatności w kodzie źródłowym (whitebox)

Stare wersje bibliotek NPM. Można powiedzieć, że to branżowy standard. Pomimo braku skutecznego ataku z ich wykorzystaniem w raporcie z pentestów powinna się znaleźć rekomendacja aktualizacji zależności. Tak jest również i tym razem.

Niebezpieczna implementacja wybranych funkcji JavaScript. W pliku urlify.ts użytym w Proton Calendar brakuje sanityzacji, co powoduje możliwość przeprawdzenia ataku XSS. Z kolei w plikach messageContent.ts i dom.ts wartości zmiennych są wstawiane bezpośrednio do drzewa DOM poprzez innerHTML

Pliki messageContent.ts i dom.ts zostały już usunięte z repozytorum na GitHub, natomiast urlify.ts wciąż jest dostępny (z ostatnimi zmianami z 18 lutego): https://github.com/ProtonMail/proton-calendar/blob/master/src/app/helpers/urlify.ts.

Nie znaleziono poważnych błędów oprócz pierwszej opisanej podatności. Sugeruje to, że ProtonMail rzeczywiście może być liderem branży pod względem bezpieczeństwa, a szczególnie prywatności.

PODZIEL SIĘ:

Czy ten artykuł był pomocny?

Kliknij na gwiazdkę, aby zagłosować!

Średnia ocena: 0 / 5. Liczba głosów: 0

Jak na razie nikt nie podzielił się opinią.

guest
0 komentarzy
Inline Feedbacks
View all comments

Wyrażam zgodę na przesłanie oferty drogą telefoniczną przez IT Partners security sp. z o.o. z siedzibą Katowicach ul.Padereskiego 35 na podany przeze mnie adres e-mail zgodnie z ustawą z dnia 10 maja 2018 roku o ochronie danych osobowych (Dz. Ustaw z 2018, poz. 1000) oraz zgodnie z Rozporządzeniem Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (RODO).

Wyrażam zgodę na przesłanie oferty drogą mailową przez IT Partners security sp. z o.o. z siedzibą Katowicach ul.Padereskiego 35 na podany przeze mnie adres e-mail zgodnie z ustawą z dnia 10 maja 2018 roku o ochronie danych osobowych (Dz. Ustaw z 2018, poz. 1000) oraz zgodnie z Rozporządzeniem Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (RODO).

[ninja_tables id=”27481″]