[hack-alert] zatron?

[TimmeStein]

Ik log net in op mijn thuisbak. Zie ik dat daar onder user apache een binary draait met naam "Zatron". Tevens draaide er een apache process met daarachter een ip-adres zag ik met ps (ip-adres resolvde naar een of ander gov domein).

Nu kan ik dus niet meer inloggen
Wel maar eventjes vanaf me werk met een 100mbit link mijn eigen bak maar ff flooden (als ik er niet bij kan, kan niemand erbij).

De OS was stock RH7.3 met stock apache. Ik wil geen commentaar van iemand dat RH kut is. Want dit is, denk ik, een nieuwe Apache exploit. Aangezien het enige wat Google vindt over Zatron is dat het een Duitse electronica boer is.

Heeft iemand anders nog wat gehoord over Zatron (cert.org weet er ook nog niets van).

Updaten dus weer die Apache's.

Over-en-uit...

[ Voor 0% gewijzigd door TimmeStein op 11-09-2002 09:57 . Reden: typo's ]

[Creepy]

Updaten die apache? Of updaten die apaches in RH7? (dat Apache in de ene distributie exploitable is, wil niet altijd zeggen dat dat in een andere distributie ook zo is.. een andere distributie zou wel eens een andere versie kunnen draaien he..)

Als je m.b.v. een exploit 1 of andere executable op een remote machine kan starten, dan kan je die executable ook elke willekeurige naam geven. Dus de naam zatron zegt waarschijnlijk helemaal niks over de executable die draaide.

[TimmeStein]

Creepy schreef op 11 september 2002 @ 10:01:
Updaten die apache? Of updaten die apaches in RH7? (dat Apache in de ene distributie exploitable is, wil niet altijd zeggen dat dat in een andere distributie ook zo is.. een andere distributie zou wel eens een andere versie kunnen draaien he..)

Das waar, maar toch.

Als je m.b.v. een exploit 1 of andere executable op een remote machine kan starten, dan kan je die executable ook elke willekeurige naam geven. Dus de naam zatron zegt waarschijnlijk helemaal niks over de executable die draaide.

Kan. Maar komt in praktijk niet vaak voor. Binairies die draaien hebben nagenoeg altijd dezelfde naam. Of een paar verschillende. Maar ze sturen echt niet een woordenboek mee om af en toe een naampje uit te kiezen.

[Verwijderd]

het is zo dat apache 1.3.23 word gebruikt door redhat up2date, de SSL exploit is daar gepachted, maar waarschijnlijk zaten er dus meer fouten in 1.3.23 of heb je handmatig een upgrade gemaakt naar 1.3.26?

[Mark]

Als het onder de Apache user draait wil dit lang niet altijd zeggen dat jouw Apache ge-exploited is. Het kan ook een lek script zijn welke op jou machine staat welke oa. filetransfers toelaat. Dit is 99 van de 100 keer de oorzaak als je processen onder de Apache user ziet.
Verder wil de naam echt helemaal niks zeggen, een gemiddelde moderne r00tkit doet dit zelfs al automatisch.

Geef eerst eens wat versienummers weg voordat je gaat roepen dat mensen Apache moeten updaten.

[TimmeStein]

Zoals ik net al zei: "Ik kan nu niet bij mijn machine meer komen."
Eenmaal thuis aangekomen zal ik verder onderzoek doen.

[Verwijderd]

*sigh*

stock apache heeft een paar vulnerabilitys gehad sinds dat stock rh7.3 is uitgekomen. Hetzelfde geld voor je OpenSSH, en vast nog wel een paar andere apps (die mischien in de stock configuration wel per default draaien).

Feit is dat die machine stock is, en de gevaren daarvan heb je nu ondervonden. Na de reinstall gelijk ff je systeem up-to-date brengen en vooral houden.

En nee, redhat is niet k*t, als het goed onderhouden is ...

[Verwijderd]

Verwijderd schreef op 11 september 2002 @ 12:28:
*sigh*

stock apache heeft een paar vulnerabilitys gehad sinds dat stock rh7.3 is uitgekomen. Hetzelfde geld voor je OpenSSH, en vast nog wel een paar andere apps (die mischien in de stock configuration wel per default draaien).

Feit is dat die machine stock is, en de gevaren daarvan heb je nu ondervonden. Na de reinstall gelijk ff je systeem up-to-date brengen en vooral houden.

En nee, redhat is niet k*t, als het goed onderhouden is ...

sluit in mij geheel op aan als RHCE

distro maakt nl niet zoveel uit het ligt er aan wat de systeembeheerder ermee doet weet hij wat van security of niet.

sry dude maar een niet uptodate systeem op inet zetten is niet slim
geld voor alle software en OSen

[TimmeStein]

Waar de f*ck ben ik nou weer de pineut van.
Uit iptraf:

code:

UDP (88 bytes) from 213.25.231.39:2002 to <mijn-ip>:2002 on ppp0
ICMP dest unrch (port) (116 bytes) from <mijn-ip> to 213.25.231.39 on ppp0

Ik krijg van heeeeel veeeeeel hosts datagrammen richting mijn machine en mijn poort 2002.



p.s.:

code:

[root@timmestein root]# host 213.25.231.39
39.231.25.213.in-addr.arpa. domain name pointer pa39.mogila.sdi.tpnet.pl.

[ Voor 0% gewijzigd door TimmeStein op 11-09-2002 16:46 . Reden: p.s. erbij ]

[VROEM!]

Naja, als alles dat naar je bak gaat van 1 host komt, kun je die ook wellicht flooden

Of mail daarvan de webmaster om te vragen of die het geouwehoer even wil stilleggen

[_JGC_]

iptables -s 213.25.231.39 -j DROP

zoiets?

[moto-moi]

* moto-moi zou maar heel snel het volgende doen :

1) chkrootkit downloaden (link te vinden op http://freshmeat.net )
2) Machine van het internet afhalen
3) chkrootkit installeren & draaien.

