Tijdens de wekelijkse analyse kan de externe scan kwetsbaarheden aan het licht brengen. Deze worden weergegeven op het tabblad Infrastructuur van Stoïk Protect.
Om toegang te krijgen tot informatie over een specifieke kwetsbaarheid – beschrijving, gerelateerde bronnen, hoe deze te verhelpen – Klik op de kwetsbaarheid in de onderstaande lijst:
Password authentication enabled
WordPress Core < 4.7.1 - Username Enumeration (CVE-2017-5487)
Subdomain takeover
Eenvoudig uitgelegd
Door succesvol misbruik te maken van dit type kwetsbaarheid kan een aanvaller het subdomein van het slachtoffer claimen en overnemen.
Het overnemen van een subdomein is mogelijk in verschillende applicaties, zoals Github, Shopify, Netlify, Wix en AWS S3 bucket.
Technisch bekeken
Deze aanval is gebaseerd op de volgende elementen:
- De registratie van het subdomein van de externe DNS-server van het slachtoffer is zo geconfigureerd dat deze verwijst naar een externe bron, dienst of eindpunt die niet bestaat of niet actief is. Door de opkomst van XaaS-producten (Anything as a Service) en openbare cloudservices zijn er tal van potentiële doelwitten die in de gaten moeten worden gehouden.
- De serviceprovider die de externe bron/service/eindpunt host, voert geen degelijke verificatie uit van het eigendom van het subdomein.
Als het subdomein met succes wordt overgenomen, zijn er tal van aanvallen mogelijk (verspreiding van kwaadaardige inhoud, phishing, diefstal van sessiecookies van gebruikers, inloggegevens, enz.). Deze kwetsbaarheid kan worden misbruikt voor een groot aantal DNS-resource records, waaronder A, CNAME, MX, NS, TXT, enz.
Wat de ernst van de aanval betreft, heeft de overname van een NS-subdomein (hoewel minder waarschijnlijk) de grootste impact, omdat een succesvolle aanval kan leiden tot volledige controle over de hele DNS-zone en het domein van het slachtoffer.
In dit voorbeeld bekijken we de overname van een Shopify-domein, maar dit scenario kan ook van toepassing zijn op andere applicaties.
Wanneer we op het kwetsbare subdomein terechtkomen, krijgen we het volgende te zien:
Vervolgens kunnen we het beschikbare domein eenvoudig verbinden in het beheerderspaneel van Shopify:
Dit kan door een aanvaller worden gebruikt om kwaadaardige bestanden te verspreiden of phishingaanvallen te creëren die geloofwaardig lijken met geldige domeinen.
Oplossingen
- Op korte termijn, als het kwetsbare subdomein niet voor zakelijke doeleinden wordt gebruikt, raden we aan om de DNS-registratie te verwijderen.
- Op middellange termijn zou Infrastructure as Code (IaC) zeker moeten voorkomen dat het subdomein wordt verwijderd, maar de bijbehorende DNS-registratie blijft bestaan.
Een dergelijk scenario zou niet onopgemerkt blijven bij een codereview. Actieve monitoring van applicatie-assets in geval van onverwachte contentlevering, domeinverval of eigendomsoverdracht maakt vroegtijdige detectie en correctie mogelijk.
Terug naar boven
CVE-2021-22205
Eenvoudig uitgelegd
Deze kwetsbaarheid is gepubliceerd door Gitlab. Het betreft een beveiligingsprobleem bij het beheer van afbeeldingen via hun interne bibliotheek Exiftool. Het verzenden van kwaadaardige afbeeldingen leidt tot Remote Code Execution (RCE) op de server waarop de kwetsbare GitLab-instantie draait.
Technisch bekeken
Deze kwetsbaarheid is te wijten aan de overdracht van afbeeldingen die door de gebruiker zijn aangeleverd aan de geïntegreerde versie van ExifTool in de dienst. Een aanvaller zou op afstand opdrachten kunnen uitvoeren als Gitlab-gebruiker, vanwege het slechte beheer van DjVu-bestanden door ExifTool.
Als deze kwetsbaarheid wordt misbruikt, kan dit gevolgen hebben voor de onderliggende server waarop de GitLab-applicatie wordt gehost. Aangezien de kwetsbaarheid de aanvaller in staat stelt de controle over de server over te nemen, kan dit leiden tot laterale verspreiding naar aangesloten apparaten, afhankelijk van de beveiligingsconfiguratie.
Deze kwetsbaarheid is openbaar beschikbaar op internet. Een snelle zoekopdracht met trefwoord “CVE-2021-22205” leidt naar deze openbare Github-repository. Vervolgens volstaat het om de proof of concept te gebruiken en commando's uit te voeren, zoals in het onderstaande voorbeeld dat de inhoud van de servermap weergeeft:
Gevolgen
- Vanuit cyberoogpunt kan dit een directe impact hebben op de vertrouwelijkheid, integriteit, beschikbaarheid en traceerbaarheid van de assets die op de server zijn opgeslagen. Aangezien voor het misbruik van de kwetsbaarheid geen authenticatie op het platform of de server nodig is, is de impact ervan kritiek en krijgt de aanvaller toegang tot de shell.
- Vanuit organisatorisch oogpunt leidt misbruik van de kwetsbaarheid tot directe financiële verliezen doordat de veiligheid van de bedrijfsassets in het gedrang komt en achteraf een onderzoek door beveiligingsexperts nodig is om te controleren of het onderliggende netwerk niet is gecompromitteerd.
Oplossing
- Op korte termijn moet onmiddellijk een toegangsbeperking worden geïmplementeerd om zo de toegang tot de GitLab-server te beperken tot enkel bekende ontwikkelaars. GitLab is een interne dienst en mag niet toegankelijk zijn via het internet. Dit kan worden gedaan door de functionaliteit van de server te beperken, bijvoorbeeld door .htaccess-bestanden voor Apache-servers te configureren of door filterregels te maken als de server door een firewall wordt beschermd;
- Op middellange termijn verliezen de bovenstaande maatregelen sterk aan doeltreffendheid en worden ze steeds complexer. De enige mogelijke remediëring is het updaten van GitLab naar de meest recente versie.
Password Authentication Enabled
Eenvoudig uitgelegd
SSH (Secure SHell) is een netwerkprotocol waarmee beheerders op afstand veilig toegang kunnen krijgen tot een computer. Er zijn twee authenticatiemanieren om via SSH verbinding te maken met de server:
- Gebruik van een cryptografische sleutel: deze kan niet door een aanvaller worden geraden omdat het bestand complex en lang is;
- Combinatie van gebruikersnaam en wachtwoord: authenticatie met een wachtwoord kan gemakkelijker worden omzeild door cybercriminelen via brute force.
Als een kwaadwillende hacker de combinatie van wachtwoord en gebruikersnaam weet te achterhalen, kan hij beheerdersrechten verkrijgen en toegang krijgen tot de gegevens op de server. Hij kan deze vervolgens ontoegankelijk maken of stelen.
Technisch bekeken
SSH is een protocol dat voornamelijk wordt gebruikt voor het beheer van Linux-machines. Het laat onder andere toe om op afstand toegang te krijgen tot een pseudo-terminal, wat betekent dat compromittering van SSH op een server vaak neerkomt op volledige overname van die server.
Standaard raadpleegt SSH meestal het wachtwoordbestand van de gebruikers van het systeem, en de toegang wordt dus beschermd door dezelfde wachtwoorden als die welke nodig zijn om lokaal verbinding te maken met de machine of om van gebruiker te wisselen zodra men is ingelogd (bijvoorbeeld met de commando's su of sudo). Een wachtwoord kan echter voldoende zijn om een aanvaller die al toegang heeft tot de server te vertragen, maar volstrekt ontoereikend zijn tegen een groot aantal cybercriminelen.
Oplossing
Deze documentatie heeft tot doel uit te leggen hoe u toegang met een wachtwoord kunt vervangen door toegang met een cryptografische sleutel. Maar voordat we verdergaan, is het belangrijk om te vermelden dat als u SSH-toegang op machines heeft blootgesteld terwijl dit niet (meer) nodig is, de beste bescherming veruit het uitschakelen van deze dienst is.
Als dat niet het geval is en u al sleutels gebruikt om verbinding te maken, lees dan toch verder, want u moet ook controleren of de toegang met wachtwoord is uitgeschakeld.
Stap 1: een sleutelpaar genereren
De eerste stap bestaat erin een sleutelpaar te genereren. SSH-authenticatie berust op het principe van een privésleutel en een publieke sleutel, zodat een server die over de publieke sleutel beschikt, een challenge kan versleutelen en er zo voor kan zorgen dat alleen de houder van de privésleutel deze kan ontsleutelen en zo zijn identiteit kan bewijzen. Log hiervoor met SSH in op uw server en voer de volgende commando's in:
U wordt om een wachtwoord gevraagd. Dit wachtwoord wordt uitsluitend gebruikt om uw privésleutel te versleutelen en wordt u gevraagd telkens wanneer u deze wilt gebruiken. Een goed wachtwoord voorkomt dat een derde die uw privésleutel (hier het bestand my_new_ssh_key) in handen heeft gekregen, verbinding kan maken met uw server. Het gaat dus om een vorm van dubbele authenticatie (twee-factor-authenticatie).
Uw sleutelpaar is gegenereerd. my_new_ssh_key is uw privésleutel en my_new_ssh_key.pub is uw publieke sleutel. Nu moet u de server laten weten dat de houder van my_new_ssh_key.pub toestemming heeft om verbinding te maken. Voer hiervoor de volgende opdracht uit:
cat my_new_ssh_key.pub >> authorized_keys
Kopieer vervolgens het bestand my_new_ssh_key naar uw werkstation. Daarna kunt u dit bestand van de server verwijderen.
Let op: deze stap voor het genereren van sleutels en de daaropvolgende instructies voor clientconfiguratie moeten door elke gebruiker, die verbinding maakt met de server, worden uitgevoerd.
Clientconfiguratie op Windows met PuTTY
Als u een Windows-computer met PuTTY gebruikt om verbinding te maken, moet u uw privésleutel naar het juiste formaat converteren. Om dit te doen, start puttygen.exe (normaal gesproken te vinden in de map waar u PuTTY hebt geïnstalleerd), kies Conversions > Import key, selecteer uw privésleutel en klik op ‘Save private key’. De procedure wordt hieronder geïllustreerd:
Stap 2: een SSH-privésleutel converteren met PuTTY
Geef PuTTY aan dat het deze nieuwe sleutel moet gebruiken om verbinding te maken. Open PuTTY en selecteer in de menubalk aan de rechterkant Connection > SSH > Auth en klik vervolgens op ‘Browse’ om uw sleutel toe te voegen.
Als u een Linux-, MacOS- of Windows-computer met WSL (Windows sub-System for Linux) gebruikt, is de clientconfiguratie eenvoudig: voeg gewoon -i path/to/my_new_ssh_key toe aan uw gebruikelijke SSH-commando.
ssh -i my_new_ssh_key user@server
Het is waarschijnlijk dat u bij uw eerste poging de volgende foutmelding te zien krijgt:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/user/.ssh/my_new_ssh_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/home/user/.ssh/my_new_ssh_key": bad permissions
Uw SSH-client waarschuwt u dat uw privésleutel door andere gebruikers op uw computer kan worden gelezen. Om dit te verhelpen, voert u het volgende commando uit:
chmod 600 my_new_ssh_key
Stap 3: serverconfiguratie
De laatste stap is het verbieden van de verbinding via een wachtwoord. Zonder deze stap zou alles wat tot nu toe is gedaan weinig veiligheidswaarde hebben, aangezien de kennis van het sessiewachtwoord voldoende is om verbinding te maken.
Voordat u verdergaat, zorg ervoor dat u daadwerkelijk verbinding kunt maken via SSH met uw sleutel. Als u de wachtwoordtoegang uitschakelt terwijl dit niet het geval is, loopt u het risico zichzelf buiten te sluiten (lock-out).
U moet ook beheerder (root) zijn om verder te gaan. Als dat niet het geval is, gebruik dan su - of sudo su - om de rechten van uw terminal te verhogen. Open vervolgens het bestand /etc/ssh/sshd_config met uw teksteditor. Zoek in dit bestand de optie PasswordAuthentication en voer no in om de onderstaande regel te krijgen:
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
Nu moet u de configuratie van uw SSH-server opnieuw laden om deze te activeren. Als u systemd als initialisatiesysteem gebruikt, voer dan, nog steeds met root-rechten, het volgende commando uit:
systemctl reload sshd.service
Sluit uw SSH-sessie nu vooral niet af, open een ander terminalvenster op uw client en probeer opnieuw verbinding te maken. Als dat lukt, bent u klaar: uw server accepteert nu alleen nog cryptografische sleutels als inlogmethode. Als dat niet het geval is, schakel dan de wachtwoordauthenticatie weer in.
Database publicly exposed
Eenvoudig uitgelegd
Het publiek toegankelijk maken van een database via internet is van nature onveilig:
- Authenticatie met gebruikersnaam/wachtwoord is een zwakke authenticatiemethode die gevoelig is voor bruteforce-aanvallen en password spraying. Two-factor-authenticatie is complex om te implementeren;
- Hoewel sommige databases communicatieversleuteling ondersteunen, is dit bij de meeste niet het geval, waardoor ze kwetsbaar zijn voor het onderscheppen van gegevensverkeer.
- Distributed Denial-of-Service (DDoS)-aanvallen zijn eenvoudig uit te voeren;
- Gebruikersbeheer is lastig, omdat de meeste bedrijven slechts één gebruikersaccount gebruiken om verbinding te maken met de database;
- Het installeren van beveiligingsupdates en patches is ingewikkeld.
Technisch bekeken
Als een aanvaller erin slaagt een wachtwoord te achterhalen en toegang te krijgen tot de database, kan hij de opgeslagen gegevens en mogelijk zelfs de server waarop de database draait, benaderen.
Het ontwikkelen van een bruteforce-script voor het databaseprotocol is vrij eenvoudig. Het lastige deel is het achterhalen van de gebruikersnaam en het wachtwoord om verbinding te maken. Afhankelijk van het type database is er vaak een standaardaccount, zoals mysql of postgresql.
Gevolgen
- Vanuit cyberoogpunt kan dit een directe impact hebben op de vertrouwelijkheid, integriteit, beschikbaarheid en traceerbaarheid van de informatie die in de database is opgeslagen;
- Vanuit organisatorisch oogpunt leidt een succesvolle verbinding tot indirecte verliezen voor het bedrijf, omdat back-ups moeten worden ingezet om verloren of gewijzigde gegevens te herstellen.
Oplossing
- Op korte termijn raden we aan een firewall te installeren waarmee een whitelist kan worden opgesteld van IP-adressen die verbinding mogen maken met de database.
- Op middellange termijn moet de toegang tot de database gebeuren via een publieke API. De API moet bij voorkeur via een WAF verbinding maken met de database. De API kan tokens toekennen met specifieke rechten (database views) en een toegangstijd. Deze tokens kunnen eenvoudig worden ingetrokken en uw database is veel veiliger wanneer deze correct is geconfigureerd. De API kan eenvoudig worden beveiligd met TLS, whitelists, MFA en andere controles, zoals het blokkeren van een persoon na een aantal mislukte pogingen.
Symfony FOSJsRoutingBundle
Eenvoudig uitgelegd
Symfony is een open source applicatieframework – een werkomgeving die tools en software samenbrengt – dat wordt gebruikt voor PHP-applicaties. Deze kwetsbaarheid stelt een aanvaller in staat om onmiddellijk de routes in kaart te brengen die hij kan testen om uw applicatie aan te vallen.
Technisch bekeken
Deze kwetsbaarheid maakt misbruik van de Symfony FOSJsRoutingBundle, een plugin die het mogelijk maakt om het routing-systeem van de applicatie bloot te stellen in de JavaScript-code.
Om te beginnen kunt u de JsRouting-bundel openen via de volgende URL:
Ziehier een voorbeeld van het resultaat:
Een aanvaller kan onmiddellijk afleiden dat de API de methode sylius_admin_order_creation_order_create met de GET-methode blootlegt. Hij kan deze vervolgens manipuleren om een kwetsbaarheid te vinden die hij kan misbruiken.
Deze aanval heeft geen directe gevolgen, aangezien het hier gaat om een configuratiefout die voornamelijk de verkenningsfase van de aanvaller vergemakkelijkt. Toch verhoogt dit aanzienlijk het risico op een latere, gerichte aanval.
Op korte termijn raden we aan om de toegang tot de map /js/routing te beperken tot de applicatie die effectief gebruik maakt van de beschikbare API-mapping (bijvoorbeeld een domein- of IP-beperking).
CVE-2018-15473
Eenvoudig uitgelegd
Deze kwetsbaarheid maakt het mogelijk om gebruikers te inventariseren, waardoor een lijst met gebruikers en identificatiegegevens van het OpenSSh-protocol kan worden weergegeven. Als wachtwoordauthenticatie is ingeschakeld, kan de aanvaller vervolgens gerichte bruteforce-aanvallen uitvoeren op de accounts waarvan hij het bestaan kent, totdat hij erin slaagt om in te loggen.
Technisch gezien
Deze kwetsbaarheid betreft het OpenSSH-protocol in versies tussen 2.3 en 7.6.
Door een verkeerde verwerking van de pakketten die door het protocol worden ontvangen, kan een aanvaller de geldige gebruikers achterhalen.
In de onderstaande schermafbeelding zijn we erin geslaagd de gebruikers ‘root’ en ‘mail’ te vinden die geldig zijn op de server. Deze informatie stelt aanvallers in staat brute-force-aanvallen uit te voeren. Wanneer wachtwoordverificatie is ingeschakeld, kan de aanvaller vervolgens gerichte bruteforce-aanvallen uitvoeren op de accounts waarvan hij het bestaan kent, totdat hij erin slaagt om in te loggen.
De exploitcode is publiek beschikbaar en gemakkelijk toegankelijk via het internet.
De code die in deze demonstratie wordt gebruikt, is beschikbaar op GitHub.
Gevolgen
- Vanuit cyberoogpunt is de beveiliging van de hostserver in gevaar als de aanvaller een geldige combinatie van gebruikersnaam en wachtwoord vindt.
● Vanuit organisatorisch oogpunt leiden het misbruik van de kwetsbaarheid en het ontdekken van geldige inloggegevens tot directe financiële verliezen doordat de beschikbaarheid van de bedrijfsmiddelen wordt aangetast. Bovendien moet achteraf een onderzoek door beveiligingsexperts worden uitgevoerd om te bevestigen dat het netwerk niet is gecompromitteerd.
Oplossing
Op korte en middellange termijn is de enige manier om deze kwetsbaarheid te verhelpen, het beperken van de toegang tot het SSH-eindpunt tot specifieke IP-adressen, wat op lange termijn moeilijk te handhaven is, of het updaten van het SSH-protocol naar de meest recente versie (aanbevolen).
Symfony-profiler
Eenvoudig uitgelegd
Symfony is een open source applicatieframework dat wordt gebruikt voor PHP-applicaties. Wanneer de applicatie in de ontwikkelingsmodus wordt geïmplementeerd, activeert Symfony een debugcomponent die Web Profiler wordt genoemd. Deze component biedt ontwikkelaars tal van functies om de applicatie tijdens de runtime te inspecteren. Echter, aanvallers kunnen via de profiler gevoelige informatie achterhalen zoals routes, cookies, gebruikersgegevens, bestanden, enz.
Technisch bekeken
Deze kwetsbaarheid kan zowel de onderliggende server waarop het Symfony-framework draait als de applicatiecomponenten die hiermee communiceren treffen, indien er gebruikersgegevens worden gevonden.
U kunt het dashboard van de Symfony-profiler openen via de volgende URL:
{IMPACTED-ASSET}/app_dev.php/_profiler/vide/recherche/résultats?limit=10
Sinds Symfony 3.x biedt de Web Profiler de mogelijkheid om applicatiebestanden te lezen in de rootmap. Deze functie wordt door ontwikkelaars gebruikt om snel de broncode te identificeren die verantwoordelijk is voor de verwerking van een query. Deze functie kan echter misbruikt worden om configuratiebestanden te lezen:
Het is dan mogelijk om configuratiebestanden van applicaties te lezen die mogelijk vertrouwelijke technische gegevens bevatten (database-inloggegevens, sessietokens van applicaties).
Gevolgen
- Vanuit cyberoogpunt kan de impact, in het scenario waarin de aanvaller geldige inloggegevens verkrijgt, variëren van de vertrouwelijkheid van technische details tot de compromittering van de database-informatie.
- Vanuit organisatorisch oogpunt kan de impact van de kwetsbaarheid leiden tot directe financiële verliezen door wijziging van de inhoud van de gecompromitteerde database of de onderliggende server.
Oplossing
Het volstaat om de debugmodus uit te schakelen door het configuratiebestand van Symfony te wijzigen:
# app/config/config.yml
framework:
profiler:
enabled: false
SQLMap: SQL-injectie
Eenvoudig uitgelegd
Een SQL-injectieaanval of SQLI bestaat erin de kwetsbaarheden in de software van een webapplicatie te misbruiken om gegevens te stelen, te verwijderen of te wijzigen en zo controle te krijgen over de systemen waarop de geïnfecteerde applicaties draaien. Hoewel deze aanvallen gemakkelijk te voorkomen zijn, zijn ze even gemakkelijk uit te voeren.
Deze buitgemaakte informatie kan allerlei gegevens omvatten, waaronder gevoelige bedrijfsgegevens, zoals gebruikersnamen en wachtwoorden, persoonsgegevens van gebruikers of zelfs vertrouwelijke klantinformatie, zoals creditcardgegevens.
De impact van SQL-injectie op een bedrijf is aanzienlijk. Een succesvolle aanval kan leiden tot ongeoorloofde toegang tot gebruikerslijsten, de verwijdering van volledige tabellen en, in sommige gevallen, het verkrijgen van beheerdersrechten over een database door de hacker, wat allemaal zeer schadelijk is voor een bedrijf.
Technisch bekeken
SQL-injectie is een veelvoorkomende aanvalsmethode waarbij kwaadaardige SQL-code wordt gebruikt om een back-end-database te manipuleren en toegang te krijgen tot informatie die normaal niet zichtbaar mag zijn.
Gevolgen
- Vanuit cyberoogpunt kan dit een directe impact hebben op de privacy van gegevens. Alle gegevens die in de database zijn opgeslagen, zijn gecompromitteerd en, afhankelijk van de configuratie, kan er andere toegang worden verkregen, zoals code-uitvoering op de server die de database host. Aangezien voor het misbruik van de kwetsbaarheid geen authenticatie bij de applicatie nodig is, is de impact ervan kritiek;
- Vanuit organisatorisch oogpunt kan het misbruik van de kwetsbaarheid leiden tot indirecte financiële verliezen door de vertrouwelijkheid van de opgeslagen gegevens in gevaar te brengen. Dit kan publieke gevolgen hebben en leiden tot een vertrouwensbreuk. De toegang tot alle diensten die afhankelijk zijn van de getroffen database zal mogelijk onbeschikbaar zijn totdat de aanval is afgeweerd, wat kan leiden tot aanzienlijke downtime.
Oplossing
- Een API met geparametriseerde query's implementeren: de overstap van directe invoer in een webapplicatie naar het gebruik van een veilige API is de betrouwbaarste manier om SQL-injectie tegen te gaan. Hierdoor wordt de SQL-interpreter vermeden en worden voorgeformatteerde query's gebruikt. Het creëren van een geparametriseerde API is de beste methode om SQL-injectieaanvallen te beperken.
- Het implementeren van Character Escaping: als er geen API beschikbaar is, moeten uw webapplicaties speciale tekens kunnen omzeilen (d.w.z. alle tekens die van invloed zijn op de syntaxis van SQL-talen). Dit moet worden beschouwd als een laatste verdedigingslinie, want Character Escaping biedt geen afdoende bescherming in alle situaties.
Bovendien kan de webapplicatie zelf proberen bepaalde query’s te omzeilen, maar afhankelijk van de manier waarop de query’s worden verwerkt, wordt het nog moeilijker om dit te voorkomen.
Terug naar boven
CVE-2022-23808
Eenvoudig uitgelegd
Deze kwetsbaarheid betreft phpMyAdmin, een gratis en open source beheertool voor MySQL en MariaDB. Als draagbare webapplicatie die voornamelijk in PHP is geschreven, is phpMyAdmin uitgegroeid tot een van de populairste MySQL-beheertools, met name voor webhostingdiensten.
Technisch gezien
Deze CVE is ontdekt in het databasebeheerpaneel van PhpMyAdmin versie 5.1.1 tot 5.1.2. Omdat authenticatie vereist is om toegang te krijgen tot het beheerderspaneel, was het ons niet mogelijk om deze kwetsbaarheid te misbruiken. Openbare details zijn echter beschikbaar op GitHub.
Gevolgen
- Vanuit cyberoogpunt is het mogelijk om een XSS (Cross-Site Scripting)-kwetsbaarheid te activeren (kwaadaardige invoer door de gebruiker die leidt tot de uitvoering van Javascript op de browser van het slachtoffer). Misbruik van de XSS-kwetsbaarheid kan leiden tot identiteitsdiefstal van een gebruiker of diefstal van zijn account op het PhpMyAdmin-platform.
- Vanuit organisatorisch oogpunt zou een geauthenticeerde gebruiker misbruik kunnen maken van het gebrek aan sanitatie van gebruikersinvoer en zich voordoen als een geprivilegieerd account. Het gebruik van deze accounts met verhoogde rechten kan leiden tot indirecte financiële verliezen.
Hieronder vindt u een schema om XSS beter te begrijpen:
Oplossing
De enige manier om deze kwetsbaarheid te verhelpen, is door het PhpMyAdmin-platform bij te werken naar de meest recente versie.
Wordpress-accessible-wpconfig
Eenvoudig uitgelegd
Het wp-config-bestand is een van de belangrijkste configuratiebestanden in WordPress. Dit bestand kan waardevolle informatie bevatten, zoals de database-inloggegevens. Als dit bestand toegankelijk is, brengt dit de privacy en integriteit van uw gegevens in gevaar.
Technisch bekeken
Het bestand wp-config bevindt zich gewoonlijk op https://wordpress-path/wp-config.php.
Oplossing
De oplossing is om de toegang tot het bestand te beperken, zoals aangegeven in dit artikel.
Voor een Apache-server:
- Open het .htaccess-bestand met een teksteditor;
- Voeg de volgende regels code toe aan het einde van het .htaccess-bestand:
# Deny access to wp-config/php
<Files wp-config.php>
Order allow,deny
Deny from all
</Files>
Voor andere verwante applicatieservers, raadpleeg de handleiding van het configuratiebestand (Bijvoorbeeld, het nginx-configuratiebestand bevindt zich in /usr/local/nginx/conf (Unix-server).)
/location ~ /(wp-config.php) {
deny all;
return 404;
}
...
Terug naar boven
Laravel env.
Eenvoudig uitgelegd
Het .env-bestand bevat gevoelige gegevens die vanuit de broncode worden geladen in de productie- of ontwikkelomgeving. Het mag nooit in een productieomgeving worden geïmplementeerd, omdat het gevoelige ontwikkelingsgegevens bevat die mogelijk herbruikt kunnen worden in de productieomgeving.
Technisch gezien
Hieronder vindt u een voorbeeld van een .env-bestand:
Een compromittering van dit bestand vormt een direct risico voor elk betrokken onderdeel waarvan de inloggegevens in het .env-bestand zijn opgeslagen. Het bestand is gewoonlijk te vinden in het pad https://web-server-path/.env.
Gevolgen
Als de identificatiegegevens toegang geven tot de publieke Code Repository, kunnen de vertrouwelijkheid en integriteit van de broncode in gevaar komen. Deze bestanden kunnen ook database-inloggegevens bevatten. In combinatie met een publiekelijk toegankelijke database kan dit een rechtstreekse impact hebben op de opgeslagen gegevens.
Oplossing
Er zijn twee mogelijke oplossingen:
- De toegang tot het bestand beperken door het configuratiebestand van de server te wijzigen. Wijziging van het .htaccess-bestand zoals in de volgende code beperkt de toegang tot het .env-bestand:
# Deny access to .env
<Files .env>
Order allow,deny
Deny from all
</Files>
- Het geïmplementeerde bestand verwijderen, omdat geen enkel .env-bestand mag worden geïmplementeerd, ongeacht of de toegang ertoe is beperkt of niet.
CVE-2021-34473
Eenvoudig uitgelegd
Deze kwetsbaarheid, ook bekend onder de naam Proxyshell, is een combinatie van drie CVE's:
- CVE-2021-31207: omzeiling van de toegangscontrole;
- CVE-2021-34523: privilege-escalatie op de back-end van de Exchange-server;
- CVE-2021-34473: Remote Code Execution (RCE) op de server via het schrijven van arbitraire bestanden.
Technisch bekeken
De kwetsbaarheid kan worden misbruikt met behulp van publiek beschikbare code. Onderzoek in webbrowsers leidt naar broncode die beschikbaar is op GitHub.
De eerste stap van de exploit kan worden getest door het python-script proxyshell_enumerate uit te voeren, dat een lijst met e-mailadressen van de mailserver oplevert:
Deze stap bewijst dat de Exchange-server kwetsbaar is voor de exploit en dat Remote Code Execution (RCE) ook mogelijk is.
Gevolgen
- Vanuit cyberoogpunt kan een aanvaller die interactie heeft met de getroffen Exchange-server lokale beheerdersrechten op de server verkrijgen. Aangezien de Exchange-mailserver vaak met domeinbeheerdersrechten werkt, loopt het hele Active Directory-domein gevaar gecompromitteerd te worden.
- Vanuit organisatorisch oogpunt leidt misbruik van de kwetsbaarheid tot directe en indirecte financiële verliezen doordat een aanvaller bevoorrechte toegang tot het netwerk krijgt.
Oplossing
De enige manier om deze kwetsbaarheid te verhelpen, is door de versie van de Exchange-server te updaten. Aangezien deze kwetsbaarheid actief is misbruikt, raden we aan om cyberbeveiligingsprofessionals in te schakelen om te controleren of het netwerk niet is gecompromitteerd.
WordPress Core < 4.7.1 - Username Enumeration (CVE-2017-5487)
Eenvoudig uitgelegd
Gebruikersopsomming maakt het mogelijk om een lijst van WordPress-accountgebruikers weer te geven. Een kwaadwillende hacker kan een bruteforce-aanval uitvoeren om de wachtwoorden van gebruikersaccounts te achterhalen, waardoor WordPress-accounts gecompromitteerd kunnen worden.
Technisch gezien
Versie 4.7.1 van WordPress Core is gevoelig voor gebruikersopsomming via de URL https://wordpress/wp-json/wp/v2/users. De scanner kan de kwetsbaarheid ook identificeren als de WordPress-API te makkelijk toegankelijk is, zelfs als de Core-versie niet kwetsbaar is. Dit komt doordat WordPress standaard geen toegangsbeperkingen gebruikt.
Oplossing
- Als u een versie van WordPress < 4.7.1 gebruikt, moet u WordPress via het beheerderspaneel updaten naar de laatste beschikbare versie.
- Als uw versie van WordPress reeds up-to-date is, raden we aan een beveiligingsplugin te installeren, zoals Disable REST API plugin.
- Ga in uw WordPress-dashboard naar Plugins toevoegen;
- Zoek naar de plugin Disable REST API of iThemes Security (of andere plugins met goede reviews over hetzelfde onderwerp);
- Installeer en activeer de plugin.
CVE-2020-9490
Eenvoudig uitgelegd
Deze kwetsbaarheid kan een kwaadwillende hacker in staat stellen een Denial-of-Service-aanval (DDoS) uit te voeren, waardoor de beschikbaarheid van uw infrastructuur kan worden verstoord.
Technisch bekeken
Deze kwetsbaarheid is een Denial-of-Service-aanval gericht op Apache HTTPD-servers in versies ouder dan 2.4.46. Door speciale HTTP-headers (Cache-Digest) te maken, kan een aanvaller een kwetsbare HTTPD-server compromitteren.
Gevolgen
- Vanuit cyberoogpunt kan er een directe impact zijn op de beschikbaarheid van de kwetsbare server. Het misbruik van de kwetsbaarheid vereist geen enkele authenticatie, waardoor het des te gemakkelijker te implementeren is;
- Vanuit organisatorisch oogpunt zal, indien de server een applicatie host die in productie wordt gebruikt, misbruik leiden tot directe financiële verliezen door bedrijfsonderbrekingen, aangezien het systeem buiten gebruik zal zijn en telkens opnieuw zal proberen op te starten bij elk succesvol misbruik. Alle websites die op de getroffen machine worden gehost, zullen ontoegankelijk zijn.
Oplossing
De Apache HTTP-server moet worden bijgewerkt naar de laatste beschikbare versie die klaar is voor productie (versie 2.4.54, gepubliceerd op 06-08-2022).
Directory listing
Eenvoudig uitgelegd
Een directory listing geeft een aanvaller een volledige index van alle bestanden en mappen binnen een bepaalde directory. De specifieke risico's en gevolgen variëren afhankelijk van de bestanden die zichtbaar en toegankelijk zijn.
Stoïk maakt deze kwetsbaarheid alleen bekend wanneer de volgende bestanden zijn getroffen:
- De broncode van de applicatie;
- Gebruikersnamen, wachtwoorden of hashes;
- De persoonlijke gegevens van gebruikers (bankgegevens, identiteitsbewijzen, CV's)
Technisch bekeken
Er hoeft geen commando te worden uitgevoerd, er wordt toegang verkregen tot een directory-index om de bestanden weer te geven.
De meeste daarvan bevinden zich op WordPress-instanties, zoals /wp-content/uploads.
Gevolgen
Blootstelling van de inhoud van een map kan een aanvaller toegang geven tot de broncode of nuttige informatie verschaffen voor het ontwikkelen van exploits, zoals het tijdstip waarop bestanden zijn aangemaakt of informatie die in bestandsnamen kan zijn gecodeerd. Het tonen van een directory listing kan ook leiden tot het blootleggen van privé- of vertrouwelijke informatie.
Oplossing
Op Apache moet u regels code toevoegen aan het .htaccess -bestand van uw website om de directory list uit te schakelen.
Om toegang te krijgen tot het bestand heeft u een FTP-client nodig. Als u die niet heeft, kunt u de bestandsbeheerder in uw WordPress-hostingcontrolepaneel gebruiken.
Nadat u bent ingelogd op uw site, opent u gewoon de public directory van uw website en zoekt u het bestand .htaccess. U kunt het bestand .htaccess wijzigen door het naar uw bureaublad te downloaden en vervolgens te openen in een teksteditor zoals Kladblok.
Voeg onderaan het bestand de volgende code toe:
Het zal er als volgt uitzien:
Wanneer u klaar bent, sla het .htaccess-bestand op en upload het naar uw server met behulp van een FTP-client.
Als uw webserver niet op Apache draait, kunt u dit artikel raadplegen.
Docker-compose.yml exposure
Eenvoudig uitgelegd
Docker Compose is een tool waarmee Docker-applicaties kunnen worden gedefinieerd en uitgevoerd. Wanneer dit bestand publiek toegankelijk is, kan alle informatie die nodig is voor de implementatie van een applicatie worden geraadpleegd. Het is niet ongebruikelijk dat wachtwoorden en andere vertrouwelijke gegevens in dit bestand staan.
Technisch gezien
Met Compose gebruiken ontwikkelaars één configuratiebestand (docker-compose.yml) om meerdere services van de applicatie te definiëren en uit te voeren. Soms plaatsen ontwikkelaars dit bestand per ongeluk in productieomgevingen. Aangezien dit bestand doorgaans alle informatie bevat die nodig is voor de implementatie van een applicatie, is het niet ongebruikelijk dat wachtwoorden en andere geheime gegevens in dit bestand staan.
U kunt het docker-compose-bestand openen via de volgende URL in uw favoriete webbrowser: 0/docker-compose.yml
Gevolgen
Door toegang te krijgen tot een blootgesteld docker-compose.yml-bestand, kan een aanvaller misbruik maken van de kwetsbaarheid om ongeoorloofde toegang te verkrijgen tot gevoelige informatie. Als er wachtwoorden worden gevonden, kan onmiddellijk toegang tot de server worden verkregen. Zelfs als er geen geheime gegevens aanwezig zijn, kan belangrijke informatie over de interne aspecten van de applicatie worden onthuld, waardoor een kwaadwillende hacker een gerichte aanval kan uitvoeren.
Zie hieronder een voorbeeld:
Oplossing
Zorg ervoor dat het bestand docker-compose.yml niet samen met de applicatie wordt geïmplementeerd of in ieder geval niet toegankelijk is via een webserver-directory door de juiste machtigingen in te stellen.
Als gevoelige informatie, zoals inloggegevens, in het blootgestelde bestand wordt onthuld, moet deze worden ingetrokken en opnieuw worden ingesteld op de betrokken apparaten.
CVE-2022-41040
Eenvoudig uitgelegd
Deze kwetsbaarheid, in combinatie met CVE-2022-41082, stelt een geauthenticeerde aanvaller in staat om Remote Code Execution (RCE) uit te voeren.
Technisch bekeken:
Twee zero-day kwetsbaarheden (nooit eerder gepubliceerd) hebben invloed op Microsoft Exchange Server 2013, Exchange Server 2016 en Exchange Server 2019.
De eerste, CVE-2022-41040, is een kwetsbaarheid van het type Server-Side Request Forgery (SSRF). De tweede, CVE-2022-41082, maakt Remote Code Execution (RCE) mogelijk wanneer PowerShell toegankelijk is voor de aanvaller.
Op 03/10/22 was Microsoft op de hoogte van een beperkt aantal gerichte aanvallen waarbij gebruik werd gemaakt van deze twee kwetsbaarheden.
Bij deze aanvallen kan de kwetsbaarheid CVE-2022-41040 een geauthenticeerde aanvaller in staat stellen om Remote Code Execution te activeren via de kwetsbaarheid CVE-2022-41082. Het is belangrijk op te merken dat geauthenticeerde toegang tot de kwetsbare Exchange-server nodig is om een van deze kwetsbaarheden met succes te kunnen exploiteren.
Raadpleeg dit artikel van Microsoft voor meer informatie.
Gevolgen
- Vanuit cyberoogpunt maakt het misbruik van deze twee kwetsbaarheden het mogelijk om Remote Code Execution uit te voeren op de server, vaak met beheerdersrechten. Een aanvaller kan zo volledige controle krijgen over het domein of het netwerk dat is verbonden met de Exchange-server.
- Vanuit organisatorisch oogpunt zal een aanvaller directe en indirecte financiële verliezen voor het slachtoffer veroorzaken door de beschikbaarheid en integriteit van het netwerk te verstoren.
Oplossing
Om deze kwetsbaarheid te verhelpen, moet u de Exchange-server bijwerken.
CVE-2022-35914
Eenvoudig uitgelegd
Deze kwetsbaarheid maakt misbruik van een updatefout waardoor op afstand kwaadaardige code in uw infrastructuur kan worden geschreven.
Technisch bekeken
Deze kwetsbaarheid treft GLPI-software wanneer deze gebruikmaakt van een externe bibliotheek met de naam htmlawed. Om de kwetsbaarheid te reproduceren, hebben we gebruikgemaakt van een publiek beschikbare Proof of Concept (PoC) op GitHub.
De PoC is gebruiksklaar en zeer eenvoudig te gebruiken:
De impact is kritiek, er moet onmiddellijk actie worden ondernomen.
Gevolgen
- Vanuit cyberoogpunt is er een directe impact op de vertrouwelijkheid, integriteit, beschikbaarheid en traceerbaarheid van de assets die op de server zijn opgeslagen. Aangezien voor het misbruik van de kwetsbaarheid geen authenticatie op het platform of de server nodig is, is de impact ervan kritiek en is directe toegang tot de hostserver mogelijk.
- Vanuit organisatorisch oogpunt leidt het misbruik van de kwetsbaarheid tot directe financiële verliezen doordat de beschikbaarheid van de bedrijfsmiddelen wordt aangetast en moet achteraf een onderzoek door beveiligingsexperts worden uitgevoerd om te controleren of het netwerk niet is gecompromitteerd.
Oplossing
Om deze kwetsbaarheid te verhelpen, moet u de GLPI-software updaten naar de meest recente versie.
VMSA-2021-0002
Eenvoudig uitgelegd
Deze kwetsbaarheid wordt veroorzaakt door misbruik van een fout in een systeem dat ESXi heet. Hierdoor kan een kwaadwillende hacker Remote Code Execution uitvoeren en een ransomware-aanval ontketenen.
Technisch bekeken
De meerdere kwetsbaarheden, genaamd VMSA-2021-0002, hebben invloed op verschillende versies van VMware ESXi en vSphere Client. Vooral de kwetsbaarheid CVE-2021-21974 wordt op grote schaal misbruikt om het informatiesysteem binnen te dringen en ransomware te implementeren.
De kwetsbaarheid CVE-2021-21974 maakt misbruik van het feit dat OpenSLP, zoals gebruikt in ESXi, een kwetsbaarheid van het type “heap-overflow” vertoont. Hierdoor kan Remote Code Execution worden uitgevoerd met verhoogde rechten op ESXi door misbruik te maken van de bijbehorende service die blootgesteld is op poort 427.
De getroffen versies zijn onder andere (en alle eerdere versies)
ESXi 7.0 Update 1c (security Only)
- Release datum: 17/12/2020
- Buildnummer: 17325020
ESXi 6.7 P04
- Release datum: 19/11/2020;
- Buildnummer: 17167734.
ESXi 6.5 EP 23
- Release datum: 19/11/2020;
- Buildnummer: 17167537.
Alle versies van ESXi 6.0
Oplossing
- Op korte termijn kan de SLP-service rechtstreeks op ESXi worden uitgeschakeld via de documentatie van VMware.
- Op middellange termijn is het raadzaam om ESXi te updaten naar de meest recente versie.