Pierwsze wirusy komputerowe: jak wyglądało cyberbezpieczeństwo w latach 80.

Jak wyglądał świat komputerów w latach 80.

Komputery jako sprzęt dla nielicznych

W latach 80. komputer w domu był czymś między gadżetem dla pasjonata a luksusem. Zdecydowaną większość maszyn można było znaleźć na uczelniach, w dużych korporacjach, instytutach badawczych i urzędach. Użytkownik domowy to najczęściej uczeń, student, inżynier albo zapalony hobbysta, który kupił Commodore, Atari czy ZX Spectrum z oszczędności – trochę jak ktoś, kto dziś składa sobie własny serwer w domu.

Internet, w dzisiejszym rozumieniu, nie istniał. Były za to sieci akademickie (ARPANET, później NSFNET), różne sieci firmowe i systemy komunikacji oparte na modemach i liniach telefonicznych. Zwykły użytkownik, jeśli w ogóle łączył się z czymś na zewnątrz, dzwonił modemem na lokalny BBS (Bulletin Board System) albo do serwera uczelnianego. Połączenia były drogie, wolne (300–2400 bps) i niestabilne.

Cyberbezpieczeństwo w takim świecie miało zupełnie inny wymiar. Głównym ryzykiem nie był ktoś z drugiego końca globu, tylko kolega z pokoju obok, który mógł podejść do tej samej maszyny. Z tego powodu wiele zabezpieczeń dotyczyło raczej fizycznego dostępu niż oprogramowania.

Popularne platformy i systemy operacyjne

Świat komputerów lat 80. był o wiele bardziej zróżnicowany niż obecnie. Z jednej strony funkcjonowały potężne mainframe’y i minikomputery (IBM, DEC, VAX), z drugiej – dynamicznie rozwijający się rynek komputerów osobistych.

Najpopularniejsze platformy PC to m.in.:

• IBM PC i kompatybilne – pracujące głównie na MS-DOS lub PC-DOS; to właśnie ten ekosystem stał się ulubionym celem pierwszych wirusów plikowych i boot-sectorowych.
• Apple II i późniejsze Macintoshe – bardziej zamknięty ekosystem, inne architektury dysków i systemów plików, przez co wirusy rozprzestrzeniały się tu inaczej i wolniej.
• Komputery 8-bitowe (Commodore 64, Atari, ZX Spectrum, Amstrad) – często bez dysków, z kasetami magnetofonowymi jako nośnikiem, co utrudniało klasycznemu wirusowi automatyczną replikację.

Systemy operacyjne były proste w porównaniu z dzisiejszymi. MS-DOS to w zasadzie powłoka nad systemem plików i kilkoma usługami. Brak kont użytkowników, brak rozdzielenia uprawnień, brak ochrony pamięci. Program, który się uruchamiał, dostał w praktyce pełną władzę nad komputerem.

Na uczelniach i w firmach działały wczesne systemy Unix na minikomputerach (np. SunOS, BSD). Tam już istniał podział na użytkowników, procesy, pliki z uprawnieniami, ale i tak nikt nie zakładał masowego, złośliwego oprogramowania – raczej nieostrożnych użytkowników, błędy i czasem „psikusy” programistów.

Model pracy: dyskietki, BBS-y i fizyczna wymiana danych

Jeśli dziś wszystko dzieje się w chmurze, to w latach 80. „chmurą” była torba z dyskietkami. Oprogramowanie przenosiło się fizycznie: z biura do domu, między znajomymi w klubie komputerowym, od kolegi z uczelni. Dyskietki 5,25 cala (a później 3,5 cala) były tanie, lekkie i niezwykle wygodne – ale też idealne do przenoszenia czegokolwiek, w tym pierwszych wirusów komputerowych.

Modemy i BBS-y odgrywały rolę dzisiejszych serwisów z plikami czy forów. Można było:

• ściągnąć programy i gry (często nielegalnie kopiowane),
• wymienić się wiadomościami z innymi użytkownikami,
• korzystać z prostych usług, jak tablice ogłoszeniowe czy grupy dyskusyjne.

Ten model wymiany oznaczał, że każda dyskietka była potencjalnym „pendrive’em z niespodzianką”. Nikt jeszcze nie spodziewał się, że dyskietka może przenosić świadomie napisany, złośliwy kod. Awaria? Tak. Błąd kopiowania? Owszem. Wirus z intencją powielania się? To dla większości użytkowników brzmiało abstrakcyjnie.

Dlaczego mało kto myślał wtedy o bezpieczeństwie

