canary token

Canary token (honeytoken, potocznie „kanarek”) to fałszywy zasób-pułapka: plik, adres URL, klucz API, konto albo rekord w bazie, którego nikt uprawniony nie ma powodu dotykać. Każde jego użycie wysyła alarm, więc sygnalizuje włamanie albo wyciek danych. Polski blog NF.sec opisuje go jako zasób komputerowy, który istnieje wyłącznie po to, by powiadomić właściciela, gdy ktoś uzyska do niego dostęp ^[5]. Wikipedia nazywa honeytokeny pułapkami typu honeypot, które nie są systemami komputerowymi: ich wartość bierze się z nadużycia, a nie z prawidłowego użycia ^[1].

Jak działa

Mechanizm jest prosty. Obrońca tworzy zasób, który wygląda na cenny, i umieszcza go tam, gdzie zajrzy tylko ktoś niepowołany. Zasób jest powiązany z usługą nasłuchującą. Gdy intruz otworzy dokument, wywoła adres albo spróbuje zalogować się fałszywym kluczem, usługa odnotowuje zdarzenie i wysyła powiadomienie, na przykład e-mailem ^[5].

Dokumentacja serwisu Canarytokens porównuje takie pułapki do czujników ruchu w sieciach, komputerach i chmurach: umieszcza się je tam, gdzie nikt nie powinien grzebać, i dostaje wyraźny alarm, gdy ktoś ich dotknie ^[2]. Najprostszą odmianą jest token HTTP. System wydaje unikalny adres URL, a każda próba jego otwarcia generuje alarm ^[4].

RYS. 1Życie canary tokena

Wartość pułapki polega na niskim odsetku fałszywych alarmów. Skoro zasobu nie używa nikt uprawniony, każde zdarzenie jest podejrzane. Wikipedia zwraca uwagę, że honeytokeny wykrywają zagrożenia, które już ominęły zabezpieczenia obwodowe, czyli działają tam, gdzie zapora sieciowa nie pomoże ^[1].

Rodzaje

Serwis Canarytokens, rozwijany przez firmę Thinkst jako darmowa, uproszczona wersja jej produktu Canary, oferuje ponad 40 typów pułapek ^[2]. Obejmują poświadczenia chmurowe, dokumenty, pułapki sieciowe i typy wyspecjalizowane ^[2]. Usługę można też uruchomić na własnej infrastrukturze ^[5].

Szczególnie użyteczne są fałszywe klucze chmurowe. Dokumentacja zaleca zostawianie ich w prywatnych repozytoriach kodu i na komputerach programistów ^[3]. Plik ma wyglądać jak prawdziwy plik poświadczeń AWS, a alarm przechodzi przez infrastrukturę logowania Amazonu, co może opóźnić go o 2 do 30 minut ^[3]. MITRE D3FEND opisuje pokrewną technikę obronną: poświadczenie utworzone w celu wprowadzenia przeciwnika w błąd, połączone z regułą wykrywania jego użycia ^[6].

W WordPressie

Na stronie WordPress canary tokeny sprawdzają się w miejscach, do których napastnik sięga zaraz po włamaniu. Kilka typowych pułapek:

• Konto-wabik. Nieużywane konto o kuszącej nazwie, na przykład „admin”, z unikalnym hasłem. Dokumentacja ról WordPressa pokazuje, że administrator ma pełną kontrolę nad witryną ^[8], więc takie konto przyciąga ataki siłowe i credential stuffing. Konto nie powinno mieć żadnych uprawnień, a każda próba logowania na nie jest sygnałem. Pułapka nie może stać się prawdziwą furtką.
• Fałszywy klucz w konfiguracji. Klucz chmurowy-pułapka w pliku obok wp-config.php albo w kopii zapasowej. Ktoś, kto wykradł pliki i spróbował użyć klucza, ujawnia wyciek ^[3]. Zob. zaszyte w kodzie hasło.
• Rekord w bazie. Fikcyjny użytkownik albo zamówienie z unikalnym adresem e-mail. Jeśli na ten adres przyjdzie wiadomość, baza wyciekła ^[1].
• Link w dokumencie. Adres-pułapka w pliku, który leży w katalogu uploads i nie jest nigdzie linkowany ^[4].

Pułapki uzupełniają, a nie zastępują, standardowe utwardzanie. Poradnik utwardzania WordPressa zaleca między innymi monitorowanie zmian w systemie plików, czyli nowych i zmodyfikowanych plików, jako sposób wykrycia włamania ^[7]. To samo robi monitorowanie integralności plików. Canary token dodaje sygnał z innej strony: nie z tego, co zmieniono, ale z tego, co ktoś odczytał.

Znaczenie

Canary token jest tanim wskaźnikiem kompromitacji. Nie blokuje ataku, lecz skraca czas, w którym napastnik działa niezauważony. Wikipedia podkreśla, że pozwala ustalić źródło i sposób naruszenia ^[1]. Unikalny token w każdej kopii danych wskazuje, która kopia wyciekła. Przykładem są fałszywe rekordy medyczne z odrębnymi identyfikatorami w różnych miejscach bazy ^[1].

Alarm z pułapki to początek, nie koniec pracy. Powinien trafić do procesu, jakim jest reagowanie na incydenty, a w większych organizacjach do SIEM (Security Information and Event Management) i zespołu SOC (Security Operations Center). Po alarmie trzeba ustalić, skąd pochodził dostęp, i sprawdzić, czy nie doszło do eksfiltracji danych.

Dobre praktyki

• Umieszczać pułapki tam, gdzie zajrzy napastnik, a nie użytkownik: repozytoria, kopie zapasowe, katalogi konfiguracji ^[3].
• Nadawać każdej pułapce unikalny identyfikator i spisywać, gdzie leży, by alarm od razu wskazywał miejsce.
• Dbać o wiarygodność. D3FEND zaznacza, że środowisko wabików wymaga stałego utrzymania, by pozostało autentyczne ^[6].
• Nie dawać pułapkom realnych uprawnień: konto-wabik bez roli, klucz bez dostępu do czegokolwiek.
• Kierować alarmy do osoby albo systemu, który na nie odpowie; pułapka, której alarmu nikt nie czyta, nie ma wartości.

Historia i przykłady

Według Wikipedii termin „honeytoken” zaproponował Augusto Paes de Barros 21 lutego 2003 roku w wiadomości na liście dyskusyjnej publikowanej w Seclists.org ^[1]. Ta sama publikacja wymienia wczesne zastosowania: fałszywe adresy e-mail na listach mailingowych, pozwalające wykryć przejęcie listy, oraz fikcyjne rekordy w bazach danych ^[1]. Pojęcie jest spokrewnione z wartościami „canary” używanymi w ochronie stosu, z tą różnicą, że dotyczy danych, a nie zasobów systemu ^[1]. Popularność określenia „canary token” wiąże się z bezpłatnym serwisem Canarytokens firmy Thinkst ^[2], opisywanym też w polskich blogach branżowych ^[5].