Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Criminelen onderscheppen wachtwoorden en betaaldata via 'formjacking' - update

Criminelen hebben kwaadaardige code toegevoegd aan scripts van analyticsdienst Picreel en Alpaca Forms. Daardoor kunnen ze op duizenden websites wachtwoorden en betaalgegevens onderscheppen die gebruikers invullen in formulieren.

Het gemanipuleerde script van Picreel staat op 1249 websites, ontdekte beveiligingsonderzoeker Willem de Groot van Sanguine Security. De Nederlander vond dezelfde kwaadaardige code terug op 3435 websites die formulieren van opensourceproject Alpaca Forms gebruiken. Volgens de beveiligingsonderzoeker worden de ingevulde gegevens in beide gevallen naar een server in Panama gestuurd. De code zou erop wijzen dat dezelfde criminelen achter de twee aanvallen zitten.

Picreel is een analyticsdienst die websitebouwers een stuk JavaScript op hun pagina laat embedden. Dat moet inzicht bieden in het gedrag van bezoekers. De aangepaste code stuurt alle input van gebruikers door naar een server van de criminelen, zodat ze inlog- en betaalgegevens in handen krijgen.

Datzelfde gebeurde met het aangepaste script van Alpaca Forms. Die formulierendienst werd oorspronkelijk ontwikkeld door Cloud CMS en is acht jaar geleden open source gemaakt. Cloud CMS heeft nog altijd een cdn in gebruik voor het project en daarin was binnengedrongen, zegt het bedrijf tegenover ZDNet. De servers waar het gemanipuleerde script op staat, zijn inmiddels offline gehaald. Het bedrijf zegt dat er verder geen aanwijzingen zijn dat er een beveiligingslek is bij de cloudprovider. Het is nog niet bekend of Picreel al maatregelen heeft genomen.

Update, 12.00: Picreel en CloudCMS hebben de malware verwijderd, meldt Willem de Groot.

Door Julian Huijbregts

Nieuwsredacteur

13-05-2019 • 08:45

60 Linkedin Google+

Submitter: hgkertjed

Reacties (60)

Wijzig sortering
Keep op keer blijkt maar weer dat het draaien van privacy addons (hoewel bij de addon ook iets soortgelijks kan overkomen) of eigen DNS servers nog belangrijker is dan daadwerkelijke antivirus software. Meestal gaat het over advertentie netwerken waar iets mis mee is, dit keer dus analytics. Bijkomend voordeel is dat je daarmee gelijk de AVG forceert waar de meeste sites zich ook nog steeds niet aan houden.

Daarnaast kunnen websites natuurlijk ook gewoon een fatsoenlijke CSP hanteren. Third party scripts kunnen daarmee op een whitelist worden geplaatst. Mocht de 3rd party dan worden gehacked, dan blokkeert de browser het script.
Mocht de 3rd party dan worden gehacked, dan blokkeert de browser het script.
dan ben je eigenlijk al te laat
Dat heeft toch als gevolg dat bij een normale update van het externe bestand de hash ook veranderd en je script dus niet meer werkt? Hoe wordt dat dan opgelost? Automatisch de verandering in het externe bestand detecteren en dan je eigen hash ook updaten brengt je terug bij af.

Volgens mij is je scripts op je eigen servers hosten nog altijd het veiligste voor je gebruikers. Dat niet doen is eigenlijk een vorm van slecht gastheerschap.
Dat zou geen probleem moeten zijn. Een extern bestand hoort niet te veranderen. Je kiest voor die versie en die versie blijft gelijk! Een "latest" bestand includen is ronduit dom omdat het je eigen code kan breken.

