Menu

Pomiędzy bitami

Techno, porno i duszno. Blog niezupełnie technologiczny.

Security

Jak zabezpieczyć domową sieć Wi-Fi?

rozieblox

Ciągle słychać o błędach w urządzeniach Wi-Fi, ale zwykły użytkownik nie ma wielkiego pola manewru - z routera Wi-Fi korzystać będzie, może co najwyżej liczyć na aktualizację oprogramowania przez producenta. Postanowiłem popełnić krótki praktyczny poradnik o tym, jak łatwo zabezpieczyć sieć Wi-Fi w domu czy SOHO. Zakładam, że konfigurowany będzie dowolny router Wi-Fi, nie określonego producenta. Nie będę podawał konkretnych zakładek/nazw, bo na różnych routerach różnie się opcje nazywają. Efektem jest przyzwoicie zabezpieczony sprzęt w domu, zmniejszający także szansę na wykorzystanie luk w oprogramowaniu - w większości przypadków konieczny jest dostęp do urządzania przez atakującego.

Podstawy

Wymienione poniżej czynności są absolutną podstawą, a efektem jest przyzwoicie zabezpieczona sieć.

  1. Zmiana hasła administracyjnego do urządzenia - warunek absolutnie konieczny. Bez tego możliwe są ataki na urządzenie przy pomocy dowolnej strony odwiedzanej z przeglądarki w sieci domowej.
  2. Wyłączenie zarządzania na porcie WAN - po co ułatwiać włamania z zewnątrz?
  3. Włączenie szyfrowania WPA2 lub WPA + AES - brak szyfrowania czy WEP nie są żadnym zabezpieczeniem, któryś z tych dwóch powinien być obecny nawet w starych sprzętach.
  4. Wyłączenie WPS - dodawanie urządzeń przy pomocy PINu może być kuszącym ułatwieniem, ale drastycznie ułatwia włamanie do sieci.
  5. Aktualizacja firmware do urządzenia do najnowszej wersji - to, że urządzenie jest nowe i prosto ze sklepu nie oznacza, że ma wgrane nowe oprogramowanie. Warto sprawdzić, czy producent nie wydał nowszej wersji oprogramowania, często poprawiane są różne błędy dotyczące stabilności i bezpieczeństwa.
  6. Ustawienie silnego hasła do Wi-Fi - patrz rozdział o hasłach.
  7. Okresowe przeglądy - patrz rozdział o przeglądach.

Dodatki

Poniższe czynności są opcjonalne, ich skuteczność jest niewielka, dyskusyjna, albo niekoniecznie są proste czy w ogóle możliwe do wykonania.

  1. Wyłączenie zarządzania routerem przez Wi-Fi - jeśli komputer jest podłączony po kablu, nie jest to żadne utrudnienie, w innym przypadku średnio wygodne, ale podnosi nieco bezpieczeństwo, zwłaszcza jeśli wpuszczamy do swojej sieci różne obce urządzenia po Wi-Fi. Zabezpiecza przed ominięciem uwierzytelniania w przypadku błędów oprogramowania.
  2. Zmniejszenie mocy Wi-Fi - brak zasięgu oznacza brak możliwości zaatakowania sieci bezprzewodowej. Ale napastnik może mieć porządną antenę kierunkową... Tak czy inaczej, nie ma sensu zakłócać urządzeń sąsiadom - jeśli mamy przyzwoity sygnał to zwiększanie mocy nie poprawi parametrów naszej sieci.
  3. Wydzielenie osobnej sieci dla gości - czy to poprzez wirtualny access point, obecny w niektórych sprzętach, czy poprzez osobne urządzenie.
  4. Ukrycie widoczności sieci - moim zdaniem złudne zabezpieczenie. Atakujący i tak jest w stanie taką sieć wykryć, a może to utrudniać dołączanie urządzeń czy wybór najlepszego kanału.
  5. Ograniczenie dostępu na podstawie MAC adresu - kolejne złudne zabezpieczenie, bo MAC adresy można zmieniać. Niemniej trochę pomaga, bo nie każdy umie zmienić i nie każdy sprzęt/sterownik pozwala w prosty sposób na zmianę MAC. Wiąże się z koniecznością każdorazowego logowania na router i dopisywania MAC przy wpuszczaniu nowego urządzenia do sieci, więc niezbyt wygodne.

Hasła

Hasła powinny być możliwie długie (myślę, że w dzisiejszych czasach 14-16 znaków to rozsądne minimum), zawierać cyfry, wielkie i małe litery. Z uwagi na wpisywanie hasła do Wi-Fi na urządzeniach mobilnych, warto wziąć pod uwagę wygodę wpisywania, zwłaszcza, jeśli wpisujemy je często, na różnych urządzeniach. Znaki specjalne zwiększają bezpieczeństwo haseł, ale uważam, że lepiej (wygodniej i porównywalnie pod względem bezpieczeństwa) mieć hasło o kilka znaków dłuższe, niż ze znakami specjalnymi.

Przeglądy okresowe

Raz na jakiś czas - czy to kwartał, czy co pół roku - warto sprawdzić czy jest dostępne nowsze oprogramowanie dla routera, zmienić hasło do Wi-Fi. Jeśli korzystamy z kontroli dostępu na poziomie MAC adresu - warto od razu zweryfikować listę i usunąć zbędne urządzenia.

