Tag Archives: fail

KISS – keep it simple, sweetheart!

“Compliance” za wszelką cenę, tylko nie wiem z czym.

Tak było

Historia zaczyna się tak, że w ramach wymiany uprzejmości z producentem urządzenia, innym słowy – zgłoszenia (ticketu) z supportem, nastąpiła konieczność przesłania pliku – od producenta do klienta. Zazwyczaj odbywało się to bez wielkich ceregieli – plik był dołączany do zgłoszenia, pobierany przez (uwierzytelnionego) odbiorcę przy użyciu przeglądarki, transmisja szyfrowana na poziomie protokołu TLS. Proste, działające rozwiązanie.

Przyszło nowe.

Tym razem klient pobrał – zwyczajową techniką – plik (dokument z rozszerzeniem .docx), a po jego otworzeniu w skojarzonym programie MS Word jego oczom ukazał się zaskakujący widok:

Jako że domena wydawała się podejrzana, do tego link po http, postanowił zasięgnąć języka. Po odpytaniu whois niby jest światełko w tunelu (serwery DNS)…

Domain Name: CAPSULEDOCS.COM
Registry Domain ID: 1949652212_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.domainthenet.com
Registrar URL: http://www.DomainTheNet.com
Registrar: Domain The Net Technologies Ltd.
Registrar IANA ID: 10007
Registrar Abuse Contact Email: abuse@dtnt.com
Registrar Abuse Contact Phone: 972-3-7600500
Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Name Server: NS4.CHECKPOINT.COM
Name Server: NS9.CHECKPOINT.COM
DNSSEC: unsigned

… ale próba wymuszonego połączenia po https (w celu podejrzenia certyfikatu) zakończyła się (optymistycznym) błędem:

* Server certificate:
* subject: CN=ds.checkpoint.com,OU=MIS-US,O=Check Point Software Technologies Inc.,L=San Carlos,ST=California,C=US
* start date: Apr 05 00:00:00 2016 GMT
* expire date: May 04 23:59:59 2018 GMT
* common name: ds.checkpoint.com
* issuer: CN=Symantec Class 3 Secure Server CA – G4,OU=Symantec Trust Network,O=Symantec Corporation,C=US
* NSS error -12276 (SSL_ERROR_BAD_CERT_DOMAIN)

Postanowiliśmy sięgnąć do bazy wiedzy producenta. Znalazły się w niej również artykuły opisujące rozwiązanie zastosowane do zabezpieczenia pliku. Artykuł w bazie wiedzy odsyła dla odmiany do domeny securedoc.cc po oprogramowanie niezbędne do otwarcia pliku. Próbujemy więc ponownie.

Domain Name: SECUREDOC.CC
Registry Domain ID: 109699115_DOMAIN_CC-VRSN
Registrar WHOIS Server: whois.domainthenet.com
Registrar URL: http://www.DomainTheNet.com
Registrar: DOMAIN THE NET TECHNOLOGIES LTD.
Registrar Abuse Contact Email: abuse@dtnt.com
Registrar Abuse Contact Phone: 972-3-7600500
Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Name Server: NS1.DTNT.INFO
Name Server: NS2.DTNT.INFO
Name Server: NS3.DTNT.INFO
DNSSEC: unsigned

W sumie jest gorzej, bo nazwa producenta w rekordzie whois nie pojawia się nigdzie. Próba połączenia po https:

