Wczesne dyskusje o pierwszych wirusach komputerowych często pomijają podstawowe pytanie: co właściwie liczy się jako wirus. Z technicznego punktu widzenia wirus komputerowy to program lub fragment kodu, który:
sam się powiela – potrafi tworzyć swoje kopie bez ręcznej ingerencji użytkownika,
potrzebuje „gospodarza” – innego programu, pliku, sektora dysku lub systemu operacyjnego, aby się uruchomić,
modyfikuje środowisko – np. dopisuje się do plików, zmienia sektor rozruchowy, wstrzykuje się do pamięci.
Kluczowa cecha to samoreplikacja. Program, który jednorazowo coś uszkadza (np. skasuje katalog po uruchomieniu), jest destrukcyjny, ale nie jest wirusem, jeśli sam się nie rozprzestrzenia. W latach 80. użytkownicy rzadko rozróżniali te niuanse, co rodziło sporo medialnych uproszczeń.
Wirus, robak, trojan – źródło pojęciowego chaosu
W historii „pierwszych wirusów komputerowych” miesza się kilka kategorii szkodliwego oprogramowania. Z perspektywy dzisiejszej terminologii:
Wirus – potrzebuje gospodarza (pliku, sektora dyskietki), zwykle dołącza się do istniejącego kodu lub obszaru pamięci. Rozprzestrzenia się wraz z kopiowaniem zainfekowanych nośników lub plików.
Robak (worm) – jest samodzielnym programem, potrafi rozchodzić się po sieci bez „przyklejania się” do innych plików. Przykład: robak Morrisa z 1988 roku.
Koń trojański (trojan) – udaje coś pożytecznego, a w tle robi coś innego (np. kradnie dane), ale z definicji nie musi się sam kopiować.
Media, zwłaszcza w latach 80. i 90., wrzucały do jednego worka wirusy, robaki, trojany i zwykłe „psikusy” programistyczne. Dlatego w zależności od autora tekstu „pierwszym wirusem” bywały programy, które dzisiejszym językiem należałoby zaliczyć raczej do robaków albo wręcz do testów bezpieczeństwa.
Dlaczego trudno wskazać jeden „pierwszy” wirus komputerowy?
Odpowiedź na pytanie, który wirus był pierwszy, nie jest tak prosta, jak sugerują nagłówki w stylu „pierwszy wirus w historii”. Trudności są co najmniej trzy:
Różne platformy – duże mainframe’y IBM-a, sieci ARPANET, minikomputery w laboratoriach, a potem komputery osobiste. Na każdej z tych platform pojawiały się samoreplikujące się programy w różnym czasie.
Skąpa dokumentacja – pierwsze wirusy często powstawały w nieformalnych środowiskach studenckich lub „garażowych”, bez publikacji naukowych czy oficjalnych raportów. Informacje pochodzą z relacji ustnych lub spóźnionych opisów.
Różnica między teorią a praktyką – koncepcje matematyczne samoreplikujących się automatów istniały od lat 40., ale długo nie miały nic wspólnego z realnymi szkodami w systemach.
Z tego powodu jedni badacze za „pierwszy wirus” uznają laboratoryjny program Creeper na ARPANET, inni wskazują na wirusy z Xerox PARC lub wczesne wirusy na Apple II, a jeszcze inni – na Brain jako pierwszy szeroko opisany dziki wirus na PC. Każda z tych odpowiedzi jest poprawna w swoim wąskim kontekście, ale żadna nie obejmuje całego obrazu.
Granica między teorią a szkodliwą praktyką
Historia wirusów komputerowych ma wyraźny podział na dwa światy:
Świat teoretyczny – prace naukowe, modele matematyczne, gry symulujące „walkę programów” w pamięci,
Świat praktyczny – prawdziwe systemy, prawdziwe dane użytkowników, realne przestoje i straty.
W latach 60. i 70. praktyka była jeszcze bardzo ograniczona do ściśle kontrolowanych środowisk badawczych. Dopiero upowszechnienie komputerów osobistych i sieci akademickich stworzyło warunki do niekontrolowanego rozprzestrzeniania się kodu poza jedną salę laboratoryjną. W tym sensie „era pierwszych wirusów komputerowych” w rozumieniu społecznym zaczyna się naprawdę dopiero w połowie lat 80., chociaż korzeni trzeba szukać dużo wcześniej.
Teoretyczne korzenie: samoreplikujące się programy przed erą PC
John von Neumann i automaty samoreprodukujące
Jednym z pierwszych, którzy na poważnie rozważali ideę programów potrafiących się kopiować, był John von Neumann. W latach 40. i 50. pracował nad teorią automatów komórkowych i konstrukcjami, które potrafią budować swoje własne kopie. Nie interesował go sabotaż komputerów, lecz abstrakcyjne pytanie: czy system formalny może tworzyć swoje potomne systemy o tych samych właściwościach.
Von Neumann opisał to w serii wykładów i prac, zebranych później m.in. w „Theory of Self-Reproducing Automata”. Chodziło o matematyczne modele, które dziś można porównać do uproszczonych „światów” znanych z gier typu Conway’s Game of Life. Żadna z tych prac nie miała kontekstu przestępczego. Raczej wyprzedzały epokę, tworząc teoretyczny fundament dla zrozumienia, że samoreplikacja w systemach informatycznych jest możliwa i przewidywalna.
Wczesne dyskusje o programach kopiujących same siebie
W kolejnych dekadach motyw samoreplikujących się programów pojawiał się w literaturze naukowej i półpopularnej. Były to głównie rozważania:
o optymalizacji kompilatorów i translatorów – programów, które „tworzą” inne programy,
o metaprogramowaniu – kodzie, który modyfikuje samego siebie w czasie działania,
o ryzykach bezpieczeństwa – hipotetycznych scenariuszach, w których program sam się duplikuje i zużywa zasoby systemu.
Ten ostatni wątek z czasem wyrósł w osobną dziedzinę – cyberbezpieczeństwo. W latach 60. i 70. traktowano go jednak raczej jako scenariusz ostrzegawczy niż coś, co realnie się dzieje na serwerach. Z dzisiejszej perspektywy widać, że ostrzeżenia były trafne, ale nie szły w parze z wystarczającą praktyką zabezpieczania systemów.
„Core wars” – gra, która przypomina wirusy, ale nimi nie jest
Istotnym etapem między teorią a późniejszym malware była gra znana jako „Core Wars”. W latach 70. i 80. programiści pisali małe „organizmopodobne” programy zawarte w ograniczonej przestrzeni pamięci – „core”. Celem było zniszczenie przeciwnika lub zdominowanie przestrzeni poprzez kopiowanie swojego kodu i nadpisywanie pamięci rywala.
Kluczowe różnice między „Core Wars” a realnymi wirusami komputerowymi są dwie:
Gra toczy się w zamkniętej, symulowanej pamięci, nie w prawdziwym systemie plików użytkownika.
Uczestnicy dobrowolnie brali udział w rozgrywce, uruchamiając programy na wybranych maszynach.
Mimo to „Core Wars” silnie zainspirowało wielu późniejszych twórców wirusów. Mechanizmy „zagnieżdżania się” w pamięci, kopiowania i walki o zasoby bardzo przypominały to, co później zaczęło dziać się w prawdziwych systemach. Granica między „sportem programistycznym” a eksperymentem o potencjale destrukcyjnym zaczęła się zacierać.
Jak idee samoreplikacji trafiły do środowisk hakerskich
Lata 70. i wczesne 80. to eksplozja kultury hakerskiej na uczelniach technicznych, w klubach komputerowych i pierwszych sieciach BBS. Studenci informatyki, członkowie demosceny, użytkownicy wczesnych systemów Unix mieli swobodny dostęp do kodu źródłowego i dużą autonomię w eksperymentowaniu.
Idee z prac von Neumanna czy „Core Wars” przenikały do tego świata na kilka sposobów:
przez czasopisma techniczne i artykuły o teoriach automatów,
przez krążące po kampusach notatki i materiały dydaktyczne,
przez bezpośrednie kontakty między badaczami a studentami – w niektórych ośrodkach pracowali ramię w ramię nad tym samym sprzętem.
W tym środowisku samoreplikujący się program szybko przestał być abstrakcyjnym tworem matematycznym. Stał się wyzwaniem technicznym: czy da się napisać coś, co bez nadzoru użytkownika będzie „pełzało” po sieci lub kopiowało się z dyskietki na dyskietkę. Motywacja na tym etapie była zwykle mieszanką ciekawości, chęci pokazania się kolegom i poczucia humoru, a nie planem wyrządzenia masowych szkód.
Źródło: Pexels | Autor: cottonbro studio
Creeper, Reaper i ARPANET: prototypy wirusów w laboratoriach
Creeper – żart, eksperyment czy pierwszy robak?
Jednym z najczęściej wymienianych kandydatów do tytułu „pierwszego wirusa komputerowego” jest program Creeper, napisany na początku lat 70. w środowisku ARPANET – protoplaście dzisiejszego Internetu. Creeper był programem działającym na systemach TENEX, który potrafił przenosić się między maszynami w sieci i wyświetlał komunikat:
„I’M THE CREEPER, CATCH ME IF YOU CAN!”
Z dzisiejszej perspektywy Creeper był raczej robakiem niż wirusem – nie przyczepiał się do istniejących plików, lecz jako samodzielny program migrował między komputerami. Co ważne, miał charakter eksperymentalny. Jego autorzy testowali możliwości zdalnego uruchamiania kodu i zarządzania zadaniami w sieci, a nie szykowali atak. Szkody były znikome: irytacja użytkowników i konieczność usuwania programu z zainfekowanych maszyn.
Reaper – pierwszy „antywirus” w historii
W odpowiedzi na Creepera powstał inny program – Reaper. Jego zadaniem było wyszukiwanie instancji Creepera w sieci i usuwanie ich. Z technicznego punktu widzenia Reaper też zachowywał się jak robak: sam przemieszczał się między systemami i wykonywał określone działania na znalezionych zasobach.
Reaper bywa określany jako pierwszy program antywirusowy, choć w momencie powstania nikt tak tego nie nazywał. To raczej naturalna odpowiedź techniczna: skoro jeden program samodzielnie krąży po sieci, można napisać inny, który będzie go śledził i usuwał. To w zarodku pokazuje logikę, która później zdominowała branżę bezpieczeństwa: atak i odpowiedź, wirus i antywirus, robak i łatka.
Badawczy charakter wczesnych eksperymentów na ARPANET
Dla współczesnego czytelnika wychowanego na opowieściach o ransomware i atakach na banki łatwo zinterpretować Creepera jako wczesne „przestępstwo komputerowe”. Taki obraz jest jednak anachroniczny. W latach 70. ARPANET był siecią badawczą, a użytkownicy znali się często osobiście. Programy takie jak Creeper były:
pisane przez badaczy i inżynierów, nie przez zorganizowane grupy przestępcze,
uruchamiane w kontrolowanym środowisku, gdzie operatorzy systemów mieli dostęp do wszystkich maszyn,
elementem eksperymentów z rozproszonymi obliczeniami i zdalnym wykonywaniem kodu.
To nie znaczy, że nie było problemów – zaskoczenie użytkowników, spadek wydajności, niezapowiedziane procesy w tle. Jednak intencja była badawcza. Granica między „testem” a „nadużyciem” była wtedy płynna, bo brakowało formalnych polityk bezpieczeństwa i przepisów prawnych, które dziś wydają się oczywiste.
Czy Creepera można uczciwie nazwać pierwszym wirusem?
Decyzja, czy Creeper był „pierwszym wirusem komputerowym”, zależy od przyjętej definicji:
Jeśli kluczowa jest samoreplikacja – Creeper się kwalifikuje: przenosił się między hostami, tworząc swoje kopie.
Jeśli wymagamy przyczepiania się do gospodarza (pliku, sektora) – Creeper tego nie robił, więc jest „tylko” robakiem.
Jeśli bierzemy pod uwagę skalę i niekontrolowane rozprzestrzenianie – Creeper był ograniczony do środowiska ARPANET i szybko doczekał się Reapera, więc trudno go porównać z późniejszymi epidemiami.
Wirusy w środowiskach uczelnianych: Xerox PARC, eksperymenty i „gry”
Xerox PARC i kultura „zróbmy, bo się da”
W latach 70. i na początku 80. jednym z najbardziej wpływowych ośrodków badawczych był Xerox PARC. To tam powstały podstawy graficznego interfejsu użytkownika, mysz komputerowa czy koncepcja sieci Ethernet. W takim środowisku eksperymenty z oprogramowaniem, które „żyje” w sieci, były niemal naturalnym krokiem.
Badacze mieli ogromną swobodę: dostęp do wielu połączonych ze sobą stacji roboczych, możliwość modyfikowania systemów operacyjnych, brak dzisiejszych barier biurokratycznych. W praktyce oznaczało to, że program samoczynnie przemieszczający się po sieci mógł powstać jako projekt poboczny, czasem nawet jako żart między zespołami.
Źródła z tego okresu opisują m.in. programy, które:
logowały się na inne maszyny w sieci lokalnej, korzystając z domyślnych lub wspólnych haseł,
wysyłały krótkie komunikaty użytkownikowi po drugiej stronie (czasem w formie „psikusów”),
wykorzystywały planowanie zadań, by reagować na obecność konkretnego użytkownika lub godziny pracy.
Nie wszystko da się dziś jednoznacznie sklasyfikować jako wirus czy robak – wiele z tych projektów nie miało trwałego mechanizmu samoreplikacji. Natomiast sposób myślenia był zbliżony: sieć to przestrzeń, w której kod może migrować między hostami i wykonywać czynności poza bezpośrednią kontrolą pojedynczego użytkownika.
„Gry sieciowe” i programy‑pasażerowie na gapę
Na uczelniach technicznych i w ośrodkach badawczych rozwijały się też rozmaite „gry sieciowe” – nie tylko w sensie rozrywki, lecz także jako forma interaktywnego testowania infrastruktury. Były to chociażby:
proste programy‑czaty działające na wielu terminalach,
skrypty losowo wysyłające wiadomości w stylu „ping” do innych użytkowników,
symulacje wieloosobowych gier turowych w środowiskach Unix.
W takim ekosystemie łatwo o sytuację, w której ktoś dopisuje kilka linii kodu, by program kopiował się na inne konto lub maszynę, gdy tylko znajdzie otwarte połączenie. Początkowo bywało to traktowane jako rodzaj współzawodnictwa: czyj program przetrwa dłużej, czyj będzie „bardziej sprytny” w unikaniu wykrycia.
Typowa anegdota z tamtego czasu (znana z opowieści administratorów, nie zawsze dokładnie udokumentowana): student pisze skrypt, który loguje się na konta kolegów przy użyciu domyślnego hasła, wyświetla im komunikat‑niespodziankę, po czym kopiuje siebie do ich katalogu domowego i planuje kolejne uruchomienie przez cron. Z perspektywy dzisiejszego prawa – naruszenie bezpieczeństwa. Wówczas – często uznawane za psikus w granicach tolerancji środowiska, o ile nie powodował strat.
Gdzie kończy się eksperyment, a zaczyna nadużycie?
Granica między „akademicką zabawą” a nadużyciem była płynna. Zależała od lokalnej kultury i niepisanych zasad. Zwykle reagowano dopiero wtedy, gdy program:
zajmował nadmierne zasoby (CPU, pamięć, przestrzeń dyskową),
powodował utratę danych lub wstrzymywał istotne obliczenia,
był uruchamiany na maszynach spoza „grona wtajemniczonych”.
Do dziś trudno jednoznacznie wskazać „pierwszy złośliwy” wirus uczelniany, bo w większości znanych przypadków główną motywacją była ciekawość i rywalizacja, a nie zysk finansowy czy szantaż. Zmiana przyszła dopiero wtedy, gdy technologie akademickie przeniknęły do masowego rynku komputerów osobistych.
Pierwsze wirusy „na wolności”: Apple, Lisa, komputery 8‑bitowe
Domowe komputery jako nowe pole do eksperymentów
Gdy w końcówce lat 70. i na początku 80. komputery osobiste zaczęły trafiać do domów – Apple II, TRS‑80, później maszyny pokroju Commodore 64 czy Atari 8‑bit – dotychczasowy model „zamknięskiego kampusu” przestał być jedyną sceną. Programiści i zaawansowani hobbyści otrzymali nową zabawkę: maszynę w domu, z której oprogramowanie można było kopiować na kasetach magnetofonowych i dyskietkach.
W tym środowisku wczesne wirusy i robaki były często połączeniem:
demonstracji umiejętności (pokazania, że „da się” coś zrobić),
lenistwa lub braku wiedzy użytkowników, którzy korzystali z niesprawdzonych kopii programów,
braku jakiejkolwiek infrastruktury bezpieczeństwa – systemy nie miały uprawnień użytkowników, podpisów cyfrowych ani antywirusów.
Część z tych programów przeszła do historii głównie w formie ustnych przekazów i krótkich wzmianek w czasopismach. Dokumentacja jest fragmentaryczna, dlatego łatwo o przesadę w opowieściach o „pierwszym wirusie na Commodore” czy „legendarnym programie na Apple II, który kasował dyski wszystkim w mieście”.
Apple II: od dem do samoreplikujących się programów
Apple II był szczególnie podatny na eksperymenty. Oferował stosunkowo łatwy dostęp do niskopoziomowych funkcji, posiadał nośniki wymienne (dyskietki), a środowisko użytkowników było silnie powiązane z klubami komputerowymi i sceną dem. W praktyce oznaczało to dużo nieoficjalnego oprogramowania krążącego z ręki do ręki.
Na tym gruncie pojawiły się pierwsze programy samokopiujące się na dyskietkach. Działały zazwyczaj w prosty sposób:
Po uruchomieniu sprawdzały obecność swojego kodu na aktualnej dyskietce.
Jeśli go nie znajdowały, dopisywały własny fragment do sektora startowego lub do jednego z plików wykonywalnych.
Opcjonalnie wyświetlały komunikat (czasem humorystyczny, czasem groźnie brzmiący, lecz bez realnego destrukcyjnego działania).
O ile takie programy potrafiły zirytować użytkowników (spowalniały start systemu, czasem uszkadzały strukturę katalogów), o tyle ich autorzy rzadko mieli intencję faktycznego niszczenia danych. Dla wielu była to forma „sztuki technicznej” – pokazania, że zna się wewnętrzne mechanizmy systemu na tyle dobrze, by zaszyć w nim niewidoczny kawałek kodu.
Lisa i wczesne systemy z GUI
Apple Lisa, poprzednik Macintosha, funkcjonował głównie w środowiskach profesjonalnych, ale i tam pojawiały się eksperymenty z oprogramowaniem ingerującym w system poza wiedzą użytkownika. Wspomina się chociażby programy:
przechwytujące pewne zdarzenia systemowe (np. uruchomienie konkretnego programu) i reagujące nietypowym zachowaniem,
doklejające elementy graficzne lub komunikaty do standardowego interfejsu.
Część z nich można porównać do dzisiejszych „nakładek” lub rozszerzeń systemowych. Inne były bliższe idei wirusa – korzystały z mechanizmów instalacji oprogramowania, by umieścić swój kod we wspólnych bibliotekach lub plikach konfiguracyjnych. Rozprzestrzenianie następowało jednak głównie przez kopiowanie dyskietek między wąskim gronem użytkowników, więc zasięg pozostawał ograniczony.
Ekosystem 8‑bitowy: piractwo, cracki i przypadkowe „pasażerowie”
Na maszynach 8‑bitowych (Commodore, Atari, ZX Spectrum) rozpowszechnił się inny model: masowa wymiana gier i programów w postaci kopiowanych kaset i dyskietek. Królowały gry z crack‑intrem, demka, własne produkcje klubów komputerowych. W takim środowisku nawet prosty samoreplikujący się fragment kodu miał spore szanse na szybkie rozprzestrzenienie.
Wirusy na 8‑bitowcach zazwyczaj:
przyczepiały się do loaderów gier lub sektorów startowych dyskietek,
modifikowały drobne elementy (napisy na ekranie, dźwięki, czasem grafiki),
równo z określonym zdarzeniem (data, liczba uruchomień) wykonywały efekt „specjalny” – od prostego komunikatu po blokadę uruchamiania programów.
Nie zawsze były dziełem „złych hakerów”. Zdarzały się też przypadki, w których ktoś testował technikę samoreplikacji w warunkach lokalnych, a kod „wypłynął” razem z piracką kopią gry i poszedł dalej w świat bez zgody autora. W tamtym środowisku kontrola nad tym, co dzieje się z raz wypuszczonym programem, była praktycznie zerowa.
Źródło: Pexels | Autor: Tima Miroshnichenko
Brain – pierwszy szeroko opisany wirus na PC
Tło: IBM PC staje się standardem
W połowie lat 80. komputery zgodne z IBM PC zaczęły dominować w biurach, a coraz częściej także w domach. Wspólny standard sprzętowy i systemowy (MS‑DOS i jego klony) stworzył coś, czego wcześniej brakowało: globalną, w dużej mierze jednolitą platformę. Dla twórców wirusów to sytuacja idealna – raz napisany kod może działać na tysiącach, a z czasem milionach maszyn.
W tym kontekście pojawia się wirus Brain, który zwykle wskazuje się jako pierwszy powszechnie znany i dobrze udokumentowany wirus na PC. Nie był koniecznie absolutnie „pierwszy w ogóle” na tej platformie, lecz to właśnie on rozpowszechnił się na tyle szeroko, że trafił do prasy, raportów branżowych i świadomości zwykłych użytkowników.
Brain: pakistańska wizytówka w sektorze rozruchowym
Brain pojawił się ok. 1986 roku, a jego autorami byli dwaj bracia z Pakistanu, Basit i Amjad Farooq Alvi, prowadzący firmę komputerową w Lahore. Wirus infekował sektory rozruchowe dyskietek 360 KB dla systemu MS‑DOS. Mechanizm działania był stosunkowo prosty:
Po włożeniu zainfekowanej dyskietki i uruchomieniu z niej komputera wirus ładował się do pamięci.
Następnie przechwytywał żądania dostępu do dyskietki, by przy każdym kopiowaniu zainfekować jej sektor rozruchowy.
Oryginalny sektor rozruchowy był przenoszony w inne miejsce na dyskietce, tak aby system pozornie działał normalnie.
Najciekawszym elementem była jednak „wizytówka” zaszyta w kodzie. Po zbadaniu sektora rozruchowego można było odczytać tekst zawierający m.in. nazwy autorów, ich adres w Lahore i numer telefonu. W komunikacie pojawiały się sugestie, że program ma chronić przed piractwem oprogramowania, a po wykryciu infekcji należy się z nimi skontaktować.
Czy Brain był wirusem „antypirackim”? Motywacje autorów
Bracia Alvi utrzymywali, że stworzyli Brain jako rodzaj „znaku wodnego” i zabezpieczenia dla sprzedawanego przez siebie oprogramowania medycznego – miał rzekomo pojawiać się wyłącznie na nieautoryzowanych kopiach. Rzeczywistość okazała się inna: wirus nie miał skutecznych mechanizmów ograniczających zasięg, więc zaczął się rozprzestrzeniać szeroko, niezależnie od legalności oprogramowania.
Motywacja twórców pozostaje częściowo sporna:
z jednej strony wpis w sektorze rozruchowym z prawdziwymi danymi kontaktowymi sugeruje, że nie zamierzali ukrywać tożsamości ani prowadzić działalności przestępczej w klasycznym sensie,
z drugiej – wbudowanie samoreplikującego się kodu bez zgody użytkownika trudno obronić jako „uczciwy” środek antypiracki, szczególnie gdy jego zasięg wymknął się spod kontroli.
Z punktu widzenia historii wirusów Brain jest ważny z dwóch powodów. Po pierwsze, pokazał, że prosty wirus sektorowy może osiągnąć globalny zasięg w świecie dyskietek. Po drugie, był jednym z pierwszych przypadków, w których autorzy nie próbowali całkowicie ukryć swojej tożsamości, co dzisiaj wydaje się co najmniej naiwne.
Techniczne ograniczenia, które pozwoliły Brainowi rosnąć
Dlaczego stosunkowo prosty wirus mógł tak się rozpowszechnić? Złożyło się na to kilka czynników:
Brak ochrony przed zapisem – większość użytkowników nie korzystała z zabezpieczenia dyskietek przed zapisem, więc sektor rozruchowy był podatny na modyfikację.
Start komputera z dyskietki – częste w tamtym okresie; wiele firm i użytkowników uruchamiało system z dyskietek, a nie z dysku twardego.
Brak narzędzi diagnostycznych – pierwsze programy antywirusowe dopiero raczkowały, a przeciętny użytkownik nie potrafił odczytać ani zinterpretować sektorów dysku.
Dystrybucja oprogramowania przez dyskietki – każda wymiana danych fizycznych (poczta, targi, spotkania użytkowników) była potencjalnym kanałem „zakażenia”.
Od Brain do „ekosystemu” wirusów PC
Brain nie spowodował globalnej katastrofy, ale otworzył oczy administratorom i producentom oprogramowania. Ujawnił też coś jeszcze: niski koszt wejścia. Do stworzenia wirusa sektorowego na PC wystarczała dobra znajomość asemblera i struktury dyskietki, czyli umiejętności dostępne dla wielu ówczesnych pasjonatów.
Niedługo po Brainie zaczęły pojawiać się kolejne programy infekujące sektory rozruchowe i pliki wykonywalne (.COM, .EXE). Nie powstała od razu „branża cyberprzestępcza” w dzisiejszym znaczeniu. Dominowali autorzy, którzy:
traktowali wirusa jako wyzwanie inżynierskie – jak zmieścić się w kilku setkach bajtów i „przeskoczyć” z nośnika na nośnik,
szukali rozgłosu w wąskim środowisku – ich „sygnatura” miała krążyć po uczelnianych laboratoriach i firmowych serwerowniach,
eksperymentowali z technikami ukrywania się (proste szyfrowanie kodu, modyfikacja dat plików, fałszowanie komunikatów błędów).
Rozwijały się pierwsze narzędzia antywirusowe, lecz często reagowały z opóźnieniem. W typowym biurze lat 80. infekcja oznaczała serię „dziwnych przypadków”: nagłe zawieszanie się programów, błędy przy odczycie dyskietek, niepokojące komunikaty. Dopiero po czasie ktoś kojarzył fakty i sięgał po ówczesne skanery, które w niczym nie przypominały dzisiejszych rozbudowanych pakietów bezpieczeństwa.
Robak Morrisa (1988): od studenckiego eksperymentu do globalnego incydentu
Internet sprzed przeglądarek: gdzie w ogóle działał robak?
Robak Morrisa pojawił się w listopadzie 1988 roku, w zupełnie innym środowisku niż Brain. Zamiast komputerów PC z DOS‑em i dyskietek mieliśmy maszyny Unixowe (głównie VAX i Sun) podłączone do wczesnego Internetu – wtedy jeszcze sieci akademickiej i rządowej, zdominowanej przez ARPANET i jego następców.
Nie było przeglądarek, serwisów społecznościowych ani domowego Wi‑Fi. Były za to:
zdalne logowanie przez telnet i rsh,
serwery poczty elektronicznej (sendmail),
usługi systemowe, które ufnie zakładały, że „w sieci wszyscy są mniej więcej godni zaufania”.
To właśnie w takim środowisku pojawił się program, który w pamięci zbiorowej często uchodzi za „pierwszego internetowego wirusa”. Dokładniej rzecz biorąc, był to robak sieciowy – samodzielna aplikacja rozprzestrzeniająca się przez sieć bez potrzeby dołączania do istniejących plików.
Kim był Robert Tappan Morris?
Autorem robaka był Robert Tappan Morris, wówczas student Cornell University, syn znanego specjalisty ds. bezpieczeństwa z Bell Labs i współautora standardów internetowych. To nie jest poboczny szczegół: wychował się w otoczeniu, w którym bezpieczeństwo systemów i projektowanie protokołów były codziennością.
Morris miał dostęp do zasobów, które dla przeciętnego studenta były wtedy poza zasięgiem: dobre zaplecze techniczne, dostęp do sieci, kontakty w świecie akademickim. Wszystko wskazuje na to, że jego motywacją nie była chęć zniszczenia czegokolwiek, lecz zademonstrowanie słabości zabezpieczeń i – co równie ważne – sprawdzenie, na ile szybko można rozprzestrzenić kod w sieci. Problem w tym, że techniczny „eksperyment” przeprowadzono na żywej infrastrukturze bez zgody zainteresowanych.
Jak działał robak Morrisa: techniczny szkic
Robak wykorzystywał kilka różnych wektorów ataku. Ich wspólnym mianownikiem było to, że opierały się na ówczesnym modelu zaufania w sieciach akademickich – hosty często pozwalały sobie nawzajem na sporo „z automatu”.
Najważniejsze elementy działania robaka można streścić tak:
Eksploatacja luk w sendmailu – robak korzystał z trybu debug serwera poczty, który pozwalał na przekazanie i uruchomienie poleceń na zdalnej maszynie. W uproszczeniu: wysyłał specjalnie przygotowany komunikat, który powodował pobranie i uruchomienie kodu robaka.
Wykorzystanie słabości rsh/rexec – tam, gdzie administratorzy skonfigurowali relacje zaufania między hostami (np. w plikach .rhosts), robak mógł logować się bez hasła i kopiować własny kod.
Atak słownikowy na hasła – na niektórych systemach próbował odgadnąć hasła użytkowników, korzystając z prostych słowników i kombinacji, a po udanym logowaniu instalował się z ich uprawnieniami.
Po zainstalowaniu na danej maszynie robak:
szukał innych hostów w plikach konfiguracyjnych (/etc/hosts, .rhosts, plikach historii),
próbował nawiązać z nimi połączenie jedną z powyższych metod,
kopiował swój kod, kompilował go lokalnie (lub korzystał z gotowej binarki) i uruchamiał proces z nową instancją.
Z technicznego punktu widzenia nie było to „magiczne” oprogramowanie: raczej zgrabne połączenie kilku dobrze znanych wtedy problemów z bezpieczeństwem. Kluczowy błąd projektowy pojawił się gdzie indziej.
Dlaczego robak wymknął się spod kontroli?
Morris próbował uniknąć sytuacji, w której jedna maszyna zostaje zainfekowana tylko raz, a kolejne próby są ignorowane. Teoretycznie miało to zwiększyć szanse rozprzestrzenienia się robaka w sytuacji, gdyby ktoś próbował symulować obecność infekcji, by go blokować.
W praktyce zastosował prostą heurystykę: nawet jeśli robak „podejrzewał”, że dany host jest już zainfekowany, z pewnym prawdopodobieństwem i tak próbował się zainstalować ponownie. To doprowadziło do zjawiska znanego z późniejszych ataków DDoS: hosty były zalewane kolejnymi procesami robaka, które konkurowały o zasoby CPU i pamięć.
Efekt końcowy wyglądał z perspektywy administratorów tak, jakby cała sieć nagle oszalała:
systemy stawały się nieresponsywne,
obciążenie procesora szybowało do maksimum,
zdalne logowanie przestawało działać, bo tablice procesów były zapchane.
To nie był klasyczny „destrukcyjny” kod – robak nie kasował danych ani nie szyfrował dysków. Paraliżował jednak usługi na tyle skutecznie, że realnie zakłócił działanie dziesiątek (a według niektórych szacunków setek) uczelni i instytucji w Stanach Zjednoczonych.
Jak reagowały uczelnie i administratorzy?
Pierwsze godziny po pojawieniu się robaka to była seria błędnych hipotez. Poszczególne ośrodki widziały tylko swój wycinek problemu: nagłe obciążenie maszyn, niewytłumaczalne procesy, lawinowo mnożące się pliki tymczasowe. Dopiero po wymianie informacji między administratorem w jednej instytucji a kolegami z innych miejsc zaczęło być jasne, że chodzi o zintegrowany, samoreplikujący się program.
Reakcje były dość improwizowane:
odłączano całe segmenty sieci, by zatrzymać rozprzestrzenianie,
ubijano procesy i ręcznie wyszukiwano pliki z kodem robaka,
tworzono tymczasowe „łaty” do sendmaila i innych usług, publikowane w postaci biuletynów na listach mailingowych.
W ciągu kilkudziesięciu godzin udało się zidentyfikować główne mechanizmy działania robaka i opracować zestaw kroków naprawczych. Nie zmienia to faktu, że jak na tamte czasy był to pierwszy tak głośny przypadek kryzysu bezpieczeństwa w skali całej sieci akademickiej.
Proces karny i pierwsze konsekwencje prawne
Robak Morrisa miał jeszcze jeden aspekt, który wykraczał poza czystą technikę: był jednym z pierwszych przypadków, w których twórca szkodliwego kodu został formalnie osądzony w Stanach Zjednoczonych.
Morris został oskarżony na podstawie ustawy Computer Fraud and Abuse Act (CFAA), przyjętej zaledwie kilka lat wcześniej. Sąd uznał, że jego działania doprowadziły do nieautoryzowanego dostępu do systemów i zakłócenia ich pracy. Ostatecznie otrzymał wyrok obejmujący:
okres nadzoru kuratorskiego (probacji),
grzywnę finansową,
prace społeczne.
Nie była to spektakularnie surowa kara, ale miała symboliczny wymiar: środowisko informatyków akademickich dostało jasny sygnał, że granica między „badaniami” a odpowiedzialnością karną jest bardzo cienka, jeśli eksperyment prowadzony jest na cudzej infrastrukturze bez zgody właściciela.
Istnieją spory co do tego, na ile intencje Morrisa były „złe” w sensie prawniczym czy moralnym. Faktem pozostaje, że oszacowania szkód (czas administratorów, przestoje, praca przy odtwarzaniu usług) były już wtedy istotne, a skala zaskoczenia pokazała, jak naiwny był ówczesny model zaufania między systemami w sieci.
Dlaczego robak Morrisa był punktem zwrotnym?
W wielu popularnych opisach można spotkać stwierdzenie, że robak Morrisa „zmienił wszystko”. To uproszczenie, ale kilka rzeczy rzeczywiście przyspieszył.
Po pierwsze, pojawiła się presja, by traktować bezpieczeństwo jako element projektowania usług, a nie późniejszy dodatek. Administratorzy zaczęli bardziej rygorystycznie podchodzić do:
dystrybucji poprawek – nawet jeśli wymagały one rekompilacji i restartu usług w środku semestru,
kontroli haseł i polityki ich złożoności.
Po drugie, incydent przyczynił się do powstania pierwszych zorganizowanych zespołów reagowania na incydenty. Wkrótce po robaku utworzono m.in. CERT przy Carnegie Mellon University, który miał koordynować wymianę informacji o lukach i atakach. To zapoczątkowało model współpracy, na którym do dziś opierają się krajowe i branżowe zespoły CSIRT.
Po trzecie wreszcie, robak stał się ostrzeżeniem dla przyszłych „eksperymentatorów”. Pokazał, że:
kod samoreplikujący się w sieci bardzo łatwo przekracza granice przewidywalności,
„brak intencji wyrządzenia szkód” nie chroni przed odpowiedzialnością, jeśli skutki są realne,
internet, nawet w wersji akademickiej z końca lat 80., był już na tyle istotną infrastrukturą, że zakłócenie jego pracy stawało się problemem publicznym, a nie lokalnym incydentem.
Studenci, laboratoria, firmy: kto jeszcze pisał wczesne robaki i wirusy?
Robak Morrisa i Brain mają wspólną cechę: ich autorzy działali na styku środowiska akademickiego i komercyjnego. Nie byli marginalnymi „podziemnymi” postaciami, tylko osobami funkcjonującymi w oficjalnych strukturach – firmie komputerowej i uniwersytecie. To wbrew popularnemu obrazowi „hakerów w piwnicach”, ale lepiej oddaje realia tamtego okresu.
W praktyce pierwsze wirusy i robaki tworzyli głównie:
studenci informatyki i inżynierowie, którzy szukali wyzwań technicznych wykraczających poza program studiów,
pracownicy laboratoriów testujących odporność własnych systemów (czasem z aprobatą przełożonych, czasem „po godzinach”),
pasjonaci z firm komputerowych, łączący ciekawość z mniej lub bardziej naiwnym podejściem do kwestii prawnych i etycznych.
Przypadki, w których od początku chodziło o bezpośredni zysk finansowy – np. wymuszenia czy kradzież pieniędzy – były w latach 80. raczej wyjątkami. Dopiero upowszechnienie bankowości elektronicznej i płatności online na początku lat 90. stworzyło warunki do rozwoju typowo przestępczego oprogramowania. Wcześniej dominowały motywacje mieszane: ciekawość techniczna, chęć popisu, czasem ideologiczne przekonanie, że „systemy muszą zostać obnażone, by ktoś je wreszcie poprawił”.
Problem polegał na tym, że granica między demonstracją a realnym szkodnictwem szybko się zacierała. Brain pokazał, że „niewinny” eksperyment z dyskietkami może rozlać się po świecie. Robak Morrisa udowodnił, że w sieci skutki są co najmniej o rząd wielkości poważniejsze – i znacznie trudniejsze do opanowania.
Najważniejsze punkty
Nie każdy złośliwy program jest wirusem – wirus musi się samodzielnie replikować, potrzebuje „gospodarza” (pliku, sektora, systemu) i modyfikuje środowisko, podczas gdy jednorazowy program niszczący dane wirusem nie jest.
W potocznym języku wirusy, robaki i trojany były wrzucane do jednego worka, co zacierało różnice: wirus przykleja się do innych plików, robak rozprzestrzenia się samodzielnie w sieci, a koń trojański nie musi się w ogóle kopiować.
Nie da się wskazać jednego „pierwszego wirusa” w sensie absolutnym, bo różne samoreplikujące się programy pojawiały się niezależnie na innych platformach (mainframe’y, ARPANET, komputery osobiste), często bez dobrej dokumentacji.
To, co bywa nazywane pierwszym wirusem, zależy od przyjętego kryterium: czy chodzi o pierwszy eksperyment laboratoryjny (np. Creeper), pierwszy przypadek na konkretnej platformie (Apple II, Xerox PARC), czy pierwszy szeroko opisany wirus „w dziczy” jak Brain na PC.
Pierwsze koncepcje samoreplikujących się programów powstały w świecie teorii – u von Neumanna i w badaniach nad automatami komórkowymi – i nie miały celu sabotażowego, lecz pokazywały, że samoreplikacja w systemach informatycznych jest logicznie możliwa.
W latach 60. i 70. samoreplikacja była głównie scenariuszem ostrzegawczym w dyskusjach o bezpieczeństwie i metaprogramowaniu; realne, niekontrolowane infekcje zaczęły się dopiero wraz z upowszechnieniem komputerów osobistych i sieci akademickich w połowie lat 80.