Rozważania o blokowaniu ekranu

rozieblox

Przy okazji trwającej dramy dotyczącej xscreensavera w Debianie[1] przypomniał mi się pokrewny temat, o którym miałem robić wpis jakiś czas temu. Chodzi o blokadę dostępu do komputera, niezależnie od używanego systemu (Windows, Linux, OS X). Tradycyjnie jest to jakiegoś rodzaju wygaszacz ekranu, który po pierwsze blokuje możliwość odczytu danych z ekranu, po drugie, blokuje możliwość wprowadzania danych do uruchomionych programów. Do odblokowania zwykle konieczne jest podanie przez użytkownika hasła do systemu.

Rozwiązanie znane jest od dawna i wydawać by się mogło, że to wystarczy, ale czy tak jest faktycznie? Coraz więcej danych jest wprowadzanych i odbieranych z komputera nie tylko przy pomocy klawiatury i ekranu, ale także przy pomocy innych urządzeń. Programy do komunikacji VoIP, czy to Skype, czy aplikacja dostępna przez przeglądarkę typu appear.in czy hubl.in, po zablokowaniu ekranu nadal działają. Umożliwiają i odsłuchiwanie połączonych osób, i przekazują dane z otoczenia do nich. Zarówno za pośrednictwem audio, jak i video. Blokada ekranu co prawda wyłączy możliwość podglądu naszego rozmówcy, ale już nie wyłączy naszego webcama...

Jak na razie nie wiem nic o alternatywach dla wygaszaczy ekranu, które w momencie aktywacji blokowałyby nie tylko klawiaturę i ekran, ale dodatkowo wyłączały webcam(y) oraz wyciszały (mute) audio[2]. Pobieżne testy urządzeń z Androidem pokazują, że także na nich problem jest aktualny, przynajmniej w zakresie dźwięku. Warto po prostu pamiętać, że zablokowany komputer czy telefon w naszym otoczeniu wcale nie musi być tak do końca zablokowany...

[1] Skomentowałem u developera na blogu i wystarczy, wpisu nie będzie, sytuacja jest IMHO żenująca, więc szkoda klawiatury - jeśli ktoś ma cierpliwość, to wystarczy śledzić podlinkowane źródła.

[2] Jeśli istnieją systemy z takimi rozwiązaniami, albo samodzielne aplikacje, to chętnie poznam - u nikogo z nowszym Windowsem nie widziałem takiego rozwiązania.

Włamanie na serwery Minta

rozieblox

Jak donosi blog Minta, atakujący wykradli bazę danych (pełną - hash hasła, adres email, wiadomości prywatne) użytkowników forum, udało im się też podmienić linki na stronie kierując do wyposażonego w backdoora ISO.

Z racji zamykania Joggera trochę przeglądałem stare wpisy i widzę, że to nie pierwszy raz i nic nowego[1]. W roku 2008 doszło do włamania na serwery Fedory oraz Red Hata. Wtedy atakującym udało się nawet podpisać pakiety SSH w Red Hacie, co uważam za groźniejsze. Włamanie na serwery Linux Mint przypomina mi zatem póki co bardziej to, co spotkało choćby TAILS, czyli jedynie naruszenie dystrybucyjnego "frontendu", bez dostępu do kluczowych elementów dystrybucji.

Warto przypomnieć o sprawdzaniu podpisów pobranych ISO[2]. I nie chodzi mi o sumy kontrolne typu MD5 czy SHA1, które są zamieszczane na stronach WWW, a o podpisy GPG, które dobrze opisuje strona TAILS. Suma kontrolna weryfikuje jedynie brak przekłamań przy pobieraniu i zapisie. Pobieranie przy pomocy protokołu torrent również nie jest gwarancją autentyczności ISO! Pojawiają się informacje, że ISO Linuksa Mint pobrane przez torrent były bezpieczne, ale stało się tak tylko dlatego, że przypadku atakujący po prostu nie pomyśleli o publikacji zainfekowanej wersji ISO przez torrent i podmianie plików torrent na stronie.

[1] Widzę też, że kiedyś pisałem o takich drobiazgach na blogu, teraz bym pominął, gdybym nie znalazł tamtego wpisu... Czasy się zmieniają, ludzie się zmieniają nawet nar^Wblogi się zmieniają.

[2] Na temat kontenerów różnej maści tym razem będę litościwie milczał.

Automatyczne pobieranie kontaktu abuse dla domeny lub adresu IP

rozieblox

Zawsze miałem problem z szukaniem właściwego kontaktu abuse. No może problem to za dużo powiedziane, ale szukanie ręcznie, w hurtowych ilościach to nie jest nic ciekawego. Poza tym, jeśli chcemy zgłaszać automatycznie, to szukanie ręcznie odpada. A w danych whois były cuda, więc parsowanie tego byłoby wyzwaniem... Stosunkowo niedawno RIPE zrobiło jako taki porządek i pojawiły się pola abuse-c, ale już wcześniej znalazłem abusix i ich projekt Abuse Contact DB. Pozwala na wygodne odpytywanie o kontakty abuse przy pomocy DNS, więc szybko, prosto i wygodnie.

