Wat handig van Symantec!

Maar als Security.nl even had doorgeklikt op de eerste link http://www.symantec.com/security_response/attacksignatures/detail.jsp?asid=28821 dan staat daar dat het WordPress is.

Ja, maar in de vorm van een brak plaatje:

http://www.symantec.com/connect/sites/default/files/users/user-2598031/Fig4_14.png

Mag je zelf nog even overtikken.

Symantec komt hier wel wat laat mee naar buiten: https://blog.sucuri.net/2015/11/jquery-min-php-malware-affects-thousands-of-websites.html
Het lijkt voornamelijk te gaan om Wordpress sites.

WordPerfect is geen CMS ;-)
Ik zou dus niet WP maar WordPress zeggen.

PHP is de programmeertaal waarvan WP gebruikt maakt. dit betreft gewoonlijk Linux servers.
In de zelfde rant trant van windows-bashing "Linux-systemen zijn lek". Met een goede Linux-security inrichting was het eerder opgevallen.

WP draait ook onder Windows en MacOS X.
Linux zegt niks, PHP draait crossplatform....

PHP draait crossplatform Karma4...
Kan net zo goed in een Windows of OS X omgeving draaien..
Dat het meestal Linux betreft, is logisch, gezien PHP van origine in een nix omgeving draaide.

Dit heeft totaal niks met de security van Linux te maken maar met de, al dan niet bedoelde, mogelijkheden die WP je bied.
De, er vanuit gaande dat het Linux systemen zijn, zijn zelf niet kwetsbaar maar ze hebben content in WP aangebracht die bezoekers doorstuurt naar een kwaadaardige site.

Je gaat voorbij aan de echte security/beveilingsbewustzijn. Je blijft hangen in een label/techniek -verslaving.
Als we het over open standaarden hebben, dan over zaken zoals: http://www.iso27001security.com/html/27002.html Als je die basis niet hebt hoef je niet te verwachten dat het op dat vlak -security- ooit goed komt

Een goed IPDS system met herkenning van ongewenste changes in code/content draait bij een goed ontwerp als een afgescheiden container / "service accounts" op de zelfde doos (os SIEM). De verwerking analyse kan je beter op andere doos er naast doen. Dat soort inrichting op de doos is op OS level en dan heeft dat wel degelijk met het OS te maken.

Netwerkisolatie (rotuers) en firewalls zet je apart er buiten op. Die hebben hun iegen OS en eigen beheer. De niet fundamenteel gepatchde shell-shock is nog basaler op OS niveau. Een pleister op het verschijnsel niet op het ontwerp,

Jij weet helemaal niet of die WP sites geïsoleerd draaien of niet, die kunnen best in een container draaien. Maar goed, je kan tegen jou zeggen wat je wilt maar jij moet je eigen gelijk halen.

Het gaat om een heel groot aantal websites die WordPress draaien (een kwart van alle sites globaal gebruikt deze CMS) met vaak oude(re) software versies, met oude(re) of zelfs verlaten plug-in en thema code. Met wat nog veel gevaarlijker is, en genoeg zijn hier niet van op de hoogte, met "gebruikers enumeratie" en "directory listing" ingeschakeld, zodat de inlog gegevens en de directory content zo te achterhalen valt.
Dan staat er ook vaak nog oude jQuery code op die afgeserveerd moet worden (netjes zippen voor latere referentie). Ook combinaties kunnen extra kwetsbaarheid opleveren. Dus onveiligheid vaak door amateuristisch onbenul of gebrek aan pro-actieve hulp van hosting enzovoort. Met de lage aandacht ook bij scholing voor security zie ik de situatie niet snel wijzigen en sommige partijen komt dat wel heel goed uit, want "in het land der blinden is eenoog de marketing-koning en verdient scheppen geld aan het onbenul van velen".

groetjes,

vrijwillig website security analyst en website error-hunter

Ik zeg ook niet dat ik dat weet, alleen dat ze veel beter zouden moeten doen. Kom met de argumenten waarom het niet zou kunnen. Ik geef weerwoord op de nerds die alles afkappen en hun gelijk moeten halen omdat het OS veilig en heilig is.

Ben het eens met je commentaar.

Klopt.


Een directory listing (dat is web server niveau) staat nog niet toe dat je files kunt lezen als het php bestanden zijn. Die worden server side geinterpreteerd en uitgevoerd. Met een gebruikersnaam kun je nog niet veel zonder wachtwoord. Gebruik maken van een lek is veel makkelijker voor een aanvaller.

WordPress is op gehackte sites vaak niet up to date en plugins zijn inderdaad ook niet up to date en vaak ook EOL. Waar de site wel up to date is, gaat het vaak om gestolen wachtwoorden vanaf besmette werkstations.

Hier de resultaten van een willekeurige scan. Nee, ik geef de domein naam niet, maar zie zelf waarom "user enumeration" beter op "disabled" zou moet staan. Brute force attacks e.d. in combinatie met andere aanvallen (PHP, shell scripts enz. enz.).

We moeten dergelijke waarschuwingen ook weer niet onderschatten. Het zijn excessieve info proliferatie configuratie-fouten.

Quote txt van hackertarget.com

En tenslotte wat over de tooltjes hier? https://mydeface.com/tools (Admin Panel Finder en dergelijk fraais) - script kiddie spul, dat weet ik, maar er valt narigheid te veroorzaken via "trial and error".

vrijwillig website security analyst en website error-hunter

Ha Buran,

