21:12
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.

Przeczytaj także:

8 komentarzy

Dodaj komentarz
  1. 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.

  2. 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)

  3. “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?

  4. 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.

  5. 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

  6. 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.

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.