FS-data norchalanta?
 

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.

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?

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.

"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.

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.

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.

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.

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.

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. :)

Jo, precis, det är omöjligt att säga exakt vad som hänt. Även om svaret från F5-data var ett typiskt goddag yxskaft-svar som tyvärr är ganska vanligt i supportsammanhang så har de ingen anledning att undersöka en sådan sak närmare på ett enskilt konto. Misstänker de att felet ligger hos dom så ska de givetvis titta närmare på det hela men nu finns det ingenting alls som tyder på det.

Om det sker på fler konton får man börja undersöka.
Det är ganska tydligt i det här fallet att det är lösenordet eller dåliga chmod som gjort att de kunnat skriva över.

Antingen genom någon form av exekviering via era script, eller en PUT via http om ni har felaktiga chmod's.

Detta är rätt vanligt förekommande säkerhetshål på kundens sida som nyttjas för att sprida maskar på det här viset.

Körs php i safe mode? Kan du köra include() eller fread() på andra kontos filer?

Finns det verkligen något vettigt webbhotell som har allow_url_include på?

Om filerna är på samma server behövs inte url include, räcker med vanlig fil include.

Dvs om du har ditt konto på /home/mittkonto/www kan du där köra
include('/home/annatkonto/www/filsominkluderas.php');
samt köra fwrite eller fopen på samma fil.

Och du kan ju inte slå av include på en server, då funkar ju nästan ingenting, däremot safe mode och lite annat måste till.

Först skriver du om ftp-loggen, men sedan är det inte där du har tittat?

Ja, FTP är ett osäkert protokoll och lösenord skickas i klartext, men intrång sker i princip aldrig via FTP.

Förmodligen är det ett säkerhetshål i din phpkod eller i värsta fall i någon annan kunds phpkod på samma server.

Det senaste året är det många som har drabbats och det är tydligen så att hackarna verkar ha kommit åt FTP-uppgifterna. Detta har skett i många olika system. Är datorn eller servern övervakad så bör det inte vara några problem att komma över FTP-uppgifter som skickas i klartext, inte heller om du har drabbats av en keylogger.

Tack för allt intresse.
Det är väldigt skumt.

Jag förstår verkligen inte hur någon skulle kunna komma åt några inloggningsuppgifter via cms:ett.

Även om de på något vis skulle kunna göra en SQL-Injektion, så finns det inte känsliga uppgifter sparade någonstans.

Angående chmod, så går det inte att skriva till någon mapp, förutom i en mapp längre in i filsystemet.

/www/images/user_image/

SKulel det kunna vara en risk? och vad gör jag för att skydda mig i så fall?

Har du kollat så att du inte har en keylogger?
I och för sig har du det så återkommer säkerligen hacket.
Här kan du läsa mer:
http://billing.handsonwebhosting.com...article&id=220

Tack för svaret, scannar datorn nu. ska be kunden scanna sin oxå. Det låter ju högst sannolikt.

Nu har jag scannat min dator med Avira AntiVirus samt SpyBoy Search & Destroy. Men de hittar inga fel, några andra tips på program?
Något annat jag kan göra för att gå vidare och inte se till så att sidan attackeras mer?

Svårt i praktiken. Mysql körs oftast chrootad och kan inte skriva annat än till sina egna kataloger.

Jepp! Men jag vet flera webbhotell som har Windows-servrar där MySQL körs som local system. Sorgligt nog.

Jo det är nog ganska vanligt, Next-installationer brukar vi kalla dem.

Jag i länken du fick fanns det länk till ett gratisprogram som skall vara bra på att hitta keyloggers. Testa det. Comodo är ett annat gratisprogram som jag tycker är bättre än avira. Jag har kört SpyBoy Search & Destroy en gång i tiden och var inte speciellt imponerad.

Det är inte säkert att det är keyloggers, men att dom på något sätt fick tag på FTP-uppgifterna. I så fall så kan du försöka att logga in krypterat istället för okrypterat i fortsättningen.

Tack. Inga nya attacker har skett ännu i alla fall.

PHP's safe_mode är fel väg att gå. Det ställer till det mer än vad det gör nytta. Speciellt om PHP körs som en annan användare än vad kunden är (filuppladdningar mm). Finns en anledning att denna funktion försvinner i PHP6.

PHP över FastCGI, med antingen separat php.ini för varje kund eller php_admin_value i vhosten, med open_basedir, löser många problem :)

Jag gissar att sidan som du har problem med är antingen en Joomla sida eller ett forum? Alternativt något skript som har uppladdningsfunktion av någon form....

Att få en iframe injicerad i sin sida är inte ovanligt tragiskt nog och det är vanligast på sidor där det finns skript som tillåter uppladdningar (gif/XSS/SQL injections) och/eller där servern tillåter CHMOD 777.

Har du riktigt otur så behöver det inte ens vara din sida som är hackad om servern inte är säkrad ordentligt utan det kan ligga var som helst på servern....

