Chocolatey for Business ist in vielen Windows-Umgebungen das Rückgrat des Software-Managements. Was passiert, wenn ein bereits verwalteter Client kompromittiert wird? Dieser Frage sind wir nachgegangen.

Von der Praxiserfahrung zur Angreiferperspektive

Die besten Security-Research-Projekte entstehen oft dort, wo tiefes Systemwissen auf konsequentes Angreiterdenken trifft. Genau das war hier der Ausgangspunkt.

Einer der Autoren brachte jahrelange operative Erfahrung mit Chocolatey-for-Business-Umgebungen mit: Planung, Aufbau, produktiver Betrieb. Die internen Kommunikationswege, Vertrauensstellungen und Verwaltungsprozesse des Systems waren damit bereits bekannt. Der zweite Autor brachte die Perspektive des Security Researchers ein.

Wir wollten Chocolatey Central Management (CCM) aus Sicht verschiedener Angreifer betrachten.

Was ist Chocolatey for Business

Chocolatey for Business (C4B) ist eine Plattform für die zentrale Softwareverteilung in Windows-Umgebungen. Die IT entscheidet an einer einzigen zentralen Stelle, welche Software auf welchen Firmenrechnern landet, rollt sie automatisiert aus und hält sie aktuell, ohne jeden Rechner einzeln anfassen zu müssen.

Die zu verwaltenden Rechner werden mit der zentralen Verwaltung verbunden und tauchen anschließend gesammelt im Dashboard auf. Ab diesem Punkt kennt das System jede Maschine und ihren aktuellen Softwarestand.

Das Unternehmen legt fest, welche Software überhaupt freigegeben ist und verteilt werden darf. Diese kuratierte Auswahl bildet den internen Katalog, aus dem später ausgerollt wird.

Aus dem Dashboard wird bestimmt, welche Software auf welche Rechner oder Rechnergruppen soll, und die Verteilung mit wenigen Klicks angestoßen. Die Installation läuft danach automatisch auf den Zielsystemen.

Updates werden auf demselben Weg zentral verteilt. Gleichzeitig zeigt das Dashboard jederzeit, welche Software auf welchen Rechnern installiert ist und wo Aktualisierungen fehlen.

Über diese vier Schritte hinaus deckt C4B den kompletten Lebenszyklus einer Software ab. Nicht mehr benötigte Programme lassen sich auf demselben zentralen Weg wieder von den Rechnern entfernen (Deprovisioning). Und über einen Self-Service-Katalog können Mitarbeitende freigegebene Software bei Bedarf selbst installieren, ohne dass die IT jeden einzelnen Wunsch manuell bearbeiten muss.

C4B stellt einen einzigen zentralen Punkt dar, der bestimmt, welche Software auf sämtlichen Windows-Rechnern eines Unternehmens installiert, ausgeführt und aktualisiert wird. Was C4B für die IT so wertvoll macht, macht es damit zugleich zu einem lohnenden Ziel. Denn wer diese zentrale Stelle kontrolliert, kontrolliert am Ende die gesamte Flotte.

Als Sicherheitsforscher ist genau das der Punkt, an dem es interessant wird.

Ein Blick unter die Motorhaube

Um zu beurteilen, wo ein Angreifer ansetzen könnte, reicht die Vogelperspektive aus dem letzten Abschnitt nicht mehr aus. Wir mussten verstehen, woraus C4B unter der Haube tatsächlich besteht. Welche Komponenten miteinander sprechen, welche Vertrauensbeziehungen zwischen ihnen bestehen und mit welchen Rechten sie arbeiten. Erst dieses Bild erlaubt ein fundiertes Threat Modeling.

C4B ist dabei kein einzelnes Programm, sondern ein Zusammenspiel weniger Komponenten auf drei Ebenen:

• Der Kern steuert die Verteilung und führt sie aus.
• Das erforderliche Umfeld hält die Pakete bereit.
• Die optionale Automatisierung pflegt den Paketbestand.

Wir gehen sie von innen nach außen durch, vom Herzstück bis zum Rand.

