Duizenden WordPress-sites gehackt via recent gepatcht lek
Een ernstig beveiligingslek in WordPress waarvoor onlangs een update verscheen wordt nu gebruikt om websites te hacken. Dat laat beveiligingsbedrijf Sucuri weten dat de kwetsbaarheid ontdekte en aan WordPress rapporteerde. De ontwikkelaar besloot het lek een week lang opzettelijk te verzwijgen totdat voldoende websites de update hadden geïnstalleerd.
Toch zijn er nog altijd websites die op een kwetsbare WordPress-versie draaien. Via het beveiligingslek kunnen aanvallers op afstand en zonder inloggegevens de inhoud van WordPress-sites wijzigen. Binnen 48 uur nadat de kwetsbaarheid openbaar was gemaakt werden de eerste aanvallen waargenomen die misbruik van het beveiligingslek maakten. Inmiddels zijn volgens Sucuri meer dan 66.000 WordPress-pagina's door de aanvallers aangepast.
"WordPress heeft een automatische updatefunctie die standaard staat ingeschakeld, naast een handmatig updateproces dat via één muisklik is uit te voeren. Toch weet niet iedereen van dit beveiligingslek of kan zijn of haar site updaten. Dit zorgt ervoor dat een groot aantal websites wordt gehackt en gedefacet", aldus Daniel Sid van Sucuri. Ongeveer een kwart van alle websites op internet draait op WordPress.
een kwart van alle websites draait wordpress. dat google je zelf maar.
OMDAT een kwart Wordpress draait, zit ook een kwart van alle hackers dat te hacken. (ongeveer een kwart)
draai je een kleiner CMS... minder hackers, maar ook weer minder ontwikkelaars.
dus maak gewoon backups van je site, en check 'm af en toe, of abonneer je op een site-checker.
http://lmgtfy.com/?q=update+wordpress+automatically
Maar als je het uitzet is het wel noodzakelijk dat je bijvoorbeeld instelt dat je een mailtje krijgt als een update beschikbaar is. Zodat je geen ongepatchte website draait.
Goh, daar hebben ze bij Wordpress vast niet aan gedacht...
https://digwp.com/2011/04/wordpress-auto-updates/
Check je site hier: https://aw-snap.info/file-viewer/ (Redleg is je vriend).
Zet user enumeration op disabled en directory listing ook. Veel gebruikers van WordPress CMS weten dit niet.
Check via http://retire.insecurity.today/ of er oude bibliotheken gebruikt worden, die moeten worden afgeserveerd.
Check hier: http://www.domxssscanner.com/ voor sources and sinks en kwetsbaarheden.
Kijk naar iFrame kwetsbaarheden, spammy links en cloaking hier: http://isithacked.com/
Kijk ook naar andere aspecten van je website beveiliging: https://sritest.io/
Scan hier eens voor een status: https://observatory.mozilla.org/
En kijk hoe de configuratie van de naamservers is (silent liefst): http://www.dnsinspect.com/
Ga je het een beetje begrijpen nu? Maak die WordPress CMS aangestuurde sites wat veiliger, a.u.b.!
Besef dat de code op het redelijk onveilige PHP is gebaseerd, vandaar voortdurend falen....
luntrus
Besef dat de code op het redelijk onveilige PHP is gebaseerd, vandaar voortdurend falen....
luntrus
Check je site hier: https://aw-snap.info/file-viewer/ (Redleg is je vriend).
Zet user enumeration op disabled en directory listing ook. Veel gebruikers van WordPress CMS weten dit niet.
Check via http://retire.insecurity.today/ of er oude bibliotheken gebruikt worden, die moeten worden afgeserveerd.
Check hier: http://www.domxssscanner.com/ voor sources and sinks en kwetsbaarheden.
Kijk naar iFrame kwetsbaarheden, spammy links en cloaking hier: http://isithacked.com/
Kijk ook naar andere aspecten van je website beveiliging: https://sritest.io/
Scan hier eens voor een status: https://observatory.mozilla.org/
En kijk hoe de configuratie van de naamservers is (silent liefst): http://www.dnsinspect.com/
Ga je het een beetje begrijpen nu? Maak die WordPress CMS aangestuurde sites wat veiliger, a.u.b.!
Besef dat de code op het redelijk onveilige PHP is gebaseerd, vandaar voortdurend falen....
luntrus
Je laatste zin ontkracht je betoog.
De kernel software van het CMS wordt duidelijk beter aan de tand gevoeld
en wordt ook regelmatig van patches voorzien en van updates.
De problemen zitten voornamelijk in de plug-in code.
Het is bijvoorbeeld duidelijk dat niet verder ontwikkelde code, ergo verlaten code, zorgt voor de risico's.
Ik had natuurlijk moeten zeggen dat Joomla en Drupal ook op PHP en MySQL zijn gebaseerd.
Kijk bijvoorbeeld wat je hiermee kan aanrichten: https://nl.wordpress.org/plugins/insert-php/ en
user input validatie kan de kwetsbaarheden in belangrijke mate mitigeren.
Met je eens dat WordPress sites eigenlijk slechts 'platte tekst" sites moeten zijn.
Dan hoeft er niet zoveel aan de hand te zijn.
luntrus
Ik gebruik nu nog Wordpress maar als dit soort nieuws lees dan ben ik 't wel eens meer dan zat. Daarom overweeg ik wel eens een static site generator te gebruiken (zoals Jekyll: http://jekyllrb.com). Dan kan je nog steeds blog-achtige dingen doen, met overzichtpagina laatste berichten, etc. Maar volledig gegenereerd op je eigen computer, zodat er op de server alleen statische pagina's staan, geen (PHP) code.
Met een mechanisme voor incrementele upload na wijzigingen moet dat te doen zijn? (Iemand ervaring mee?)
Heb een Drupal 6 site (niet meer ondersteund dus per definitie onveilig) verhuisd naar een subdomein en achter Apache basic authentication gezet. Een static site generator genereert na wijzigingen m.b.v. HTTtrack een platte html site op het publieke domein. Heb Httrack behoorlijk moeten tunen i.c.m. met wat postprocessing om de site qua url-structuur identiek aan het origineel te krijgen ivm ranking in google, maar het draait inmiddels wel al maanden als een zonnetje.. En veilig...
Maar een statische website van ~50 pagina's (2MB aan tekst) te beheren met een CMS van meer dan 10MB lijkt mij onzin.
Gelukkig zijn we vrij in onze manier van werken, we publiceren alleen een eind-resultaat. :-)
dat ik het als gatenkaas begin te labelen. 't Zelfde als met fLash, waar
vrijwel wekelijks een nieuwe versie voor moet worden geinstalleerd.
Buiten dit feit vind ik het irritant dat deze software standaard gebruik
maakt van google api's / google fonts.
Bij sites waarbij dit niet is uitgezet, mekkert noscript over 3rd party
scripts van google. In mn hosts heb ik fonts.googleapis.com (en vele
andere)naar localhost verwezen, ik wil namelijk niet dat google een
notitie maakt dat ik weer 's (bv) de site http://thehackernews.com/
heb bezocht. Het laden werd hierdoor wel vertraagd omdat er maar geen
gewenste reactie terugkwam van fonts.googleapis.com (of ajax...)
aangezien deze nu dus wordt doorverwezen naar localhost/devnull.
Gelukkig vond ik in de instellingen van noscript terug dat je remote
fonts kan uitschakelen (kan t ff nie zosnel trug vinden) zodat het
connecten naar google geheel wordt overgeslagen.
Te paranoia/allu enzo, sla ik de plank totaal mis, of tochnie?
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?