Trochę, żeby ułatwić życie kolegom, a trochę, żeby automatycznie zgłaszać nadużycia (np. próby włamań po SSH) ze swoich hostów, popełniłem funkcję w Perlu[1], która zwraca pierwszy email z listy, na podstawie ww. bazy. W międzyczasie zająłem się czym innym, znalazłem serwis, który rozwiązał temat automatycznego raportowania prób włamania. Temat więc trochę umarł. Przynajmniej do wczoraj/przedwczoraj, kiedy znalazłem ten wpis i dowiedziałem się, że najprawdopodobniej nikt nie powiadomił firm hostujących, plus zwykła ciekawość: a gdzie te skompromitowane hosty leżą? Z potrzeby chwili i własnej ciekawości skleciłem skrypt, który bierze domenę (czyli adres strony), sprawdza jego IP (dokładniej: rekord A) i ustala stosowny adres email do kontaktu z abuse.

Wynik działania dla domen .pl jest tu, a wynik działania dla całej listy tu. Skrypt jest zdecydowanie do poprawienia i rozwoju: w tej chwili nie zwraca nic przy braku kompletu danych, czyli brak obsługi błędów, jest wolny, bo działa sekwencyjnie, nie jest to czysty Perl, nie obsługuje IP (ani IPv6 czyli rekordów AAAA), grupowania domen/IP po kontakcie abuse (żeby nie słać wielu maili na ten sam adres) i wysyłki maili, ale leci na GitHuba. W ramach motywatora. ;-) Może kiedyś przyda się komuś, kto znajdzie jakiś malware...

TIL: istnieje oficjalne narzędzie w Pythonie, obsługujące bazę danych abuse; działa zarówno dla IPv4 jak i IPv6 (ale nie obsługuje domen). Generalnie robi to, co moja pierwotna funkcja w Perlu, tylko trochę lepiej. Mam wrażenie, że jak wtedy patrzyłem na tę stronę, to go nie było...

PS Z różnych źródeł wiem, że większe polskie hostingi są już powiadomione, nie ma potrzeby wysyłania maili. ;-) Warto natomiast zobaczyć, czy nie ma na liście strony własnej/znajomych - problem leży tak naprawdę po stronie użytkownika hostingu i  jego niezaktualizowanej aplikacji, więc tylko on może go tak naprawdę rozwiązać.

[1] Teraz widzę, że funkcja nie jest w czystym Perlu, tylko wywołuje zewnętrzny program host, poprawię wkrótce.

Obciach jest chwilowy, popularność jest wieczna

rozieblox

Pewna rodzina z Poznania (albo okolic) postanowiła wstawić sobie do niemal całego domu kamery, udostępnić w internecie i poszukać sponsorów. Albo rozgłosu. Rodzina składa się z dorosłych, którzy decydowali, oraz dzieci, które głosu zapewne nie miały, a nawet jeśli miały, to raczej nie rozumiały, co się dzieje naprawdę. Zresztą, wiele wskazuje na to, że nie do końca wiedzieli i rodzice...

O całej sprawie można poczytać nieco więcej u Lotty, mnie zdumiały niektóre aspekty. Po pierwsze, wygląda na to, że sąd w ekspresowym tempie nakazał rzecz dość dziwną, mianowicie wyłączenie kamer. I jest to podyktowane rzekomo prawem do prywatności dzieci. Zastanawiam się, gdzie tu miejsce na odwołanie, uprawomocnienie wyroku itp. Zastanawiam się też, gdzie leży granica. Bo jakoś usuwania np. zdjęć dzieci zamieszczonych przez rodziców w internecie nikt usuwać nie każe, a przecież też bez zgody dzieci są publikowane i niekoniecznie z "oficjalnych" okazji. Różnica czy obraz ruchomy czy statyczny? Cóż, obowiązku posiadania firan czy zasłon w oknach w domu też nie ma, ciekawe, czy rodzinami w domach bez zasłoniętych okien też się sąd interesuje?

 

Po drugie, dziwi mnie poruszenie wokół sprawy. Przecież to taki nieudolny, amatorski Big Brother, bez profesjonalnej obsługi, bez napięcia i bez reżyserowania czy selekcji. Podobnie jak w tym programie, uczestnicy sprzedają na chwilę swoją prywatność, w zamian otrzymując pieniądze i zyskując rozgłos. Stąd tytuł. Czy to się opłaca? Patrząc na stronę na Wikipedii poświęconą polskiej edycji Big Brothera - wszystko to już było, te same kontrowersje, te same motywacje. Nie było jedynie dzieci. Czy uczestnikom udało się zdobyć popularność? Z tego co kojarzę, to tak, bo do tej pory potrafi mi w TV mignąć o kimś, że brał udział. Sprawdziłem na ww. stronie - jest ich więcej, choć procentowo mniej, niż się spodziewałem. Cóż, gwarancji sukcesu nie ma.

Po trzecie, kamery (i mikrofony) są wszędzie i mało kto zdaje sobie sprawę z rozmiarów inwigilacji i możliwości podglądu/podsłuchu. Dobra okazja by przypomnieć grafikę z dawnego wpisu:

