Połączeniami telefonicznymi do SQLi, czyli jak hakują prawdziwi mistrzowie

dodał 15 lutego 2015 o 20:04 w kategorii Błędy  z tagami:
Połączeniami telefonicznymi do SQLi, czyli jak hakują prawdziwi mistrzowie

Nasz Czytelnik podesłał nam opis własnoręcznie odkrytego błędu umożliwiającego zdalne wykonanie kodu w popularnym systemie bilingowym. Sposób przeprowadzenia ataku zrobił na nas ogromne wrażenie.

Autor  przeprowadził atak typu SQLi składając złośliwe zapytanie do bazy z kawałków zapisów połączeń telefonicznych. Oddajmy zatem głos Czytelnikowi, który wprowadzi Was w świat VoIP, by pokazać tajniki swojego odkrycia.

Wpis gościnny
 Autorem tekstu jest Michał ‚w4cky’ Błaszczak, zawodowo administrator systemów Linux oraz systemów telekomunikacyjnych, hobbystycznie security researcher.

www: blaszczakm.blogspot.com, mail: blaszczakm@gmail.com

Większości z nas ataki typu SQL injection i Remote Code Execution na aplikacje internetowe już się przejadły. Istnieje garstka programistów, która nadal popełnia te błędy, ale to już nie to samo co działo się kilka lat temu. Ja postanowiłem spojrzeć na SQL Injection z innej strony i odejść od hakowania interfejsów webowych aplikacji, a skupić się na całkowicie innym wektorze ataku.

Bezpieczeństwo systemów VoIP – wprowadzenie

W tym tekście chciałbym przedstawić Wam jak zhakować działające już w Internecie systemy wykorzystywane w telekomunikacji. Jako że od kilku lat całkowicie z przypadku pochłonęła mnie praca z wykorzystaniem technologii VoIP (ang. Voice Over Internet Protocol) postanowiłem sprawdzić jak wygląda temat bezpieczeństwa w tej branży. Wszyscy wokoło skupili się na możliwości podsłuchiwania rozmów i innych atakach w warstwie sieciowej oraz na zabezpieczaniu interfejsów webowych swoich systemów telekomunikacyjnych. Ja postanowiłem sprawdzić jak to wygląda na innym polu – ale o tym za moment.

Od jakiegoś czasu prywatnie prowadziłem projekt Hack VoIP, który miał dwa cele:

  • pozwolić mi poznać jak największą ilość systemów VoIP,
  • sprawdzić poziom ich bezpieczeństwa.

Projekt od samego początku zakładał, że każda znaleziona przeze mnie podatność zostanie zgłoszona do producenta systemu/oprogramowania, a ja po jakimś czasie opublikuję błąd lub gotowy exploit na blogu i w jednym z serwisów zajmujących się publikacją takich podatności. Jako że wszystko to robię samemu i całkowicie hobbystycznie to oczywiście publikacje nie pojawiają się tak często jak bym sobie tego życzył, a wynika to z tego że albo błąd nie jest jeszcze naprawiony (brak czasu producenta oprogramowania) albo ja nie mam czasu go opublikować lub nie mam czasu sprawdzić następnego oprogramowania.

Kilka publikacji już za mną, a ja podnosząc sobie poprzeczkę, doszedłem do bardzo popularnego systemu A2Billing. Wykorzystuje go wielu operatorów VoIP działających w Internecie oraz lokalnych dostawców Internetu i telefonii VoIP. System po krótkich badaniach okazał się dość bezpieczny (znalezione parę XSS’ow oraz CSRF) ale to zdarza się bardzo często i nie jest tym czego szukałem – oczywiście miałem świadomość tego, że ze względu na swoją popularność został już przebadany pod względem bezpieczeństwa.

Jako że sam A2Billing to głównie ‚logika’ systemu telekomunikacyjnego, która odpowiada za interfejs WWW, sprzedaż usług oraz obsługę klienta, to postanowiłem skupić się na styku ‚logiki z silnikiem’. Silnikiem w tym przypadku jest Asterisk – programowa centrala VoIP. Jako że osobom nie zajmującym się na co dzień tematem VoIP było by ciężko zrozumieć resztę tekstu, muszę zacząć od tego tym czym jest Asterisk i jak działa.

O Asterisku słów kilka

