Dawno, dawno temu, czyli jak kiedyś hakowano mainframe’y

dodał 2 listopada 2014 o 19:20 w kategorii Info  z tagami:
Dawno, dawno temu, czyli jak kiedyś hakowano mainframe’y

Historia włamań czy kradzieży haseł ma tyle lat, co komputery. Zawsze gdy ktoś spróbuje ograniczyć jakiś dostęp, pojawi się ktoś, kto spróbuje te ograniczenia ominąć. Oto historia o tym, jak hakowanie komputerów wyglądało kilkadziesiąt lat temu.

Serwis DailyWTF opublikował bardzo ciekawe wspomnienia pracownika uniwersyteckiego centrum komputerowego. Co prawda w tekście nie pada żadna data, ale historie dotyczą zapewne końca lat 60-tych lub początku lat 70-tych. Posłuchajcie zatem, jak się drzewiej hakowało.

Najszybszy komputer świata

Autor tekstu nie podaje lokalizacji swojej historii ani modeli opisywanych komputerów, ale przynajmniej jeden z nich da się zidentyfikować. Wiemy jedynie, że był on przez kilka lat najmocniejszym komputerem świata i został zaprojektowany przez osobę o imieniu Seymour. Odpowiedź może być tylko jedna – był to CDC 6600, którego projektantem był Seymour Cray (tak, od tych Crayów). Był to wówczas najszybszy komputer świata i utrzymywał ten tytuł od roku 1964 do 1969. Jego prędkość nie szła jednak w parze z bezpieczeństwem.

Ówczesne komputery nie oferowały zbyt wielu funkcji. Na opisywanej maszynie można było przechowywać pliki (jeden folder na użytkownika), kompilować programy w COBOLu, FORTRANie lub Pascalu i uruchomić SPSS (tak, ten program ma już 46 lat!). Oczywiście czas dostępu do takiej maszyny był mocno ograniczony i osoby, które chciały ją wykorzystywać bardziej od konkurencji musiały znajdować metody obejścia ograniczeń.

CDC 6600 w pełnej krasie

CDC 6600 w pełnej krasie

Plik godny pożądania

Wszystkie loginy, hasła oraz opisy uprawnień były przechowywane w jednym pliku binarnym. Hasła oczywiście figurowały w nim w formie jawnej – nikt nie wpadł jeszcze na pomysł by je szyfrować lub tworzyć funkcje skrótu. Posiadacz takiego pliku mógł korzystać z cudzych kont, więc był to bardzo łakomy kąsek. Ale jak się do niego dobrać?

System oferował prostą funkcję w przypadku przerwania wykonywanego zadania – dołączał do niego wszystkie wykorzystywane pliki i udostępniał je użytkownikowi. Jako że cała interaktywna sesja była traktowana jako jedno „zadanie”, wystarczyło uruchomić program do zmiany haseł a następnie przerwać sesję i plik z hasłami lądował w rękach użytkownika.

Ta metoda wkrótce została załatana poprzez wymuszenie braku obsługi przerwań z poziomu terminala w procesie zmiany hasła. Kilka dni później ktoś wpadł na to, że nie wyłączono obsługi przerwania „przekroczony czas procesora”. Wystarczyło zatem ustawić limit np. na 1 sekundę, uruchomić program, który wykorzysta 0,99 sekundy i uruchomi program do zmiany hasła. W trakcie zmiany hasła następowało przerwania z powodu końca czasu procesora i plik z hasłami znowu lądował w rękach użytkownika. Ta metoda działała ponoć przez około miesiąc.

Kolejne odkrycie kombinatorów było dość trywialne – obszar pamięci wykorzystywany przez programy w FORTRANie nie był – zapewne z powodów „oszczędnościowych” – inicjalizowany przez operacje systemowe i można było w nim znaleźć fragmenty pamięci działających procesów, w tym także procesu zmiany hasła. W dostępnej pamięci mieściło się dokładnie 128 loginów i haseł, co w zupełności wystarczało do swobodnej pracy.

Inna metoda pozyskania pliku z hasłami wiązała się z pamięcią zewnętrzną, z której korzystały wspólnie dwa mainframe’y. Konta użytkowników działały na obu maszynach, zatem musiały one wymieniać treść kluczowego pliku własnie za pośrednictwem tego modułu pamięci (było to długo przed wprowadzeniem Ethernetu). System wyposażony był w narzędzie do zrzucania treści dzielonej pamięci. Trzeba było zatem jedynie dokonać zmiany hasła i zrzucić pamieć, by znaleźć w niej pożądany plik. Metoda ta działała przez kilka miesięcy.

Kiedy wszystkie znane dziury zostały załatane kombinatorzy zwrócili uwagę, że od północy do 6 rano konta użytkowników nie działają – był to czas przeznaczony na pracę administratorów porządkujących maszyny. Jako że system nie posiadał funkcji „zawieszenie pracy”, ktoś zaryzykował hipotezę, że zapewne kluczowy plik z hasłami jest podmieniany na inny, pozbawiony haseł, a 6 rano oryginalny plik jest przywracany na właściwe miejsce. Pozostało już tylko czekać na błąd administratora, który zapisze plik z hasłami z niewłaściwymi uprawnieniami w publicznie dostępnym folderze. Jednego dnia właśnie takie wydarzenie miało miejsce. Co prawda plik by zaszyfrowany, ale hasło było jego nazwą wspak.

Ostatnią z opisywanych metod był „atak na taśmę”. Kiedy system zwalniał, oznaczało to, ze trwa tworzenie kopii bezpieczeństwa, czyli przegrywanie danych z dysku na taśmę. Gdy operacja się kończyła, można było poprosić system o dostęp do taśmy. Czasem operator myślał, że to procedura backupowa chce dokończyć pracę i dostęp przyznawał. A na taśmie foldery systemowe znajdowały się na samym początku…

Kawał historii

Jak więc widzicie, w pierwszych latach rozwoju technologii IT zdobycie pliku z hasłami nie było trudnym zadaniem. Co ciekawe, najczęściej nie jest nim również teraz – tylko wykorzystywane błędy są czasem trochę bardziej złożone.

Może ktoś z Was chce się podzielić historiami z czasów młodości? Na uczelni jednego z redaktorów serwisu w połowie lat 90-tych można było zmieniać uprawnienia własnego katalogu domowego (również na 777) i kiedyś ktoś to wykorzystał, dopisując do kilkudziesięciu kont niefrasobliwych użytkowników swój klucz SSH. O keyloggerach na prawie każdym terminalu tekstowym już nie wspominając…