Google hat neue Anti-Diebstahlfunktionen für Android vorgestellt. Einige erfordern das neue Android 17, andere funktionieren auch mit älteren Versionen.

Biometrie als zweiter Faktor

Um Langfingern den Gerätediebstahl möglichst unattraktiv zu machen, hat Google hier nachgebessert: Denn ein verlorenes Gerät kostet etwa nicht nur den Wert des Telefons, sondern auch finanzielle Verluste, die durch Betrug entstehen können.

Die neuen Vorkehrungen bauen auf den im Januar 2026 eingeführten Funktionen auf – darunter zusätzliche Einstellungen für die Sperre bei fehlgeschlagener Authentifizierung und einem erweiterten Schutz durch die Identitätsprüfung. Das bedeutet, dass Diebe, die möglicherweise an das Gerätepasswort oder an die PIN gelangt sind, die Geräteortung nicht deaktivieren oder erneut auf das Telefon zugreifen können, wenn Besitzerinnen und Besitzer es als verloren markieren.

Keine neuen WLAN- und Bluetooth-Verbindungen

Laut Google aktiviert das Auslösen von „Als verloren markieren“ ferner zusätzliche Schutzmaßnahmen wie das Ausblenden der Schnelleinstellungen und das Deaktivieren neuer WLAN- und Bluetooth-Verbindungen. Überdies erzwingt das Gerät eine biometrische Authentifizierung zum Entsperren des Geräts – heißt: nur die Eigentümerin oder der Eigentümer des Geräts kann das Gerät etwa mit dem Fingerabdruck entriegeln.

Überdies erklärt Google, dass die neuen Diebstahlschutzfunktionen unter Android 17 standardmäßig aktiviert werden. Dies habe man nach einem erfolgreichen Pilotprojekt in Brasilien entschieden. Zudem erweitert Google in Märkten wie Argentinien, Chile, Kolumbien, Mexiko und Großbritannien diese Schutzmaßnahmen auf alle Geräte mit Android 10 oder höher. Funktionen wie „Remote-Sperre“ und „Diebstahlschutz-Sperre“ seien automatisch aktiviert.

Mit Android 17 will Google Dieben außerdem den Zugriff auf Nutzerdaten erschweren. Auf unterstützten Geräten werde die Anzahl der Versuche, die PIN oder das Passwort zu erraten, deutlich reduziert und zudem längere Wartezeiten zwischen fehlgeschlagenen Versuchen eingeführt. Dies soll verhindern, dass Angreifer sich durch schnelles Ausprobieren Zugang zum gestohlenen Smartphone verschaffen können. Außerdem hat Google Verbesserungen daran vorgenommen, wie der Sperrbildschirm Informationen nach fehlgeschlagenen Versuchen anzeigt, erklärt das Unternehmen.

Um eine mögliche Rückgabe von Geräten zu vereinfachen, könne die IMEI eines Geräts nun über den Sperrbildschirm auf Geräten mit Android 12 oder neuer abgerufen werden. Laut Google können Strafverfolgungsbehörden, Gerätehersteller oder Mobilfunkbetreiber diese eindeutige Gerätekennung nutzen, um die Eigentumsverhältnisse einfach zu überprüfen und das Gerät den rechtmäßigen Besitzern zurückzugeben. Diese Funktion könne jederzeit in den Geräteeinstellungen deaktiviert werden.

(afl)

Microsoft hat Windows mit dem BitLocker eine Laufwerksverschlüsselung verpasst, die auch physischen Angriffen standhalten soll, also auch die Fälle abfangen soll, bei denen etwa Geräte geklaut werden. Immer wieder werden jedoch Schwachstellen bekannt, etwa durch Auslesen der Secrets im TPM des Rechners. Eine weitere aktuell weitreichend funktionierende Variante setzt auf die Windows Recovery Environment (WinRE).

Microsoft selbst hat zuletzt im Mai 2025 mit „BitUnlocker“ derartige Attacken über WinRE dokumentiert – und Updates veröffentlicht, die davor eigentlich schützen sollen. IT-Forscher von Intrinsec haben nun einen Weg entdeckt, mit dem sich der Schutz abermals aushebeln lässt, wieder mittels WinRE. Für die Praxisrelevanz der Angriffe ist wichtig zu wissen: Zum Aushebeln der BitLocker-Verschlüsselung ist physischer Zugriff nötig.

BitUnlocker-Angriffe

Die von Microsoft vorgestellte Angriffskette startet laut der IT-Forscher damit, dass der Boot-Manager das System Deployment Image (SDI) und die darin referenzierte WIM-Datei (Windows Image Format) lädt und die Integrität der WIM prüft. Durch das Hinzufügen einer weiteren WIM im Blob-Table prüft der Boot-Manager die erste WIM-Datei, lädt aber ungeprüft die zweite, die von Angreifern kontrolliert wird. Die zweite WIM enthält ein WinRE-Image, das eine cmd.exe-Datei starten kann, die bei Ausführung Zugriff auf das entschlüsselte BitLocker-Laufwerk ermöglicht. BitLocker wurde im weitreichend eingesetzten Auto-Unlock-Mode beim Start durch die bestandene Prüfung entsperrt (CVE-2025-48804, CVSS 6.8, Risiko „mittel“).

