Beste allemaal,

ik ben momenteel in discussie met iemand die er een sport van begint te maken de schuld van een bug op door mij gebruikte software af te schuiven, situatie is als volgt (beknopt):

mijn CMS heb ik inmiddels al enkele tientallen keren opgeleverd aan verschillende klanten, vaak komt hier een fotoalbum module bij kijken. Dit foto album wordt doorgaans voorzien van een lightbox om de plaatjes op een leuke manier te tonen aan de bezoeker. Tot op heden nog nooit last gehad van geïnfecteerde website's, maar sinds kort hebben we het CMS een keer moeten installeren op een andere hosting en daar is dus een en ander geïnfecteerd geraakt. Het is een vrij simpele infectie, er is namelijk in index.php een stukje code toegevoegd wat een iframe include via een base64_decode(). Op diezelfde manier is in de bestanden home.* en *.js een stuk javascript toegevoegd met een document.write() tag in die hetzelfde trucje doet. Ik ben dit ooit 1x eerder tegen gekomen en dit kwam destijds door de onkunde van de serverbeheerder, zijn hele filesysteem was blijkbaar niet zo goed beveiligd.

Anyway, volgens de hostende partij wordt deze bug veroorzaakt door een Lightbox script (let op: het gaat om "lightbox evolution" van codecanyon, een betaalde plugin). Nu heb ik serieus overwogen of dit een mogelijkheid kon zijn, maar zover mijn bevindingen komen lijkt me dit uitgesloten.

De hostende partij doet verder niets dan met het vingertje naar mij/lightbox wijzen zonder enig ondersteunend bewijsmateriaal waar we iets mee kunnen om de bug op te kunnen lossen en heeft zonder pardon de website van de klant al bijna 2 weken down liggen.

Nu is mijn vraag: in hoeverre is het via javascript mogelijk om de oorzaak van deze bug te zijn? Zover ik weet is javascript namelijk - zonder serverside taal als PHP - niet in staat om bestanden te openen en stukjes code toe te voegen? Wel is er een javascript-only mogelijkheid tot "uploaden" van files, maar hierbij word volgens mij de inhoud als tekststring opgeslagen welke je bijvoorbeeld als img-src kunt gebruiken.

In de lightbox bevind zich wat betreft file uploads helemaal geen mogelijkheid of ook maar iets wat hier mee doet. Verder worden alle externe links in een iframe ingeladen en wordt er geen gerenderde HTML rechtstreeks in de bron van de pagina geplakt (nu zou dit geloof ik ook al niets moeten kunnen uitmaken, want de PHP van die externe pagina wordt eerst uitgevoerd voordat het resultaat in de lightbox terecht komt?)

Wat me verder nog enigsinds doet twijfelen aan lightbox als oorzaak is dat er een bepaald ritme te vinden is in de geïnfecteerde bestanden;

alles wat eindigd op .js heeft een infectie onderaan de pagina
alles wat begint met home. heeft een infectie onderaan de pagina
de htaccess is geinfecteerd
de index bestanden zijn geinfecteerd
er zijn 2 "google_verify.php" bestanden aangemaakt (hierin staat enkel de iframe/div die geinclude wordt)

Alles wijst erop dat er op de een of andere manier een PHP bestand is geupload wat aangeroepen kan worden welke via het filesystem zoekt op bovenstaande bestanden en die aanpast, maar dit bestand is dus niet op de website van mijn klant te vinden..

Graag jullie mening, ik sta nog steeds open voor een bug in lightbox, het is mijn script niet en het kan goed zijn. Maar mijn bovenstaande bevindingen geven mij de indruk dat de oorzaak ergens anders gezocht dient te worden. Aangezien de hostende partij zich onthoud van enig bewijsmateriaal waar we iets mee kunnen en alleen met de vingertjes wijst ben ik op mezelf aangewezen de klant tevreden te houden.

Alvast bedankt!

Ik weet niet hoe je php code eruit ziet voor het uploaden en weergeven van afbeeldingen?

Het is mogelijk om php code of JavaScript code te injecteren in een afbeelding

Bovendien wanneer je onveilig met de get array om gaat en deze direct include is je code vatbaar voor remote php injectie hierdoor hoeven de php codes niet eens op je server te staan.


Dus wellicht kun je je php code eens sturen per pm

Misschien geen sterke onderbouwing, maar aangezien "lightbox evolution" toch wel veel gebruikt wordt en er 0,0 meldingen op google te vinden zijn over een hack/virus door/van dit script denk ik niet dat het daaraan ligt.

Het probleem dat je schetst (virus met iframe/base64_decode) is de laatste weken vaker hier op sitedeals gemeld. Oorzaak is (zover ik weet) niet 100% zeker, ik weet alleen dat ik zoiets ook heb gehad een 2tal jaar geleden en toen kwam het door malware op mijn eigen PC.

Deze malware 'tapte' het FTP verkeer af en kon zo de bestanden aanpassen. Nadat ik de malware met malwarebytes (top programma! www.malwarebytes.org) had gewist (en volgens mij ook mijn ftp wachtwoorden had gewijzigd) had ik er geen last meer van.

Ik acht de kans dan ook vrij groot dat de oorzaak komt door een besmette pc die verbinding maakt met FTP.

Mocht je toch denken dat het door de hoster komt; is er geen forum waar veel van klanten bijeenkomen en kan je daar niet lezen of er meer mensen zijn met dit probleem? Je kan ook trachten te achterhalen welke sites daar gehost zijn (whois data o.i.d.) en dan kijken of er sites besmet zijn.

Origineel gepost door Raymond Nijland

Ik weet niet hoe je php code eruit ziet voor het uploaden en weergeven van afbeeldingen?

Het is mogelijk om php code of JavaScript code te injecteren in een afbeelding

Bovendien wanneer je onveilig met de get array om gaat en deze direct include is je code vatbaar voor remote php injectie hierdoor hoeven de php codes niet eens op je server te staan.


Dus wellicht kun je je php code eens sturen per pm

Alle uploads van de server zijn nagekeken, heb de extensies naar .php veranderd om de inhoud te zien en het zijn allemaal gewoon plaatjes, geen gekke code of iets dergelijks. De upload scripts zijn ook beveiligd met een login-check en de databasetabel die bruteforce aanvallen detecteert bevat enkel IP adressen van toegestane personen.

Het script richt zich ook puur op de front-office van de website, de folder /admin/ is onaangetast gebleven, leek mij in eerste instantie vreemd. Maar na wat denkwerk is het op zich best logisch, dit soort hackjes hebben toch niets aan een code in de admin, die wordt te weinig bezocht.

GET/POST/COOKIE waardes worden als eerste in index.php door een sanitize functie gehaald, nergens op de sites mogen deze waardes iets van HTML code bevatten, die wordt er als eerste uit gestript, daarnaast wordt ook nog htmlentities() erover gehaald, dus als er al code via GET/POST/COOKIE komt, dan bevat deze enkel html entiteiten en normale karakters.

Ik heb gisteren nog e.e.a. onderzocht en de lightbox blijkt het diepst liggende script te zijn wat is aangetast. Ik verwacht dus dat er ergens (want het is shared hosting) een script draait wat de mappen uitleest en de bestanden die het wilt aanpassen (htaccess, index.*, home.* en *.js) in een array plaatst en vervolgens weer achterstevoren uitleest. Ik heb hierom nog 1 dieperliggende js bestand aangemaakt om te kijken of deze theorie uberhaupt mogelijk kan zijn, tevens heb ik de lightbox geupdate naar de laatste versie, maar nogmaals, de kans dat het de Lightbox is, lijkt mij enorm klein.

De hostende partij is zelfs zo kortzichtig dat zelfs na het meerdere malen aangeven dat het niet om de gratis variant gaat, dat hij me gisteren nog even wilde benadrukken dat hij het niet kon begrijpen hoe ik "Open-source GPL software" kon verkopen aan mijn klanten. Dus zelfs na diverse malen aan te geven dat het geen open-source is hamert hij nog steeds hier op door.

Anyway, we zijn een dagje verder en de website is vandaag alweer geinfecteerd, ik heb gisteren een uur op zijn aanwijzingen besteed om de boel op te lossen, maar dat heeft niet geholpen. Wat ik wist wordt dus gewoon bevestigd, namelijk dat de Lightbox de oorzaak gewoon niet is.

@Jopie: die onderbouwing wil ik ook niet gebruiken, maar het geeft wel al iets aan. Over de Opensource wordpress variant is wel een en ander te vinden, maar dus niet over deze specifieke plugin. Dit type hack is mij ook bekend hoor, ben hem 1x eerder tegen gekomen en toen werden al mijn sites geinfecteerd door de website van iemand anders op een shared hosting account. Wordt je even goed pissig van, maar goed, het is je werk nu eenmaal. Wat ik het ergste vind is dat de hoster alles op mij afschuift en in een mailtje inclusief CC naar iedereen toe aangeeft dat ik "duidelijk niet weet hoe de hack werkt want lightbox is het schuld". De beste man bedoeld het vast goed voor zijn eigen situatie wat beter af te schilderen, maar daar heb ik vrij weinig aan.

