We’re Tracking the Future of Security

Autor: Osiris

  • F-Droid 2.0 gestaltet die Suche und Aktualisierung quelloffener Android-Apps neu

    F-Droid 2.0 gestaltet die Suche und Aktualisierung quelloffener Android-Apps neu

    F-Droid hat Version 2.0 seines offiziellen Android-Clients veröffentlicht und bezeichnet sie als das umfassendste Anwendungsupdate des Projekts seit zehn Jahren. Die Neugestaltung modernisiert die Art und Weise, wie Nutzer freie und quelloffene Android-Anwendungen entdecken, suchen und pflegen, behält dabei jedoch das Repository-Modell von F-Droid bei.

    Der Client wurde auf Grundlage aktueller Android-Muster neu entwickelt

    Die Benutzeroberfläche konzentriert sich nun auf Entdecken, Suche und Meine Apps. Kategorien sind in den Entdeckungsbereich integriert, während installierte Anwendungen und Aktualisierungen unter Meine Apps zusammengeführt wurden. Nach Angaben des Projekts wurden wichtige Komponenten nach 14 Testversionen mit Kotlin Compose neu geschrieben und bilden damit eine neue Grundlage für die künftige Entwicklung.

    Der Entdeckungsbereich umfasst neu hinzugefügte, kürzlich aktualisierte und häufig heruntergeladene Anwendungen. Auch das Kategoriensystem wurde erweitert, damit sich spezialisierte Werkzeuge wie VPNs, Firewalls und Passwortmanager leichter finden lassen. Laut F-Droid bleibt das Nutzungserlebnis frei von verhaltensbasiertem Tracking.

    Vertrauen in Repositorys erfordert weiterhin eine fundierte Prüfung

    Ein neu gestalteter Client kann die Sichtbarkeit von Aktualisierungen und das Auffinden von Software verbessern. Nutzer und Organisationen sollten jedoch weiterhin Repository-Richtlinien, Signierung, Aktualisierungsrhythmus und Anwendungsberechtigungen prüfen. Für mobile Geräteflotten ist zudem eine klare Regelung für Software erforderlich, die außerhalb eines verwalteten kommerziellen App-Stores installiert wird. SectechMedia behandelt entsprechende Kontrollen in seiner Berichterstattung zur Cybersicherheit.

    Quellen

  • Lokales KI-Modell überarbeitet Credential-Dumper und umgeht im Labortest zwei EDR-Produkte

    Lokales KI-Modell überarbeitet Credential-Dumper und umgeht im Labortest zwei EDR-Produkte

    Ein Sicherheitsforscher berichtet, dass ein unzensiertes lokales KI-Modell ein Windows-Programm zum Auslesen von Anmeldedaten so lange veränderte, bis es ohne Warnmeldungen zweier im Testlabor verfügbarer Endpoint-Detection-and-Response-Produkte ausgeführt wurde. Das Experiment belegt keine universelle Umgehung von EDR-Systemen, veranschaulicht jedoch, wie lokale Modelle ohne dienstseitige Schutzmechanismen die iterative Entwicklung offensiver Werkzeuge beschleunigen können.

    Das Modell veränderte mehrere beobachtbare Verhaltensweisen

    Der Test begann mit einem Tool, das den LSASS-Prozess klonen und einen verschlüsselten Speicherabbild-Dump erstellen sollte. Die ersten Versionen wurden erkannt. Nach Aufforderungen, unauffälliger vorzugehen, änderte das lokale Modell das Verhalten bei der Prozesserzeugung, reduzierte die Zugriffsrechte, fügte zeitliche Variationen ein, änderte die Ausgabepfade und entfernte eingebettete Zeichenfolgen. Der Forscher berichtet, dass der überarbeitete Build anschließend ohne Erkennung durch die beiden getesteten Produkte ausgeführt wurde.

    Das Ergebnis beschränkt sich auf eine Laborumgebung, eine Aufgabe und zwei nicht näher bezeichnete EDR-Plattformen. Daraus sollte nicht verallgemeinernd abgeleitet werden, dass KI jedes Endpoint-Produkt umgehen kann.

    Verteidiger benötigen Validierung auf Verhaltensebene

    Sicherheitsteams sollten Schutzmaßnahmen anhand von Verhaltensweisen beim Zugriff auf Anmeldedaten testen, statt sich ausschließlich auf statische Signaturen zu verlassen. Sinnvolle Schutzebenen umfassen LSASS-Schutz, die Isolierung von Anmeldedaten, die Reduzierung von Berechtigungen, Telemetriedaten zu Prozesszugriffen sowie die Korrelation zwischen Endpoint- und Identitätssystemen. Auch die Governance von Modellen ist relevant, wenn Organisationen lokale KI-Tools zulassen. SectechMedia verfolgt diese Risiken in seiner Berichterstattung zur Cybersicherheit.

    Quellen

  • Brand in einem Wohngebäude in Oakland verletzt vier Menschen und macht rund 70 Bewohner obdachlos

    Brand in einem Wohngebäude in Oakland verletzt vier Menschen und macht rund 70 Bewohner obdachlos

    Bei einem Brand der Alarmstufe drei in einem vierstöckigen Wohngebäude in East Oakland wurden vier Bewohner verletzt und rund 70 Menschen obdachlos. Dies geht aus lokalen Medienberichten hervor, die sich auf Angaben der Feuerwehr stützen. Der Brand brach kurz nach Mitternacht im Häuserblock 5100 der Bancroft Avenue aus. Beim Eintreffen der Einsatzkräfte waren Rauch und Flammen auf allen vier Etagen sichtbar.

    Einsatzkräfte führten während der Eskalation Rettungen durch

    Innerhalb weniger Minuten wurde die Alarmstufe auf drei erhöht; rund 65 Feuerwehrleute waren im Einsatz. Die Einsatzkräfte retteten mehrere Bewohner, während andere das Gebäude selbstständig verließen. Drei Erwachsene und ein neunjähriges Kind wurden wegen Rauchgasvergiftungen und anderer Verletzungen in ein Krankenhaus gebracht. Verletzungen unter den Feuerwehrleuten wurden nicht gemeldet. Der Brand war nach etwas mehr als einer Stunde unter Kontrolle.

    Die Behörden berichteten von erheblichen Schäden. Das Gebäude mit 21 Wohneinheiten wurde als unbewohnbar gesperrt. Mit Unterstützung des Roten Kreuzes wurde eine Notunterbringung organisiert. Zum Zeitpunkt der Berichterstattung wurde die Brandursache noch untersucht.

    Brände in Mehrfamilienhäusern stellen mehrere Schutzmaßnahmen auf die Probe

    Brände in Wohngebäuden stellen gleichzeitig hohe Anforderungen an die Detektion, die Hörbarkeit von Alarmen, geschützte Fluchtwege, die Brandabschnittsbildung und den Zugang für die Feuerwehr. Bei der Auswertung nach dem Ereignis sollte untersucht werden, ob die Alarme jeden bewohnten Bereich erreichten, wie sich der Rauch auf die Ausgänge auswirkte und ob die Erfassung der Bewohner die Rettungsmaßnahmen unterstützte. SectechMedia begleitet diese technischen Themen in seiner Berichterstattung über Brand- und Lebensschutz.

    Quellen

  • US-Senat nimmt landesweites Kennzeichenkameranetz von Flock verstärkt unter die Lupe

    US-Senat nimmt landesweites Kennzeichenkameranetz von Flock verstärkt unter die Lupe

    Das landesweite Netz automatisierter Kennzeichenerkennungskameras von Flock Safety wird von US-Gesetzgebern wegen der Suchpraktiken, des Datenaustauschs und der Rechenschaftspflicht verstärkt unter die Lupe genommen. Bei einer Anhörung eines Unterausschusses des Justizausschusses des Senats kamen Vertreter des Unternehmens, der Strafverfolgungsbehörden und der Bürgerrechtsorganisationen zusammen, um zu erörtern, wie lokal beschaffte Kameras ein wesentlich umfassenderes durchsuchbares Netz bilden können.

    Lokale Kameras können überregionale Suchvorgänge unterstützen

    Flock-Kameras erfassen Fahrzeugkennzeichen und zugehörige Merkmale und machen die Datensätze anschließend entsprechend den Berechtigungen und Aufbewahrungseinstellungen der jeweiligen Behörde durchsuchbar. Das System kann behörden- und gebietsübergreifende Ermittlungen unterstützen, doch diese Reichweite wirft zugleich Fragen dazu auf, wer die Daten durchsuchen darf, welche Zwecke zulässig sind und wie Missbrauch erkannt wird. Senatoren haben nach Berichten über Suchvorgänge, die Behörden- oder Bundesstaatsgrenzen überschritten, Informationen zu den Schutzmaßnahmen angefordert.

    Nach Angaben von Flock umfassen die Kontrollen Auditprotokolle, Zweckangaben, rollenbasierte Berechtigungen sowie Optionen, mit denen Behörden den Datenaustausch beschränken können. Diese Kontrollen hängen jedoch weiterhin von der Konfiguration der Richtlinien, der Überprüfung durch Vorgesetzte und einer wirksamen Reaktion ab, wenn ein Suchvorgang gegen Regeln verstößt.

    Governance muss dem Umfang des Netzes entsprechen

    Behörden, die Kennzeichenerkennungsnetze bewerten, sollten vor der Einführung die zulässigen Nutzungszwecke, die Aufbewahrung, den behördenübergreifenden Zugriff und die Häufigkeit der Auditprüfungen festlegen. Bei der Beschaffung sollten zudem exportierbare Protokolle und ein Verfahren zur Untersuchung von Beschwerden vorgeschrieben werden. Es geht nicht nur um die Genauigkeit der Kameras, sondern darum, ob die Zugriffsregeln auch bei wachsendem Netz durchsetzbar bleiben. SectechMedia begleitet diese Systeme in seiner Berichterstattung zur Perimetersicherheit.

    Quellen

  • Lunex Stealer nutzt anfälligen AMD-Treiber, um Sicherheitstools zu blenden

    Lunex Stealer nutzt anfälligen AMD-Treiber, um Sicherheitstools zu blenden

    Forscher haben eine mehrstufige Windows-Malware-Kette dokumentiert, bei der Lunex Stealer einen legitim signierten, aber anfälligen AMD-Kerneltreiber missbraucht, bevor Browser- und Kryptowährungsdaten erfasst werden. Die Technik ist ein Beispiel für „Bring Your Own Vulnerable Driver“ (BYOVD), bei dem Angreifer einen vertrauenswürdigen Treiber laden, dessen bekannte Schwachstelle Funktionen auf Kernel-Ebene ermöglicht.

    Der Treiber wird zur Schwächung der Überwachung eingesetzt

    Die Angriffskette beginnt mit einer gefälschten Verifizierungsseite und einem schädlichen Installationsprogramm. Dessen Loader nutzt den mit CVE-2023-20598 verbundenen anfälligen Treiber PDFWKRNL.sys, um die von Sicherheitsprodukten verwendeten Callbacks zu beeinträchtigen. Die Produkte können weiterhin ausgeführt werden, verlieren jedoch den Einblick in die nachfolgenden Aktivitäten. Der abschließend eingesetzte Stealer zielt auf Anmeldedaten, Sitzungscookies und Wallet-Informationen aus mehreren Chromium-basierten Browsern ab und kann zur Persistenz sowie für entfernte Dateioperationen eine Native-Messaging-Komponente hinzufügen.

    AMD veröffentlichte 2023 sein ursprüngliches Bulletin zur Treiberschwachstelle. Die aktuelle Kampagne ist relevant, weil sie zeigt, wie ältere Schwachstellen in signierten Treibern mit neueren Techniken zur Malware-Verbreitung und Persistenz kombiniert werden können.

    Treiberkontrollen müssen im Betrieb getestet werden

    Verantwortliche für die Abwehr sollten anfällige Treiber inventarisieren, Herstellerupdates einspielen, die Telemetriedaten zum Laden von Treibern überprüfen und testen, ob Microsofts Sperrliste für anfällige Treiber in ihrer tatsächlichen Windows-Konfiguration aktiv ist. Der Diebstahl von Browser-Anmeldedaten erhöht zudem den Stellenwert phishingresistenter Authentifizierung und eines schnellen Widerrufs von Sitzungen. SectechMedia verfolgt entsprechende Entwicklungen in seiner Berichterstattung zur Cybersicherheit.

    Quellen

  • Asset-Inventar und Konfigurationsmanagement für elektronische Sicherheitssysteme

    Asset-Inventar und Konfigurationsmanagement für elektronische Sicherheitssysteme

    Elektronische Sicherheitsinfrastrukturen wachsen Projekt für Projekt. Kameras, Lesegeräte, Gegensprechanlagen, Sensoren, Rekorder und Gateways werden von unterschiedlichen Auftragnehmern ergänzt und bleiben häufig viele Jahre in Betrieb. Ohne ein verlässliches Inventar können Teams nicht erkennen, welche Komponenten aktualisiert werden müssen, welche von einem veralteten Server abhängen oder welcher Ausfall eine Überwachungslücke erzeugen würde.

    Welche Angaben das Inventar enthalten sollte

    Jeder Datensatz sollte Asset-Typ, Hersteller, Modell, Seriennummer, physischen Standort, zuständige Stelle, Installationsunternehmen, Netzwerkkennungen, Firmware- und Softwareversionen, Supportstatus, Garantie, Speicherort der Konfigurationssicherung und betriebliche Funktion ausweisen. Zusätzlich sollten vorgelagerte Abhängigkeiten bei Stromversorgung und Netzwerk sowie die betrieblichen Folgen eines Ausfalls dokumentiert sein.

    Stabile Kennungen verwenden

    Bezeichnungen wie Kamera 12 werden nach Umbauten schnell mehrdeutig. Eine stabile Asset-Kennung sollte mit dem Gerätedatensatz verbunden bleiben, auch wenn sich Hostname, IP-Adresse oder Anzeigename ändern. Grundrisse, Rackpläne, Wartungstickets und Monitoring-Plattformen sollten dieselbe Kennung verwenden.

    Konfiguration als kontrollierte Information behandeln

    Das Inventar beschreibt, was vorhanden ist; das Konfigurationsmanagement dokumentiert, wie es bestimmungsgemäß arbeiten soll. Für Netzwerkeinstellungen, Benutzerrollen, Aufzeichnungsprofile, Türzeitpläne, Alarmregeln und Integrationen sollten freigegebene Baselines geführt werden. Sensible Exporte müssen verschlüsselt und zugriffsgeschützt sein, da sie Zugangsdaten, Topologie und Sicherheitsabdeckung offenlegen können.

    Erkennen und abgleichen

    Automatisierte Erkennung kann vernetzte Assets auffinden, aktive Scans können jedoch empfindliche Geräte beeinträchtigen. Sichere Erkennungsmethoden sollten mit Switch- und DHCP-Daten, Controller-Exporten und physischer Überprüfung kombiniert werden. Abweichungen zwischen beobachtetem und freigegebenem Zustand sollten eine Prüfaufgabe auslösen und nicht stillschweigend überschrieben werden.

    Installation und Außerbetriebnahme kontrollieren

    Die Qualität des Inventars geht häufig an Projektgrenzen verloren. Vor der Abnahme sollten Installationsunternehmen vollständige Gerätelisten, Firmwarestände, die Übergabe von Zugangsdaten, Lizenzen und geprüfte Konfigurationssicherungen bereitstellen. Bei der Außerbetriebnahme sind Netzwerkzugang, Zertifikate, Cloud-Registrierungen und Monitoring-Regeln zu entfernen; anschließend müssen Entsorgung oder sichere Wiederverwendung dokumentiert werden. Ein physisch entferntes Gerät, dem Software weiterhin vertraut, bleibt ein Risiko.

    Qualität des Inventars messen

    Sinnvolle Kennzahlen sind Geräte ohne Verantwortliche, nicht mehr unterstützte Firmware, fehlende Konfigurationssicherungen, unbekannte Netzwerkstandorte und Datensätze, die nicht fristgerecht geprüft wurden. Ausnahmen sollten nach Standort und Systemverantwortung ausgewertet werden. Eine steigende Asset-Zahl bei gleichbleibender Zahl unbekannter Geräte kann eine Verbesserung darstellen, während ein perfektes Dashboard auf Basis veralteter Daten wertlos ist.

    Inventar mit Lebenszyklusentscheidungen verknüpfen

    Firmware-Hinweise und End-of-Support-Meldungen werden erst dann handlungsrelevant, wenn betroffene Modelle schnell lokalisiert werden können. Dieselben Datensätze unterstützen Inbetriebnahme, Ersatzteilplanung, Lizenzverlängerungen und Ersatzinvestitionen. Bei Änderungen sollte das Inventar außerdem Redundanz- und Wiederherstellungsbeziehungen abbilden, wie sie in der Failover-Planung für Sicherheitsnetzwerke beschrieben werden.

    Mindestprozess für den Betrieb

    1. Eine verantwortliche Stelle für das maßgebliche Inventar benennen.
    2. Aktualisierungen bei Installation, Umzug und Außerbetriebnahme verpflichtend machen.
    3. Automatisierte und physische Nachweise nach einem festgelegten Zeitplan abgleichen.
    4. Nicht unterstützte und aus dem Internet erreichbare Assets zuerst prüfen.
    5. Freigegebene Konfigurationssicherungen aufbewahren und die Wiederherstellung testen.
    6. Nicht identifizierte Geräte und überfällige Prüfungen messen.

    Fazit

    Ein Inventar ist nur dann nützlich, wenn es Entscheidungen unterstützt. Ziel ist nicht die perfekte Tabelle, sondern die Fähigkeit, Risiken zu lokalisieren, Abhängigkeiten zu verstehen und einen bekannten, ordnungsgemäßen Betriebszustand ohne Vermutungen wiederherzustellen.

    Referenzquellen