image

Australische overheid geeft tips om WordPress te beveiligen

donderdag 5 maart 2020, 09:53 door Redactie, 8 reacties

Organisaties die gebruikmaken van platformen zoals WordPress, Drupal en Joomla doen er verstandig aan om hun installatie goed te beveiligen, aangezien aanvallers continu naar kwetsbare websites zoeken. Daarvoor waarschuwt het Cyber Security Centre van de Australische overheid (ACSC).

"Kwetsbaarheden in contentmanagementsystemen (CMS) worden vaak misbruikt door aanvallers. Zodra een CMS is gecompromitteerd kan de webserver voor gerichte aanvallen worden gebruikt", aldus het ACSC. Het gaat dan bijvoorbeeld om het installeren van malware op de webserver of het injecteren van kwaadaardige code in de website.

Om dergelijke aanvallen te voorkomen geeft het ACSC verschillende beveiligingstips, zoals het gebruikmaken van een CMS-hostingprovider, in plaats van het zelf installeren en onderhouden van een CMS. Verder wordt aangeraden om beschikbare beveiligingsupdates voor het CMS en onderliggend systeem tijdig te installeren. Het draaien van verouderde webserver- en CMS-software is namelijk een veelvoorkomende reden dat aanvallers weten in te breken.

Tevens adviseert het ACSC om gebruikersnamen en wachtwoorden van alle diensten te veranderen, sterke passphrases te gebruiken en toegang tot het beheerderspaneel tot alleen goedgekeurde interne ip-adressen te beperken. Verder moeten alleen betrouwbare CMS-plug-ins worden gebruikt en is het verstandig om niet gebruikte functionaliteiten en plug-ins uit te schakelen. Dat geldt ook voor debug- en foutmeldingen. Afsluitend wordt aangeraden om CMS-installaties te monitoren.

Image

Reacties (8)
05-03-2020, 12:27 door Anoniem
Hoe vaak hebben wij dit hier ook al niet aangehaald?.
Op PHP gebaseerd CMS, "an neverending drama" in vele bedrijven.
Wordt onvoldoende van updates en patches voorzien.
Draait soms met plug-ins, die verlaten zijn, dus nooit meer veilig kunnen worden.

Draait met kwetsbare bibliotheken (jQuery als licorice all sorts, allerlei versies naast elkaar).
Heeft heel vaak verkeerde settings qua user enumeration and directory listing
(die staan dan op "enabled").

Dank aan de Nederlandse onderrzoeker en Willem de Groot, een andere roepende in de woestijn,
die Magento webshops wat veiliger probeert te houden via zijn mage report scans.
Voorbeeldje van een hele versie missers: https://publicwww.com/websites/magento+/3

Krakatau en ik hebben hier al zo vaak voor gewaarschuwd.
Toch gaan de decision makers bij website development liever voor een gelikte website met dit CMS
dan voor een wat veilige(r) ontwerp.

Om over beveiliging en monitoring van de client server connectie maar te zwijgen.
Kijk maar eens hier; https://webcookies.org/
Het lijkt wel of je er geen beweging in positieve zin in kan krijgen.

Hoeveel incidenten zijn er nodig om de getrainde aapjes wakker te krijgen?
Ik vecht al twaalf jaar tegen deze bierkaai.
Schiet niet op, nou, dan krijgt men maar wat men verdient - kwetsbare pruts.

luntrus
05-03-2020, 13:08 door Anoniem
Door Anoniem: Hoe vaak hebben wij dit hier ook al niet aangehaald?.
Op PHP gebaseerd CMS, "an neverending drama" in vele bedrijven.
Wordt onvoldoende van updates en patches voorzien.
Draait soms met plug-ins, die verlaten zijn, dus nooit meer veilig kunnen worden.

Draait met kwetsbare bibliotheken (jQuery als licorice all sorts, allerlei versies naast elkaar).
Heeft heel vaak verkeerde settings qua user enumeration and directory listing
(die staan dan op "enabled").

Dank aan de Nederlandse onderrzoeker en Willem de Groot, een andere roepende in de woestijn,
die Magento webshops wat veiliger probeert te houden via zijn mage report scans.
Voorbeeldje van een hele versie missers: https://publicwww.com/websites/magento+/3

Krakatau en ik hebben hier al zo vaak voor gewaarschuwd.
Toch gaan de decision makers bij website development liever voor een gelikte website met dit CMS
dan voor een wat veilige(r) ontwerp.

Om over beveiliging en monitoring van de client server connectie maar te zwijgen.
Kijk maar eens hier; https://webcookies.org/
Het lijkt wel of je er geen beweging in positieve zin in kan krijgen.

Hoeveel incidenten zijn er nodig om de getrainde aapjes wakker te krijgen?
Ik vecht al twaalf jaar tegen deze bierkaai.
Schiet niet op, nou, dan krijgt men maar wat men verdient - kwetsbare pruts.

