Durch laufende Anfragen an den Whatsapp-Server können Angreifer die Verschlüsselung für ein bestimmtes Opfer kurzzeitig um eine Stufe senken – oder es für alle unerreichbar machen (Denial of Service). Wertvoller sind wohl die nebenbei gesammelten Informationen über die Zielperson. Auf der IT-Sicherheitsmesse DEFCON 2025 haben am Sonntag (Ortszeit) die österreichischen Sicherheitsforscher Gabriel Gegenhuber und Maximilian Günther von der Universität Wien ihre Erkenntnisse präsentiert.

Im Zentrum stand dabei ein Sicherheitsmerkmal namens Perfect Forward Secrecy (PFS). Dabei wird – zusätzlich zu länger gültigen Schlüsselpaaren der Gesprächspartner – für jede Nachricht ein eigenes Schlüsselpaar erzeugt. Das soll verhindern, dass mit einem aufgedeckten Schlüssel auch andere Nachrichten entschlüsselt werden können. Das bedeutet allerdings, dass laufend Einmalschlüssel ausgehandelt werden müssen.

Bei asynchroner Kommunikation, wie sie für Whatsapp und Signal typisch ist, sind die Teilnehmer nicht unbedingt gleichzeitig online; in so einem Fall schlägt das direkte Aushandeln eines Schlüsselpaars fehl. Das Signal-Protokoll, das in einer Variante auch Grundlage Whatsapps ist, löst dieses Problem durch vorausschauenden Upload von Einmalschlüsseln auf den Server. Dort können sie jederzeit von Dritten abgerufen werden. Dann werden Nachrichten dreifach Ende-zu-Ende verschlüsselt: mit dem statischen Identitätsschlüsselpaar, dem zirka monatlich ausgetauschten, signierten Vorschlüsselpaar (Prekey) und mit dem PFS-Schlüsselpaar. Nur wer alle drei Schlüssel knackt, kann eine abgefangene Nachricht entschlüsseln.

Die Angriffsmethode

Der von den Österreichern gezeigte Angriff erlaubt, die Verwendung der Einmalschlüssel für alle Whatsapp-Nachrichten einer Sitzung von der ersten Nachricht bis inklusive der ersten Antwort zu verunmöglichen. Diesen Nachrichten fehlt dann die PFS, die Teilnehmer einer Whatsapp-Unterhaltung erhalten darauf aber keinen Hinweis. Der Angreifer muss „nur noch“ die beiden anderen Schlüssel knacken. Die Absenkung des Sicherheitsniveaus ist also moderat.

Die theoretische Möglichkeit wird schon in Anmerkungen zum Signal-Protokoll angesprochen und wurde von den Österreichern erstmals in der Praxis unter Beweis gestellt. Aber das ist aber nicht das Ende der Geschichte.

Die Methode ist erstaunlich simpel: Der Angreifer nutzt einen alternativen Whatsapp-Client und muss die Telefonnummer des Zielkontos kennen. Damit fordert er wiederholt neue PFS-Schlüssel vom Server an. Schickt das Endgerät des Zielkontos nicht schnell genug neue Schlüssel, was insbesondere iPhones und Macs schwerzufallen scheint, ist der Vorrat alsbald erschöpft. Whatsapp hat offenbar keine Beschränkung (Rate Limiting) für solche Schlüsselbestellungen eingebaut. In den Tests der Forscher der Universität Wien und SBA Researchs hat es trotz Abwarten jeder einzelnen Serverantwort nur 40 Sekunden bis zwei Minuten gedauert. Mit parallelen Abfragen durch mehrere Endgeräte geht es sogar in zehn Sekunden.

Außerdem unterscheiden sich die Initialisierungswerte der drei abrufbaren Schlüsselarten je nach Betriebssystem des Zielclients. Das mag bei der Auswahl von Malware für einen gezielten Angriff über einen anderen Kanal helfen.

Das Datenschutzproblem

Erstaunlich viel lässt sich aus der Art und Weise ableiten, wie neue Einmalschlüssel auf dem Server auftauchen. Einfachste Variante: Es tauchen keine neuen Schlüssel auf. Dann ist das jeweilige Endgerät aller Wahrscheinlichkeit nach offline.

