20:17
14/9/2014

Korzystając z kończącego się weekendu, zapraszamy was do przeczytania czegoś luźniejszego niż zwykle. Przed Wami opowiadanie Emila. Historia ta zdarzyła się naprawdę. Z wiadomych przyczyn, pewne jej szczegóły są “rozmyte”, ale nie powinno to wpłynąć na zrozumienie przesłania tej opowieści…

Autorem poniższego opowiadania jest Emil Oppeln-Bronikowski.

Wszyscy popełniamy błędy, ale niektórzy z nas mogą popełnić błędy lepszej jakości: pomyłki, które kosztują pieniądze, czas i resztki włosów pracowników administracyjnych. Mając pod opieką systemy kilku firm, staram się docenić, jak wiele mogę im zaszkodzić, popełniając pomyłkę. Kiedy w zeszłym roku „usprawniałem” jeden z systemów, spowodowałem wyciek danych — na szczęście w obrębie firmy — nie doczytałem dokumentacji, nie sprawdziłem, ugryzło mnie w tyłek.

Kiedy w piątek otrzymałem e-mail z sekretariatu, wiedziałem już, że coś się dzieje. Poznałem po formacie. Pewnie czytaliście już kiedyś taki e-mail, panika nakryta kocem hipotetycznych pytań. Gdybym produkował bomby atomowe, mógłby brzmieć następująco:

„Co by się stało, gdybym nacisnął przycisk, którego z pewnością nie nacisnąłem, bo jest na nim napis, żeby go nie naciskać. I co się stanie, kiedy ten licznik, którego nie widzę, bo nie nacisnąłem guzika, osiągnie zero. Pytam dla kolegi.”

Kiedy przybyłem na miejsce zbrodni, okazało się, że przestępstwa przeciwko danym nie popełniono, a lęk był spowodowany niezrozumieniem operatora maszyny liczącej.

Elementarne, drogi Watsonie.

Spodziewając się, że duża wskazówka dogoni zaraz małą i wybije weekend, rozluźniłem się i opowiedziałem pracownikom sekretariatu anegdotkę, jak to miesiąc temu przyłapałem kogoś zalogowanego na konto „test” w systemie, i że go zablokowałem.

Wszystko eksplodowało.

Kto się logował? Czemu? Kto jest winien? Kto założył takie konto? Jakie miało uprawnienia? Skandal! Zdrada! Ktoś zaintonował „Ojczyznę wolną racz nam zwrócić, Panie”.

Wyjaśniałem więc, powoli i metodycznie, że nie ma powodów do obaw, że wina jest winnych, ale oni już tu z pewnością nie pracują i prosiłem, aby zachować spokój.

W tym punkcie historii musicie wiedzieć, że nie ufam użytkownikom. OK, głównie nie ufam im w temacie zgłaszania błędów. Żeby napisać dobre zgłoszenie, użytkownikowi musi naprawdę zależeć, a o to nie zawsze łatwo. Nie jest to przytyk: kiedy jechałem tramwajem, który opuścił torowisko w wyniku praw fizyki, nie interesowało mnie, jak budować zwrotnice, żeby więcej nie wykolejały tramwajów, tylko kiedy wreszcie będę w domu, do cholery, pieprzone bilety czasowe!

Z tego powodu mój kod pieczołowicie zapisuje całą drogę użytkownika przez system: gdzie klika, co ma w formularzu, daty, adresy IP, wszystko, co umożliwi mi odtworzenie interakcji, która spowodowała błąd.

Kiedy usiadłem wreszcie przy biurku, rzuciłem okiem na historię użytkownika „test” i napisałem e-mail ze szczegółami jego wizyty. Widział płatności za jeden miesiąc, zaliczki, raport taki i owaki. Był bardzo krótko. IP Telekomunikacji, gdzieś w Łódzkiem. Pewnie jakiś zgorzkniały były pracownik. Przepisałem pracownikom sekretariatu coś na ból głowy i żeby wyłączali dostęp do takich kont w przyszłości.

unnamed-11

Wtedy zauważyłem, że pierwszą akcją użytkownika „test” była zmiana hasła. Wydaje się całkiem oczywiste: nieużywane od 2011 r. konto podpada pod wymuszoną zmianę hasła zgodnie z wymogami ustawy. Pożałowałem, że naprawiłem swój błąd w kodzie logowania danych. Widzicie, zapisywanie wszystkich danych z POST powoduje, że czasem musiałbym wziąć hasło w stanie surowym i zostawić je w logach. Bardzo brzydko jest tak robić. Dlatego szybko zatkałem dziurę. No, „szybko”, było w systemie jakiś tydzień…

