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

Door , , 62 reacties

Cms-bouwer Joomla heeft drie beveiligingsproblemen gepatcht, waaronder een zeer kritiek lek waardoor een sql-injectie uitgevoerd kan worden. Het sql-probleem zit in versie 3.2 tot en met 3.4.4 en werd ontdekt door Trustwave SpiderLabs. De patch hoogt het versienummer iets op naar 3.4.5.

Joomla! fpaDe onderzoekers van Trustwave konden volledige toegang krijgen tot elke kwetsbare Joomla-site, schrijft Trustwave op zijn blog. Joomla had op 20 oktober volgens W3Techs 6,6 procent van de markt voor website-cms'en in handen, wat zou betekenen dat zo'n 2,8 miljoen websites draaien op het cms. De patch naar Joomla 3.4.5 is te downloaden vanaf de Joomla-site. Naast de drie beveiligingsupdates is er niets veranderd aan de code van het cms.

In aanloop naar de patch gaf Joomla op 16 oktober al aan dat er een zeer belangrijke patch uit zou komen op 22 oktober, waardoor de meeste beheerders van servers waar Joomla op draait, al bekend zullen zijn geweest met de komst van de patch. Verdere details werden toen nog niet vrijgegeven.

Het probleem in Joomla komt door niet voldoende filteren van data die opgevraagd wordt. Naast de sql-problemen, zijn twee andere bugs opgelost in de com_contenthistory- en com_content-functie die het mogelijk maken voor aanvallers om toegang te krijgen tot data die normaal alleen voor gebruikers met de juiste rechten zichtbaar moet zijn. De com_content-kwetsbaarheid zit in Joomla-versies 3.0 tot en met 3.4.4 in plaats van 3.2 tot en met 3.4.4.

De sql-kwetsbaarheid zit in /administrator/components/com_contenthistory/models/history.php. Door een sql-injectie uit te voeren, wordt vervolgens een foutpagina getoond. In het error-rapport onderaan de pagina staat een sessie-id. Na het plakken van het sessie-id in de cookie-sectie in de request om de /administrator/-directory binnen te komen, worden administrator-rechten toegekend en wordt toegang verkregen tot het admin-control-panel. Een gedetailleerde omschrijving van de hele hack staat op het Trustwave-blog.

Moderatie-faq Wijzig weergave

Reacties (62)

Als je nu update via de ingebouwde update functie worden er diverse bestanden overschreven terwijl dat niet nodig is. Deze zitten niet in de incremental update die je via de website kan downloaden, maar dus wel in de auto updater. In mijn geval betreft het een aanpassing in /plugins/content/pagebreak/pagebreak.php . Snel opgelost, mits je backups hebt, maar dus wel even opletten!

Verder zit er al sinds vorig jaar een fout in sessies in combinatie met Chrome voor ingelogde gebruikers. Als ze dat nu ook eens aanpakken...

[Reactie gewijzigd door sdk1985 op 22 oktober 2015 21:03]

Thanks voor de heads up! Maar is het bij Joomla niet de bedoeling om belangrijke (core) files te overriden i.p.v. overschrijven? :) Dan voorkom je dus dit soort zaken als het bestand een keer moet worden geüpdatet.
Dat lijkt mij ook, het lijkt mij niet de bedoeling om corefiles zelf te gaan zitten aanpassen..
Dat is in ieder geval handiger, behalve wanneer je het override bestand handmatig moet gaan updaten zodat je niet blijft zitten met de security exploit :+ .

In mijn geval heb ik in de template map inderdaad een aantal onschuldige com_content en mod_breadcrumbs overrides staan. Echter de getroffen file is een standaard system plugin (pagebreak, heeft geen tmpl folder) en dat heb ik helaas nooit aan de praat gekregen via een template override.

De auto updater heeft in ieder geval flink huisgehouden als ik naar de timestamps van php files kijk ;).