luntrus
Even gratis jouw ego strelen en reclame maken, terwijl het artikel over Australië gaat?
05-03-2020, 13:38 door karma4
Door Anoniem: ...
Toch gaan de decision makers bij website development liever voor een gelikte website met dit CMS dan voor een wat veilige(r) ontwerp. ...
luntrus
Dat is de terugkerende algemene factor. Heel handig (niet dus) om tegengestelde geluiden naar beslissers te sturen.
Vraagje: Zou een aanpak in containerisatie van de lagen in het plaatje niet veel kunnen helpen?
Nu wordt met docker ingezet om alle lagen als een monolitisch blok heel vaak te kopiëren. Gaat heel vaak naar niet veilig in een snelle uitrol en snel een gelikt resultaat voor de productowner.
05-03-2020, 14:17 door Anoniem
Beste karma4,

Dat zou best wel kunnen helpen, maar het gaat om algemene veiligheidsmaatregelen hier. Iedereen kan weten dat je de laatste CMS versie moet gebruiken en dat geldt ook voor thema's en plug-ins. Af te voeren code afvoeren. Niet oudere bibliotheken naast nieuwere aanhouden. Men codeert m.i. zonder enig oog voor security. Ik zie geen DOM-XSS scans voor sinks en sources uitvoeren, etc. etc. Wat hoor je, "Het werkt toch, man. Wat z**k jij nou weer!

Er zijn "two to tango" voor nodig, dus niet alleen de website developer en website admin, die de boel veilig dient te hebben en houden, bijvoorbeeld qua header-security, DNSSEC etc. waar nodig, maar ook bij de hoster, cloudboer, die kwetsbare code en server software moet afserveren. Goed development is een goede grondhouding aannemen.

Als de snelweg een IT infrastructuur zou zijn, kwamen we nogal wat auto's met betonnen gestorte kippengaas vloertjes tegen en afgesleten banden. Onvoorstelbaar, op Interwebz tolereren we dit kennelijk allemaal. Vanwege belangen denk ik, anders valt het echt niet te verklaren en natuurlijk het vigerend ongekend technologisch onbenul van vele Internet deelnemers, Ja zowel onder eindgebruikers als inrichters. Leg het maar eens uit?

Op een security forum vraag ik al meer dan dertien jaar aandacht voor genoemde problematiek. Er verandert geen z*k.
Loop acht jaar rond op een Hoge School voor IT studies geen aandacht voor,. Zie toe bij praktische MBO opleidingen, geen aandacht. Dat worden later onze first line TOP Desk medewerkertjes. Mannen en vrouwen, die rapportjes moeten opmaken en mensen helpen bij software problemen. Security aandacht, zilch! Getrainde aapjes, klaargestoomd door grootgraaier & co.

Neen, men is dit soort alert verspreiders als ondergetekende liever kwijt dan rijk. Man, man, man, wordt je daar moedeloos van op den duur. Altijd weer die roepende in de woestijn zijn. En de woestenij wordt alleen maar woester.

luntrus
05-03-2020, 16:53 door karma4
Door Anoniem: ….
Op een security forum vraag ik al meer dan dertien jaar aandacht voor genoemde problematiek. Er verandert geen z*k.
Loop acht jaar rond op een Hoge School voor IT studies geen aandacht voor,. Zie toe bij praktische MBO opleidingen, geen aandacht. Dat worden later onze first line TOP Desk medewerkertjes. Mannen en vrouwen, die rapportjes moeten opmaken en mensen helpen bij software problemen. ….
luntrus
Gedeelde smart maakt het niet minder helaas, het wordt eerder verdubbeld. Perfect zal niet zo maar 1,2,3 gaan lukken.
Wat ik nu zie is dat de hele stack open ligt als er ergens eentje is omgevallen en het probleem bekend wordt.
Met gescheiden rollen gescheiden taken etc. bouw je tenminste daartussen nog wat veiligheid.
Auto's hebben ook allemaal extra's gekregen die je nooit nodig hoopt te hebben. Wie wil nu de kreukelzone en riemen en airbags gebruiken waarvoor ze bedoeld zijn. Tja goed development met een goede grondhouding …..
05-03-2020, 18:12 door Anoniem
@karma4,

Wat een rare opmerking van anoniem van 13:08
Even gratis jouw ego strelen en reclame maken,
terwijl het artikel over Australië gaat?
Ja, dat doe ik dan vooral totaal anoniem hier, hoi, hallo,
hoort u mij? Ik ben Willem de G. niet, alhoewel ik zijn werk waardeer. Ik doe het echter als vrijwillger 'for the good of all'.
Behalve een stickertje hier en een T-shirtje daar niets om mijn ego mee te strelen. ;>)

