Da muss ich mal etwas zu loswerden, denn das ist alles banale Theorie, genau so, als ob man seinen Schlüssel im Auto stecken lässt, damit dies jemand fremdes wegfahren kann!
Das sich Microsoft lächelnd über die Einreichung von Akamai hinweggesetzt hat bzw. nicht einmal darauf eingegangen ist, liegt einfach daran, dass diese theoretische Problematik schon seit Einführung von Windows 8 / 8.1 Clients bekannt ist!!
Seitens Akamai dann solch einen Alarm zu schlagen, ohne sich vielleicht vorab mal die entsprechenden Papers anzuschauen, halte ich mal für Stimmungsmache…und ich bin nicht gerade der absolute MS-Fan!
Bei der Installation der Server-Rolle DHCP innerhalb einer Active Directory Domain, wird danach ohne den Konfigurationsassistenten aufzurufen bzw. die Powershell zum Einrichten zu benutzen ein RegistryKey erzeugt:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Ohne jegliche Konfiguration des DHCP wird im Unterschlüssel ein DWORD Wert = 1 eingetragen.
Allerdings kenne ich keinen einzigen Admin, der einen DHCP-Server ohne Einrichtung in die AD packt, so dass dieser noch nicht einmal dem DNS bekannt gemacht wird und auch keine eigene feste IP erhält…!
Eine Konfiguration ist also zwingend notwendig. Beim Durchlauf der Grundkonfiguration, egal ob per Assistent oder per Ablaufplan in der PS, wird bei der Verknüpfung des DHCP und den DNS autom. der DWORD Wert in besagten Unterschlüssel auf den Wert 2 geändert
Damit wäre die ganze Akamai Panik fürn Poppes…!
RegistrationOverwrite weist die folgenden möglichen Werte auf:
- 0 – Kein Überschreiben.
- 1 – Datensätze, die der DNS-Client erstellt, überschreiben Datensätze, die vom DHCP-Server erstellt werden. Dies ist der Standardwert.
- 2 – Datensätze, die der DHCP-Server erstellt, überschreiben Datensätze, die der DNS-Client erstellt).
Man kann sich als gut vorstellen, wieso MS nichts weiter dazu an Akamai gesendet hat 
Und nun komme ich noch zu Punkt 2, da bei Akamai und hier im Artikel, eine Angriffs-Situation (Final zum Spoofing) beschrieben wird, bei der extrem wichtige Infos fehlen bzw. bei der reale Fakten einfach übergangen und nicht genannt werden!!
-
Eine DHCP-Server Rolle, innerhalb einer Active Directory im internen Netzwerk, kann nur auf einem Windows Server installiert / konfiguriert werden. Der Server muss eine bestimmte Vertrauensstellung zur AD und der Domain haben! Um den administrativen Aufwand zu minimieren, hält dieser Server nicht nur die DHCP Rolle, sondern noch viele weitere genutzte Dienste und OUs und wird sehr wahrscheinlich als Domain-Controller (primärer DC) hochgestuft. Je größer das gesaamte Netzwerk, desto mehr DCs werden eingesetzt. Diese müssen in Echtzeit mit dem primären DC eine Replikation eingehen können.
Alle Infos hier, sollen nur klarmachen, wo überhaupt die Rollen / OUs für DHCP / DNS untergebracht sind. -
Wenn wir nun mal theoretisch davon ausgehen, dass die Verwalter der AD, des Netzwerks, gegen alle Regeln und gegen die Vernunft ihren DC aufgesetzt haben, ohne die Konfigurationen von oben. Akamai behauptet nun, dass irgend ein Client dort rumspazieren kann!** Bei Verwendung von Secure Updates werden alle vom Server empfangenen Update-Anfragen authentifiziert und autorisiert** Nun meine Frage dazu: Wo kommt der Client eigentlich her? Wo befand der Client sich direkt während der Anfrage??
-
Rüschtüsch: Er muss sich schon zu diesem Zeitpunkt als authentifizierter Client (Computer-Konto) innerhalb der Active Directory befunden haben. Von außen (Internet) kann er den DHCP normalerweise nicht erreichen, außer mit einem zuvor gehackten VPN-Zugang, SSO, Firewall-Gateway, RDP usw. Dann brauchen wir uns über DNS-Spoofing wohl kaum noch Gedanken machen
Also wird der Client-Computer schon in einer OU registriert und verwaltet sein. Um nun überhaupt die Situation nutzen zu können, müsste ein pöser Pube irgendwie in eine weitere OU (Benutzerkonten etc.) hereinkommen können, um danach den Client manipulativ ausnutzen zu können, also ein fetter Hack mittels Exploit, Shell etc. Dann gibt es wieder keinen Grund mehr, sich den Kopf über Spoofing zu zerbrechen! Von alleine wird der Client zwar eine solche Anfrage stellen können, aber wer will diese dann wie ausnutzen??? Bei einem Hack, wäre ja schon lange eine vollständige Infiltration geglückt…ein nachfolgendes Spoofing entzieht sich irgendwie der Logik!
1 „Gefällt mir“