Trzy lata, sześć miesięcy i dwa tygodnie

Rzadko coś mnie zadziwia do tego stopnia i wielowymiarowo, jak to, o czym dowiedziałem się dziś. Chodzi oczywiście o błąd w Google+. No dobrze, nie sam błąd mnie zadziwił, bo ten był raczej mizerny. Poszło o to, że jeśli użytkownik Google+ udostępnił jakiejś aplikacji dostęp do danych publicznych swojego konta Google+, to aplikacja miała też dostęp do danych prywatnych. Z bardziej krytycznych – w świetle choćby RODO – do adresu email, imienia, nazwiska.

Chodzi o 500 tys. użytkowników, dane nie są super wrażliwe, udostępnione tylko aplikacjom. Oczywiście błąd pozostaje błędem, ale ten w dodatku został wykryty samodzielnie, nie na skutek wycieku. Ogólnie niezły potencjał na opowieść, którą nawet jeśli nie można się pochwalić, to nie ma się co wstydzić.

I tu pojawiają się tytułowe trzy lata, sześć miesięcy i dwa tygodnie, które jeżą włos na głowie. No dobrze, nie wszystkie. Trzy lata, to czas, kiedy podatność była dostępna. Tak naprawdę, powinny być dwa i pół, ale lepiej pasowało do clikcbaitowego tytułu. W dodatku zupełnie nie ma znaczenia ile czasu podatność była obecna – prawdopodobieństwo wykrycia nie rośnie z każdym dniem.

Ciekawe są dwie kolejne wartości. Sześć miesięcy to czas, przez który Google zataiło informację o podatności, bojąc się reakcji opinii publicznej. Wykryto ją w marcu 2018, ogłoszono wczoraj. W dodatku twierdzą, że w sumie nie wiedzą, czy podatność została wykorzystana, bo logi API mają z tytułowych dwóch tygodni, a nie trzymają ich dłużej, bo szanują prywatność użytkowników. Poważnie tak uzasadnili, w informacji o wycieku, która jest niejako przy okazji. Bardzo ładne zagranie PR-owe, ale jedyny komentarz, który przychodzi mi do głowy to:

Źródło: https://imgflip.com/i/2jpigy

Prędzej uwierzyłbym, że nie mają tych logów, bo im się na dyskach nie mieściły. 😉

Nie wiem, czy tak właśnie wygląda the right thing w świecie security, ale po graczu wielkości Google spodziewałem się jednak większej transparentności.

Kolejne zaskoczenie to reakcja rynku. Czy też może właśnie brak tej reakcji. Akcje Alphabet symbolicznie spadły, szybko odrobiły. Nie stało się nic… Przynajmniej na razie, zobaczymy jeszcze jak zareagują urzędy regulujące różnej maści, ale póki co wszystko wskazuje na to, że ani prywatność, ani transparentność nie są dzisiaj w cenie.

MauiBot – analiza zachowania bota

Pewnego dnia patrząc w logi serwera WWW zauważyłem sporą aktywność bota identyfikującego się jako:

MauiBot (crawler.feedback+dc@gmail.com)

Z zapałem crawlował labirynt dla botów, w User Agent nie było zazwyczaj obecnego URLa, żeby poczytać, co to za wynalazek, więc uruchomiłem wyszukiwarkę. Szybko udało mi się ustalić, że to bad bot, działający z chmury Amazonu (AWS) i nawet są reguły dla nginx do blokowania ruchu od niego.

Na początek parę znalezionych linków:

Wygląda, że bot pojawił się w marcu tego roku, czyli jest dość świeży. Wygląda też, że potrafi spowodować trochę problemów, przynajmniej na shared hostingach i/lub stronach słabo zoptymalizowanych.

Dokładniejszych informacji nie ma, więc postanowiłem poobserwować zwyczaje bota na własną rękę.