Durch wiederholte Schlüsselerschöpfung kann ein Angreifer langfristige, heimliche Beobachtungen anstellen: Ist beispielsweise ein bestimmtes Desktopgerät oder eine bestimmte Browserinstanz regelmäßig zu Bürozeiten online, kann unter Umständen auf den Aufenthaltsort des Zieles geschlossen werden. Umgekehrt lassen neue Schlüssel von einem meist nur Abends oder am Wochenende genutzten Desktoprechner auf den Aufenthalt des überwachten Whatsapp-Users zu Hause schließen.

Tauchen neue Schlüssel auf, lässt sich aus dem Tempo des „Nachladens“ bedingt auf das Endgerätemodell schließen (fingerprinting). In den Tests der Forscher gelang die Schlüsselerschöpfung beispielsweise bei einem Samsung Galaxy A54 mit eingeschaltetem Bildschirm und LTE-Datenverbindung nur bei vier Prozent der Anfragen. Bei iPhones hingegen fast immer (iPhone SE 93%, iPhone 8 zu 88%, iPhone 11 zu 80%). Standby oder WLAN-Anbindung bremsen das Nachladen tendenziell weiter.

Ein Poco X3 über LTE-Mobilfunk mit aktivem Bildschirm schaffte den Schlüsselupload zügig, sodass es nur bei 17 Prozent der Anforderungen zu einer Erschöpfung kam. Im Standby-Modus über WLAN waren die Angreifer hingegen zu 76 Prozent erfolgreich. (In diesem Punkt ähnelt der PFS-Erschöpfungsangriff dem ebenfalls von den beiden Österreichern auf der DEFCON 2025 vorgestellten Angriff mittels heimlicher Zustellbestätigungen auf Whatsapp und Signal, wo ebenfalls device fingerprinting möglich ist.)

Headlamp ist ein Web-User-Interface (UI) für Kubernetes, das unter der Open-Source-Lizenz Apache 2.0 in Version 0.34 bereitsteht. Nun hat das Entwicklungsteam ein Plug-in im Alpha-Status hinzugefügt: AI Assistant. Es erweitert Headlamp um KI-Fähigkeiten und unterstützt dabei mehrere Anbieter wie OpenAI, Anthropic oder Mistral.

Die Features des neuen KI-Assistenten

Headlamp AI Assistant bietet ein Conversational Interface, um mit Kubernetes-Clustern zu interagieren. Der Assistent soll dabei helfen, Ressourcen zu verwalten, Schwierigkeiten zu beheben und komplexe Konfigurationen mittels natürlicher Sprache zu verstehen. Dabei ist AI Assistant kontextbewusst (context-aware), das heißt, es nutzt Informationen über den entsprechenden Cluster, um relevantere und präzisere Antworten zu liefern.

Zu den Funktionen zählen konfigurierbare Tools zum Finetuning der KI-Fähigkeiten, wie direkter Kubernetes-API-Zugriff, ebenso wie eine tiefgreifende Analyse, etwa zum Erkennen von Schwierigkeiten oder dem Interpretieren von Logs. Entwicklerinnen und Entwickler müssen ihre eigenen API-Keys und Endpunkt-Informationen für den Modellanbieter verwenden, was zu entsprechenden Kosten führen kann.

Die unterstützten Anbieter sind:

• OpenAI (GPT-Modelle)
• Azure OpenAI Service
• Anthropic (Claude-Modelle)
• Mistral AI
• Google (Gemini-Modelle)
• lokale Modelle (via Ollama)

Praktischer Einsatz – nicht nur für erfahrene Developer

Wie das Headlamp-Team ausführt, soll der KI-Assistent sowohl erfahrenen Entwicklerinnen und Entwicklern als auch Kubernetes-Neulingen hilfreich zur Seite gehen. Ohne tiefere Kubernetes-Kenntnisse wären Fragen wie „Ist meine Anwendung gesund?“ oder „Wie kann ich das beheben?“ denkbar. Nach solchen oberflächlichen Anfragen könnten tiefergehende zum Beispiel sein: „Liste alle problematischen Pods auf“ oder „Wie kann ich diesen Pod fixen?“. Auch Aktionen kann der KI-Assistent nach Aufforderung und mit entsprechender Berechtigung ausführen, etwa auf Befehl „Starte dieses Deployment neu“.

