Jak zhakowano Apache Software Foundation?

Fundacja Apache przedstawiła dziś na swym blogu szczegółowe sprawozdanie z serii poważnych incydentów, jakie miały miejsce w ciągu kilku ostatnich dni. W wyniku całej serii ukierunkowanych ataków, włamywaczom udało się uzyskać administracyjny dostęp do szeregu usług oraz serwerów należących do Apache Software Foundation. Doszło również do wycieku baz zawierających skróty haseł dostępowych do serwisów JIRA, Bugzilla oraz Confluence.

Wszystko zaczęło się 5. kwietnia od umieszczenia w systemie JIRA (komercyjne rozwiązanie do śledzenia zgłoszeń oraz zarządzania procesami) następującego zgłoszenia:

ive got this error while browsing some projects in jira http://tinyurl.com/XXXXXXXXX

Adres URL, do którego kierował serwis Tinyurl, wskazywał z powrotem na usługę JIRA, zawierał jednak kod zdolny do wykonania ataku typu XSS (Cross-site scripting) wykradającego pliki cookies użytkowników zalogowanych do serwisu. W taki oto sposób włamywacze zdołali przejąć kilka sesji administracyjnych JIRA.

W wyniku prowadzonych jednocześnie ataków typu brute force, crackerom udało się również zdobyć poświadczenia jednego z administratorów systemu JIRA. Dostęp administracyjny oraz odpowiednio spreparowane pliki JSP, pozwoliły na dostęp do katalogów domowych poszczególnych użytkowników oraz utworzenie furtki (backdoor) pozwalającej na późniejszy dostęp do serwera. Instalacja odpowiedniego pliku JAR pozwoliła natomiast intruzom na przechwytywanie wszystkich haseł w trakcie logowania się użytkowników.

Jedno z przechwyconych w ten sposób haseł okazało się być dla crackerów przepustką do serwera brutus.apache.org na pełnych prawach administracyjnych. Tutaj możliwe okazało się z kolei uzyskanie danych pozwalających na dostęp do serwera minotaur.apache.org (aka people.apache.org). Na tym etapie udało się wreszcie zauważyć obecność crackerów, a firma Atlassian została poinformowana o nieznanej do tej pory podatności na atak typu XSS, obecnej w jej oprogramowaniu JIRA. Warto podkreślić, że firma Atlassian upubliczniła dziś również informacje na temat własnych incydentów bezpieczeństwa.

Krytyczne usługi zostały w końcu przez ASF w trybie natychmiastowym przeniesione na inny serwer (thor.apache.org). 10. kwietnia działanie usług JIRA oraz Bugzilla zostało w pełni przywrócone. Firma Atlassian opublikowała dziś natomiast odpowiednią poprawkę dla oprogramowania JIRA (JRA-20994 oraz JRA-20995). Działania systemu Confluence (narzędzie do pracy grupowej w przedsiębiorstwie, bazujące na koncepcji Wiki) nie udało się nadal przywrócić.

Po niedawnych cyberatakach wymierzonych w Google, Adobe oraz wiele innych wiodących firm z branży informatycznej, jest to więc kolejny w ostatnim czasie przykład ukierunkowanego ataku zakrojonego na bardzo dużą skalę. Jest to niestety również kolejny dowód na to, że w chwili obecnej nawet największe i najnowocześniejsze organizacje nie mają pomysłu na skuteczną obronę przed tego typu zagrożeniami…

żadnych reklam, sama wiedza.

Zarejestruj się na BEZPŁATNY NEWSLETTER i raz w tygodniu otrzymuj najważniejsze wiadmości
ze świata IT, nowych technologii i kryptowalut.