[Reactie gewijzigd door sdk1985 op 22 oktober 2015 23:36]

Is dat al een bekend issue op Github? Want anders kan je dat gewoon daar plaatsen.
Eerlijk gezegd geen idee. Heb het ooit weleens gerapporteerd op het forum en heb er weleens vaker users over gehoord.

De bug is vrij simpel te reproduceren. Kwestie van een aantal keren artikelen openen en afsluiten met afwisselend back (niet netjes) en close (netjes).

Vervolgens krijg je binnen een minuut de volgende melding als je een eerder geopend artikel probeert te openen: "Error You are not permitted to use that link to directly access that page (#156)." Herhaalde pogingen resulteren daarna niet eens meer in een melding maar geven een refresh van de overzichtpagina. De Chrome browsing data een uur terug zetten lost het op.

[Reactie gewijzigd door sdk1985 op 22 oktober 2015 22:04]

Als je bekend bent met/op Github, hier kan je een issue aanmelden:
https://github.com/joomla/joomla-cms/issues

Ik moet eerlijk zeggen dat ik je bug daar niet gezocht heb, te veel tabjes open zo vlak voor het slapen die nog afgewerkt moeten worden... :+
Wat ik wel eigenaardig vind: nog geen uur nadat de update van joomla live staat, zetten die lieve jongens van Trustwave de hack online. Op hun site beweren ze: " Trustwave helps businesses fight cybercrime, protect data and reduce security risk." Ze bewijzen hier het tegendeel.

Had dit zelfverklaarde cybercrimefighterbedrijf niet een dagje kunnen wachten?
Normaal gesproken wacht ik een paar dagen met het bijwerken van een nieuwe Joomla versie. In het verleden zijn er wel eens issues geweest die direct na een nieuwe release naar voren kwamen. Vanwege de security bulletin van afgelopen dagen met de grote urgentie, deze keer maar wel meteen de website bijgewerkt. Tot nu toe nog geen problemen ondervonden. Ben nu wel benieuwd hoe lang het duurt voordat deze exploit actief wordt misbruikt, aangezien er een uitgebreide beschrijving op internet is verschenen.
Hier hetzelfde... maar geupdate. Als ik de exploit zo bekijk lijkt het er wel op dat je de database prefix moet kennen. Die wordt tegenwoordige random gegenereerd. Verder lijkt het te vereisen dat een standaard error pagina die een systeemfout weergeeft wordt gebruikt. Het geeft maar weer aan hoe belangrijk het is om geen systeemfouten aan eindgebruikers te tonen, maar dat je er zelf maar een verhaal bij moet verzinnen. Het is overigens wel een "mooie" exploit waar best wel wat losse joomla eindjes zijn gevonden.
Daarnaast moet de sessie ook nog eens een actieve adminsessie zijn. in 90% van de gevallen of meer zal die sessie niet meer actief zijn, of je moet net geluk hebben dat een admin is ingelogd. In Joomla verloopt een sessie by default na 15 minuten inactiviteit :P
Ik zag een melding van een Joomla ontwikkelaar dat twee uurtjes na de update beschikbaar werd in zijn logs al de eerste pogingen te zien waren.
Viel me ook al op, beetje jammer. Meteen alle sites geüpdatet :)
Ik zag al reacties van Joomla ontwikkelaars op twitter daarover, die waren er totaal niet blij mee. Het is een serieus probleem die gevonden is. Op deze manier veroorzaken ze echt veel gehackte sites omdat het blijkbaar relatief makkelijk te misbruiken is. Ik hoop echt dat mensen de social media aandacht opgevallen is en vandaag klaar was voor de update.
Ligt het nu aan mij, of is het überhaupt wat vreemd, dat je de sessie kan kapen?

