[Security] TSEC der Switch wurde wohl gehackt!

  • Per RCM Exploit gelang den Hackern einen Vollzugriff auf der Nintendo Switch, damit verfügt man die volle Kontrolle über den sicheren Bootprozess, das Nintendo nur der Versuch blieb einen cleveren Workaround zu bauen mithilfe von TSEC (Tegra Security Co-processor) für die Signierung und Abschottung der Keys, welcher ab der FW 6.2.0 als alternativer sicherer Bootvorgang auf der Switch fungierte, um das Ausführen einer CFW zu verhindern/erschweren.
    Ab 7.0.x konnte der TSEC zu dem nicht mehr via SMMU umgangen werden.


    TSEC ist eine dedizierte Einheit, die von einem NVIDIA Falcon-Mikroprozessor mit Kryptoerweiterungen angetrieben wird.
    Er galt bislang als gut gesichert und unhackbar, bis jetzt nun,


    Mike Heskin (@hexkyz) twittert, dass der TSEC nun gehackt wurde:



    "Es scheint, dass meine Tweets von gestern einige Leute verwirrt haben. Ich kann es dir nicht verübeln. Dass ich bei der einfachen englischen Sprache scheiterte ("bis" statt "während", smh) *und* den falschen Hash zu posten, half überhaupt nicht, aber was soll ich sagen? Ich war zu aufgeregt und müde, um es überhaupt zu bemerken.


    Ich werde nun versuchen, einen kurzen Überblick über all dies zu geben. TSEC ist eine Steuerung, die in den meisten Tegra-Geräten verwendet wird, einschließlich des Switch. Wie viele andere Controller in Tegra-Geräten wird er von einem Falcon-Mikroprozessor betrieben, jedoch mit zusätzlichen Kryptofunktionen (über das SCP).


    Auf dem Switch wird neben HDCP auch der TSEC im Bootprozess der Konsole verwendet, indem er eine zusätzliche Quelle der Geheimhaltung für die Schlüsselableitung bietet.
    Mit fw 6.2.0 wurde die Rolle von TSEC erweitert, um eine sichere Boot-Kette wiederherzustellen, da der RCM-Exploit sie zerstört hatte.


    Als 6.2.0 fiel, konnten wir TSEC mit Tegras SMMU besiegen. Dies funktionierte, indem TSEC den Eindruck erweckte, dass es in einer sicheren Umgebung läuft, während wir die volle Kontrolle über den Speicherinhalt hatten. In diesem Fall gab es keine Kompromisse bei der TSEC selbst.


    Dann kam 7.0.0. das eine TSEC-Nutzlast einführte, die die SMMU vollständig umgehen konnte, indem sie einen versteckten Kommunikationskanal zwischen der TSEC und dem Tegra Memory Controller nutzte. Dies erforderte die tatsächliche Nutzung der TSEC, die schließlich die notwendigen Schlüssel lieferte.


    Was Sie wahrscheinlich nicht wissen, ist, dass dieser spezifische Exploit nur unter bestimmten Umständen funktionieren würde (was aus offensichtlichen Gründen nicht näher erläutert wird). Während die Schlüssel 7.0.0 auf diese Weise extrahiert werden konnten, konnten die Schlüssel 6.2.0 zum Beispiel nicht (so bizarr das auch klingen mag).


    Aus diesem Grund war es ungewiss, ob Schlüssel in zukünftigen Updates extrahiert werden konnten oder nicht..... Bis jetzt. Das dritte Mal ist der Charme. Ich habe vor ein paar Wochen einen kritischen Designfehler gefunden und nach einer kurzen Brainstorming-Sitzung mit @SciresM konnten wir das Krypto-Schema des TSEC für immer auslöschen.


    Das bedeutet, dass alle Falcon v5 (und möglicherweise auch davor oder danach) basierten Controller auf Hardware-Ebene anfällig sind, was uns die Möglichkeit gibt, alle notwendigen zukünftigen Schlüssel zu extrahieren!


    Der Weg dorthin war nicht einfach: Ich begann bereits im Januar 2018 mit dem Angriff auf TSEC. Aber zusammen mit den brillanten Köpfen von @qlutoo, @shuffle2, @SciresM und @elmirorac konnten wir über 5 verschiedene Fehler unter uns finden und ausnutzen, die entscheidend waren, um hierher zu gelangen.


    Der erste Hash sollte von einem 6.2.0er Schlüssel sein, den wir vorher nicht ausgeben konnten (außer, dass ich es versaut habe und den Hash von *dem* *nur* einen* gepostet habe, den wir tatsächlich *auskippen könnten, seufzen....), während der zweite Hash von etwas ist, das nur von dieser Ebene der Pwn erhalten werden kann.


    Noch einmal, ein großer Applaus an @qlutoo, @shuffle2, @SciresM und @elmirorac für die gesamte Arbeit und auch an die Leute von nouveau/envytools für die erstaunliche Arbeit bei der Dokumentation der Falcon und anderer obskurer Controller im Laufe der Jahre!"


    Quelle: https://twitter.com/hexkyz/status/1101940118338838530
    .

  • Exkat das was im Text steht:

    was uns die Möglichkeit gibt, alle notwendigen zukünftigen Schlüssel zu extrahieren!

    Um eines klarzustellen, dass ist kein Jailbreak o.Ä., wovon gepatchte Konsolen profitieren könnten und das ist übrigens nichts für Enduser sondern nur für CFW Developer interessant.
    Die allerersten ausgelieferten Switches sind ja schon bereits offen wie ein Scheunentor, worauf ALLES möglich ist - TSEC ist nur eine separate Einheit und hat vor 6.2.0 nicht viel gemacht.
    Ab der FW 6.2.0+ konnte Nintendo ihre Keys zur Entschlüsselung der FW vor den Hackern isolieren, in dem diese in den TSEC verstaut wurden - bislang war TSEC ein Bereich, worauf Devs keinen Zugriff hatten.
    Da nun auch dieser gehackt wurde, hat Nintendo somit kein weiteres Ass im Ärmel um das Entschlüsseln der Firmware zu verhindern.
    Somit können sie keine effektiven Anti-CFW-Maßnahmen in ihren zukünftigen Updates mehr einleiten.

  • bislang war TSEC ein Bereich, worauf Devs keinen Zugriff hatten.

    Aber die Keys wurden doch trotzdem gefunden...wie sind die denn an diese Keys dran gekommen, wenn kein Zugriff möglich war?

  • @muxi


    naja, auf der 6.2.0 wurden keine Keys aus dem TSEC gedumpt, da man einen Vuln in der von NVIDIA gut dokumentierten SMMU nutzte, um das Bootverfahren des TSEC´s zu umgehen.


    Auf der 7.0.0 wurde das dann viel komplizierter, die SMMU wurde von TSEC von nun an ignoriert, es blieb den Devs keinen anderen Weg, als den TSEC zu exploiten, was ihnen schließlich auch gelang.


    Sie hatten aber offenbar (schon) vorher eine schwächere Sicherheitslücke genutzt um an die Keys ran zu kommen auch wenn sie das nicht an die grosse Glocke hängen wollten, die Keys sind bis heute alle nicht von ScresM und co. veröffentlicht worden, sodass Atmosphere diese auto. extrahiert. Ich bezweifel stark, dass sie an die Keys kamen ohne den TSEC anzugreifen - gestern haben sie nun ihr Schweigen gebrochen, dass der TSEC doch nun gehackt wurde.


    Offiziell hieße es jedoch immer, dass der TSEC ungehackt blieb, allerdings haben sie jetzt den VOLLEN Zugriff drauf und ich zitiere hexkyz:

    Zitat

    Ich habe vor ein paar Wochen einen kritischen Designfehler gefunden und nach einer kurzen Brainstorming-Sitzung mit @SciresM konnten wir das Krypto-Schema des TSEC für immer auslöschen.

  • Was soll Nintendo da groß gegen unternehmen können?

  • @muxi Sie können natürlich andere nervige Sachen anstellen, wie bspw. Systemmodule neu implementieren, massiv refaktorisieren und obfuskieren und was nötig ist. aber das Entschlüsseln der Firmware zu verhindern sieht für sie schlecht aus.


    TSEC und bootROM (dank dem Tegra RCM Exploit) sind gehackt, also sollten sie sich lieber auf die jetzige/zukünftige Hardware-Revisionen konzentrieren, dass sich so eine gravierende Lücke wie in dem RCM nicht mehr wiederholt.


    Zwei nicht zu behebende Hardwarefehler pünktlich zum zweiten Geburtstag der Switch xD

  • Dieser Exploit wird nicht öffentlicht dokumentiert und bleibt für hexkyz und ScresM "Top Secret". Ich bin mir relativ sicher, dass TX auf Hexkyz' Liste der letzte ist, mit dem man das teilen würde.
    Also muss TX vieles auf eigene Faust machen, würde aber auch reichen, wenn sie das 1:1 von Atmsophere übernehmen würden (was sie eh schon tun).

  • Dann sollte es zukünftig wohl schneller vonstatten gehen, eine CFW an eine neue FW Version anzupassen. Sehe ich das richtig?

  • Die haben ja noch mehr Arbeit, weil sie u.a. den Installer und das Mounten usw. an FW 7.x anpassen müssen. Man bedenke dabei, dass z.Bsp. Goldleaf erst seit Kurzem halbwegs mit FW 7.x zufriedenstellend arbeitet!

  • @muxi Das ist nicht so einfach, wie man es erstmal animmt - sie arbeiten bestimmt auf Hochtouren, um ihre CFW für 7.0.0 funktionstüchtig zu machen.


    TX hat nicht das technische Know-How um den TSEC selbstständig zu exploiten - esseidenn, die Atmo-Devs legen ihre TSEC-Exploits offen.


    Für TX bietet sich nur die einzige Möglichkeit und zwar das Forken des sept-Moduls in ihre CFW, um sie auf 7.0.x zum Laufen zu kriegen.
    Obwohl sept Open Source ist, wird es nicht so einfach funktionieren, es sei denn, es wird mit privaten TSEC-keys verschlüsselt, so dass TSEC sept  selbst entschlüsseln kann.
    Das sept-Modul von Atmosphere hat übrigens ein Brandzeichen von Atmosphere, das man nicht entfernen kann.


    TX hat zwei Möglichkeiten:


    • Einen Weg finden, selbst an die TSEC-keys dran zukommen mittels eines Exploits, was eben lange dauern kann (wenn überhaupt), da alle Methoden dazu privat sind.
    • Sie verwenden die Lösung von Atmosphere, die bereits mit den nötigen privaten Keys verschlüsselt und open-Source wurde, einschließlich des Logos von Atmosphere, welches dann jedes Mal als Splashscreen aufkommt, sobald man in das SX OS bootet.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!