Der Kern: Chocolatey Central Management (CCM)

Chocolatey Central Management ist die zentrale Verwaltung und das Herzstück von C4B. Über CCM sieht ein Administrator von einer Oberfläche aus die gesamte Rechnerflotte und weist zu, welche Software auf welche Maschinen soll. Unter der Haube besteht CCM aus drei zusammenspielenden Komponenten:

• Einer Weboberfläche, über die der Administrator arbeitet.
• Einem Dienst, bei dem sich die verwalteten Rechner melden.
• Einer Datenbank, die den Software- und Statusbestand jeder Maschine festhält.

Hier werden Deployment Pläne formuliert, also die Anweisung, was auf welchen Maschinen installiert oder ausgeführt werden soll. CCM greift dabei nicht selbst auf die Rechner zu, sondern erteilt den Auftrag und überlässt die Ausführung einer lokalen Komponente auf dem Zielsystem.

Der Kern auf den Geräten: der Agent

Diese lokale Komponente ist der Chocolatey Agent, ein Dienst, der auf jedem verwalteten Rechner läuft. Er fragt in regelmäßigen Abständen bei CCM nach, ob ein neuer Auftrag vorliegt und führt ihn aus, sobald einer eintrifft.

Zwei Eigenschaften machen ihn zu einem kritischen Punkt in der Kette. Erstens läuft er mit lokalen Administratorrechten, da das Installieren von Software diese voraussetzt. Zweitens ist das, was er ausführt, nicht auf reine Paketinstallationen beschränkt: ein Deployment kann auch beliebige PowerShell-Skripte auf dem Zielrechner ausführen. Der Agent vertraut also dem Auftrag der Zentrale und setzt ihn mit den höchsten Rechten auf dem System um. Wer CCM kontrolliert, kann über diesen Weg beliebigen Code auf jedem angebundenen Rechner ausführen.

Das erforderliche Umfeld: das Repository

Die Pakete selbst liegen nicht in CCM, sondern in einem Repository, einem Paketspeicher, aus dem die Clients ihre Software beziehen. Diese Rolle muss vorhanden sein, ist aber produktneutral: C4B bringt kein eigenes Repository mit, sondern lässt sich in eine bereits vorhandene Lösung einfügen. Wir haben uns an die offizielle Installationsanleitung gehalten, die dafür Nexus vorsieht, eine verbreitete Repository-Software. Hier könnte aber auch eine Software wie Artifactory oder sogar eine einfache Dateifreigabe verwendet werden.

Die optionale Automatisierung: die CI-Pipeline

Bleibt die Frage, wie die Pakete ins Repository gelangen. Software kann aus der öffentlichen Chocolatey Community oder aus anderen Quellen stammen und wird vor der Verteilung ins interne Repository überführt. Diesen Nachschub kann eine CI-Pipeline automatisieren, ein Ablauf, der neue oder aktualisierte Pakete regelmäßig und ohne manuelles Zutun einspielt. Zwingend ist das nicht, C4B beherrscht diesen Schritt auch selbst, aber die offizielle Anleitung sieht dafür Jenkins vor, einen gängigen Automatisierungsserver, und so haben auch wir es umgesetzt.

Welchen Angriff wollten wir zeigen?

Bevor die technische Analyse begann, haben wir uns gefragt, wer dieses System angreifen würde, von wo aus und mit welchem Ziel. Wir sind die Architektur durchgegangen und haben die denkbaren Angreiferpositionen gesammelt, von außen nach innen und mit wachsenden Rechten:

• Externer Angreifer: Kein Zugang zum Firmennetz. Der einzige Weg, auf dem von außen Daten ins System gelangen, sind Pakete aus den konfigurierten Quellen, also ein Supply-Chain-Attack. Eine darüber hinaus exponierte, angreifbare Fläche haben wir nicht gefunden.
• Interner Angreifer ohne Client: Angreifer im Firmennetz, aber ohne übernommenen Endpunkt. Wir haben alle Komponenten des Testaufbaus gescannt und auf Schwachstellen untersucht aber keine gefunden.
• Authentifizierter Benutzer mit eingeschränkten Rechten: Ein gültiges CCM-Konto ohne Admin-Rechte. Diese Position hat etwas zutage gefördert, das später Teil unseres Reports wurde. Als eigenständiges Angreifermodell ist sie aber schwach. Warum sollte ausgerechnet ein niedrig privilegierter CCM-Benutzer der Angreifer sein? Diese Bedrohung entfaltet sich erst zusammen mit einem realistischen Einstiegspunkt.
• Kompromittierter Client: Ein bereits in CCM registrierter Endpunkt wird übernommen. Welche Vertrauensstellungen lassen sich von hier aus missbrauchen? Hier haben wir angesetzt.

Übrig bleibt der kompromittierte Client, und das aus gutem Grund. In unseren Incident-Response-Fällen sind die Einstiegsvektoren immer wieder dieselben: Phishing, Malware, gestohlene Zugangsdaten und Fehlkonfigurationen. Ein realistischer Angreifer verschafft sich selten direkt Administratorrechte, sondern landet zunächst auf einem gewöhnlichen Endpunkt. Genau daran orientiert sich die Annahme, von der wir ausgegangen sind: Gehe davon aus, dass bereits ein Client übernommen ist. Die Frage ist, was der Angreifer von dort aus erreichen kann. Diese Ausgangslage, dass ein Teil des Systems schon in der Hand des Angreifers ist, nennt man Assumed Breach.

Ausschlaggebend war am Ende eine einzige Frage: Was würde ein Nachweis tatsächlich zeigen, und wem hilft er? Der Supply-Chain-Weg wäre denkbar gewesen, hätte aber wenig gebracht. Dass sich über offene Paketquellen Schadcode einschleusen lässt, ist ein bekanntes Grundrisiko jeder Softwareverteilung und nichts, das Chocolatey am eigenen Produkt beheben könnte. Der kompromittierte Client dagegen führt auf eine beantwortbare und behebbare Frage. Das ist für uns der Maßstab guter Sicherheitsforschung, Missstände aufzuzeigen, die sich auch abstellen lassen.

Ein in CCM registrierter Client genießt implizites Vertrauen. Das System kommuniziert mit ihm, verteilt Software an ihn und erwartet Rückmeldungen von ihm. Kein Endpunkt ist aber vertrauenswürdig, nur weil er im Management-System registriert ist. Damit stand die Frage, die unsere Untersuchung geleitet hat: Kann ein Angreifer, der einen solchen Client kontrolliert, dessen Vertrauensstellung gegen die Infrastruktur wenden, gegen den Kern des Systems, gegen CCM?

Die Findings

Bei der Analyse des CCM-Dashboards stießen wir nicht auf einen isolierten Programmierfehler, sondern auf ein durchgängiges Muster.Das Frontend behandelt von außen gelieferte Werte, als wären sie Code, statt als reinen Text. Nutzergesteuerte Zeichenketten werden quer durch die Anwendung als rohes HTML gerendert. Damit lässt sich an vielen Stellen HTML in die Ansicht des Administrators einschleusen, eine sogenannte stored HTML Injection.

Der wirkungsvollste Weg dorthin führt über den Hostnamen, den ein verwalteter Client an CCM meldet. Auf dem Client wird die Datei chocolatey-agent.exe als Hintergrundprozess ausgeführt.

In unserem Aufbau haben wir uns diese Datei mit dnSpy etwas genauer angeschaut. Wir fanden hier die Funktion GetHostName(), welche die Microsoft API verwendet um den Hostname des Clients herauszufinden, auf dem die Software ausgeführt wird. Dieser ermittelte Rechnername wird dann an CCM gemeldet.

Wir haben diese Funktion so verändert (sogenanntes binary patching), dass sie statt des Namens einen anderen String sendet.

Diesen String konnten wir dann so in der Admin Konsole finden.

Als nächstes versuchten wir eine Überschrift (ein H1 HTML-Element)

