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:

7 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

Twój komentarz

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