4500 wycieków informacji z polskich banków, czyli o pewnym raporcie

W ostatnich dniach obserwowaliśmy, jak kolejna firma “security” chciała na białym rumaku wjechać na polski rynek i scenę ITSEC. A wyszło, jak wyszło – czyli nie na koniu, a osiołku, nie wjechała, a się wturlała i nie na białym, a… sami zobaczcie.

Choć to my zaczęliśmy dyskusję na temat owego raportu, to autorem poniższego wpisu jest Tomek Bukowski, który do dyskusji się włączył i został przez autorów de facto zaproszony do głębszej analizy. A musieli wiedzieć, że Tomka do głębszej analizy zapraszają tylko naprawdę odważni ludzie pewni swego. Jednak nie uprzedzajmy faktów. Głos ma Tomek.

Geneza artykułu

Ponieważ zostałem wywołany do tablicy, postanowiłem odnieść się do konkretnych punktów opublikowanego raportu.

Nie wykluczam, że wersja dystrybuowana do banków może zawierać więcej szczegółów, jeśli w ogóle ją wysłano, bo nie użyto tu czasownika dokonanego :-). Niemniej jednak publikowanie “czegoś” (bo to, co jest publicznie dostępne, ciężko nazwać inaczej niż zbiorem pie-chartów), co ma ewidentnie za zadanie wzbudzić zainteresowanie dzięki użyciu Wielkich Słów (marketing przez zamieszanie?!), a nie zawiera jakichkolwiek wartości merytorycznych – po prostu jest niesmaczne. Niestety takie “opracowania” czytane są później przez osoby nietechniczne lub średnio-techniczne, które na podstawie takich treści wyrabiają sobie (bardzo wypaczoną) opinię o rzeczywistości.

FUD na cashless.pl

Zaczęło się od dobrego clickbaitu po koniec września w serwisie cashless.pl: “Najbezpieczniejszą stronę wśród banków w Polsce ma…”. Dalej czytam “Wywodząca się z Kazachstanu firma WebTotem, której główna siedziba mieści się obecnie w Warszawie, przeanalizowała strony 33 działających w Polsce banków”. Który z bezpieczników nie kliknie? Przecież dobry raport bezpieczeństwa jest lepszy do poduszki niż “Applied Cryptography” Bruce’a Schneiera!

Po kliknięciu szybko przychodzi rozczarowanie. Absolutny brak konkretów, a raport będzie w przyszłym miesiącu. Wiemy tylko, że “Ogólny poziom bezpieczeństwa stron bankowych oceniono jednak jako przeciętny (61 proc.)”. Cokolwiek to znaczy i w jakichkolwiek jednostkach jest mierzone.

Jest. FUD continues!

Na początku października pojawił się raport! I oczywiście dalsze uprawianie clickbaitingu:

• Interia: “WebTotem: Polskie banki w sieci średnio bezpieczne”
• Antyweb: “WebTotem sprawdził zabezpieczenia stron banków w Polsce. Mamy pełen raport z audytu!”
• Puls Biznesu: “Banki podatne na ataki hakerskie”

I całe ITSEC community rzuciło się do lektury! Powyższych artykułów nie będę komentował. Raport można pobrać (po sprzedaniu swoich danych) pod adresem: https://wtotem.com/reports/banks/poland

Uwaga od autora artykułu

Starałem się w miarę konstruktywnie podejść do każdej części raportu. Dlatego tam, gdzie byłem w stanie, zwróciłem uwagę na to, czego brakuje, żeby taki raport miał więcej wartości merytorycznej (i czasami sensu).

WSTĘP

Do nie-audytu (bo tak sam WebTotem opisał dokument na Facebooku, vide screen powyżej) wybrano 33 banki – w teorii kryterium było fizyczne posiadanie serwerów w Polsce.

O ile obecność na liście podmiotów takich jak PKO BP, Millennium, Getin (i innych znanych banków) nikogo raczej nie dziwi, za to na pewno zastanawiać powinny poniższe pozycje:

• Pekao Bank Hipoteczny – czyżby nietrafiona próba znalezienia banku Pekao SA?
• Mazowiecki Bank Regionalny – jeśli internet nie kłamie, został ZLIKWIDOWANY w 2011 roku?!
• Bank Spółdzielczy w Brodnicy – a gdzie inne Banki Spółdzielcze? Co takiego wyjątkowego jest w Brodnicy? (gratuluję Brodnicy miejsca w zaszczytnym gronie).