[Bart]

ik hoorde gister over apache exploit waarbij je dus de id van apache krijgt.

Dus wat betreft dat process wat op apache id draait klopt dat wel. Verder weet ik er niet veel vanaf. Wat je ook kan doen is je machine ff nmappen op alle poorten.

http://www.insecure.org

Gebruik nmap -sT -p 1-65535 <ip> -vv voor volledige scan.

[Blubber]

en wat schiet je daar mee op?

[Creepy]

Blubber schreef op 11 september 2002 @ 18:12:
en wat schiet je daar mee op?

Dan zie je precies welke poorten opstaan voor de buitenwereld.
Een netstat -ap wil daarbij ook wel eens helpen om te zien welke processen welke poorten en sockets hebben open staan.

[serkoon]

Op de incidents list (zie insecure.org bijv) zijn de laatste tijd dezelfde meldingen te lezen: veel udp verkeer op poort 2002..

Apache upgraden en boel fixen.

[TimmeStein]

Update

Volgens de nieuwste versie van chkrootkit ben ik niet ge-rootkit. Heb een zooi sites na lopen zoeken. Er zijn inderdaad wat meldingen van veel udp verkeer op poort 2002 (o.a. een Cisco server die op die poort zou moeten draaien met een exploit). Ik krijg nu 100 van deze pakketjes per seconde binnen. Toen ik vanmiddag nog op mijn stage zat kon ik niet inloggen omdat mijn machine lekker op al die udp pakketten stond te antwoorden dat die service niet available was. En dat is natuurlijk altijd lekker voor je upstream met een asymmetrische verbinding als ADSL.

Firewall aangepast. Ben er nog niet helemaal achter hoe dat met die apache zat. Maar die udp-storm is wel te verklaren. Nu nog die Zatron (owner apache)uitzoeken.

[Verwijderd]

gewoon een mailtje naar [e-mail] en kijken hoe snel jij zijn verbinding down hebt.

edit: ik zie zojuist dat dat in polen is... wellicht niet zo effectief.

[TimmeStein]

Verwijderd schreef op 11 september 2002 @ 20:41:
gewoon een mailtje naar [e-mail] en kijken hoe snel jij zijn verbinding down hebt.

edit: ik zie zojuist dat dat in polen is... wellicht niet zo effectief.

o.a. vanuit Polen. De halve wereld stuurt me datagrammen.

[Wilke]

Wat dan apart is: waarom stuurt de halve wereld juist JOU data-grammen...ik bedoel, het is me hier nog niet opgevallen, die poort 2002.

En geloof me: met onze bagger-upstream zou dat me heel snel opvallen!

[TimmeStein]

Wilke schreef op 12 september 2002 @ 01:52:
Wat dan apart is: waarom stuurt de halve wereld juist JOU data-grammen...ik bedoel, het is me hier nog niet opgevallen, die poort 2002.

En geloof me: met onze bagger-upstream zou dat me heel snel opvallen!

Misschien stuurt de halve wereld niet JUIST mij datagrammen, maar stuurt de halve wereld OOK mij datagrammen.

Het wordt er allemaal niet duidelijker op. Gister met XS4All gebeld. Die wisten van niets. Er is nog niet een nieuwe worm ofzo ontdekt.

[Verwijderd]

Dat chkrootkit niks kan vinden wil nog niet zeggen dat er helemaal niks aan de hand is. Chkrootkit herkend namelijk niet elke rootkit die in het wild voorkomt en ik heb dus ook wat rootkits gezien (nieuwste versie van adore) die zich specifiek voor chkrootkit kunnen verbergen. Zowiezo moet je chkrootkit ook draaien met een set binaries (zoals ls, ps ,enz) die te vertrouwen zijn. De binaries op je machine zijn mogelijk vervangen voor speciale versies die het rootkit proces verbergen. De standaard check die door chkrootkit wordt gedaan op de binaries op je machine is vooral het greppen naar bepaalde strings, niet echt afdoende dus.

