Datacenters draaien vaak op betrouwbare hardware, maar het managementlaagje verdient minstens zoveel aandacht. Volgens securitybedrijf Lava maakt een BMC-kwetsbaarheid (CVE-2013-4786) uit 2004 misbruik van het IPMI-protocol (Intelligent Platform Management Interface) mogelijk. Daardoor kan een aanvaller wachtwoordhashes bemachtigen en vervolgens offline wachtwoorden kraken, zonder telkens opnieuw online pogingen te moeten doen.
Omdat Baseboard Management Controllers (BMC’s) in veel serverplatformen aanwezig zijn, en beheerders er ook toegang toe hebben wanneer het besturingssysteem uitvalt, vormen BMC’s een van de meest bevoorrechte ingangen tot het datacenter. Als zo’n ingang zwak beveiligd is of standaardreferenties gebruikt, kan één blootgestelde server een lastig te detecteren startpunt worden.
Waarom BMC’s zo aantrekkelijk zijn voor aanvallers
Een BMC is ontworpen om serverbeheer mogelijk te maken, zelfs als het besturingssysteem niet werkt. In de praktijk betekent dat dat beheerders via de BMC doorgaans onder meer power-cycle-acties kunnen uitvoeren, firmware-updates kunnen doen en laag-niveau platforminstellingen kunnen wijzigen.
Daarnaast is er beheer via meerdere oppervlakken. Denk aan out-of-band beheer via IPMI, aan een Redfish management-API via HTTPS en aan webgebaseerde admininterfaces. Het probleem volgens Lava is dat in veel implementaties die interfaces dezelfde gebruikersdatabase gebruiken.
Dat heeft een concreet gevolg: als een aanvaller via IPMI iets kan “ontdekken” dat herleidbaar is naar wachtwoordgegevens, kan dat vervolgens ook helpen bij pogingen tegen andere managementvlakken.
De kern van de BMC-kwetsbaarheid: offline password cracking
De BMC-kwetsbaarheid die Lava beschrijft, is CVE-2013-4786. Die is geïntroduceerd in de IPMI 2.0 authenticatiespecificatie. De essentie zit in het authenticatieproces: tijdens verificatie kan de BMC een HMAC-SHA1 auth-code teruggeven. Die code wordt berekend met accountwachtwoord- en sessiewaarden die voor de aanvrager bekend zijn.
Volgens de NIST-advisory waarop Lava zich baseert, kan een niet-geauthenticeerde remote partij die UDP-poort 623 kan bereiken, die response opvragen. Daarna kunnen wachtwoordpogingen offline worden getest door de relevante hash uit de RAKP-berichten (RAKP message 2 response) te verkrijgen.
Het grote verschil met “gewoon” proberen inlogpogingen online door te voeren, is de efficiëntie. In plaats van per kandidaat opnieuw interactie met de doelmachine te moeten doen, kan een aanvaller het proces verschuiven naar offline cracking. Daardoor zijn zwakke, hergebruikte of standaard wachtwoorden extra riskant.
Wat Lava aantrof: internetblootgestelde managementinterfaces
Lava stelt dat het onderzoek bijna 37.000 internet-exposed server-managementinterfaces vond die het IPMI-protocol gebruiken. Daarbovenop meldt Lava dat meer dan 24.000 van die interfaces vóór login wachtwoordafgeleide authenticatiehashes openbaar maken.
Met andere woorden: niet alleen is het managementvlak vindbaar vanaf het internet, bij een aanzienlijk deel van die blootgestelde endpoints valt ook nog informatie te verzamelen die direct bruikbaar is voor offline aanvallen.
Extra alarmsignalen: lege gebruikersnaam en bekende accounts
Naast het fundamentele mechanisme van CVE-2013-4786 benadrukt Lava een aantal extra configuratieproblemen bij een deel van de onderzochte systemen.
- Volgens Lava accepteerden 6.240 hosts een lege gebruikersnaam in combinatie met een zwak wachtwoord.
- Bij 2.340 hosts vond Lava een benoemde accountnaam terug, zoals Admin of root, met wachtwoorden die vaak voorkomen in publiek beschikbare wordlists.
Daar komt bij dat Lava ook gevallen beschrijft waarin BMC’s gebruikten van “constrained” en voorspelbare wachtwoordformaten die als fabrieksinstelling worden uitgegeven.
Dit soort patronen betekent in de praktijk dat een aanvaller niet hoeft te “gokken” met willekeurige combinaties, maar kan terugvallen op waarschijnlijkheidsmodellen en bestaande lijsten.
Het bredere gat in de managementlaag
Lava positioneert de BMC-kwetsbaarheid niet als een geïsoleerd incident, maar als een aanwijzing voor een breder beveiligingsgat in het datacenter management plane. BMC’s sturen namelijk kritieke infrastructuurprocessen aan, terwijl ze vaak minder monitoring en bescherming krijgen dan de systemen die ze beheren.
Combineer dat met moderne GPU-gebaseerde cracking en met wachtwoorden die voorspelbaar of standaard zijn, dan kan één blootgestelde BMC uitgroeien tot een bevoorrechte en moeilijk te detecteren toegang. Juist omdat het gaat om out-of-band beheer kan het ook sneller buiten het zicht vallen van standaard alerts die primair op OS- of applicatielagen focussen.
Wat je nu kunt doen: check, patch en beperk blootstelling
Als je datacenter draait op serverhardware met BMC’s, is dit het moment om je managementketen te herijken. Lava’s bevindingen laten zien dat het probleem niet alleen technisch is, maar ook draait om configuratie, bereikbaarheid en accounthygiëne.
1) Inventariseer internetblootstelling van managementinterfaces
Begin met een realistische inventaris: welke managementinterfaces zijn vanaf het internet bereikbaar, en via welke protocollen? Let daarbij specifiek op interfaces die IPMI gebruiken en op BMC’s die zich via UDP-poort 623 laten bereiken.
2) Vervang of verminder bereikbaarheid waar mogelijk
Als een endpoint publiek bereikbaar is, is beperking van toegang een snelle winst. Plaats managementverkeer waar dat kan achter toegangscontrole, netwerksegmentatie of restrictieve firewallregels. Het doel is simpel: zorg dat alleen beheerde netwerken en geautoriseerde systemen toegang hebben.
3) Gebruik sterke, unieke credentials voor BMC’s
Vervang standaardwachtwoorden, voorkom hergebruik en schakel over naar sterke, unieke wachtzinnen of wachtwoordvarianten. Lava’s observatie over zwakke wachtwoorden en bekende accountnamen toont aan dat default-achtige instellingen een directe hefboom vormen.
4) Kijk naar vendorspecifieke patches en hardening
Onderzoek per platform welke vendormaatregelen beschikbaar zijn rondom de betreffende CVE. In het algemeen geldt: zorg dat firmware en managementcomponenten actueel zijn en volg hardeningrichtlijnen voor IPMI, Redfish en webinterfaces.
Heb je meerdere managementsurfaces, ga dan extra zorgvuldig te werk. Als interfaces dezelfde database gebruiken, dan is een zwak punt in één oppervlak een risico voor het geheel.
Gerelateerde beveiligingsaanpak: patchmanagement en exploitatie voorkomen
De situatie rond BMC’s past in een breder patroon: beveiligingsproblemen in infrastructuurbeheer worden regelmatig misbruikt wanneer patches niet tijdig worden toegepast of wanneer kwetsbaar bereik openstaat. Op onze site bekijken we dat soort risico’s vanuit verschillende invalshoeken.
- Lees ook: Implicaties van hacks en patches: wat je nu doet voor praktische aandachtspunten rond opvolging na meldingen.
- Daarnaast is SonicWall SMA1000: ransomware via misbruik relevant als voorbeeld van hoe kwetsbaarheden kunnen uitmonden in echte aanvallen wanneer beveiliging niet op tijd sluit.
- Voor de aanpak rond kwetsbare managementcomponenten kan ook N-able N-central: aanvallers nemen server over helpen om het belang van beheerinterfaces te duiden.
Conclusie
De BMC-kwetsbaarheid CVE-2013-4786 laat zien hoe kwetsbare servermanagementlagen het verschil maken tussen “beheersbaar” en “ingrijpend compromis”. Lava’s scanning- en observaties wijzen op een verontrustende combinatie: veel IPMI-interfaces zijn internetblootgesteld, een groot deel daarvan lekt password-afgeleide informatie en sommige systemen gebruiken bovendien zwakke of voorspelbare inloginstellingen.
Door internetblootstelling terug te dringen, BMC-credentials strikt te beveiligen en firmware en managementsoftware tijdig te patchen, kun je het risico aanzienlijk verkleinen. Vooral omdat BMC’s out-of-band controle bieden, is het cruciaal dat je juist deze laag meeneemt in je beveiligingsstrategie—niet alleen de systemen die zichtbaar draaien in je datacenter.
