30/8/2018
To jest historia z rodzaju “Mogło być znacznie gorzej”. Jeszcze w czerwcu odezwał się do nas Miłosz, który poinformował nas o możliwości… wgrania dowolnego skryptu na stronę Banku Spółdzielczego w Jarocinie. Dziura wynikała z tego, że moduł wtyczki do zarządzania plikami na serwerze był po prostu dostępny dla każdego.
Dziurawy CodeIgniter + przestarzałe wtyczki == co może pójść nie tak?
Do maila od Czytelnika, ze względu na sezon urlopowy, dotarliśmy w naszej redakcyjnej skrzynce dopiero po 2 tygodniach (teraz wiecie, dlaczego szukamy rąk do pracy ;). Ale dziura wciąż była niezałatana. Natychmiast chwyciliśmy więc za telefon. Odebrała pracownica, która od razu skierowała nas do właściwej osoby. Na szczęście w banku znano Niebezpiecznika, co skróciło tłumaczenia i sprawę potraktowano od razu poważnie.
Rozmawialiśmy z Szymonem Krauze, informatykiem, który 20 lipca obiecał szybko usunąć problem i przedstawić wyjaśnienia w późniejszym czasie. Te wyjaśnienia otrzymaliśmy miesiąc później, czyli dopiero 28 sierpnia, ale za to w formie przepięknego skanu.
Wypiszmy to, co najważniejsze:
- Podatność mogła istnieć od 14 maja do 20 lipca tego roku.
- Strona, na której wykryto problem, pełniła wyłącznie rolę informacyjną. Nie przechowywano na niej żadnych informacji wrażliwych, a dostęp do bankowości internetowej to już inny ośrodek przetwarzania.
- Nasze zgłoszenie zostało odpowiednio obsłużone. Zarejestrowano incydent bezpieczeństwa i podjęto niezbędne kroki.
- Dziura była obecna, kiedy serwer był poddawany “testom penetracyjnym” przez zewnętrzną firmę. Wygląda na to, że firma tego błędu nie zauważyła
Bank ma rację, pisząc że problem dotyczył strony informacyjnej a nie serwisu transakcyjnego. Ale warto w tym kontekście wspomnieć, że przejęcie kontroli nad stroną informacyjną banku też może być groźne. Przypomnijmy tu:
- atak na stronę Komisji Nadzoru Finansowego z lutego 2017 roku oraz tzw. technikę wodopoju. Dziurawa strona była w tamtym przypadku “tylko” narzędziem służącym do zainfekowania ludzi powiązanych z bankami. Następnie przestępcy zaatakowali banki, a z jednego z nich wykradli dane.
- atak na Plusbank, który również miał zacząć się od błędu “na stronie logowania” banku. Wstrzyknięte skrypty pozwalały podsłuchiwać wprowadzane dane i wyłudzać informacje dotyczące klientów. Skończyło się kradzieżą kilku milionów złotych.
Bank Spółdzielczy w Jarocinie na stronie informacyjnej “linkuje” do serwisu transakcyjnego, a więc ktoś kto na stronie informacyjnej może umieszczać złośliwe skrypty jest w stanie przejąć to kliknięcie ofiary i podstawić jej (w prawdziwej domenie banku!) fałszywy formularz logowania, z którego pozyska dane.
Warto wiec dbać o aktualizację frameworka. Zwłaszcza jeśli jest się bankiem. Nawet jak audyty i pentesty nie wykryją błędów.
Posłuchaj jednego z naszych 8 cyberwykładów. Wiedzę podajemy z humorem i w przystępny dla każdego pracownika sposób. Zdalnie lub u Ciebie w firmie. Kliknij tu i zobacz opisy wykładów!
Każdy powinien zobaczyć te webinary! Praktyczna wiedza i zrozumiały język. 6 topowych tematów — kliknij tutaj i zobacz szczegółowe opisy oraz darmowy webinar.
A gdzie brawa za sprawne załatanie portalu i przede wszystkim za piękne wyjaśnienie sprawy i nie zamiatanie ich pod dywan? Co jak co, ale podany bank może być pod tym kątem wzorem dla swoich dużo większych braci, którzy raczej niechętnie piszą tak obszerne wyjaśnienia i raczej zamiatają je pod dywan. Poprawcie mnie jeśli się mylę i jest jednak inaczej. BRAWA dla BS w Jarocinie!
Co Ty bredzisz? Jakiś tam portal można sobie łatać nawet łopatą, ale strona banku nawet jeżeli działa jako informacyjna ma działać należycie.
Z pisma nie wynika, że w czasie istnienia luki odbyły się “testy penetracyjne”, a jedynie “badanie podatności” (zapewne automat skanujący po różnych CVE)
“więc ktoś kto na stronie informacyjnej może umieszczać złośliwe skrypty jest w stanie przejąć to kliknięcie ofiary i podstawić jej (w prawdziwej domenie banku!) fałszywy formularz logowania, z którego pozyska dane.”
Jak możliwe jest wstawienie tego formularza w prawdziwej domenie?
jak wgrasz np JS, który się wykona po stronie klienta to możesz zablokować zdarzenie kliknięcia w link (return false; lub np. event.preventDefault() w jQuery czy inaczej). Następnie skrypt w domenie banku (tej informacyjnej, podatnej) wyświetla fałszywy formularz logowania do systemu transakcyjnego. Tak, to nie będzie domena systemu transakcyjnego ale całość wygląda wiarygodnie – prawda?
Najprostsze rozwiazanie to :
firma audytorska znalazla ale nie pozwolono jej tego pokazacwiec podala to inna metoda. Ktos moglby poleciec za zle napisanie strony, ktora nie byla kluczowa.
Porzadny haker jednak nie zostawia niedorobek i znalazl sposob by to upublicznic.
c.n.w.
Nie zgodzę się z Panem Krauze, ponieważ doskonale znam specyfikę pracy informatyka w Bankach Spółdzielczych, oraz samą budowę infrastruktury (zresztą w 95% banków spółdzielczych bardzo podobną). Prawdą jest, że portal informacyjny czyi główna strona www Banku znajduje się w innym centrum przetwarzania. W zasadzie BS nie trzymają stron WWW na swoich serwerach. Albo wykupują kompleksową usługę w Banku zrzeszającym albo jakiś hosting na którym stawiają oddzielnie zakupiony CMS. ZAGROŻENIE JEST KOLOSALNE, ponieważ WSZYSCY klienci banków spółdzielczych udają się na stronę główną banku, by tam kliknąć w odnośnik do bankowości elektronicznej, która mają w znakomitej większości na własnych serwerach w centrali banku (ew. na serwerach producenta systemu bankowości el. dla BS-ów a jest ich w Polsce trzech). Zatem zagrożenie było krytyczne bo mając kontrolę nad stroną główną można było kierować klientów na LEWE SERWERY
Strona tego banku wygląda jakby zatrzymała się w czasie w jakihś początkach internetu, takie banki jesli mają służyc dla prostych ludzi, to już lepiej żeby wgl nie udostepniały bankowości internetowej i nie tworzyly wgl zadnej tresci w internecie. Niech rozdają jakies ulotki po wiosce, bd na pewno bezpiecznie.