Priorytetem lat 80. była funkcjonalność i dostępność, a nie bezpieczeństwo. Komputer miał działać, uruchamiać oprogramowanie i pozwalać na eksperymenty. Programiści cieszyli się, że da się coś w ogóle zrobić w dostępnej ilości pamięci, a nie zastanawiali się nad tym, czy ktoś będzie próbował tę pamięć złośliwie nadpisać.

Wiele decyzji projektowych z tamtego czasu – brak izolacji użytkowników, bezpośredni dostęp do sprzętu, swoboda modyfikacji sektorów dysku – wynikało z prostoty i ograniczeń sprzętowych. Ochrona byłaby „kosztownym luksusem”. Efekt uboczny: systemy były otwarte jak dom w małej wsi bez zamków w drzwiach. Nikt nie spodziewał się złodziei, więc nikt nie montował kłódek.

Dopiero pojawienie się pierwszych wirusów komputerowych i robaków sieciowych uświadomiło branży, że otwarte drzwi kuszą nie tylko ciekawskich, ale też osoby o mniej niewinnych zamiarach.

Narodziny koncepcji wirusa komputerowego

Teoretyczne korzenie: von Neumann i samoreplikujący się kod

Idea programu, który potrafi tworzyć własne kopie, nie wzięła się znikąd. Już w latach 40. John von Neumann opisywał w teorii automaty samoreplikujące – abstrakcyjne maszyny, które potrafią odtwarzać samych siebie. Koncepcja ta została przeniesiona na grunt informatyki w latach 60. i 70., gdy zaczęto bawić się programami, które kopiują własny kod w pamięci.

W środowiskach akademickich pojawiały się doświadczenia, w których kilka programów „walczyło” o zasoby maszyny. Każdy próbował się skopiować i „wypchnąć” inne. To były raczej gry laboratoryjne niż świadome tworzenie złośliwego oprogramowania, ale zasada była ta sama: kod jako coś, co może się rozprzestrzeniać.

Od żartów w laboratoriach do zagrożeń poza uczelniami

W zamkniętych sieciach uczelnianych programy samoreplikujące się funkcjonowały czasem jako żarty. Ktoś pisał skrypt, który powielał się w katalogach innych użytkowników, spowalniając system, a potem wszyscy wspólnie szukali sposobu, jak go zatrzymać. To była część kultury eksperymentowania.

Problem zaczął się wtedy, gdy podobne podejście przedostało się do świata komputerów osobistych i firmowych. Połączenie trzech elementów okazało się wybuchowe:

• łatwego dostępu do niskopoziomowych operacji na dyskach,
• braku świadomości zagrożeń wśród użytkowników,
• chęci popisania się umiejętnościami programistycznymi.

Tak narodziły się pierwsze wirusy komputerowe w dzisiejszym znaczeniu: programy, które potrafiły zarażać inne pliki lub sektory dysku i przenosić się między maszynami bez zgody użytkownika.

Wirus, robak, koń trojański – proste rozróżnienia

W latach 80. terminologia dopiero się kształtowała. Do dziś wiele osób używa słowa „wirus” na każde złośliwe oprogramowanie, ale technicznie rzecz biorąc, istnieją istotne różnice:

• Wirus – przyczepia się do innego pliku lub sektora dysku (np. sektora rozruchowego). Aktywuje się, gdy uruchomiony zostanie zarażony program lub gdy komputer startuje z zainfekowanego nośnika. Potrzebuje „gospodarza”.
• Robak (worm) – samodzielny program, który rozprzestrzenia się głównie przez sieć. Nie musi „podczepiać się” do istniejących plików; sam się rozsyła (np. przez luki w usługach sieciowych).
• Koń trojański – program udający coś użytecznego (np. grę, narzędzie), w rzeczywistości wykonujący złośliwe działania. Nie musi się sam powielać; rozprzestrzenia się przez to, że użytkownicy go instalują.

W latach 80. wirusy dotyczyły głównie komputerów osobistych i dyskietek, robaki – sieci akademickich i serwerów Unix, a konie trojańskie były często po prostu zmodyfikowanymi programami, mającymi w sobie „niespodziankę” od autora.

Dyskusje etyczne: czy wolno pisać wirusy „dla nauki”

Gdy pierwsze wirusy komputerowe trafiły do mediów, wywołały spore poruszenie. W środowiskach akademickich zaczęto się zastanawiać, czy tworzenie takiego oprogramowania w celach badawczych jest dopuszczalne. Pojawiały się argumenty:

• „Trzeba rozumieć wirusy, aby umieć się przed nimi bronić.”
• „Publikowanie kodu wirusa to zaproszenie dla osób, które wykorzystają go w złych celach.”

