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

D

zisiaj stworzymy sobie małe wejście do szyny danych wzbogacającej o metadane adres IP klienta. Prototyp o nazwie Interceptor, który zademonstruje użyje JA3 do fingerprintingu botów, skanerów, szkodliwego oprogramowania oraz innych programów, które korzystają w komunikacji z protokołu HTTPS. Zacznijmy od JA3. Firma Salesforce otworzyła tę metodę fingerprintigu klientów TLS w 2017 roku. Podstawowa koncepcja pobierania “cyfrowych odcisków palców” od klientów TLS pochodzi z badań Lee Brotherstona (w 2015 roku wygłosił on prezentację na ten temat). Jak wiemy TLS i jego poprzednik SSL, są używane do szyfrowania komunikacji dla popularnych aplikacji, aby zapewnić bezpieczeństwo danych. Aby zainicjować sesję TLS klient wysyła pakiet: TLS Client Hello po potrójnym uścisku dłoni TCP. Pakiet ten i sposób, w jaki jest generowany, zależy od metod i innych pakietów / bibliotek oprogramowania użytych podczas budowania danej aplikacji klienckiej.
[ czytaj całość… ]

Z

nalezienie tylnego wejścia (ang. backdoor) uruchomionego w systemie Linux nie zawsze może być trywialne. Tylne furtki służą do interakcji atakującego z hostem w czasie rzeczywistym i są konsekwencją / kolejnym krokiem włamania do systemu. Sposród różnych backdoorów, które można wykorzystać w środowisku *nix jest bardzo dobrze znany bindshell, czyli powłoka, która nasłuchuje na określonym porcie TCP/IP. Uruchomi ona wszystko, co zostanie wysłane do tego portu i odpowie danymi wyjściowymi z przesłanych poleceń. Jej wariantem jest odwrócona powłoka (ang. reverse shell), ponieważ zamiast łączenia się atakującego z ofiarą, napastnik powoduje (np. poprzez podatną webaplikację), że to system ofiary łączy się do niego z powrotem. Dlaczego to takie ważne? Ponieważ większość funkcji filtrowania sieci jest skonfigurowana tak, aby szczegółowo blokować ruch przychodzący z internetu. Jednak bardzo często ruch wychodzący jest nieograniczony lub znacznie mniej filtrowany. Dlatego odwrócony bindshell jest świetnym sposobem na przeskakiwanie zapór ogniowych i innych mechanizmów ochrony.
[ czytaj całość… ]

D

omowa sieć WiFi to nasze święte miejsce. Nasz skromny kawałek cyberprzestrzeni. Tam podłączamy nasze telefony, laptopy i inne “inteligentne” urządzenia ze sobą i internetem. Jeszcze nie ma końca dwa tysiące dwudziestego roku, a nasze sieci lokalne zostały zaludnione przez rosnącą liczbę urządzeń. Od inteligentnych telewizorów i odtwarzaczy multimedialnych po asystentów domowych, kamery bezpieczeństwa, lodówki, zamki do drzwi i termostaty – nasze LANy stały się schronieniem dla zaufanych urządzeń osobistych i domowych. Wiele z tych urządzeń oferuje ograniczone lub żadne uwierzytelnianie w celu uzyskania dostępu i kontrolowania swoich usług. Z natury ufają one innym urządzeniom w sieci w taki sam sposób, w jaki z własnej woli ufalibyście komuś, komu pozwoliliście znaleźć się w Waszym domu. Korzystają z takich protokołów, jak Universal Plug and Play (UPnP) i HTTP, aby swobodnie komunikować się między sobą, ale są z natury chronione przed połączeniami przychodzącymi z internetu za pomocą zapory ogniowej routera. Można porównać to do ogrodu otoczonego murem. Niestety wystarczy podążenie za złym linkiem, aby umożliwić atakującemu dostanie się do wewnętrznej sieci i uzyskanie kontroli nad różnego rodzaju urządzeniami.
[ czytaj całość… ]

B