Het probleem met onveilig op PHP gebaseerd CMS is helaas niet beperkt tot Australië, maar een globaal probleem.
Maar vooral een probleem, daar waar veel softwarematige monocultuur bestaat.
In het land der blinden is immers altijd eenoog koning.

Veel voorkomende veiligheidsproblemen op de stack van zeg maar een doorsnee Word Press websites:
No-disallowed-headers (zo'n 50 problemen per website)
No-protocol-relative-URLs (2 of 3 problemen zeker)
SRI issues (rond de 30 issues)
Strict-transport-security (in de 50 problemen, zeg maar)
x-content-type-options (een dikke 50 issues doorgaans)
no-vulnerable-javascript (zelden meer dan 3 af te voeren bibliotheken)
SSLLabs (gemiddeld 1 aanbeveling) bron: Open JS Stichting.

Ga dat dan maar uitsplitsen per Stack security laag.

Het is ook nog eens de veiligheidsgerelateerde interactie tussen de verschillende componenten van client en (web)server.
En dan gaat het steeds om de aard van de kwetsbaatheid en een methode die uit te buiten,
net zoals bij DOM-XSS de relatie sinks en sources.

Als er geen tijd wordt gegund de maatlat er goed langs te kunnen leggen via een voortdurende pentest,
blijven we in de mallemolen rondtollen van nu.

luntrus
05-03-2020, 22:55 door souplost
Door Anoniem: @karma4,

Wat een rare opmerking van anoniem van 13:08
Even gratis jouw ego strelen en reclame maken,
terwijl het artikel over Australië gaat?
Ja, dat doe ik dan vooral totaal anoniem hier, hoi, hallo,
hoort u mij? Ik ben Willem de G. niet, alhoewel ik zijn werk waardeer. Ik doe het echter als vrijwillger 'for the good of all'.
Behalve een stickertje hier en een T-shirtje daar niets om mijn ego mee te strelen. ;>)

Het probleem met onveilig op PHP gebaseerd CMS is helaas niet beperkt tot Australië, maar een globaal probleem.
Maar vooral een probleem, daar waar veel softwarematige monocultuur bestaat.
In het land der blinden is immers altijd eenoog koning.

Veel voorkomende veiligheidsproblemen op de stack van zeg maar een doorsnee Word Press websites:
No-disallowed-headers (zo'n 50 problemen per website)
No-protocol-relative-URLs (2 of 3 problemen zeker)
SRI issues (rond de 30 issues)
Strict-transport-security (in de 50 problemen, zeg maar)
x-content-type-options (een dikke 50 issues doorgaans)
no-vulnerable-javascript (zelden meer dan 3 af te voeren bibliotheken)
SSLLabs (gemiddeld 1 aanbeveling) bron: Open JS Stichting.

Ga dat dan maar uitsplitsen per Stack security laag.

Het is ook nog eens de veiligheidsgerelateerde interactie tussen de verschillende componenten van client en (web)server.
En dan gaat het steeds om de aard van de kwetsbaatheid en een methode die uit te buiten,
net zoals bij DOM-XSS de relatie sinks en sources.

Als er geen tijd wordt gegund de maatlat er goed langs te kunnen leggen via een voortdurende pentest,
blijven we in de mallemolen rondtollen van nu.

luntrus
Wat je nodig hebt is een goed framework (bv https://www.djangoproject.com/ ) dat je behoedt tegen de meest voorkomende beveiligingsfouten. Een PHP gebaseerd CMS is niet meer van deze tijd maar nog wel veel gebruikt door hobbyisten.
06-03-2020, 14:46 door Anoniem
Hoi, m'n beste souplost,

Het wordt toch nog op MBO praktisch onderwijs niveau veel ingeklopt op de stack.
Het zogenoemde lagere IT en gamer-opleidingsomgevingen. ;>)
Later lopen ze bij je provider en bij de ambtenarij, de zogeheten vierde IT macht.

En ook bij grote zakelijke web developers voor PHP gebaseerd CMS (Word Press, Magento, Drupal).
Ziet er mooi uit, maar de veiligheid laat te wensen over. Goedkoop is duurkoop vaak, maar niet altijd.

Typisch Hollands, als als eerste aanzien de ramen maar goed gelapt zijn, is het verder een rotzootje in huis
en draagt men de rest van de week dezelfde onderbroek.
Codeurs idem zelfde patroon, gelikt maar niet super veilig.

Zelf getuige van. PHP je weet vaak echt niet waar je blijft met dat soort spaghetti code, ook de gehard versies.
Ik krijg het soms met twee vorken niet uit elkaar. De rode draad vasthouden is namelijk tamelijk moeilijk.

Trouwens alle PHP staat op de webserver. En daar zie je vaak nog oude kwetsbare versies van PHP paraderen.

m.vr.gr.

luntrus
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.