* About to connect() to securedoc.cc port 443 (#0)
* Trying 62.219.91.45…
* Connection refused
* Failed connect to securedoc.cc:443; Connection refused
* Closing connection 0
curl: (7) Failed connect to securedoc.cc:443; Connection refused

W akcie desperacji pomacaliśmy po http:

HTTP/1.1 301 Moved Permanently
Location: https://ds.checkpoint.com/ds-portal/desktop

Jest! Nareszcie URL, który wygląda przyzwoicie. Jest https, jest nazwa producenta, Certyfikat się zgadza. Ameryka!

Teraz to już z górki…

Teraz wystarczy “tylko” pobrać oprogramowanie, którego nie potrzebujemy, zainstalować na komputerze, na którym użytkownik nie ma uprawnień do instalacji oprogramowania i  wygenerowany sztucznie problem zostanie bohatersko rozwiązany?

Nie wiem, dlaczego akurat taki, a nie inny pomysł. To znaczy jedyna sensowna odpowiedź, to próba “podprogowego” marketingu tego konkretnego produktu. Niestety wykonanie kiepskie, grupa docelowa na taki security theater też sie nie nabiera, a w rezultacie cierpi użytkownik końcowy, który czeka na instrukcje zapisane w tym nieszczęsnym pliku…

Checkpoint jednak (jeszcze) nie migruje do SHA-256

work-in-progress-CC BY-SA 2.0-kevandotorg-on-flickr
CC BY-SA 2.0 https://www.flickr.com/photos/kevandotorg/

Można się było tego spodziewać. O planach Checkpointa dotyczących migracji z SHA-1 do SHA-256 pisałem tutaj. Mój klient otrzymał poprawki na czas na 99% urządzeń, pozostały 1% przejawiał problemy natury filozoficznej (nie poddam się aktualizacji i co mi zrobisz) bądź technicznej (w dniu aktualizacji dysk zdechł). Najwidoczniej jednak znaleźli się użytkownicy, którzy pokpili sprawę. w związku z czym Checkpoint migrację certyfikatów musiał odłożyć w czasie. Póki co do lutego 2016. Żródło: aktualna treść SK103839

“To proactively enhance the security of our online update services, Check Point is planning to gradually migrate its SHA-1 based certificates to SHA-256 based certificates during February 2016.”

Security through obscurity wiecznie żywe

CC BY-NC 2.0 Glen Darrud
CC BY-NC 2.0 Glen Darrud

P.T. Pan Klient zażądał dzisiaj, żeby zablokować skanowanie jego systemów (udostępnionych publicznie usług) przez Shodan. Jako że Shodan nawiązując połączenie niczym szczególnym się nie wyróżnia, to technicznie należaloby to zrealizować blokując ruch z określonej grupy adresów źródłowych (z których Shodan dokonuje skanowania). Podejście to ma masę słabości, poczynając od tego, że Shodan takiej listy nie publikuje, a to co można znaleźć w sieci to zapis pewnego wycinka rzeczywistości w określonej chwili, bez gwarancji, że zebrane adresy będą niezmienne w przyszłości.

Inżynier, który pracował nad tym zgłoszeniem, zrobił dobrą robotę, i zasugerował uszczelnienie polityki firewalla tak, aby tylko rzeczywiście niezbędne zasoby były dostępne publicznie, a także regularne testy bezpieczeństwa, aplikowanie poprawek i innych rozwiązań usuwających ewentualne podatności – zamiast blokowania skanera. Pan Klient jednak wie lepiej, płaci i wymaga, tak więc koniec końców zaimplementowana została reguła blokująca kilkadziesiąt adresów mniej lub bardziej powiązanych z Shodanem. Inne niż Shodan skanery, w tym potencjalni atakujący, mogą dalej prowadzić rekonesans ze swoich (lub cudzych) adresów. Ponieważ rezultatu tych działań nie będzie widać na shodan.io to Pan Klient będzie spał spokojniej, może nawet zmniejszy częstotliwość testów penetracyjnych, a z poczynionych oszczędności ktoś przyzna mu premię.

A kiedy padną ofiarą ataku… winny będzie MSSP, który przegrał zawody w kopaniu się z koniem.

Zasada czystego biurka – clean desk policy

CC BY-NC-SA 2.0 Tal-Bright
CC BY-NC-SA 2.0 Tal Bright

Przemierzałem budynek, w  którym obowiązuje zasada czystego biurka (clean desk policy), a na ścianach co kilka metrów wiszą plakaty przypominające o tym fakcie. Mijając małą salę konferencyjną zobaczyłem stół przygotowany dla trzech osób, na nim dokumenty, a w promieniu kilku metrów nie było żywej duszy. Zdjęcia brak, bo wykonywanie zdjęć było zabronione (ale jak wiadomo, norma prawna zapisana w art. 278 Kodeksu Karnego nie jest respektowana przez złodziei, a intruz niekoniecznie będzie zainteresowany przestrzeganiem polityki bezpieczeństwa).

FireEye, FPC, DLP, IPS i inne słowa kluczowe dobrze sie sprzedają. Niestety najsłabszym ogniwem byli i są ludzie, a nie środki techniczne. Z drugiej strony nie ma lepszej ochrony niż zespół dobrze wyszkolonych, inteligentnych osób.

Ciekawe jak często można pracownikom przeprowadzać szkolenie z podstaw bezpieczeństwa – unikając zmęczenia materiału i mechanicznych odpowiedzi pozbawionych odrobiny refleksji – tak żeby każdy cykl szkoleń zmniejszał liczbę klikniętych linków, otwartych załączników w niezamawianej korespondencji elektronicznej, czy też pozostawionych na biurku przedmiotów.

W tym temacie: ciekawa decyzja administracyjna dotycząca poświadczenia bezpieczeństwa.