02.11.2014 | 19:20

Adam Haertle

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…

Powrót

Komentarze

  • 2014.11.02 19:34 Tomek

    Heh, te czasy gdy miało się quotę 1 MB na Novellu i dzięki spreparowanemu plikowi „logout.exe” można było zgarnąć trochę więcej od użytkowników, którzy nie mieli nawyku resetu stacji przed przystąpieniem do pracy ;-)

    Odpowiedz
  • 2014.11.02 19:53 steppe

    Na uczelni różnie bywało, ale najwyraźniej walka studentów z systemem ma głębokie korzenie i tradycję :)
    Akurat trochę inaczej oceniałbym łatwość znalezienia opisywanych podatności. Na te czasy pomysły były przecież nowatorskie. Ktoś stosował typowe podejście prawdziwego hackera: musisz poznać jak działa system, żeby coś osiągnąć. Nie mieli wtedy rootshell.com jak ludzie w latach 90. ;)
    Fajny artykuł, aż się przypominają boje ze splitvt i tym podobnymi w starych Linuksach…

    Odpowiedz
  • 2014.11.02 20:35 r

    1. Zdobycie hasełów na HP-UX z wykorzystaniem fingera (suid) (jak mnie pamięć nie myli to link /etc/shadow do ~/.plan no i finger $USER)

    2. Zrzucanie /dev/urandom (przez write) na terminal prowadzącego ćwiczenia (obraz na rzutniku).

    3. Generalnie na uczelni na serwerze wspólnym ludzie trzymali bardzo różne rzeczy (nie tylko studenci) w katalogu domowym (prawa standardowe do odczytu).

    4. Phreaking :-)

    Odpowiedz
  • 2014.11.02 23:24 Darek

    Na mojej uczelni komputery na jednym z laboratoriów miały zablokowany dostęp do Internetu. Udało mi się ustalić, że mogę połączyć się, za pomocą rlogin, z inną maszyną, która miała dostęp do Internetu. Pózniej już tylko małe, napisane na laborkach z c, proxy i Internet śmigał aż miło. Nic to, kiedy się zorientowałem, że mam dostęp za pomocą wspomnianego rlogin do kilkudziesięciu komputerów na całej uczelni. Maszyny te za pomocą MPI można było spiąć w całkiem pokaźny klaster. Zapewne do tego celu skonfigurowany został dostęp przez rlogin. Nie miałem jednak odwagi spróbować :)

    Odpowiedz
  • 2014.11.03 18:22 zdegustowany

    Mój znajomy miał inny pomysł na zdobywanie haseł do mainframe (ostatnie lata IBM360 w CIUW). Napisał wniosek i dostał konto „root” – oczywiście w samym systemie mainframowym nie miało ono specjalnych uprawnień (kontem dla BOFH-a było OPER).

    Natomiast ludzie, którzy wcześniej pracowali na Linuxach, BSD itp gdzie wysyłali maile, kiedy mieli problemy? Oczywiście do roota. Czasem nawet od razu załączali login i hasło…

    Po jakimś czasie obsługa się zorientowała i konto zabrali ale nic więcej nie mogli zrobić, bo w regulaminie nie było zastrzeżenia że nie wolno zakładać kont o nazwach takich jak administracyjne w innych systemach.

    Odpowiedz
    • 2014.11.04 09:17 Ziutek

      Ładna historia, ale nieprawdziwa. Tam nie było ani roota, ani maila. Albo to nie była trzystasześćdziesiątka.

      Odpowiedz
  • 2014.11.03 21:00 4 8 15 16 23 42

    Poważnie nikt tego nie zauważył : ” Posłuchajcie zatem, jak się drzewiej hakowało.” ?

    Odpowiedz
  • 2014.11.03 23:21 Ziutek

    Fajnie, tylko to nie mainframe.
    Tzn. nie TEN mainframe! Nie każdemu psu Burek, ale nie ma „kopirajta” na imię Burka.

    Spróbujcie znaleźć jakiś sensowny włam, lub wirusa na IBM mainframe, a konkretnie na system operacyjny z/OS i jego poprzedników. Życzę zdrowia.

    PS. W jednym z moich systemów hasło na „superusera” brzmi SYS1. Bo złamałem wszystkie zasady. Można? Można! I tam można się włamać. Jakby ktoś chciał, to za skromną opłatą udostępnię ;-)

    Odpowiedz
    • 2014.11.04 11:32 Adam

      Ziutek, chyba nie czytałeś https://zaufanatrzeciastrona.pl/historia-pewnego-wlamania/ o tym, jak Anakata kilka mainframe’ów (w tym Nordei) popsuł. I to dokładnie z/OS. Te włamy chyba były wystarczająco sensowne? Mógł nawet generować fałszywe przelewy.

      Odpowiedz
      • 2014.11.04 17:57 Ziutek

        Ależ czytałem! I znam sprawę nieco głębiej, niż to było opisane.
        Włam polegający na zdobyciu usera i passworda do systemu, który jest dostępny z Netu. Sorry, tego się nie da obronić ;-)

        PS. Jeszcze więcej mainframów zhackował Kevin Mitnick. Głównie dzwoniąc po ludziach o prosząc ich o zrobienie czegoś.

        Odpowiedz
        • 2014.11.04 18:03 Adam

          A lokalny błąd pozwalający na podniesienie uprawnień to pies? Poza tym login/pass miał chyba tylko do jednego systemu, a dwa pozostałe? Podziel się historią :)

          Odpowiedz

Zostaw odpowiedź do Darek

Jeśli chcesz zwrócić uwagę na literówkę lub inny błąd techniczny, zapraszamy do formularza kontaktowego. Reagujemy równie szybko.

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

Komentarze