Maar, ik ben het met je eens zelf hosten is het veiligst. Het voordeel van een CDN is echter dat de kans bij populaire libraries enorm groot is dat diezelfde library / versie al eens bij een andere site gebruikt is en dus in de cache staat.
Dit ja ^ :) is een paar bytes meer aan je javascript code toevoegen en klaar.
Sign up to view / Upgrade to view... Is de lijst nog ergens anders te vinden ?
Ik kan er gewoon bij. Via de link van het artikel kom je op Twitter: (daar heb ik ook geen account maar krijg deze tweet wel te zien)
"Het gemanipuleerde script van Picreel staat op 1249 websites, "
Dan op de link onder 'Victims' klikken brengt je naar:
https://publicwww.com/websites/%22assets.pcrl.co%22/

Edit: never mind.. ik zie dat je de eerste paar pagina's kunt bekijken van de lijst.. daarna krijg je inderdaad de melding "Upgrade to view"

[Reactie gewijzigd door DonJunior op 13 mei 2019 09:54]

Dat vind ik eigenlijk ook het grote nadeel van bijvoorbeeld het gebruik van composer.
composer update, en klaar is kees. Verschillende packages worden geupdate, maar je weet totaal niet wat er aan meuk of geïnfecteerde scripts is toegevoegd.

Maar ja gemak dient de mens, en daar kies ik dan ook voor want zo hou je alles wel snel en makkelijk up2date.
Daarom doe je ook nooit `composer update` op live omgevingen. Enkel `composer install --no-dev` en dan worden alléén de packages uit je lockfile geïnstalleerd, waar je ook al mee getest had (en eventueel natuurlijk gereviewed).

Composer is juist relatief veilig tegen het soort attacks waar het hier over gaat. Aangezien de packages altijd lokaal geïnstalleerd staan en niet on-the-fly van een remote-server worden ingeladen zoals de javascript files die in dit geval gecompromitteerd waren.
Nou om eerlijk te zijn heb ik altijd gedacht dat --no-dev geen development versies zou installeren.
Bedankt voor deze tip ;)
--no-dev zorgt er inderdaad voor dat je dev dependencies niet worden geïnstalleerd.

Het verschil zit m in install vs update.
Dat is zo ongeveer een "plaag" van iedere package manager.
Het is dus wel de bedoeling dat je je dependencies reviewt. En bij een package manager zijn je installatie/upgrade-acties altijd expliciet, en kan er dus niet zomaar iets achter je rug om veranderd worden (wat bij een CDN-geserveerd script wel kan).
Dat is 't nadeel van externe sources gebruiken.
Helemaal gelijk. Dit is nog een voorbeeld waarom ik mijn IT infrastructuur en infrastructuur onder mijn beheer volledig onafhankelijk wil. Alles zelf beheren en alles lokaal draaien. Je wil geen grote third party "Single Point Of Failure".

Ik ben weer nijdig naar mijn werkgever die alles in de cloud en proprietary wil, vandaar deze comment. Ik wil niet met maar beperkte rechten in mijn eigen systeem zitten als beheerder, of machteloos zijn wanneer het systeem van een derde faalt. Met mensen zoals mijn werkgever verdienen ze hun geld toch wel, ook al ligt het system er 3x per week uit en hebben we te maken met een grote leak om de paar jaar. dus waarom zullen ze hun IT en software op orde hebben?
bijkomend foutje in je redenering is het idee dat je het zelf beter kunt doen. Je hebt het idee meer controle te hebben over alles, maar die extra controle is niet zoveel waard persé. (immers: bij waar het nu mis is gegaan hadden ze ook beheerders met controle en toch ging het mis).
Maar hij neemt zijn verantwoordelijkheid wel.

Waar is (bv) de verantwoordelijkheid van Tweakers als ze straks weer malware lopen te verspreiden via het door hun gebruikte 3rd party advertentie netwerk?
dat is meer managementpraat dan wat anders. Het gros van de it-omgevingen zijn veel te complex geworden om alles zelf wat te doen. Je moet dan al een verdomd goede programmeur zijn (in diverse talen), een netwerkbeheerder zijn, een ad-beheerder, enz.

