Site beveiligen

Hoe je site beveiligen tegen hackers?

Net zoals je pc of Mac zijn web-sites doelwitten van programmeurs met slechte bedoelingen. Ze hebben een verschillende kennis en bedoelingen, de ene al wat onschuldiger dan de andere, maar ze zijn allen best te vermijden.
1. Waarom?

Enkele redenen waarom zij jouw site willen besmetten:

invoegen van advertenties (viagra), linken naar andere sites
invoegen van bestanden die de analytics van andere websites beïnvloeden (en alzo de SEO-ranking beïnvloeden) (bron: http://www.bluebridgedev.com/hacked-joomla-changes )
jouw server gebruiken voor spam-mails waardoor jouw domein geblacklist kan worden
PCs van surfers infecteren
stelen van gevoelige data zoals email-adressen, credit card nummers
stelen van jouw traffiek en je surfers naar andere web-site doorverwijzen
politieke motieven
zo maar, de kick
met als nieuwste mode: losgeld vragen om je bestanden terug vrij te geven (bron: http://www.bluebridgedev.com/hacked-joomla-changes )

2. Wat, hoe … enkele termen

Enkele termen nader belicht:

Spammen is bekend als het versturen van een mail naar een grote massa mensen (email-adressen) waar deze niet om gevraagd hebben.
Gebeurt deze verzending vanaf jouw server, dan riskeer je niet alleen een tragere page-load (en slechtere SEO-ranking) maar ook dat jouw mailings verstuurd vanuit jouw server als spam aanzien zullen worden. (Als er een groot aantal mails in een zeer korte tijd verstuurd worden vanuit 1 machine, dan beantwoord dit aan het gedrag van een spammer).

Blacklist Hier bedoelen we de zwarte lijst van web-sites die beschouwd worden als onveilig of kwaadaardig. Hoewel een site van oorsprong goede bedoelingen heeft, kan die op de zwarte lijst komen doordat ze gehackt is (en daardoor onveilig voor surfers wordt).
Als Google tijdens het crawlen van je site ontdekt dat je site gehackt is, dan is er een grote kans dat hij die site op de blacklist zet. Deze lijst deelt Google met Twitter, desktop antivirus programma’s, … . Maar er zijn nog andere firma’s die een (eigen) blacklist beheren.
Die blacklists worden geconsulteerd door (veiligheidsprogramma’s of add-ons van) browsers die aan de eindgebruiker een verwittigen tonen als de bezochte site geblacklist staat.

Drive-by-downloads Hierbij is het doelwit niet zozeer jouw site als wel de computer van jouw surfers om daarop kwaadaardige programma’s te downloaden. Als de computer van de surfer niet genoeg beveiligd is zal deze bij een bezoek aan jouw site geïnfecteerd worden met een virus, malware of zoals nu meer gebeurt ransomeware. Ransomware blokkeert de toegang tot de bestanden op de computer, mits betaling van losgeld zal de blokkade opgegeven worden.

Data Exfiltratie Hier wil de hacker gegevens stelen die hij zelf kan gebruieken / uitbuiten. Dit kan gaan van emails (voor spamming), persoons-identicatie-gegevens tot kredietkaart-gegevens.

Defacing verandert je home-pagina zodat je site-bezoekers een andere inhoud, boodschap te zien krijgen. Dit wordt ook wel hacktavism genoemd.

Phishing simuleert een webpagina van een firma (bank!) om van de onschuldige surfer persoonlijke informatie op te vragen. Net zoals bij data exfiltratie is het doel de verkregen gegevens te misbruiken.
Jouw site kan gehackt zijn om die valse webpagina te herbergen. Jouw site lijkt dus te werken zoals het hoort, maar uw server is wel gehackt. Dit misbruik zal je misschien niet zo snel zien maar mischien wel voelen door de traagheid van page-load als de valse web-pagina veel resource vraagt (en/of veel trafiek aantrekt).

Terwijl bovenstaande termen de bedoeling van de hackers illustreren, komen hieronder de manieren van hacken aan de beurt.

Vulnerability Exploitation behelst alle manieren van hacken waarbij een zwakheid in de programma-code of functionaliteit ervan misbruikt wordt. Hieronder zijn enkele van dergelijke misbruiken nader beschreven.

Code injection verandert de executie van een programma doordat de hacker eigen code injecteert in de programma-code. Dit is niet mogelijk met programmeer-talen die gecompileerd moeten worden maar in een web-omgeving worden er genoeg script-talen gebruikt, die dat wel toelaten, zoals PHP en SQL-querying. Hieronder bespreken we 2 types.

Met SQL-injection probeert de hacker een SQL-commando uit te voeren, niet in een database-interface zoals phpMyAdmin maar door dit commando mee te geven in een url-query of een web-form-veld. Als de webpagina die input van het veld of url-query naar zijn database stuurt dan wordt de geïnjecteerde SQL-commando van de hacker mee naar de database gestuurd en mee uitgevoerd (waarop de hacker hoopt). Het geïnjecteerde SQL-commando is vaak een creatie van een administrator account waarmee de hacker dan volledige toegang heeft tot je content management systeem. Een ander doel dat bereikt kan worden door de database te infecteren:

in artikels Javascript invoegen zodat bij een bezoek aan die pagina een andere pagina (door de hacker gespecifieerd) getoond wordt,
downloaden van je database-gegevens,
je gegevens wijzigen of zelfs vernietigen.

Command-injection werkt op een gelijkaardige manier, alleen is het niet de bedoeling dat de database het meegegeven commando opneemt maar de server . Dit is een vorm van Remote Code Execution, de hacker laat zijn kwaadaardige commando’s uitvoeren zonder dat hij toegang heeft tot het systeem.

Als de code niet op de server maar op de client wordt uitgevoerd dan spreekt men van Cross Site Scripting of XSS. Als de surfer met zijn browser jouw site bezoekt zal die kwaadaardige code (in Javascript) uitgevoerd worden. Deze code kan bijvoorbeeld verstopt zitten onder een onschuldig lijkende URL-link. Op het moment dat de surfer daarop klikt, zal de kwaadaardige code uitgevoerd worden op zijn PC.

File Inclusion Sommige programmeertalen laten het toe dat tijdens een executie van een programma de commando’s uit een ander bestand, wiens naam tijdens de uitvoering bepaald wordt, ook mee uitgevoerd worden , ook gekend als “dynamic file include” mechanisme. De hacker zal van dit principe gebrik maken om zijn bestand mee te laten uitvoeren. Als hij dit bestand al op jouw server staat dan noemt men dit een Local File Inclusion, als het bestand op een andere server staat, noemt men dergelijk Remote File Inclusion.

Backdoor is een stuk code dat de hacker geplaatst heeft op je site. Deze zal zo goed mogelijk verstopt zitten om het detecteren (en saneren) te verhinderen. Verstopt in een bestand met een onschuldige naam (zodat onwetende denken dat het bestand essentieel is, een voorbeeld main.php zoals gemeld in http://www.joomlacommunity.eu/nieuws/gebruikersgroepen/983-website-hack-via-xmlrpc-backdoor-script.html ), gecrypteerd door speciale code (eval base64_decode) , op een plaats waar men niet zo snel aan denkst (zoals tijdelijke bestanden of plugins) , … Enkele voorbeelden vind je op een blog-artikel van Sucuri (Engelstalig).

SEO Spam wordt grotendeels gebruikt door spammers om de positie van hun klanten in zoekmachines, zoals Google, te vergroten. Hierbij worden zelfs iFrames, sitemaps, … gegenereerd om de zoekmotoren Google, Bing, … ranking te verhogen ten voordele van de aanvallers’ site.

Privilege Escalation Door een fout concept, functionaliteit of bug in de site-software heeft een gebruiker meer rechten dan oorspronkelijk bedoeld, zodat hij meer kan doen en bereiken dan geoorloofd. Een hacker kan hiervan misbruik maken.

Image hotlinking is in feite geen aanval op jouw site maar eerder een misbruik van jouw materiaal. Je afbeeldingen worden namelijk opgeroepen in/door een ander site. Als die veel bezoekers heeft, dan kan jouw server leiden onder diens traffiek ten nadele van je eigen bezoekers (en je S.E.O.).

Distributed Denial of Service Bij een DDoS is het de bedoeling om de beschikbaarheid van je site te verstoren door je site te overbelasten met een overdaad aan fake bezoeken, je server te belasten met een overweldigende hoeveelheid verzoeken t.t.z. taken die via jouw site aangevraagd zijn. Hierdoor komt de server er nog nauwelijks toe jouw site weer te geven en zullen jouw surfers hun bezoek opgeven, zelfs het open van de backoffice zal geduld vragen, als het nog wel lukt.

Brute Force Attack duidt op het herhaaldelijk proberen in te loggen op je site als administrator. De hacker zal via een programma alle mogelijke combinaties van gebuikersnaam en paswoord uitproberen. Hierbij kan het programma de meest voorkomende paswoorden gebruiken of zelfs een heel woordenboek. Hoe langer je paswoord, hoe langer het zal duren dat een dergelijk programma de juiste combinatie zal gevonden hebben.

In onderstaande grafiek van Sucuri kan je de trends zien van de laatste jaren:

Trends van infecties 2014 2016 Q1

Cijfers die heel 2016 beslagen werden niet gepubliceerd bij Sucuri maar hieronder krijg je een idee van de evolutie in 2016 en 2017:

Trends van infecties 2016

Types malware infecties voor het jaar 2017 zoals gedetecteerd door Sucuri:

type malware besmettingen

Mag het een magere troost heten dat wat betreft infecties Joomla! beter scoort dan WordPress,
ook rekening houdend met het aantal websites die op de respectievelijke CMS draaien:

gehackte websites per CMS
De 3 werkterreinen voor jou

Om je site te beveiligen en voorbereid te zijn op een hacker, zijn er 3 gebieden die je inzet vragen:

het versterken, veilig stellen van de eigen digitale elementen (software, configuraties en infrastructuur)
inzetten van tools die de aanvallen afweren en/of ontdekken
het nemen van voorzorgen die een sanering van de site vergemakelijken (met o.m. Backups)

Deze 3 werkterreinen komen in de volgende hoofdstukken uitgebreid aan bod.

B. Hacken voorkomen

Om je site veilig te houden zodat ze goed weerstand kan bieden tegen aanvallen van buitenaf, kom je met volgende aanbevelingen al ver:

Update jouw Joomla! CMS alsook alle extensies en templates
Wees zeker dat de server-software up to date is
Wees zeker dat de (server en site) configuratie optimaal is
Zorg dat de bestands- & folder-permissies juist staan
Laat jouw site regelmatig scannen (virus, malware, WAF, …)
Gebruik sterke paswoorden en verander de standaard admin gebruikersnaam
Neem regelmatig backups en verzeker je ervan dat je deze kan restoren
Wees op de hoogte door veiligheidsberichten te lezen
Ondanks alles blijf waakzaam

In de volgende hoofdstukken gaan we dieper in op elke van de punten.
1. Joomla!-installatie

Sommige Joomla! versies zijn niet genoeg beveiligd. Zo volgden versies 3.4.5 , 3.4.6 en 3.4.7 elkaar snel op vanwege gevaar op SQL-injection (opgelost in versie 3.4.7) en remote code executie (te wijten aan een zwakheid in PHP). Het is dan zaak om een upgrade niet uit te stellen!
Andere voorbeelden:

In de Joomla versies 2.5.13 en kleiner alsook in 3.1.4 en kleiner, was de kontrole op verdachte bestanden te zwak. De sites waar je als geregistreerd gebruiker toegang tot de media-beheerder had, waren super kwetsbaar. Je kon een uitvoerbaar bestand uploaden als je achter de naam maar een punt zette. Eenmaal opgeladen kon je dat bestand dan uitvoeren ( https://blog.sucuri.net/2013/08/joomla-media-manager-attacks-in-the-wild.html https://www.siteground.com/blog/joomla-vulnerability/ ).
In de Joomla! bijeenkomst van 20-03-2016 toonde Karel hoe hij dankzij een bug eender welk bestand kon opladen. Op die werkwijze kan een indringer toegang tot Joomla! en bijhorende gebruikersomgeving bekomen.

Omdat bij de release van een Joomla! versie er kort nadien weer een andere versie opduikt die een veiligheidslek moet dichten (versies 3.4.5 – 3.4.7 en versie 3.7.0 – .3.7.2) is het aangeraden om bij een nieuwe (major) versie van Joomla! niet onmiddelijk te upgraden… tenzij er duidelijk een veiligheidsreden is! Zo vermijd je meerdere updates te moeten doen in zeer korte tijd.
2. Extensions

Behoud de discipline om enkel extensies te installeren die noodzakelijk zijn voor jouw site.
Bij het kiezen van extensies probeer ook een idee te krijgen van de reputatie & het niveau van de developer en zijn producten (wanneer is de laatste update uitgevoerd, is de developer eerder een hobbyist dan een professional, …).

Neem enkel extensies via de JED, i.e. extensions.joomla.org , zo ben je er steeds zeker van dat er geen infecties in de download-bestanden zouden zitten.
Hoe komt het dat ondanks alle updates je site toch nog gehackt kan worden? Vanaf het moment dat een probleem ontdekt is tot de release van de verbeterde versie, verloopt er enige tijd: de developer heeft namelijk zijn tijd nodig om in zijn programma het veiligheidslek te vinden en te dichten.

Het updaten van extensies en modules, plugins, … is een vaak gehoord beveiligingsadvies. Maar ondergetekende vindt dit niet zo evident: er is vaak geen mogelijkheid om de relevantie van updates na te gaan. Bovendien blijken niet alle Joomla! extensies gebruik te maken van de update-melder. Dit kon Manu ondervinden met BreezingForms wiens bestanden gehackt werden eind 2015. Hij heeft daarom nu een document gemaakt waarin alle extensies vermeld zijn die geen automatische melding tonen als er een nieuwe versie beschikbaar is. Die lijst bevat de URL naar de Joomal Extension Directory (JED) – om met een click de meest recente versie in de JED te kunnen verifiëren – en daarnaast staat in de lijst de versie die geïnstalleerd is in de site. Dan is het enkel een discipline om elke N maanden die lijst af te lopen en de versies vermeld in JED te vergelijken met die op de site.
Dit opvolgingswerk van versies kan ook uitgevoerd worden door extensies en services: dit doet bijvoorbeelde de extensie https://www.akeebabackup.com/products/admin-tools.html en een extra service bij Watchful.li https://watchful.li/tools/ (daar kan je alle gecheckte extensies opgelijst zien).

Desinstalleer extensies die je niet meer gebruikt, zeker als je ze niet meer update. Daardoor zijn er al minder bestanden op de server en dus minder kans op infectie. Voor extensies die uit de JED verwijderd zijn, is ook aangeraden ze te verwijderen, ze te vervangen door andere.
3. Themes

Een template bevat niet louter grafische elementen maar ook code en is daarmee ook kwetsbaar. Nicholas Dionysopoulos verwoordt het zo: “I’ve seen many sites getting hacked because of a dated template with a SQL injection or XSS vulnerability.”
Een voorbeeld was SQL injection in een van de modules van RocketTheme (tweede helft 2013).
4. Paswoorden

Ter illustratie een getuigenis van provider Siteground:
Op 9 april 2013 werden bij hun meerdere Joomla-sites aangevallen. Bots gebruikten meer dan 1000 verschillende IP’s per server om door te dringen. Siteground blockeerde meer dan 92.000 Ips en in 12 uur blokkeerden ze 15 millioen login requests.
In een daarop ovlgende onderzoek rond admin-paswoorden ontdekte Siteground dat 40% zeer zwakke paswoorden gebruikt!

Vandaar volgende raadgevingen:

Gebruik als paswoord iets kryptisch of waarom niet een volledige zin zoals “niets beters dan werken bij ons”, “leef met vlag en wimpel, maar hou het simpel”. Als de hacker een random-generator gebruikt om het paswoord te ontdekken, dan zal voor elk character méér in het paswoord het aantal combinatiemogelijkheden met 40 (of meer) toenemen. Dit feit lijkt te weinig vespreid terwijl het een goede combinatie is van veiligheid (lang paswoord dus langere detectietijd nodig) en gebruiksvriendelijkheid (gemakkelijk te onthouden).

Wijzig de gebruikersnaam van de administrator (bijv. “rege1neef_j@n” , maar niet zoiets als “admin2”).

Een extra beveiliging kan er ook in bestaan om inloggen met mijnsite/administrator te verhinderen. Hiervoor biedt de plug-in-extensie AdminExile de meeste opties.

Als Joomla het mocht toelaten dan zou een captcha in de login goed zijn daar het een login door (hacking)programma’s verhindert.
In je cPanel kan je ook een extra paswoord voor je Joomla-administrator definiëren (cPanel > Password directories > Administrator ) (slde 18 http://www.slideshare.net/siteground/joomla-security-webinar ).
Een meer omslachtige maar bestaande methode voor Joomla-Admin login die super veilig is: de 2-key-authenticated log-in.

Wil je checken hoe veilig je paswoord bevonden wordt: https://howsecureismypassword.net/

Wil je een paswoord beheerder (op eender welk toestel)? Bekijk dan https://lastpass.com/

Je zou er ook aan kunnen denken om enkel bepaalde IP-adressen toegang te verlenen aan de administrator-console.

Overweeg een “secret url parameter”. Met de klassieke URL voor de Joomla! back-end kan men dan niet meer inloggen tenzij er een extra parameter wordt meegegeven, me name de “secret parameter”. Als bijvoorbeeld je geheime secret parameter gelijk is aan “w81seven”, dan kan men enkel inloggen de back-end met de unieke url: http://www.jewebsitenaam.be/administrator/index.php?w81seven . Dus nog meer gis-werk voor een hacker. Afhankelijk van de server (Linux, Windows, …) zouden er enige beperkingen, qua lengte van het woord enz… kunnen gelden. Beveiligingsaudit nodig? Vraag info bij Security-Taskfore. Veel bedrijven worden geconfronteerd met diefstal of fraude omdat hackers hun website, IT-infrastructuur of cloudservice kunnen hacken.