Und fanden dies als gerendertes HTML in der Admin Konsole wieder.

Dies bedeutet, dass wir HTML als Hostname übertragen können, welches vom Browser des Admins als valides HTML gerendet wird, sobald die entsprechende Ansicht im Dashboard geöffnet wird. Als nächstes versuchten wir einen komplexeren Angriff mit mehr HTML.

Dieser Payload bewirkt, dass beim Betrachter ein gefälschtes Loginfenster im Chocolatey Style angezeigt wird, mit der Behauptung die Sitzung sei abgelaufen.

Gibt der Administrator hier seine Zugangsdaten ein, werden sie an einen Server im Internet geschickt, der sich unter der Kontrolle des Angreifers befindet.

Eine Content Security Policy ist vorhanden und verhindert wirksam, dass eingeschleustes JavaScript ausgeführt wird. Ein klassischer Cross-Site-Scripting-Angriff scheitert an dieser Stelle. Die Policy enthält jedoch keine Vorgabe, wohin Formulare abgeschickt werden dürfen, und diese eine Lücke genügt.

Damit greift genau der Hebel, den wir in der Architektur beschrieben haben. Die Schwachstelle selbst ist von mittlerem Schweregrad, sie erlaubt keine direkte Codeausführung und setzt voraus, dass ein Administrator die manipulierte Ansicht öffnet und im gefälschten Dialog seine Daten eingibt. Doch wer auf diesem Weg die Zugangsdaten eines CCM-Administrators erbeutet, erbt dessen Kontrolle über die Verteilung, und damit über jeden angebundenen Rechner. Ein einzelner kompromittierter Client wendet so die Vertrauensstellung, die ihm das System entgegenbringt, gegen CCM.

Der Angriffsvektor ist dabei kein Zufallsfund an einer Stelle, sondern eine systemische Eigenschaft. Solange von außen gelieferte Werte ungefiltert als HTML dargestellt werden, ist jede Ansicht, die solche Werte anzeigt, ein potenzieller Einschleuspunkt. Der gemeldete Hostname ist der schärfste, aber nicht der einzige.

Wir fanden HTML Injections an verschiedenen anderen Stellen.

In Deployment Plans.

In den Profilen von Usern

Das Problem ist also systemisch.

Responsible Disclosure: Warum wir nicht sofort veröffentlicht haben

Für uns war von Beginn an klar, dass das Ziel nicht die Bloßstellung eines Herstellers ist, sondern ein sichereres Produkt für alle, die es einsetzen. Eine sofortige Veröffentlichung der technischen Details hätte Angreifern einen Vorsprung verschafft. Sie hätten die Lücke ausnutzen können, bevor betroffene Unternehmen überhaupt die Chance auf einen Patch hatten.

Deshalb haben wir den Weg der koordinierten Offenlegung gewählt. Wir haben die Schwachstelle an Chocolatey gemeldet, der Hersteller hat sie bestätigt, und im September wurde mit CCM 0.18.0 ein Fix veröffentlicht. Parallel haben wir für den Befund eine CVE beim MITRE beantragt.

Die Zusammenarbeit mit dem Team von Chocolatey war dabei durchweg professionell und konstruktiv. Reproduzierbarkeit, Risikobewertung und die technische Ursachenanalyse standen im gemeinsamen Fokus. Das ist nicht selbstverständlich und verdient es, erwähnt zu werden.

Wie hätten Betreiber den Angriff verhindern können?

Die naheliegende Frage nach einem Fund wie diesem lautet: „Was hätte eine betroffene Umgebung tun können, um sich zu schützen?“

Wir haben die üblichen Verteidigungslinien durchgespielt, und das Ergebnis ist unbequem.

Zwei-Faktor-Authentifizierung für das Dashboard klingt zunächst nach der offensichtlichen Antwort. CCM bietet sie an, allerdings standardmäßig deaktiviert und derzeit nur als E-Mail-Verifizierung. Gegen genau diese Angriffskette hilft sie kaum. Der zweite Faktor ist nicht phishing-resistent, und dieselbe untergeschobene Anmeldemaske, die Benutzername und Passwort abfragt, kann in einem weiteren Schritt ebenso den per E-Mail zugestellten Code abgreifen. 2FA erhöht die Hürde, aber sie schließt die Lücke nicht.

