Hej,

Jag är utsatt för systematiska hackerattacker på mitt amerikanska webbhotell Servage. De kommer in någonstans och jag kan inte begripa hur. Det har nu skett för tredje gången.

Efter första gången bytte jag lösenord på alla inloggningskonton och databaser.
Efter andra gången fick jag rådet att täta för mysql-injections med hjälp av "mysql_real_escape_string" vilket jag gjorde.

Nu har det skett för tredje gången. De lägger in osynliga skräplänkar, kod som får virusprogrammen att blinka till och ful-filer i image-mappen (php-sidor).

Då jag knappast är nån expert så vet jag inte längre hur jag ska göra. Är det någon annan här som blivit drabbade av samma sak? Kanske samma hackers/script?

Jag får känslan av att sidan är "automathackad". De skadar inte själva sidan men inplanterar som sagt osynliga länkar och scriptkod.

Titta in källkoden på www. google earth cool places. com - OBS! Gör det bara om du har ett virusprogram installerat.

Hur skulle du felsöka?

Jag har för övrigt ett phpLD-directory installerat på samma webbhotell.

// Clirre

ps. Hade en annan tråd här om samma fel där jag felaktigt anklagade mitt gamla webbhotell för problemet. Startar därför en ny tråd som är mer relevant.

Jag kan underlätta för er också med att ställa några raka frågor:

1. Om man har fri tillgång till en databas så kan man skapa filer i en katalog med hjälp av detta?

2. Om man kan skapa filer som ovan så kan man skapa en ingång för att kunna editera andra filer?

3. Mysql-injections är ett sätt att kunna skapa såna filer?

4. mysql_real_escape_string är tillräckligt för att stoppa mysql-injections?

5. Om man kan komma in på en sida så kan man komma in på flera sidor på samma webbhotell?

6. Remote Mysql v.5 är ett stort säkerhetshot?

7. kmz (Google Earth-filer) kan innehålla portar/virus mm?

8. Känner du igen tillvägagångssättet från något speciellt säkerhetshål? Badware, osynliga iframes mm.

9. Vilka vanliga säkerhetsluckor kan scannas automatiskt av script för att hitta svaga sidor?

10. Är phpLD en känd säkerhetsfara?

11. Finns det bra, gratis tjänster på nätet som letar säkerhetshål på ens sida? Jag har googlat men inte hittat något jag förstått mig på.

12. Kan det ligga kod lagrad i databasen som ger en öppen dörr? Vad och var ska jag leta efter i såna fall?

13. Har du blivit hackad någon gång? Vad gjorde du då?

Servage Ligger ej i USA utan i holland!
Jag skulle byta till senaste php LD scriptet som är det säkraste.
sen gå in på servage nånstans finns det lite mer att kryssa in på säkerhet området.

Börja att logga IP-nummer på allt som sker mot din databas (i alla tabeller). Efter ett tag har du en lista på onda IP som du kan förbjuda access från.

Har funkat mycket bra för mig (dock ej phpLD).

Kända programvaror (som tex phpLD, phpBB, etc) är ett vanligt och tacksamt mål för automagiska hackningar.

kör dom med suphp?
Och vad är rättigheterna på dina filer och kataloger.
Om du tex har 777 på en katalog tex så kan ju någon annan på servern skriva runt på ditt konto lite som dom vill.
Om det endast är din site som har detta problemet och du har shared hosting..
ja då ska du kolla vilka rättigheter alla filer har och se till att du uppdaterat dina scripts osv.

Servage.net hacked på webhostingtalk forumet

Sökte medans jag satt o skrev ett svar till dig.
Du verkar inte vara ensam.

Ska försöka svara på några av frågorna. Jag är dock ingen expert på detta, så andra får gärna rätta mig om jag har fel eller komplettera med mer info.

Vet inte. Kanske via stored procedures. Beror nog på vilken databas man har och hur den är konfigurerad.

Ja, det borde vara möjligt. Man skulle kunna skapa en php-fil med all möjlig elak kod och sedan anropa den utifrån.

Ja, med mysql-injections bör man väl kunna göra i stort sett allt som kan göras mot databasen så länge det inte är konfigurerat några restriktioner.

Ja, det bör det vara.

Mycket möjligt, men det beror på hur webbhotellet har konfigurerat servern och hur man har kommit in. Med SSH-access så kan man t ex göra mer än med FTP-access (tror jag).

Paros och Priamos ska vara bra, men jag har inte testat dem själv ännu.

Tack för alla era svar! Blir otroligt glad över att ni hjälper mig. Har haft osannolikt struligt på senaste tiden där detta hack bara är en sak i mängden (pajade datorn och var Proinet-kunde också).

Jag var inte direkt inne på att det skulle vara något hos webbhotellet men jag har fått svar från två olika håll nu att det kan vara något lurt med Servage. Ska följa upp det spåret närmare.

Lite svar på era frågor mm:

- Servage ligger inte i USA, det har du rätt i (visste iofs inte det när jag valde dem) men ligger de inte i Tyskland?
- Det phpLD-scriptet jag kör var för en sida som var väldigt ny, dvs inga besökare så jag börjar med att ta bort hela sidan. Det gör ingen riktig skada att ta bort det.
- Jag har inte satt några rättigheter aktivt, allt har satts automatiskt av webbhotellet. Det är -rw-r--r- på alla filer och drwx-xr-x på mappar. Vissa mappar och filer de har hackat så har de blivit satta till 777 (har ändrat tillbaka förstås).
- Testade Priamos men kunde inte installera det, ska kolla med Paros också.
- Ska försöka hitta nån logg eller nåt sätt att aktivera det hos Servage så att jag kan se vad som hände. Det är ganska lätt att se när sidorna blev hackade (alla filer har samma Senast Ändrat-datum).
- Vet inte vad subhp är för något men jag erinrar mig vagt att jag tog bort en fil skapad av hackarna som kan ha hetat något liknande. Kommer dock inte ihåg...

