In der Beschreibung des Angriffs gibt Zdrnya die folgende Abfolge von Aktionen an. Nachdem der Angreifer Zugriff auf den Computer des Opfers erhalten hat, aktiviert er den Entwicklermodus in Google Chrome, sodass er die Erweiterung lokal und nicht über den Store herunterladen kann. Daher wird eine böswillige Erweiterung, die als Plug-In eines Sicherheitsprodukts getarnt ist, in den Browser geladen.
Im Code der Erweiterung selbst beschreibt der Forscher eine Standardmethode für die Interaktion mit der Google Cloud-Infrastruktur, mit der beliebige Daten zwischen zwei Browsern "ausgetauscht" werden können. Das heißt, vermutlich sah der Angriff so aus: Wir hacken uns in den Computer, installieren eine böswillige Erweiterung und autorisieren den Browser unter einem einmaligen Google-Konto. Auf der Seite des Angreifers reicht es aus, sich unter demselben Konto anzumelden, um Daten vom Computer des Opfers abzurufen.
Was genau auf diese Weise übertragen wurde, gibt der Experte nicht bekannt, sondern weist auf die Einschränkungen der Methode hin: Die maximale Größe der über die Google Chrome-Infrastruktur übertragenen "Schlüssel" darf 8 KB nicht überschreiten, und ihre maximale Anzahl beträgt 512. Das heißt, Pro Sitzung können 4 MB Daten übertragen werden ... Dies reicht aus, um einen infizierten Computer zu steuern und Token für den Zugriff auf Cloud-Dienste von Unternehmen zu übertragen.
Zdrnya betont, dass auf dem betroffenen System keine andere schädliche Software vorhanden war. Es wird nicht einfach so funktionieren, den Zugriff auf die Google Cloud-Infrastruktur auf der Ebene der Unternehmensnetzwerkrichtlinien zu blockieren: Nicht nur die Cloud ist an diese gebunden, sondern beispielsweise wird auch die Verfügbarkeit des Netzwerkzugriffs im Browser überprüft. Als Lösung schlägt der Forscher die Anwendung von Richtlinien vor, die die Installation von Erweiterungen im Browser verbieten, mit Ausnahme der in der weißen Liste markierten. Eine solche originelle Methode der Interaktion mit dem angegriffenen System kann lange Zeit ignoriert werden - dies eröffnet Angreifern den Weg zu Unternehmensdaten, auf die unter normalen Bedingungen über einen Browser zugegriffen werden kann. In den meisten Fällen kann dies Unternehmens-E-Mail, Tools für die Zusammenarbeit von Dokumenten und vieles mehr sein.
Was ist sonst noch passiert?
Die Geschichte des Angriffs auf Experten für Informationssicherheit (siehe vorherige Übersicht ) wurde fortgesetzt. Eine Zero-Day-Sicherheitsanfälligkeit in der V8-Engine wurde entdeckt und im Google Chrome-Browser geschlossen . Obwohl die Entwickler von Google dies nicht kommentieren, wird davon ausgegangen, dass die Organisatoren des Angriffs es verwendet haben. Darüber hinaus fanden südkoreanische Experten einen weiteren Vektor des gleichen Angriffs: Den Opfern wurden HTML-Dateien mit bösartigem Code gesendet, die eine zuvor unbekannte Sicherheitsanfälligkeit in Internet Explorer 11 ausnutzten. Die Datei enthielt angeblich Informationen zu einer Sicherheitsanfälligkeit im Google Chrome 85-Browser.
Netscout berichtet unter Berufung auf chinesische Forscher von Baidu Labs über eine neue Methode zur Verstärkung eines DDoS-Angriffs mithilfe eines falsch konfigurierten Plex-Medienservers.
Im Thread unter dem obigen Link spricht ein Forscher unter dem Spitznamen OverSoft über eine schlecht geschützte IP-Videokamera mit einer Personenzählfunktion. Die Geschichte beginnt mit einer unersetzlichen WLAN-Netzwerkkennung und einem Passwort und wird nur noch trauriger. In der Kamera fand ich ein Raspberry Pi Compute Module mit einem Standardbenutzer-Pi, vom Entwickler übrig gebliebenen Dokumenten (einschließlich einer MP3-Datei) und einer Reihe von Python-Code. Das Ergebnis ist ein Gerät, das theoretisch eine Verbindung zu einem Unternehmensnetzwerk mit praktisch ungesichertem WLAN herstellt und die Möglichkeit bietet, vollen Zugriff auf ein Konto mit einem Standardkennwort und maximalen Berechtigungen zu erhalten.
Das Google Project Zero-Team veröffentlichtÜberblick über Zero-Day-Schwachstellen, die im letzten Jahr bei echten Angriffen verwendet wurden. Von den 24 Löchern verwenden acht eine neue Methode, um ein bereits bekanntes Problem auszunutzen. Schlussfolgerung: Es ist möglich, das Leben von Angreifern etwas zu verkomplizieren, wenn Schwachstellen nach einer detaillierten Analyse der Ursache geschlossen werden, sodass das gelöste Problem nicht erneut geöffnet werden kann.
Vor mehr als einem Monat, am 4. Januar, gab es einen großen Fehler im Slack Messenger. Über die Ergebnisse des Vorfalls wurde ein detaillierter Bericht veröffentlicht . Der Rückgang war auf mehrere Gründe zurückzuführen: Am ersten Geschäftstag nach den Feiertagen in den meisten Ländern haben die Benutzer die Infrastruktur mehr als erforderlich geladen, und das Tool zur automatischen Kapazitätsskalierung in Amazon Web Services funktionierte nicht wie erwartet.
Eine Studie der Kobalos-Malware für Linux-Systeme zeigt ein ungewöhnliches Angriffsziel: Supercomputer.
Ein neues Beispiel für einen Angriff auf die Lieferkette: Forscher von ESET fanden infizierte NoxPlayer-Software (Emulation von Android-Anwendungen), die direkt von der Entwickler-Website verteilt wurde.