Mac i problemy z locale w terminalu – HOWTO

Jak pisałem, częściowo siedzę na macu. Zrozumiałem ludzi, którzy narzekali na obsługę systemu klawiaturą w macach. Wiele skomplikowanych combo na trzy palce. Ale to mogła by być kwestia przyzwyczajenia, zwłaszcza w trybie graficznym. Jeśli jednak ktoś korzysta głównie z terminala, to „fun” jest na zupełnie innym poziomie. Otóż funkcję klawisza Ctrl w macOS „normalnie” (czyli w GUI) spełnia lewy klawisz command, umieszczony tam, gdzie normalnie jest alt. Jeśli jednak przejdziemy do terminala, to w aplikacjach uruchomionych w konsoli żeby zrobić ctrl-c należy wcisnąć… control-c. Tak, jest też osobny klawisz control, którego należy używać w terminalu.

Jeśli jednak korzystamy z VirtualBox i uruchomimy tam Linuksa, to żeby utworzyć nową zakładkę w przeglądarce należy użyć… control-t. W GUI. W tej samej przeglądarce pod macOS używamy command-t. IMO totalna porażka UXowa i coś do czego nie sposób się przyzwyczaić, jeśli ktoś używa systemów na przemian. Można najwyżej nieustannie pamiętać, ale u mnie kończy się to masą missclicków. Zobaczę jeszcze co będzie po podłączeniu zewnętrznej, pecetowej klawiatury, choć to raczej z ciekawości – w końcu to nie stacjonarka. Ew. poszukam jakiegoś software’owego rozwiązania, choć staram się unikać przemapowywania klawiszy jak mogę – ciężko się później korzysta z instrukcji w necie.

Z pozytywów – doceniam działające kopiowanie i wklejanie w terminalu przy pomocy command-c i command-v. Pod Linuksem są na to osobne skróty, choć do tego akurat używałem myszy i zaznacz (i automatycznie skopiuj) i środkowego przycisku do wklejania. Domyślnie działa też – analogicznie jak pod Linuksem – wklejanie zaznaczonego w terminalu tekstu przy pomocy środkowego klawisza myszy. Niestety, jest ograniczone do konsoli, aby skopiować jakieś polecenie z przeglądarki trzeba już używać skrótów klawiszowych.

Wracając do tematu z topica. Po zmianie systemu na macOS i logowaniu przy pomocy ssh na serwery witał mnie komunikat w stylu:

-bash: warning: setlocale: LC_ALL: cannot change locale (pl_PL.UTF-8)
-bash: warning: setlocale: LC_ALL: cannot change locale (pl_PL.UTF-8)
-bash: warning: setlocale: LC_ALL: cannot change locale (pl_PL.UTF-8)

Sprawa jasna, problem ustawieniami locales, tyle, że nigdy mi się nie zdarzał, w systemie (macOS) niby są ustawione. Na chwilę odpuściłem temat, bo mało estetyczny komunikat przy logowaniu to nie dramat, ale szybko okazało się, że potrafi to wpływać – rzecz jasna ujemnie – na działanie poleceń i skryptów. Gdy tylko siadłem do szukania rozwiązania okazało się, że problem jest popularny, wręcz powszechny.

Pierwsze rozwiązanie, które znalazłem, wyglądało elegancko i nawet tłumaczyłoby, czemu nie działa skoro locales są ustawione. Niestety, po włączeniu i otwarciu nowych zakładek w terminalu, a nawet restarcie terminala okazało się, że… nie działa. Teraz widzę, że rozwiązanie jest stare, z 2012, wtedy mi umknęło.

Dopiero tu znalazłem faktyczne rozwiązanie problemu z locale w terminalu pod macOS. Jest proste i sprowadza się do dodania dwóch linii w pliku ~/.bash_profile:

export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8

Powinno działać także z wersją polską, ale nie testowałem – w moim przypadku powyższa wersja jest OK, przynajmniej po pobieżnym sprawdzeniu nie zauważyłem problemów. Ustawienie z pierwszego rozwiązania również zostawiłem.

Łamanie hashy NTLMv2 na podstawie pcap

Tu jest oryginalny wpis o jak crackować hash NTLMv2 pobierany z pliku pcap, wszystko opisane ładnie i dokładnie, ze zrzutami ekranu, ale pozwolę sobie na skrócony mirror, bo przydaje mi się to sporadycznie, a sądząc po kondycji strony z oryginałem niewykluczone, że do tego czasu oryginalny wpis zniknie (obym się mylił).

  1. Filtr ntlmssp w wireshark.
  2. Potrzebne dane w formacie dla hashcata, zapisywane w crackme.txt:
    username::domain:ServerChallenge:NTProofstring:ntlmv2response
  3. Oryginalne ntlmv2response zawiera na swoim początku NTProofstring, należy go usunąć przed użyciem wyżej.
  4. Uruchomienie:
    hashcat -m 5600 crackme.txt passwordlist.txt

Jak widać ekstrakcja hashy NTLMv2 potrzebnych danych ze zrzutu ruchu sieciowego jest ręczna. Szukałem pobieżnie automatu, ale nie znalazłem, a skoro używam rzadko, to pisać nie ma sensu. W sumie nie tyle pisać, co próbować pisać, bo rozmieszczenie danych miałem nieco inne, niż w linkowanym przykładzie. Gdyby jednak ktoś znał coś takiego, to chętnie poznam.

Przyspieszyć hashcata

Na blogu nfsec.pl pojawił się wczoraj wpis dotyczący crackowania hashy md5crypt[1] przy pomocy hashcat. 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. 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, hashcat, którego użyłem w wersji z GitHub (wersja development) to 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.