Cameras are recording your life 24 hours a day. Think about it.Zdjęcie grafiki na murze, IIRC Nowy Sącz.

Coraz więcej urządzeń, które posiadamy, jest wyposażonych w kamerę lub mikrofon oraz dostęp do sieci. Smartfon, tablet, telewizory, komputery... Wbudowany mikrofon posiada też na przykład Banana Pi (komputer, jakby nie patrzeć). Dedykowane kamery IP montowanych samodzielnie w domach czy teoretycznie zamknięte systemy monitoringu są oczywiste. Wszystkie te urządzenia mogą być (i są!) wykorzystywane do podglądu/podsłuchu przez producentów urządzeń i oprogramowania (Facebook!, Google!), służby (to jakby oczywiste i chyba w sumie najlepiej - przynajmniej teoretycznie - obwarowane prawnie)  i... włamywaczy komputerowych. Zresztą część kamer IP jest po prostu wystawiona do sieci, nawet włamywać się nie trzeba. Zabezpieczenia tego typu sprzętu wielowymiarowo leżą. Poczynając od udostępnienia w sieci przez samego użytkownika, przez niezmienione domyślne hasła[1] po... błędy producenta, typu niemożliwe do zmiany hasło "serwisowe".

 

Stawiam, że 99% (źródło: sufit, chodzi o skalę) ludzi nie zdaje sobie sprawy z tego, co naprawdę potrafi zrobić (i robi!) ich urządzenie. Czy różnica, czy obserwuje/podsłuchuje nas obsługa producenta, czy losowi ludzie jest naprawdę tak wielka? Naiwna wiara, że systemy monitoringu obsługują jacyś inni ludzie, niż losowi? Kto ma świadomość, że kamera w laptopie może pracować bez zapalonej diody? Kto zamontował fizyczne zabezpieczenie na kamerze w laptopie (polecam wpisać laptop camera cover w wyszukiwarkę)? Co z mikrofonem, który "odciąć" znacznie trudniej i który od zawsze jest aktywowany bez choćby próby fizycznego powiadamiania użytkownika?

Warto też pamiętać, że "publiczne" kamery bywają umieszczane w niezupełnie publicznych miejscach. Typu łazienki/toalety w urzędzie. A monitoring osiedlowy może umożliwiać pracownikom zaglądanie do mieszkań. O kamerach w przedszkolach itp. nie wspominam (a bywają, niekoniecznie zabezpieczone).

Ostatnia sprawa to konsekwencje. W znacznej mierze zgadzam się z twierdzeniem, że to społeczeństwo jest chore (nie owa rodzina). No bo czy ktoś normalny będzie gapił się w te kamery i robił "żarty", ocierające się o stalking? Nawiasem, stawiam, że nawet gdyby rodzina nie podała namiarów na siebie na stronie, to stalkerzy szybko by ją namierzyli... Faktem jest, że wygląda, że rodzice - przy swojej prymitywnej motywacji - niezupełnie zdają sobie sprawę co się dzieje i jakie są konsekwencje ich działań.

Na koniec: nie, nie popieram tego, co robi ta rodzina. Dziwi mnie jedynie, że ludzie, którzy to znaleźli nie wytłumaczyli im po prostu, czemu robią źle, tylko zaczęli zamawiać pizzę itp. I dziwi mnie pójście na noże, sąd, zamiast wizyty kogoś z instytucji zajmującej się prawami dzieci. Tym bardziej, że IHMO akurat prawnie nie sposób zabronić udostępniania takiego "odsłoniętego okna" w postaci kamer.

Natomiast jest to kolejna okazja do przypomnienia ludziom o wszechobecności kamer i mikrofonów. I o konieczności aktualizacji oprogramowania i zabezpieczenia dostępu, szczególnie do kamer IP.

[1] Insecam.org to serwis, który podaje namiary na kamery z niezmienionym hasłem, dostępne w sieci, z podziałem na kraje i kategorie. Aktualnie z Polski jest 95 kamer, w tym pokazujące obraz z wnętrz różnego rodzaju.

Spam o grze na giełdzie - wzorzec, sprawdź logi

rozieblox

Od pewnego czasu dostaję sporo spamu dotyczącego gry na giełdzie. Polsko brzmiące From, w treści zwykle niemieccy uczeni, gra na giełdzie, sztuczna inteligencja oraz całą dobę. W różnych wariantach. Do tego link do strony.

Z tego co mi się obiło o ekran, nie tylko ja to dostaję, a z tego co widzę po skrzynkach - filtry nadawców sobie nie radzą. Poza tym, myślałem, że się skończyło, ale widzę, że nadchodzi kolejna fala.

Zgłaszałem do SpamCopa (nie bez trudności) i akurat w tej kwestii dostałem kilka odpowiedzi z podziękowaniami za zwrócenie uwagi na problem, poza tym, jest charakterystyczny ciąg w URLu, więc wygląda na działanie jakiegoś niezbyt znanego robaka.

Mianowicie wszystkie(? albo prawie wszystkie) URLe, do których odsyłają maile ze spamem zawierają ciąg:

.php?b=2

Zapewne jeśli prowadzi serwer WWW, to warto grepnąć logi pod tym kątem. Kod 200 będzie oznaczał, że prawdopodobnie strona jest zainfekowana.

Zatem prośba do adminów WWW o sprawdzenie logów pod tym kątem, a do adminów poczty o próbę uwzględnienia tego w regułach antyspamowych.

PS Jakby przyjrzeć się bliżej, to pewnie nawet okaże się, że problem dotyczy tylko starej wersji któregoś CMSa, ale tego nie chce mi się już analizować.

O bezpieczeństwie po polsku

rozieblox

Jakieś dwa tygodnie temu serwis Sekurak.pl opublikował pierwszy numer swojego zina o bezpieczeństwie. Całego jeszcze nie przeczytałem, ale pierwsze wrażenie bardzo dobre. Przyda się chyba wszystkim mającym styczność z komputerami, poczynając od administratorów systemów, przez programistów, po frontendowców i ogólnie "webmasterów". Bezpiecznikom chyba też, bo chwalą.

Magazyn napisany jest profesjonalnie - czytelne grafiki, streszczenia artykułów, dobre formatowanie i przykłady. Widywałem gorsze artykuły w płatnych czasopismach. Sporo o podstawach, czyli czym jest CSRF, czym jest SQL injection, czym jest XSS. Zdecydowanie warto pobrać i przynajmniej rzucić okiem, tym bardziej, że po polsku i za darmo, poza tym, pisane w taki sposób, żeby czytający od razu się orientował, czy dany artykuł będzie interesujący.

Do pobrania Sekurak Offline w wersji pdf, mobi oraz epub.

Jakość niektórych narzędzi security Linuksie

rozieblox

Był sobie ciekawy wpis dotyczący siły haseł i narzędzi do automatycznego jej sprawdzania. Szykowałem się do dokładniejszej zabawy i testów, ale jakoś się rozeszło po kościach, więc krótko o tym, co zauważyłem.

Wnioski na temat jakości narzędzi do generowania haseł i automatycznego sprawdzania nie są zbyt optymistyczne. Narzędzia do haseł mają błędy. Smutne błędy. Spójrzmy na następujące wynik dotyczące haseł wygenerowanych przez pwgen i sprawdzanych cracklib-checki. Za każdym razem generowane było 100 tys. haseł, o zadanej długości (poczynając do 10 i kończąc na 20). Liczba podaje, ile nie było OK wg cracklib-check.

LANG=C pwgen -s -1 10 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK' 
79 LANG=C pwgen -s -1 11 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
122 LANG=C pwgen -s -1 12 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
16 LANG=C pwgen -s -1 13 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
27 LANG=C pwgen -s -1 15 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
59 LANG=C pwgen -s -1 16 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
98 LANG=C pwgen -s -1 17 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
141 LANG=C pwgen -s -1 18 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
215 LANG=C pwgen -s -1 19 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
275 LANG=C pwgen -s -1 20 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
373

Jak widać, ilość słabych haseł spada, osiągając minimum w okolicy dwunastoznakowych, by następnie systematycznie rosnąć. Rzut oka na generowane hasła i... wszystko jasne:

HiGFYedy6gHG: it is too simplistic/systematic
nowuTUtOon4W: it is too simplistic/systematic
O4rstUX43Bef: it is too simplistic/systematic
1mMTsIHZyHIH: it is too simplistic/systematic
SeVw3MnMnOpp: it is too simplistic/systematic

Domyślnie(?) cracklib-check uznaje powtórzenie znaków za oznakę słabego hasła. Kurtyna.

Kolejne narzędzie, które znam, lubię i którego używam często (zwykle modyfikując wynik, jednakowoż) to gpw. Okazuje się, że posiada ono brzydki błąd, który powoduje, że czasami hasło nim wygenerowane jest krótsze, niż planowaliśmy, tj. niż podane w stosownym parametrze. Przykład: 100 tys. haseł szesnastoznakowych (niby!):

gpw 100000 16 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -v ': OK' | grep -i short
aqs: it is WAY too short

I hasło typu aqs. Jest nawet zgłoszony błąd w Debianie w tej sprawie. Też mam mieszane uczucia co do poziomu istotności błędu, ale... sprawdzanie długości otrzymanego wyniku to przecież trywialna sprawa, więc jakie inne błędy może mieć soft?

Ogólnie: mam wrażenie, że nie warto zbytnio ufać gotowym narzędziom. Może nawet nie to, żeby od razu pisać coś własnego, ale warto sprawdzić gotowce (bezpieczne! wolnoźródłowe!), nim się z nich skorzysta.

Dziwne wpisy w auth.log, czyli coś nowego na SSH

rozieblox

Jedną z maszynek mam wystawioną do netu z SSH na standardowym, 22 porcie[1]. Głównie w celu zbierania śmieci (i zgłaszania ich do blocklist.de). Zerknąłem na /var/log/auth.log i zobaczyłem masę nietypowych wpisów typu:

Jan  8 19:41:28 xxx sshd[32002]: Connection closed by 195.130.253.159 [preauth]
Jan  8 19:46:52 xxx sshd[32298]: Connection closed by 195.130.253.159 [preauth]
Jan  8 19:52:16 xxx sshd[32645]: Connection closed by 195.130.253.159 [preauth]

