image

Duizenden servers bij grootschalige aanval gehackt

zaterdag 23 januari 2016, 08:31 door Redactie, 25 reacties
Laatst bijgewerkt: 23-01-2016, 13:16

Bij een grootschalige aanval zijn wereldwijd meer dan 3500 servers gehackt, zo waarschuwt beveiligingsbedrijf Symantec. De websites die op de servers draaien worden door de aanvallers voorzien van code die bezoekers naar een kwaadaardige website doorstuurt.

Deze website bevat weer verschillende scripts die gegevens van doorgestuurde bezoekers proberen te verzamelen, zoals ip-adres, Adobe Flash Player-versie, taalinstelling en beeldschermresolutie. Vooralsnog wordt er via deze aanval geen malware verspreid. Symantec denkt dan ook dat het om een voorbereidende aanval gaat.

De gehackte websites hebben allen gemeen dat ze een "bekend contentmanagementsysteem" draaien, zo laat Symantec in de blogposting weten. In de omschrijving van de 'attack signatures' wordt gesproken over verschillende WordPress-sites. Het beveiligingsbedrijf heeft daarnaast de code online gezet die aan gehackte websites wordt toegevoegd. Beheerders krijgen dan ook het advies te controleren dat hun website deze code niet bevat. Is dit het geval, dan moet de hele website worden doorgelicht, aangezien alleen het veranderen van het beheerderswachtwoord niet voldoende is.

Reacties (25)
23-01-2016, 09:21 door [Account Verwijderd]
[Verwijderd]
23-01-2016, 09:24 door dnmvisser
De gehackte websites hebben allen gemeen dat ze een bekend contentmanagementsysteem draaien, maar Symantec laat niet weten welk

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.

Wel heeft het beveiligingsbedrijf de code online gezet die aan gehackte websites wordt toegevoegd.
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.
23-01-2016, 09:26 door [Account Verwijderd]
[Verwijderd]
23-01-2016, 09:35 door [Account Verwijderd]
[Verwijderd]
23-01-2016, 09:42 door [Account Verwijderd] - Bijgewerkt: 23-01-2016, 09:42
[Verwijderd]
23-01-2016, 09:45 door Anoniem
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.
23-01-2016, 10:00 door Anoniem
Door Buran: Natuurlijk WP, what else zou je bijna zeggen.
WordPerfect is geen CMS ;-)
Ik zou dus niet WP maar WordPress zeggen.
23-01-2016, 10:15 door karma4
Door Buran: PHP is geen CMS
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.
23-01-2016, 10:35 door Anoniem
WP draait ook onder Windows en MacOS X.
Linux zegt niks, PHP draait crossplatform....
23-01-2016, 10:37 door Power2All - Bijgewerkt: 23-01-2016, 10:37
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.
23-01-2016, 11:01 door Anoniem
Door karma4:
Door Buran: PHP is geen CMS
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.

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.
23-01-2016, 11:01 door karma4
Door Power2All: Dat het meestal Linux betreft, is logisch, gezien PHP van origine in een nix omgeving draaide.
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
23-01-2016, 12:20 door karma4
Door Anoniem: 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.
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,
23-01-2016, 13:16 door Anoniem
Door karma4:
Door Anoniem: 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.
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.

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.
23-01-2016, 14:44 door [Account Verwijderd]
[Verwijderd]
23-01-2016, 16:35 door Anoniem
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
23-01-2016, 21:25 door karma4
Door Anoniem: 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.
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.

vrijwillig website security analyst en website error-hunter
Ben het eens met je commentaar.
24-01-2016, 03:27 door Anoniem
Door Anoniem:
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.

Klopt.

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.

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.
24-01-2016, 19:09 door Anoniem
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.

Warning User Enumeration is possible
The first two user ID's were tested to determine if user enumeration is possible.

ID User Login
1 watafes watafes
2 None
It is recommended to rename the admin user account to reduce the chance of brute force attacks occurring. As this will reduce the chance of automated password attackers gaining access. However it is important to understand that if the author archives are enabled it is usually possible to enumerate all users within a WordPress installation.

Only the first two user ID's were tested with this scan, use the Nmap NSE enumeration scripts (use your own Nmap installation or try option 2 below) to discover additional user ID's.
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
24-01-2016, 20:34 door [Account Verwijderd]
[Verwijderd]
24-01-2016, 22:29 door Anoniem
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
25-01-2016, 08:34 door karma4
Door Buran:
Door karma4:Ik geef weerwoord op de nerds die alles afkappen en hun gelijk moeten halen omdat het OS veilig en heilig is.

Stel je WP nou eens voor als een applicatie die ontworpen is om alleen rondjes mee te kunnnen tekenen, plots is er iemand die een methode vind om er ook driehoekjes mee te kunnen tekenen. Dan is er niks met het OS aan de hand maar wel met de aplicatie, daar kan je immers iets mee doen waar deze niet voor ontworpen is. Dat is precies wat er op dit moment met WordPress aan de hand is.

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.
25-01-2016, 20:06 door [Account Verwijderd]
[Verwijderd]
25-01-2016, 23:27 door Anoniem
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
26-01-2016, 00:04 door Anoniem
Door Anoniem: 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.).

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.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.