J

akiś czas temu dowiedzieliśmy się, że klucze OpenSSH mogą posłużyć do podpisywania plików lub commitów git. Do tego samego celu możemy wykorzystać klucze używane w certyfikatach SSL/TLS (pozyskane z dowolnej strony, która jest dostępna za pomocą protokołu HTTPS). Pierwszym krokiem jest stworzenie pliku z wiadomością:

echo 'TOP Secret Message' > msg.txt

Drugim jest podpisanie pliku za pomocą prywatnego klucza, który znajduje się na serwerze:

openssl dgst -sha256 -sign /etc/apache2/ssl/server.key -out msg.txt.sig msg.txt

Trzecim jest konwersja pliku msg.txt.sig z formatu binarnego do tekstowego używając BASE64:

openssl base64 -in msg.txt.sig -out msg.txt.sig.asc

Jeśli teraz opublikujemy plik z wiadomością msg.txt oraz jego podpis: msg.txt.sig.asc, każdy posiadający dostęp do strony będzie mógł zweryfikować jej autentyczność. W pierwszym kroku użytkownik musi uzyskać klucz publiczny:

openssl s_client -connect nfsec.pl:443 | openssl x509 -pubkey -noout > pubkey.key

Następnie użytkownik musi ponownie zamienić opublikowaną sygnaturę tekstową do formy binarnej:

openssl base64 -d -in msg.txt.sig.asc -out msg.txt.sig

i zweryfikować poprawność wiadomości za pomocą pobranego klucza:

user@user:~$ openssl dgst -keyform pem -verify pubkey.key -signature msg.txt.sig msg.txt
Verified OK

Ale to nie wszystko. Skoro użytkownik może bardzo prosto pozyskać klucz publiczny serwera to jest w stanie szyfrować wiadomości przeznaczone do jego administratora lub właściciela:

openssl pkeyutl -in msg.txt -out to_agresor.enc -pubin -inkey pubkey.key -encrypt

Tak przesłana wiadomość może zostać odczytana za pomocą klucza prywatnego, który został użyty w certyfikacie TLS/SSL danego serwera:

root@stardust:~# openssl pkeyutl -in to_agresor.enc -out msg.txt -inkey \
                 /etc/apache2/ssl/server.key -decrypt
root@stardust:~# cat msg.txt
TOP Secret Message

W ten sposób każdy użytkownik może zaszyfrować wiadomość dla właścicieli swoich ulubionych stron internetowych – nawet jeśli nie publikują one jawnie klucza publicznego.

Więcej informacji: Using HTTPS certificates to sign/encrypt arbitrary data

O

penSSH – Secure Shell Server zapewnia bezpieczny, szyfrowany zdalny dostęp do systemów *niksowych. Po stronie serwera znajduje się plik authorized_keys w katalogu .ssh (głównym folderze użytkownika), w którym można skonfigurować uwierzytelnianie za pomocą klucza publicznego. Przy normalnej konfiguracji użytkownik uzyskuje pełny dostęp do systemu, w którym skonfigurowano uwierzytelnianie. Jednak w niektórych przypadkach, takich jak automatyczne operacje na zdalnych serwerach (np. wdrażanie kodu, tworzenie kopii zapasowych, uruchamianie konkretnych skryptów), sensowne jest ograniczanie dostępu do kilku lub nawet jednego polecenia. Oprócz ograniczenia poleceń dla danego użytkownika zapobiegamy również kompromitacji zdalnego serwera w przypadku przejęcia klucza prywatnego.
[ czytaj całość… ]

P

ierwszy raz z truflową świnką ryjącą za poszukiwaniem kluczy mogliśmy spotkać się w Oh Shit, Git?!. Najnowsza, trzecia wersja została zupełnie przepisana w języku Go. Dodano do niej obsługę ponad 600 typów kluczy zwiększając tym samym zdolność tego narzędzia do polowania na wycieki danych uwierzytelniających. W dodatku detektory te obsługują aktywną weryfikację z odpowiednimi interfejsami API. Ujawnione dane uwierzytelniające, w tym pary tajnych kluczy, stanowią poważny problem cyberbezpieczeństwa. Klucze mogą być nadużywane do włamywania się do sieci korporacyjnych, często bardziej potajemnie i przez dłuższy czas niż wykorzystywanie luk w popularnym oprogramowaniu.
[ czytaj całość… ]

Znalazłeś w repozytorium X prywatny klucz SSH i chciałbyś się dowiedzieć do kogo należy? Nic prostszego:

ssh -i znajda.key git@github.com

Warning: Permanently added 'github.com' (RSA) to the list of known hosts.
PTY allocation request failed on channel 0
Hi nfsec! You've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.

Działa również z gitlab.com, bitbucket.org i zapewne innymi.

Więcej informacji: GNU/JUSTIN

J

eśli nasza maszyna Linuksowa otwiera całą masę nowych połączeń – z czasem może zaistnieć zapotrzebowanie na większą liczbę portów. Standardowe ustawienia zawierają dość mały zakres – od 32768 do 61000. W celu zwiększenia przedziału możemy użyć polecenia sysctl. Należy mieć na uwadze, że powiększanie ilości portów zarejestrowanych oraz dynamicznych jest przydatne tylko dla serwerów o wysokiej wydajności i przepustowości. W celu odczytania aktualnego zakresu wystarczy wydać polecenie:
[ czytaj całość… ]