Niektórzy badacze starali się więc opisywać mechanizmy, a nie publikować gotowy kod. Inni uważali, że pełna jawność przyspieszy rozwój narzędzi ochronnych. To napięcie istnieje do dziś, ale w latach 80. było czymś nowym, tak jak całe pojęcie cyberbezpieczeństwa.

Wraz z pierwszymi wyrokami sądowymi za tworzenie i rozprzestrzenianie malware granica między nauką a przestępstwem zaczęła się klarować: można badać, ale nie wolno puszczać w świat kodu, który realnie szkodzi użytkownikom.

Pierwsze znane wirusy na komputery osobiste

Brain (1986) – pakistański wirus od sektora rozruchowego

Za jeden z pierwszych szeroko znanych wirusów na komputery osobiste uchodzi Brain, wykryty w 1986 roku. Stworzyli go dwaj bracia z Pakistanu – Basit i Amjad Farooq Alvi. Co ciekawe, prowadzili oni legalną firmę komputerową i początkowo twierdzili, że Brain miał chronić ich oprogramowanie przed piractwem.

Brain infekował sektor rozruchowy dyskietki (boot sector). Kiedy użytkownik startował komputer z zainfekowanej dyskietki, wirus ładował się do pamięci, a następnie „zarażał” kolejne dyskietki, które były wkładane do napędu. Kod wirusa zawierał dane kontaktowe twórców – adres i numer telefonu w Pakistanie – co dziś brzmi niemal niewiarygodnie.

Mechanizm był prosty: po uruchomieniu zmieniał tablicę alokacji plików (FAT), przekierowując odwołania do zainfekowanego sektora. Zainfekowana dyskietka wciąż działała, ale jej sektor rozruchowy zawierał teraz Brain. Użytkownik nie widział problemu, dopóki wirus nie zaczął powodować błędów lub spowalniać pracy.

Vienna, Cascade, Jerusalem – wczesna „klasyka” wirusów DOS

Po Brainie pojawiła się cała fala wirusów na system MS-DOS. Do najbardziej znanych należą:

• Vienna – jeden z pierwszych wirusów plikowych na DOS. Infekował pliki COM, dodając swój kod na końcu pliku i modyfikując nagłówek tak, by przy uruchomieniu program skakał najpierw do wirusa. Co jakiś czas losowo kasował pliki.
• Cascade – oprócz infekcji plików COM słynął z efektu wizualnego: „spadających” liter na ekranie, które wyglądały jak opadający śnieg znaków. Ten „efekt specjalny” sprawiał, że użytkownicy zauważali infekcję, ale często dopiero po tym, jak wirus zdążył się rozprzestrzenić.
• Jerusalem – wykryty po raz pierwszy na Uniwersytecie Hebrajskim w Jerozolimie. Zainfekowane pliki EXE i COM rosły, powodując po pewnym czasie brak miejsca na dysku. Wirus miał też „ładunek” aktywowany w piątki trzynastego – kasował wtedy programy podczas ich uruchamiania.

Wspólne cechy tych wirusów to:

• działanie na poziomie plików wykonywalnych DOS (COM, EXE),
• brak zaawansowanego ukrywania – pliki często „puchły”, można było zauważyć zmiany rozmiaru,
• efekty uboczne od lekkich psikusów po realne niszczenie danych.

Dość często autorów napędzała mieszanka ciekawości, chęci zaznaczenia swojej obecności („podpisy” w kodzie) i zabawy, a nie bezpośrednie korzyści finansowe. W latach 80. trudno jeszcze mówić o przemysłowej cyberprzestępczości.

Jak wyglądała typowa infekcja przez „pożyczoną” dyskietkę

Wyobraźmy sobie typowy scenariusz z 1987 roku. Pracownik biura pożycza od kolegi dyskietkę z programem do księgowości lub grą. W domu wkłada dyskietkę do stacji, startuje komputer z twardego dysku, uruchamia program. W tle wczytuje się również kod wirusa – na przykład wirus plikowy typu Jerusalem.

Od jednego komputera do całego biura

Po pierwszym uruchomieniu z „pożyczonej” dyskietki wirus pozostawał w pamięci operacyjnej. Użytkownik kończył pracę z programem, wyjmował dyskietkę, następnie włączał swój ulubiony edytor tekstu albo aplikację do fakturowania. Każde takie uruchomienie było dla wirusa okazją, by dopisać swój kod do kolejnych plików COM lub EXE.

Po kilku dniach większość najczęściej używanych programów na dysku lokalnym była już zainfekowana. Gdy ktoś kopiował je na inną dyskietkę, by zanieść do domu, do klienta albo do działu obok – przenosił również wirusa. Tak jak ksero powielało błędy w oryginale, tak kopiowanie programów powielało zainfekowany kod.