Są to jedyne wpisy w logach dotyczące tych IP. IP jest stosunkowo niewiele, połączenia zwykle co kilka minut. Brak śladów po próbie logowania. Wydaje mi się, że wcześniej tego nie było, przynajmniej nie aż tyle. Logi mam od 7 grudnia, wygląda, że zjawisko zaczęło się w okolicy 11 grudnia, a apogeum miało miejsce na przełomie roku:

zegrep -h "Connection closed by .*preauth" /var/log/auth.log* | awk '{print $1" "$2}' | sort | uniq -c | sort -n
      1 Dec 11
      1 Dec 12
      1 Dec 21
      1 Dec 8
      2 Dec 18
      4 Dec 17
     10 Dec 26
     19 Dec 16
     43 Dec 14
     75 Dec 22
    150 Jan 4
    155 Jan 8
    159 Dec 24
    209 Dec 15
    214 Dec 27
    267 Jan 5
    303 Jan 7
    360 Dec 28
    381 Jan 3
    445 Dec 29
    446 Jan 6
    717 Dec 30
    905 Jan 2
   1041 Jan 1
   1132 Dec 31

Jeśli chodzi o rozkład IP, to na moim serwerze wygląda to następująco (tylko ponad 100 wystąpień prezentuję):

zegrep -h "Connection closed by .*preauth" /var/log/auth.log* | awk '{print $9}' | sort | uniq -c | sort -n | egrep "[0-9][0-9][0-9]
    113 128.199.252.25
    147 121.78.147.217
    159 195.154.226.100
    358 195.130.253.159
    416 118.98.43.33
    684 37.187.119.89
   1378 76.74.157.51
   1416 112.216.92.44
   1883 112.107.2.154

Kolejnych 13 IP ma powyżej 10 wystąpień.

Jeśli chodzi o kraje, to raczej malware'owy standard (dla >10 wystąpień):

zegrep -h "Connection closed by .*preauth" /var/log/auth.log* | awk '{print $9}' | sort | uniq -c | sort -n | egrep "[0-9][0-9] " | awk '{print $2}' | xargs -L1 geoiplookup | sort | uniq -c | sort -n
      1 GeoIP Country Edition: AR, Argentina
      1 GeoIP Country Edition: AT, Austria
      1 GeoIP Country Edition: GB, United Kingdom
      1 GeoIP Country Edition: ID, Indonesia
      1 GeoIP Country Edition: IT, Italy
      1 GeoIP Country Edition: NL, Netherlands
      1 GeoIP Country Edition: RU, Russian Federation
      2 GeoIP Country Edition: FR, France
      2 GeoIP Country Edition: IP Address not found
      3 GeoIP Country Edition: CN, China
      3 GeoIP Country Edition: KR, Korea, Republic of
      5 GeoIP Country Edition: US, United States

Ktoś się orientuje o co chodzi? Jakiś nowy atak? Błąd w skryptach od bruteforce w którymś botnecie?

UPDATE Dzięki pomocy ludzi z #z3s udało się ustalić, że tego typu wpisy w logach pojawią się, jeśli nawiąże się połączenie tylko w celu pobrania obsługiwanych sposobów szyfrowania (i rozłączy się po ich otrzymaniu). Nie tłumaczy to oczywiście, czemu połączenia się powtarzają. Padła sugestia, że może jakiś głupi bot wykłada się na nietypowej konfiguracji - host nie ma domyślnego konfiga SSH, tylko wdrożone zalecenia z bettercrypto.org (polecam, swoją drogą).

[1] Ponieważ było to pierwsze pytanie, jakie dostałem, to dopiszę: tak, celowo, tak nie mam tu innego portu/fail2ban/knockd, choć każda z tych metod pewnie eliminuje 99% skanów. Jestem świadomy możliwości nie oglądania tego typu rzeczy, ale tu chcę je widzieć.

Konsekwencje prawa nieuniknionych konsekwencji

rozieblox

Ponieważ rysiek nie daje możliwości komentowania u siebie (a szkoda), będzie krótki wpis. Ryśkowe prawo nieuniknionych konsekwencji mówi o tym, że:

Jeśli coś jest technicznie możliwe,
jest praktycznie nieuniknione.

Zupełnie się z tym zgadzam. Osobiście wyznaję dość podobną zasadę, którą można streścić

Każde zdarzenie o niezerowym prawdopodobieństwie zaistnienia prędzej czy później nastąpi.

Trochę fatalistyczne, fakt (szczególnie w kontekście kolizji ciał w przestrzeni kosmicznej o niepomijalnej masie), ale sprowadzając do komputerów i bezpieczeństwa: każda baza zostanie wykradziona, każde dane prywatne ujawnione, każde hasło zostanie złamane. Prędzej lub później.

W kontekście Diaspory, która jest przytoczona przez ryśka jako remedium na problemy dotyczące ochrony prywatności m.in. na Facebooku

Zwyczajnie nie da się wprowadzić reklam lub sprzedać danych prywatnych wszystkich użytkowników tej sieci jednocześnie. jest to technicznie niemożliwe.

