J

akiś czas temu Inti De Ceukelarie odkrył lukę pozwalającą na przeprowadzenie ataku na przestrzeń nazw w postaci adresów e-mail. Wykorzystanie tego błędu pozwala na uzyskanie dostępu do wewnętrznych systemów, mediów społecznościowych lub wewnętrznej komunikacji atakowanej firmy. Ze względu na skalę błąd nadal jest aktualny dla wielu firm, a w swej prostocie jest bardzo prosty do wykonania.

Bardzo wiele firm outsourcuje różnego rodzaju usługi do innych firm. Wiele z nich, jak Slack, Yammer, Facebook Workplace, Google Apps – wymaga od pracowników rejestrowania się za pomocą swojego adresu e-mail w domenie @firmy. Gdy pracownik kliknie link weryfikacyjny wysłany na wewnętrzny, @firmowy adres e-mail – może dołączyć do przestrzeni firmy w danej, zewnętrznej usłudze i uzyskać dostęp do wewnętrznej komunikacji i usług tej firmy.

Metoda #1 – system zgłaszania i śledzenia błędów

Załóżmy, że nasza firma posiada system zgłaszania i śledzenia błędów. Umożliwia on automatyczne tworzenie nowych zgłoszeń (ang. tickets) za pomocą wysyłania wiadomości e-mail na unikalny adres w tej samej domenie firmowej tylko z odpowiednim prefiksem. Na przykład wysłanie wiadomości e-mail pod adres: projekt2501+issuetracker@firma.corp spowoduje, że na stronie issuetracker.firma.corp zostanie założone nowe zgłoszenie błędu dla projektu 2501. Osoba, która wysyła taką wiadomość jest zarejestrowanym użytkownikiem systemu śledzenia błędów i ma dostęp do publikowanych przez siebie zleceń i odpowiedzi od zespołu wsparcia tej firmy. Widzimy dokąd to zmierza? Jeśli ta sama firma korzysta z jakieś usługi zewnętrznej, która wymaga rejestracji za pomocą @firmowego adresu e-mail – wystarczy teraz, że atakujący np. chcąc uzyskać dostęp do dedykowanej przestrzeni firmy komunikatora Slack poda przy rejestracji do usługi firma.slack.corp adres e-mail: projekt2501+issuetracker@firma.corp. Slack teraz automatycznie wyślę potwierdzenie rejestracji nowego użytkownika do systemu śledzenia błędów. Atakujący zobaczy tą wiadomość jako odpowiedź w jednym ze zleceń i będzie w stanie kliknąć link potwierdzający rejestrację i tym samym uzyska legalne konto dające mu dostęp do wewnętrznej komunikacji firmy za pomocą komunikatora Slack. Odzyskiwanie hasła i inne operacje będą posiadały identyczny mechanizm. System zgłaszania i śledzenia błędów został wykorzystany tutaj jako pośrednik publikujący całą komunikację z zewnętrzną usługą.

Metoda #2 – system obsługi klienta

