Przyspieszyć hashcata

Na blogu nfsec.pl pojawił się wczoraj wpis dotyczący crackowania hashy md5crypt[1]. Spojrzałem na sprzęt i moją uwagę przykuła wydajność karty Intela Intel(R) Iris(TM) Graphics 650:

Hashmode: 500 - md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5) (Iterations: 1000)
Speed.#2.........: 423.2 kH/s (53.30ms) @ Accel:256 Loops:250 Thr:8 Vec:1

Mam Intel Corporation Skylake GT2 [HD Graphics 520] widzianą jako Intel(R) Gen9 HD Graphics NEO i hashcata w wersji v5.1.0 (binarka, stable), na potrzeby zabaw z platformami CTF, o których wspominałem niedawno. Część zadań wymaga użycia brute force, i chociaż nie było do tej pory okazji wyjść poza coś typu gotowy słownik, to pewnie jeszcze się przyda. Rzecz w tym, że moja karta jest znacznie wolniejsza:

Hashmode: 500 - md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5) (Iterations: 1000)
Speed.#1………: 156.1 kH/s (76.04ms) @ Accel:256 Loops:250 Thr:8 Vec:4

Rozumiem, że to inny sprzęt i inny system (u mnie Debian w wersji unstable), ale postanowiłem podrążyć temat.

Po pierwsze, zauważyłem, że mam starsze pakiety OpenCL dla Intela. Aktualizacja nie przyniosła co prawda poprawy wydajności, ale na innym sprzęcie (Ubuntu) była w ogóle niezbędna do poprawnego działania hashcata – bez najnowszej wersji md5crypt w ogóle nie dawał się tam łamać.

Po drugie, użyłem hashcata w wersji z GitHub (wersja development) v5.1.0-951-g6caa7869 (również niezbędny na Ubuntu do poprawnego łamania md5crypt). Efekt okazał się całkiem przyjemny:

Hashmode: 500 - md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5) (Iterations: 1000)
Speed.#1………: 232.7 kH/s (51.57ms) @ Accel:256 Loops:250 Thr:8 Vec:4

Niemal połowę szybciej. Warto aktualizować soft i sterowniki, nawet, jeśli wersja wygląda na tylko nieznacznie nowszą. Co ciekawe, przyrost wydajności jest tak duży tylko dla niektórych algorytmów, w tym md5crypt. Inne, jak zwykłe md5 różnice mają jedynie symboliczne:

Hashmode: 0 - MD5
Speed.#1………: 476.6 MH/s (51.75ms) @ Accel:128 Loops:32 Thr:256 Vec:4

Hashmode: 0 - MD5
Speed.#1………: 493.4 MH/s (50.09ms) @ Accel:512 Loops:128 Thr:16 Vec:4

Tyle tym razem – trochę o instalacji i uruchomieniu hashcata, trochę o przyspieszeniu na poziomie softu. Mam świadomość, że to trochę takie wyścigi ślimaków, ale… jak się nie ma co się lubi, to się lubi co się ma. Może kiedy indziej będzie o doborze parametrów i budowie skutecznych słowników do crackowania hashy przy pomocy hashcata.

[1] Ładnie po polsku, owinięte w bawełnę, nazywa się to audyt haseł. Ewentualnie, mniej owijając w bawełnę, łamanie funkcji skrótu haseł. Zostanę jednak przy brzydkiej, potocznej wersji angielskiej.

Lynis – narzędzie do audytu bezpieczeństwa systemów Linux

Czasem zdarza się, że znajdę jakieś stare, fajne narzędzie, którego nie znałem wcześniej. Tak jest w przypadku Lynis – programu open source napisanego przez CISOfy służącego do audytu bezpieczeństwa systemu na podstawie bieżących ustawień. Przypadkiem, na komórce w tramwaju mignął mi wpis o nim gdzieś w sieci, opis był ciekawy, więc postanowiłem dać szansę, choć od dłuższego czasu nie interesowałem się podobnymi programami. Kiedyś, na początku przygody z Linuksem bawiłem się Bastille Linux i to w zasadzie wszystko, jeśli chodzi o automaty.