łędy popełnia każdy z nas. Zazwyczaj są to nasze błędy “autorskie”, ale często są to też błędy powielające błędy innych. Te drugie zazwyczaj wynikają z ślepej wiary w ścieżki, którymi prowadzą nas inne osoby – mówiąc prościej – podążając za tutorialami / przewodnikami z sieci zakładamy, że ich autor nie popełnił błędów, a my właśnie nie kopiujemy ich dalej. Jeśli wpiszemy w dowolną wyszukiwarkę frazy typu: “nginx ssl tutorial“, “apache ssl tutorial“, “haproxy ssl tutorial” itd. to możemy odnaleźć pewne wzory, którymi rządzą się te przewodniki…
[ czytaj całość… ]

S

SL / TLS jest pozornie prostą techniką zapewniającą m.in. ochronę witryn internetowych. Gwarantuje poufność transmisji danych przesyłanych przez internet, zachowując przy tym prostotę instalacji i działania – z wyjątkiem, gdy tak nie jest. Przy końcówce 2014 roku, gigant z Mountain View – Google – na swoim blogu poinformował, że strony korzystające z certyfikatów SSL, będą bardziej “lubiane” w wynikach wyszukiwania, a także chętniej indeksowane. Nie jest to jednak ostatnie słowo. Główna litera Alfabetu nie tylko tą akcją chce wprowadzić strony WWW w kolejny etap bezpiecznego internetu. Już na początku 2017 roku, rodzima przeglądarka Chrome będzie posiadała mechanizmy, które podczas łączenia z dowolną witryną jednoznacznie odpowiedzą użytkownikowi na pytanie: czy korzystanie z niej jest bezpieczne?
[ czytaj całość… ]

3

grudnia portal Let’s Encrypt osiągnął status beta tym samym dając możliwość wszystkim zainteresowanym użytkownikom podpisywania certyfikatów SSL za darmo. Za projektem stoją takie firmy, jak Akamai, Cisco, Electronic Frontier Foundation, Mozilla Foundation, Internet Society, IdenTrust, czy Automattic. Najważniejszą informacją jest fakt, że certyfikatom wydawanym przez portal Let’s Encrypt, w przeciwieństwie do dotychczas istniejących “darmowych” rozwiązań, ufają wszystkie liczące się na rynku Internetu przeglądarki. W dodatku cały proces wygenerowania i podpisania certyfikatu jest łatwy i można go prosto zautomatyzować.
[ czytaj całość… ]

P

oniższe reguły mod_rewrite pozwalają na przekierowanie całego ruchu HTTP na HTTPS na serwerach Apache utworzonych w ramach AWS EC2 – wykorzystując nagłówek X-Forwarded-Proto dostarczany przez Load Balancer:

  RewriteEngine On
  RewriteCond %{HTTP:X-FORWARDED-PROTO} !https [NC]
  RewriteCond %{REQUEST_URI} !^/status\.php
  RewriteRule ^/?(.*) https://domena.pl/$1 [R=301,L]

Gdzie URL http://domena.pl/status.php jest sprawdzana przez Health Checker w celu stwierdzenia, czy dany serwer WWW jest reponsywny – dlatego została wykluczona z przepisywania.

Więcej informacji: Elastic Load Balancing Concepts and Terminologies

H

TTP Strict Transport Security (HSTS) jest opcjonalnym mechanizmem zabezpieczeń, w którym serwer WWW oświadcza klientowi (np. przeglądarce internetowej), że komunikacja powinna odbywać się tylko po bezpiecznym połączeniu. Oświadczenie serwera WWW odbywa się poprzez zastosowanie specjalnego nagłówka odpowiedzi HTTP: “Strict-Transport-Security“. Klient obsługujący mechanizm HSTS otrzymując ten nagłówek będzie zapobiegał wszelkiej łączności poprzez protokół HTTP w określonej domenie i starał się, aby wszystkie połączenia odbywały się przez HTTPS.
[ czytaj całość… ]

A

ktualnie istnieje wiele otwartych sieci Wi-Fi, czyli tzw. Hotspotów. Problemem hotspotów jest częsty brak zapewnienia odpowiedniego szyfrowania i izolacji poszczególnych klientów. Dlatego w tego rodzaju sieciach najczęściej dochodzi do podsłuchiwania ruchu sieciowego, a tym samym przejęcia danych autoryzacyjnych do poczty, czy różnych serwisów społecznościowych lub bankowych, w których podczas trwania procesu uwierzytelniania – ruch między naszą przeglądarką lub klientem pocztowym, a serwerem nie zawsze jest (cały czas) szyfrowany.
[ czytaj całość… ]