text: Privilege Escalation für Konfigurationsmanagement, Teil I | Zugschlusbeobachtungen
  Random Entry: T-Online-"Navigationshilfe" zerstoert Namensaufloesung im Windows-VPN
  < Rheintalbahn voraussichtlich wochenlang unterbrochen | ssh proxycommand, ssh -W, ssh proxyjump >
  Posted by Marc 'Zugschlus' Haber on Sunday, August 27. 2017
  Wenn man sich die Konfiguration seiner Systeme (managed systems) von einem Automaten (Konfigurationsmanagement-System, KMS) abnehmen lassen möchte, muss man ihm dazu die notwendigen Rechte geben. Da beißt die Maus keinen Faden ab.
  Aber was sind die notwendigen Rechte, wie gibt man sie dem Automaten, und welche Implikationen für die Systemsicherheit (im Sinne von security) haben sie?
  In diesem Artikel und seinen weiteren Teilen stelle ich ein paar Methoden vor, versuche ihre Vor- und Nachteile herauszuarbeiten und bitte euch um Kommentare und eure Meinung dazu. Dieser Teil 1 beschäftigt sich mit dem, dem ich eigentlich nur einen Absatz widmen wollte, und aus dem dann ein eigener Artikel geworden ist: Dem Pull-Prinzip mit einem Agenten.
  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.
  Categories: Freie Software | 5 Comments
  Defined tags for this entry: devops, konfiguarationsmanagement, linux, puppet, security, unix
  Andre on Monday, August 28. 2017 :
  Und dann gibts noch Dinge wie Chef, die ihren Code nicht zwingend aus dem Repo beziehen, sondern gesondert bestückt werden.
  In der Versionsverwaltung hat man den Code eigentlich auch nur, um ihn in der Versionsverwaltung zu haben.. Die eigentlichen Kochbücher, Rollen, Nodes und sonstiges lädt man dann noch explizit in den Server ein und zumindest Kochbücher(und damit Rezepte) können und sollten versioniert werden.
  In geeignet disziplinierten Umgebungen kann man dann die Versionen für verschiedene Umgebungen pinnen und so Updates nach und nach ans Produktionssystem heranführen
  Marc 'Zugschlus' Haber on Monday, August 28. 2017 :
  Wobei ich hier den Unterschied nicht sehe: Ein kompromittierter Arbeitsplatzrechner öffnet das Konfigurationsmanagement. Höchstens das Reviewing wird in einer Chef-Umgebung erleichtert.
  Oder verpass ich da was?
  Kristian Köhntopp on Tuesday, August 29. 2017 :
  In meiner Arbeitsumgebung halten wir das so, daß der Laptop des SRE eigentlich nur eine ssh-Ausgangsbasis ist. Technisch gesehen könnte das auch ein Chromebook sein.
  Aller Code liegt in einer VM in der Entwicklungs- und Testumgebung. Von dort wird auch ins puppet.git gepushed. Rollout erfolgt mit einem Rollout-Script und in Stages, erst in das eine Produktionsumgebung an einem Standort, dann Sichtprüfung, dann in eine andere Produktionsumgebung an einem anderen Standort.
  Marc 'Zugschlus' Haber on Tuesday, August 29. 2017 :
  Wenn der SRE auf dem Chromebook Medieninhalte abruft, ist ein erfolgreicher Angreifer auf den Arbeitsplatz trotzdem "drin". Zwar nicht so weit, und das "drin" sein ist für den Angreifer aufwendiger, aber Passworte abgreifen und Bildschirmausgabe sehen kann er dennoch.
  09:47 | Link | Reply
  Das ist okay, den Security Fuzzies hier reicht das als Mitigation.
  ssh-Keys für Zugriff sind 24 Stunden Temp Keys. Man kriegt sie durch Login auf "ssh.firma.com" mit 2FA und Yubikey Neo. Paßwort alleine und auch der fixe SSH-Key nutzen Dir nix, um in Test- oder Prod zu kommen.
  In reply to [ Top level ]#1: Andre on 2017-08-28 14:56 #1.1: Marc 'Zugschlus' Haber on 2017-08-28 15:54 #2: Kristian Köhntopp on 2017-08-29 09:43 #2.1: Marc 'Zugschlus' Haber on 2017-08-29 09:47 #2.1.1: Kristian Köhntopp on 2017-08-29 09:54