Dat was ook een beetje mijn punt, we onderschatten ons eigen kunnen veelal immens hard en schatten andermans kunnen veel lager in, waardoor we de neiging hebben tot 'als ik het zelf doe, dan wordt het tenminste goed gedaan', wat veelal pertinent niet klopt :)

Dus of je je verantwoordelijkheid neemt? Misschien, maar dat is niet zo heel interessant, de boeiendere vraag is of het goed geregeld is (wat niet impliceert dat het nooit fout kan gaan, shit happens)
Niet alles is zelf te doen inderdaad. Maar de troep die op bijna elke site geïnclude wordt, kun je een groot deel ook zelf hosten. Er is geen technische reden om dit soort formulieren van derde partijen in te laden.

Net als veel andere meuk die door websites ingeladen wordt vanaf derde partijen. Dat is eigenlijk nergens voor nodig en duwt steeds meer mensen richting noscript en adblockers.
mwah ik heb wel eens wat highly skilled pen-testers een dagje mogen volgen. Daar werd vakkundig een site die als goed beheerd werd gezien, helemaal een stukken getrokken. De overschatting die mensen (inclusief mezelf trouwens) van nature hebben over hun eigen werk is echt significant. Het zijn trouwens vaak de makkelijke dingen waar het op mis gaat.
Ik heb zelf een paar goede hackers/crackers in mijn omgeving die mijn pagina's in het verleden langs gingen.

Je hoeft verder niet alles zelf te maken, maar bepaalde zaken zelf in beheer nemen is zo verkeerd nog niet. Of je nu iets remote include of lokaal weg zet. Je bent in beide gevallen afhankelijk van de grimmen van een derde partij. Maar door het zelf te hosten heb je het nog enigszins in de hand. Zo gaan alle requests in mijn CMS via een router, waar ik zelf bv makkelijk bepaalde requests kan opvangen en een boel shit mee kan tegen houden, zonder zelf de code in te hoeven duiken van meuk van derde partijen.

Om formulieren te gebruiken zijn er tig oplossingen die je als libs/modules of whatever kan includen. Om je bezoekers te tracken zijn er ook tig oplossingen.

Remote includen is bij websites in 9/10 gevallen laksheid of "het is op deze manier mijn verantwoordelijkheid niet".