Bez reklam.

  1. Awatar jarek
    jarek

    Powinni byli uzywac linuxa a nie windows.

    1. Awatar kuku
      kuku

      … perla a nie javy, vima a nie emacsa, domestosa a nie acze.

      1. Awatar jarek
        jarek

        Jesli uzywali emacsa to pewnie wjechali im przez sendmaila.

        1. Awatar 123qwe
          123qwe

          Co do "emacsem przez sendmaila", już wiem jak to zrobili. Fake maila wysłali.. 😉

          http://www.chemie.fu-berlin.de/chemnet/use/info/e…

        2. Awatar 3ED
          3ED

          A co to im dało? echo "CC: Blabla [..]"|sendmail -cośtam 😉

  2. Awatar trasz
    trasz

    Z ciekawostek – jakis czas temu, po ktoryms z incydentow, goscie z Apache opowiadali, ze skore uratowal im fakt, iz trzymali dane na ZFS pod FreeBSD i mogli szybko zrobic rollback snapshotow.

    1. Awatar krzabr
      krzabr

      Ciekawe ile one ważyły ….

      1. Awatar trasz
        trasz

        @krzabr: Pojecia nie mam. Z tym, ze w tym przypadku roznica miedzy Linuksem i reszta swiata jest jakosciowa, nie ilosciowa – nie jest istotne, ile maja snapshoty, ale to, ze w Linuksie ta funkcjonalnosc nie jest dostepna. (Wlasciwie to czesc funkcjonalnosci jest, ale w wersji tak kulawej, ze bezuzytecznej.)

        1. Awatar Reddie
          Reddie

          Snapshoty ZFS to po prostu zintegrowana z systemem plików funkcjonalność kopii zapasowych, więc Linux (podobnie jak większość systemów) takową posiada.

        2. Awatar Kwant
          Kwant

          Ciekawe, a znajomy ostatnio mówił, że regulareni robi snapshoty systemu plików (dużego) pod Linuxem żeby zrobić spójny backup na tasiemki – żeby w ciągu kilku godzin zgrywania mieć pliki z jednej chwili.

          Popisywanie się ignorancją nie jest szczególnie cenione…

        3. Awatar trasz
          trasz

          @Reddie: Tyle tylko, ze snapshot w ZFS:

          1. Nie wymaga czasu na zrobienie – "zfs snapshot" wykonuje sie w sekunde, niezaleznie od wielkosci filesystemu czy liczby plikow, i

          2. Nie wymaga wygospodarowania miejsca – jest copy-on-write.

          W praktyce przeklada sie to na zupelnie inne podejscie do wykorzystania snapshotow – poniewaz zrobienie ich praktycznie nie trwa, mozesz robic je prewencyjnie, na przyklad przed upgradem systemu w laptopie.

          @Kwant: Napisalem przeciez, ze w Linuksie jest dostepna czesc tej funkcjonalnosci, ale w kulawej wersji: mozesz robic snapshoty LVM-em, ale jest to problematyczne organizacyjnie (musisz recznie wydzielic na to miejsce) i powolne (snapshot zajmuje wiecej miejsca i dziala wolniej).

        4. Awatar el.pescado
          el.pescado

          Online?

        5. Awatar el.pescado
          el.pescado

          To był komentarz @Kwant.

        6. Awatar Maciej Piechotka
          Maciej Piechotka

          @trasz: LVM + xfs posiada możliwość z tego co pamiętam atomicznych snapshotów COW. Określasz maksymalne dodatkowe miejsce na dysku.
          O btrfs nie wspominając.

          Zgoda – musisz 'ręcznie' przydzielić miejsce ale ponieważ to LVM to porzydzielasz 'logiczne' miejsce a nie fizyczne.

        7. Awatar trasz
          trasz

          @Maciej Piechotka: Jesli dobrze pamietam, to to "logiczne" miejsce w LVM musi miec pokrycie w fizycznym. W sensie, musisz miec w VG miejsce nie przydzielone zadnemu LV, i albo zagwarantowac, ze go wystarczy, albo modlic sie, zeby tak bylo. I nadal pozostaje problem wydajnosci.

          O Btrfs nie ma co wspominac, bo ciezko powiedziec, kiedy stanie sie produkcyjnie uzywalny.

        8. Awatar Tomasz Woźniak
          Tomasz Woźniak

          @trasz: snapshot w ZFS na Apache? Nie stać ich na porządnego sana- nie wierzę.

        9. Awatar norbert_ramzes
          norbert_ramzes

          @Tomasz Woźniak Z tego co się orientuję to nazwisk i nazw własnych się nie tłumaczy (choć są wyjątki od tej reguły – ale nie tym razem) ale odmieniać można. Tak więc zamiast "sana" powinno być "suna" albo "sun'a" albo jeszcze inaczej "sun-a".

        10. Awatar trasz
          trasz

          @Tomasz Woźniak: Do SAN-ow ZFS jest idealny. Pewnie miales na mysli NAS-a – ale znow, nawet NetApp pod paroma wzgledami (sumy kontrolne, snapshoty) ustepuje ZFS-owi. Z kolei nowe macierze Suna maja w srodku Solarisa z ZFS-em.

        11. Awatar trasz
          trasz

          Erm, wait. Zle pamietalem. Znaczy, pamietalem mniej wiecej dobrze, ale ZFS byl pod Solarisem (to bylo jakos przed wydaniem FreeBSD 8.0; pierwszego, z "oficjalnie stabilnym" ZFS-em).

          https://blogs.apache.org/infra/entry/apache_org_d…

        12. Awatar Raffael777
          Raffael777

          @norbert_ramzes

          Człowieku, on mówił o czymś co nazywa się w skrócie SAN

          http://en.wikipedia.org/wiki/Storage_area_network

        13. Awatar jarek
          jarek

          > @trasz: snapshot w ZFS na Apache? Nie stać ich na porządnego sana- nie wierzę.

          Nawet jesli stac, to co z tego. Jesli software'owe rozwiazanie zdaje
          egzamin to po co pchac pieniadze w specjalizowane wynalazki. Google
          jedzie na podrasowanych PCtach a nie na NAS/SAN i jakos daje rade.

    2. Awatar miodek
      miodek

      Gorąca prośba do wszystkich osób. Piszcie z polskimi znakami, bo okropnie się czyta takie komentarze bez polskich liter. Wiadomym jest, że łatwiej i szybciej jest tak pisać, ale potem dla czytających to (a na pewno dla mnie) jest to udręka. Z góry dziękuję i pozdrawiam.

      Ps.
      Polecam naukę do bezwzrokowego pisania. samo opanowanie klawiatury zajęło mi raptem dwa dni, no i potem trochę samozaparcia i treningu i nie ma problemu z polskimi znakami.

      1. Awatar jarek
        jarek

        Spier*alaj z polskimi znakami, ASCII rzadzi!

        1. Awatar norbert_ramzes
          norbert_ramzes

          Jeszcze raz zobaczę u Ciebie takie słowo – BAN.

      2. Awatar Reddie
        Reddie

        Mi tam nie przeszkadzają.

    3. Awatar Mieszko Kaczmarczyk
      Mieszko Kaczmarczyk

      trzymali dane na ZFS pod FreeBSD i mogli szybko zrobic rollback snapshotow.

      Jak sie to robi – ma ktos link do opisu?

      1. Awatar trasz
        trasz

        @Mieszko Kaczmarczyk: Robi sie przez "zfs rollback pool/filesystem@nazwa-snapshotu".

  3. Awatar pjure efil
    pjure efil

    jak zwykle młot thora (thor.apache.org) rozwiązał wszystkie problemy 😛

  4. Awatar LM
    LM

    Bo usługi typu tinyurl to Zuo.

    1. Awatar keke
      keke

      http://www.longurlplease.com/

    2. Awatar 3ED
      3ED

      Oj tak, tinurl nawet nie sprawdza co skraca: http://tinyurl.com/y4h8prt

      PS1. Upewnijcie się, czy noscript nie blokuje wam tinyurl-a. 😉
      PS2. Wiem że większość z was o tym wie ale warto przypomnieć.

    3. Awatar vshader
      vshader

      skoro tinyurl to zło, to ja polecam http://www.shadyurl.com/

  5. Awatar riklaunim
    riklaunim

    Kiedyś zgłaszałem im XSS i problemy z walidacją wywalające Javowe wyjątki w Confluence jak Pylons zrobił wiki w oparciu o to. Jak ktoś chętny to może potestować na jakiejś demówce 😉

  6. Awatar Bastian
    Bastian

    Skoro takie potęgi internetowe jak apache czy google nie radzą sobie z atakami to mnie jako adminowi, który toczy nieustający trud w ciągłej nauce jak zabezpieczyć serwer, pozostaje tylko przyjąć do wiadomości, ze choć niewiadomo ile czasu nad tym spędze, to i tak go nie zabezpieczę wystarczająco..przyjmując takie założenie jakoś lżej na sercu 🙂

    1. Awatar Iskast
      Iskast

      Co nie zmienia faktu, że od nadmiaru wiedzy głowa nie boli… O ile wie się jak ją wykorzystać. 😉

  7. Awatar y0g1
    y0g1

    Nie jestem ekspertem, ale czy z powyższego nie wynika, że należy rozważniej projektować aplikacje webowe.
    W tym przypadku wydaje się, że cookies zostały użyte do wszystkiego, nawet
    do danych dotyczących logowania i sesji, które powinny być przechowywane
    po stronie serwera, a nie przeglądarki. Co do zrzutów różnych wersji obrazu
    systemu plików – jestem zwolennikiem przechowywania kopii na zewnętrznych
    serwerach/nośnikach. Wówczas jest pewność, że w wyniku kompromitacji serwera nie zostały zafałszowane kopie bezpieczeństwa.

    1. Awatar Nowaker
      Nowaker

      Jak sobie wyobrażasz trzymanie danych dot. logowania i sesji wyłącznie po stronie serwera? Głupstwa pleciesz, kolego.

  8. Awatar owczi
    owczi

    Rzadko zdarza mi sie komentowac newsy na linuxnews.pl, ale tym razem powiem co wiem 😉

    Problem polega na tym, ze Jira (chociaz podstawowa wersja jest open-source) mimo ze jest uzywana przez duze organizacje (finansowe np. – Merril Lynch, HSBC, NYSE Euronext), nie ma jednak tak szerokiej rzeszy uzytkownikow jak poczciwa Bugzilla czy Trac, a wiec analiza tego oprogramowania pod wzgledem bezpieczenstwa opiera sie glownie na pracy developerow Atlassian – lub ludzi ktorzy nie maja zamiaru sie dzielic swoimi odkryciami. Luki bezpieczenstwa sa w kazdym oprogramowaniu – ale opis dzialania crackerow uwidacznia rowniez luki bezpieczenstwa w samej organizacji.

    Jesli zwykle przechwycenie cookies pozwolilo na przechwycenie sesji – to najprawdopodobniej uzytkownik mial wlaczona opcje "remember my login on this computer" – pierwszy blad. Admin kliknal "zly URL" uzywajac uprzywilejowanego konta Jira – z zalozenia OK, ale paranoik by tak nie zrobil – czyli niby drugi blad. Dalej – udalo sie zdobyc lokalny dostep – w "brute force" w dzisiejszych czasach nie wierze. Zainstalowano plik .jar (plugin Jira zapewne – inaczej nie da sie dorzucic swojego kodu) ktory pozwolil na dostep do hasel i zainstalowanie backdoora. A wiec Jira (Tomcat / cokolwiek) byla uruchomiona z konta ktore na to pozwolilo (mowie o dostepnie lokalnym – kazdy plugin ma dostep do bazy danych Jiry) – trzeci blad. Jedyne do czego Tomcat / Jira potrzebuje uprawnien to otwarcie niskiego portu (443/80), dalej tylko dostepu do bazy danych i prawa zapisu logow, plikow tymczasowych oraz zalacznikow Jiry. Uzytkownik pod ktorego ID dziala serwer aplikacji po zrzuceniu roota powinien moc robic tylko to co jest niezbednie porzebne do jego dzialania – bron Boze nie powinno to byc normalne konto z shellem. Dalej – jesli ktorys z adminow uzywal tego samego hasla do logowania sie do publicznego serwera www, co haslo roota lub haslo lokalnego konta (ktore jak widac musialo miec albo sudo bez hasla albo autentykacje bazowana na kluczach – kluczach niezabezpieczonych haslem albo zabezpieczonych tym samym haslem) – czwarty blad. Do tego najwyrazniej ich infrastruktura pozwala na skakanie od serwera do serwera po SSH w sieci produkcyjnej bez koniecznosci uzycia dedykowanej infrastruktury zarzadzania – typowy blad malych organizacji, ale jak widac nie tylko – piaty blad.

    Jesli chodzi o hashe hasel – Atlassian uzywaja "Wlasnego" hasha "Atlassian-SHA" ktory jest tak naprawde hashem SHA-512, takze bedzie podatny na ataki slownikowe, ale trudniejsze hasla powinny byc bezpieczne – bardziej martwi baza adresow e-mail. Chociaz Jira sama w sobie nie posiada funkcji blokowania kont po ilus probach (przynajmniej w wersji 3.12 i nizej, ale nie sadze – uzywaja 3.15, dosc starej wersji – 4.1 jest juz na rynku), ale obsluguje zewnetrzne mechanizmy autentykacji – ldap na przykład. Jesli Confluence i Jira uzywaly tej samej bazy uzytkownikow, to zapewne przy uzyciu Atlassian Crowd – aplikacji Single Sign-on, ktora posiada konektory dla Active Directory, LDAP itp (ASF ma tez wlasny produkt, Apache Directory Server). Gdyby uzywali Crowd, hashy hasel nie udalo by sie wyciagnac z samej Jiry.

    Co do ZFS i snapshotow – ciekaw jestem, od kiedy uzywaja ZFS pod FreeBSD i czy lokalnie czy przez siec. Jesli uzywaja rozwiazania typu SAN (iSCSI, FC itp) siedzacego a ZFS, to generalnie OK – ale do wydania stabilnej wersji FreeBSD 8, podczas gdy ZFS byl _w miare_ stabilny, uzywanie ZFS + NFS w duzych srodowiskach bylo koszmarem (podkreslam – duzych – powiedzmy 50TB+, i konkretnie w kombinacji z NFS) – dla mnie na razie jesli ZFS+NFS to (Open)Solaris – chociaz wszystko moze sie zmienic. iSCSI to to nie bylo, bo jak na razie nie ma targetu iSCSI pod FreeBSD.

    Takze oprocz tego, ze byla luka bezpieczenstwa w produktach Atlassian, to generalnie ASF nie utrudnil pracy crackerom. Dobrze, ze nie byly to dane kart kredytowych – a wiec ostatecznie bol w dupie i niewygoda plus duzo zamieszania, ale bez bardziej powaznych strat.

    Ogolnie – nic nowego, kazdej organizacji zdarzaja sie takie rzeczy, ale tylko niewiele z nich mowi o tym otwarcie. Moglo byc gorzej.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *