webspace hacker?

[snoei]

Momenteel vind ik bijna dagelijks in mijn webroot htm / html files welke niet van mijzelf afkomstig zijn.

Ik heb dus het idee dat deze door een vreemde erop gezet worden. Om er zeker van te zijn dat niemand mijn wachtwoorden zou hebben heb ik deze met enige regelmaat veranderd, maar dit mocht niet baten, de bestanden blijven komen. Toen ben ik dus de log-files maar eens gaan nakijken, en wat blijkt nou, d.m.v. het http PUT commando worden de bestanden in de webroot gezet.

Dit heb ik gemeld aan mijn provider, maar die geeft de schuld aan mijzelf. Aldus mijzelf (en de persoon waar ik de site samen mee beheer) ligt de fout weldegelijk bij de provider en niet bij mij. Iedere keer dat ik weer zo'n bestand dump actie tegenkom meld ik dit bij de provider, maar die blijft stug volhouden dat zei daar niets aan kunnen doen... Klopt zoiets, of behoren ze er wel wat aan te kunnen (en dus ook moeten) doen?

[Cardinal]

snoei schreef op maandag 30 mei 2005 @ 16:32:
Momenteel vind ik bijna dagelijks in mijn webroot htm / html files welke niet van mijzelf afkomstig zijn.

Ik heb dus het idee dat deze door een vreemde erop gezet worden. Om er zeker van te zijn dat niemand mijn wachtwoorden zou hebben heb ik deze met enige regelmaat veranderd, maar dit mocht niet baten, de bestanden blijven komen. Toen ben ik dus de log-files maar eens gaan nakijken, en wat blijkt nou, d.m.v. het http PUT commando worden de bestanden in de webroot gezet.

Dit heb ik gemeld aan mijn provider, maar die geeft de schuld aan mijzelf. Aldus mijzelf (en de persoon waar ik de site samen mee beheer) ligt de fout weldegelijk bij de provider en niet bij mij. Iedere keer dat ik weer zo'n bestand dump actie tegenkom meld ik dit bij de provider, maar die blijft stug volhouden dat zei daar niets aan kunnen doen... Klopt zoiets, of behoren ze er wel wat aan te kunnen (en dus ook moeten) doen?

Wat zijn de namen van die mappen en gaat het hier niet om de standaard "Frontpage" mappen

[Koelkasten]

die webspace is dat webspace op een server van je provider?
In dat geval lijkt het me dat iemand jou username en pass heeft of kan uitlezen omdat ze ergens in een script van jou staan. en op die manier filles put in je webroot dir. Als het wachtwoord uit een script komt is het dus alsnog je eigen fout maar indien ook dat niet zo is is het misschien een veiligheids lek van de provider. (dit is nog niet met zekerheid te zeggen hangt nog van veel factoren af)

Indien het webspace is op een server die je zelf beheert dan is het idd je eigen schuld / verantwoording. misschien draaien bepaalde processen onder root die dat niet zouden moeten of heeft de webroot dir de verkeerde (te veel dus) rechten. Of het programma / proces wat je FTP server draait is oud / onveilig of niet goed geconfigureerd.

[snoei]

cardinal808 schreef op maandag 30 mei 2005 @ 16:34:
[...]


Wat zijn de namen van die mappen en gaat het hier niet om de standaard "Frontpage" mappen

nee, het zijn geen standaard frontpagemappen, maar pcb.htm en dan in dat ding teksten ala "xxx was hear for hacking.."

[r0b]

snoei schreef op maandag 30 mei 2005 @ 16:44:
[...]


nee, het zijn geen standaard frontpagemappen, maar pcb.htm en dan in dat ding teksten ala "xxx was hear for hacking.."

En wat voor bestanden staan er (van jou) op die server? Toevallig een aantal lekke PHP files?

[ Voor 3% gewijzigd door r0b op 30-05-2005 16:49 ]

[Verwijderd]

Geef eerst is de volgende info:

Is het een eigen server? --> of een server van je provider

[jeanj]

r0b schreef op maandag 30 mei 2005 @ 16:47:
[...]


En wat voor bestanden staan er (van jou) op die server? Toevallig een aantal lekker PHP files?

