Die Kea DHCP-Server-Suite hat sich als moderne Nachfolge-Lösung des klassischen ISC DHCP etabliert und ist mittlerweile in zahlreichen Linux- und BSD-Distributionen weit verbreitet. Als Open-Source-Projekt des Internet Systems Consortium (ISC) bietet Kea innovative Funktionen, unterstützt mehrere DHCP-Varianten und ermöglicht eine flexible Konfiguration über eine REST-API. Doch trotz dieser Fortschritte offenbarten Sicherheitsexperten bedeutende Schwachstellen, die das Vertrauen in die Sicherheit des Systems beeinträchtigen können. Die Security-Meldung der ISC zur Offenlegung dreier Schwachstellen in Kea hat in der IT-Sicherheitsgemeinschaft und bei Administratoren für großes Aufsehen gesorgt. Die entdeckten Probleme betreffen insbesondere die lokale Angriffsfläche und erlauben es unprivilegierten Benutzern, Rechte auf Root-Ebene zu erlangen oder sensible Informationen auszulesen. Die Erkenntnisse basieren auf einer gründlichen Analyse der Kea-Version 2. 6.
1, wobei die Schwachstellen auch ältere Versionen betreffen, und wurden temporär koordiniert mit den betroffenen Distributionen kommuniziert, um Patches rechtzeitig zu gewährleisten. Es lohnt sich daher, die Details zu den einzelnen Schwachstellen zu verstehen, um Risiken im eigenen Umfeld zu erkennen und geeignete Maßnahmen umzusetzen. Ein kritischstes Sicherheitsproblem zeigt sich beim Befehl "set-config" der Kea REST-API. Hier kann ein Angreifer lokal eine bösartige Hook-Bibliothek angeben, die vom Kea-Control-Agent geladen wird. Durch das Platzieren einer präparierten dynamischen Bibliothek beispielsweise im Home-Verzeichnis eines Benutzers lässt sich der Programmfluss manipulieren und schadhaften Code in Root-Rechten ausführen. Dies ist vor allem gefährlich, wenn die Kea-Dienste mit vollen Administratorrechten laufen, was zum gängigen Standard in vielen Distributionen gehört.
Selbst wenn Kea mit reduzierten Rechten betrieben wird, führt der Angriff zu einem vollständigen Kompromiss der Kea-Prozesse und kann die Netzwerkfähigkeiten des Dienstes unerlaubt erweitern. Die zweite bedeutende Schwachstelle betrifft den "config-write" Befehl der REST-API, mit dem der Kea-Service angewiesen werden kann, seine Konfigurationsdaten in eine beliebige Datei auf dem System zu schreiben. Durch die unkontrollierte Pfadangabe kann ein lokaler Angreifer gezielt kritische Systemdateien oder Konfigurationsdateien auf dem Server überschreiben oder manipulieren. In Kombination mit geeigneter Dateiauswahl ist damit ein Angriff denkbar, der zu einer dauerhaften Eskalation oder einem Denial-of-Service führen kann. Vor allem wenn Kea als root läuft, ist diese Schwachstelle hochgradig kritisch. Zum dritten bekannten Problem gehört die Umleitung von Logdateien auf beliebige Pfade.
Über die REST-API kann ein Angreifer die Konfiguration so ändern, dass Logdateien nicht mehr an vorgesehenen Orten abgelegt werden, sondern unter Systemdateien, die sensible Informationen enthalten könnten. Dabei ist es möglich, Berechtigungsschwächen auszunutzen und etwa Debug-Level-Protokolle zu erzwingen, wodurch interne Abläufe und sensible Daten offengelegt werden könnten. Hinzu kommt, dass auf einigen Systemen die Kea UNIX-Domain-Sockets im unsicheren Verzeichnis /tmp platziert werden. Dies erlaubt lokalen Benutzern, eigene Socket-Dateien anzulegen und damit echten Kea-Prozessen vorzugaukeln, was eine gezielte Manipulation und Service-Spoofing ermöglicht. Diese Schwäche können Angreifer nutzen, um Administratoren zur Ausführung gefälschter oder gefährlicher Kommandos zu bringen oder sensible Daten abzufangen.
In verschiedenen Distributionen, darunter Fedora und Arch Linux, sind Kea-Dienste bisher häufig mit root-Rechten konfiguriert und setzen Sockets in /tmp ein, was diese Angriffe erleichtert. Daneben wurde eine undichte Stelle bei den Datei- und Verzeichnisberechtigungen entdeckt: Die DHCP-Lease-Dateien sowie Logdateien sind in vielen Standardinstallationen weltweit lesbar, sodass potenziell alle lokalen Benutzer auf diese Daten zugreifen können. Auch wenn DHCP-Leases nicht immer als hochgradig sensibel gelten, bergen sie doch einen Informationswert, der Angreifern Aufschluss über Netzwerkinfrastruktur und verbundene Geräte geben kann. Die Untersuchungen zeigten, dass verschiedenste Linux- und BSD-Distributionen unterschiedlich von den Schwachstellen betroffen sind.
So ist beispielsweise bei Debian und Ubuntu durch Nutzerkonten mit eingeschränkten Berechtigungen sowie den Einsatz von AppArmor-Profilen eine vollständige Ausnutzung der schwersten Sicherheitslücken erschwert oder verhindert. Fedora und Arch Linux hingegen sind oftmals vollständiger gefährdet, nicht zuletzt, weil in älteren Versionen der Kea-Server als root läuft und der Socket unter /tmp liegt. Der Hersteller ISC hat in den nachfolgenden Kea-Versionen 2. 4. 2, 2. 3 und 2. 7. 9 umfangreiche Bugfixes veröffentlicht, die unter anderem das Laden von Hook-Bibliotheken auf vertrauenswürdige Systemverzeichnisse einschränken und verbindliche Pfade für Schreiboperationen und Logfiles vorgeben. Zugleich werden in der Standardkonfiguration die REST-API-Zugriffe nun authentifiziert, so dass unberechtigte Nutzer keinen vollständigen Zugriff mehr erhalten. Auch die Verzeichnisse für Sockets, Logs und Zustandsdaten werden standardmäßig mit restriktiven Berechtigungen angelegt.
Die Kea-Entwickler empfehlen dringend, diese Security-Updates umgehend einzuspielen und gegebenenfalls die Konfigurationsanpassungen vorzunehmen. Darüber hinaus werden weitere Härtungsmaßnahmen angedacht, zum Beispiel natürliche Schutzmaßnahmen gegen Timing-Angriffe bei der Authentifizierung und der Umgang mit API-Zugangsdaten, um versehentliche Informationslecks zu vermeiden. Betreiber sollten daher nicht nur Updates einspielen, sondern auch den Schutz von Berechtigungen, Nutzerdaten und API-Authentifizierungsmechanismen sorgfältig prüfen. Auf der Ebene der Systemadministration empfiehlt es sich, Kea nicht als root, sondern mit dedizierten und möglichst restriktiven Service-Konten auszuführen. Die Platzierung von Unix-Domain-Sockets sollte nicht im allgemein zugänglichen /tmp, sondern in geschützten Verzeichnissen erfolgen. Zugriffsbeschränkungen und Sicherheitsmodule wie AppArmor oder SELinux können zusätzlichen Schutz bieten.
Regelmäßige Audits der Dateiberechtigungen an Log- und Zustandsverzeichnissen sind ebenfalls ratsam, da diese derzeit oftmals zu großzügig gesetzt sind. Zusammenfassend zeigen die Sicherheitsvorfälle rund um Kea DHCP deutlich, wie sensibel die Konfiguration von Netzwerkdiensten ist und dass insbesondere lokale Benutzerrechte nicht unterschätzt werden dürfen. Die Offenlegung der Schwachstellen durch ISC und die rasche Veröffentlichung von Patches zeigen einen vorbildlichen Prozess der interdisziplinären Kommunikations- und Sicherheitskooperation. Für Administratoren bedeutet dies vor allem, wachsam zu sein, schnell und sorgfältig Sicherheitsupdates zu implementieren und Best Practices bei Betrieb und Absicherung von DHCP-Servern zu berücksichtigen. Kea bleibt trotz der Zwischenergebnisse eine vielseitige und leistungsstarke Lösung, die mit angemessenen Vorsichtsmaßnahmen auch weiterhin zuverlässig zum Einsatz kommen kann.
Die jüngsten Security-Reports bieten darüber hinaus wertvolle Hinweise auf Verbesserungen, die zukünftig in weiteren Kea-Versionen mit einfließen dürften, um noch umfassenderen Schutz und Robustheit zu gewährleisten. Systemsicherheitsverantwortliche sollten die öffentlichen Informationen aufmerksam verfolgen und ihre eigenen Netzwerke zeitnah daraufhin prüfen, um mögliche Angriffsvektoren zu schließen und Risiken zu minimieren. Somit trägt eine kontinuierliche Sicherheitskultur entscheidend dazu bei, Vertrauen in die Infrastruktur und Stabilität der Netzwerke sicherzustellen.
