Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Panowie tak się właśnie naciełem na:
http://niebezpiecznik.pl/post/backdoor-udajacy-bibl … utils-so-1-9/
mam się bać?
w każdym bądź razie u mnie wygląda to tak:
locate libkeyutils /lib/x86_64-linux-gnu/libkeyutils.so.1 /lib/x86_64-linux-gnu/libkeyutils.so.1.4 /usr/share/doc/libkeyutils1 /usr/share/doc/libkeyutils1/changelog.Debian.gz /usr/share/doc/libkeyutils1/copyright /var/cache/apt/archives/libkeyutils1_1.5.2-2_amd64.deb /var/lib/dpkg/info/libkeyutils1:amd64.list /var/lib/dpkg/info/libkeyutils1:amd64.md5sums /var/lib/dpkg/info/libkeyutils1:amd64.postinst /var/lib/dpkg/info/libkeyutils1:amd64.postrm /var/lib/dpkg/info/libkeyutils1:amd64.shlibs
na serwerze domowym tak:
root@Debian:~# locate libkeyutils /lib/libkeyutils.so.1 /lib/libkeyutils.so.1.3 /usr/share/doc/libkeyutils1 /usr/share/doc/libkeyutils1/changelog.Debian.gz /usr/share/doc/libkeyutils1/copyright /var/lib/dpkg/info/libkeyutils1.list /var/lib/dpkg/info/libkeyutils1.md5sums /var/lib/dpkg/info/libkeyutils1.postinst /var/lib/dpkg/info/libkeyutils1.postrm /var/lib/dpkg/info/libkeyutils1.shlibs
puki co chyba nie mam się czego bać?
najgorsze jest to że jeszcze nie wykryli przyczyny infekcji... Panowie macie jakieś inn wieści?
Offline
zmien nazwe biblioteki :-), jak sie sciagnie od nowa to wiesz ze masz problem.
Skoro wiesz jaki masz problem i wiesz ze go masz to zaczynasz monitorowac polaczenia wychodzace oraz przychodzace, jak biblioteka sie sciagnie to po czasie polaczenia oraz po dacie utrzorzenia biblioteki ( zakadajac ze nie jest modyfikowany) bedziesz w stanie stwierdzic skad to sie ***** wzielo :-).
iptables ubijesz polaczenia na dany ip i jestes tymczasowo w domu.
Dodatkowo koazde polaczenie posiada cos w miano sygnatury w koncu masz mac masz ip, masz port, w przypadku requestu powtornego polaczenia zeby pobrac biblioteke, bedziesz jeszcze mial okreslona sekwencje bitow w pakiecie z requestem :-). ( nawet jezeli request idze przez jakis wlasny byte protocol ).
[edit]
sprawdzenie czy biblioteka istnieje pewnie opiera sie na sprawdzeniu czy plik istnieje, do tego celu na 99.5% idzie proba odczytu z biblioteki czyli proba otworznie pliku,
moza by monitorowac co chce otowrzyc ten plik ( ale nie jestem pewien jak :-), lsof raczej nie uchwycie tego requestu ).
No i jeszcze mozna klepnac plik o takiej samej nazwie
touch nazwa_pliku
potem zobaczyc czy zostanie utworzona nowa biblioteka, czy owy "wajrus" widzac plik o podanej nazwie zaprzestanie działań :-).
Prawde mowiac bardzo chcial bym miec maszynke z tym syfem zeby sie z nim pobawic po swojemu :-).
Ostatnio edytowany przez gindek (2013-02-23 01:16:23)
Offline
Z 3 i 4 na końcu są z repowego libkeyutils1 (zależnie od wersji), tam o taki z 9 na końcu chodzi.
Offline
Właśnie , nikt nie stwierdził że ma się nazywać inaczej niż libkeyutils.so.1.9. Niektórzy piszą że to może być wina zawirusowanych Windowsów na których dochodzi do przechwycenia hasła roota przy logowaniu na serwery z Linuksem .
http://www.webhostingtalk.com/showpost.php?p=8567829&postcount=978
Są i inne zdania ;
http://www.webhostingtalk.com/showpost.php?p=8566703&postcount=845
Tu jak usunąć by nie instalowało się na nowo , gdy się to ma , nie sprawdzałem bo nie mam .
http://www.webhostingtalk.com/showpost.php?p=8566297&postcount=795
Offline
To nie jest dziura w ssh.
Prawdopodobnie dziura jest w jaju, dzięki czemu można z poziomu np php czy Apacha wbić się na konto roota, i podmienić bibliotekę.
Jest kilka sposobów, żeby nawet wyskoczyć z chroota przy takiej eskalacji uprawnień.
Zwłaszcza, że dotyczy to systemów RHEL, które miały trochę problemów z uprawnieniami plików w /proc, i oczywiście oficjalnie mają włączonego SELINUXA, którego jednak niewielu potrafi skonfigurować w trybie strict, żeby chronił cały system.
Offline
Jacekalex napisał(-a):
To nie jest dziura w ssh.
Prawdopodobnie dziura jest w jaju
To jest backdoor dla SSH. Gdzie jest dziura nikt nie wie, Ty od razu wyrokujesz, że pewnie w jądrze i PHP/Apache, ja śmiało stwierdzę, że pewnie w Fiacie 126p!
A równie dobrze żadnej dziury może nie być, autor backdoora mógł po prostu założyć darmowy serwer shelli, osobiście i celowo go zbackdoorował, po czym łowił logując się na podsłuchane hasła na roota na inne serwery lub próbując zwrotnie zalogować się na roota korzystając z hasła użytkownika serwera. Albo postawił hosting ze zbackdoorowanymi wymienionymi panelami administracyjnymi (dalej ta sama zasada). I kula śnieżna się toczy.
Offline
To jest backdoor dla SSH. Gdzie jest dziura nikt nie wie, Ty od razu wyrokujesz, że pewnie w jądrze i PHP/Apache, ja śmiało stwierdzę, że pewnie w Fiacie 126p!
W tym punkcie zgodzić się z tobą nie mogę, z prostego powodu.
Kto z użyszkodników systemowych ma prawo do zmiany tej biblioteki:
ls -l /lib64/libkeyutils.so.1.4 -rwxr-xr-x. 1 root root 38402 01-04 03:51 /lib64/libkeyutils.so.1.4
Czy mnie się zdaje, czy tylko root?
Jaki moduł Linuxa nadzoruje uprawnienia użytkowników w zwykłym standardowym Debianie?
Czy mnie się zdaje, czy tylko root?
A kto ma takie uprawnienia w RHEL, gdzie od kopa po instalacji masz włączonego SELINUXA -tryb targeted?
Krasnoludki?
Moim zdaniem, w którymś momencie wykorzystano dziurę pozwalającą na eskalację uprawnień.
Identyczna sprawa, jak dziura w Debianie, opisana tutaj:
http://zaufanatrzeciastrona.pl/post/linuxowy-rootki … pakietow-tcp/
Ciekawa sprawa? Dotyczy RHEL, ale nie dotyczy Fedory?
Czym się różni Fedora od RHEL?
Moim zdaniem, prawdopodobnie dziura była w kernelu 2.6.32.
Pewnie zalatana w którejs kolejnej wersji tego jajka, wychodzą praktycznie co tydzień.
Większości Linuxów już nie dotyczy, bo już dawno nikt z użytkowników np Debiana nie używa jajka 3.6.32, o ile np wie, co to backporty.
Kiedy ja ostatnio miałem 2.6.32? W Ubuntu 10.0.4? Kiedy to było?
Natomiast, jak znam administratorów różnych serwerów, to panuje zasada, jak działa, lepiej nie ruszać.
Zazwyczaj mają ważniejsze sprawy na głowie. ;)
I nie zawsze pamięta się o regularnych aktualizacjach.
Osobiście znam jeden serwer ( powszechnie znany), gdzie kilka dni temu widziałem php 5.3.15 - wyleciało z Gentoo z powodu dziur bezpieczeństwa, i jajo 2.6.33.2.
Zabytkowa i od dawna nie aktualizowana wersja, na szczęście dozbrojona łatką grsec, niestety starą jak sam kernel.
Oczywiście RHEL to duża i bogata firma, i tłumaczenie jest takie same, jak w M$
- u nas? to niemożliwe, to użytkownicy administratorzy mają zainfekowane komputery i dlatego.
Wszystkie firmy z branży IT mają takie samo tłumaczenie, opracowane i przećwiczone miliony razy przez działy PR.
Pozdrawiam
;-)
Offline
faktycznie nikt jeszcze nie zdjagnozował jak to badziewie się na tych serwerach znalazło... i to jest chyba w tym wszystkim najbardziej niepokojące.
Offline
chyba coś już wiadomo:
http://blog.sucuri.net/2013/02/cpanel-inc-server-compromised.html
Link z niebezpiecznika
Offline
Debian Squeezy domyślnie po zainstalowaniu pakietu libkeyutils1 tworzy biblioteki
/lib/libkeyutils.so.1 /lib/libkeyutils.so.1.3
http://packages.debian.org/search?suite=squeeze& … ibkeyutils.so.
Offline
lukaz1987: dzięki za info!
Offline
Ta biblioteka też występuję w innych gałęziach: wheezy, sid. Bez tej biblioteki nie mogłem dzisiaj włączyć programu pgadmin3.
debian:/home/lukasz# pgadmin3 pgadmin3: error while loading shared libraries: libkeyutils.so.1: cannot open shared object file: No such file or directory
Offline
Czyli wszystkie Debiany zainfekowane. ;)
Offline
Ta biblioteka jest w porządku.
Offline
Wiem, pisałem o tym kilka postów wyżej. ;)
Offline
Ehhh. Najprostszy sposób że sprawdzić czy lib należy do tych podejrzanych czy jest czysty:
strings PODEJRZANY_LIB | egrep 'connect|socket|inet_ntoa|gethostbyname'
Jak coś zwróci to system jest skompromitowany i nadaje się do reinstalki ;]
Do tego syf mógł się wbić przez exima lub w spób znacznie bardziej prozainczy: zainfekowany system z M$ na pokładzie
sznurek 1
sznurek 2
sznurek 3
sprawdzenie M$
A wystarczy poszperać 5 minut na google i problem rozwiazany
nilfheim ~ # strings /lib32/libkeyutils-1.2.so | egrep 'connect|socket|inet_ntoa|gethostbyname' nilfheim ~ # valhalla ~ # strings /lib32/libkeyutils.so.1.4 | egrep 'connect|socket|inet_ntoa|gethostbyname' valhalla ~ # winnetou@wigwam ~ $ strings /lib32/libkeyutils.so.1.4 | egrep 'connect|socket|inet_ntoa|gethostbyname' winnetou@wigwam ~ $
Offline
Coś w temacie http://websecurity.pl/nowy-wirus-atakuje-serwery-linux/
Offline
W artykule http://zaufanatrzeciastrona.pl/post/wlamanie-do-ser … ikow-cpanelu/ wskazano możliwą drogę, jaką rootkit mógł dostawać się do systemów.
Offline
Te tytuły ciągle wprowadzają w błąd. To nie są dziury w ssh tylko w różnego rodzaju panelach (tu np. w cPanel).
Offline
Racja, niepotrzebnie tytuł jak z onetu... sorki za to.
Offline
Luz. Akurat miałem na myśli całe internety trąbiące o backdoorach w Linuksie :)
Ostatnio edytowany przez yossarian (2013-03-13 20:00:42)
Offline
Szczerze?
Ja bym zrobił backup configów, stron i zaorał serwer od nowa....
Offline
Bitels napisał(-a):
Racja, niepotrzebnie tytuł jak z onetu... sorki za to.
Zawsze możesz zmienić.
Offline
nie wiem czy jest sens... wszyscy którzy tu zaglądają i ich to interesuje już pewnie i tak przeczytali co chcieli, a zmieniając tytuł mógł bym tylko zmarnować bym ich cenny czas bo zobaczyli by "nowy tytuł". chociaż z drugiej strony pewnie i tak to robię offtopując ;)
Offline