Maar goed, ik laad om dit soort onzin ook niet zo maar scripts of whatever in van derde partijen bij een website. Want hoe veilig is het dat er nu dik 3000 websites tegelijk onderuit gehaald zijn?
In dit geval betreft het een formulier, maar het had ook zomaar het Google Analytics script kunnen zijn.
Het is niet altijd mogelijk om dependencies zelf te hosten. Echter je kunt als je een script van een CDN afhaalt in veel gevallen wel de [url=https://www.w3.org/TR/SRI/}integrity attribute[/url] zetten.

Als de hash niet meer klopt, krijgt de bezoeker in elk geval wel een waarschuwing/foutmelding (afhankelijk van welke browser je gebruikt). Zorg wel dat je altijd expliciet naar een specifieke versie op een CDN linked en niet naar current of latest, want anders blijf je bij elke release continue de hashes aanpassen..
Het verschil is dat het niet om hun eigen geld gaat.
van de beheerders die ik ken is geld niet echt bepaald een motivator. Of het wel of niet om hun eigen geld gaat, is daarbij dan ook niet echt de vraag als die in actie moeten schieten voor iets, wel de kans om een issue op te lossen (wat veel meer motiveert).
Eens, ik word ook zo vaak boos op me zelf dat ik teveel dingen voor niets doe en laat doen om dat ik de uitdaging dan leuker vindt het feit dat het geld oplevert. maar dat heeft niets met beheerder te maken. ik als commercieel econoom ( De door jullie zo gehate geldwolf in veelte dure pakken )
bijkomend foutje in je redenering is het idee dat je het zelf beter kunt doen. Je hebt het idee meer controle te hebben over alles, maar die extra controle is niet zoveel waard persé.
Bij eigen beheer kun je zelf kiezen hoeveel prioriteit problemen krijgen. Overal worden fouten gemaakt, maar bij je eigen fouten kun je het probleem zelf ook weer oplossen, of experts inhuren om het voor je te doen. De keuze om de hele nacht door te werken aan een probleem kun je zelf maken.

Bij ingekochte diensten heb je die keuze meestal niet. Je probleem komt al snel op de grote stapel en support begint met dooddoeners als "is de firmware wel up to date?", "ik moet mijn script afmaken" of "installeer eerst maar onze remote-support tool". Het hoeft natuurlijk niet zo te gaan, er is ook goede support te krijgen, maar het is altijd zo dat iemand anders bepaalt hoeveel prioriteit je probleem krijgt.

Inkopen zal bijna altijd goedkoper zijn dan zelf doen en vaak hogere kwaliteit geven, maar als het echt belangrijk wordt en er onmiddellijk actie nodig is dan is het erg lastig om dezelfde toewijding te krijgen als eigen personeel kan bieden.
Je realiseert je hopelijk dat jouw eigen onafhankelijke infrastructuur ook in de problemen kan komen? Falende hardware, bugs en security issues in de software, verkeerde configuraties van het besturingssyteem etc etc.

Elk bedrijf moet zijn eigen afweging maken of zij alles in eigen beheer willen, of (deels) uitbesteden aan third-parties, voor beide opties is wat te zeggen. Maar de wijze waarop je je bovenstaande bericht schrijft komt nogal arrogant over, mist enige zelfreflectie, en daarmee gebrek aan inzicht in de risico's van de eigen infrastructuur.
De systemen en netwerken die ik beheer zijn niet heel complex. Servertje met CentOS voor netwerkboot en account beheer, alle persoonlijke Bestanden lokaal en op een externe file server. Hosts zijn Windows met een vage shell er overheen. En ongeveer 50 gebruikers op het netwerk. De meeste software is web-based en draai onder Flash. Het is naar mijn idee niet super moeilijk om het beter te doen, helemaal als ik kijk naar hoe het nu draait.

Ik werk met uitgevers zoals Noordhoff en Meulenhoff, hun spul ligt er regelmatig uit of heeft te kampen met bugs, de touchboards werken niet met de nieuwste versie van Fash in combinatie met hun software bijvoorbeeld. Geef mij de broncode maar en ik port/clone die troep wel over naar een Electron desktop applicatie.

Het netwerk alleen al wordt bijna 2000 euro per maand voor betaald, die 2000 euro geeft ons het recht te bellen as het systeem weer eens niet werkt. Verloor de file server verbinding met de backup omdat het internet even down was? Kan je bellen want de link hersteld zichzelf niet, een simpele Systemd service zal dit probleem oplossen.

[Reactie gewijzigd door Omega op 13 mei 2019 10:23]

Zelf Flash software draaien waardoor je gebruikers de slechte flash plugins moeten gebruiken en je dan zorgen maken dat dingen naar de Cloud/PaaS/SaaS gaan en zeggen dat je het beter kan 8)7 8)7 8)7

[Reactie gewijzigd door GrooV op 13 mei 2019 10:20]

Verbaast me dat dit nog gebruikt wordt, gezien de prijs en omdat het nooit populair geweest is.
Je kan ook gewoon 1 browser hebben voor die tools en dan een andere voor gewoon surfen. Dus IE voor flash en Firefox met adblockers voor de rest. Het is niet zo moeilijk en er is een hoop mogelijk.

Niet zo snel oordelen.
Skool Automatisering?
Old Skool :) Niets mis mee BTW.