I teraz wyobraźcie sobie moją minę, kiedy odkrywam, że gość w systemie trafił akurat w ten okres. I że mam „serializowane” słowniki jego POST-u do zmiany hasła. Wydłubuję je do konsoli i rzucam okiem. Pierwsza zmiana hasła, nieudana, używała imienia mitologicznego stworzenia. Druga próba zmiany hasła też się nie powiodła. Trzecia za to tak! Patrzę więc na hasło i zaczynam drapać się po brodzie. Nikt nie jest chyba aż tak głupi? Podłączam się na chwilę do bazy produkcyjnej i robię zapytanie. Aha. Zapisuję numer telefonu.

Dzwonię. Sygnał, drugi, klik…

Dzień dobry. Dzwonię, żeby się dowiedzieć, czy logował się Pan do systemu, używając konta „test”. Aha. Nie, nie ma co robić paniki, gdyby Pan próbował coś modyfikować, to może byłyby problemy. Skąd wiem? Zrobił Pan dwa błędy. Pierwszym, oczywistym, było logowanie się do systemu, do którego odebrano Panu dostęp. Drugim była zmiana hasła na swój własny adres zamieszkania.

Jedyna prawdziwa nauka, która płynie z tego tekstu, jest taka: w systemach, gdzie czynnik ludzki jest odpowiedzialny za poprawne nadawanie/odbieranie dostępu, dobrą praktyką byłoby automatyczne blokowanie kont, które nie logowały się t czasu (t zależne od natury pracy wykonywanej przez użytkowników).

Dużo łatwiej odpowiedzieć na e-mail pracownika, który nie może się zalogować, niż wyławiać tych, którzy powinni stracić dostęp, a informacja ta zaginęła gdzieś w papierowym piekle.

A także: nie zakładajcie kont „test”.

Przeczytaj także:


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

44 komentarzy