Działanie Lynis sprawdzałem tylko na Debianie i Ubuntu – działa bardzo sprawnie, generuje sensowne raporty z uwzględnieniem specyfiki dystrybucji. Przy każdym raporcie jest link do krótkiego opisu z wytłumaczeniem danej opcji. Dla początkujących jest to dobra okazja do poczytania nt. ustawień i ich wpływu na bezpieczeństwo systemu, dla zaawansowanych automat, który sprawdzi, czy czegoś nie przeoczyliśmy lub nie zapomnieliśmy włączyć np. po testach.

Program jest dostępny jako pakiet, więc instalacja sprowadza się do:

apt-get install lynis

Uruchomienie audytu również jest proste:

lynis audit system

Polecam dodanie przełącznika -Q. Program jedynie generuje raport, niczego nie zmienia w systemie, więc uruchomienie jest bezpieczne. Wynik wyświetla na ekran oraz do logu, znajdziemy tam zarówno znalezione błędy, ostrzeżenia, jak i wskazówki do hardeningu systemu.

Narzędzie ma zastosowanie raczej dla systemów, prywatnych,  utrzymywanych ręcznie – te konfigurowane automatycznie raczej nie mają miejsca na powstanie błędu, a forma raportu jest raczej przyjazna dla ludzi, niż maszyn.

Oczywiście przy domyślnej konfiguracji zgłosi także odstępstwa od normy, które są zamierzone albo nieistotne, więc wynik będzie nieco przegadany. Mimo to polecam wypróbowanie samodzielnie.

Polecenie su – zmiany

Jakiś czas temu zauważyłem, że mój Debian unstable na domowym desktopie zmienił zachowanie. Na koncie root przestał działać skrypt do aktualizacji systemu i usypianie.

Szybko sprawdziłem i oczywiście chodziło o PATH. Dopisałem pełne ścieżki do poleceń i prawie zapomniałem o sprawie, przypuszczając, że chodzi o jakiś chwilowy błąd w którymś z pakietów.

Jednak problem nie zniknął, więc postanowiłem sprawdzić dokładnie, co się wydarzyło. Na pierwszy ogień poszło sprawdzenie /etc/profile, w którym znalazłem spodziewane:

if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"

Również w /etc/login.defs wszystko wyglądało poprawnie:

# *REQUIRED* The default PATH settings, for superuser and normal users.
#
# (they are minimal, add the rest in the shell startup files)
ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Skończyły mi się pomysły, więc udałem się na kanał #debian-next z pytaniem, czy to błąd, czy może były ostatnio jakieś zmiany. I okazuje się, że zmiany były, grubsze, dotyczące polecenia su.

Uprzednio, wydanie „gołego” polecenia su zmieniało użytkownika na root oraz ustawiało należną mu ścieżkę. Obecnie należy podawać su – (forma niezalecana) lub, lepiej, su -l, aby osiągnąć ten efekt.

I jeszcze co ciekawsze fragmenty dokumentacji (man su). Było:

The current environment is passed to the new shell. The value of $PATH is reset to /bin:/usr/bin for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the
superuser. This may be changed with the ENV_PATH and ENV_SUPATH definitions in /etc/login.defs.
[...]
-, -l, --login
Provide an environment similar to what the user would expect had the user logged in directly.

Aktualnie jest:

For backward compatibility, su defaults to not change the current directory and to only set the environment variables HOME and SHELL (plus USER and LOGNAME
if the target user is not root). It is recommended to always use the --login option (instead of its shortcut -) to avoid side effects caused by mixing envi-
ronments.
[...]
-, -l, --login
Start the shell as a login shell with an environment similar to a real login:
o clears all the environment variables except TERM
o initializes the environment variables HOME, SHELL, USER, LOGNAME, and PATH
o changes to the target user's home directory
o sets argv[0] of the shell to '-' in order to make the shell a login shell

Więc gdyby komuś w jakiejś debianopodobnej dystrybucji niebawem su przestało ustawiać PATH, to najprawdopodobniej chodzi o tę zmianę.

3 powody dla których nie kupię Raspberry Pi 3

Blisko trzy lata temu (ależ ten czas leci) pisałem, dlaczego nie kupię Raspberry Pi. Parę dni temu opublikowana została specyfikacja Raspberry Pi 3. I też widzę, że nie kupię, choć cieszę się na płytkę z 64 bit ARM. Powody są trzy:

  1. Brak portu SATA. Najmniej istotny, bo można podłączyć dysk po USB (i raczej tak zrobię), ale nadal trochę boli.
  2. Tylko 1 GB RAM. Mało. Na desktop – przeraźliwie mało. IMO minimum dla desktopa na dzień dzisiejszy to 2 GB RAM. Zresztą skoro mocniejszy procesor, to i serwer można by bardziej obciążyć, a tu RAM też się przydaje.
  3. 100 Mbps ethernet. Dla rozwiązań typu NAS 100 Mbps to zdecydowanie za mało.

Co zamiast Raspberry Pi 3? Czaję się na najwyższy model Pine 64 czyli PINE64+ 2GB. Co prawda też nie ma SATA, ale ma 1Gbps kartę sieciową oraz 2 GB pamięci RAM. I ma kosztować przy tym 29 dolarów + 12 dolarów za wysyłkę do Polski.

Wady Pine64? Wspomniany brak SATA, jeśli ktoś potrzebuje USB i bluetooth, to musi dołożyć kolejnych 10 dolarów, albo kupić wersje na USB (2,5 w Chinach) i zająć oba porty. No i trzeba poczekać do maja.

UPDATE To wszystko oczywiście z mojego punktu widzenia, który można streścić „małe, tanie, mocne i Linux działa”. Z punktu widzenia kogoś, kogo bardziej interesuje zabawa elektroniką będzie to wyglądało zupełnie inaczej, bo w grę wchodzi choćby łatwość supportu czy dostępność rozszerzeń.

Warto też przeczytać komentarz Piotra (pierwszy) – Odroid wygląda nieźle (jak zwykle zresztą), choć jest nieco droższy (jak zwykle zresztą). Patrz porównanie. Czyli ciekawych alternatyw dla Raspberry Pi 3 jest więcej.

Dowiedziałem się też o istnieniu dystrybucji Armbian. Autorzy nie piszą niestety zbyt wiele, ale wygląda interesująco i wspiera wiele płytek. Oferuje świeży kernel i wspiera Debiana (Wheezy, Jessie) oraz Ubuntu Trusty.

Ubuntu 14.04 LTS, apt-dater i restart usług

Jakiś czas temu zachwalałem apt-dater jako narzędzie do aktualizacji większej ilości systemów. Jak pisałem w późniejszych uwagach, apt-dater nieźle integruje się z programem needrestart. Tyle teorii…

Niestety, o ile na Debianie Jessie wyglądało to naprawdę dobrze i sprawdzenie przez checkrestart (inne polecenie realizujące podobne zadanie) dawało spójne wyniki z needrestart, o tyle na Ubuntu 14.04 LTS needrestart pokazywał często, że do restartu nic nie ma, o tyle checkrestart był zupełnie innego zdania... I – co gorsza – miał rację.

Przyczyną okazała się różnica w wersji needrestart. W Jessie jest to 1.2, w Ubuntu 14.04 LTS – 0.5. Ponieważ to skrypt perlowy, to dałem szansę i wrzuciłem wersję z Debiana (stable). Instaluje się czysto, działa bardzo dobrze – w połączeniu z apt-dater wykrywa więcej usług do restartu i także tu wyniki needrestart są teraz spójne z checkrestart.

Nawiasem, checkrestart w Jessie ma problem z mysql i zawsze pokazuje, że należy go zrestartować. Jest na to zgłoszony bug. Ale to tak nawiasem, kto korzysta, ten wie, zresztą można dopisać mysql do wyjątków w konfigu.