Ook mijn eerste gedachte. Of code injectie (perl/mysql/...)

Kun je bij je webserver log files? Of vraag anders aan je provider het log voor jouw server van de dag dat het gebeurd. Je kunt aan de time stamp van de file(s) wel zijn wanneer ze ongeveer zijn aangemaakt.

Beschouw ook je html/php code etc, database en alle gewone files etc als gecompromiteerd, ga dus niet syncen van de webserver naar je zelf toe. Een beetje cracker laat een backdoor/virus/trojen/.../.. achter (of meer

En vergeet niet aangifte te doen, niet dat het helpt, maar gewoon voor de statistieken ....

[McKaamos]

pasgeleden was hier (ik loop momenteel stage bij een niet nader te noemen hostingprovider) iemand die een lek script had. je kon via het bestand een commando op de shell uitvoeren, en daarmee is toen (geloof ik) een IRC bot geinstalleerd op de space van die klant.

[snoei]

tis een server van protagonist.

er draaien asp scripts op. Aldus protagonist is er maar 1 map, genaamd db, geschikt voor schrijfacties. Zelf kunnen we nergens rechten instellen. In deze db map staat dus onze database en worden alle andere bestanden geupload via een script.

Ik kan zelf bij de logfiles en ben er al achter wanneer het gebeurt is.

code:

2005-05-27 12:09:45 dsl**-**-*****.ttnet.net.tr - 209.217.**.*** 80 PUT /pcd.htm - 200 239 633 Microsoft+Data+Access+Internet+Publishing+Provider+DAV+1.1 -
2005-05-27 12:54:12 dsl**-**-*****.ttnet.net.tr - 209.217.**.*** 80 PUT /pcdelisi.htm - 201 293 638 Microsoft+Data+Access+Internet+Publishing+Provider+DAV+1.1 -

deze gegevens (uit de logfiles, maar dan van een tijdje terug) heb ik al een keer naar protagonist gestuurd, maar die blijft de schuld bij mij neerleggen. Voor zover ik (en diegene die de site gemaakt heeft) kan er via de scripts nooit in de webroot geschreven worden. (aangezien de map db de enige met schrijfrechten is)

[ Voor 3% gewijzigd door BalusC op 30-05-2005 17:07 . Reden: aub geen adressen openbaar stellen ]

[BalusC]

Ik heb de hostnames en IP adressen uit je log ff snel gemasked. Het is niet de bedoeling om deze openbaar te stellen

[ Voor 6% gewijzigd door BalusC op 30-05-2005 17:08 ]

[snoei]

oeps, ff niet bij stil gestaan...

[Icey]

Klinkt als een ongepatchte server. Kijk eens naar WebDAV en "Microsoft+Data+Access+Internet+Publishing+Provider+DAV" op google. Wat je kan doen is al jou scriptjes/bestanden eraf halen. Als je dan na een weekje opeens weer die bestanden heb weet je zeker dat het niet aan je server ligt.

http://www.microsoft.com/...ity/bulletin/ms03-007.asp

[ Voor 13% gewijzigd door Icey op 30-05-2005 17:17 ]

[r0b]

Via Google naar hier en dan naar hier et voila:

In the oacs-dav package versions prior to 0.7d webdav method filters can be enabled on the site page root for filesystem access. In the default configuration this will enable unauthenticated access to any files available to the user the AOLserver process is running as.

Wordt dit pakket toevallig gebruikt?

[ Voor 5% gewijzigd door r0b op 30-05-2005 17:19 ]

[snoei]

dat zou ik inderdaad kunnen doen om het zeker te weten, maar helaas kan de site geen week offline....

[PhoeniX-]

Volgens mij zijn 't nogal prutsers bij protagonist. Ik heb voor een vriend van me laatst ook tig Eggdrops op moeten ruimen uit zijn (php) hosting pakket waar verder niets bijzonders op draaide.

[BJD]

Als het om een apache server gaat (wat ik niet vermoed omdat je het over ASP had) zou je kunnen proberen om met een .htaccess de acties in te perken. Ik weet niet inhoevere dat bij IIS kan.
Voor meer info over htaccess files moet je even op de apache site kijken.