Dodaj komentarz
  1. Strasznie dziwnie napisane – ciężko się to czyta.

    • Po stylu zgaduję, że to chyba Emil jest zaginionym w 2011 Charyzjuszem Hakerem! (ktoś pamięta jeszcze jego blog?) Zdemaskowałeś się Emilu! :-] Kiedy kolejne odcinki Charyzjusza?

    • Rzeczywiście, słabe. Mało mięska, mało przypraw, taka tartinka.

    • Zupełnie jakby z angielskiego tłumaczył jakiś analfabeta, kiedyś dużo podobnych tekstów krążyło po sieci. Ale może to zwyczajna grafomania.

    • Z dwojga złego, pomiędzy zarzutem o podjumania tekstu, a zwykłą grafomanią, wybieram grafomanię. Następnym razem (jeśli następny raz nastąpi) postram się skalibrować ton do tego, czego spodziewają się czytelnicy. Nie wszyscy muszą kochać gawędziarstwo okołotechnologiczne.

    • Kwestia gustu: mnie na ten przykład styl ten bardzo odpowiada. Często ludzie próbują tak pisać na siłę i wtedy nieprzyjemnie się czyta, natomiast u Emila na ogół wychodzi dość naturalnie.

    • Bez przesady, nie jest taki zly ten styl: ja przeczytalem do konca, a to w Internecie nie zdaza sie przeciez czesto :)

  2. “Druga próba zmiany hasła też się powiodła.” <- Tutaj mały błąd merytoryczny, chyba się jednak nie powiodła. :) Przedstawienie historii — miazga, gratulacje dla autora; mnogość takich możliwych przypadków mnie przeraża.

  3. O, Emil, hej.

  4. Dla mnie morałem tej historii jest fakt, że połączenia w Waszej firmie są nieszyfrowane… a przechwytywanie informacji z pola password można śmiało porównać do montowania kamery w kabinie toaletowej – niby fajnie, ale jednak…

    • (Mam nadzieję, że ELinks poradzi sobie z poprawnym odpowiedzeniem w wątku)

      @Bartek

      Wydaje mi się, że pomyliłemś warstwy. HTTPS odpowiada za szyfrowanie transmisji, logowanie odbywa się na poziomie aplikacji. Nikt nie mógłbym się zalogować gdybym nie mógł „przeczytać” haseł wysyłanych w formularzu, prawda?

    • Tym bardziej Twoja praktyka jest niepokojąca, bo zapewniasz użytkownikowi poczucie bezpieczeństwa poprzez bezpieczną transmisję, a następnie logujesz jego hasło przed jego haszowaniem – przy założeniu, że nie przechowujecie haseł w postaci PT :-)

    • @Bartek

      Zgadza się, to nie jest dobre zachowanie. Jak wspominałem w tekście loguję „ruch” użyTkowników i informacje, które przesyłają; niestety, przez własną nieuwagę, zapomniałem wyłączyć to dla formularza wymuszonej zmiany haseł.

      Stąd tytuł notki: przez moje zaniechanie wskoczył mi przez przypadek do logów użytkownik, który nie był grzeczny.

      Myślę, że przeceniasz jednak „prywatność” użytkowników w systemie biznesowym, do którego mają dostęp z uwagi na stosunek pracy. Użytkownik w takim systemie nie może się spodziewać prywatności, na końcu ktoś musi trzymać pieczę nad całością.

  5. Skoro już jesteśmy przy tym, nie zakładajcie również kont “dupa” :(

    • Ani z innymi częściami ciała w loginie, nazwie itp.
      Gdybym jednak uczył się na własnych błędach byłbym geniuszem :)

    • Znajomy chciał ustawić hasło “penis” – było za krótkie ;)

  6. Opi, jak zwykle trzymasz poziom :)

  7. Tekst trudny w odbiorze jednak puenta bardzo dobra, brawo:
    dobrą praktyką byłoby automatyczne blokowanie kont, które nie logowały się t czasu (t zależne od natury pracy wykonywanej przez użytkowników).

  8. Sytuacja z przed miesiąca, jeden z administratorów postanowił wprowadzić exploit do systemu i prawie mu się to udało zrobić, bo exploit został namierzony… Administrator jednak zapobiegawczo usunął wszelkie tropy w jego kierunku, wyczyścił logi systemowe i usunął bash_history ze swojego konta, aby nikt nie wiedział, że zrobił to on. Jednak nie pomyślał o tym, że w momencie usunięcia bash_history zostanie utworzony nowy, z datą wylogowania z systemu, co zrobił po wprowadzeniu exploita i jako jedyny logował się do systemu w tym czasie. Mocno zawęziło to krąg podejrzanych ;)

    • Masz rację. Następnym razem zmodyfikuję historię Basha.

  9. Tekst wcale nie jest jakiś bardzo trudny w odbiorze, chociaż nie należy do tzw. streszczeń dla kierownictwa. Emil ma taki flow, dzięki czemu lubię go czytać.

    Anyway, niezłą taktyką jest ustawianie czasu życia kont na jakiś czas (np. miesiąc) i obowiązek ich przedłużania przez przełożonego/przełożonych. Oczywiście, będzie to generowało zlecenia w typie zapomniałem, nie przedłużyło się, etc…

    • Jeśli praca jest strice w biurze a nie zdalna, wystarczy wymusić zmianę hasła co jakiś czas i zezwolić na tą operację tylko z wewnętrznej sieci.

      Na marginesie, widzę, że komentarze niekumatych lub niepotrafiących czytać więcej niż kilka zdań ze zrozumieniem i zawartymi weń przenośniami, skutecznie odwiodły Mr. Bronikowskiego od publikacji tu czegokolwiek w przyszłości. No cóż, nie dla każdego jest Jego blog, jak i podobne strony, np. strona Lemata. Mógłbym się zacząć zastanawiać dlaczego w serwisie traktującym o bezpieczeństwie (gdzie nierzadko były bardziej rozbudowane treści) połowa komentujących nie potrafiła zrozumieć powyższego tekstu, ale dam se siana – jeszcze by mi w wyniku wyszło, że to dobrze, bo “im mniej wiesz tym lepiej śpisz”, i poniekąd dzięki temu pewni ludzie mają pracę… Pozdro.

  10. Jednak zdecydowanie lepiej, aby info musiało pójść do admina o zwolnieniu pracownika z dniem takim a takim i poleceniem odebrania dostępu do każdego “jego” konta ze skutkiem na określony dzień.
    W korpo tak się dzieje, co nie znaczy, że na pewno w każdej… ;]

  11. U mnie test jest dosyć często:
    http://pastebin.com/qafNkTYK

  12. @GwynBleidD

    To dupa a nie administrator sokoro nawet unset HISTFILE nie zna…

    Tekst raczej marny, oby jak najmniej takich.

  13. I co się stało z delikwentem?

    • Delikwent ma już spory zapas własnych problemów (jeden z powodów dla których już nie pracuje) więc nie było sensu mu dokładać niczego nowego na głowę. Poza dostępem do kilku raportów (których nie drukował i nie miał raczej czas dokładnie przeczytać patrząc na timestamp) nie zrobił nic, co wymagałoby targania go za ucho.

      Opieprzyłem, pogroziłem palcem i wyjaśniłem, że zarchiwizuję wszystko gdyby w przyszłości nadal chciał być nieprzyjemny.

  14. test to zawsze była masakra ;P
    Kiedyś na serwerze założyłem takie konto do przetestowania local-sploita. wget, rozpakowanie, żarówka “aha, lepiej nie robić przez su -“, tutaj zadzwonił telefon, skończyłem gadać, zalogowałem sie jako test z zamiarem a tam… kufa… już bot chodzi i wisi na jakimś ircu efnetowym ;) ;) szczena mi opadła ;d

    Także nie zakładajcie kont „test”.

    • No chyba, że bez hasła to się zgodzę.

      Ale jeśli mocne hasło to dlaczego nie? Ja mam pozakładane z mocnymi hasłami a jak skończę testy to konto blokuje.Nawet nie muszę pamiętać ani zapisywac hasła, a jak znowu konto jest potrzebne to odblokuję i ustanowie nowe hasło.

  15. Nic z tego nie kumam. Co to jest konto “test”? Jak ten ktos zalogowal sie na to konto? Znal haslo? Czyli to bylo jego stare konto czy co?

    Dlaczego nie zakladac konta “test”? (cokolwiek to znaczy)

  16. “Test” sugeruje, że w systemie jest konto, do którego dostęp mogą mieć dostęp różne osoby (a hasło pewnie na przylepnej karteczce), konto takie może mieć zbyt szerokie uprawnienia i częściej niż rzadziej hasłem będzie test123.

    Konto, które jest zakładane na szybko, do którego dostęp ma więcej niż jedna osoba, które może eskalować uprawnienia to zapraszanie do siebie rozrabiaków.

    To nie znaczy, że każde konto “test” jest takie, ale doświadczenie mówi mi, że przytrafia się to często.

  17. ‘tekst trudny w odbiorze’ – mnie osobiście tę historię czytało się lekko i przyjemnie, może dlatego, że poza rewelacyjnymi zdolnościami informatycznymi (sic!), jaram się czytaniem książek i prowadzeniem bloga ;-)

  18. “Tekst trudny w odbiorze”? Albo mam z autorem ten sam zestaw zaburzeń poznawczych, albo narzekający mają problem z przeczytaniem czegokolwiek dłuższego, niż komentarz na fejsbuku…

  19. Do mojego gw, z jednego IP, TCP SYN nie częściej niż 1 raz na minuę.
    Poza tym, IPeki z których są próby logowania na nieistniejącego bądź niedozwolonego użytkownika trafiają do iptables z -j DROP.
    Do tego, raz na jakiś czas przeładowuję w iptables listę DROPów ze spamhouse.

  20. Ten styl pisania… Stary, 1999 był 15 lat temu.

  21. Bardzo męczące w odbiorze. Jeśli autorowi sie zdaje, że ma zdolności literackie lub zadatki na filozofa moralistę to niestety musze rozczarować.

  22. Największy błąd to nawiązywanie na początku akapitu/zdania do rzeczy o których jeszcze autor nie raczył wspomnieć. Czyli inaczej mówiąc, nie ma prawie żadnej chronologii zdarzeń co powoduje, że całość czyta się mało przyjemnie. Mamy cały czas wrażenie chaosu i ogólnego “ale o co k**** chodzi” ;]

    • A może o to chodziło? Ja przeczytałem z lekkością i wszystko zrozumiałem i nie tylko ja z tego co widzę, więc chyba problem leży po stronie czytających, a nie piszącego…

  23. Tekst ok, nawet zdun zrozumial :)

  24. Jak przeczytałem artykuł to przypomniało mnie się zdarzenie którego miałem wątpliwą przyjemność doświadczyć, otóż pewnego dnia pewne małżeństwo (stare komuchy jakieś) poprosiło mnie o odzyskanie hasła do sys. gdyż nie mogli sie zalogować. Pierwsze co mi się w oczy rzuciło po przyjściu doń to, to że w pralce Frani okładali wodę tłuczkiem do mięsa ..(sic!) Na moje pytanie CO PAŃSTWO ROBIĄ ? odparli mi z błyskiem w oku iż w miękkiej wodzie się lepiej pierze … ? Nie rozwodziłem się ani sekundy nad tym zdarzeniem i szybciutko przeszedłem do pytań technicznych dotyczących celu mojej wizyty, o czym wspominałem kilka linijek wyżej, czyli odzyskanie chasła logowania. W tym celu uruchomiłem płytke z programem Kon Boot, utworzyłem dodatkowe konto administratora, zalogowałem się, uruchomiłem program WDC … suma summarum hasłem do logowania było słowo Rzeżucha które to przepisali z torebki z nasionami kture akurat sadzili, a którą to potem wyrzucili. Hasło rzeczywiście wpisywali “Rzeżucha” tylko przy tym straszne byki walili.

  25. To doprawdy fenomenalne, jak wielu krytyków literackich, niewątpliwie z olbrzymim dorobkiem własnym, czyta Niebezpiecznika. Jestem zachwycony.

  26. Fajny tekst – lubie taki styl. Co do histori z hasłami to zaczynajac prace w nowej firmie po pewnym czasie odkryłem ze główna ksiegowa ma konto z uprawnieniami administartora domeny – poprzednik wytłumaczy z miał problem z nadaniem jej dostepu do udziałów sieciowych wiec dlatego dał jej te uprawnienia. Horror.

Odpowiadasz na komentarz Michał

Kliknij tu, aby anulować

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: