TrustSource

Wie TrustSource vor Dependency Konfusion schützen kann

Was ist passiert?

Sicherheitsforscher haben es mit Hilfe eines Dependency-Konfusion Angriffes geschafft, sich Zugang zu diversen Hochsicherheits-Netzwerken zu verschaffen. Mit Hilfe dieses Angriffes ist es Ihnen gelungen, Informationen und Daten aus den betroffenen Netzwerken nach draußen zu schicken. Je nach Ausgestaltung des Angriffsszenarios wären jedoch auch andere Aktivitäten denkbar. Erst einmal hinter den Verteidigungslinien angekommen, lässt sich das Schadensszenario frei wählen.

Wie ist der Angriff erfolgt?

Die Sicherheitsforscher sind auf die Idee gekommen, als Sie in den veröffentlichten Open Source Werkzeugen der Firmen (Apple, Adobe, etc.) Namen privater Pakete gefunden haben.

Oft nutzen Unternehmen Open source und ergänzen gewisse Funktionalitäten oder grafische Steuerelemente mit eigenen Bibliotheken. Diese wiederum werden nur von einem Team entwickelt und als eigene Pakete bzw. Bibliotheken für andere Entwicklungsteams bereitgestellt. Das ist effizient und komfortabel, da die breite Menge der Entwicklungs-Teams sich nicht kümmern muss, das Look-and-Feel dennoch konsistent über unterschiedliche Anwendungen bzw. Services bleibt.

Spielen die Unternehmen nun Software zurück an die Community und werden die Referenzen auf solche „privaten“ Pakete nicht aus dem Quellcode entfernt, trägt die Veröffentlichung dien Namen dieser Pakete nach draußen. Das an sich ist noch nicht so gefährlich. Interessant wird dies erst, wenn die Information für eine Dependency-Attack (s. nebenan) ausgenutzt wird.

Wie können Sie sich schützen?

  • Komponenten-Namen:
    Folgen die internen Komponentennamen einem Namens-Schema, wie bspw. ORG.COPMANY.UNIT.UITOOLS wird es für Dritte erheblich schwieriger entsprechende Namen in den Paketmanagern anzulegen, ohne dass es Aufsehen erregt.ORG.COPMANY.UNIT.UITOOLS fällt mehr auf, als die 100ste Version von UITOOLS.
  • Nutzung von Paketmanager-Proxies:
    Um in dem Angriff erfolgreich zu sein, sind die lokalen Verteilmechanismen zu überlisten. Es sollte sichergestellt sein, dass für gewisse Paket-Typen, u.a. bspw. mit Hilfe der  Namenskennung ode reiner einfachen Blacklist, keine Updates von außen gezogen werden.
  • Versionsüberwachung:
    Mit Hilfe einer Versionshistorie wird es schnell möglich, festzustellen, welche Versionen im Einsatz sind. Ein Sprung von 1.2.3 zu 69.1.0 lässt sich schnell entdecken, bzw. fällt auf.

Was ist eine Dependency-Konfusion?

Moderne Package-Systeme nutzen Paketmanager, insbesondere um die stetig wachsende Zahl von Open Source Komponenten zu verwalten. Jede Build-Vorschrift enthält daher eine Liste der einzubindenden Komponenten. Unter Java ist das die POM.XML-Datei, bei Node.JS (JavaScript) ist das die PACKAGES.JSON.

In dieser Datei sind die Komponenten und die Mindestanforderungen and die Komponenten, die Versionsnummern angegeben. Da sich viele Komponenten öfter ändern, steht in den Vorschriften oft nicht nur die exakte Versionsangabe, bspw. 1.2.3 sondern ein Vermerk wie ^1.2.3, was so viel bedeutet wie: „Gib mir mindestens die 1.2.3 oder neuer.“ . Erfolgt seitens der Maintainer der Komponente eine Update auf bspw. 1.2.4 (neuer Patch) oder 1.3.0 (neues Feature) würde die eigene Lösung mit Hilfe der Formulierung beim nächsten Bauen von den Neuerungen profitieren können.

Wird nun in einem Package Manager von einem bösartigen Akteur eine neuere Version eingestellt, bspw. eine 2.1.0, so kann er relativ sicher sein, dass diese Version vom Package Management für den oben beschriebenen Kontext bereitgestellt würde. Baut das Projekt nun anständig, würde dieser schadhafte Code in ein QS-System ausgebracht und dort ausgeführt. Je nach

 

Sie wollen Schwachstellen entlang des gesamten Produkt-Lebenszyklus Ihres Produkt verlässlich überwachen?

TrustSource kann gegen solche Angriffe schützen!

TrustSource kennt die aktuellen Versionen Ihrer Module und Lösungen sowie der öffentlich verfügbaren. plötzliche Versionssprünge öffentlich verfügbarer Komponenten werden von unseren Systemen erkannt und an unser Support-Team zur Prüfung gemeldet. Kritisch einzustufende Entwicklungen werden an die Projekte zurückgemeldet.

Nutzen Sie bereits TrustSource ist Ihnen vermutlich das Konzept des „linked Modules“, des Einbindens von Releases eigener Software bekannt. Tauchen hier Versionen auf, die bisher unbekannt sind, führt auch dies zu einer Meldung an den jeweiligen Projektleiter. Somit können Sie sicher sein, entsprechende Entwicklungen schnell zu bemerken.


Microsoft erweitert Githubs integrierte Vulnerability Management Fähigkeiten

Software eats the world - Microsoft eats Software?

Mit der Übernahme von Github hat Microsoft ein klares zeichen gesetzt, dass es seinen Führungsanspruch in der Gestaltung von Software nicht nur erhalten, sondern ausbauen will. Mit den nun in aller Eile geschaffenen Vulnerability-Werkzeugen in Github untermauert Microsoft seinen Anspruch als Platzhirsch in der Software-Entwicklung.

Github hat mit seiner erfolgreichen Mirror-Strategie den Anspruch als quasi-Standard-Repository für Software erfolgreich platzieren können. Neben einer stabilen und smarten Versionierungs- und Synchronisationslösung für Quellcode hat das Mirroring sämtlicher Open-Source-Projekte dazu beigetragen, das Gefühl von Größe geschickt zu vermitteln. Github wurde der Platz, an dem man Software findet.

Microsoft hat dies erkannt. Zudem haben Satya Nadella – und/oder sein Team – erkannt, welche Themen gerade in der Software-Entwicklung Relevanz entwickeln. Nachdem sich mit IoT letztlich Software in alle Arten von Gegenständen verbreitet, bekommen Schwachstellen (Vulnerabilities) und rechtliche Konformität (legal Compliance) eine erheblich höhere Bedeutung.

Mit Macht besetzt Microsoft nun dieses Thema. Durch die Übernahme von Github hosted Microsoft über Nacht einen Großteil der offenen Quellcodes dieser Welt. Die Software-Industrie hat mit CI/CD-Lösungen schon viel für ihre Qualitätssicherung getan und diese nahtlos an Github angeschlossen. Immerhin gibt es in diesem Segment noch eine handvoll alternative Lösungen.

Das leidige Thema „Schwachstellen- und Patch-Management“ ist derzeit noch etwas unsortiert, da es zum einen keiner gerne macht, zum anderen auch ein sehr zähes und unproduktives Geschäft ist. Dennoch haben Equifax und andere Fälle eindringlich aufgezeigt, was Folgen des Unterlassens sein können. Also beschäftigt sich inzwischen jeder notgedrungen damit.

Mit den in den letzten Wochen bekanntgegebenen Lösungen rund um das Multi-Language-Package-Management, die freien Vulnerability-Alerts – jetzt auch gestützt durch die Whitesource Vulnerability-Database für Enterprise Kunden — und durch die Übernahme von Dependabot – für eine Versionskontrolle á la Versioneye – stopft Microsoft diese Lücke und zementiert somit die Führungsposition von Github als Heimat allen Quellcodes.

Wer sollte sich jetzt noch mit diesen leidigen Aufgaben beschäftigen wollen, wenn er sie quasi freihaus durch ein Hosting bei Github erledigt bekommt? Vermutlich nur Verschwörungstheoretiker und Technikverliebte.

Letzten Endes bleibt es eine Vertrauenssache, wem man zutraut, die richtigen Abhängigkeiten bzw. Vulnerabilities zu identifizieren:

  • Werden hier meine tatsächlich zum Einsatz kommenden Abhängigkeiten analysiert oder dient nur das Original als Vorlage für die Alarme?
  • Können die aufgezeigten Vulnerability-Alerts tatsächlich einen Mehrwert bringen oder erzeugen sie aufgrund des hohen Lärmpegels, der mit meiner Bedrohungssituation nichts mehr zu tun hat nur ein ohrenbetäubendes Rauschen, welches meine Entwickler von der Arbeit abhält?

Die Antworten zu diesen Fragen werden die nächsten Monate liefern. Ansatz und Ambition dieses Schrittes erscheinen mir jedoch brillant! Wesentlich substanzieller als die bereits überraschende Übernahme von RedHat durch IBM.

Wenn man Einfluss und Informationsgewinn vergleicht, erschient die Cost-Impact-Ratio bei MS etwas günstiger auszufallen. Unabhängig davon verfügt Microsoft über hinreichend Capability to achieve, um das Vorhaben mittelfristig zu einem Erfolgsmodell zu drehen und den Platz als „Heimat allen Quellcodes“ zu behaupten. Was das wiederum für die Offenheit von Open Source bedeutet, mag jeder für sich selbst beurteilen.

Was bedeutet das für TrustSource?

Kurz nach dem Announcement haben mich erste Kunden gefragt, was das für uns bedeutet. Nach einiger Überlegung bin ich zu dem Schluss gekommen, dass uns diese Ergebnisse das Leben einfacher machen werden.

Zum einen ist die Maintenance so vieler Package-Manager – wir unterstützen derzeit 13 – auf Dauer ein aufwändiges Unterfangen. Open Source hin oder her, am Ende liegt die Maintenance dennoch beim Hauptsponsor.

Zum anderen erwarten wir eine verbesserte Informationslage aus den neue APIs. Derzeit ist die Information mehr als oft noch gruselig dürftig. Die Option, das Vulnerability-Assignment uns schenken zu können, ließe uns jubeln. Ich sehe das zwar noch nicht, da die Grundlage für das Vulnerability-Assignment neben einer sehr

Zudem fokussiert TrustSource auf den Compliance-Aspekt. Wir bieten eine OpenChain-konformen Prozess, samt Policy-Propagation, Trainings, einer automatisierten Legal-Analyse, die Compliance-Artefakt-Generierung, und und und. Das sind Berge von Aufgaben, die auch ein Clearly Defined nicht abbildet.

Auch erscheint mir eine Repository-basierte Analyse von Schwachstellen und Abhängigkeiten nicht unbedingt geeignet, den Lebenszyklus und die rechtliche Eignung einer Komponente im Anwendungskontext zu beurteilen. Immerhin ergibt sich die Eignung der Komponente nicht aus dem Repository, sondern dem gewählten Einsatzzweck in Verbindung mit einem kommerziellen Kontext. Dies lässt sich auf Repository-Ebene schlicht nicht abbilden.

Wir freue uns daher darauf, in den kommenden Monaten die neuen APIs zu integrieren, damit (hoffentlich) unseren Kunden eine verbesserte Informationslage zu bieten und ggf. die letzte Lücke in der Kette der Software-Herstellung zu schließen. Zudem unterstreicht es unsere Auffassung, dass wir in einem relevanten Segment aktiv sind, dass derzeit viel in Bewegung ist.

Sie wollen Ihre Open Source Compliance stärken, wissen aber nicht, wie starten?