Fick det här svaret från Servage idag (på frågan om det är något från deras sida som är fel). Hade ställt frågan innan och bara fått svaret att det var mitt script som var fel och att jag skulle anlita någon php-programmerare för att fixa koden.

"Server maintenance has been followed with high security breach. Meanwhile it will be much appreciated if you can secure the scripts which are being hacked randomly,"

Förstår inte helt vad de menar så jag kommer fråga tillbaka.

dom vill att du ska säkra de skript som blivit hackade.. så dom slipper göra det..

Vet du vilka script det rör sig om?
Det går att göra så mycket "roliga" saker med php om den som skrivit skriptet inte har tänkt ett par gånger extra på säkerheten.

Förresten, du har väl loggfiler? Kika i dem och försök se vilka filer som körs för att lokalisera de script som orsakar problem.

problemet är att servern är hackad.. antagligen.. det verkar vara så att de har blivit rootade eller liknande igenom en kernel bug.
kerneln i fråga e lite smågammal.... lite!

Fick svaret:

It may be for some vulnerable third party scripts or insecure permissions on the files.
Anyways, we have already informed our security team and they will check if there is anything from server side.

Jag har aldrig ändrat permissions på filer eller mappar själv. Jag har inga specialsidor heller, allt är php med mysql v5 (många har remote). phpLD är undantaget, den sidan har jag raderat för tillfället.

Det verkar ju mer och mer som om webbhotellet är hackat men det verkar inte vara nåt ramaskri, dvs inte alla är drabbade. Kanske bara de med svag php-kod och eftersom jag inte är jätteduktig finns det möjligen luckor.

Det är dock otroligt svårt att felsöka koden efter säkerhetsluckor och "roliga" fel då allt blir hackat. Om filer är ändrade i varje mapp på hotellet så vet man ju inte var de kommit in och var de ändrat efter att de kommit in. Några tips här? Några tips på vanliga luckor (bortsett från mysql-injections). Gärna tips på nån bra hemsida.

Jag har inte hittat nån logg eller nåt ställe där man kan enabla det heller.

Jag har frågat innan men inte fått nåt riktigt bra svar:

Vilka permissions ska man ha på filer respektive mappar för mesta möjliga säkerhet. Alla filer är vanliga php-sidor. Inget bör skrivas till dem, jag har inga mappar där man kan ladda upp saker, allt är bara rena hemsidor så att säga.

Du kan sätta katalogerna till 555 och filerna till 444, då kan alla läsa men ingen kan skriva till dom.

Får användarna ladda upp filer på servern?

Se dig om efter ett webbhotell som använder brandväggar. De flesta "automathackningar" sker genom att de hittar en säkerhetshål och sedan använder ett skript från servern som tankar andra hack till servern. Om brandväggen stoppar trafik från att hämta ner saker till servern så ger de flesta upp ganska fort och ger sig på någon annan istället.

Använder du templates som på något sätt inkluderas?
I så fall kan det handla om RFI.

hnn: nej, alla förslag skickas till mig via mejl...lite antikt system men jag har inte kunnat göra ett script som laddar upp filer automatiskt som är säkert...

Inga templates heller, tror inte RFI bör vara möjligt på det sättet jag byggt sidan. Undantaget är fortfarande phpLD som jag inte har kontroll över.

Jag har fått hjälp av en vänlig själ här på WN med ett webbhotell jag får krascha på (ursäkta ordvitsen) tills jag vet att Servage är säkrade. Ska bli intressant att se om sidan fortsätter bli hackad då. DNS:en håller på att slå om i detta nu.

Sen lutar det kanske åt att byta webbhotell igen (till nåt säkrare). Vill helst inte det för jag har varit nöjd med Servage såhär långt.

Är det bara en slump att Proinet (mitt dåvarande svenska webbhotell) och Servage (mitt "amerikanska" webbhotell) blev hackade inom bara ett par dagars mellanrum? Samma kernel-fel kanske? Spekulation, men för mig personligen är det ganska ironiskt att båda mina webbhotell blev hackade samma vecka.

Joo, du verkar ha fått maximal otur!

Har inte sett något i tråden om det, men har du gått igenom dina apache-loggar? Har du tur hittar du något där, som RFI mm som diskuterats tidigare.

För PHPLD specifikt hittade jag dessa:
http://www.smilehouse.com/advisory/p...ory_070121.txt
http://www.securityfocus.com/bid/20765


/Martin

Mitt tips är att kontakta ConfigServer och beställ en genomgång för att säkra servern ordentligt. Det kostar bara 75 dollar och det är helt klart värt varenda öre.

http://www.configserver.com/cp/cpanel.html

Hej alla,

Tack för alla era svar. Jag har nu klarat mig i en vecka efter att jag bytte webbhotell (blev annars hackad i princip varje dag) så jag kan *peppar, peppar* fömoda att det var webbhotellet Servage som var problemet.

Jag har dock tagit till mig av era förslag och sidan borde ha blivit säkrare efter allt detta!