Po tygodniach takiego „łańcuszka dyskietkowego” okazywało się, że pół firmy ma ten sam problem: programy działają coraz wolniej, czasem pojawiają się błędy we/wy, a miejsca na dysku jakby ubywa szybciej niż dotychczas. Nikt jeszcze nie łączył tego od razu z pożyczoną grą sprzed miesiąca.

Amiga, Atari, Apple – wirusy spoza świata PC

Komputery IBM PC i klony z MS-DOS-em nie były jedynym celem twórców wirusów. W drugiej połowie lat 80. pojawiły się też zagrożenia specyficzne dla innych popularnych platform:

• Amiga – system AmigaOS, z jego wygodnym interfejsem i rozwiniętą grafiką, dorobił się m.in. wirusa Byte Bandit, który infekował sektory rozruchowe dyskietek. Wiele amigowców pamięta również rodzinę wirusów Lamer Exterminator. Infekcja często objawiała się nietypowymi komunikatami lub zawieszaniem się gier.
• Atari ST – także korzystało z dyskietek, więc scena wirusowa nie ominęła i tej platformy. Tu również spotykano się głównie z infekcjami sektorów rozruchowych, które rozchodziły się głównie przez wymianę gier.
• Apple Macintosh – pierwszy masowo opisywany wirus na Maca to Elk Cloner z początku lat 80., pierwotnie na Apple II. Rozprzestrzeniał się przez zainfekowane dyskietki systemowe i wyświetlał żartobliwy wierszyk po określonej liczbie uruchomień.

Każda z tych platform miała własne mechanizmy systemowe, więc autorzy wirusów musieli poznać ich „wnętrzności”: struktury systemu plików, sposób ładowania systemu, obsługę przerwań. To nie były przypadkowe zabawki; często stała za nimi solidna wiedza o konkretnym systemie operacyjnym.

Robak Morrisa i pierwsze globalne ostrzeżenie

Internet, który jeszcze nie był Internetem

Pod koniec lat 80. nie istniał jeszcze dzisiejszy, komercyjny Internet. Funkcjonowały jednak sieci akademickie i rządowe, połączone w coś, co z grubsza przypominało trzon późniejszego Internetu – m.in. ARPANET i jego następców. Korzystali z nich głównie naukowcy, studenci informatyki, wojskowi. Świat zewnętrzny praktycznie nie wiedział, że „tam gdzieś” żyje inna warstwa komunikacji.

W tym środowisku dominowały systemy Unix i jego warianty. Maszyny stały w serwerowniach, w szafach rackowych, a użytkownicy logowali się do nich z terminali tekstowych. Nie było antywirusów, firewalli ani systemów wykrywania włamań – po prostu logowanie hasłem i tyle. Zasada była podobna jak w wypadku wczesnych PC: „wszyscy jesteśmy kolegami, po co się przed sobą zabezpieczać”.

Kim był Robert Tappan Morris

W 1988 roku student Cornell University, Robert Tappan Morris, napisał program, który miał – według późniejszych wyjaśnień – zbadać rozmiar ówczesnego Internetu. Zamierzał puścić w sieć robaka, który łączyłby się z kolejnymi maszynami, instalował swoją kopię, wysyłał informacje zwrotne, a potem spokojnie trwał.

Morris korzystał z kilku ówczesnych technologii Unixowych, m.in. usług finger i sendmail, oraz zaufania opartego na plikach .rhosts i /etc/hosts.equiv, które pozwalały na logowanie się między zaufanymi maszynami bez podawania hasła. Brzmi znajomo? To przodek dzisiejszych „zaufanych relacji” między serwerami, ale wtedy zabezpieczenia były minimalne.

Jak działał robak Morrisa

Robak Morrisa był samodzielnym programem sieciowym. Nie podczepiał się do istniejących plików jak klasyczny wirus, lecz sam się rozsyłał. Jego działanie można streścić w kilku krokach:

• Wykorzystywał znane (choć niezałatane) luki w usługach sieciowych sendmail i finger, co pozwalało mu uruchomić na zdalnej maszynie własny kod bez zgody użytkownika.
• Jeśli nie znajdował podatności, próbował logować się na konta użytkowników metodą słownikową, testując proste hasła.
• Po udanym „włamaniu” kopiował swój kod na nową maszynę i uruchamiał się tam, zaczynając cały proces od nowa.

Co ciekawe, autor przewidział mechanizm, który miał zapobiec łatwemu usuwaniu robaka: nawet jeśli maszyna była już zainfekowana, po pewnym czasie mogła zostać zainfekowana ponownie. Miało to utrudnić administratorom „oszukanie” robaka, że jest obecny, by powstrzymać dalsze próby infekcji.