Ik snap ook niet waarom alles zo moeilijk is/lijkt, het is veelal bullshit bingo heb ik het idee.
Flash is lek als een rieten mandje en dat al jaren. |:(
Ondanks dat ik het met je eens ben dat veel bedrijven enkel uit gemak maar voor een grote derde partij kiezen is het altijd een afweging, en soms is een third party gewoon geschikter. Los van het punt dat je noemt (single point of failure) kunnen de kosten er simpelweg tegen opwegen, of is de schaalbaarheid van belang wat bij een third party wellicht ook beter is. "software op orde" en iets onderbrengen bij een third party kunnen best hand-in-hand gaan.
Je bent liever zelf je singlepointoffailure?
Als een netwerk waar ik volledige controle over heb een probleem heb kan ik direct het probleem bestrijden. Mocht een schijf in een server defect gaan bijvoorbeeld: Zal niet lang duren voor ik de kapotte schijf heb gevonden waarna ik snel een vervangende schijf kan installeren en een backup image er op flash, er vanuit gaand dat ik geen RAID toepas op die machine.

Momenteel hebben we weer te kampen met een "Third party single point of failure". Alle Chromebooks lopen te klagen over Flash bij een van de software pakketten, uitgevers website ligt er uit gok ik.
Ik begrijp hieruit dat jij dus ook nooit op vakantie gaat, en 24/7 bereikbaar bent voor het bedrijf?
De ideale medewerker ;)
Ok, schijf vervangen kun je dan.

En hoe sla je een amplified DDOS af?
Stekker dr uit, alles draait toch lokaal. Dan maar even geen internet :P
Je zou ook alles via een third party en jezelf laten lopen, je hebt dan altijd een backup toch? en geen single point of failure.
En daarom altijd Content-Security-Policy gebruiken als er externe sources/scripts worden gebruikt. Daarmee creëer je een whitelist van scripts welke uitgevoerd mogen worden, maar ook een whitelist naar welke domeinen informatie gestuurd mag worden. Wordt een extern script gehackt/geïnfecteerd, dan nog kan het script geen schade doen.

Daarnaast zijn er nog andere maatregelen denkbaar. Cookies niet leesbaar laten zijn vanuit javascript (httponly = true), zodat sessie en authenticatietokens niet gestolen kunnen worden.
Was hier de oplossing niet gewoon een script met SRI checksum embedded? Zo weet je zeker dat de versie van het script dat jij gekozen hebt het doet.

Tijdens het ontwikkelen zou je als ontwikkelaar toch sowieso merken dat de data naar meer dan 1 endpoint verstuurd wordt.. hopelijk?
Waar je naar verstuurd is niet iets dat overmate duidelijk wordt binnen je browser. Dit is iets dat je echt actief moet traceren. En dat is iets dat lang niet altijd gedaan wordt. Sterker nog, gezien het grote aantal web developers in vele soorten en maten zal het waarschijnlijk slechts een kleine minderheid zijn die dit soort dingen regelt.
Ook dat was inderdaad een maatregel geweest die had kunnen helpen. Zo creëer je ook meerdere security lagen in de vorm van een Swiss Cheese Model

[Reactie gewijzigd door Skyaero op 13 mei 2019 11:18]

Sja. Ik snap dat partijen dit soort tracking op hun website willen. Maar wáárom in hemelsnaam, zou je die trackers ook inladen op inlog- of betaalpagina's of andere pagina's waar gevoelige gegevens ingevuld moeten worden? Je weet toch al precies wat mensen op zo'n pagina komen doen, en het risico is het gewoon echt niet waard....

De enige reden die ik kan verzinnen is dat je gewoon echt te dom bent om te poepen en dezelfde header gewoon rucksichtsloss op al je pagina's include.
Het gevaar is niet alleen de trackers. Bedenk eens wat de impact zal zijn als bijvoorbeeld jQuery de sjaak is, en wordt gehacked. Dat iemand de jQuery CDN files weer te manipuleren, dan heb je miljoenen websites in één keer te pakken.

Zelf heb ik voor mijn werk een feature in hun CMS gebouwd waarmee externe sources on-demand worden gedownload en lokaal worden opgeslagen. Een update hiervan gebeurt enkel nadat iemand de broncode heeft gecheckt in een 'diff'-tool om te zien wat de wijzigingen zijn (controleren op malicious code gaat dan heel vlot). Als alles in de haak is, wordt die versie van de CDN gedownload en lokaal gebruikt.

