Blokujący komunikatory internetowe administratorzy są przekonani, że panują nad sytuacją. Czy aby na pewno?

W wielu firmach oglądane strony WWW oraz poczta podlegają monitorowaniu. Pracowników interesuje tymczasem zachowanie choćby odrobiny prywatności. Na tym tle toczy się nieustanna wojna o to, kto przechytrzy kogo. Administratorzy bezpieczeństwa blokują popularne komunikatory, ale użytkownicy uczą się niespostrzeżenie obchodzić zasieki. Pomysłowość niektórych "sztuczek" budzi podziw, ale prowadzi do wniosku, że bezpieczeństwo informacji nie jest w stanie, w jakim być powinno.

Pozorny spokój

Najpopularniejszą metodą ochrony prywatności jest użycie tunelowania SSH, które bardzo skutecznie szyfruje połączenie. Scenariusz użycia zakłada uruchomienie klienta SSH, np. Putty, ustawionego tak, by połączenia na lokalny port były tunelowane wewnątrz SSH na maszynę docelową, gdzie jest serwer pośredniczący w3cache pracujący na porcie 22, ale równie dobrze na każdym innym. Co ciekawe, w Polsce są już firmy oferujące (odpłatnie) konto na takim serwerze.

Pomysłów na prywatność jest jednak znacznie, znacznie więcej. Jeden z trików polega na tworzeniu szyfrowanych tuneli za pośrednictwem całkowicie otwartych poleceń HTTP GET i POST na porcie 80. Dane są wysyłane i odbierane poprzez niby-obrazki i z zewnątrz ruch taki trudno odróżnić od normalnej aktywności przeglądarki. Komunikacją i "opakowywaniem" danych steruje niewielki aplet Java uruchamiany w przeglądarce.

Pracownicy korzystają także z płatnych serwisów, które w ramach "legalnej" witryny, ale np. w oddzielnej ramce, wyświetlają zawartość strony docelowej dostarczanej użytkownikowi przez szyfrowany tunel SSL. Inną metodą jest posługiwanie się tunelami IP-over-ICMP. Takie zabiegi są dość trudne do wykrycia, bo niewielu administratorów monitoruje ruch ICMP. Niektórzy użytkownicy posiadają konta na zdalnych serwerach terminalowych albo używają ultraVNC do łączenia się z komputerem domowym.

Do uwolnienia się od czujnego spojrzenia "wielkiego brata" można posłużyć się programami obecnymi w każdym biurze, zwłaszcza tymi wykorzystującymi skryptowe języki programowania. Niejedno duże biuro projektowe korzystające z AutoCAD było "wyposażone" w system umożliwiający wymianę wiadomości na żywo między pracownikami kreślącymi rysunki w tym programie. Mały, lokalny komunikator sieciowy został dawno temu stworzony w języku skryptowym AutoLISP.

Studenci, korzystający ze znakomitego edytora tekstu dla programisty - EMACS, mogą korzystać z klienta rozmów IRC. Wystarczy załadowanie odpowiedniego skryptu. Podobnie obsługa poczty systemów Unix, która w EMACS jest od dawna. Wielu administratorów nie zdaje sobie sprawy z potęgi języków skryptowych. Umiejętnie użyte mogą być znakomitą pomocą, ale jednocześnie bardzo poważnym zagrożeniem bezpieczeństwa. Najlepszym przykładem są skrypty dostępne w pakiecie Microsoft Office.

Ze względu na popularność aplikacji Microsoftu pojawiły się na rynku programy działające wewnątrz Excela, napisane w języku VBA. Ich zastosowania są bardzo różne, od narzędzi wspomagających sam arkusz, np. wpisywanie kwot "słownie", po skomplikowane narzędzia analityczne. Niemniej w języku VBA można napisać komunikator i w ten sposób obejść ograniczenia. W Internecie można znaleźć specjalnie przygotowany arkusz, który jest klientem korzystającym z bardzo dobrego protokołu komunikacyjnego - Jabber. Dzięki skonfigurowanemu transportowi do najpopularniejszych w Polsce komercyjnych komunikatorów Gadu-Gadu i Tlen.pl do znajomych można pisać wprost z projektu bilansu...

Komunikator w Excelu

Uruchomienie programu w Excelu jest kwestią chwili. Może nie jest zbyt wygodny, ale na pierwszy rzut oka trudno powiedzieć, czy pracownik wykonuje normalne zadania w Excelu, czy też, wypełniając komórki tekstem, rozmawia ze znajomymi. Obok zasadniczej części arkusza można przecież umieścić prawdziwe dane i wykresy (patrz ilustracja poniżej). Excel łączy się z Internetem poprzez interfejs loopback, wymaga więc aplikacji pośredniczącej posługującej się popularnym tunelowaniem SSH na porcie 443.

Dzięki temu połączenie jest podobne do typowej komunikacji szyfrowanej za pomocą SSL i nie wywołuje alarmów przy standardowych ustawieniach firewalla. Konto dostępowe do "serwisu tunelowego" jest płatne, niemniej i to, jak się okazuje, da się obejść. Istnieje zresztą wersja arkusza, która nie wykorzystuje proxy ani tunelu, ale za to nie wymaga uruchamiania czegokolwiek poza Excelem i nie wymaga opłat. Wykrycie takiego programu nie jest łatwe. Wszystkie połączenia internetowe wykonuje niewzbudzająca podejrzeń aplikacja Excel.exe. Przy odpowiedniej konstrukcji makropolecenia połączenia są nie do odróżnienia od tych, jakie wykonuje Excel przy wklejaniu do arkusza danych z przeglądarki.

Modelowa aplikacja skryptowa nie wykonuje połączeń poza maszynę, na której jest uruchomiona. To zadanie wykonuje inny program, który tuneluje połączenie do serwera pośredniczącego. W takim przypadku system wykrywania intruzów instalowany na tym komputerze wykryje połączenie Excela kierowane na interfejs loopback - tak jak przy wykonywaniu poleceń kopiuj-wklej z przeglądarki.

Drugie połączenie również zostanie zarejestrowane, ale istnieją aplikacje, które dokonują tunelowania za pomocą podpisanej kontrolki ActiveX albo aplikacji w Javie uruchamianych z przeglądarki internetowej (np. klient Nokia NSAS). W takim przypadku hybrydowy system wykrywania włamań zapisze połączenia z przeglądarki do Internetu. Połączenie docelowe może być szyfrowane za pomocą SSL, a poza tym komunikator wysyła niewiele danych, zatem analiza ruchu raczej nie da powodów do alarmu.

Wyłączyć nie sposób

Chociaż szkodliwość programu dla firmy nie jest wielka, jego istnienie powinno być sygnałem ostrzegawczym dla osób odpowiedzialnych za bezpieczeństwo. Ryzyko niekontrolowanego wycieku poufnych informacji jest bardzo duże. Oprogramowanie antywirusowe jest zazwyczaj konfigurowane tak, by reagowało na konkretne funkcje lub fragmenty kodu VBA. Na razie na wspomniane arkusze nie reaguje.

Wielu użytkowników pozwala też na włączanie makr, nawet jeśli nie zna autora arkusza. Wątpliwe jest, by administracyjne wyłączenie obsługi makropoleceń było możliwe - taki zabieg zbyt wielu osobom utrudniłby normalną pracę. Ważną rolę pełni więc edukacja użytkowników i wpojenie im współodpowiedzialności za bezpieczeństwo.