Een malware die de FTP aftatpte heb ik ook aan gedacht, maar als het goed is hebben we een tijdje geleden enkel het IP van mijn kantoor en van de hostende partij toegang gegeven tot FTP verkeer naar de betreffende website dus dat zou niet meer mogen. Wat wel een optie is, is dat het via FTP verkeer van een andere site van deze klant gaat (die komt immers op hetzelfde hostingpakket uit, alleen worden domeinnamen via htaccess naar een folder gedirigeerd).

Ik denk verder heus niet dat het door de hoster komt, maar ik vind het gewoonweg van weinig intelligentie getuigen om te denken en te communiceren dat een javascript de oorzaak is van het aanpassen van bestanden, dat kan gewoon niet zonder een PHP bestand wat de boel moet aanpassen. Ik kan zometeen weer achter de PC kruipen om te zoeken wat nu weer is aangepast omdat de hostende partij zo'n grote plank voor de kop heeft om enkel en alleen vast te houden aan hun eigen theorie omdat lightbox het eerste bestandje is wat is aangepast.

Bij de meeste controlpanels (DirectAdmin, Cpanel) kan je zelf ook de Apache logs in kijken.
Als je daar even in kijkt rond het tijdstip dat het bestand is aangepast, dan kan je dat uitsluiten.

DirectAdmin: Site Summary / Statistics / Logs -> Apache Usage Log

Kijk ook even wat de rechten van de bestanden en mappen zijn in je directory.

Weet ik, helaas heb ik die toegang niet, enkel FTP. Hierin staat ook een mapje met de logs in. Aangezien ik nu een dieperliggend mapje heb gemaakt kan ik dit zo meteen controleren. De rechten zijn maximaal 755, probleemloos op onze eigen server gebruikt op tientallen websites, dit zou ook een veilige setup moeten zijn?

Origineel gepost door Joshua de Gier

maar als het goed is hebben we een tijdje geleden enkel het IP van mijn kantoor en van de hostende partij toegang gegeven tot FTP verkeer naar de betreffende website dus dat zou niet meer mogen.

De malware waar ik over heb past de files aan via jou eigen PC en "lift op je eigen PC mee" op het FTP verkeer, dus dan zal zo'n IP restrictie niets uitmaken.

Download en probeer het eens: malwarebytes.com , kan nooit kwaad...

Ik zit op een mac :-) zo te zien is dat Windows software, kans is sowieso klein dat het aan mijn kant ligt dan, eerder bij een klant. Ik doe absoluut niets vreemds en werk al jaren zonder virusscanner, ook op de windows pc/laptops hiervoor. Ik verwacht echt dat het probleem ergens anders ligt.

Overigens was ik iets te vlug met constateren dat er opnieuw wat op stond, een van de opgeschoonde files is niet gecommit geworden gisteren, net opnieuw gedaan en even vingers over elkaar dat het probleem verholpen is.

Joshua, dat men een webhoster is betekent niet per sé dat men alle ins- en outs weet van het programmeren. Van wat ik gelezen heb is het niet jouw schuld. Wellicht dat de gebruiker een te makkelijk FTP wachtwoord heeft of dat inderdaad zijn/haar pc geinfecteerd is. Zelfs als je toegang tot de logs hebt, kan het zijn dat je daar ook geen uitsluitsel in terugvind.

Ik kan je echter wel aanraden alle FTP (en wellicht CMS user) wachtwoorden aan te passen.

Als collega-programmeur wens ik je heel veel succes hiermee.

Thanks :-) Ik ben voornamelijk nog wat gefrustreerd over het feit dat hij enkel aanstuurt op fouten in open-soure wat niet open-source is en op geen enkel moment ook maar enige mogelijkheid openlaat waarbij het zijn schuld kan zijn. Ik steek hier nu uren in terwijl ik ook weet dat de oorzaak bij hem kan liggen of bij een van zijn klanten.

Zover ik weet geven de logfiles enkel aan welke files aangeroepen worden en staat hier helemaal niet in welke files op welk moment worden aangepast of door wat/wie. Of vergis ik me hierin? Ik heb slechts 1 vreemd dingetje kunnen vinden in de logfiles en dat was een aanvraag naar zo goed als elke pagina van de website met de volgende user-agent:

MorMor v2.6

Maar ook deze user-agent heeft zover ik kon zien geen enkele vreemde file aangesproken, niet eens alle bestanden wat geinfecteerd zijn. Google bood me geen enkele oplossing op de vraag wat MorMor v2.6 nu exact is/was, misschien dat iemand hier wat meer ervan af weet?

