CleanPress

Kategorie: Security

  • Es ist ein Loch im Schuh…

    Foto: Gia Oris on Unsplash

    In den letzten Tagen geisterte eine Sicherheitslücke durch die Medien, die auf den Namen BootHole getauft wurde und die Katalognummer CVE-2020-10713 erhielt. Dort hieß es beispielsweise, es seien Millionen (potenziell sogar Milliarden) Geräte betroffen und das unter Linux wie unter Windows und auch dann, wenn Secure Boot eingeschaltet sei.

    Wenn das Kind erstmal im Brunnen ist…

    Das ist so weit alles richtig. Was dann aber im Text nur beiläufig erwähnt wird, ist, dass zur Ausnutzung der Lücke Root-Rechte benötigt werden. Hat ein Angreifer aber bereits Root-Rechte, kann er machen, was er möchte.

    GRUB2-Konfiguration manipuliert

    Was war passiert? Die Sicherheitsfirma Eclypsium hatte im April 2020 eine Lücke entdeckt, die über die Manipulation der Konfigurationsdatei grub.cfg des Bootloaders GRUB2 oder generell bei Maschinen mit aktiviertem Secure Boot das Einschleusen von Schadcode ermöglicht. Die technischen Hintergründe vermittelt der Artikel There’S A Hole In The Boot.

    Zwei Hacks notwendig

    Schadcode im Bootprozess ist sehr gefährlich, da sind wir uns einig. Dort installierte Malware wie etwa ein Bootkit kann unter Umständen lange unentdeckt bleiben und ermöglicht uneingeschränkte Kontrolle der befallenen Geräte. Aber wie bereits erwähnt, muss man zur Manipulation der Datei grub.cfg Root-Rechte besitzen, die normalerweise nur durch einen vorausgehenden Hack zu erhalten sind.

    GRUB2 ist meist signiert

    Der Zusammenhang mit Secure Boot entsteht dadurch, dass GRUB2 bei allen großen Distributionen mit Secure Boot signiert ist. Dazu verwenden Distributionen eine kleine Datei, die als Shim bezeichnet wird. Dieser enthält den Code, um den Bootloader zu verifizieren. Dieser Shim wird beim Start gegen die UEFI-CA von Microsoft verifiziert, bevor der Shim den GRUB2-Bootloader lädt und verifiziert.

    Heap-Overflow

    Ist die grub.cfg entsprechend manipuliert, kann per BootHole Code eingeschleust werden, da der Parser in GRUB2 nicht ordnungsgemäß beendet wird, wenn ein Fehler entdeckt wird,
    was zum erzeugen von Pufferüberläufen im Heap-Datenbereich genutzt werden kann. Ein Angreifer kann dadurch bereits vor dem eigentlichen Start des Systems Code ausführen. auf diesem Weg kann beispielsweise Ransomware untergeschoben werden.

    8,2 von 10

    Das ist zweifelsohne eine gefährliche Lücke, die deshalb auch mit 8.2 von 10 möglichen Punkten beim CVSS-Index bewertet wurde. Die Angaben zur tatsächlichen Gefährdung sind aber nach meinem Dafürhalten mal wieder weit übertrieben und kommen mit markigen Überschriften dem Marketing von Eclypsium zugute.

    Weitere Lücken entdeckt

    Aber die Beschäftigung von allen großen Distributoren mit dem Problem förderte weitere sieben Sicherheitsprobleme bei GRUB2 ans Licht, die gleich mit beseitigt werden konnten. Angepasste Versionen von GRUB2 sind teilweise bereits erstellt und in Kürze einspielbar.

    Lücke gefährlich – Gefährdung gering

    Wir müssen uns wegen BootHole um unsere privaten Rechner wohl kaum Sorgen machen, denn zwei notwendige Attacken erscheinen hier nicht lohnenswert. Cyber-Gangster kennen weniger aufwendige Wege, unsere Rechner in ihre Botnetze zu integrieren. Rechner mit sensiblen Informationen im Enterprise-Umfeld sollten über geeignete Maßnahmen wie TPM oder PureBoot den Bootprozess absichern. Oder seht ihr das anders?

  • Network Security Toolkit neu aufgelegt

    Foto: Markus Spiske on Unsplash

    Die auf Fedora basierende Linux-Distribution Network Security Toolkit (NST) wurde auf Version 32 aktualisiert, eine Hauptversion, die neue Funktionen und Verbesserungen einführt. Damit einher geht ein Update auf das aktuelle Fedora 32 und Kernel 5.6.15.

    Mit NST Netzwerke live scannen

    Das Network Security Toolkit ist eine Live-Distribution, die eine Reihe quelloffener Sicherheits- und Netzwerk-Tools zur Durchführung routinemäßiger Diagnosen und Überwachungsaufgaben zur Verfügung stellt. Die Distribution sich besonders für Netzwerksicherheitsanalyse-, Validierungs- und Überwachungswerkzeug auf Servern, die virtuelle Maschinen hosten. Zusätzlich zu Fedora als Unterbau verfügt NST über ein eigenes Repository mit zusätzlichen Paketen.

    Verbesserungen des Interface

    NST 32 SVN:11992, wie das neue Release offiziell betitelt ist, bietet ein überarbeitetes NST WUI mit einigen neuen Sparten und Funktionen. Bei WUI handelt es sich um die Benutzerschnittstelle von NST. Eine der neuen Sparten erlaubt die Darstellung von Statistiken von Wireshark, TShark und Kismet. Die Ergebnisse können weiter mit den NST Network Tools Widgets untersucht werden.

    Darüber hinaus wird Dirble unterstützt, ein Tool zum Scannen und Scrapen von Webseiten für Windows und Linux. Weitere neue Sparten in NST WUI werden für Intels AMT Management Console sowie für das JavaScript-Tool Cropper.js angeboten.

    Unterstützung für Pen-Tests

    Das webbasierte Interface unterstützt jetzt die auch bei Kali Linux zu findende Anwendung The Harvester die bei Penetrationstests hilft, die Bedrohungslage eines Unternehmens im Internet zu bestimmen. Das Tool sammelt dazu E-Mails, Namen, Subdomains, IPs und URLs aus einer Vielzahl öffentlicher Datenquellen.

    Network Security Toolkit 32 kann von der Webseite des Projekts heruntergeladen werden. Weitere Einzelheiten verraten die Release Notes.

  • Russland sperrt Mail-Provider

    Photo by Dele Oke on Unsplash

    Die russische Telekommunikationsbehörde Roskomnadsor sperrt derzeit im Auftrag des Geheimdienstes FSB ausländische Mail-Provider. Roskomnadsor unterstehen im Rahmen der Presseaufsicht unter anderem die Ressorts Informationstechnologie und Massenmedien.

    ProtonMail bereits gesperrt

    Jetzt sind mehrere Mail-Provider, bei denen die Sicherheit der Kommunikation im Vordergrund steht, von der Sperrung bedroht. So berichtete ProtonMail gestern von Sperrungen ihres Dienstes innerhalb Russlands. Betroffen sind Nutzer von ProtonMail und ProtonVPN, die zum Zeitpunkt der Sperrung nicht eingeloggt waren. ProtonMail rät als erste Maßnahme zum Verwenden des Tor-Browsers zum Umgehen der Sperre.

    Nun auch mailbox.org bedroht

    Heute vermeldet auch der deutsche Mail-Provider mailbox.org in einem Blogeintrag, von der Sperrung bedroht zu sein. Auch bei dem von Peer Heinlein in Berlin gegründeten Mail-Versender stehen Sicherheit und Schutz der Privatsphäre im Vordergrund.

    Registrierungspflicht

    Bereits im September 2019 wurde die geplante Sperrung bekannt. Der Vorwurf lautet, der Provider habe auf eine Auskunftsanfrage im 2. Quartal 2019 nicht reagiert und sei nicht im russischen Telekommunikationsverzeichnis „ARI“ eingetragen. Anlass sollen über bestimmte Provider versandte E-Mails mit Bombendrohungen sein.

    Keine Anfrage bekannt

    Peer Heinlein sagte damals, ihm sei »keine Anfrage von Roskomnadsor bekannt«. Am 29. Dezember 2019 hat Roskomnadsor vor einem Gericht in Moskau die Sperrverfügung beantragt. Der Berliner Provider wird sich beim am 5. Februar anstehenden Prozess anwaltlich vertreten lassen um »für eine freie, sichere Kommunikation einzutreten«.

    Heinlein tritt mit seinem Unternehmen gegen diese Art von Zensur ein und äußerte sich im September zu einem Workaround:

    Dieser Vorfall zeigt einmal mehr, wie wichtig freie Kommunikationsstrukturen wie das weltweite TOR-Netzwerk sind. Dieses ermöglicht Anwendern auch in totalitären und überwachenden Staaten die sichere Teilnahme am Internet und der freien Kommunikation. Aus diesem Grunde betreibt mailbox.org zur sicheren Kommunikation eigene TOR-Server und ist auch über die sogenannten TOR-Onion-Adressen weltweit erreichbar.

  • NSA gibt Hacker-Tool als Open Source frei

    Der US-amerikanische Geheimdienst NSA hat auf seiner derzeit abgehaltenen Jahreskonferenz RSA Conference 2019 die Freigabe des Hacker-Tools GHIDRA als Open Source bekannt gegeben

    Binärpakete analysieren

    GHIDRA ist ein Java-basiertes Reverse-Engineering-Framework mit einer grafischen Benutzeroberfläche (GUI), das für die Ausführung auf einer Vielzahl von Plattformen wie Linux, Windows und macOS entwickelt wurde. Das Framework enthält eine Reihe mächtiger High-End-Softwareanalyse-Tools, die es Anwendern ermöglichen, kompilierten Code zu analysieren.

    Gut oder böse?

    Offiziell setzt die NSA das selbst entwickelte Software-Reverse-Engineering-Tool bereits seit über einem Jahrzehnt intern ein, um Sicherheitsprobleme in Software zu beheben. Genausogut kann das Werkzeug aber auch dazu dienen, Backdoors in Binärsoftware zu platzieren.

    Keine Backdoor!

    Bei der Vorstellung des Werkzeugs auf der RSA betonte Rob Joyce, Referent für Cybersicherheit bei der NSA, GHIDRA habe keine Backdoor: »Dies ist die letzte Community, in die du etwas mit einer installierten Hintertür freigeben möchtest, für Leute, die nach diesem Zeug suchen, um es auseinanderzunehmen.«

    Keine Backdoor?

    Der britische Sicherheitsforscher Matthew Hickey vom Unternehmen Hacker House fand laut The Register einen zunächst verdächtigen Port, wenn das Tool im Debug-Modus läuft. Dann öffnet es den Port 18001 für das lokale Netzwerk und akzeptiert und führt Remote-Befehle von jeder Maschine aus, die sich verbinden dahin kann. Der Debug-Modus ist standardmäßig aber nicht aktiviert und kann auch auf Verbindungen des Host-Rechners beschränkt werden. Also eher keine Backdoor.

    Reverse-Enginiering-Tools

    Zu den Funktionen gehören Disassemblierung, Montage, Dekompilierung, und Skripting sowie Hunderte von weiteren Funktionen. GHIDRA unterstützt eine Vielzahl von Prozessanweisungen und ausführbaren Formaten und kann sowohl im interaktiven als auch im automatisierten Modus ausgeführt werden. Benutzer können auch ihre eigenen GHIDRA-Plugins oder Skripte mit Java oder Python entwickeln.

    InfoSec-Community hoch erfreut

    Die InfoSec-Community wartete bereits seit der ersten Ankündigung im Januar auf das mächtige Werkzeug zum Aufspüren von Viren und Malware, das nun in Version 9.0 auf der Webseite des Projekts zur Verfügung steht. Bisher standen in dieser Qualität lediglich teure kommerzielle Werkzeuge wie IDA-Pro, Radare, Capstone oder Hopper zur Verfügung.

    GHIDRA soll in nächster Zeit komplett auf GitHub zur Verfügung stehen, eine Installallationsanleitung steht auf der Projektseite bereit.

  • Hybrid-Trojaner bedroht Linux

    Hybrid-Trojaner
    Foto: Markus Spiske auf Unsplash

    Die Zeiten, in denen Linux nicht interessant für Viren und Trojaner war, scheinen vorbei. Der Hybrid-Trojaner Linux.BtcMine.174 bedroht Linux-Installationen gleich auf mehreren Ebenen. Neben Monero-Crypto-Mining tritt er als Keylogger auf, kann Passwörter stehlen, ein Rootkit installieren und DDoS-Attacken fahren.

    Schädlinge nachgeladen

    Entdeckt wurde Linux.BtcMine.174 von den russischen Sicherheitsforschern des Antivirus-Herstellers Dr. Web. Die Forscher stellten fest, dass nach der Infektion über die Server der Cyber-Kriminellen verschiedene weitere Schad-Software nachgeladen wird. 

    Crypto-Währung minen

    Der Trojaner ist ein Shell-Script mit rund 1.000 Zeilen. Hauptaufgabe des Schädlings ist das Mining der Crypto-Währung Monero auf den befallenen Rechnern.  Nach der Infektion, bei der versucht wird, das Script in ein Verzeichnis mit Schreib- und Leserechten zu installieren prüft es zunächst, ob der Server der Trojaner-Entwickler erreichbar ist, um zusätzliche Module nachladen zu können.

    Die schmutzige Kuh herausgeholt

    Reichen die bei der Infektion erlangten Rechte nicht aus, versucht die Schad-Software, die beiden bereits seit Jahren geschlossenen Sicherheitslücken CVE-2013-2094 und CVE-2016-5195, auch als Dirty Cow bekannt, auszunutzen, um höhere Rechte zu erlangen.

    Nach der Installation des Monero-Miners prüft das Script den Rechner auf das Vorhandensein weiterer Mining-Software, um diese zu deaktivieren. Dann wird der Bill Gates Trojaner (PDF) nachgeladen, der DDoS-Attacken mit einem selbst erstellten Botnet durchführen kann.

    Rootkit inklusive

    Laut Dr.Web fügt sich der Trojaner dann als Autorun-Eintrag in Dateien wie /etc/rc.local, /etc/rc.d/.. und /etc/cron.hourly ein und lädt anschließend ein Rootkit herunter und startet es. Das Rootkit hat unter anderem die Fähigkeit, benutzerdefinierte Passwörter für den su-Befehl zu entwenden und Dateien im Dateisystem, in Netzwerkverbindungen und laufenden Prozessen zu verstecken.

    Weiterverbreitet

    Doch damit noch nicht genug, der Trojaner versucht, weitere Rechner zu infizieren und sammelt dazu Informationen über alle entfernten Server, die der infizierte Rechner per SSH kontaktiert hat. Dann werden, wenn möglich, die zugehörigen Anmeldeinformationen gestohlen. Daher vermuten die Forscher, dass die Weiterverbreitung per SSH der Hautptverteilungsweg des Trojaners ist. 

    Derzeit wenig Gefahr

    Insgesamt wird die Gefahr die von diesem Trojaner ausgeht, derzeit von Fachleuten trotzt seiner Komplexität als relativ gering angesehen. In letzter Zeit werden häufiger Schadsoftware und Sicherheitslücken aus unterschiedlichen Gründen hochgespielt. Hier könnte es der Wunsch von Dr. Web sein, seinen Absatz von Antivuren-Software zu erhöhen. Die Hashes zur Überprüfung, ob eine Infektion vorliegt, finden sich jedenfalls auf GitHub. Ein aktueller Kernel der Reihe 4.19 reicht aber bereits zur Abwehr aus.

  • PortSmash: Erneut Sicherheitslücke bei Intel

    PortSmash
    Bild: Hacker | Quelle: The Presier Project | Lizenz: CC BY 2.0

     

    Forscher an Universitäten in Finnland und Kuba haben unter der Leitung von Billy Brumley eine neue Sicherheitslücke entdeckt, die auf den Namen PortSmash getauft wurde. Die neue Lücke ist, wie auch schon Meltdown und Spectre zu Jahresbeginn, eine Seitenkanalattacke.

    PortSmash erlaubt es einem versierten Angreifer, verschlüsselte Daten wie etwa kryptografische Schlüssel oder andere privilegierte Informationen von internen CPU-Prozessen auszulesen. Die Lücke wurde bisher für CPUs der Baureihen Skylake und Kaby Lake bestätigt. PortSmash ist zudem das erste Ergebnis einer auf fünf Jahre ausgelegten Forschungsreihe in Sachen Seitenkanalattacken, die vom Europäischen Forschungsrat finanziell ausgestattet ist.

    Seitenkanalattacke

    Eine Seitenkanalattacke stellt eine Technik dar, die verwendet wird, um verschlüsselte Daten aus dem Speicher oder der CPU eines Computers auszulesen. Von den verschiedenen Formen der Seitenkanalattacke bedient sich PortSmash der Timing Attack.

    Dazu werden minimale Diskrepanzen bei den Laufzeiten eines Algorithmus, des Energieverbrauchs des Prozessors während der Berechnungen oder der elektromagnetischen Ausstrahlung beobachtet und analysiert, um zusätzliche Informationen zu erhalten, die helfen können, Verschlüsselungsalgorithmen zu brechen und die verarbeiteten Daten der CPU wiederherzustellen.

    Hyper-Threading ermöglicht Angriff

    Anders als Meltdown und Spectre nutzt PortSmash nicht das Speicher-Subsystem oder die Caching-Mechanismen der CPUs aus. Die Forscher fanden heraus, dass PortSmash CPUs betrifft, die die SMT-Architektur verwenden, die es ermöglicht, mehrere Threads in der Form von Multithreading gleichzeitig auf einem CPU-Kern auszuführen. Intel setzt  SMT als Hyper-Threading (HT) um.

    PoC auf GitHub

    Gelingt es einem Angreifer, einen präparierten Prozess im Rahmen von SMT neben einem legitimen Prozess laufen zu lassen, so kann er kleine Mengen an Daten des legitimen Prozesses auslesen, die dann bei der Rekonstruktion der verschlüsselten Daten hilfreich sein können. Ein Proof-of-Concept (PoC) des keinesfalls trivialen Angriffs ist von den Forschern auf GitHub eingestellt worden. Dabei werden OpenSSL-Schlüssel von einem TLS-Server entwendet. Ein ausführliches Papier soll in den nächsten Tagen folgen.

    Intel arbeitet an Patch

    Intel ist die Lücke vor rund einem Monat bekannt gemacht worden, bisher liegt noch kein Patch dagegen vor. Intel teilte gestern abwiegelnd mit, die Lücke habe nichts mit Spectre, Meltdown oder L1 Terminal Fault gemeinsam. Man werde weiter »mit Kunden, Partnern und Forschern zusammenarbeiten, um die identifizierten Schwachstellen zu verstehen und zu beheben«.

    Vermutlich auch AMD betroffen

    Die Forscher gehen davon aus, dass auch CPUs von AMD, die SMT verwenden, von PortSmash betroffen sind. Bereits letztes Jahr war mit TLBleed eine ähnliche Lücke entdeckt worden, die ebenfalls HT ausnutzt und die das OpenBSD-Projekt veranlasste, die Unterstützung für Intels HT-Technologie in ihren Kerneln zu deaktivieren.

     

  • Nextcloud kooperiert mit HackerOne

    Nextcloud kooperiert mit HackerOne

    Nextcloud kooperiert mit HackerOne
    Quelle: Nextcloud
      Sicherheit ist in einem Unternehmen wie Nextcloud, das in Europa die sensitiven Datenbestände seiner Kunden mit einer cloudbasierten Open-Source-Softwearelösung absichert, nicht erst seit dem Inkrafttreten der DSGVO das A und O. In diesem Sinne setzt Nextcloud, die Client-Server-Software für File-Hosting unter eigener Kontrolle, bereits seit 2016 auf die Zusammenarbeit mit der Bug-Bounty-Plattform HackerOne.

    Mehr Augen sehen mehr

    Dahinter steht die Erkenntnis, dass ein Team von über 100 qualifizierten Hackern Probleme früher entdeckt und schnellere Lösungen  für Sicherheitsprobleme anbieten kann als die im Unternehmen angestellten Sicherheitsexperten eines kleinen Teams. In der Praxis sieht das so aus, das die Hacker prämienbasiert für die Entdeckung und Behebung von im Bounty-Programm definierten Sicherheitslücken entlohnt werden.

    »Given enough eyeballs, all bugs are shallow« – Linus Torvalds

    Damit kann Nextcloud bei Sicherheitsproblemen eine Reaktionszeit von unter einer Stunde aufweisen, kann aber andererseits das Budget schonen, indem Sicherheitsexpertise »on demand« zugekauft wird. Diese Lösung hat bereits zur Behebung von rund 120 spezifischen Sicherheitsproblemen beigetragen. Dafür hat Nextcloud rund 8.500 US-Dollar Prämien gezahlt, deren Höhe im Durchschnitt bei 100 – 150 US-Dollar lagen und deren höchste 750 US-Dollar betrug.

    Illustre Kundschaft

    Viele großen Unternehmen wie General Motors, Google, Twitter, GitHub, aber auch mit Regierungsstellen wie das US-Verteidigungsministerium arbeiten mit HackerOne zusammen. Dabei konnten bisher über 72.000 Schwachstellen behoben werden, wobei mehr als 32 Millionen US-Dollar an Prämien gezahlt wurden.

    »We might not be a 1,000-person company but we have expertise that challenges companies many times our size and this is one way it shows.« – Jos Poortvliet, Head of Marketing

    Jetzt hat Nextcloud zusammen mit HackerOne eine Fallstudie veröffentlicht, die die Zusammenarbeit zwischen dem kleinen Sicherheitsteam bei Nextcloud und den Experten bei HackerOne detailliert.

    Nextcloud-Konferenz 2018

    Nextcloud wird unter anderem die Ergebnisse des letztjährigen HackerOne-Programms auf der heute beginnenden Nextcloud-Konferenz  am 25. August 2018 an der Technischen Universität in Berlin vorstellen. Durch das Bug-Bounty-Programm mit HackerOne schützt Nextcloud nicht nur seine Kunden, sondern auch das Unternehmen selbst im Fall von gerichtlichen Auseinandersetzungen in Sachen DSGVO. Die Zusammenarbeit ist ein guter Beleg dafür, dass Nextcloud seine Möglichkeiten voll ausgeschöpft hat.

  • Chrome 67 verstärkt die Sicherheit mit Seiten-Isolierung

    Chrome 67
    Bild: google_chrome | Quelle jibunkaiwai | Lizenz: CC BY 2.0

     

    Mit Chrome 67 dreht Google weiter an der Sicherheitsschraube. Das neueste Feature im Kampf gegen Spectre & Co. heißt Site Isolation, zu deutsch Seiten-Isolierung. Mit der Sicherheit erhöht sich allerdings auch der RAM-Bedarf des Browsers.

    Verschärfte Trennung

    Mit Site Isolation verschärft Google die Trennung von Inhalten im Browser. Galt bisher die Maxime, dass jeder Tab in einem eigenen Prozess läuft, so verfeinert Google nun diese Aufteilung weiter. Mit der bisherigen Lösung liefen etwa Cross-Site-Iframes oder -Pop-Ups im gleichen Prozess wie die Seite, die sie erzeugt hatte. Das erlaubte einem erfolgreichen Spectre-Angriff unter Umständen, Daten wie unter anderem Cookies oder Passwörter anderer Frames oder Pop-ups zu lesen.

    Spectre-Angriffe erschweren

    An Site Isolation arbeitete Google schon lange, bevor die Spectre-Angriffe Furore machten. Dabei geht es um eine einschneidende Änderung der Chrome-Architektur, die jeden Rendering-Prozess auf Dokumente von einer einzigen Seite beschränkt. Dies bedeutet, dass alle Navigation zu Cross-Site-Inhalten den jeweiligen Tab zum Wechseln der Prozesse veranlasst. Es bedeutet auch, dass alle Cross-Site-Iframes in einen anderen Prozess als ihr übergeordnetes Frame gesetzt werden, indem out-of-process iframes verwendet werden.

    Site Isolation für (fast) alle

    Mit Chrome 67 ist Site Isolation für 99 Prozent der Nutzer auf allen Betriebssystemen aktiviert, das verbleibende eine Prozent dient als Kontrollgruppe. Mit der Aktivierung reduziert sich die Datenmenge, die ein Angreifer stehlen könnte, und »reduziert die Bedrohung durch Spectre erheblich«, so Google.

    Kehrseite der Medaille

    Google plant, die Site Isolation auf Chrome für Android auszudehnen und arbeitet an der Lösung bekannter Probleme. Mit Chrome 68 kann die Seiten-Isolierung sowohl manuell auf dem Handy über ein Flag als auch über Unternehmensrichtlinien aktiviert werden. Wie so oft, hat aber auch diese Verbesserung einen Pferdefuß: Dadurch, dass mehr Rendering-Prozesse erzeugt werden, erhöht sich der RAM-Verbrauch des beliebtesten Browsers weiter. Google-Entwickler Charlie Reis führte das im Sicherheitsblog des Unternehmens aus:

    Site Isolation führt dazu, dass Chrome mehr Rendering-Prozesse erstellt, was mit Leistungseinbußen verbunden ist: Auf der positiven Seite ist jeder Rendering-Prozess kleiner, kurzlebiger und hat intern weniger Konkurrenz, aber es gibt aufgrund der größeren Anzahl von Prozessen etwa 10-13 Prozent Gesamtspeicher-Overhead in realen Workloads. Unser Team arbeitet weiterhin hart daran, dieses Verhalten zu optimieren, um Chrome schnell und sicher zu halten.

  • Ubuntu-Fehler: Sperrbildschirm kann umgangen werden

    Ubuntu-Fehler
    Bild: Security | Quelle GotCredit | Lizenz: CC BY-2.0

     

    Hacker können Zugriff auf laufende Anwendungen auf einem Ubuntu-Rechner erhalten, wenn Sie physischen Zugriff auf dessen Festplatte haben. Dieser bereits am 18. Juni gemeldete und erst  jetzt bekannt gewordene Ubuntu-Fehler betrifft alle Versionen seit Ubuntu 14.04 LTS »Trusty Tahr«.

    Vermutlich sind aber auch die Derivate der Ubuntu-Familie (bestätigt für 18.04 MATE) als auch Ableger wie Linux Mint und andere betroffen. Dabei besteht Zugriff auf offene Anwendungen des Anwenders, bevor dieser das Gerät in den Ruhemodus schickt.

    Kritischer Ubuntu-Fehler

    Wenn der Angreifer die Festplatte, auf der sich die Installation befindet, während des Ruhemodus (suspend) entfernt und dann das Gerät aufweckt, gibt es mehrere Möglichkeiten: Der Sperrbildschirm erscheint und die Eingabe eines beliebigen Passworts erlaubt den Zugriff. Wenn das beliebige Passwort nicht angenommen wird, kann der Ausschaltknopf der Hardware betätigt und dadurch der Zugriff erreicht werden. Bleibt der Bildschirm dunkel, kann der Vorgang, beginnend mit dem Ruhemodus des Rechners wiederholt werden.

    Die erste Stellungname eines Canonical-Security-Ingenieurs liest sich nicht gerade beruhigend:

    [su_quote style=“modern-light“ cite=“Marc Deslauriers“]Es ist unwahrscheinlich, dass wir dies beheben werden, da ein Angreifer mit einem physischen Zugriff einfach direkt auf die Festplatte zugreifen oder das Passwort auf der Festplatte ersetzen und den Computer entsperren kann.[/su_quote]

    Auch wenn dies so richtig ist, das Entfernen der Festplatte eines Rechners erfordert lediglich mechanisches Geschick und kein Wissen wie man das Passwort ersetzt. Es ist ein einfach klingender Hack und er funktioniert, indem er einen Fehler in der Art und Weise ausnutzt, wie das System Daten speichert, wenn Ubuntu im Ruhezustand ist.

    Ein weiterer in diesem Zusammenhang aufgetauchter Fehler erlaubt manchmal das Umgehen des Sperrbildschirms durch Anschließen eines HDMI-Monitors, sobald der Sperrbildschirm auftaucht.

    AMD-Microcode zurückgezogen

    Erst gestern wurde ein anderes Sicherheitsproblem bei Ubuntu 14.04 LTS »Trusty Tahr« beseitigt, indem der vorherige unsichere Zustand wieder hergestellt wurde. Der am 20. Juni ausgelieferte AMD-Microcode musste zurückgezogen werden, da er durch eine Regression vereinzelt den Bootvorgang von Rechnern unterbrach und diese somit nutzlos machte.

    Der AMD-Microcode sollte eigentlich den Auswirkungen der Anfang Januar bekannt gewordenen Spectre-Lücke (CVE-2017-5715) entgegenzuwirken. Nun zog Canonical den Microcode zurück, indem das Paket amd64-microcode 3.20180524.1~ubuntu0.14.04.2+really20130710.1 an seine Stelle rückte.

  • Einbruch bei Gentoo durch Achtlosigkeit ermöglicht

    Einbruch bei Gentoo
    Photo by Anas Alshanti on Unsplash

     

    Die Analyse des Einbruchs und der Übernahme des GitHub-Repositories der Linux-Distribution Gentoo ist abgeschlossen. Aus dem jetzt vorliegenden schriftlichen Report lassen sich zwei Kernaussagen ableiten.

    Vorbildliche Reaktion

    Zum einen haben die Entwickler vorbildlich reagiert und sind sofort nach der Entdeckung an die Öffentlichkeit gegangen. Zweitens wurde der Einbruch durch ein kompromittiertes Passwort auf einer anderen Webseite erst ermöglicht. Wie die Entwickler feststellten, konnte das Passwort für den Hack von dem kompromittierten Passwort abgeleitet werden. Einer der Entwickler verwendete ähnliche Passwörter auf verschiedenen Webseiten und Diensten.

    Drei Repositories betroffen

    Der oder die Einbrecher hatten nach dem Eindringen zunächst alle legitimen Accounts entfernt und dann versucht, durch das Hinzufügen von rm -rf-Kommandos in verschiedenen Repositories Daten auf den Rechnern der Nutzer zu löschen, die per git pull diese Repositories auf ihre Rechner ziehen. An dieser Stelle waren allerdings Sicherheitsmaßnahmen eingebaut, die das Ausführen dieser Befehle verhinderten. Betroffen von den Änderungen der Einbrecher waren die Repositories gentoo/gentoo, gentoo/musl und gentoo/systemd. Kopien dieser Repositorien aus dem betroffenen Zeitraum sollten auf keinen Fall genutzt werden.

    Schwachstellen identifiziert

    Die Analyse hat einige Schwachstellen in der Handhabung der GitHub-Repositories seitens der Gentoo-Entwickler aufgezeigt. So sei unter anderem die Kommunikation mit Anwendern der betroffenen Repositories nicht ideal gewesen. Zudem war der Mechanismus zum Widerruf der Zugangsdaten schlecht implementiert. Es gab darüber hinaus kein Backup der Details der Gentoo-Organisation auf GitHub. Systemd, eines der drei betroffenen Repositories, war kein Spiegel eines Gentoo-Repository, sondern direkt auf Github gespeichert.

    Auswirkungen

    Die Gentoo-Organisation auf GitHub war als Folge des Einbruchs für fünf Tage gesperrt. Eine unangenehme Folge des Einbruchs war zudem, dass alle früheren Pull Requests  von den zugehörigen Commits getrennt und geschlossen wurden. Das konnte von GitHub nicht rückgängig gemacht werden, sodass Anwender ihre Pull Requests erneut öffnen müssen.

    Laute Einbrecher

    Die Attacke verlief relativ laut, was zur schnellen Entdeckung beitrug. Einerseits wurden durch das Entfernen aller Konten die Entwickler per E-Mail informiert. Zum anderen erzwangen der oder die Täter ihre Änderungen mit dem Kommando git push –force. Damit hatten die Einbrecher selbst verhindert, dass ihre Änderungen lautlos von Anwendern mit einem git pull auf ihre Rechner gezogen werden konnten.

    Lehren gezogen

    Der Originalcode von Gentoo war zu keinem Zeitpunkt gefährdet, da er sich auf Servern der Organisation befindet, auf GitHub liegt lediglich eine Kopie. Die Entwickler selbst arbeiten fast ausschließlich mit dem Originalcode, während Beiträge aus der Community auch über die Gentoo-GitHub-Organisation vorgenommen werden. Als eine der Lehren aus dem Vorfall forciert Gentoo jetzt die Verwendung von Zwei-Faktor-Authentifizierung (2FA) für Konten auf GitHub. Viele Anwender nutzten diese doppelte Absicherung bereits vor dem Vorfall, aber nicht alle.