Frage:
Ist es dringend erforderlich, den Zugang zu einem privaten Repo zu widerrufen, sobald eine Person es fälschlicherweise erhalten hat, und sich dessen bewusst zu werden?
gaazkam
2017-11-22 18:18:05 UTC
view on stackexchange narkive permalink

Auf Niebezpiecznik.pl, einem beliebten InfoSec-Blog, wurde ein Beitrag veröffentlicht, der eine interessante Situation beschreibt.

Ein Unternehmen hat einem zufälligen Programmierer fälschlicherweise Zugriff auf sein BitBucket-Repo gewährt . Dieser Programmierer alarmierte anschließend verschiedene Mitarbeiter des Unternehmens und forderte sie auf, den Zugriff so schnell wie möglich zu widerrufen. Er fand diese Mitarbeiter träge (zum Beispiel sagte einer, er würde den Zugang erst widerrufen, wenn er von seinem Urlaub zurück war), und alarmierte den Niebezpiecznik-Blog, der sich anschließend an das Unternehmen wandte. Erst dann wurde der Zugriff widerrufen.

Es ist klar, dass der Programmierer das Fehlen eines sofortigen Widerrufs des Zugriffs als ein sehr schwerwiegendes Versehen im Namen der Sicherheitsrichtlinien des Unternehmens ansah. Und hier bin ich überrascht.

Betrachten wir dies aus Sicht des Unternehmens. Jemand kontaktiert sie, behauptet, er habe fälschlicherweise Zugang zu ihrem privaten Repo erhalten, und fordert sie auf, diesen Zugang zu widerrufen. Jetzt ist diese Person entweder am Inhalt dieses Repos interessiert oder nicht; Er hat auch moralische Werte, die nicht stark genug sind, um sie nicht herunterzuladen. Wenn er bereit ist, den Inhalt des Repos zu überprüfen, hatte er bereits genügend Zeit, dies zu tun. und wenn er dies noch nicht getan hat, wird er dies wahrscheinlich noch nicht getan haben, wenn der Mitarbeiter von seinem Urlaub zurück ist. Mit anderen Worten, die Milch ist bereits verschüttet und nichts Schlimmeres als das, was bereits geschehen ist, wird wahrscheinlich in Zukunft passieren.

Infolgedessen würde ich denken, dass die Situation nicht mehr dringend ist und gut warten kann bis der Mitarbeiter von seinem Urlaub zurück ist.

Wo irre ich mich?