[actieplan]
Dus even de manual van chkrootkit gaan lezen, even een korten tcp dump maken van je netwerk verkeer (liefst met body van UDP pakketten erbij) en dan heel snel die bak van het internet af halen en dan nog eens goed controleren met chkrootkit. Logfiles doorspitten en zowiezo een complete reinstall voor je die bak weer aan het internet hangt.

Subscribe je ook op de redhat security mailing list en eventueel bugtraq (verplicht voer voor elke admin).

En laat ons even weten wat je vindt, want dit soort dingen zijn altijd erg interessant om te onderzoeken.

[ Voor 0% gewijzigd door Verwijderd op 12-09-2002 15:33 . Reden: typo's ]

[Verwijderd]

Het zal er niets mee te maken hebben maar ik had gisteren (voor de eerste keer) ook iets heel eigenaardigs (ik heb trouwens ook apache draaien, ik weet niet of het daar mee te maken heeft). Ik zet het even in dit topic want een nieuw topic hiervoor openen lijkt me overdreven.

Mn box draait super stabiel en ik heb nog geen problemen gehad. Tot gisteravond. Ik had een newserver sessie open staan en een browser window en een terminal venster. Ik ging boodschappen doen en kwam 20 minuten later terug. Mn systeem zat niet in de screensaver en bij de eerste blik op de monitor zag ik een venster openstaan met daarin (ik kon het zo gauw allemaal niet goed lezen) CPU exception errors en er liepen regels (vrij traag) door het scherm heen plus er waren wat waarden die van 1 naar 100 liepen. Het was gewoon een soort van beheerst X debug venster waar netjes alleerlei messages voorbij kwamen. Ik was er helemaal gebiologeerd van De laatste melding was dat er een exception was en dat het systeem zou rebooten. En ja hoor daar ging ie! Naja ik dacht laat maar gaan. Bij het opnieuw booten kreeg ik zo'n ascii tekening, mannetje met verdriet smiley en de tekst no operating system found. PC uitgezet met de schakelaar en daarna ging alles weer ok, moest wel fschk e.d. Ik werk er nu weer mee en geen problemen verder.

Heel raar. Ik bedoel whatever het is geweest een DOS? BUG? het is geen reclame voor Linux dit soort dingen. Naja ik meld het maar even misschien een nieuw soort DOS ofzo je weet het maar nooit. Ik heb dit nog niet eerder gehad. Mn machine is 100 procent goed gewoon

[Verwijderd]

Klinkt idd niet erg gezond. Ik zou die bak maar eens goed nakijken , als ik jouw was.
In bovenstaande replies vind je waarnaar je kan kijken.
Laat ons het weten aub als je wat vind , dat blijft interessant

[Verwijderd]

TimmeStein schreef op 11 september 2002 @ 16:45:
Waar de f*ck ben ik nou weer de pineut van.
Uit iptraf:

code:

UDP (88 bytes) from 213.25.231.39:2002 to <mijn-ip>:2002 on ppp0
ICMP dest unrch (port) (116 bytes) from <mijn-ip> to 213.25.231.39 on ppp0

Ik krijg van heeeeel veeeeeel hosts datagrammen richting mijn machine en mijn poort 2002.



p.s.:

code:

[root@timmestein root]# host 213.25.231.39
39.231.25.213.in-addr.arpa. domain name pointer pa39.mogila.sdi.tpnet.pl.

Hmm, zag net naar aanleiding van het bericht van RonaldH dat er een worm is die een openssl bug uitbuit. Op poort UDP 2002

http://online.securityfoc...9/2002-09-10/2002-09-16/2

en de bug die wordt uigebuit:
http://online.securityfocus.com/bid/5363

Dus topicstarter zo snel mogelijk die machine van het internet af (als je dat al niet had gedaan).

[TimmeStein]

Kreeg net een mail van XS4all (wat een goeie club toch heh) dat mijn systeem vulnerable zou kunnen zijn. Daar stond ook die link in naar securityfocus. Ik ben trouwens niet de pineut, maar enkel slachtoffer van die udp/2002 pakketjes.

[Verwijderd]

hoe kan je dan zien dat je vulnerable bent? ben helemaal up2date volgens redhatnetwork, maar ik vertrouw het niet. RedHat doet er meestal even over voordat een upgrade grondig getest is en uitgeeft. kan ik iets in de access_log zien of moet ik met een packetsniffer op poort 2002 gaan kijken voor een dag ofzo.

[TimmeStein]

Als je apache met SSL (port 443) draait moet je je openSSL updaten.
Als je geen HTTPS gebruikt hoef je dus nergens bang voor te zijn.

Je moet ff kijken of er iets op port 2002 staat te luisteren: "netstat -a".
Als hier staat dat udp port 2002 open staat ben je al de pineut.