Zugschlusbeobachtungen

Bei diesem Verfahren installiert man auf den managed systems ein Stück Software, das Agent genannt wird. Diese Software läuft als root, hat damit alle notwendigen (und vermutlich zu viele) Rechte, holt sich die Konfigurationsdaten (in Puppet-Sprache: den Katalog) von einer zentralen Stelle (in Puppet: dem Puppet-Master oder Puppet-Server) und setzt die dort hinterlegten Anweisungen dann auf dem System um. Da das managed system sich die Daten von zentraler Stelle abholt, nennt man dieses Konzept das Pull-Prinzip.

Der große Vorteil des Pull-Prinzips ist, dass man streng genommen keinen interaktiven Zugang auf die managed systems zulassen muss: Alle notwendigen Aktionen können vom Konfigurationsmanagementsystem über den Agenten veranlasst werden. Natürlich wird man auch dann, wenn man das konsequent durchzieht, eine Hintertür auf die managed systems konfigurieren wollen, aber man kann hergehen und jede Nutzung dieser Tür zum erklärungsbedürftigen Incident erklären. Man kann den Zugang passend vernageln, Protokollierungsmechanismen verwenden und ihn generell so unbequem machen, dass die Leute ihn freiwillig nur im Notfall benutzen werden.

Hätte man die Daten, auf deren Basis die Agenten die automatische Konfiguration vornehmen, unter hinreichend enger Kontrolle, kann man mit so einem Schema ein sehr hohes Sicherheitsniveau erreichen. Der Haken an der Geschichte ist, dass man das in aller Regel nicht hat.

Der normale Workflow bei der Arbeit mit einem solchen System ist, dass der Devops-Engineer seine Arbeit auf seinem normalen Arbeitsplatzrechner mit normalen Benutzerrechten macht, diese dann in ein Versionskontrollsystem wie git committed und das Ergebnis dann in ein zentrales Repository pushed, von dem es dann - nicht selten ohne weitere Freigabe - zur Abholung durch die managed systems bereitgestellt wird. Dabei sind auf dem Arbeitsplatzrechner außer dem Zugriff auf das Versionskontrollsystem keine besonderen Rechte notwendig.

Und schwupps, ist das Sicherheitsniveau, was vorhin noch so toll aussah, massiv reduziert: Es reicht, den Arbeitsplatzrechner des Devops-Engineers so weit zu übernehmen, dass mit Benutzerrechten Dateien geschrieben werden können.

Dann hinterlegt der geneigte Angreifer seine "bösen" Konfigurationsdaten in der Working Copy der Versionskontrolle und wartet darauf, dass der Engineer in einem Moment der Unaufmerksamkeit die unerwünschten Informationen zusammen mit seiner Arbeit committed und per push zur Verteilung freigibt. Nutzt der Engineer für diese Freigabe ein durch den ssh-Agent unterstütztes ssh, kann der Angreifer seine "Arbeit" sogar gleich selbst mit den Rechten des Engineers freigeben. Hierfür sind weder auf dem Arbeitsplatzrechner noch auf dem zentralen System besondere Rechte außer der Erlaubnis zum commit und zur Freigabe notwendig; die Privilege Escalation zu root erfolgt in dem Moment, wo die Agenten auf den managed systems die freigegebenen Daten abrufen und die enthaltenen Kommandos ausführen.

Wie schützt man sich gegen diesen Angriff: "Ganz einfach", in dem man die Sicherheit des Devops-Arbeitsplatzrechners entsprechend erhöht. Leider sinkt dabei seine Benutzbarkeit, und treibt man das zu weit, wird sich ein guter Devops- Engineer (inklusive mir) überlegen, ob er sich nicht eine andere Wirkungsstätte sucht. Das Arbeiten mit so einem System hat mit "Spaß am Gerät" ungefähr so viel zu tun wie der Baggersee des Nachbarorts mit dem Pazifik. Um diesen Angriffsvektor spürbar zu reduzieren, darf der Rechner zum sinnvollen, geekkompatiblen Arbeiten inklusive Internetrecherche nicht mehr zu gebrauchen sein.

Möchte man das nicht tun, bleibt Peer Review. Hierbei werden Änderungen nur zugelassen und freigegeben, wenn ein zweites Augenpaar drauf geschaut hat und bestätigt hat, dass die Änderung unschädlich ist. Dank moderner Versionskontrollsysteme kann man die Kontrolle durch das zweite Augenpaar vollständig entkoppeln; effizienter ist aber meiner Meinung nach, dass sich der Autor der Änderung und der Reviewer zusammen an einen Rechner setzen und gemeinsam die Änderungen durchgehen. Ob man unreviewten Code schon in die Test-Pipeline schiebt, muss jede Installation für sich - abhängig davon, inwieweit fehlerhafter oder bösartiger Code schon Schaden in der Test-Pipeline erzeugen kann oder nicht - entscheiden.

Immerhin kann man zwischen "Unfall" und "Super-Unfall" unterscheiden. Beim Unfall, dem Einschleusen von Schadcode über die im Normalbetrieb vom Benutzer verwendete Schnittstelle, ist der Schadcode wenigstens "offiziell" in der Versionskontrolle, so dass sich nachvollziehen lassen dürfte, auf welche Weise er ins System gelangte, wie lange er zur Abholung bereitstand und welche managed systems ihn bekommen haben. Beim "Super-Unfall" ist die zentrale Stelle, von der die Systeme sich ihre Konfigurationsdaten abholen, selbst unter der Kontrolle eines Angreifers, der nun nach Gutdünken entscheiden kann, wann er welchen managed systems welchen Code zur Verfügung gestellt hat, den diese dann gutgläubig ausführen, ohne dass Spuren in der Versionskontrolle entstehen. Ein solcher unerwünschter Zugriff kommt einer Root-Shell auf allen managed systems Systemen gleich.

Und schon ist durch ein bisschen weiter denken der No-Brainer bei der Einführung des Konfigurationsmanagementsystems plötzlich zum Thema der Arbeitsplatz-Security und des Risikomanagements geworden.

Allerdings ringen sich die wenigsten Installationen zur logischen Folge, einem Zwei-Rechner-Konzept für Arbeitsplatzrechner, durch. Durch Remote-Desktop-Techniken wie rdp, xpra oder Citrix lässt sich das Risiko weiter reduzieren; allerdings entstehen hierbei interessante neue Herausforderungen.