Misschien lees ik erover heen, maar ik zie niet, dat de sessie ook actief moet zijn.
Nu weet ik niet uit mijn hoofd, hoe sessies normaliter gecontroleerd worden. (neem aan dat een ander IP adres bijvoorbeeld niet zomaar werkt)
Houdt Yoomla php sessies langer open, of creeert die ze automatisch vanuit de database, als je ze handmatig invoert?

Dat laatste lijkt me toch een redelijke security risk, ala unsalted wachtwoorden. (naast dat een SQL injection mogelijk is)
Nu weet ik niet uit mijn hoofd, hoe sessies normaliter gecontroleerd worden. (neem aan dat een ander IP adres bijvoorbeeld niet zomaar werkt)
Het is voornamelijk keuzes maken, grote bedrijven willen nog wel eens load-balancers voor niet hebben waardoor ip-adressen kunnen wisselen dus daarop vastpinnen geeft weer andere problemen.
Je kan hem op browser characteristics vastpinnen, maar dan log je mensen uit bij een update van chrome / FF en dat is ook meestal niet gewenst.
Maar vooralsnog is een sessie id niet-versleuteld opslaan in deze context toch net zo erg als een unsalted wachtwoord?

Ik zou dat namelijk stiekem wel de reden vinden om echt niemand iets van Joomla aan te raden.
SQL injections zou je tegenwoordig toch echt wel ervaring mee moeten hebben (en dus overgaan op methodes, waarbij je simpelweg niet de query zelf kan laten aanpassen), maar ik gooi dat even op de 'legacy' code hoop.

Dit is niet even in een pluginnetje gevonden ofzo.. dus ik vind het behoorlijk ernstig, als mijn aanname juist blijkt.
Een session ID is maar een random string die geldig is zolang de sessie duurt.
De data waar dat ID heen wijst is veel interessanter.
Ja inderdaad.. Zo is het zoals ik het me bedenk.. Het feit dat je met een sessie id (die eigenlijk random zou moeten zijn) specifieke gegevens kan ophalen.. vind ik zo raar.. en herken ik eigenlijk niet uit andere systemen.

Ik heb wel eens heel lang geleden een code gemaakt, waarmee dat ook mogelijk was. (zelf sessie management via database).. Lijkt me niet dat de 'industrie' deze werkwijze erg tof vindt.
Nee ik vind het ook raar.
In mijn eigen systeem kan je hooguit met dat ID de boel op de server zelf gaan opzoeken, maar daar heb je al server-toegang voor nodig + kennis van PHP.
Gelukkig ben ik niet de enige dan.. SQL injection vind ik eigenlijk niet goed te praten, maar tollereer ik. Dat de sessie hijacking mogelijk is.. Ik zou er mensen voor ontslaan, want je hoort gewoon niet in de back-end te werken met die aanpak.

Systemen ala Joomla zouden best wel een een paar keer diep in de code gecontroleerd mogen worden; kennelijk nooit gedaan.
Nu staat mijn mening vaak niet op 1 lijn met de developers van zulke systemen. Ook heel vaak in Wordpress commentaar regels gezien "You never need this!" of een andere typische opmerking.
Precies.. daar.. waar ik iets moest extenden ;)

(was bezig met een échte multidomain site implementatie)
In Joomla zit (of zat) blijkbaar iets een beetje verkeerd in elkaar, als je met het browsen naar een pagina waar je niet bij mag automatisch een sessie creëert die rechten heeft op die (en alle gerelateerde?) pagina(s) dan is de boel niet veilig natuurlijk, ben benieuwd waarom dat zo werkt.

Sowieso altijd voorzichtig zijn met systemen als Joomla Wordpress Drupal etc, het is maar iets kleins (en je moet ook niet de hele veiligheid van een site daarop laten leunen!!) maar als je zulke systemen gebruikt is het altijd verstandig om de admin directory even te hernoemen, ondersteunen voor zover ik weet de meeste CMS's vandaag de dag ook gewoon via config files.
Ik heb vroeger met Joomla gewerkt en werk tegenwoordig nog wel eens met Wordpress.
Wordpress kent gewoon een nieuwere code structuur, waarbij SQL injection echt alleen mogelijk is.. als je zelf dingen gaat lopen schrijven.