Ten mechanizm okazał się zgubny – zbyt częste powielanie doprowadziło do lawinowego obciążenia wielu maszyn. Procesy robaka zużywały moc obliczeniową i pamięć, aż systemy zaczynały się dławić, działać skrajnie wolno, a w końcu zawieszać.

Pierwszy „kryzys bezpieczeństwa” sieci

4 listopada 1988 roku administratorzy na uczelniach i w instytucjach rządowych zaczęli zauważać, że ich serwery Unix zachowują się bardzo dziwnie. Obciążenie CPU skakało do 100%, logowanie było utrudnione, systemy odmawiały przyjmowania kolejnych połączeń. Początkowo nikt nie wiedział, co się dzieje – awaria sprzętu? błąd w systemie?

Dość szybko jednak okazało się, że na dziesiątkach, a potem setkach maszyn pojawia się tajemniczy kod zachowujący się w podobny sposób. Zaczęły się gorączkowe telefony między administratorami, wymiana maili (tam, gdzie poczta jeszcze działała), ad hoc powstające zespoły reagowania. Tak naprawdę rodził się pierwszy w historii incydent, który dziś nazwalibyśmy „kryzysem cyberbezpieczeństwa na skalę sieciową”.

Szacunki szkód i liczby zainfekowanych systemów różnią się w zależności od źródła, ale jedno jest pewne: robak Morrisa uświadomił, że otwarte, połączone sieci są podatne na szybkie, automatyczne ataki. To nie był już pojedynczy wirus na dyskietce w jakimś biurze – to była awaria całego ekosystemu połączonych komputerów.

Konsekwencje prawne i narodziny „incident response”

Robert Tappan Morris został namierzony, oskarżony i ostatecznie skazany na podstawie nowego wówczas amerykańskiego prawa dotyczącego nadużyć komputerowych. Wyrok nie był drakoński, ale miał znaczenie symboliczne: po raz pierwszy tak szeroko dyskutowano odpowiedzialność karną za tworzenie i uruchamianie samoreplikującego się kodu.

Drugim skutkiem było powołanie w 1988 roku pierwszego zespołu reagowania na incydenty w sieci – Computer Emergency Response Team (CERT) w Carnegie Mellon University. Ich zadaniem było zbieranie informacji o zagrożeniach, ostrzeganie operatorów sieci i koordynowanie działań naprawczych. Od tej pory bezpieczeństwo sieci przestało być marginesem i trafiło na listę priorytetów administratorów.

Jak działały pierwsze wirusy „od środka”

Prosty, ale sprytny: wirus plikowy na DOS

Typowy wirus plikowy z epoki DOS-u był zaskakująco zwięzły. Często mieścił się w kilkuset bajtach lub kilku kilobajtach kodu w asemblerze. Składał się z kilku kluczowych elementów:

• Procedury infekującej – otwierała wskazany plik wykonywalny (COM, EXE), sprawdzała, czy nie jest już zainfekowany (np. po sygnaturze w nagłówku), a następnie dopisywała własny kod i modyfikowała punkt wejścia programu, by po uruchomieniu najpierw startował wirus.
• Części rezydentnej – po pierwszym uruchomieniu wirus instalował się w pamięci i „podpinał” pod przerwania DOS-u, np. INT 21h (funkcje usług systemowych) albo INT 13h (obsługa dysków). Dzięki temu przechwytywał operacje na plikach i dyskach, dorzucając infekcję w tle.
• Ładunku (payload) – to była widoczna „twarz” wirusa: wyświetlanie komunikatu, psucie danych, efekt graficzny. Często aktywował się po określonej dacie albo liczbie uruchomień.

Dobry autor wirusa dbał o to, by zarażone programy nadal działały. W przeciwnym razie użytkownicy szybko zauważaliby problem i wymieniali dyskietki lub instalowali kopie zapasowe. Wirus miał być trochę jak nieproszony lokator: korzystać z zasobów, ale nie demolować mieszkania zbyt szybko.

Infection by design: przechwytywanie przerwań

Serce wielu wczesnych wirusów DOS-owych tkwiło w mechanizmie przerwań. W uproszczeniu: aby wykonać operację systemową, program wywoływał odpowiednie przerwanie, np. INT 21h z konkretną funkcją (otwórz plik, zapisz plik, itp.). Informacje o tym, jaki kod ma obsłużyć dane przerwanie, były zapisane w tablicy wektorów przerwań na samym początku pamięci.

Wirus rezydentny robił bardzo prostą sztuczkę:

1. Zapamiętywał oryginalny adres obsługi przerwania.
2. Podmieniał wpis w tablicy wektorów na swój adres.
3. Gdy program wołał o usługę DOS-u, sterowanie trafiało najpierw do wirusa. Ten decydował, czy „zainfekować” dany plik lub dysk, po czym przekazywał wykonanie dalej – do oryginalnej procedury systemowej.