Asterisk to centrala VoIP która pozwala na wykonywanie połączeń telefonicznych, wysyłanie faksów, tworzenie menu głosowych (IVR) oraz wielu jeszcze innych rzeczy – wszystko zależy od naszej wyobraźni i umiejętności. Jego twórcą jest Mark Spencer i firma Digium, którzy na potrzeby programu stworzyli protokół IAX jako alternatywę dla skomplikowanego SIP. Asterisk jest także macierzystym środowiskiem protokołu wykrywania usług VoIP dostępnych na danym węźle o nazwie DUNDi, który ma być alternatywą dla ENUM w architekturze P2P (źródło: wikipedia.pl).

Asterisk również posiada kilka interfejsów służących do komunikacji. Jednym z nich jest AGI – dosyć dobre rozwiązanie, które pozwala na wpięcie go w dialplan, czyli moduł, który jest przetwarzany podczas połączenia telefonicznego i sterowania całym połączeniem właśnie z poziomu AGI. AGI to osobny program, pisany zazwyczaj w C, PHP lub Perlu przez autora wcześniej wspomnianej logiki, którą w tym przypadku jest A2Billing. To właśnie ten program obsłuży nam całą logikę połączenia i będzie kazał wykonać rożne instrukcje z połączeniem telefonicznym centrali Asterisk.

Jakie to będą instrukcje? W naszym przypadku i w dużym uproszczeniu wygląda to tak:

  1. połączenie telefoniczne trafia do Asteriska
  2. Asterisk zestawia to połączenie i kieruje je do wspomnianego wcześniej AGI
  3. AGI sprawdza kto dzwoni, gdzie się chce dodzwonić (czy obsługujemy numer docelowy, czy konto na numerze docelowym jest aktywnie, czy jest to zwykle konto telefoniczne czy może jakaś usługa telekomunikacyjna jak IVR lub poczta głosowa)
  4. w zależności od wyniku sprawdzania logiki następują inne procesy jak np. zestawienie połączenia głosowego.

Jak pewne już zauważyliście mamy tutaj ciekawy fragment – w pkt.3 AGI coś sprawdza, np. jaki numer dzwoni itp., czyli już mamy jakiś punkt zaczepienia. Jak się okazało podczas audyty bezpieczeństwa interfejsu webowego, programista dość skutecznie walczył z SQL Injection oraz innymi atakami, lecz w AGI to całkowicie pominął. Pewnie doszedł do wniosku, że numery telefonów niewiele mu mogą zrobić – otóż się mylił, ale jak pokazuje życie to nie tylko on tak pomyślał, w ten sposób myślą również inni projektanci systemów telekomunikacyjnych, ale o tym również później.

Aby jeszcze bardziej przybliżyć Wam problem będę musiał opisać jak wygląda połączenie telefoniczne do Asteriska – dla ułatwienia skupię się tutaj tylko na jednym protokole – protokole SIP.

Protokół SIP – SIP (ang. Session Initiation Protocol) – protokół inicjowania sesji, zaproponowany przez IETF standard dla zestawiania sesji pomiędzy jednym lub wieloma klientami. Jest obecnie dominującym protokołem sygnalizacyjnym dla Voice over IP). SIP ma w zamierzeniu dostarczać zestaw funkcji obsługi połączenia i innych cech obecnych w publicznej sieci telefonicznej (PSTN). Jako taki zawiera funkcje, które umożliwiają znane ze stacjonarnej telefonii operacje: wybieranie numeru, dzwonek w telefonie, sygnał zajętości itp. Jednakże ich implementacja i używana terminologia jest odmienna (źródło: wikipedia.pl)

Oznacza to, że SIP pozwala nam zainicjować połączenie telefoniczne oraz doprowadzić je do końca. Nie chcąc schodzić za bardzo z tematu artykułu (który de facto nie jest o protokole SIP) wspomnę tylko, że podczas wykonywania połączenia z telefonu do centrali jest przekazywanych kilka parametrów takich jak adres IP, numer telefonu oraz nagłówki.

Schemat komunikacji VoIP

Schemat komunikacji VoIP

Tak, tak jak już zapewne się domyślacie możemy wysłać co tylko chcemy więc dlaczego by wysyłać tylko numerki (lub literki)? Tym przykładem chcę Wam pokazać, że ludzie którzy tworzą systemy nie do końca zdają sobie sprawę jak działają protokoły, które będą wykorzystywać. Tutaj znowu zaufali protokołowi, który jak się okazuje wyprowadził ich na manowce bo pozwoli wysłać różne znaki specjalne.

SQLi w połączeniu