(ik neem aan dat elke contributor, die SQL injection risico introduceert, een figuurlijke nekschot krijgt)
Daarom zeg ik hierbij ook expliciet alle hoop in Joomla op, omdat dit gewon veels te lang heeft voortgesukkeld en kennelijk in de basis fout gaat al. (vermoedelijk is het 1 van de oprichters/seniors, die eigenwijs doet / marketing als projectlead).

Het blijft altijd een risico met deze pakketten en elke plugin moet je gewoon op zijn minst skimmen door de code.
Ik vind het echt ongelofelijk knap dat ze zo'n exploit überhaupt vinden!
Waarom vind je het knap, in dit geval?
Omdat het pad via sessie cookies en Headers loopt. Knap gevonden, vind ik dan.
Veel sites werken met sessie cookies, het is dan ook een welbekende techniek om te kijken of je een vreems uitziend ID wat ergens op een pagina (error page, log page, about page) kan worden gebruikt om zo in te loggen.

Da's ook waarom dit soort ID's idealiter niet alleen in een cookie staan en dat er van de sessie wordt bijgehouden waar deze vandaan komt, om zo te voorkomen dat de sessie zomaar op een andere pc gebruikt kan worden. IP adres, browser en andere gegevens kunnen gebruikt worden om een sessie ID beter te beschermen.
Ip is alleen niet aan te raden... Ik heb vaak genoeg bij grote bedrijven load balancing gezien waarbij je externe ip zomaar veranderd...
In dat geval kun je ook werken met een combi met whitelisting. Zodra je binnen die IP' switched behoud je de sessie zolang bijv. De useragent en andere variabelen kun je dan vervolgens ook gebruiken. Mss icm een html5storage opgeslagen hash. Er zijn een hoop mogelijkheden :)
Gelukkig is het updaten van een Joomla CMS zeer eenvoudig. Heel goed van deze mensen dat er direct een update is uitgebracht.
Ik weet niet hoeveel mensen aan Joomla hebben gewerkt maar met zo'n gigantische codebase lijkt het me niet heel onvermijdelijk dat er af en toe iets verkeerd terecht komt.

[Reactie gewijzigd door Aggror op 22 oktober 2015 19:53]

Nouja... Af en toe is enigszins een understatement.
http://www.cvedetails.com...endor_id-3496/Joomla.html
310 Vulnerabilities in de algehele productlijn is echt een immens aantal.
Ik bedoel... Zelfs phpNuke (*slaat kruisje*) had er nog minder. :P

Het is best vaak mis met Joomla. Samen met Wordpress (noot: al komt dat vaak door brakke plugins. Ironisch genoeg was dat een tijdje terug iThemes Security :')) is het 't meest gehackte CMS zowat. Als er een site gehacked wordt is de culprit meestal 1 van die 2.

Dat komt ook door brak update gedrag van de gebruikers overigens, en dat neem ik Joomla niet kwalijk; maar het lijkt zowat alsof er in elke Joomla versie wel een exploitable lek zit; en dat maakt het wel nogal een probleempje.

Wel blij dat ze er bovenop blijven zitten, maar volgens mij heeft die hele codebase echt een zeer grondige review nodig. :)
Gek, naar mijn herinnering is dit de eerste keer dat er echt een serieus probleem was. Met deze link valt het de laatste jaren wel mee, gelukkig.
http://www.cvedetails.com/vendor/3496/Joomla.html
Het aantal security problemen in Joomla Core is juist gering. Het wil nog wel eens mis gaan met extensies, een probleem waar meer populaire cms'en mee kampen.