oznacza to, że da się zdobyć dane wszystkich użytkowników tej sieci. Jak? Wystarczy błąd w aplikacji. Jak trafnie zauważa Wiktor:

One wszystkie ze sobą gadają i mają ten sam, możliwy do sprawdzenia kod.

Wystarczy klasyczny 0 day, i jeśli tylko komuś będzie zależało na tych prywatnych danych, to zdobędzie je. Oczywiście nie wszystkie, bo albo jakiś serwer będzie offline, albo będzie nietypowo skonfigurowany, albo zwyczajnie admin zdąży go załatać. Albo nie zdąży zaktualizować do podatnej wersji.

Fakt, że oprogramowanie jest open source nie eliminuje prawdopodobieństwa wystąpienia błędu. Wystarczy wspomnieć błąd z OpenSSL w Debianie. Zresztą, chyba wszyscy pamiętamy o tegorocznym Heartbleed...

Należałoby więc raczej mówić jedynie o zmniejszaniu prawdopodobieństwa zaistnienia zdarzenia, nie jego eliminacji. W tej chwili raczej nikt się na dane użytkowników Diaspory nie połasi, ale nie dlatego, że nie może, tylko dlatego, że się po prostu nie opłaca. Użytkowników Diaspory jest zwyczajnie za mało.

EncFS - kolejne narzędzie do szyfrowania upada

rozieblox

Dawno temu zachwycałem się EncFS[1]. Obsługiwało AES, pozwalało szyfrować pliki, nie partycje i pozwalało trzymać je na zwykłym systemie plików. Tak naprawdę szyfrowany był katalog. Jakiś czas temu upadł Truecrypt, który - zdaniem twórców - okazał się nie tak bezpieczny, jak postrzegali go ludzie. Teraz kolej na EncFS.

Wczoraj, podczas aktualizacji systemu[2], dostałem w twarz dialogboksem o następującej treści:

Encfs security information

According to a security audit by Taylor Hornby (Defuse Security), the current implementation of Encfs is vulnerable or potentially vulnerable to multiple types of attacks. For example,
an attacker with read/write access to encrypted data might lower the decryption complexity for subsequently encrypted data without this being noticed by a legitimate user, or might use
timing analysis to deduce information.

Until these issues are resolved, encfs should not be considered a safe home for sensitive data in scenarios where such attacks are possible.

Pięknie, prawda? Szczególnie, że EncFS byłby świetnym rozwiązaniem do szyfrowania plików w chmurze - EncFS dla WebDAV czy Dropbox były proste w założeniu i wygodne w użytkowaniu[3]...

Wygląda, że pomału można żegnać się z EncFS. A podobnych alternatyw jakoś nie widać na horyzoncie.

[1] Strona projektu zwraca 404. Przypadek? W każdym razie nie linkuję, łatwe do wyszukania...

[2] Debian unstable. Akurat tam nie używam encfs, ale instaluję wszędzie. Planowałem do chmury.

[3] Ładne ilustrowane howto dla EncFS w chmurze.

Dziura w OpenSSL, o jakiej się nie śniło

rozieblox

No bo jak inaczej nazwać błąd, który pozwala na zdalny dostęp do pamięci podatnej maszyny? Co prawda "tylko" 64kB i "tylko" związanej z procesem korzystającym z biblioteki zawierającej błąd, ale biorąc pod uwagę, do czego OpenSSL służy... Wyciec mogą klucze (jeśli nie zostaną zmienione, to w przypadku ich przechwycenia będzie można podsłuchać transmisję nawet po aktualizacji biblioteki), loginy i hasła (jeśli użytkownicy nie zmienią haseł, to atakujący będzie mógł się dostać do serwisów nawet po zmianie certyfikatów i aktualizacji biblioteki).

Heartbleed

Źródło: http://heartbleed.com/

Błąd związany z OpenSSL w Debianie sprzed blisko 6 lat to przy tej dziurze pikuś - wtedy wystarczyło zaktualizować pakiet i zmienić klucze. Teraz na dobrą sprawę należałoby zmienić wszystkie certyfikaty SSL (o ile były używane na choć jednej podatnej maszynie) i skłonić wszystkich użytkowników do zmiany haseł. Niekoniecznie technicznych użytkowników, dodajmy.

Ważne jest to o tyle, że niektóre popularne polskie serwisy oferujące darmową (i nie tylko) pocztę były podatne. I to dość długo (nie wiem, czy nadal nie są). Jeśli atakujący uzyska dostęp do poczty, a używamy tej skrzynki do przypominania hasła w innych serwisach to zmiana w nich haseł nie rozwiązuje problemu.

Dodatkowo sprawdzanie podatności systemów było utrudnione. Popularny test sprawdzający podatność na atak z powodu obciążenia zgłaszał... false negatives. Czyli system był podatny, a narzędzie testujące twierdziło, że jest OK. I to w pewnym momencie, wg moich obserwacji, w jakichś 9x% prób... Problemu tego nie miało narzędzie CLI, ale dość szybko przestało ono być dostępne. Zapewne dlatego, że skutkiem ubocznym tego narzędzia był zrzut pamięci i dostęp do wrażliwych danych.

