Tirith: nowy „strażnik” terminala blokuje ataki podszywające się pod bezpieczne komendy

Wprowadzenie do problemu / definicja luki

Ataki „imposter” w terminalu żerują na tym, iż człowiek ocenia komendę wzrokiem, a system interpretuje ją w bajtach. W praktyce oznacza to, iż polecenie może wyglądać na bezpieczne, ale zawierać znaki Unicode z innego alfabetu (homoglify), znaki niewidzialne (np. zero-width) albo sekwencje sterujące terminala (ANSI), które zmieniają to, co widzisz.

Klasycznym przykładem jest IDN homograph/homoglyph attack: domena w URL wygląda jak znana („install.example-cli.dev”), ale jeden znak jest np. cyryliczny i prowadzi do serwera atakującego. To dokładnie ten typ problemu, który przeglądarki przez lata „oswoiły” (m.in. poprzez polityki wyświetlania punycode i ostrzeżenia), natomiast terminale przez cały czas potrafią bezrefleksyjnie renderować podejrzane znaki.

W skrócie

• Tirith to otwartoźródłowe, wieloplatformowe narzędzie, które podpina się pod powłokę (m.in. zsh/bash/fish/PowerShell) i analizuje komendy przed wykonaniem, ze szczególnym naciskiem na URL-e wklejane/uruchamiane w terminalu.
• Wykrywa m.in. homoglify/homografy (Unicode lookalikes, punycode, mieszane skrypty), terminal injection (ANSI, bidi overrides, zero-width), wzorce pipe-to-shell (np. curl | bash) oraz próby modyfikacji „dotfiles” (np. ~/.bashrc, ~/.ssh/authorized_keys).
• Z deklaracji autora: analiza jest lokalna, bez telemetrii i bez połączeń sieciowych, a narzut ma być sub-milisekundowy.

Kontekst / historia / powiązania

Homoglify (znaki wyglądające podobnie/identycznie) to temat znany od dawna — szczególnie w obszarze domen międzynarodowych (IDN). IETF standaryzuje sposób kodowania Unicode do ASCII w DNS m.in. przez Punycode, co umożliwia domeny niełacińskie, ale jednocześnie otwiera pole do nadużyć „look-alike”.

Z kolei Unicode Consortium opisuje mechanizmy i modele zagrożeń związane z „confusables” oraz mieszaniem skryptów w UTS #39 (Unicode Security Mechanisms) — to fundament wielu detekcji konfuzji znaków w produktach security.

W praktyce w cyberprzestępczości problem wraca falami:

• w phishingu (URL-e w mailach),
• w supply chain (typosquatting, fałszywe repozytoria),
• oraz coraz częściej w socjotechnice „uruchom tę komendę” (np. w fałszywych instrukcjach, ticketach, pastebinach, „naprawkach” podawanych przez rzekomy support). Tirith celuje właśnie w tę warstwę „między okiem a powłoką”.

Analiza techniczna / szczegóły luki

1) Homograph/homoglyph w URL-ach (Unicode lookalikes, punycode, mixed scripts)

Mechanizm jest banalny: atakujący rejestruje domenę łudząco podobną do prawdziwej, np. przez podstawienie jednego znaku na konfuzowalny (łacińskie „i” vs cyrylickie „і”). Człowiek widzi „to samo”, resolver DNS widzi coś innego.

Tirith ma reguły, które identyfikują m.in.:

• znaki spoza ASCII w hostnames,
• domeny punycode,
• etykiety z mieszanymi skryptami (np. łacina + cyrylica).

2) Terminal injection: ANSI, bidi overrides, znaki zero-width

To bardziej podstępna klasa ataków: nie tylko podszywasz się pod domenę, ale też manipulujesz tym, co terminal wyświetla, aby ukryć fragment komendy lub „przestawić” jej widok (np. przez bidi overrides). To jest ta sama rodzina problemów, która stała za „Trojan Source” (atakami wykorzystującymi adekwatności Unicode do rozjazdu między tym, co widzi człowiek, a tym, co przetwarza parser/kompilator).

3) Pipe-to-shell i „source-to-sink patterns”

Wzorce typu:

• pobierz → wykonaj (curl … | bash, wget … | sh),
• dynamiczna ewaluacja (eval $(…), python <(curl …)),
  są „ulubioną” bramą do kompromitacji, bo redukują czas na refleksję do zera.

Z podejścia Tirith wynika, iż nie wszystko musi być blokowane — część przypadków może być ostrzeżeniem, ale najważniejsze jest, by operator zobaczył ryzyko zanim wciśnie Enter.

4) Dotfile hijacking i ryzyka ekosystemu

Ciekawy element to detekcje skupione na:

• nadpisywaniu ~/.bashrc, ~/.ssh/authorized_keys, ~/.gitconfig (trwała kontrola nad środowiskiem),
• typosquattingu repozytoriów/źródeł,
• podejrzanych rejestrach kontenerów,
• „userinfo” w URL-ach (np. user:pass@host) i shortenerach.

Praktyczne konsekwencje / ryzyko

Dla zespołów Dev/DevOps/SRE największy problem to automatyzm: kopiuj-wklej z dokumentacji, GitHub Issues, Slacka, ticketu, Stack Overflow, a choćby z „fixa” podanego przez rzekomy support. Jedno wklejenie może:

• uruchomić droppera z fałszywej domeny (homoglyph),
• ukryć prawdziwy cel przez znaki niewidzialne lub ANSI,
• dołożyć trwały backdoor przez modyfikację dotfiles,
• wyciągnąć sekrety (tokeny w ENV, SSH agent forwarding, cloud creds),
• zainfekować pipeline (gdy komenda jest odpalana na runnerach CI).

Ważny szczegół praktyczny: wg opisu BleepingComputer, Tirith nie podpina się do cmd.exe, a więc nie „załatwi” wszystkich scenariuszy na Windows, jeżeli atak bazuje na klasycznym Command Prompt.

Rekomendacje operacyjne / co zrobić teraz

1. Wprowadź barierę techniczną w CLI

• Jeśli pracujesz intensywnie w terminalu (dev/ops), rozważ wdrożenie Tirith jako „guard rail” na stacjach roboczych oraz bastionach administracyjnych, szczególnie tam, gdzie często wkleja się komendy.

2. Zmień nawyki wokół „curl | bash”

• Standard: pobierz do pliku → obejrzyj → zweryfikuj sumy/podpis → dopiero uruchom.
• W CI: unikaj dynamicznych install-scriptów z sieci; preferuj wersjonowane artefakty, lockfile, repozytoria o kontrolowanej reputacji.

3. Ogranicz powierzchnię Unicode tam, gdzie to możliwe

• W politykach wewnętrznych (np. dokumentacja) zalecaj kopiowanie komend z repo firmowego, a nie z losowych wątków.
• W narzędziach bezpieczeństwa i review uwzględniaj ryzyka „confusables” (UTS #39).

4. Defense-in-depth

• EDR/AV + kontrola uruchomień (AppLocker/WDAC na Windows, systemy allow-listing na Linux/macOS).
• Minimalne uprawnienia: ogranicz możliwość zapisu do newralgicznych plików (dotfiles) tam, gdzie to realne.
• Separuj konteksty: admin shell vs user shell; osobne profile/VM dla zadań wysokiego ryzyka.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

• Przeglądarki vs terminal: przeglądarki mają „świadomość URL” jako obiektu bezpieczeństwa; terminal jest z założenia „głupi” i renderuje tekst. Tirith próbuje wypełnić tę lukę, dodając analizę ryzyk na etapie wykonywania komendy.
• Trojan Source vs CLI attacks: Trojan Source pokazał, iż Unicode może wprowadzić rozjazd między percepcją a interpretacją w kodzie źródłowym; w CLI stawka jest podobna, tylko skutki bywają natychmiastowe (uruchomienie komendy zamiast „ukrytej intencji”).

Podsumowanie / najważniejsze wnioski

Tirith jest ciekawą odpowiedzią na realny problem: terminal przez cały czas nie ma natywnych mechanizmów obrony przed homografami, znakami niewidzialnymi i częścią wstrzyknięć wizualnych. Podejście „hook w powłoce + lokalna analiza regułowa” może skutecznie zmniejszyć ryzyko incydentu wynikającego z jednego, pechowego copy-paste.

Nie zastąpi to higieny operacyjnej (review skryptów, ograniczanie uprawnień, kontrola uruchomień), ale jako warstwa „ostatniej szansy” przed Enterem — ma sens szczególnie tam, gdzie presja czasu i automatyzmy są codziennością.

Źródła / bibliografia

• BleepingComputer: „New tool blocks imposter attacks disguised as safe commands” (8 lutego 2026). (BleepingComputer)
• Repozytorium projektu Tirith (README, instalacja, kategorie detekcji). (GitHub)
• Unicode Consortium: UTS #39 „Unicode Security Mechanisms” (confusables, mixed-script). (unicode.org)
• IETF: RFC 3492 „Punycode” (IDN/ASCII encoding, kontekst domen międzynarodowych). (datatracker.ietf.org)
• Boucher & Anderson: „Trojan Source: Invisible Vulnerabilities” (Unicode/bidi jako klasa problemu bezpieczeństwa). (arXiv)