Diese initiale Alpha-Version des Plug-ins soll bereits hilfreich sein, in Zukunft sollen jedoch weitere Features folgen. Derzeit kann es ausschließlich mit dem Kubernetes-Tool umgehen. Laut dem Headlamp-Team wären auch tiefere Einsichten für GitOps via Flux-Plug-in, Monitoring via Prometheus oder Paketverwaltung via Helm möglich. Auch eine Integration mit dem Model Context Protocol (MCP) steht im Raum.

Weitere Details zum neuen Assistenten liefern der Headlamp-Blog und das Repository auf GitHub.

(mai)

Mut ist im Produktalltag ein Thema, das oft unter der Oberfläche bleibt. Was braucht es, damit Product Owner nicht nur fachlich, sondern auch persönlich Verantwortung übernehmen? Oft sind es die Momente, in denen man spürt, dass etwas gesagt oder getan werden sollte, man sich jedoch zurücknimmt. Die Gründe dafür sind vielfältig und oft tief verankert.

Product Ownership erfordert Mut

Darüber spricht Oliver Winter in dieser Podcastfolge mit Silke Kanes. Sie kennt diese Dynamik aus ihrer Arbeit als Coach und aus ihrer eigenen Produktlaufbahn. Für sie ist Mut kein angenehmes Extra, sondern eine grundlegende Voraussetzung, um in der Rolle wirksam zu sein. Wer Produktverantwortung trägt, muss Entscheidungen treffen, mit Unsicherheit umgehen, Klartext reden und Reibung aushalten. Dafür reicht Methodenwissen nicht aus. Es braucht Selbstreflexion, emotionale Stabilität und Klarheit über die eigene Rolle. Mut beginnt oft dort, wo die Komfortzone endet. Das kann der Moment sein, in dem es unbequem wird, in dem kein Applaus kommt oder man sich angreifbar macht. Genau in diesen Augenblicken entsteht Führung.

Klares Nein statt Ausbrennen

Im Gespräch geht es auch um typische Spannungsfelder im Alltag von Product Ownern. Das passiert zum Beispiel, wenn Teams sich in Details verlieren, wenn Stakeholder drängen oder wenn die eigene Intuition signalisiert, dass etwas nicht passt. Wer in solchen Situationen stumm bleibt, ausweicht oder alles allein trägt, brennt langfristig aus. Mut zeigt sich häufig leise, etwa im klaren Nein zu einer weiteren Priorität, im offenen Gespräch über Zielkonflikte oder darin, Zweifel zu teilen, anstatt ein perfektes Bild zu wahren.

Mut ist kein Einzelkampf

Mut ist jedoch kein Einzelkampf. Silke Kanes beschreibt, wie sehr ein Umfeld mit psychologischer Sicherheit hilft. Ehrliches und unterstützendes Feedback, ein konstruktiver Umgang mit Konflikten und die Möglichkeit, sich weiterzuentwickeln, ohne sofort alles perfekt machen zu müssen, sind entscheidend. Oliver Winter betont, dass Mut Raum braucht, um sichtbar zu werden. Dieser Raum kann in Retrospektiven, in Gesprächen auf Augenhöhe oder in Momenten entstehen, in denen jemand das Unausgesprochene anspricht. Auch Coaches und Führungskräfte brauchen Mut, um Themen offen anzusprechen, Strukturen zu hinterfragen und Product Ownern Rückendeckung zu geben.

Am Ende ist Mut kein fester Wesenszug, sondern ein Muskel. Er wächst durch Übung, durch ehrliche Selbstreflexion und durch die Erfahrung, dass sich Bewegung lohnt. Wer in der Produktarbeit wirklich Verantwortung übernehmen will, kommt an dieser Arbeit nicht vorbei. Genau deshalb lohnt sie sich.

Die aktuelle Ausgabe des Podcasts steht auch im Blog der Produktwerker bereit: „Die Produktwerker: Komfortzone is nich! – Warum Produktmenschen sich mehr (zu)trauen sollten„.

(mai)