Qua grondige review, Joomla 3.x is niet te vergelijken met Joomla 1.5 , als dat is wat je bedoelt. Qua eisen aan de hosting software is Joomla veeleisender dan sommige andere CMS'en, maar veel hosters lopen niet bepaald voorop. Veel PHP-updates zijn security updates, maar hoe lang duurt het niet voordat die verplicht worden door een CMS?
Dat is ook een deel van het speelveld.
Nouja... Af en toe is enigszins een understatement.
http://www.cvedetails.com...endor_id-3496/Joomla.html
310 Vulnerabilities in de algehele productlijn is echt een immens aantal.
Als je verder kijkt, zie je dat er "maar" 3 in 2015 gevonden zijn, de rest (en veel meer per jaar) in 2014 en verder terug. Toppunt is 2008, met 96 gevonden security leaks, dan gaat het rap ja. De "top 3" waarin voor Joomla de meeste security leaks gevonden zijn, zijn dan ook 2008 (96), 2007 (59) en 2006 (51). Dan zit je al op ruim tweederde van de gevonden bugs. Die dus in versies zitten, waarvan ik toch zeker mag hopen, dat die al jaren niet meer gebruikt worden.

Overigens zijn de meeste (55,5%) code exectution leaks, op twee gevolgd met SQL injection leaks (41,3%). (Bron)

Mag hopen dat Joomla beheerders niet meer op codebase zitten van 2013 en ouder... ;)

[Reactie gewijzigd door CH40S op 23 oktober 2015 02:02]

SQL-injectie in een CMS wat al zo lang bestaat, en in deze tijd is wel een beetje triest, hoor.
Ik vind het knap dat het niet veel vaker voorkomt. De codebase van Joomla is best groot, en best oud al (uit de tijd VOOR behoorlijke DB lagen). Een tikfout is zo gemaakt.
Heeft PHP geen ondersteuning voor parameterized queries ?
Zeker wel. Al heel lang. Maar development is vaak het maken van keuzes. Daarnaast kan het zijn dat het probleem al eerder gemeld is maar dat het niet belangrijk genoeg was om het aan te pakken. Prioriteiten zijn soms een beetje krom.
Zeker wel, maar nog niet zo lang als Joomla al bestaat. Nu ga ik er wel vanuit dat de DB laag van Joomla meegegroeid is met de ontwikkelingen in PHP, maar zoals ik eerder zei: een foutje is zo gemaakt (of vergeten ergens de code aan te passen).
Op meerdere manieren zelfs. In ieder geval in PDO, waarschijnlijk ook in msqli.
Triest? Beetje vreemde reactie maar goed.

Het probleem in de code is in november 2013 in een release-versie gekomen. Het bestond dus al twee jaar maar het gebruik van die functionaliteit is volgens mij niet zo groot. Misschien dat daarom de aandacht wat minder is geweest voor exploits.
Update uitgevoerd van 3.4.4 naar 3.4.5 zonder issues.
Had nog geen email van Joomla zelf gehad.
@Blubber: komop een beetje genuanceerder mag ook wel. Ik snap dat je het dom vind maar fouten maken is nog steeds menselijk.
Ik ben het eigelijk wel met 'm eens. Je word er, overal, op gehamerd om je queries te beveiligen als je ze nog zelf schrijft. De meeste CMS'en/applicaties gebruiken een DB abstractie laag die het voor je doet (met prepared statements), dus daarom vinden we het zo vreemd dat het anno 2015 nog voorkomt.
Ik ben eigenlijk wel benieuwd waarom het nu pas gepatched is en niet een tijdje geleden.
Ik ken de Joomla codebase niet zo goed, maar het kan zo zijn dat het misschien te onoverzichtelijk is door bijvoorbeeld verschillende code styles of gewoon door oudere technieken.
Ik ook. Ik ken Joomla helemaal niet, alleen van naam. Anno 2015 zou je toch verwachten dat er unit tests gedraaid worden op de codebase, dan komen zulke dingen (als het goed is) direct naar boven.