Im Juli 2025 hat Microsoft aktualisierte Boot-Manager verteilt, die das Problem lösen sollen. Der ist mit den PCA-2011- oder CA-2023-Secure-Boot-Zertifikaten signiert. Das nun gefundene Sicherheitsleck besteht darin, dass Secure Boot lediglich das Zertifikat einer Binärdatei prüft, jedoch nicht ihre Version. So lässt sich eine anfällige „bootmgfw.efi“-Datei vor dem Sicherheitsupdate starten, die mit dem PCA-2011-Zertifikat signiert ist – die ist aus Secure-Boot-Sicht genauso gültig wie die gepatchte Fassung.

Die Secure-Boot-Zertifikate lassen sich nicht einfach so zurückziehen, das wird auch gerade bei dem Auslaufen der alten 2011er-Zertifikate sichtbar. Microsoft müht sich redlich, die Zertifikate zu aktualisieren und liefert insbesondere für Admins in Unternehmensnetzen auch reichlich Hilfestellung, damit das Upgrade zügig erfolgen kann. Solange diese aktualisierten Zertifikate nicht verteilt und die veralteten Zertifikate zurückgezogen wurden, ist ein Angriff mit einem veralteten Boot-Manager (Downgrade-Attacke) möglich. Die IT-Forscher stellen auf GitHub auch einen Proof-of-Concept (PoC) bereit, der die Schwachstelle demonstriert. Der Angriff benötigt nur Minuten und kein komplexes Equipment, sondern etwa lediglich einen USB-Stick und physischen Zugriff.

Um den Schutz vor derartigen Angriffen zu verbessern, empfehlen die IT-Sicherheitsforscher, die Funktion der PIN-Abfrage beim Start zu aktivieren – das verhindert die meisten BitLocker-Angriffe. Das sei die einzige Maßnahme, die verlässlich vor diesen Angriffen schütze. Microsoft empfiehlt zudem, den Boot-Manager auf das CA-2023-Zertifikat zu migrieren und das alte PCA-2011-Zertifikat zurückzuziehen. Eine Anleitung von Microsoft aus dem Jahr 2023 erklärt den Vorgang. Das aktiviert demnach auch das Versionstracking mittels Secure Version Number (SVN). Da diese Gegenmaßnahmen etwas umständlich seien, sind sie nicht sehr weit verbreitet.

Dieser Angriff dürfte sich jedoch mit dem Ablaufen der alten PCA-2011-Zertifikate im Oktober 2026 erledigen. Der vorgestellte Angriff zeigt jedoch einmal mehr, dass der Umzug auf die neuen Secure-Boot-Zertifikate rasch erfolgen sollte.

(dmk)

Von Microsoft als „kritisch“ eingestufte Sicherheitslücken bedrohen unter anderem Azure, M365, Office, SharePoint, Windows und Word. In vielen Fällen können Angreifer Schadcode auf Computer schieben und so Systeme vollständig kompromittieren.

Admins sollten sicherstellen, dass die Windows-Update-Funktion aktiv ist und Systeme auf dem aktuellen Stand sind. Andernfalls sind PCs verwundbar. Bislang gibt es keine Berichte, dass Angreifer bereits Schwachstellen ausnutzen.

Kritische Lücken

Am bedrohlichsten gilt eine „kritische“ Lücke (CVE-2026-42826) mit dem höchstmöglichen CVSS Score 10 von 10 in Azure DevOps. An dieser Stelle können Angreifer auf einem nicht näher ausgeführten Weg auf eigentlich geschützte Informationen zugreifen. Microsoft gibt an, die Schwachstelle serverseitig gepatcht zu haben. Admins müssen an dieser Stelle also nichts tun.

Weitere „kritische“ Schwachstellen betreffen unter anderem Azure Managed Instance for Apache Cassandra (CVE-2026-33109), Microsoft Dynamics 365 On-Premises (CVE-2026-42898) und den DNS-Client in Windows (CVE-2026-41096). Im letztgenannten Fall können entfernte Angreifer ohne Authentifizierung über eine präparierte DNS-Anfrage Speicherfehler auslösen, sodass Schadcode auf Computer gelangt. Davon sind verschiedene Windows-11- und Server-Ausgaben betroffen.

Sicherheitslücken aufspüren

An diesem Patchday hat Microsoft insgesamt knapp 140 Sicherheitsprobleme gelöst. In einem Beitrag gibt das Unternehmen an, dass ein Großteil der Schwachstellen mithilfe mehrerer KI-Agenten entdeckt wurde.

Weiterführende Informationen zu den Schwachstellen und bedrohter Software findet man in Microsofts Security Update Guide.

(des)