Heel herkenbaar. Ik heb pas een soortgelijke situatie meegemaakt. Nu ben ik geen programmeur dus de exacte details kan ik je niet vertellen, maar zal het als volgt samenvatten:

Diverse op Wordpress en andere CMS-en draaiende sites werden regelmatig besmet. Steeds dezelfde index.php bestanden, die aan het begin of einde werden voorzien van een stukje gecodeerd script waarin een redirect zat verborgen. Na veel gezoek zijn we er pas na lange tijd achter gekomen wat het was: Op een PC van de klant stond een oude Java versie die kwetsbaar bleek. Latere Java updates waren wel OK, maar als je Java automatisch gaat updaten blijft de oude boel lekker staan. Die kwetsbare Java update zorgde in combinatie met Filezilla (waarin de FTP gegevens als ongecodeerde tekst worden opgeslagen!) voor de problemen. Malwarebytes aangeschaft, alle mogelijke FTP-clients verwijderd en in plaats daarvan WinSCP met een hoofdwachtwoord geïnstalleerd, en de problemen waren sindsdien voorbij.

Nu is het vaak moeilijk om tegen je klant te zeggen dat het probleem bij hem zit. Maar je kunt wel gaan elimineren door de FTP gegevens te wijzigen en deze nog even niet aan je klant door te geven. Als de infecties daarna niet meer voorkomen is het aannemelijk dat het probleem bij je klant zit.

Verder schiet me nog één dingetje te binnen: gebruik je in dat CMS misschien een Open Source WYSIWYG editor met file-uploader? Daarin zit ook nog wel eens een probleempje... Maar zoals gezegd: ik ben geen progger, laat ik het maar houden bij hetgeen ik daadwerkelijk heb gezien.

Origineel gepost door Joshua de Gier

user-agent: MorMor v2.6

Maar ook deze user-agent heeft zover ik kon zien geen enkele vreemde file aangesproken, niet eens alle bestanden wat geinfecteerd zijn. Google bood me geen enkele oplossing op de vraag wat MorMor v2.6 nu exact is/was, misschien dat iemand hier wat meer ervan af weet?

"MorMor" kan ik terug herleiden naar topclick-prospects.nl
[Mozilla/5.0 (compatible; MorMor TCP Spider; http://www.topclick-prospects.nl/TcpSpider.aspx)]

Topclick-prospects lijkt weer onderdeel te zijn van Topclick (.nl)

Ik denk verder onschuldig

Bedankt voor je reactie, het FTP probleem kunnen we uitsluiten aangezien de klant (even) geen toegang had tot de FTP. Hoe het met zijn andere sites zat weet ik niet zeker, maar zover mij verteld wordt, worden deze door de hostende partij onderhouden.

Het CMS gebruikt inderdaad een opensource editor (CKEditor), alleen zijn de upload handlers voorzien van een eigen beveiliging eromheen, als je niet ingelogd bent kom je dus ook niet op die pagina terecht als je ze aanroept. Verder zijn ze ook nog gelimiteerd aan enkel afbeeldingen uploaden, dus niet de standaard "upload wat je wilt" module.

Origineel gepost door jopie t

"MorMor" kan ik terug herleiden naar topclick-prospects.nl
[Mozilla/5.0 (compatible; MorMor TCP Spider; http://www.topclick-prospects.nl/TcpSpider.aspx)]

Topclick-prospects lijkt weer onderdeel te zijn van Topclick (.nl)

Ik denk verder onschuldig

Thanks, dan leidt dat draadje ons ook naar niks nuttigs :)

Als de hoster niet wil meewerken... wat heb je dan aan zo'n hoster? Het is een kleine moeite om even te checken op die geinfecteerde bestanden wel/niet via ftp zijn binnengekomen. Zo ja, wijzig de wachtwoorden nadat je de pc gecleaned hebt. Zo niet, komt het via een andere manier binnen.
Via javascript kun je iig niks op de server aanpassen aangezien het clientside draait.
Als de rechten goed staan en je website draait met de privileges van de betreffende user (waarbij apache dus geen schrijfrechten heeft), dan ligt het probleem bij jou. Draait de website onder de apache user (waarbij deze dus wel schrijfrechten heeft) dan kan het meestal via alle users gebeuren. Je hoster zou er in dat geval toch wel goed aan doen om de boel eens grondig te checken.

Als je Googled naar MorMor kom je opvallend vaak dit IP-adres tegen: 95.211.144.86 ...