Het zal waarschijnlijk ook te maken hebben met het aantal personen wat eraan werkt. Hoe meer mensen werken aan een project hoe groter de kans op dit soort incidenten word.
Zeg, kan ik mijn foute reactie niet verwijderen? :+

[Reactie gewijzigd door Xaverius op 23 oktober 2015 07:28]

Goed onderbouwd man.

Net als met Wordpress is het grootste risico van Joomla het gebruiken van extensies/plugins. Als je gecrackte/genullde extensies/thema's gebruikt, of niet op tijd update is het overal vragen om problemen. Maar mede door de uitbreidbaarheid zijn het twee enorm veelgebruikte systeem.
Je reactie getuigt niet van "heel wat jaren meelopen in de IT", en al helemaal niet van professionaliteit. Of bedoel je met IT-ervaring zelf een website maken via een wysiwyg-editor?

Joomla (samen met Wordpress) wordt door veel meer grotere bedrijven gebruikt dan jij denkt, en het zijn meer dan prima systemen die zich wel degelijk bewezen hebben. Het probleem zit hem bij mensen (zoals jij?) die niet weten hoe ze er mee om moeten gaan. Je wordt niet voor niets met -1 gemodeerd. Wat is volgens jou een betere oplossing? Een maatwerk CMS? Het is niet voor niets dat 90% van de grote media-/internetbedrijven oplossingen bieden aan klanten door middel van Wordpress/Joomla.

Er is geen spam verstuurd omdat het systeem van Joomla of Wordpress lek was, maar omdat een hobbyist met allemaal louche plugins aan de slag ging zonder alles netjes up-to-date te houden. Dáár zitten de problemen. Of geef jij Windows zelf ook de schuld van BSOD's door fabrikanten die slechte drivers leveren?
Weet je, als jij met gecertificeerde drivers een bsod krijgt is het inderdaad de schuld van microsoft. Dan is hun certificatie programma niet op orde.

En er zijn ook heel veel grote bedrijven die bewust om deze reden niet voor Wordpress of Joomla kiezen. Dus dat is een non argument.

Maar zoals ik al zei blijf het lekker gebruiken. Ik gaf enkel mijn persoonlijke ervaring weer met dit soort scripts. Je hoeft mijn ervaring niet te delen! Jij bekijkt security enkel vanuit je persoonlijk gebruik. Ik bekijk het meer vanuit een breed perspectief wat zoiets voor het hele internet betekent. Ik vind dat als je dit soort scripts ontwikkeld welke door jan en alleman te gebruiken zijn je ook een taak hebt om te zorgen dat jan en alleman deze makkelijk veilig kunnen houden. Dat laatste is simpelweg niet het geval en tien duizende hobby sites staan vandaag de dag met grote security risks online, wat ons internet er niet beter op maakt.
Zet alle computers maar gauw uit dan, die veroorzaken ook alleen maar ellende met botnets en malwareverspreiding! :o Hebben ons alleen maar ellende gebracht die dingen 8)7
Ja, dat is mij weleens gebeurd, dat ik met certified drivers een bsod kreeg, dus ook een non argument. Dat veel bedrijven kiezen om iets niet te doen, wilt ook niet altijd zeggen dat het goed is, hetzelfde non argument. Kom met feiten ipv onderbuik gedoe.
Is het dan niet de schuld van microsoft als zij drivers certificeren die gewoon instabiel zijn?
Precies, daarom same als jou redenatie, een non-argument. Zo kan je bezig blijven.
Hoezo niet dan? Hun certificeren toch drivers die niet goed zijn. Dan gaat toch de hele point van hun certificatie programma verloren.. Ik snap je denkwijze echt niet.

Hun certificeren een driver als zijnde geschikt voor windows. Als deze dat dan niet blijkt te zijn heeft microsoft toch wat verkeerd gedaan?

[Reactie gewijzigd door ro8in op 23 oktober 2015 21:15]

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True