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…
Powinni byli uzywac linuxa a nie windows.
… perla a nie javy, vima a nie emacsa, domestosa a nie acze.
Jesli uzywali emacsa to pewnie wjechali im przez sendmaila.
Co do "emacsem przez sendmaila", już wiem jak to zrobili. Fake maila wysłali.. 😉
http://www.chemie.fu-berlin.de/chemnet/use/info/e…
A co to im dało? echo "CC: Blabla [..]"|sendmail -cośtam 😉
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.
Ciekawe ile one ważyły ….
@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.)
Snapshoty ZFS to po prostu zintegrowana z systemem plików funkcjonalność kopii zapasowych, więc Linux (podobnie jak większość systemów) takową posiada.
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…
@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).
Online?
To był komentarz @Kwant.
@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.
@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.
@trasz: snapshot w ZFS na Apache? Nie stać ich na porządnego sana- nie wierzę.
@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".
@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.
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…
@norbert_ramzes
Człowieku, on mówił o czymś co nazywa się w skrócie SAN
http://en.wikipedia.org/wiki/Storage_area_network
> @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.
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.
Spier*alaj z polskimi znakami, ASCII rzadzi!
Jeszcze raz zobaczę u Ciebie takie słowo – BAN.
Mi tam nie przeszkadzają.
Jak sie to robi – ma ktos link do opisu?
@Mieszko Kaczmarczyk: Robi sie przez "zfs rollback pool/filesystem@nazwa-snapshotu".
jak zwykle młot thora (thor.apache.org) rozwiązał wszystkie problemy 😛
Bo usługi typu tinyurl to Zuo.
http://www.longurlplease.com/
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ć.
skoro tinyurl to zło, to ja polecam http://www.shadyurl.com/
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 😉
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 🙂
Co nie zmienia faktu, że od nadmiaru wiedzy głowa nie boli… O ile wie się jak ją wykorzystać. 😉
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.
Jak sobie wyobrażasz trzymanie danych dot. logowania i sesji wyłącznie po stronie serwera? Głupstwa pleciesz, kolego.
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.