Systemy zbierające informacje o jeszcze niezałatanych błędach takie jak Bugzilla powinny zapewniać ich odpowiednią ochronę. Niestety nie zawsze tak jest, a czasem błędy w nich odkrywane są tak proste, że aż śmieszne.
Po niedawnym wycieku błędów typu 0day z repozytorioum informacji o błędach Mozilli badacze postanowili bliżej przyjrzeć się narzędziu Bugzilla, które służy do zarządzania informacjami o błędach. Znaleźli w nim niezwykle trywialny, lecz bardzo niebezpieczny błąd.
Email jak podstawa autoryzacji
Bugzilla ma ciekawy model autoryzacji dostępu. Może ona udostępniać konkretne zasoby na podstawie domeny, w której znajduje się adres email użytkownika. Ma to swoje częściowe uzasadnienie w małych organizacjach, gdzie sama przynależność do organizacji oznacza dostęp do pełnej informacji o błędach. Np. osoby posiadające skrzynki pocztowe w domenie mozilla.org mogą przeglądać większość zawartości repozytorium.
W procesie rejestracji nowego konta użytkownik najpierw podaje swój adres email. Bugzilla konta nie zakłada od razu, ponieważ aby zapewnić, że osoba podająca się za posiadacza danej skrzynki faktycznie nią dysponuje, wysyła na ten adres linka aktywującego konto i zawierającego specjalny token. Dopiero po kliknięciu w linka system tworzy konto użytkownika w oparciu o podany wcześniej adres email.
Taki długi adres
Testerzy firmy PerimeterX postanowili przyjrzeć się procesowi zakładania konta, słusznie identyfikując go jako kluczowy dla bezpieczeństwa danych. To, co odkryli, jest bardzo ciekawym przykładem możliwości wykorzystania prostych ograniczeń aplikacji do przeprowadzenia skutecznego ataku.
W momencie rejestracji nowego użytkownika jego adres email jest zapisywany przez aplikację w bazie danych w kolumnie o ograniczeniu rozmiaru zapisywanego ciągu do 255 bajtów. Co zatem stanie się, gdy użyjemy adresu dłuższego? Baza odpowiednio go przytnie do 255. Jaki będzie skutek dla aplikacji?
Jeśli podamy w formularzu rejestracji adres email w formie
aaa[...]aaa@
mozilla.com
.naszadomena.pl
gdzie ciąg do .com ma dokłądnie 255 znaków, to do bazy zostanie zapisywany adres aaa[…][email protected], dający automatycznie wysokie uprawnienia dla użytkownika. Z kolei email z prośbą o potwierdzenie zostanie wysłany na pełen adres podany w trakcie rejestracji, na serwer przez nas kontrolowany. W ten sposób badacze z PerimeterX założyli sobie konto na mozillowej Bugzilli. Dostalo ono następujące uprawnienia:
Mozilla została o błędzie poinformowana, Bugzilla została załatana, aktualizujcie jeśli korzystacie. I sprawdźcie, czy Wasze aplikacje nie umożliwiają podobnej sztuczki.
Komentarze
Silent errors FTW ;) Ostatnio miałem podobny problem, na szczęście warstwa odpowiadzialna za bazę danych rzucała wyjątki zamiast po cichu coś „naprawiać”.
Nie wyjaśniono skąd się biorą nadmiarowe uprawnienia przy omawianej długości adresu e-mail.
Wyjasniono, tylko nie zrozumiales.
Pytam ?
Chodzi o to, że bugzilla z automatu dawała uprawnienia osobom z mailem *@mozilla.com. Taki ficzer po prostu ma bugzilla i tak była ustawiona.
Koleś zarejestrował maila z innej domeny (dzięki czemu dostał kod aktywacyjny), ale baza przycięła go i zostawiła tylko początek, który był mailem z domeny mozilli. Więc koleś dostał uprawnienia…
@Tomasz wyjaśniono:
Po ucięciu podanego maila został o napisany w bazie jakoaaa[…][email protected], a tak jak wcześniej wspomniano wszystkie adresy z domeny mozilla.com mają z automatu najwyższe uprawnienia.
> sprawdźcie, czy Wasze aplikacje nie umożliwiają podobnej sztuczki.
Moje aplikacje nie dają z automatu uprawnień po domenie adresu e-mail, bo to kretyńskie ಠ_ಠ
Nie zrozumiałeś chyba zamysłu takiego rozwiązania… : )
Może Twoje aplikację są tworzone z zlepek kodu z stackoverflow ? :)
Rozwiązanie jest kretyńskie. Przecież emaile w domenie mozilla.com mają nie tylko developerzy ale też sekretarki, marketingowcy czy niebieskowłose feministki pełniące rolę specjalistek od równouprawnienia.
Na co takim osobom jakiekolwiek uprawnienia nadawne domyślnie? Żeby sobie dały wyphishingować hasło?
Może Mozilla.org to nienajlepszy przykład (fakt, że w tym przypadku takie podejście to kretynizm), ale łatwo mogę sobie wyobrazić organizacje/kilkuosobowe firemki, w których dostęp do informacji o błędach może spokojnie być nielimitowany dla wszystkich jej członków i nie ma potrzeby komplikowania tego bardziej.
Czy ja napisałem że to rozwiązanie w tym przypadku jest dobre ?
NIE, ale bywają przypadki w których to rozwiązanie jest dobre i pozwala na zmniejszenie personelu, który by dodawał pracownika do systemu, chyba żebyś napisał skrypt – dodajesz na stronie pracownika a w AD tworzone jest dla niego konto. Jednak jak wiesz w zastosowaniach korpo to odpada, dlatego to rozwiązanie jest dobre o ile zrobisz to dobrze, a nie tak jak tutaj. Dlatego jestem daleki od stwierdzenia że to jest kretyńskie rozwiązanie. Równie dobrze można powiedzieć – nie piszcie systemów CRM – ludzie robili wszystko od zawsze ręcznie a że trzeba zwiększać CKZ o kolejnego pracownika to już nie istotne:). Dlatego nie neguj całego zamysłu błędem, lub złego zastosowania rozwiązania do danej potrzeby : )
Z drugiej strony takie „tricki”, jak automatyczne udzielenie uprawnień wg domeny to coś, o czym łatwo zapomnieć/nie dogadać. Bo jestem sobie w stanie wyobrazić, że dwa lata po postawieniu takiej bugzilli ktoś w firmie zacznie przydzielać maile służbowe np. zewnętrznym zleceniobiorcom. I nie dogada się z drugim adminem, że tamten daje uprawnienia wg domeny.
Więc faktycznie jest to trochę ryzykowne…
Rozumiem zamysł takiego rozwiązania i uważam, że jest kretyński. Ale spoko, dzięki za ad personam, Onet z butów wyłazi.
Uprawnienia powinny być dawane przez usera z prawami zarządzania uprawnieniami dostępu innych userów w tej domenie, nie z automatu.
*mozilla.com ofkoz
Czy bazy domyślnie przycinają sobie dane do 255 znaków nie informując o tym aplikacji czy też trzeba się postarać i o to poprosić? Bo wg mnie główne zadanie bazy danych to upewnienie się, że WSZYSTKIE dane zostały poprawnie zapisanie i jeśli się to nie uda to powinno się to skończyć błędem a nie zapisaniem „uszkodzonego” wiersza.
Nie wiem jak inne, ale taki chociażby MySQL zwraca ostrzeżenie. Dobry ORM powinien pytać bazy o opis tabeli przed wsadzeniem do niej danych i sprawdzać już na tym etapie, czy wszystko gra.
Jesteś pewien? A w której wersji MySql? W 5.1 na pewno przycina bez ostrzeżenia (i potrafi więcej takich brzydkich numerów)
jak dobrze pamiętam, MSSQL w pewnych sytuacjach też obcinał, bez informowania. Niestety (a może na szczęście), dawno z nim nie pracowałem, więc nie jestem w stanie tego zweryfikować.
dokłądnie