https://archive.mroczna-zaloga.org/ Paweł Goleń, blog - Zrzędzenie starego zgreda pl Serendipity - http://www.s9y.org/ Sat, 15 Mar 2025 22:14:03 GMT https://archive.mroczna-zaloga.org/templates/bulletproof/img/s9y_banner_small.png https://archive.mroczna-zaloga.org/ 100 21 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#c29927 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1256 nospam@example.com (Ja bym ) Ja bym dodał kwestie "co atakujący umie" :) co atakujący ma,może i umie :) Mon, 17 Nov 2014 19:11:33 +0100 https://archive.mroczna-zaloga.org/archives/1256-guid.html#c29927 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#c29924 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1256 nospam@example.com (Przemek Skowron) Możliwe, że nasze myśli nie mogą się spotkać z tym samym mianownikiem. Rozwiązaniem strategicznym może i jest idealny TIV, ale on nie istnieje, prawda? - jeśli masz przykłady idealnego tzn., że odnalazłeś odpowiedź na pytanie z Twojej prezentacji i bardzo chętnie się z nim zapoznam. Jeśli nie ma idealnej strategi - idealna to taka realizowalna, w krótkim czasie (zanim nam ukradną więcej niż klienci/firmy są w stanie przetrwać) i kosztowo efektywna ;-) działa się na poziomie działań taktycznych->operacyjnych. Czy inne rozwiązania są krótkotrwałe? - mam przykłady, że nie, mogą być skuteczne przez lata, trzeba je tylko rozwijać. Czy IPS raz skonfigurowany i zapomniany daje 100% jego możliwości? - nie i uważam, że w tym przypadku jest podobnie, a nawet tak samo. Podałem SELinuksa jako podobny przykład z innego świata, nie wiązałem go z malware - bankerami. Tue, 11 Nov 2014 14:46:31 +0100 https://archive.mroczna-zaloga.org/archives/1256-guid.html#c29924 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#c29909 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1256 nospam@example.com (Paweł Goleń) Chyba mówimy trochę o dwóch różnych rzeczach. Oczywiście można stosować "doraźne" rozwiązania, które mają przeciwdziałać aktualnym atakom. Ale te doraźne rozwiązania nie rozwiązują problemu. Dlatego będę się upierał, że rozwiązaniem strategicznym jest efektywny (i używalny) TIV. Nie znaczy to, że trzeba rezygnować z rozwiązań tymczasowych jeśli są efektywne/opłacalne. Trzeba tylko pamiętać, że są one krótkotrwałe. A jeśli chodzi o koszty rozwiązań - to jest to nie tylko koszt ich wprowadzenia, ale również choćby stopień niewygody dla użytkownika. I w tym przypadku ewentualne wyłączenie możliwości wklejania rachunku jest wysoko na skali upierdliwości. Z drugiej strony nie podoba mi się komunikat typu "rachunek został wklejony, sprawdź jego poprawność", bo wraz z pojawieniem się Banatrix stracił na aktualności (wyłączenie kopiowania numeru rachunku zresztą też). Lepsza byłaby instrukcja - "zawsze sprawdź numer rachunku w SMS". Jeśli chodzi o skuteczność ataków socjotechnicznych - trochę trudno z nimi walczyć technicznie, prawda? Inna sprawa, że mechanizmy bezpieczeństwa muszą być zrozumiałe i wygodne dla tych, którzy z nich korzystają. A nad pozostałymi kwestiami można dyskutować długo i namiętnie :) Przy czym SELinux to konkretna implementacja modelu MAC. Tak, można zrobić przy pomocy MAC dużo i jest to dobre rozwiązanie tak długo, jak przy jego pomocy próbujesz rozwiązać te problemy, do których został on stworzony. Tylko, że takiego SELinux nie ma dla Windows i niestety - malware na stacji może wszystko, nawet jeśli jest uruchomiony w kontekście zwykłego użytkownika, to może zrobić praktycznie wszystko z innymi procesami tego użytkownika (z dokładnością do tematu Integrity Levels, które są pewną namiastką MAC). Tue, 11 Nov 2014 11:48:50 +0100 https://archive.mroczna-zaloga.org/archives/1256-guid.html#c29909 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#c29880 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1256 nospam@example.com (Przemek Skowron) Do czasu kiedy ataki socjotechniczne będą skuteczne to kody autoryzacyjne nie są wg. mnie wystarczające - mówię o tych powszechnych i wygodnych rozwiązaniach. Może kiedyś będzie okazja do prezentacji jak w "nie idealny" sposób skutecznie rozwiązywać/oddalać niebezpieczeństwo związane z malware i dlaczego większość czeka na to "idealne" rozwiązanie, a do tego czasu wydaje się, że "jest OK - nie ma idealnego rozwiązania, więc cóż... malware na stacji może obejść wszystko". Jestem pod wielkim wrażeniem "bezradności/pasywności" bezpieczników w takich sytuacjach - chcą wszystko albo nic, pomijam sytuację kiedy chcą "certyfikat" lub "papier", który ma być ich tarczą ratunkową, że coś zrobili i to nie ich wina. Administrator (root - (e)uid-0) w Linuksie też może wszystko, a czy nie po to stosujemy nie idealne rozwiązania jak SELinux (choćby jego podsystem auditd), kontenery, etc. by zmniejszyć ryzyko? Pojawia się znana i powszechna podatność w SELinuksie to i zmienia się SELinuks. Bezpieczeństwo to proces...bla bla bla. :-) Moim zdaniem walka z malware to walka z ich ekosystemem, jeśli nie całym to jego fragmentami tam gdzie jest dźwignia do sukcesu - obrony środków klientów banków i gdzie sięgają "ręce". To wszystko wymaga zmiany myślenia, trzeba pozbyć się dogmatu: "na stacji malware może wszystko" - otóż może to co jest zaimplementowane i system na to pozwala. Czasem malware trzeba oszukać, a nie zablokować czy ograniczyć. Trzeba zmieniać taktykę na taką, której się nie spodziewają. Czy to są skuteczne metody? - TAK, pogadać możemy jak się spotkamy znów na mieście lub przy innej okazji, bloga pewnie czytają również ci "źli" ;-) Sun, 09 Nov 2014 20:35:38 +0100 https://archive.mroczna-zaloga.org/archives/1256-guid.html#c29880 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#c29876 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1256 nospam@example.com (Paweł Goleń) Ale doskonale zdajesz sobie sprawę, że jest to jedyny (potencjalnie) skuteczny sposób, prawda? :) Oczywiście możesz implementować różnego rodzaju "zabezpieczenia", ale dla atakującego dysponującego malware na stacji ofiary wszystkie te zabezpieczenia są możliwe do obejścia. To, co ewentualnie może Cię przez pewien czas bronić to ta stara zasada o uciekaniu przed niedźwiedziem - musisz biec szybciej, niż najwolniejsza osoba z grupy. Sun, 09 Nov 2014 20:17:40 +0100 https://archive.mroczna-zaloga.org/archives/1256-guid.html#c29876 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#c29872 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1256 nospam@example.com (Przemek Skowron) Hehe, część ludzi i tak przepisuje kody autoryzacyjne i nie zauważają co właściwie autoryzują. Wcześniej miałem na myśli to, że ci co wiedzą o tym, iż malware może w locie podmieniać numer rachunku beneficjenta, powinni się przed tym już zabezpieczyć - nie licząc tylko na to, że Klient zauważy w opisie kodu autoryzacyjnego, że ma podpisać nie tą transakcję/operację, którą chciał wykonać. Sun, 09 Nov 2014 15:10:30 +0100 https://archive.mroczna-zaloga.org/archives/1256-guid.html#c29872 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#c29871 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1256 nospam@example.com (Paweł Goleń) No: http://en.wikipedia.org/wiki/Transaction_verification :) Sun, 09 Nov 2014 14:25:34 +0100 https://archive.mroczna-zaloga.org/archives/1256-guid.html#c29871 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#c29865 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1256 nospam@example.com (Przemek Skowron) Moim zdaniem kwestia taktyki jaką obierzemy - znam przypadki kiedy krótkofalowo (choć na wiele miesięcy, czasem lat) można było obronić się przed malware wykorzystując mechanizmy, które miały znane i powszechne słabości, choć nigdy nie zaimplementowane z złośliwym oprogramowaniu. Co do skupiania się na "schowku" - pełna zgoda, ale przecież te inne miejsca, gdzie podmieniany jest przez malware numer rachunku to już wszyscy zabezpieczyli, right? ;-) Sun, 09 Nov 2014 13:43:37 +0100 https://archive.mroczna-zaloga.org/archives/1256-guid.html#c29865 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#c29857 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1256 nospam@example.com (Paweł Goleń) Z tym "może zrobić teraz" to bym uważał. Jednak jest mała różnica między tym, że istnieje techniczna możliwość zrobienia czegoś poprzez zaimplementowanie dodatkowej funkcji w malware, a nowym atakiem, który do powodzenia najpierw wymaga jakiejś nowej ciekawej słabości/podatności. Nie można się skupiać na "schowku" jeśli wiadomo, że możliwa (i czasami wykorzystywana) jest modyfikacja rachunku, który przez schowek nie przechodzi. Sun, 09 Nov 2014 11:15:58 +0100 https://archive.mroczna-zaloga.org/archives/1256-guid.html#c29857 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#c29854 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1256 nospam@example.com (Przemek Skowron) za mało miejsca w smsie - try again ;-) Fri, 07 Nov 2014 22:37:51 +0100 https://archive.mroczna-zaloga.org/archives/1256-guid.html#c29854 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#c29843 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1256 nospam@example.com () Wystarczy w SMS-ie weryfikującym transakcję umieścić info, że numeru rachunku nie ma na liście rachunków używanych. Fri, 07 Nov 2014 21:37:33 +0100 https://archive.mroczna-zaloga.org/archives/1256-guid.html#c29843 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#c29828 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1256 nospam@example.com (Przemek Skowron) Banatrix podmienia numer rachunku bezmyślnie tam gdzie go znajdzie i czasem na tyle bez sensu, że nie udaje mu się podmienić tak by pozwolić zrealizować przelew fraudowy lub wręcz podpowiada użytkownikowi, że coś jest nie tak z jego widokiem bankowości. Pozwolić kopiować numer rachunku można, tylko trzeba to zrobić z głową - np. tak by bezwzględnie uruchomić weryfikację choćby części numeru przez Klienta + suma kontrolna numerów rachunków (przynajmniej w przelewach krajowych) rozwiąże problem w znakomitej większości przypadków banaptera. Podchodząc do elementów: co atakujący może i co ma - ma to moim zdaniem sens jeśli opisując "co może" wskazujemy co "może zrobić" dzisiaj, przy tym co już widujemy. Podstawą w planowaniu defensywnych elementów bezpieczeństwa jest przewidywanie, jak można złamać nasze zabezpieczenie i jakie warunki trzeba spełnić by to zrobić. Widząc możliwe rozwiązania na rynku oraz te zrobione w wew. fabrykach jestem przekonany, że można obejść każde ze stosowanych metod obrony z tym, że nie wszystkie "teraz", bo nie został ten atak jeszcze zaimplementowany (czyt. ujawniony) LUB nie jest powszechny. Fri, 07 Nov 2014 17:57:19 +0100 https://archive.mroczna-zaloga.org/archives/1256-guid.html#c29828 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#c29818 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1256 nospam@example.com (Paweł Goleń) W tym przypadku schowek nie jest wykorzystywany, więc to, że ludzie kopiują numery nie ma żadnego znaczenia. Co do podmieniania numeru rachunku "bez zastanowienia się czym on jest" - to akurat mam tu pewną wątpliwość. Przypominam, że przelew zawiera informację o koncie źródłowym i docelowym. Rachunek źródłowy w różnych bankach jest prezentowany różnie (identyfikator, bezpośrednio numer). Podmienianie wszystkiego co wygląda na numer rachunku może spowodować, że przelew się nie wykona, bo numer rachunku źródłowego będzie nieprawidłowy. Akurat z tego, co widzę, w mBank nie ma tego "problemu", numer rachunku źródłowego nie jest tam podawany "wprost". Z drugiej strony jednak grzebanie bezpośrednio po pamięci i podmiana "jak leci" nie jest bardzo uniwersalna. Fri, 07 Nov 2014 06:46:09 +0100 https://archive.mroczna-zaloga.org/archives/1256-guid.html#c29818 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#c29808 https://archive.mroczna-zaloga.org/archives/1256-banatrix.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1256 nospam@example.com (Marcin Rybak) to jest kwestia uniwersalności malware, podmienia 26 znakowe ciągi cyfr bez zastanowienia się czym jest dany ciąg. W przypadku podmiany w przeglądarce, czy podczas wysłania POST'a/GET'a, musiałby podmieniać dobre pole (aby np. nie podmienić rachunku źródłowego), a tak - jest po prostu łatwiej, ludzie kopiują numery kont, więc tę ludzką ułomność exploitują i eksploatują Fri, 07 Nov 2014 00:58:23 +0100 https://archive.mroczna-zaloga.org/archives/1256-guid.html#c29808