Bardziej popularnymi od systemów śledzenia i zgłaszania błędów są systemy do obsługi klienta. Najczęściej są to Zendesk, Kayako, Freshdesk, WHMCS, czy inne specjalne dedykowane pod firmę. Bardzo wiele z nich umożliwia pojedyncze logowanie (ang. single sign-on – SSO), aby uwierzytelniony użytkownik został automatycznie zalogowany do działu pomocy technicznej, aby zapewnić bezproblemową obsługę jego zgłoszeń. Jednak bardzo wiele tego typu systemów jest skonfigurowana w ten sposób, że nie prosi o weryfikację podawanego adresu e-mail – oznacza to, że każdy może zarejestrować się z dowolnym adresem e-mail – nawet takim nie należącym do niego i bez problemu czytać wszystkie zgłoszenia utworzone przez ten adres e-mail. W dodatku komunikacja z takimi systemami najczęściej jest zautomatyzowana i umożliwia dalszą komunikację poprzez wysłanie wiadomości e-mail od użytkownika na adres support@firma.corp. Widzimy dokąd to zmierza? Mając świadomość, że np. komunikator Slack (lub inna dowolna usługa z której korzysta @firma) wysyła wiadomości weryfikujące adres e-mail nowego użytkownika z adresu feedback@slack.corp – wystarczy, że zarejestrujemy się z takim adresem np. w zendesk.firma.corp, a przy rejestracji nowego konta w Slacku podamy adres support@firma.corp. Slack wyślę wiadomość z weryfikacją konta do systemu zendesk.firma.corp, a że ten nie sprawdził naszego konta – my logując się do niego za pomocą feedback@slack.corp – będziemy mieli dostęp do treści wiadomości z weryfikacją konta. I ponownie możemy przejąć wewnętrzną komunikację @firmy. Wszystkie systemy, które nie weryfikują adresów e-mail w takich systemach są podatne na ten atak. Podatne są też systemy obsługi klienta, które wymagają weryfikacji adresu e-mail, ale już tego nie robią w procesie jego zmiany.

W dodatku bardzo wiele firm używa też tego samego adresu e-mail: support@firma.corp do obsługi innych serwisów, jak np. media społecznościowe. Oznacza to, że możemy tym samym sposobem wygenerować link do zmiany hasła dla konta support@firma.corp – rejestrując się w systemie obsługi klienta z adresem e-mail, z którego link do zmiany hasła wysyła Twitter lub Facebook. Możemy też spróbować zarejestrować się w takim systemie z adresem e-mail: no-replay@firma.corp i przechwycić token resetowania hasła dla skrzynki support@firma.corp – uzyskując dostęp do uprzywilejowanego konta i wszystkich informacji o klientach firmy.

Jak się bronić?

Luki te występują, jeśli zgłoszenia od użytkowników można tworzyć za pośrednictwem poczty e-mail i jeśli zgłoszenia te są dostępne dla użytkowników z niezweryfikowanym adresem e-mail. Dlatego:

• Powinniśmy upewnić się, że każda rejestracja konta i zmiany jego adresu e-mail powinna zostać zweryfikowana przez nasz system do obsługi zgłoszeń / błędów od użytkowników.
• Powinniśmy zadbać o rozdzielenie adresów e-mail używanych wewnątrz @firmy, a zewnętrznymi systemami. Na przykład jeśli nasza firma używa skrzynek @firma.corp w zewnętrznych usługach, gdzie krążą wewnętrzne informacje i dokumenty – to nie powinna ich używać w zewnętrznych systemach obsługujących użytkowników przez adresy e-mail. Systemy śledzenia błędów i obsługi klientów powinny być obsługiwane przez adresy e-mail w innych subdomenach lub domenach np. @wsparcie.firma.corp / @wsparcieklientafirmy.corp i być osobnymi skrzynkami (nie aliasami).
• Nie używać oficjalnych i tych samych skrzynek do różnych serwisów. Media społecznościowe i inne poboczne serwisy nie obsługujące całej naszej firmy powinny być powiązane z osobną skrzynką e-mail – nie związaną z żadną inną usługą / systemem w naszej firmie.
• Jeśli mamy możliwość wpływania na zewnętrzne firmy, które świadczą dla naszej firmy usługi – możemy poprosić je o implementację losowego adresu e-mail, z którego wysyłane są linki do weryfikacji / zmiany hasła dowolnego konta. Uniemożliwi to drugą metodę ataku, ponieważ agresor nie będzie w stanie przewidzieć jakiego adresu użyć przy rejestracji konta w systemie obsługi klientów (który i tak powinien zostać poddany weryfikacji). Jeśli nasza firma również świadczy taki mechanizm – też powinniśmy zaimplementować w nim losowość adresów.

Więcej informacji: How I hacked hundreds of companies through their helpdesk, Scary Tickerts