Jag kan intyga detta. Vi ser det på Levonline också. Typiskt är att någon bot går in och redigerar alla filer som heter något med index och default, men det har även hänt att alla filer som slutar på .php och .html har ändrats. Attackerna sker alltid via FTP med rätt lösenord.

Även om man rensar filerna så brukar botarna komma tillbaka rätt snart. Det brukar dock hjälpa att ändra lösenordet på FTP-kontot, och allra bäst är som redan sagts att köra SCP eller SFTP (som egentligen är samma protokoll). En del FTP-klienter har inbyggt stöd för SFTP/SCP. För Windows rekommenderar vi annars WinSCP.

Jag har inte sett någon uppenbar koppling mellan färdiga CMS och dessa FTP-hack. Det är lika ofta hemmasnickrad kod som drabbas, eller sajter helt utan PHP (enbart HTML).

Då har ni antingen ovanligt få eller ovanligt många tillbud, jag hoppas på det förra :) Småhackers kan norpa ett FTP konto och busa runt lite, men den stora massan med hackade webbplatser sker med bottar direkt fokuserade på kända säkerhetshål.

Jag skrev en post om Joomla moduler som hade säkerhetsbrister och jag tror jag har haft 5-10.000 försök från bottar dom senaste två åren riktade just mot den posten :)

Skript som tillåter uppladdningar och där det krävs CHMOD 777 för att skriptet ska fungera är rena julafton för dom här bottarna vilket är en bra anledning till varför kunder aldrig ska behöva ge högre rättigheter än 755 på kataloger och 644 på filer.

Att få en iframe injicerad i en sida är ett typiskt angrepp mot bland annat PHPBB och gamla IPB forum som jag vet om, annars brukar det vara vanligare med en defacial när man byter ut förstasidan till exempel om man får tillgång till en kunds FTP uppgifter eller att man lägger in skript gömda i användarens kataloger som sedan används för phishing, spam eller att vidare infektera servern.

Kolla också kataloger och filer så inte någon har laddat upp något skumt som t.ex ett phpshell. En möjlighet är ju att nån använt ett säkerhetshål i en webbapplikation och laddat upp ett phpshell som sedan lämnar kontot öppet i stort sett.

Vi stoppar många "vanliga" injektionsattacker med hjälp av mod_security redan, vilket kanske förklarar varför vi inte alltid ser sås tora problem med färdiga system. Men visst har vi haft vår beskärda del av Joomla-hack också.

Jag håller inte med dig helt om rättigheterna. Webbservern ska inte kunna skriva till filer som har 755-rättigheter. Det är en större säkerhetslucka än att kräva 777-rättigheter imo.
Det är sällan som ett hack drabbar andra sajter än den sajt som blivit hackad, åtminstone har det vad jag vet aldrig hänt på Levonline, trots att vi kräver 777-rättigheter på de mappar som webbservern ska kunna skriva till.

Det är förvisso möjligt för andra kunder att ändra något på en 777:ad sajt, men det kräver att den som hackar vet vilka sajter som finns på andra kunders konton (eftersom vi inte ger other listrättigheter till public_html, och då måste man veta vilka domäner som användaren har där).

Å andra sidan kommer de flesta filer att ha skrivrättigheter för den egna användaren, eftersom användaren tycker det är opraktiskt att inte kunna ändra sina egna filer, och att ge webbservern skrivrättigheter till alla filer på kontot kan potentiellt ställa till mycket problem för den enskilda kunden. Att bara kräva 755-rättigheter för att webbservern ska kunna skriva (vilket råkar vara samma rättigheter som behövs för att den egna användaren ska kunna skriva till filerna) gör ju då i praktiken att webbservern kan skriva till hela kundens hemkatalog, vilket öppnar upp mycket för den som hittar säkerhetshål i kundens sajt. Med 777-rättigheter kan man i alla fall välja själv vilka mappar som ska vara skrivbara.

Min favoritlösning är en där det krävs 775-rättigheter för att webbservern ska kunna skriva till filer, och att man köra webbservern som en annan användare än kunden, men som en unik användare för varje kund och i en unik grupp. Eller ännu snyggare är om man lyckas sätta upp ordentliga SELinux-regler...

Prova att sätta upp en ledig server utan mod_security eller suphp/suexec, lägg på en Joomla installation med dom mest utsatta modulerna och skriv sedan en post om vilka moduler som ligger där...kan vara spännande att se hur länge den står oinfekterad ;)

Jag skulle gärna vilja veta mer om vilka säkerhetsrisker som ligger i en 755 sajt jämfört med en 777 sajt (generaliserad så det heter duga, men du vet hur jag menar ;)) och jag skulle också gärna höra mer om din favoritlösning om du vill dela med dig?

Skrev en post på flashback att betatestare sökes för ett community med den och den modulen i joomla :P