Was ist, wenn jemand diesen zufälligen Programmierer gehackt hat?Da geht dein geistiges Eigentum.Viel Glück, überfordert zu werden.
Das Problem, im Urlaub zu sein, ist keine Folge - wenn das Unternehmen nur eine einzige Person hat, die in der Lage ist, diese Änderung vorzunehmen, und diese Person im Urlaub ist, ist dies das eigentliche Problem.
Indem er sich bemühte, seinen Zugang zu widerrufen, implizierte er "und bewertete, ob irgendwelche Geheimnisse kompromittiert worden sein könnten".Indem er prüft, ob sein Zugang noch funktioniert, weiß er, dass sich wahrscheinlich niemand mit dem Problem befasst hat.
Erinnern Sie sich an eine klassische Hacker- "Legende", als [Motorola-Leute ein Sicherheitsproblem in einem Xerox-System fanden] (http://catb.org/jargon/html/meaning-of-hack.html)
Hat der Blog die qualitativen Aspekte des Repositorys kommentiert, z.Größe oder Inhalt?Wissen wir zum Beispiel, ob dieses Repository die gesamte umfangreiche Codebasis des Unternehmens mit Geschäftsgeheimnissen enthielt oder ob es sich möglicherweise um geringfügige, unwichtige Inhalte handelte?
Stellen Sie diese Frage ernsthaft?!Warst du es, der im Urlaub war?
In diesem Fall würde ich das Repo aus einer Sicherung vor dem Berechtigungsfehler wiederherstellen.
Sich in populären Infosec-Blogs nicht lächerlich zu machen, ist an sich schon ein guter Grund, schnell zu handeln, und einer, der im Nachhinein wirklich nicht den Vorteil haben sollte.Es ist ein Problem, ob es eine tatsächliche Sicherheitsanfälligkeit gibt, die durch Ihre Zeit noch verstärkt wird.Sie hätten aber auch darüber nachdenken sollen, wie sich dies auf das Image des Unternehmens auswirkt, wenn sie sehr entspannt reagieren.Wenn Sie Ihren Benutzern vertrauen möchten, reicht es nicht aus, professionell zu sein, sondern Sie sollten auch professionell aussehen.
Der Zufallsprogrammierer möchte nichts damit zu tun haben.Was ist, wenn etwas Schlimmes passiert?Der Programmierer möchte nicht auf der Verdächtigenliste stehen
Hier ist [eine Perspektive] (https://panic.com/blog/stolen-source-code/) von einem Entwickler darüber, was passiert, wenn Ihr Quellcode pwn'd wird.Es erklärt, warum ein Verstoß nicht als das Ende der Welt angesehen werden kann.
Neun antworten:
#1
+109
Anders
2017-11-22 18:30:15 UTC
view on stackexchange narkive permalink

Es gibt eine Reihe von Gründen:

  • Wenn es einer Person passiert ist, ist es möglicherweise mehr passiert. Diese anderen Leute sind möglicherweise nicht so freundlich.
  • Wer weiß, diese Person könnte ihre Meinung ändern. Wenn sie sich die Mühe gemacht haben, sich mit Ihnen in Verbindung zu setzen, und dafür nur ein "meh" erhalten, sind sie möglicherweise etwas verärgert und beschließen, Sie dafür zu bestrafen.
  • Oder sie möchten einfach nur ein bisschen herumstöbern zum Spaß und versehentlich etwas kaputt machen.
  • Sie möchten wahrscheinlich die Protokolle überprüfen, um festzustellen, dass diese Person die Wahrheit sagt. Vielleicht haben sie stillschweigend Ihre Verschlüsselungsschlüssel gestohlen, bevor sie Sie kontaktiert haben. Sie möchten wahrscheinlich alle Ihre Geheimnisse drehen, nur um sicherzugehen.
  • Und vor allem ist dies ein Big F * cking Deal ™. Wer nicht mit Schock und Entsetzen reagiert, sondern stattdessen eine andere Piña Colada bestellt, versteht den Ernst der Lage eindeutig nicht.

Es gibt einige sehr gute Punkte in Kommentaren und diese Antwort, dass unter bestimmten Umständen alles in Ordnung sein könnte (z. B. Nur-Lese-Zugriff, keine Geheimnisse im Code usw.). Das ist richtig, aber ich würde trotzdem argumentieren, dass dies ernster genommen werden sollte. Sind Sie wirklich zu 100% sicher, dass Ihr Repo keine Geheimnisse in einem alten Commit enthält? Die Tatsache, dass jemand, der keinen Zugriff auf Ihre Systeme haben sollte, es trotzdem hat, ist an sich schon ein schlechtes Omen.

Kommentare sind nicht für eine ausführliche Diskussion gedacht.Diese Konversation wurde [in den Chat verschoben] (http://chat.stackexchange.com/rooms/69189/discussion-on-answer-by-anders-is-it-urgent-to-revoke-the-access-to-a-private-re).
"* Sind Sie wirklich zu 100% sicher, dass ein altes Commit in Ihrem Repo keine Geheimnisse enthält? *" Wenn das Repo privat ist, enthält es per Definition Geheimnisse.
@Simba Ich habe viele private Repos, die keine Geheimnisse enthalten - sie sind nur privat, weil ich mich nie die Mühe gemacht habe, sie zu teilen, normalerweise, weil sie für niemanden außer mich von Interesse sind.
Außerdem: Solange sie Zugriff auf das Repo haben, können ihnen Lecks und Hacks vorgeworfen werden, die mit Informationen aus dem Repo gemacht wurden.(Dies endet nicht vollständig, wenn der Zugriff widerrufen wird, begrenzt jedoch den potenziellen Schaden.)
#2
+58
Monica Apologists Get Out
2017-11-22 18:32:51 UTC
view on stackexchange narkive permalink

Während es unmöglich ist, die Gedanken der Spieler zu lesen, würde ich denken, dass der unabhängige Programmierer

A) nicht der Unangemessenheit beschuldigt werden möchte - es ist viel schwieriger, beschuldigt zu werden IP-Diebstahl, wenn Sie treten und schreien, um Ihren Zugriff nach Eile zu widerrufen.

B) Entsetzt über die Sicherheitslage des Unternehmens, das das private Repository kontrolliert, und weiß, dass er dies wünschen würde, wenn er dafür verantwortlich wäre informiert werden.

A, A und wieder A. Und ein bisschen B. Aber meistens eine ganze Menge A.
Er weiß wahrscheinlich genau, wie viel Ärger er bekommen kann, wenn er schweigt.Sie kennen offensichtlich seine Kontaktinformationen, um ihm Zugang zu gewähren.
Ich verstehe nicht, warum dies 40 positive Stimmen bekam.Die Frage fragt nach den Verwaltungsaktionen.Die Diskussion über die Motivation des Programmierers gehört nicht in eine Antwort.
@Harry Johnston Wenn Sie einen Punkt haben, dann machen Sie es.Im dritten Absatz geht es nicht um die Aktionen des Programmierers, sondern um die Einstellung des Programmierers.
@Acccumulation, Ich verstehe nicht, warum Sie diese Unterscheidung für relevant halten, was mich glauben lässt, dass mein vorheriger Kommentar nicht klar war, also werde ich umformulieren: Die Frage basiert auf der zweifelhaften Annahme, dass die "Einstellung" des Programmierers, wie Sie es ausdrückenbasiert ausschließlich auf einer objektiven Einschätzung des Risikos für das Unternehmen.Der Konsens über Stack Exchange ist, dass es eine gültige Antwort ist, zu erklären, warum die Prämisse einer Frage fehlerhaft ist.Dies wird manchmal als "Rahmenherausforderung" bezeichnet.
@HarryJohnston Angesichts der Tatsache, dass der letzte Satz des fraglichen Absatzes "Und hier bin ich überrascht." Lautet, sehe ich nicht, wie die Frage als Annahme angesehen werden kann, dass die Position des Programmierers gültig ist.
@Acccumulation, Ich interpretierte diesen Satz als "Ich fand das überraschend, und deshalb stelle ich diese Frage", da es sonst wenig Sinn machen würde, ihn zu erwähnen.Wenn Sie es anders interpretiert haben, kann ich sehen, warum diese Antwort für Sie irrelevant erscheint.
Ich schätze diese Antwort.Es gibt mir ein besseres Verständnis für das Thema.
#3
+19
Nzall
2017-11-22 20:35:32 UTC
view on stackexchange narkive permalink

Zu beachten ist, dass das Gewähren eines zusätzlichen Benutzerzugriffs auf ein Repository einen völlig neuen möglichen Angriffsvektor eröffnet. Wenn eine andere Person mit böswilligen Absichten Zugriff auf das Konto hat, dem der Zugriff auf das Repo gewährt wurde, ohne dass der ursprüngliche Kontoinhaber davon Kenntnis hat, kann diese Person problemlos Ihren gesamten Quellcode herunterladen.

Ja +1, man kann nie wissen, ob die Anmeldeinformationen eines unbekannten Dritten stark sind.Oder kompromittiert.
Aus diesem Grund speichern Sie niemals API-Schlüssel oder vertrauliche Informationen in Ihrem Repo, da Repos ständig durchgesickert sind.
#4
+10
Voo
2017-11-24 03:15:29 UTC
view on stackexchange narkive permalink

Um eine andere Sichtweise als die Mehrheit zu bieten, sollte es wirklich kein Sicherheitsrisiko sein, wenn das Projekt gut gehandhabt wird.

Grundsätzlich gibt es zwei Dinge Zu erfüllen. Erstens, dass

  • Sie keinen Code in Release-Zweige einfügen können, ohne dass andere Personen sich abmelden müssen. Dies wird normalerweise dadurch erreicht, dass Pull-Anforderungen und Codeüberprüfungen für jeden Code erforderlich sind, der in einen Release-Zweig gelangt. In diesem Fall müssen Sie sich darüber keine Sorgen machen, wenn die Person nur Lesezugriff auf das Repository hat. Trotzdem sollten Sie dies trotzdem haben.

und zweitens, dass

  • niemand Geheimnisse in das Repository aufnimmt. Ja, Sie haben möglicherweise geheime API-Schlüssel, Codesignaturzertifikate und was nicht, aber die echten sollten NIE in Ihrem Haupt-Repository sein, auf das jeder zugreifen kann. Wenn einige Geheimnisse erforderlich sind, damit der Code funktioniert, fügen Sie einige Dummy-Entwicklungs- / Testversionen in Ihr Repository ein. Die realen sollten jedoch separat aufbewahrt werden, wobei nur eine kleine Anzahl von Personen Zugriff hat, vorzugsweise, damit Ihr Build-System sie automatisch ohne manuelle Beteiligung einschließt.

Wenn beides zutrifft, sehe ich aus Sicherheitsgründen keinen wirklichen Schaden. Ob der Code einige wertvolle Geschäftsgeheimnisse enthält, die einem Konkurrenten bekannt werden könnten, ist ein anderes Thema.

Oder eine andere Art, darüber nachzudenken: Die Situation hier ist nichts Besonderes. Sie müssen sich jedes Mal, wenn ein Mitarbeiter kündigt, mit denselben Problemen befassen ! Wenn Ihr Repository Geheimnisse enthielt, kennt eine externe Person jetzt alle.

Wenn das Unternehmen in dieser Ruhe ein Geschäftsgeheimnis oder ein wertvolles geistiges Eigentum speichert, ist es sehr wahrscheinlich, dass der ausscheidende Mitarbeiter eine Art NDA-Klausel in seinem Vertrag hat und für die Verwendung dieser Informationen haftet.Zufällige Personen, denen Zugang gewährt wurde, sind nicht vertraglich verpflichtet, diese Informationen nicht zu verwenden, soweit dies gesetzlich zulässig ist.
+1, obwohl ich denke, dass es dringend ist, ist es aus den von Ihnen hervorgehobenen Gründen dringend - dem Fremden wurde möglicherweise die Berechtigung zum Festschreiben und Bereitstellen von Code erteilt, und Geheimnisse befinden sich möglicherweise im Repo, möglicherweise in alten Festschreibungen versteckt, weil niemandist perfekt und Sicherheit erfordert mehrere Wachsamkeitsebenen.
@Anders Ja, ich habe nur aus Sicherheitsgründen gedacht.Wenn geschäftliche Erwägungen oder gesetzliche Anforderungen berücksichtigt werden sollen, wird dies viel komplizierter und ich fühle mich nicht qualifiziert, eine vollständige Antwort darauf zu geben.
@Zefiryn-NDAs sind das Papier, auf dem sie gedruckt werden, nicht wert.
#5
+7
Pieter B
2017-11-24 05:03:37 UTC
view on stackexchange narkive permalink

Wenn Sachen gestohlen werden, schauen Sie zuerst, welche Leute einen Schlüssel zum Safe haben.

Ich habe in der Vergangenheit getreten und geschrien, um nicht das zu haben Wenn also (wann) etwas gestohlen wurde, würden sie mich nicht als möglichen Täter ansehen.

Das könnte also für diesen Programmierer genauso gewesen sein. Er wollte nicht diesen Schlüssel haben.

Wenn Sie ein privates Repo haben, können Sie mir Zugriff gewähren, ohne es mir zu sagen.(Sie können meine öffentlichen SSH-Schlüssel ohne mein Wissen oder meine Zustimmung von Github abrufen und sie dann entsprechend zu .ssh / authorized_keys hinzufügen.) Ich habe die Schlüssel, um Änderungen in Ihrem privaten Repo vorzunehmen.Werde ich das missbrauchenWahrscheinlich nicht.Kümmert es mich?NEIN.
#6
+4
Booser
2017-11-23 16:24:22 UTC
view on stackexchange narkive permalink

Sie haben Recht, dass die Situation möglicherweise überhaupt nicht dringend ist und die nachlässige Reaktion der Mitarbeiter gerechtfertigt sein könnte. Vielleicht hat sich der Mitarbeiter nicht um das Problem gekümmert, weil der betreffende Code nicht mehr verwendet wurde oder er keine Geheimnisse mehr hat.

#7
+3
Felix
2017-11-23 20:17:19 UTC
view on stackexchange narkive permalink

Ich habe einmal für ein Startup gearbeitet, bei dem alle die gleichen SSH-Schlüssel verwendeten, weil jemand dachte, es wäre einfacher, einen Schlüssel zu löschen / zu ersetzen, wenn jemand etwas Dummes tut.

Auch das gibt es Möglicherweise hat der Entwickler seinen Schlüssel auf einem öffentlich zugänglichen Computer wie einem Computer an der Universität gespeichert. Dies mag sehr unsicher klingen, ist jedoch für "Hello World" und "Practice Papers" geeignet.

In diesem Fall kann das Unternehmen, wie Sie angegeben haben, relativ sicher sein, dass die Person, die das gemeldet hat Vorfall wird nicht versuchen, das Unternehmen zu verletzen. Sie können jedoch nie sicher sein, wer Zugriff auf das Konto / die Schlüssel der Person hat, die den Vorfall gemeldet hat.

#8
+1
CGretski
2017-11-25 04:06:13 UTC
view on stackexchange narkive permalink

Ich lese kein Polnisch, also verzeihen Sie alles, was bereits angesprochen wurde:

Bitbucket hostet Git und Mercurial Repos - beide sind verteilte CVS; Diese sind im Allgemeinen nicht mit technologischen Kontrollen zum Schutz des geistigen Eigentums / zur Verhinderung des Austritts von geistigem Eigentum vereinbar. Jeder vorhandene Klon / jede vorhandene Gabel kann ohne zentrale Sichtbarkeit des Prüfpfads geklont werden.

Für die Änderung eines Repos sollten geeignete Sicherheitskontrollen vorhanden sein, z. B.

  • PKI-Abmeldung für alle Commits
  • schreibgeschütztes Repo mit Pull-Anforderungen

Somit ist jeder mögliche Schaden bereits angerichtet.

#9
+1
Giacomo1968
2017-11-25 12:42:13 UTC
view on stackexchange narkive permalink

Sicherheit - letztendlich - besteht aus einer Reihe von Prozessen und Verfahren sowie einer Denkweise. Es ist kein festes Regelwerk. Wenn Sie der Meinung sind, dass ein System aufgrund einer geringfügigen Verletzung von one anfällig ist, ist Ihre gesamte Sicherheitseinstellung bestenfalls fehlerhaft und möglicherweise nur für Henny Penny / Chicken Little nützlich.

  • Wenn Anmeldeinformationen nicht verfügbar sind, wen interessiert das? Nach meiner Erfahrung als Codierer, Linux-Systemadministrator und Sicherheitsbereiniger / Fixierer das größte Problem mit Code In einem Repo ausgesetzt zu sein, ist einfach das Risiko, dass Anmeldeinformationen offengelegt werden. Die Realität ist, dass die meisten vernünftigen Codierer wissen, wie man ohne feste Codierungsdaten in ihren Code codiert. Aber die meisten Codierer sind nur faul und wissen, warum - oder wie - jemand ein System mit Anmeldeinformationen erstellen kann, die vom Kerncode getrennt sind.

    Wenn dieses System also von vernünftigen Codierern ausgeführt wurde und das Repo nicht Anmeldeinformationen offenlegen, dann wissen Sie was? Wen interessiert das. Aber - wie viele von uns bereits wissen - gibt es beschissene Codierer auf "Mall Cop" -Ebene, die nur Anmeldeinformationen in den Kerncode einfügen, und das ist es. Sie müssen es nach Gehör spielen.

  • Die Offenlegung von Geschäftsgeheimnissen ist ein Risiko. Dies hängt von der Branche und den Anforderungen ab, unter denen der Code erstellt wurde. Wenn der Code für ein Blog oder eine einfache Website ist? Was auch immer. Selbst wenn es sich um eine E-Commerce-Website handelt, wenn es sich um eine lokalisierte Kopie von Magneto handelt, ist dies kein wirkliches Risiko, da es sich um Open-Source-Software handelt. Aber wenn diese Software proprietär und riskant wäre - wie etwas, das Finanzdaten und möglicherweise sogar heißen neuen Code für ein Spiel verfügbar machen könnte -, dann ist dies ein Risiko.

Aber am Ende des Tages besteht die Aufgabe eines Hackers mit „weißem Hut“ darin, andere über die Probleme zu informieren. Wenn sie ein "Wen interessiert das?" Einstellung zur Exposition, das ist ihr Problem. Vielleicht sehen sie wirklich kein Risiko? Vielleicht ist es ihnen wirklich egal und die Belichtung wird andere verletzen? Vielleicht sind sie Idioten? Vielleicht sind sie so intelligent, dass die Offenlegung von Code nur - vielleicht - ein paar Tage Refactoring bedeuten würde, um das Risiko zu begrenzen? Aber am Ende des Tages kann man so viel tun, um jemanden davon abzuhalten, sich selbst zu verletzen.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...