Dit weerlegt het hele voordeel van de CDN, maar een 3rd party CDN gebruiken is gewoon vragen om dit soort ellende. (Zoals dat bericht van gister ook weer, AV partijen gekraakt)
Met een integrity hash voorkom je dit probleem met die third party scripts hoor. Maar daar waren de ontwikkelaars precies niet slim genoeg voor.

Zie:
https://hacks.mozilla.org...-integrity-in-firefox-43/

[Reactie gewijzigd door Aardbol_23564 op 13 mei 2019 11:31]

Dat is inderdaad de juiste oplossing. Maar browse het web eens rond, vrijwel niemand lijkt dit te gebruiken. Heel vaak zijn de beheersystemen hier ook niet op ingericht, denk bijv aan tag management oplossingen.

Deze feature is in mijn ervaring nog behoorlijk onbekend in de algemene developer community, kan wel wat marketing gebruiken. Ik vind dat geen kwestie van "slim", eerder een kwestie van opvoeding.
Zelfs het gebruiken van een externe image kan ernstige security issues met zich mee brengen. Zo heb ik ooit voor een klant het kapen van afbeeldingen een keer voorkomen door deze images te redirecten naar een pagina binnen de website van deze klant. Dat betekende dus dat op de plek van deze image, de site werd geladen. Klinkt wellicht extreem maar is echt mogelijk. Zo kun je dus ook via iets onschuldigs als het gebruiken van een externe afbeelding je bezoekers in gevaar brengen.
Ik vind het niet normaal dat als je vandaag een grote website bezoekt er gebruik wordt maakt van tientallen externe domeinen. Analytics hier, advertising daar.

Sinds enkele jaren gebruik ik de NoScript addon en whitelist enkel de domeinen om de website te doen werken. Een beetje omslachtig, maar het is de enige mogelijkheid om nog relatief anoniem en veilig op het internet te surfen.
Precies. Het is gewoon absurd wat er gebeurd. Hoe zou men het vinden als er in de supermarkt iemand met je meeloopt en gaat noteren waar je allemaal naar kijkt en hoe lang? Vastlegt wat je voor kleding draagt. Met je meeloopt naar buiten en weer opschrijft of je op de fiets of met de auto of anders komt, compleet met merk en type en kenteken. Dat als je dan bij de electronicagrootwinkel komt er iemand heel nadrukkelijk met een bord en folders van een bepaald merk koelkasten rond je heen cirkelt want je had net bij de supermarkt iets te lang voor de vriesafdeling gestaan. Dat zou men onacceptabel vinden. Maar dat is wel wat er op internet gebeurd.
Als je een minder omslachtige manier zoekt, kun je natuurlijk gewoon een adblocker installeren. Maar dat had je vast al bedacht.
Wat ik nergens lees is of er nu ook actief actie wordt ondernomen om de geinfecteerde scripts offline te krijgen. Blijkbaar weet men waar deze scripts draaien gezien er een "victims list" is gepubliceerd.
https://cloudcms.statuspage.io/
Alleen hebben ze zelf nog geen incidenten 8)7 :X

"All Systems Operational"

May 13, 2019
No incidents reported today.

May 12, 2019
No incidents reported.
Enz.

Dus niks aan de hand hoor... :o
Dit doet me denken aan een interessant artikel over een gelijke vector: externe code ;). Alle externe code over 1 kam scheren is wellicht iets te generiek... maargoed, zoals de auteur van dat artikel ook schrijft:
Lucky for me, we live in an age where people install npm packages like they’re popping pain killers.


Om te kunnen reageren moet je ingelogd zijn


OnePlus 7 Pro (8GB intern) Microsoft Xbox One S All-Digital Edition LG OLED C9 Google Pixel 3a XL FIFA 19 Samsung Galaxy S10 Sony PlayStation 5 Huawei P30 Pro

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank, Intermediair en Independer de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True