Dat is het algemeen basisprincipe van elke hack, software iets laten doen waar het in principe niet voor ontworpen is en dit uitbuiten om het iets te laten uitvoeren wat eigenlijk niet zou mogen.
Daar hebben we het hier niet in de eerste plaats niet over. Al is dit wel het gevolg van e.e.a..
Hier in deze draad hebben we het over mensen die software gaan gebruiken, zoals die "uit de doos" komt, Dit, zonder zich te bekommeren of weet te hebben van wat men wel of niet moet installeren, instellen, verwijderen, en ook welke code combinaties indien toegevoegd de zaak gelijk inherent nog veel onveiliger maken.
De software vendor levert het hele pakket aan om later niet het verwijt te krijgen dat er iets niet bij zit en "zoek het dan maar uit" is het credo of verdiep u in het "manuaal en de bug-reports". De zogenaamde "nerds" hier en misschien zijn het echt alleen maar gewone mensen met wat meer relevante kennis wat dit betreft, willen uitleggen dat heel veel Word Press en ander CMS niet met veiligheid voor ogen wordt geïmplementeerd en zo de bezoekers van websites extra risico laten lopen. Degenen verantwoordelijk voor het website onderhoud loggen niet, updaten niet, serveren oudere code niet op tijd af. Ze gebruiken kwetsbare en niet kwetsbare jQuery libraries door elkaar als de spreekwoordelijke "Engelse drop" en het veiligheidsdenken wordt ze ook nog eens niet bijgebracht. Technische IT weet meestal wel van wanten!
Wat kunnen we dan eigenlijk verwachten? Iets anders dan "errors, fails and warnings"? Het gaat meestal toch nog vrij lang goed in de sfeer van dat was "meer geluk dan wijsheid".

vrijwillig website security analyst en website error-hunter

Op zich heb je gelijk. De titel van het artikel is "server " gehackt. Voor velen is een server synoniem aan de doos/hardware. Dat past niet in de context dan is de volgende de logische machine het os.

Als we het over applicatie lekken hebben dan is de definitie van wat er onder verstaan wordt belangrijk. Is de apache Webserver een applicatie of is Maria dB en applicatie php of WordPress. Ik zie deze hele reeks als Tools om het eigenlijke doel te realiseren. Het eigenlijke doel de content website blog waar het om te doen is. (De applicatie)

Begin nu eens met het security beleid vanaf de top de applicatie.
Hier moet je wat over zeggen in het kader van risico impact.
Dan ga je naar beneden met wat je nuttig voldoende vind in kosten baten om te doen. Dit is de lijn van open standaarden als iso27k.

Wat je veel te veel ziet gebeuren is Nerds die vastzitten in een antipathy dan wel verslaving.

WordPress lek Het is niet het gele stickertje op de machine met de user/password van de admin. Het zit in de Tools van de Stack met het os.
Voor de gebriket is dat 1 geheel als service.
Prima als je een scheiding in lagen wil aanbrengen maar dan moet je dat consequent doen. Niet selectief zoals je het zelf het beste uitkomt.

Wie dit draadje hier heeft gelezen en goed tot zich heeft laten doordringen heeft hier weer veel van opgestoken.
Alleen al door met elkaar discussie te voeren komt er verheldering.
Dank voor de interessante bijdragen, die mijn persoontje ook weer even lekker op scherp hebben gezet.
Nu nog in de praktijk brengen door ieder die hier is geweest. Natuurlijk moeten alle omgevingsfactoren ook meegewogen worden, zoals wat heeft waar en op welke wijze toegang en hoe gevaarlijk kan dit in dat geval zijn. Maar het gaat om het principe om vanaf het begin rekening te houden met veilig toepassen en dat dan ook in de praktijk te brengen.
En wat betreft de eeuwige linux & Windows vraagstukken, ASP.NET Websites vertonen vaak ook vele fails, errors en warnings. Doe maar eens een rondje langs om even een voorbeeldje te noemen wat bekende Chinese ASP.NET websites en je houdt je hart vast en de moed zakt je letterlijk in de digitale schoenen. Scanner is hier te vinden voor u allen: https://asafaweb.com/
Men ziet het er is nog veel te doen - de beveiligingsgerichte lieden en proactieve hosters niet te na gesproken,
O, ja en dat PHP advies van Muria, van harte mee eens en dat wil ik graag mee onderstrepen. Hij heeft gelijk.

vrijwillig website security analyst en website error-hunter

Je moet als verantwoordelijk beheerder altijd je systeem hardenen, maar in de praktijk is dat niet de manier waarop op grote schaal gehackt wordt. Dat is het verschil tussen theorie en werkelijkheid.

Random brute force attacks komen relatief weinig voor, vaak is het alleen een beperkt aantal standaard wachtwoorden. Het wordt anders als een doel specifiek wordt uitgezocht waar een complete dictionary attack wordt gedaan. Dat dien je sowieso onmogelijk te maken, maar hier van belang is dat het voor een doorsnee site niet aan de orde is. Hacken gebeurt vaak om die servers voor spam te gebruiken. De aanvallers kan het weinig schelen welke site het precies is.

@Muria

Geen Windows voor servers gebruiken is een onzin opmerking. Windows is niet onveiliger dan Linux (punt). Er worden vele malen meer Linux servers gehackt dan Windows servers, ook als je dat corrigeerd naar marktaandeel.

PHP kun je best gebruiken, als je er maar geen lekke applicaties gebruikt. Ik zou geen php willen gebruiken voor een server die behoorlijk veilig moet zijn (m.a.w. als er wat valt te beschermen), maar dat is iets anders dan gebruik van php ruecksichtlos afwijzen. Dat gaat te ver.