Zastanawiające jest również, w jaki sposób dokonano oceny “fizycznego posiadania serwerów w Polsce”. Przykładowo “polska” domena HSBC (https://www.hsbc.pl/) przykryta jest przez Akamai, hsbc.pl rozwiązuje się na klasę IP Microsoft (Azure?), a rekordu MX nie ma (ale jest rekord DMARC :-).

Jak widać (na screenie powyżej) – według autorów dokument nie jest audytem. Z kolei na stronie 04/34 możemy przeczytać: “The audit was conducted in the first half of June 2020” – chyba jednak miał to być audyt?! Może ktoś zmienił zdanie, jak już plik znalazł się “w internecie”.

“During research, WebTotem AI specialists did not interfere in the operation of the bank’s Internet resources: for the checks, it was enough to send “light” HTTP and DNS requests and analyze the responses that came from the server. Thus, all the data was collected in the way a regular user visiting the resource could do it”

Super – ale nie ma czegoś takiego jak “light” request. Że bez wszystkich nagłówków? Z jednej lokalizacji i tylko jedna sztuka? Request to request. 

“…It includes an analysis of the use of approaches to make recommended settings for web servers and related components.”

“The main objective of this study is to assess the security level of publicly available banking resources (we are talking about the official website of the bank)…“

Chwalić należy podjęcie każdej inicjatywy mającej za zadanie podnieść świadomość (nie)bezpieczeństwa. Jak można wywnioskować z podkreślonych fragmentów, autorzy poddawać ocenie będą STRONY INTERNETOWE banków. Zobaczymy, jak będzie dalej.

”…in accordance with best practices (such as PCI DSS, GDPR, OWASP Top-10, OWASP Application Security Verification Standard).“

W dalszej części raportu nie ma absolutnie żadnych odniesień do konkretów z OWASP Top 10. Zauważono jedynie, że takie istnieją. Sam PCI DSS został wymieniony w raporcie RAZ (w powyższym zdaniu). Osobiście ciężko mi sobie wyobrazić (a miałem PCI DSS “w ręku”), jak można ten standard doszywać do automatycznego skanu stron/serwerów. Trochę pachnie to koniecznością wymienienia tzw. buzzwordów. 

“We have selected several control points that can be checked without interfering with the work of the bank’s web resource, thus eliminating any technical damage.”

Oby się okazało, że tak było! Przejdźmy do konkretów.

Metodyka oceniania

O ile informacja na temat wag poszczególnych testów składowych jest przejrzysta, a same wartości wag też jakoś specjalnie nie dziwią, o tyle w opisie możemy znaleźć parę ciekawostek:

• “The percentage score characterizes the number of undetected or discovered security errors” – jestem ciekaw, jak zliczano niewykryte problemy. 
• 10% oceny końcowej stanowi ocena… otwartych portów. Nie wiem, jak się mają otwarte porty do oceny serwisów/serwerów WWW. Ale może się nie znam…
• 15% oceny to… “Email security”. Nie wiem, jak ma się to do “web servers and related components”. Być może “Emacsem przez sendmail” weszło za bardzo?

To, czego absolutnie tutaj brakuje, to lista konkretnych witryn (jak się dalej okaże, także serwerów pocztowych ^_^), które były przedmiotem analizy, ponieważ banki (i nie tylko) często udostępniają usługi (bankowości  internetowej) na domenach (lub subdomenach) innych niż “strona informacyjna” – co ma sens z punktu widzenia separacji infrastruktury oraz stosowania polityk i mechanizmów bezpieczeństwa. Nie wiadomo więc, czy oceniane było bezpieczeństwo “strony głównej” czy też “bankowości”. 

“Software composition”, strona 11

Tutaj mamy znienacka informację, iż w tej sekcji ocenie poddawana była eksploatacja podatności webowych. Nie wiem, jak “u was”, ale tam gdzie mi przyszło pracować, nazywa się to testy penetracyjne. I aby zrobić to poprawnie, wymagana jest “ofensywna” interakcja z serwisem będącym przedmiotem analizy. 

“This section describes the results that could describe the risk of exploiting web vulnerabilities such as SQL Injection, Cross Site Scripting, Broken…”

Dalsza lektura rozdziału sugeruje, że badacze bazowali na dostępnych informacjach dotyczących wersji używanego oprogramowania (CMS?). Kto kiedykolwiek robił “nieuwierzytelnione” (bez bezpośredniego [whitebox] dostępu do usług)  skany bezpieczeństwa (bazujące na banerach itp.), które nie skończyły się długimi listami false-positive, niech szybko podniesie rękę i rzuci kamień. Dodatkowo należy brać pod uwagę, że systemy, na których bezpieczeństwie powinno nam (klientom) i im (bankom) zależeć najbardziej, to najczęściej nie jest CMS z półki, tylko własna lub pisana na zamówienie bankowość internetowa, a wyszukanie w nich podatności to nieco więcej niż wykonanie automatycznego skanu. 

Czego brakuje w tej sekcji? Konkretów. Dobrego opisu metodyki oceny, np.:

• Jakie strony były analizowane – informacyjna czy bankowości?
• Czy brano pod uwagę wersję wersję serwera WWW?
• Jak “głęboko” skanowano daną stronę?
• W jaki sposób uzyskano informację o wersji (nagłówki, metadane, fusy)?
• W ilu miejscach nie udało się ustalić wersji?
• Czy uwzględniono również wersje używanych bibliotek działających w przeglądarce po stronie użytkownika (js)?
• Czy automat (jak to wspomniano na początku) dobrze radzi sobie z głębokim skanem, tzn. “single page”, gdzie wszystko “robi się” po ajaxowych api? (CURL też potrafi wysłać “lekkie” żądanie HTTP (-:  )

Na koniec lekki FUD: “Vulnerability: using an outdated version of the software, which is highly likely no longer supported by the developer. The CMS or its components has not been updated.” – Niebo zwali się nam na głowy. Jeżeli oprogramowanie nie jest w najnowszej wersji – to już na pewno nie jest wspierane przez dewelopera. Nie oznacza to, że będę namawiał do ignorowania takich sytuacji – oznacza to, iż potrzebna jest tutaj klasyczna analiza ryzyka, która weźmie pod uwagę wsparcie (w tym “premium”, lub jego brak) oraz informacje dotyczące znanych podatnościach i ich publicznej dostępności.

Website performance, strona 12

Najstarsi górale nie byli mi w stanie powiedzieć, jak ma się czas ładowania strony (FCP, FID wyjaśnione tutaj: https://developers.google.com/speed/docs/insights/v5/about) do bezpieczeństwa. MOŻE jeszcze czas odpowiedzi serwera na pojedyncze żądanie HTTP jakoś dałoby się podciągnąć pod “dostępność”. Bardzo szybko również dostajemy kwiatek:“Testing of best performance practices is performed to analyze the site’s resistance to stress”. Jeżeli z założenia test był nieofensywny, to czy odporność na warunki skrajne (stress test) mierzono po… jednym requeście/jednym załadowaniu strony? Jeżeli nawet tak – to w jakich warunkach (dzień tygodnia, pora dnia)? To naprawdę nie ma sensu.

Tak – tego typu testy (testy obciążeniowe/testy skrajnych warunków) wykonuje się. I tak – mierzy się czasy odpowiedzi. Ba, nie tylko strony, ale całej infrastruktury. Ale nie w ten sposób.

Czego brakuje w tej sekcji? Jak wszędzie: konkretów, dobrego opisu metodyki oceny. Co to jest “High speed”?!

IP/Domain reputation, strona 13

Z ogólnym problemem poruszonym w tej sekcji ciężko się nie zgodzić – reputacja (obecność na różnego rodzaju czarnych listach)  “domeny” czy “adresu IP” jest istotnym składnikiem oceny stanu (nie tylko) bezpieczeństwa. Obecność na takiej liście w zasadniczej większości przypadków oznacza jakiegoś rodzaju problemy (nie tylko z bezpieczeństwem), np.: listy serwerów wysyłających spam, open-relay, DNS-reflectory itp. Natomiast (podobnie jak w innych sekcjach raportu) już na początek mamy dobrą tezę:

“A good reputation means that a web resource is secure, while but a domain is given “black list” status, antiviruses warn guests of possible security threats when they attempt to visit the resource”. Próbując to przełożyć na biznesowy język – jeżeli nasza  infrastruktura ma “dobrą reputację” (nie ma jej na czarnych listach itp.), to zasoby na stronie są bezpieczne. Hura.

Czego brakuje w tej sekcji? Jak wszędzie: konkretów, dobrego opisu metodyki oceny, np.:

• Jakie adresy (nazwy) domenowe brano pod uwagę?
• Jakie adresy IP brano pod uwagę?
• Czy sprawdzano całe klasy adresowe?
• Jak pozyskano klasy adresowe?
• Czy uwzględniono infrastrukturę współdzieloną, tzw. chmurę?
• Względem których źródeł sprawdzano reputację domeny (adresów IP?) i dlaczego akurat te źródła wybrano?

HTTP Security Headers and Content Security Policy Scoring, strony 14-15

Duży plus – tutaj mamy dość krótko i konkretnie wyjaśnione, co to są nagłówki bezpieczeństwa w HTTP. Zastanawiać się można na pewno, dlaczego do oceny brano pod uwagę (co prawda dobrze opisany) nagłówek X-XSS-Protection, skoro większość przeglądarek porzuciła dla niego wsparcie.

Również wymieniany nagłówek X-Frame-Options zastępowany jest odpowiednią dyrektywą w polityce CSP – ale nadal posiada on pełne wsparcie w przeglądarkach.

Czego brakuje w tej sekcji? Jak wszędzie: konkretów, dobrego opisu metodyki oceny, np.:

• Czy oceniana była zawartość nagłówków, czy tylko ich obecność?
• W przypadku oceny zawartości – jakie były wartości referencyjne i dlaczego?

Traffic encryption, strony 16-18

Ten rozdział – o dziwo – zaczyna się od bardzo konkretnej listy (wraz z opisem) wykonanych “testów”. Duży plus. To, czego na pewno brakuje:

• Jakie serwisy/domeny były poddawane ocenie?
• Czy w przypadku wielu witryn jednego podmiotu brano pod uwagę najgorszy wynik?
• Czy żeby być “na zielono”, trzeba zaliczyć wszystkie testy?
• Co z testem “SSL Rating”, który nie daje wartości binarnej?

Polemizować można również z wagą (a w zasadzie jej brakiem) wymienionych testów. Część wymienionych ataków pozwala np. jedynie zapoznać się z treścią zaszyfrowanej komunikacji. Przy ocenie bezpieczeństwa należy odpowiednio dobrać wagi do takich testów.  Przykład ataku POODLE: “If attackers successfully exploit this vulnerability, on average, they only need to make 256 SSL 3.0 requests to reveal one byte of encrypted messages” – pozwala on na zapoznanie się z JEDNYM bajtem szyfrogramu po wymianie 256 komunikatów SSL 3.0. Tak, jest to podatność (jak każda inna), ale nie bez powodu podatnościom przypisuje się wagi.

Information leak, strona 19

To jest bez wątpienia jeden z moich ulubionych rozdziałów. 61% badanych instytucji (a zgodnie z założeniami raczej ich stron – chyba że przedmiotem raportu nie są tylko strony/serwisy!)… no właśnie, nie wiadomo, co miało nie tak te 61%. Czy na ich stronie znaleziono wycieki danych!? Czy może gdzieś w internecie znaleziono wycieki ze strony instytucji? Gdzie szukać i czego? Całość kwituje enigmatyczne sformułowanie, iż podatnością (vulnerability) jest tutaj używanie przez pracowników służbowych maili w “różnych serwisach” (w oryginale: “various services”). To w połączeniu z faktem, iż pracownicy mają tendencje do re-używania tych samych haseł, ma prowadzić do… nieautoryzowanego dostępu do poczty i dokumentów. Muszę przyznać, że to jeden z większych skrótów myślowych, jaki widziałem. Fakt, można się spotkać (nie tylko w bankach) z procederem polegającym na używaniu służbowego adresu mailowego do rejestracji w celach “prywatnych”, np. w serwisach randkowych, aukcyjnych itp. Fakt, nie jest to dobra praktyka z perspektywy bezpieczeństwa, ale czy o to chodzi w tym rozdziale? Nie wiadomo. Wiadomo, że z jednego z banków wyciekło 2500 danych! (kilogramów – dopisek autora)

Czego tutaj brakuje: wszystkiego. 

• Nie wiadomo, co było oceniane.
• Jaki związek ma używanie służbowych maili z bezpieczeństwem strony danej organizacji? Zwykle “bardzo ciężko” jest odgadnąć konwencję nazewnictwa, która stoi za nadawaniem służbowych adresów e-mail, prawda? :-)
• Magicznie założono, że jeśli pracownik użyje takiego samego hasła (jak na przykład do Active Directory) w zewnętrznym serwisie, to można już hakować bank. Pominięto np. że w bankach standardem jest brak dostępu do poczty z internetu, 2FA itd.
• Jeśli nawet pominąć powyższy punkt – to jak było to oceniane? Jak/czy ktoś wyszukiwał fakt użycia adresu służbowego w “różnych serwisach” i co to za serwisy?!

Network Security (open ports), strona 20

W tym rozdziale w miarę wiadomo, co się działo. NMAP :-). Na tym zdaniu można chyba skończyć pozytywne opinie. Ponieważ nie wiadomo:

• Jakie adresy skanowano? (jak we wszystkich poprzednich rozdziałach)
• Jakie porty (może “top common”, bo tak nmap robi domyślnie)?
• Dlaczego (to zamysł autora recenzji) na adresie (IP – domysł autora), na którym świadczona jest usługa HTTP i HTTPS, nie mogą być otwarte inne porty? Szczególnie w czasach, kiedy pula adresów IPv4 już się dawno skończyła. Otwarte porty (inne niż 80 i 443) nie oznaczają przecież, że są one obsługiwane na tym samym serwerze (a raczej klastrze serwerów), co strona WWW.

Ale wiadomo, że 29 banków z listy ma “dobrze”.

Email security, strony 21-23

Jeden cytat wart miliona słów: “This check is to verify whether the web resource’s mail server is configured correctly to prevent these common threats”. A teraz pytanie – jak się ma usługa (obsługa) poczty elektronicznej do bezpieczeństwa strony web? Czyżby był to kolejny skrót myślowy, którego nie dane jest mi zrozumieć? Obawiam się, że jest to kolejne pytanie bez odpowiedzi…

Plus na pewno należy się tym razem za wymienienie, jakim testom poddawane były usługi poczty elektronicznej. Chociaż z wielu opisów testów absolutnie nie wynika, jakie były kryteria sukcesu.

Na koniec rozdziału – wisienka (do czego autorzy już nas przyzwyczaili): “Vulnerability: incorrect configuration of the browser’s post server”. Chyba najlepiej zacytować tutaj google-translate i tak to zostawić: “Luka: nieprawidłowa konfiguracja serwera pocztowego przeglądarki”.

Current state, strona 24

Kolejny rozdział – perełka. O ile już na wstępie podjęto próbę wylistowania, co składało się na ocenę:

• “Presence of malicious scripts on the website” – jak najbardziej logiczne i zrozumiałe.
• “The presence of a hidden network of cryptocurrency miners” – sytuacji nie ratuje nawet google-translate: “Obecność ukrytej sieci górników kryptowalut”. Ale dobrze oddaje sens tego punktu.
• “Check the speed of the website” – zaraz, zaraz… ale wcześniej był cały rozdział o tym.
• “Complaints from users about the presence of viruses on the site detected by their antivirus software” – brzmi logicznie, ale jak to można sprawdzić?!
• “Site’s presence on «black list» of search engine reputation databases” – to też już gdzieś widzieliśmy. Być może, jak się nie ma nic konkretnego do powiedzenia, należy się powtarzać.

Całe szczęście 100% banków zaliczyło ten test na zielono! (Ciekawe, jak się ma to do faktu, iż parę stron wcześniej tylko 33% było high speed).

Security.txt compliance, strona 25

Chyba jedyny rozdział, w którym wiadomo, o co chodzi. Masz plik security.txt albo nie. 100% ankietowanych go nie miało. 

GDPR compliance, strona 26

Nie znam się na GDPR, więc nie będę oceniał merytoryki z tym związanej. Jednak jak zwykle autorzy nie napisali, co było przedmiotem oceny w tym rozdziale – więc nie ma się do czego ustosunkować.

“Conclusions”

Skrócona wersja (inspirowana skrótami myślowymi popełnionymi przez autorów raportu): 

Nie jest dobrze – strony polskich banków mogą paść ofiarą hakerów, jeżeli ich mail serwery mają zamknięty port 25. Powyższe zdanie oddaje odczucia autora dotyczące całego raportu.

Na koniec mamy jeszcze ciekawą sekcję “Cases”, opisującą np. atak na polskie banki poprzez umieszczenie złośliwej treści na stronie internetowej regulatora. Co ciekawe – dla mnie to nowość – okazało się, że 20 (DWADZIEŚCIA) polskich banków ucierpiało z powodu dużej utraty danych w tym incydencie. Autorom chyba nawet przytaczanie faktów idzie słabo.

Podsumowanie

Szkoda czasu. Całość ma najprawdopodobniej wywołać zamieszanie, nie niosąc za tym merytorycznej treści. Miały być referencje do (naprawdę dobrych) standardów – PCI DSS czy OWASP. Były wykresy kołowe (3D). Szkoda, że również takie “raporty” mogą kreować rzeczywistość w oczach osób, które niekoniecznie posiadają techniczną wiedzę dotyczącą bezpieczeństwa teleinformatycznego.

W artykule celowo nie użyto słowa cyber.