Wygląda, że 25 lipca ok. 1:20 trafił na moją stronę domową i zaczął podążać za kolejnymi linkami. Korzystał z IP 54.237.208.52, nie dało się obserwować opisywanego w niektórych miejscach wykonywania requestów grupami po 4-8 co 30 sekund. Wykonywał między 100 a 250 requestów na godzinę.

Tego samego dnia ok. 20:40 zmienił IP na 54.87.252.55 i… zaczął wszystko od początku. 26 lipca około 1:20 skończyły się requesty dotyczące blogów, pozostały tylko dotyczące wypasania botów.  W tym momencie intensywność crawlowania znacząco wzrosła – między 1600 a 2100 requestów na godzinę. Daje się też zauważyć grupowanie requestów, choć wygląda ono nieco inaczej niż w opisywanych w sieci przypadkach – 3-4 requesty co 5-6 sekund. Być może każdy wątek dla danej ścieżki wykonuje 4 requesty co 30 sekund.

Zaczynam też obserwować spadek liczby zapytań na godzinę. 26 lipca o godzinie 7 było 1500 requestów, następnie systematycznie z godziny na godzinę spada do 900 requestów o 19 i 550 o godzinie 5 następnego dnia. O godzinie 19 27 lipca jest już tylko 340 requestów, a o godzinie 9 28 lipca już tylko 250 zapytań na godzinę.

W tym momencie zaczynam eksperymentować. Po pierwsze dodaję przed linkami z parametrami i za nimi linki z inną ścieżką, ale również prowadzące do labiryntu. Bot natychmiast za nimi podąża, najwyraźniej dokładając nowe wątki/procesy, bo liczba requestów wzrasta do ponad 700/h, przy czym liczba do bazowego powoli spada do ok. 200/h.

31 lipca liczba requestów to ok. 150/h. Podstawiam linka do labiryntu ale w innej domenie, ale MauiBot ignoruje tego linka. Trochę zbyt długo zwlekałem z analizą, obecnie bot reaguje bardzo powoli, więc publikuję teraz, a kolejne obserwacje pojawią się wkrótce, jako aktualizacja tego wpisu.

UPDATE

Aby sprawdzić, czy pomija ze względu na inną domenę, czy w ogóle przestał, dołożyłem kolejnego linka, tym razem w crawlowanej dotychczas domenie. Podążył za nim, a liczba requstów wzrosła do ok. 210/h. Podobnie bot podążył za URLem w tej samej domenie po podaniu pełnej ścieżki zamiast względnej, używanej wszędzie dotychczas.

Wygląda na to, że odwiedzone URLe są zapamiętywane – bot nie wrócił do początkowego indeksu, mimo podanie osobnego linka w odwiedzonej już ścieżce.

Aby sprawdzić, jak sobie radzi z forkowaniem i jak to wpływ na ilość requestów, wysłałem go w dziewięć kolejnych, niezależnych miejsc.

Ostatecznie przestałem go obserwować na bieżąco przez cztery tygodnie i w zasadzie czekałem tylko, kiedy skończy pobierać i czy np. nie zmieni IP. Nie zmienił, za to pobierać przestał 20 sierpnia 2018. Tempo pobierania w ostatnich godzinach to ok. 335/h, pobierał ze wszystkich stron w grupach nie po 4, a po 8 requestów.

Jak zabezpieczyć domową sieć Wi-Fi?

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

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

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

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

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

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

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

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' 
79LANG=C pwgen -s -1 11 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
122LANG=C pwgen -s -1 12 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
16LANG=C pwgen -s -1 13 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
27LANG=C pwgen -s -1 15 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
59LANG=C pwgen -s -1 16 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
98LANG=C pwgen -s -1 17 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
141LANG=C pwgen -s -1 18 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
215LANG=C pwgen -s -1 19 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
275LANG=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/systematicnowuTUtOon4W: it is too simplistic/systematicO4rstUX43Bef: it is too simplistic/systematic1mMTsIHZyHIH: it is too simplistic/systematicSeVw3MnMnOpp: 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 shortaqs: 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

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

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

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 informationAccording 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 usetiming 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

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