12.10.2020 | 12:06

Wpis Gościnny

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:

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.

Powrót

Komentarze

  • 2020.10.12 13:04 Marek

    Adamie, nie znasz się. Raport wygenerowała AI, on MUSI być prawdziwy :)

    Odpowiedz
  • 2020.10.12 13:30 Cośtam

    Zespół studentów od bezpieczeństwa próbuje funkcjonować w czasach nieludzkiego kapitalizmu a wy tak zaraz pała na początek

    Odpowiedz
  • 2020.10.12 16:05 Marek

    Poczułem się jakbym obserwował przepychankę dzieci w piaskownicy. Jakaś no-name firma wjeżdża z jakimś bieda raportem jakich w sieci wiele i ktoś się przejął na tyle żeby wdawać się z nimi w polemikę. A że inne serwisy przedrukowały to jako prawdę objawioną? Co chwila tak robią. Jak chcecie porządny tekst napisać to podejmijcie się przeanalizowania artykułów na temat security z ostatniego roku na takim przykładowo Antywebie i policzcie stosunek prawdy do bzdur. Taka high-levelowa analiza mogłaby pokazać problem jaki mają media z pisaniem o bezpieczeństwie.

    Odpowiedz
    • 2020.10.13 07:45 asdsad

      +1

      Odpowiedz
    • 2020.11.12 13:10 R.

      Zasada jest prosta: gdyby raport byl zupelnie z czapy, nikt by na niego nie zworocil uwagi, jednak dziwnym trafem natychmiast zaczeto wytaczac ciezkie dziala. Interesujace, prawda?

      Odpowiedz
  • 2020.10.12 16:38 Bezpiecznik

    Tomku BRAWO!!! Trzeba to tępić.

    Odpowiedz
  • 2020.10.12 16:51 Bezpiecznik

    Na ich stronie jest też raport Kazachskich banków https://wtotem.com/files/reports/kz_banks2020.pdf

    Ciekawe czy siedzibe firmy zmienili po publikacji tamtego raportu ;)

    Odpowiedz
  • 2020.10.12 17:16 J

    Wygląda to tak jakby ktoś zapuścił na „stronach banków” kilka narzędzi, nie potrafiąc jednocześnie wyciągnąć z tego żadnych bardziej sensownych wniosków. Przyjmowane wnioski wyglądają na „z kapelusza”, co tam autorom przyszło do głowy. Przypuszczam że w przypadku NMAP’a pewnie było coś w stylu: więcej otwartych portów=mniejszy score, niezależnie od rozmiarów banku i wystawianych usług.

    Nie zdziwiłoby mnie też to, gdyby raport „pełny” przesłany do banków zawierał zwyczajnie surowe wyjście z użytych narzędzi.

    Podziwiam Tomka za to, że postawił sobie za cel skomentowanie wszystkich punktów tego tekstu.

    Odpowiedz
    • 2020.10.14 10:02 Antoś

      No ale przecież tak wygląda 95% rynku i praktyk security u nas- dokładnie jak ten raport. Przykłady? Będąc w jednej firmie router odciął nas od sieci bo używaliśmy tor browsera, a reguły routera zakładają że tora używają tylko przestępcy.
      Inny przykład: blokowanie dostępu do aplikacji finansowych na rootowanych telefonach. Bo… no właśnie bo tak.
      Dzięki temu że prezes kupił narzędzia security 3 renomowanych firm jesteśmy już bezpieczni na 300%. Narzędzia schowaliśmy do szafy i możemy je pokazać w razie audytu, a jak będzie trzeba to zatrudnimy gościa który rozumie co jest w raporcie napisane, może nawet wyjście z NMAPa ogarnie.

      Odpowiedz
  • 2020.10.12 17:33 C. Bolek

    „Bank Spółdzielczy w Brodnicy – a gdzie inne Banki Spółdzielcze?”
    – Może to, że to najstarszy BS w Polsce. Ale poza tym nie sądzę, żeby miał swoje i osobno zarządzane servery.
    ..
    „Co takiego wyjątkowego jest w Brodnicy?”
    – To piękne miasto jest :-)

    Odpowiedz
  • 2020.10.12 18:00 C. Bolek

    „Podsumowanie
    Szkoda czasu. Całość ma najprawdopodobniej wywołać zamieszanie, nie niosąc za tym merytorycznej treści.”
    – Nie, całość miała wywołać lawinę zleceń z banków na likwidację tych wszystkich 'strasznych problemów z bezpieczeństwem’.

    Odpowiedz
  • 2020.10.12 19:45 Vegeta_Ssj

    https://api-1.2ke2xgwx4.wtotem.com/
    https://api-2.2ke2xgwx4.wtotem.com/

    To teraz bankiery powinni ich potestować xD Etycznie.

    Odpowiedz
  • 2020.10.12 19:46 Vegeta_Ssj

    https://files.2ke2xgwx4.wtotem.com/

    To też wygląda interesująco.

    Odpowiedz
  • 2020.10.13 00:00 Ban-kier

    Jeden audyt powie, że za mało otwartych portów. Drugi audyt, że za dużo otwartych portów. Pieniążki krążą, wszyscy są zadowoleni. Ekonomia bullshitu.

    Odpowiedz
    • 2020.10.13 20:01 Haha

      Ales pierdo… faktycznie mało otwartych portów jest problemem ale chyba natury egzystencjonalnej…kasa krąży dla odbiorców takich raportów chyba :-)

      Odpowiedz
  • 2020.10.13 02:14 Łukasz

    Powinniście odnieść się jeszcze do takich kwiatków jak to: https://wtotem.com/blog/nearly-3k-polish-websites-were-infected-by-malware/ co potem dalej bezmyślnie powielono jeszcze tutaj: http://di.com.pl/prawie-3-tys-zawirusowanych-domen-pl-namierzyl-startup-z-kazachstanu-64526. To jakiś dramat. Celowa dezinformacja czy jak?

    Odpowiedz
  • 2020.10.13 07:17 hashtak

    „Śpiewać każdy może,
    trochę lepiej, lub trochę gorzej,
    ale nie oto chodzi,
    jak co komu wychodzi.
    Czasami człowiek musi,
    inaczej się udusi”
    ?

    Odpowiedz
  • 2020.10.13 08:33 Oskar

    Robię takie testy w zasadzie za darmo. Wchodze na Qualys SSL labs, klikam „Test your server” i gotowe. Nie publikowałem audytu, bo chciałem jeszcze sprawdzić Mozilla Observatory.

    Odpowiedz
  • 2020.10.13 09:37 Obserwator

    Co prawda to prawda.

    Jak ostatnio zmieniałem bank, to sobie sprawdziłem najpierw dwie rzeczy:
    Czy domena banku jest podpisane przez DNSSEC?
    W przypadku banków ogólnopolskich ciężko było znaleźć domeny podpisane, koniec konców w Polsce znalazłem trzy banki z podpisanymi domenami.
    Kolega, z którym sprawę przedyskutowałem, poszukał w Niemczech,
    tam podpisaną przez DNSSEC domenę miał jeden bank.

    Drugi test dotyczył serwisu transakcyjnego, sprawdziłem, czy adresy IP serwisu transakcyjnego są podpisane przez RPKI.
    Wynik była pocieszny, nie znalazłem banku, który miałby adresy IP podpisane przez RPKI.

    Co nie znaczy, że jakaś banda ściemniaczy może pisać bzdurne raporty na temat np W3C czy nmapa, bo to akurat są bzdury totalne.
    Zwłaszcza, że np w netfilterze (iptables) można doinstalować xtables-addons i przekierować ruch na moduł DELUDE, wtedy dopiero będzie widać tysiące „otwartych portów”. xD

    Z innych obserwacji dotyczących mojego poprzedniego banku, strona serwisu transakcyjnego byłą tak przeładowana ofertami fantastycznych pożyczek i ubezpieczeń, że serwis transakcyjny przypominał sklep z zabawkami, wszystko tańczyło i śpiewało, było przez to praktycznie nieużywalne.
    Później się okazało, ze informatycy z tego banku w ogóle nie panują nad tym, co w tym serwisie transakcyjnym się dzieje.
    Na szczęście wyemigrowałem z tego banku przed jego największą katastrofą.

    Dlatego w bankach i w całym kraju z pewnością jest sporo do zrobienia pod względem bezpieczeństwa. co nie znaczy, że byle kretyn może udawać speca IT i pisać bzdurne „pro” raporty.

    Pozdro

    Odpowiedz
    • 2020.10.13 17:41 Kaz

      Vegeta, oczekujesz jakichś DNSSEC, RPKI (pierwszy raz widzę ten skrót), a większość polskiej e-bankowości możesz rozwalić þrzez zwykły MITM, bo żaden duży bank nie ma poprawnie zaimplementowanego HSTS.

      Odpowiedz
      • 2020.10.13 23:17 Laik

        Po co podpisywac ip?

        Odpowiedz
  • 2020.10.13 09:59 Czesiek

    Na końcu powinni dopisać zdanie „Istenieją liczne dowody że tragiczny poziom bezpieczeństwa banków to wina KNF, nasku i oprogramowania antywirusowego” to złagodziło by napięcie trochę

    Odpowiedz
  • 2020.10.13 11:45 m

    Wybaczcie, nie doczytałem artykułu. To jak artykuły o wirusie. Złota igła we wiadrze gów..

    Odpowiedz
  • 2020.10.13 13:36 Twój nick

    Szybkość otwierania strony ma zapewne świadczyć o odporności na DDoS.

    Odpowiedz
    • 2020.10.14 12:58 C. Bolek

      Ale nie na podstawie jednej transakcji!

      Odpowiedz
  • 2020.10.13 14:55 Chendryk Rzeromski

    Myhm… z ta sprzedaza danych to lekka przesada, poniewaz akceptuja jako podany do wysylki raportu adres z guerilla mail… co w sumie nie dziwi :)

    Odpowiedz
  • 2020.10.13 16:41 Observer

    I potem pojęcie audytu się dewaluuje przez takie kretyństwa, jak chcesz przeprowadzić rzetelny audyt – to klient marudzi że drogo – bo w sieci takie audyty panie widział i wie… no i taki audyt można kupić w każdym sklepie z audytami… i jak tu komuś rzetelnie zrobić audyt żeby coś z tego miał a nie bzdety…

    Odpowiedz
  • 2020.10.14 09:31 Vegeta_Ssj

    @Kaz: nie wiem do konca o czym mowisz, ale to mozesz rozwalic chyba uzytkownika bankowosci a nie bankowosc. Bo jak rozumiem chodzi ci o podsluchanie hasla zuczka co sie loguje? Nuda xD To jest passe. Facebook ma jakos to fajnie rozwiazane, bo nawet jak zaaplikujesz trucizne z jakims mitm to haslo jest przesylane zaszyfrowane. Request jest czytelny, ale pass nie jest plaintextem.

    Odpowiedz
    • 2020.10.14 15:04 niezarejestrowany

      Jak dobrze że nie projektują systemów zabezpieczeń przeciwko takim hakerom jak ty :)

      Odpowiedz
    • 2020.10.14 17:11 Stefan

      Wiesz, że mówią iż największą głupotą niejakiego szatana była próżność i że zazwyczaj ostatnim krokiem do prokuratury takich ludzi – których skąd innąd rozumiem – jest moment w którym zaczynają się udzielać w takich miejscach jak to.
      Zrób sobie przysługę bo staniesz się kolejnym przedmiotem prelekcji ludzi którzy za wiele nie mają do powiedzenia

      Odpowiedz
  • 2020.10.14 10:36 pnc

    Ci goście nie zauważyliby honeypota nawet gdyby podszedł u kopnął ich w krocze…

    Odpowiedz
  • 2020.10.14 18:41 Vegeta_Ssj

    „Jak dobrze że nie projektują systemów zabezpieczeń przeciwko takim hakerom jak ty :)”

    Ja nie jestem hakerem.

    Odpowiedz
  • 2020.10.26 15:06 Adam

    Dzisiaj ta sama firma robi akcję z PZU na „darmowy audyt bezpieczeństwa stron MSP”

    Odpowiedz
  • 2020.11.15 00:06 MamKonto

    Sacha Baron Cohen zbiera materiały do trzeciej części trylogii – nie poznaliście się na prowokacji?

    Odpowiedz

Zostaw odpowiedź

Jeśli chcesz zwrócić uwagę na literówkę lub inny błąd techniczny, zapraszamy do formularza kontaktowego. Reagujemy równie szybko.

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

Komentarze