Szybko okazało się, że w AGI do którego przekazywany był numer telefonu jest podatność typu SQL injection. Problem tkwił w samej technice wykorzystania tego błędu ponieważ nie mogłem wysłać więcej niż 100 znaków, a i tak na początku wysyłanego łańcucha musiał znaleźć się numer telefonu. Kolejnym problem okazał się brak zwracanego wyniku, w takim przypadku nie pomaga nawet Blind SQL Injection. Dość długo myślałem jak wykorzystać ten błąd, ale w końcu się udało. Wybrałem się do Krakowa na spotkanie OWASP gdzie podczas rozmowy z Krzyśkiem Kotowiczem na temat SQL Injection zostałem naprowadzony na pomysł sposobu wykorzystania błędu. Chciałbym w tym miejscu serdecznie mu podziękować za ta rozmowę. Na czym polegał pomysł Krzyska? Na tym aby wysyłać do bazy krótkie zapytania SQL, które będą aktualizować znak po znaku – tak, to mogło się udać.

Na początku musiałem mieć coś co chcę aktualizować. Exploit który napisałem miał za zadanie:

  1. podczas pierwszej próby połączenia telefonicznego zrobić INSERT
  2. w następnych wykonywać tylko UPDATE

W ten sposób za pomocą kilkudziesięciu – kilkuset prób połączenia telefonicznego mógłbym do bazy danych dodać na przykład nowego administratora systemu z własnym hasłem. Oczywiście udało się to zrobić. Poniżej pierwszy raz prezentuję kod tego exploita:

Exploit korzysta z publicznie dostępnej klasy php-sip. Przedstawiony przeze mnie kod to nic innego jak dialer VoIP, który zamiast numeru wysyła przy pierwszej próbie połączenia INSERT – aby dodać użytkownika do bazy, a w następnych już tylko UPDATE skrótu hasła dla tego użytkownika. Poniżej przykład jak wygląda uruchomienie tego exploita na konsoli administracyjnej centrali Asterisk:

Nagrałem również film pokazujący użycie exploita.

Podsumowanie

Tym tekstem chciałem pokazać Wam, jak można zaatakować popularny system telekomunikacyjny używający trywialnego ataku SQL Injection w miejscu, w którym nikt się tego nie spodziewał. Dzięki temu zdobyłem dostęp administracyjny do całego systemu telekomunikacyjnego gdzie mogłem mieć dostęp do danych użytkowników w tym również do ich billingów, doładowań, zakładać nowych użytkowników itp. Mógłbym dzwonić gdzie chcę, zupełnie za darmo i z wysokim poziomem anonimowości (dane abonenta mogłem podać jakie tylko chciałem) – to dopiero phreaking naszej ery :)

Błąd oczywiście został zgłoszony producentowi, który do sprawy podszedł bardzo poważnie. Nie zdecydowałem się opublikować 0day-a ponieważ konsekwencje mogły być za duże. Dopiero w tym tekście pierwszy raz publikuję kod tego exploita. Zachęcam Was to spojrzenia szerzej na bezpieczeństwo w takich przypadkach.

Podziękowania

Podziękowania

Nawiązując do tytułu – teraz już wiecie jak za pomocą telefonu dobrać się do systemu operatora – jest tylko jeden problem, większość dialerów nie pozwala na przesyłanie znaków specjalnych – ale czy to naprawdę jest problemem? :) Tekst również pokazuje, że czasami warto porozmawiać o problemie z innymi osobami – tak jak w przypadku mojego wyjazdu na OWASP i rozmowy z Krzyśkiem Kotowiczem.

Mam nadzieję, że zachęciłem Was do badania różnych interfejsów, a nie tylko interfejsu webowego. Osoby, które chciałyby mi pomóc przy projekcie Hack VoIP serdecznie do tego zapraszam. Administratorów i twórców systemów telekomunikacyjnych chciałbym uczulić na tego typu problemy. Błędy te są bardzo chętnie wykorzystywane przez ludzi, którzy zajmują się włamywaniem do systemów operatorów VoIP i przekazują później ten ruch na numery premium, z czego czerpią korzyść finansową. W mojej opinii bywają one dużo cenniejsze na czarnym rynku od podatności w serwisach webowych gdzie zazwyczaj jedynym profitem są dane z baz danych. Tutaj osoba atakująca Wasz system zyskuje podwójnie – dane z systemu telekomunikacyjnego oraz możliwość wykonywania połączeń na koszt operatora pozostając przy tym anonimowa, co może prowadzić do różnych nadużyć takich jak zgłoszenia o podłożeniu bomb itp.