Ein Intrusion Detection System hätte den Angriff theoretisch bemerken können, etwa an einem auffällig langen, HTML-artigen „Hostnamen“, den ein Client meldet. In der Praxis setzt das aber voraus, dass man bereits weiß, wonach man sucht. Typische Angriffsmuster und Payloads lassen sich mit passenden Signaturen erkennen, das ist jedoch Detektion im Nachhinein, keine Prävention, und es hängt vollständig davon ab, dass die richtigen Regeln vorab existieren.

Der Gedanke, einzuschränken, mit welchen Zielen der CCM-Server kommunizieren darf, führt in die Irre. Die gefälschte Anmeldemaske wird nicht vom Server abgeschickt, sondern vom Browser des Administrators. Der Abfluss der Zugangsdaten verlässt also den Admin-Arbeitsplatz, nicht den CCM-Server. Eine Egress-Beschränkung des Servers greift an der falschen Stelle und verhindert diesen Angriff nicht.

Damit bleibt eine ernüchternde Bilanz. Wirksam verhindern lässt sich der Angriff nur an zwei Stellen. Zum einen durch eine korrekt konfigurierte Content Security Policy mit einer form-action-direktive, die den Abfluss an fremde Ziele unterbindet. Zum anderendurch konsequentes Encoding der von außen gelieferten Werte im Frontend. Beides liegt außerhalb des Einflussbereichs der Betreiber. Es sind Eigenschaften des Produkts, die nur der Hersteller setzen kann. Genau das hat Chocolatey mit dem Patch im September getan.

Die einzige Verteidigungslinie, die tatsächlich in der Hand der Betreiber lag, war die Aufmerksamkeit der Administratoren selbst. Ein unerwarteter „Sitzung abgelaufen“-Dialog, der nach erneuter Anmeldung verlangt, ist genau die Art von Moment, in dem Misstrauen angebracht ist. Darauf allein sollte sich Sicherheit allerdings nie verlassen müssen.

Lessons Learned

Am Ende steht eine Erkenntnis, die über Chocolatey hinausreicht. Ein Management-System ist darauf ausgelegt, seinen verwalteten Systemen zu vertrauen und Aufgaben für sie auszuführen. Dieses Vertrauen ist kein Fehler, sondern der Sinn des Produkts. Zum Problem wird es an der Stelle, an der Daten von einem verwalteten System ungeprüft übernommen werden. Denn sobald ein einzelner Client in der Hand eines Angreifers ist, sind auch die Daten, die er meldet, angreiferkontrolliert. Ein gemeldeter Hostname ist dann kein Rechnername mehr, sondern eine Eingabe des Angreifers.

Diese Denkweise, Daten aus der verwalteten Flotte grundsätzlich als potenziell bösartig zu behandeln, ist die eigentliche Lehre aus diesem Projekt. Sie gilt nicht nur für CCM, sondern für jede Plattform, die zentral Systeme verwaltet.

Timeline

Wie Mint Secure euch unterstützt

Assumed Breach Assessment: Wir simulieren Angriffe durch kompromittierte Systeme und bewerten, welche Auswirkungen eine Erstkompromittierung in eurer Infrastruktur hätte.

Threat Modeling: Systematische Analyse eurer Architektur, Trust Boundaries und Angriffspfade, bevor ein Angreifer sie findet.

Red Team & Pentesting: Von der Angriffssimulation bis zum verwertbaren Bericht zeigen wir, was in eurer Umgebung tatsächlich möglich ist.

Security Research & Responsible Disclosure: Wir untersuchen Produkte und Plattformen auf unbekannte Schwachstellen und begleiten die koordinierte Offenlegung, vom ersten Fund bis zum ausgelieferten Fix, so wie in diesem Projekt.

Sprecht uns an.