Spørsmål:
Hvordan kan en PHP-fil legges til igjen og igjen til det hackede nettstedet mitt?
Victoria Ruiz
2016-11-04 00:35:10 UTC
view on stackexchange narkive permalink

Jeg har en delt hostingplan (jeg vet, jeg vet) på GoDaddy, og alle filene i den er blitt hacket. Det er flere nettsteder i planen, hver av dem har en mappe. Mappene og undermappene til hvert nettsted er fulle av hackede filer, og det samme er mappene over public_html.

Jeg har slettet mange filer med skadelig kode, og jeg føler at jeg har slettet alt bortsett fra at det er en xm1rpc.php -fil som dukker opp igjen 10 sekunder etter at jeg har slettet den. .htaccess , configuration.php og index.php , alt sammen i roten til et av nettstedene, ser ut til å bli smittet veldig raskt også .

Hvordan klarer de å gjøre det? Jeg har søkt etter crons i kontrollpanelet, endret passord (FTP, admin, etc), hva skal jeg se etter? Slik at du vet, er nettstedene Joomla og WordPress.

Du behandler symptomene, ikke årsaken.De har en jevn bakdør på en eller annen måte, enten det er gjennom kompromitterte administratoropplysninger, plugins eller skjemaer på nettstedet ditt.Det er ingen måte å vite sikkert hvordan de kommer inn uten omfattende kodegjennomgang eller pakkefangst, men jeg vil begynne å fylle hullene ved å deaktivere eventuelle "snazzy" plugins som ikke er 1000% nødvendige.
Du kan også slette filene skadelig programvare oppretter, men har du sjekket ALLE kjernefilene for kodemodifikasjoner?Bare fordi du slettet alle nye, åpenbart falske filer, betyr ikke det at de ikke endret wp-config eller noen annen kjernefil under den første infeksjonen.
Takk for informasjonen, Johnny.Jeg skal prøve å deaktivere plugins.Jeg ble kvitt noen gamle ting allerede, og jeg har sjekket for mange bakdører i filer som wp-config og gjenopprettet dem til de originale filene.Det faktum at det bare tar 10 sekunder å få den infiserte filen tilbake, får meg til å tro at de enten bomber nettstedet eller har en cron hvert 10. sekund, ville det være fornuftig?Eller er det noen annen måte for hacket å komme tilbake så raskt?
Fremgangsmåten du har tatt er gode.Er det noen måte for deg å stenge nettstedet helt - slå av offentlig tilgang, midlertidig slette joomla og wordpress, den slags ting?
Det tradisjonelle rådet er å drepe en infisert maskin og sakte begynne å gjenopprette sikkerhetskopier på en ny når du bekrefter at sikkerhetskopiene dine er rene.Jeg vet ikke hvor enkelt det ville være for deg å gjøre, men det er det tryggeste alternativet.
@vic3685 Jepp.Du mangler fortsatt noe.Hvis du blir reinfisert så raskt, er det noe vedvarende på systemet ditt, og ringer hjem for en ny nyttelast.Det er svært lite sannsynlig at du blir angrepet hvert 10. sekund (kjører du RevSlider ved en tilfeldighet? Det er en gjeldende utnyttelse for det).I tillegg, hvis du har to forskjellige CMSer som kjører på samme forekomst, er det 2x angrepsoverflaten.Det er ikke et optimalt oppsett i det hele tatt ...
Jeg ville sikkerhetskopiere hele siden, endre passordet og slette alt innholdet.hvis filene fremdeles vises igjen, bør du få pengene tilbake fra verten og finne noe mer pålitelig.
Takk alle for innspill.Det ser ut til at det vil ta en stund for meg å finne ut hva som var den virkelige årsaken, og jeg vil begynne å skille hosting-kontoene for alle nettsteder.Forhåpentligvis blir de ikke infisert på nytt, og hvis de gjør det, håper jeg det bare er en av dem!
Din lokale maskin kan være infisert, så når du kobler til via FTP, laster den opp den 'xm1rpc.php' og andre klynger.
Mulig duplikat av [Hvordan håndterer jeg en kompromittert server?] (Http://security.stackexchange.com/questions/39231/how-do-i-deal-with-a-compromised-server)
Mulig duplikat av [Nylig hack henger sammen med alle javascript-filer] (http://security.stackexchange.com/questions/121137/recent-hack-appends-to-all-javascript-files)
Har du tilgang til WHM eller Cpanel?
Fem svar:
user129555
2016-11-04 01:08:03 UTC
view on stackexchange narkive permalink

Du kan ha noen bakdør i databasen som innebygd HTML eller Javascript.

Hvis du er sikker på at du har fjernet alt fra filene, kan du se inn i databasen.

Også , sørg for at du oppgraderer begge CMS-ene til de nyeste versjonene og deaktiverer / fjerner alle ubrukte moduler i begge, slik at de ikke vil hacke deg igjen på samme måte. hvis noen virkelig bomber deg.

Out of Band
2016-11-04 01:37:53 UTC
view on stackexchange narkive permalink

Sjekk først tilgangsloggene til nettstedene dine for å bevise for deg selv at du ikke blir infisert på nytt gjennom den samme angrepsvektoren som fikk deg smittet. Hvis du ikke ser forespørsler som kommer hvert tiende sekund, bør det være nok for nå.

Du sa at det ikke er mistenkelige cronjobs. Hvordan sjekket du dette? Er du sikker på at cronjobs alle dukker opp på kontrollpanelet du nevnte, selv om de ikke ble opprettet gjennom kontrollpanelet?

Hvis det virkelig ikke er noen cron-jobber, er den neste sannsynlige årsaken til reinfeksjon. er en ondsinnet prosess som fortsatt kjører på serveren og fortsetter å sove i ti sekunder, og deretter sjekker for eksistensen av filene og gjenskaper dem hvis de ikke er der lenger.

Hvis det er det som skjer, da er det også sannsynlig at du fortsatt har en kopi av de ondsinnede filene på serveren et sted (enten det, eller de lastes ned fra en ekstern kilde). Ikke glem å sjekke / tmp-katalogen for skjulte underkataloger. / tmp er et sannsynlig sted for skadelig programvare å bo på fordi det vanligvis kan skrives over hele verden.

Noe skadelig programvare bruker et pent triks på unix-systemer for å skjule filene sine: kjøringsprosessen åpner filene og fjerner dem deretter, noe som gjør dem usynlige for kommandoer som ls og find, men fordi de er åpne , de er fremdeles der (til prosessen som holder dem åpne avsluttes). Det gode er at siden de er åpne, vil de dukke opp under /proc.

Du må finne denne prosessen og drepe den. Jeg vet ikke noe om GoDaddy, har du skalltilgang? I så fall kan du bruke ps-kommandoen til å vise aktive prosesser som kjører under brukernavnet ditt.

Dette er imidlertid alt meningsløst med mindre du finner infeksjonsvektoren. Sjekk tilgangsloggene for veldig lange nettadresser som inneholder tilfeldige strenger først. Dette er ganske enkelt hvis du vet hvordan du bruker grep og regulære uttrykk. Hvis du finner noe som ser mistenkelig ut, kan du google URL-en. dette kan gi deg en beskrivelse av sikkerhetshullet som gjorde det første bruddet mulig, og det er det du trenger å vite for å sikre systemet.

Takk for innspillene dine, Pascal!Hvordan kan jeg ellers se etter cron-jobber?
hvis du ikke har shell-tilgang, er det veldig komplisert og innebærer å skrive et php-skript som kjører lokale systemkommandoer og rør resultatet i skriptutgangen.Med shell-tilgang, bruk "crontab -l" og sjekk /etc/cron.d-katalogene (kan også være plassert et annet sted, avhengig av serverkonfigurasjonen din).
GAD3R
2016-11-04 02:13:38 UTC
view on stackexchange narkive permalink

Hvordan kan en fil legges til om og om igjen til nettstedet mitt?

Å utnytte "Privilege Escalation-feilen" på systemet / programmene

A bruker med en lavprivilegert konto kan få root-privilegiet ved å utnytte Privilege Escalation-feilen, den ondsinnede brukeren (med root-tilgang) tar full kontroll over databasen ved å legge til, slette filer ....

Eksempel: det nye sikkerhetsproblemet oppdaget på LAMP (Linux-Apache-MySQL-PHP) 01.11.2016 CVE-2016-6664 (MySQL og MariaDB)

Beskrivelse

MySQL-baserte databaser, inkludert MySQL, MariaDB og PerconaDB, påvirkes av et sårbarhet for opptrapping av privilegier som kan la angripere som har fått tilgang til mysql-systembrukeren ytterligere eskalere sin rettighet til rotbrukeren, slik at de kan kompromittere systemet. sårbarhet stammer fra usikker filhåndtering av feillogger og andre filer.

Jeg antar at hvis det var tilfelle, trenger de ikke legge til flere ondsinnede filer.Hvorfor trenger de det?Hvis de allerede kompromitterte systemet ved hjelp av SQL DB-sårbarhet, ville det ikke være behov for ytterligere handlinger for noe annet formål.
KanekiDev
2016-11-10 21:08:23 UTC
view on stackexchange narkive permalink

Det er ganske vanskelig å svare på bare informasjonen du gir.

Noen kamerater sa at problemet ditt kan være en SQL-sårbarhet i databaser, men jeg tror ikke det (jeg kan fortsatt ha feil). Som om det var tilfelle, ville ingen ytterligere filinjeksjon være nødvendig for å få tilgang til systemet ditt.

Det er ganske riktig at det er en sjanse for at noen prøver å utnytte noen av de gjeldende sårbarhetene på siden din for å få tilgang.

Så, det meste jeg kan si er:

  • Den mest sannsynlige årsaken (antar jeg) er en RFI-sårbarhet (Remote File Inclusion), i PHP dynamisk nettsider er ganske vanlig.
  • Joomla som mange av CMS-motorer (som @ user129555 sa) er ganske sårbare, og nye feil / sårbarheter blir funnet så raskt.
  • Det BESTE du kan gjøre er:

    1. Sjekk webfilene dine og tillatelsene (noen CMS krever at noen filer slettes, eller endre tillatelsene etter den første konfigurasjonen for sikkerhet).
    2. Se etter mulige sårbarheter ved å google (eller bruke sider eller offentlige databaser som CVE).
    3. Bruk hvilken som helst motor for å finne noen sårbarheter ( det er tonnevis for CMS).
    4. Oppdater alt (Joomla) til de siste versjonene, til f ix de fleste sårbarheter.

Lykke til!

Lester T.
2016-11-15 20:24:40 UTC
view on stackexchange narkive permalink

Din xm1rpc.php kom fra wordpress. Følg disse trinnene, det løser problemet ditt. Gå rett til poenget og følg trinnene nedenfor for å fikse det. Dette er et slags kiddie-arbeid, ikke kompliser det for mye ved å gå overalt

  1. Gå til hver wordpress du har tilgang til. Last ned dette pluginet i hver wordpress og bruk dette til å skanne og fjerne skadelig programvare.
  2. Oppdater wordpress til den nyeste versjonen for hvert nettsted.
  3. Endre passord til alle wordpress-sider, cpanel og whm (hvis du har)

Hvordan fungerer det? Din /wp-includes/load.php er infisert. Dette vil fortsette å lage den ondsinnede php-filen som vil infisere .htaccess, .configuration.php og index.php



Denne spørsmålet ble automatisk oversatt fra engelsk.Det opprinnelige innholdet er tilgjengelig på stackexchange, som vi takker for cc by-sa 3.0-lisensen den distribueres under.
Loading...