Na koniec mały paradoks. Systemy, w których logowanie było bez szyfrowania nie są podatne na dziurę (za to były i są podatne na podsłuchanie transmisji). Podobnie jak Debian Squeeze, czyli oldstable, któremu wkrótce skończy się support bezpieczeństwa. Użyta w nim wersja OpenSSL jest na tyle stara, że nie jest podatna.

Na razie status jest taki, że jest dostępna poprawka, załatana jest część systemów (wczoraj o ok. 17 było naprawdę sporo dziurawych). Widziałem tylko jedną firmę (polską), która poinformowała o błędzie użytkowników i zaleciła zmianę certyfikatów (ale już ani słowa o hasłach). Osobiście zalecam zwykłym użytkownikom w tej chwili zmianę ważniejszych haseł (zwł. pocztowych!) i obserwację sytuacji. Gdy opadnie kurz, tj. administratorzy załatają systemy i wymienią certyfikaty - ponowna zmiana haseł, tym razem wszystkich (ale naprawdę wszystkich wszystkich).

Błędowi poświęcona jest specjalna strona i tam odsyłam po szczegóły. Tak jeszcze patrzę na to, co napisałem parę lat temu i chyba tekst dane, niezależnie od tego jak zabezpieczane, nie są bezpieczne i prędzej czy później nastąpi ich ujawnienie łapie się na jakieś motto.

UPDATE: Ważna uwaga, o której zapomniałem. Jeśli aktualizujemy OpenSSL w systemie, to trzeba jeszcze zrestartować usługi. W Debianie można skorzystać z polecenia checkrestart (pakiet debian-goodies), ale na przynajmniej jednym systemie pokazywał, że nie ma nic do restartu, choć był apache i zabbix-server. Można zamiast tego użyć:

lsof -n | grep ssl | grep DEL

CryptoLocker - polski akcent

rozieblox

Istnieją poważne poszlaki, że za ransomware o nazwie CryptoLocker stoją... Polacy. Malware ów został zbadany i opisany na blogu [deadlink] (polecam lekturę całego wpisu), autor uzyskał dostęp do bazy (niestety dość pustej) i widać w kodzie tekst:

define('DBPASS', 'Be6mybCWhpFpgG4u');//Dostep do sql zamiana!!!

Swojsko brzmiący komentarz, prawda? Swoją drogą ładny przykład na to, że korzystanie z Tor nie oznacza braku możliwości namierzenia, gdzie stoi serwis, chociaż w tym przypadku autorowi wpisu nie udało się uzyskać adresu IP systemu.

UPDATE: Jak donosi Zaufana Trzecia Strona, malware nie nazywa się CryptoLocker, a CryptorBit. Polecam ich wpis - dużo więcej informacji i po polsku.

Botnet w Torze.

rozieblox

Napisałem dziś na µblogu, że mam dylemat. I podałem tego linka do bloga projektu Tor. Ostatnio zajmowałem się czym innym i zupełnie przegapiłem opisywany gwałtowny wzrost użytkowników Tora. Dziś zagadka została wyjaśniona - winny jest botnet, który korzysta z Tora do zarządzania węzłami (dobre źródło, po polsku i blog ogólnie ciekawy). Mój dylemat polega na tym, że w chwili obecnej 80% węzłów Tora stanowią komputery zombie wykorzystywane do ataków DDoS, wysyłania spamu itp., a ja nie chcę pomagać spamerom/abuserom.

Jasne, wiadome było, że nie tylko do szczytnych zastosowań Tor służy, ale do tej pory nie miałem żadnych konkretnych, jednoznacznych danych. Teraz je mam.

Sytuacja jest bardzo niekorzystna dla projektu, o czym autorzy nie piszą. Botnet prosto można rozbroić np. wyłączając mu komunikację. Czyli - na poziomie operatora ISP - np. blackhole'ując wszystkie node'y Tora (pośredniczące, czyli relay nodes; lista węzłów wyjściowych i pośredniczących jest publiczna, o czym pisałem we wpisie nt. walki z Tor). Chyba, że botnet jest naprawdę sprytny i korzysta z bridge node'ów, ale coś mi mówi, że raczej nie. Poza tym, zablokowanie - albo przynajmniej drastyczne utrudnienie - dostępu do informacji o bridge nodes też nie jest specjalnie trudne dla ISP...

Twórcy Tora są więc w trudnej sytuacji. Z jednej strony projekt powstał dlatego, że chcą zapewnić swobodną komunikacją. Z drugiej - jeśli nie będą interweniować i nie wyłączą w jakiś sposób botnetu, to istnieje ryzyko, że cała sieć Tor stanie się obiektem ataku jako wspierająca botnet.

Póki co, mój dylemat rozwiązałem tak, że drastycznie zredukowałem pasmo na moim relay node. I czekam na rozwiązanie sprawy. Jeśli trend się utrzyma, nie wykluczam wyłączenia węzła w ogóle.

PS. Jest jeszcze też oczywiście spiskowa teoria. Wszystko to dzieło wspierających kontrolę użytkowników i obywateli i zemsta za dekonspirację PRISM.

© Pomiędzy bitami
Blox.pl najciekawsze blogi w sieci