Efekt był taki, że z punktu widzenia użytkownika wszystko działało normalnie: pliki się kopiowały, programy otwierały, dyskietki formatowały. Tyle że po drodze wirus doklejał się tam, gdzie chciał. Ten sam trik stosowały później niektóre programy ochronne, instalując swoje moduły monitorujące w podobny sposób.

Wirusy sektora rozruchowego: „pierwszy po BIOS-ie”

Innym popularnym rozwiązaniem były wirusy infekujące sektor rozruchowy dysku lub dyskietki. Komputer z epoki PC-AT po włączeniu wykonywał następującą sekwencję:

1. BIOS wykonywał testy sprzętu (POST).
2. Następnie odczytywał z wybranego dysku (twardego lub dyskietki) pierwszy sektor – tzw. boot sector lub MBR – i przekazywał mu sterowanie.
3. Ten mały program ładował resztę systemu operacyjnego (np. DOS) z kolejnych sektorów.

Wirus rozruchowy zastępował oryginalny boot sector własnym kodem. Przy starcie komputera to on był uruchamiany jako pierwszy. Jego zadanie było dwojakie: po pierwsze, załadować się do pamięci i przejąć kontrolę nad operacjami dyskowymi, a po drugie – wczytać oryginalny boot sector i przekazać mu sterowanie, aby system mógł się normalnie uruchomić.

Dzięki temu użytkownik niczego nie podejrzewał, a wirus miał idealną pozycję, by infekować kolejne dyskietki wkładane do napędu. Wystarczyło, że ktoś uruchomił komputer z zainfekowanej dyskietki choć raz, a wirus „przenosił się” na dysk twardy i z niego dalej rozsiewał infekcję.

Polimorfizm i zaczątki technik ukrywania

Choć większość wczesnych wirusów była stosunkowo prosta, pod koniec lat 80. pojawiły się już pierwsze próby utrudnienia ich wykrywania. Tak narodziły się wirusy polimorficzne, których kod zmieniał się przy każdej infekcji.

Podstawowa idea wyglądała tak:

• Wirus składał się z części „roboczej” (zawsze tej samej) oraz z dekryptora, który był generowany na nowo przy każdej infekcji.
• Cały główny kod wirusa był zaszyfrowany prostym szyfrem (np. XOR z losowym kluczem).
• Podczas infekowania nowego pliku wirus losował inny klucz i generował nieco inny dekryptor, np. z dodatkowymi instrukcjami, które nic nie robiły (tzw. junk code).

Proste antywirusy kontra polimorfizm

Najwcześniejsze skanery antywirusowe działały jak „psie nosy” wyszkolone na konkretny zapach. Szukały sygnatur – krótkich, charakterystycznych sekwencji bajtów w plikach lub sektorach dysku. Jeśli wzorzec się zgadzał, program ogłaszał: „mamy infekcję”. Taki mechanizm był szybki i skuteczny na pierwsze, statyczne wirusy.

Polimorfizm mieszał im szyki. Skoro przy każdym zarażeniu zmieniał się kod dekryptora, to klasyczna sygnatura przestawała być pewna. Producenci antywirusów zaczęli więc dodawać bardziej wyrafinowane techniki:

• Emulację – skaner uruchamiał podejrzany fragment kodu w kontrolowanym, wirtualnym środowisku i czekał, aż wirus sam się „odszyfruje”. Dopiero wtedy sprawdzał, czy w pamięci nie pojawił się znany wzorzec.
• Heurystyki – zamiast szukać konkretnej sekwencji bajtów, analizował zachowanie: np. czy kod próbuje modyfikować sektor rozruchowy, instalować się w tablicy przerwań, dopisywać się do końca wielu plików.

Tak rozpoczął się swoisty wyścig zbrojeń. Autorzy wirusów dodawali kolejne warstwy zaciemniania kodu, antywirusy rozbudowywały emulatory i mechanizmy analizy. Choć skala była wtedy nieporównywalnie mniejsza niż dziś, logika konfliktu pozostała identyczna.

Stealth: kiedy wirus udaje, że go nie ma

Polimorfizm utrudniał złapanie wirusa „na dysku”. Kolejny krok to było ukrywanie się „w locie” – w momencie, gdy system lub użytkownik próbował odczytać zainfekowany plik czy sektor. Tak narodziły się wirusy typu stealth.

Mechanizm był zaskakująco elegancki. Wirus, który przechwytywał przerwania dyskowe lub plikowe, mógł:

1. Rozpoznać, że bieżące żądanie pochodzi z programu antywirusowego lub narzędzia diagnostycznego.
2. Przy takim żądaniu nie zwracać faktycznej zawartości zainfekowanego sektora, tylko „podsunąć” oryginalne dane zachowane gdzieś z boku.
3. Analogicznie, korygować raportowaną długość pliku tak, aby nie było widać, że „urosnął” o kilkaset bajtów z powodu infekcji.

Z punktu widzenia użytkownika wszystko wydawało się w porządku: narzędzie porównujące pliki nie widziało różnic, skanery pracowały na „wyczyszczonym” obrazie. Jedyną wskazówką bywały subtelne anomalie – nietypowe zużycie pamięci, nieco dłuższy czas dostępu do dysku, sporadyczne błędy przy kopiowaniu.

To właśnie te pierwsze wirusy stealth pokazały, że obrona oparta wyłącznie na sprawdzaniu plików na dysku ma swoje granice. Coraz ważniejsze stawało się monitorowanie zachowania systemu i programów.

Cyberbezpieczeństwo zanim tak je nazwano

Administrator jako „człowiek od wszystkiego”

W latach 80. nie było jeszcze wyspecjalizowanych „security engineerów”. Na uczelniach, w instytutach i większych firmach królował administrator systemu – osoba, która jednocześnie:

• instalowała i aktualizowała systemy operacyjne,
• tworzyła konta użytkowników i ustalała uprawnienia,
• naprawiała sprzęt, wymieniała taśmy, dyski i wentylatory,
• była pierwszą linią wsparcia, gdy cokolwiek „przestawało działać”.

Bezpieczeństwo było jednym z wielu zadań, i to nierzadko traktowanym jako kłopotliwy dodatek. Trudno się dziwić: gdy masz na głowie dziesięć innych rzeczy, pokusa ustawienia prostych haseł dla wszystkich lub zostawienia terminali zalogowanych „na stałe” była spora. Jeden z klasycznych obrazków z tamtych czasów to otwarte drzwi do serwerowni i kartka z hasłem root przypięta do monitora – „żeby inni admini mieli łatwiej”.

Proste hasła, otwarte konta, domyślne ustawienia

Z dzisiejszej perspektywy podstawowe praktyki były wręcz beztroskie. Na wielu systemach multiuser standardem były:

• hasła typu „password”, „guest”, „1234”, często niezmieniane latami,
• konta współdzielone przez całe zespoły – jedna nazwa użytkownika dla całego działu,
• brak limitów liczby nieudanych logowań, co czyniło ataki słownikowe banalnymi,
• pozostawianie sesji zalogowanych na terminalach, bo „i tak tylko my tu chodzimy”.

Na komputerach osobistych było jeszcze luźniej. PC w biurze zwykle uruchamiał się prosto do DOS-u lub innego systemu, bez ekranów logowania. Każdy, kto usiadł przy klawiaturze, miał pełną kontrolę nad maszyną i dyskiem. Ochrona fizyczna w postaci zamykanych drzwi była często jedyną linią obrony – jeśli ktoś wszedł do pokoju z komputerem, mógł robić co chciał.

Kopia zapasowa zamiast antywirusa

Zanim pojawiły się pierwsze komercyjne pakiety antywirusowe, podstawową „strategią bezpieczeństwa” była dobra kopia zapasowa. Firmy, które poważniej traktowały dane, inwestowały w: streamer taśmowy, kilka kompletów nośników i procedurę regularnego backupu. Cała reszta ufała szczęściu.

Przy infekcji typowy scenariusz wyglądał następująco: ktoś zauważa, że programy odmawiają posłuszeństwa lub dane są uszkodzone. Pojawia się podejrzenie wirusa. Jeśli istniała świeża kopia zapasowa, administrator formatował dysk, instalował system od nowa i przywracał dane z taśmy czy dyskietek. Gdy zapasów nie było – trzeba było ratować, co się da, ręcznie.

Takie podejście miało jedną zaletę: uczyło pokory. Kto raz stracił kilka dni pracy przez brak backupu, zazwyczaj zaczynał robić kopie znacznie częściej. Z drugiej strony, brak narzędzi do analizy i usuwania infekcji powodował, że wielu użytkowników nawet nie zdawało sobie sprawy, że ich systemy były „nosicielami”.

Brak izolacji i zaufanie do oprogramowania

O dzisiejszych mechanizmach typu sandbox, uprawnieniach per aplikacja czy izolacji procesów w kontenerach nikt jeszcze wtedy nie myślał. Systemy operacyjne epoki DOS-u i wczesnych Windows (a na maszynach 8-bitowych jeszcze bardziej) zakładały pełne zaufanie do uruchamianego programu.

