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

K

ontynuując naszą serię Necronomicon zajmiemy się dzisiaj publicznymi wiaderkami danych, które są umieszczone w chmurze. Bardzo wiele firm i prywatnych osób nadal przeprowadza adopcję chmury publicznej, której flagową usługą jest możliwość taniego przechowywania plików różnej maści. Mimo wielu badań, opracowań i raportów niewielu z tych adeptów zdaje sobie sprawę, że gdy tylko zdecydują się na ustawienie (świadomie lub nie) publicznego dostępu do dowolnego wiaderka (ang. bucket) istnieje duże prawdopodobieństwo, że ich nazwy zostaną odgadnięte, a dane zindeksowane oraz wystawione innym użytkownikom do łatwego przeszukiwania i pobierania. 24 września 2023 roku wyszukiwarka GrayHatWarfare przyznała, że jej baza danych zawiera 416.712 różnych wiaderek danych, 316.00 z S3, 6800.000 z DigitalOcean, 44000 z Google oraz 49.900 otwartych kontenerów z Azure, co daje łącznie 10,4 miliarda publicznie dostępnych plików. Patrząc z perspektywy bezpieczeństwa te wszystkie publiczne magazyny danych zawierają wiele szalonych rzeczy: pliki PST (które można zaimportować do programu Outlook, jako kompletne skrzynki e-mail); paszporty (których zapisywanie jest nielegalne w kilku krajach); certyfikaty urodzin; numery ubezpieczenia społecznego z USA; recepty oraz dane medyczne; rachunki i dane klientów; polisy ubezpieczeniowe; klucze licencyjne; dane dostępowe; klucze dostępowe; tokeny; certyfikaty TLS; pliki konfiguracyjne do narzędzi: WinSCP, FileZilla, Sublime, Menedżery haseł, VPN, Gitlab; Pliki konfiguracyjne PHP…
[ czytaj całość… ]

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ść… ]

B

ardzo wiele firm utrzymuje repozytoria publicznych projektów na popularnych serwisach takich jak Github oraz Gitlab. Na przykład listę loginów poszczególnych użytkowników w serwisie Github można uzyskać bardzo łatwo – wystarczy odwiedzić adres: https://github.com/orgs/$firma/people.

Plus iterując po poszczególnych projektach: https://github.com/$firma/$projekt/graphs/contributors można zebrać dość dużą ilość unikatowych użytkowników. Gdzie następuje wyciek? Otóż Github używa adresów e-mail powiązanych z kontem Github (można mieć ich więcej niż jeden – a często na jednym koncie łączy się prywatne i firmowe adresy) przy zatwierdzaniu kodu (ang. commit) oraz innych aktywnościach w profilu użytkownika. Kiedy użytkownik zatwierdza kod w publicznym repozytorium jego adres e-mail jest publikowany i staje się publicznie dostępny.
[ czytaj całość… ]

Poniżej znajduje się aktualizacja wcześniejszej listy:

1. CloudFlare:
– 1.1.1.1
2. Quad9:
– 9.9.9.9
3. Google:
– 8.8.8.8, 8.8.4.4
4. CleanBrowsing:
– 185.228.168.168, 185.228.168.169
5. OpenDNS:
– 208.67.220.220, 208.67.222.222
6. Norton ConnectSafe:
– 199.85.126.10, 199.85.127.10
7. Comodo Secure DNS:
– 8.26.56.26, 8.20.247.20
8. DNS.Watch:
– 84.200.69.80, 84.200.70.40
9. VeriSign Public DNS:
– 64.4.64.6, 64.6.65.6
10. Yandex DNS:
– 77.88.8.88, 77.88.8.2

Więcej informacji: DNS Resolvers Performance compared, Jak znaleźć najszybszy publiczny serwer DNS w Polsce?

curl -s http://public-dns.info/nameserver/pl.csv > list; cat list | cut -d "," -f1 | \
xargs -i timeout 1 ping -c1 -w 1 {} | grep time | \
sed -u "s/.* from \([^:]*\).*time=\([^ ]*\).*/\2\t\1/g" | grep -v "1 packets" | sort -n

Więcej informacji: DNS servers in Poland

1. Google:
– 8.8.8.8, 8.8.4.4
2. OpenDNS:
– 208.67.220.220, 208.67.222.222
3. Norton ConnectSafe:
– 199.85.126.10, 199.85.127.10
4. Comodo Secure DNS:
– 8.26.56.26, 8.20.247.20
5. DNS.Watch:
– 84.200.69.80, 84.200.70.40
6. VeriSign Public DNS:
– 64.4.64.6, 64.6.65.6