Program działający w trybie rzeczywistym na PC miał praktycznie nieograniczony dostęp do pamięci i sprzętu. Mógł nadpisać inny fragment pamięci, podmienić tablicę przerwań, modyfikować sektory dysku z pominięciem systemu plików. To był raj nie tylko dla wirusów, ale też dla wszelkiej maści „sprytnych” narzędzi i demoscenowych cudów, które wyciskały z maszyn ostatnie soki.

Panowało też duże zaufanie do źródeł oprogramowania. Dyskietki z programami krążyły po biurach i uczelniach, kopiowane z rąk do rąk. Ktoś przyniósł „najnowszy edytor tekstu” albo grę z domu? Mało kto zastanawiał się, skąd pochodzi oryginał. Jeśli program działał, był używany. Bez podpisów cyfrowych, reputacji wydawcy czy centralnych repozytoriów trudno było odróżnić legalną kopię od zainfekowanej.

Wczesne programy antywirusowe i „szpitale dyskietkowe”

Pierwsze narzędzia antywirusowe były bardzo wyspecjalizowane. Często tworzyli je pasjonaci – programiści, którzy napotkali konkretny wirus i napisali narzędzie do jego wykrywania oraz usuwania. Tak powstawały małe programiki typu CLEAN-XYZ.EXE, przeznaczone do jednej, dokładnie opisanej infekcji.

Z czasem zaczęły pojawiać się bardziej uniwersalne skanery, które:

• przeglądały kolejne pliki i sektory w poszukiwaniu znanych sygnatur,
• oferowały proste leczenie – przywrócenie oryginalnego nagłówka, usunięcie dopiętego kodu wirusa,
• pozwalały stworzyć „czystą” dyskietkę startową, aby uruchomić komputer bez wczytywania zainfekowanego systemu.

W większych organizacjach wykształcił się nawet rodzaj „szpitala dyskietkowego”. Gdy pracownik podejrzewał infekcję, przynosił swoje nośniki do osoby odpowiedzialnej za IT. Tam dyskietki były skanowane, leczone i dopiero po „odkażeniu” wracały do obiegu. Dla wielu ludzi to był pierwszy kontakt z pojęciem wirusa komputerowego jako realnego, namacalnego zagrożenia, a nie abstrakcyjnej ciekawostki z magazynu.

Edukujące strachy i biurowe legendy

Informacje o wirusach rozchodziły się wtedy w sposób bardzo ludzki: przez opowieści, ostrzeżenia na korytarzu, krótkie notatki na tablicy ogłoszeń. Ktoś usłyszał, że „jakiś wirus kasuje wszystko trzynastego w piątek”, ktoś inny, że „nie wolno wkładać cudzych dyskietek, bo komputer wybuchnie”. Brzmi jak żart, ale takie pół-legendarne historie miały duży wpływ na zachowania.

Strach często bywał przesadzony, lecz działał wychowawczo. Użytkownicy zaczynali:

• pytać, skąd pochodzi dany program,
• ostrożniej korzystać z cudzych nośników,
• zgłaszać podejrzane objawy zamiast je ignorować.

To była bardzo pierwotna, ale skuteczna forma świadomości bezpieczeństwa. Zanim pojawiły się modne hasła i szkolenia, ludzie uczyli się na cudzych wpadkach – dokładnie tak, jak w świecie fizycznym.

Listy mailingowe, BBS-y i pierwsze „centra ostrzegania”

Internet w dzisiejszym rozumieniu dopiero raczkował, ale istniały już listy mailingowe i BBS-y (Bulletin Board Systems), na których administratorzy wymieniali informacje. Gdy pojawiał się nowy wirus, gdzieś na świecie ktoś pisał krótki opis: objawy, sposoby rozpoznania, czasem fragmenty kodu. Inni potwierdzali lub uzupełniali dane.

Z takich nieformalnych kanałów wyrosły późniejsze struktury w rodzaju CERT-ów czy serwisów z bazami sygnatur. Na początku było to jednak bardziej podobne do klubu zapaleńców niż do zorganizowanego centrum reagowania. Mimo to już wtedy kształtowały się pewne nawyki:

• publikowanie ostrzeżeń przed „dzikimi” programami krążącymi po sieciach,
• udostępnianie prostych porad – jak sprawdzić, czy system jest zainfekowany,
• dzielenie się narzędziami naprawczymi i skryptami pomocniczymi.

Jednostkowe incydenty z końca lat 80. pokazały, że bez takiej współpracy walka z samoreplikującym kodem jest znacznie trudniejsza. Z czasem to nieformalne „wymienianie się notatkami” przerodziło się w bardziej sformalizowane procesy, ale fundament powstał właśnie w epoce pierwszych wirusów.