S3 Ep95: Slack Leak, Github-Angriff und Post-Quanten-Krypto [Audio + Text]

Klicken und ziehen Sie auf die unten stehenden Schallwellen, um zu einem beliebigen Punkt zu springen. Du kannst auch direkt zuhören auf Soundcloud.

DOUG.  Slack Leaks, ungezogener GitHub-Code und Post-Quanten-Kryptographie.

All das und noch viel mehr im Naked Security Podcast.

[MUSIKMODEM]

Willkommen zum Podcast, alle zusammen.

Ich bin Doug Aamoth.

Bei mir ist wie immer Paul Ducklin.

Paul, wie geht es dir heute?

---

ENTE.  Super-duper, wie immer, Doug!

---

DOUG.  Ich bin super-duper aufgeregt, zu dieser Woche zu kommen Tech-Geschichte Abschnitt, weil …

…du warst dabei, Mann!

Diese Woche, am 11. August …

---

ENTE.  Ach nein!

Ich glaube, der Groschen ist gerade gefallen…

---

DOUG.  Ich muss nicht einmal das Jahr sagen!

11. August 2003 – Die Welt wurde auf den Blaster-Wurm aufmerksam, der Windows 2000- und Windows XP-Systeme betraf.

Blaster, auch bekannt als Lovesan und MsBlast, nutzte einen Pufferüberlauf aus und ist vielleicht am besten für die Nachricht bekannt, „Billy Gates, warum machst du das möglich? Hören Sie auf, Geld zu verdienen, und reparieren Sie Ihre Software.“

Was ist passiert, Paul?

---

ENTE.  Nun, es war vielleicht die Ära, bevor wir Sicherheit so ernst nahmen.

Und glücklicherweise wäre diese Art von Fehler heutzutage viel, viel schwieriger auszunutzen: Es war ein Stack-basierter Pufferüberlauf.

Und wenn ich mich richtig erinnere, wurden die Serverversionen von Windows bereits mit dem gebaut, was so genannt wird Stapelschutz.

Mit anderen Worten, wenn Sie den Stapel innerhalb einer Funktion überlaufen lassen, erkennt die Funktion, bevor sie zurückkehrt und den beschädigten Stapel beschädigt, dass etwas Schlimmes passiert ist.

Es muss also das angreifende Programm herunterfahren, aber die Malware kann nicht ausgeführt werden.

Aber dieser Schutz war damals nicht in den Client-Versionen von Windows enthalten.

Und wie ich mich erinnere, war es eine dieser frühen Malware, die erraten musste, welche Version des Betriebssystems Sie hatten.

Bist du auf 2000? Bist du auf NT? Hast du XP?

Und wenn es falsch war, stürzte ein wichtiger Teil des Systems ab, und Sie erhielten die Warnung „Ihr System wird gleich heruntergefahren“.

---

DOUG.  Ha, an die erinnere ich mich!

---

ENTE.  Es gab also diesen Kollateralschaden, der für viele Menschen das Zeichen dafür war, dass Sie von Infektionen gehämmert wurden …

… die von außen kommen könnten, als wären Sie nur ein Heimanwender und hätten zu Hause keinen Router oder keine Firewall.

Aber wenn Sie sich in einem Unternehmen befanden, würde der wahrscheinlichste Angriff von jemand anderem innerhalb des Unternehmens kommen und Pakete in Ihr Netzwerk spucken.

Also, ganz ähnlich wie bei dem CodeRed-Angriff, über den wir vor ein paar Jahren in einem Podcast gesprochen haben, war es wirklich das schiere Ausmaß, die Lautstärke und die Geschwindigkeit dieses Dings, das das Problem war.

---

DOUG.  Okay, das war vor ungefähr 20 Jahren.

Und wenn wir die Uhr auf vor fünf Jahren zurückdrehen, dann war das der Zeitpunkt Slack begann undicht zu werden gehashte Passwörter. [LACHEN]

---

ENTE.  Ja, Slack, das beliebte Collaboration-Tool…

… es hat eine Funktion, mit der Sie einen Einladungslink an andere Personen senden können, um Ihrem Workspace beizutreten.

Und Sie stellen sich vor: Sie klicken auf eine Schaltfläche mit der Aufschrift „Link generieren“ und es wird eine Art Netzwerkpaket erstellt, das wahrscheinlich JSON enthält.

Wenn Sie jemals eine Zoom-Meeting-Einladung erhalten haben, wissen Sie, dass sie ein Datum und eine Uhrzeit und die Person, die Sie einlädt, und eine URL, die Sie für das Meeting verwenden können, und einen Passcode und all das enthält Sachen – es hat ziemlich viele Daten drin.

Normalerweise graben Sie sich nicht in die Rohdaten ein, um zu sehen, was darin enthalten ist – der Kunde sagt nur: „Hey, hier ist ein Meeting, hier sind die Details. Möchten Sie annehmen / vielleicht / ablehnen?“

Es stellte sich heraus, dass, als Sie dies mit Slack, wie Sie sagen, mehr als fünf Jahre lang gemacht haben, in dieser Einladung irrelevante Daten verpackt waren, die für die Einladung selbst nicht unbedingt relevant waren.

Also keine URL, kein Name, kein Datum, keine Zeit …

…aber der Passwort-Hash des *einladenden Benutzers* [LACHEN]

---

DOUG.  Hmmmmm.

---

ENTE.  Das ist kein Scherz!

---

DOUG.  Das hört sich schlimm an…

---

ENTE.  Ja, das tut es wirklich, nicht wahr?

Die schlechte Nachricht ist, wie um alles in der Welt ist das da reingekommen?

Und wenn es einmal da drin war, wie um alles in der Welt konnte es fünf Jahre und drei Monate lang der Aufmerksamkeit entgehen?

In der Tat, wenn Sie den Artikel über Naked Security besuchen und sich das ansehen vollständige URL des Artikels, werden Sie feststellen, dass es am Ende heißt, blahblahblah-for-three-months.

Denn als ich den Bericht zum ersten Mal las, wollte mein Verstand es nicht als 2017 sehen! [LACHEN]

Es war vom 17. April bis 17. Juli, und da waren viele „17“ drin.

Und ich habe das Jahr 2017 als Startjahr ausgeblendet – ich habe es falsch verstanden als „April bis Juli *dieses Jahres*“ [2022].

Ich dachte: „Wow, *drei Monate* und sie haben es nicht bemerkt.“

Und dann war der erste Kommentar zu dem Artikel: „Ähm [HUSTEN]. Es war tatsächlich der 17. April *2017*.“

Wow!

Aber jemand hat es am 17. Juli [2022] herausgefunden, und Slack hat es zu ihrer Ehre am selben Tag behoben.

Wie: "Oh, verdammt, was haben wir uns dabei gedacht?!"

Das ist also die schlechte Nachricht.

Die gute Nachricht ist, dass es sich zumindest um *gehashte* Passwörter handelte.

Und sie wurden nicht nur gehasht, sie wurden *gesalzen*, wo Sie einzigartig ausgewählte, zufällige Daten pro Benutzer mit dem Passwort mischen.

Die Idee dahinter ist zweigeteilt.

Erstens, wenn zwei Personen dasselbe Passwort wählen, erhalten sie nicht denselben Hash, sodass Sie keine Rückschlüsse ziehen können, indem Sie die Hash-Datenbank durchsuchen.

Und zweitens können Sie kein Wörterbuch bekannter Hashes für bekannte Eingaben vorberechnen, da Sie für jedes Passwort * für jedes Salz * ein separates Wörterbuch erstellen müssen.

Es ist also keine triviale Übung, gehashte Passwörter zu knacken.

Abgesehen davon ist die ganze Idee, dass sie nicht öffentlich bekannt sein sollen.

Sie werden gehasht und gesalzen, *falls* sie auslaufen, nicht *damit sie auslaufen können*.

Also, Ei auf Slacks Gesicht!

Laut Slack war etwa einer von 200 Benutzern oder 0.5 % betroffen.

Aber wenn Sie ein Slack-Benutzer sind, würde ich annehmen, dass sie, wenn sie fünf Jahre lang nicht bemerkt haben, dass sie gehashte Passwörter preisgegeben haben, vielleicht auch die Liste der betroffenen Personen nicht vollständig aufgezählt haben.

Also, geh und ändere trotzdem dein Passwort … du könntest es genauso gut.

---

DOUG.  OK, wir sagen auch: Wenn Sie keinen Passwort-Manager verwenden, sollten Sie sich einen besorgen; und schalten Sie 2FA ein, wenn Sie können.

---

ENTE.  Ich dachte, das würde dir gefallen, Doug.

---

DOUG.  Ja, ich will!

Und dann, wenn Sie Slack oder ein ähnliches Unternehmen sind, wählen Sie a seriöser Salt-Hash-and-Stretch-Algorithmus beim Umgang mit Passwörtern selbst.

---

ENTE.  Ja.

Die große Sache in Slacks Antwort und das, was meiner Meinung nach fehlte, war, dass sie nur sagten: „Keine Sorge, wir haben die Passwörter nicht nur gehasht, wir haben sie auch gesalzen.“

Mein Rat ist, dass Sie, wenn Sie in eine solche Verletzung geraten, bereit sein sollten, den Algorithmus oder Prozess, den Sie zum Salten und Hashen verwendet haben, und idealerweise auch das, was aufgerufen wird, anzugeben Dehnung, wo Sie das Salted-Passwort nicht nur einmal hashen, sondern vielleicht 100,000 Mal hashen, um jede Art von Wörterbuch- oder Brute-Force-Angriffen zu verlangsamen.

Und wenn Sie angeben, welchen Algorithmus Sie verwenden und mit welchen Parametern. PBKDF2, bcrypt, scrypt, Argon2 – das sind die bekanntesten „Salt-Hash-Stretch“-Passwortalgorithmen da draußen.

Wenn Sie tatsächlich angeben, welchen Algorithmus Sie verwenden, dann: [A] Sie sind offener und [B] Sie geben potenziellen Opfern des Problems die Möglichkeit, selbst einzuschätzen, wie gefährlich sie dies für möglich gehalten haben .

Und diese Art von Offenheit kann tatsächlich sehr helfen.

Slack hat das nicht getan.

Sie sagten nur: „Oh, sie wurden gesalzen und gehasht.“

Aber was wir nicht wissen, ist, haben sie zwei Bytes Salt eingefügt und sie dann einmal mit SHA-1 gehasht?

…oder hatten sie etwas, das etwas widerstandsfähiger gegen Risse war?

---

DOUG.  Bleiben wir beim Thema der schlechten Dinge, wir bemerken einen sich entwickelnden Trend, bei dem die Menschen sind Injizieren von schlechtem Zeug in GitHub, nur um zu sehen, was passiert, Risiken aussetzen ...

…wir haben noch eine dieser Geschichten.

---

ENTE.  Ja, jemand, der sich jetzt angeblich auf Twitter geoutet hat und gesagt hat: „Macht euch keine Sorgen, Jungs, nichts passiert. Es war nur für die Recherche. Ich werde einen Bericht schreiben, mich von Blue Alert abheben.“

Sie haben buchstäblich Tausende von gefälschten GitHub-Projekten erstellt, die auf dem Kopieren von vorhandenem legitimem Code basieren und absichtlich einige Malware-Befehle darin eingefügt haben, wie z demnächst.

Also Dinge, die wirklich Schaden anrichten könnten, wenn Sie eines dieser Pakete installieren.

Ihnen echt aussehende Namen zu geben …

… offensichtlich den Commit-Verlauf eines echten Projekts auszuleihen, so dass das Ding viel seriöser aussah, als Sie es sonst erwarten würden, wenn es nur mit „Hey, laden Sie diese Datei herunter. Du willst es doch auch!"

Wirklich?! Forschung?? Das wussten wir noch nicht?!!?

Jetzt können Sie argumentieren: „Nun, Microsoft, denen GitHub gehört, was machen sie, um es den Leuten so einfach zu machen, diese Art von Zeug hochzuladen?“

Und da ist etwas Wahres dran.

Vielleicht könnten sie Malware besser von vornherein fernhalten.

Aber es ist ein bisschen übertrieben zu sagen: „Oh, es ist alles Microsofts Schuld.“

Noch schlimmer finde ich, zu sagen: „Ja, das ist echte Forschung; das ist wirklich wichtig; Wir müssen die Leute daran erinnern, dass dies passieren könnte.“

Nun, [A] das wissen wir bereits, vielen Dank, denn viele Leute haben das schon einmal gemacht; Wir haben die Botschaft laut und deutlich verstanden.

Und [B] das ist *keine* Forschung.

Damit wird bewusst versucht, Menschen dazu zu verleiten, Code herunterzuladen, der einem potenziellen Angreifer die Fernsteuerung ermöglicht, im Gegenzug die Möglichkeit, einen Bericht zu schreiben.

Das klingt für mich eher nach einer „großen fetten Ausrede“ als nach einem legitimen Motivator für die Forschung.

Und deshalb ist meine Empfehlung, wenn Sie denken, dass dies *Forschung ist, und wenn Sie entschlossen sind, so etwas noch einmal zu machen, *erwarten Sie nicht viel Mitgefühl*, wenn Sie erwischt werden.

---

DOUG.  In Ordnung – wir werden darauf und auf die Leserkommentare am Ende der Show zurückkommen, also bleiben Sie dran.

Aber lassen Sie uns zuerst darüber reden Ampel, und was sie mit Cybersicherheit zu tun haben.

---

ENTE.  Ahhh, ja! [LACHEN]

Nun, es gibt ein Ding namens TLP, das Ampelprotokoll.

Und das TLP ist das, was Sie ein „Human Cybersecurity Research Protocol“ nennen könnten, das Ihnen hilft, Dokumente zu kennzeichnen, die Sie an andere Personen senden, um ihnen einen Hinweis darauf zu geben, was Sie von ihnen erwarten (und, was noch wichtiger ist, was Sie von ihnen erwarten * nicht*) mit den Daten zu tun.

Insbesondere, wie weit sollen sie es umverteilen?

Ist das etwas so Wichtiges, dass du es der Welt erklären könntest?

Oder ist das potenziell gefährlich oder enthält es möglicherweise einige Dinge, die wir noch nicht öffentlich machen wollen … also behalte es für dich?

Und es fing an mit: TLP:RED, was bedeutete: „Behalte es für dich“; TLP:AMBER, was bedeutete: „Sie können es innerhalb Ihres eigenen Unternehmens oder an Ihre Kunden verteilen, von denen Sie glauben, dass sie dies dringend wissen müssen“; TLP:GREEN, was bedeutete: "OK, Sie können dies innerhalb der Cybersicherheitsgemeinschaft weit verbreiten lassen."

Und TLP:WHITE, was bedeutete: „Du kannst es jedem erzählen.“

Sehr nützlich, sehr einfach: ROT, GELB, GRÜN… eine Metapher, die global funktioniert, ohne sich Gedanken darüber zu machen, was der Unterschied zwischen „geheim“ und „vertraulich“ ist und was der Unterschied zwischen „vertraulich“ und „klassifiziert“ ist, all das komplizierte Zeug braucht eine ganze Reihe von Gesetzen drumherum.

Nun, der TLP hat gerade einige Modifikationen erhalten.

Wenn Sie sich also mit Cybersicherheitsforschung beschäftigen, stellen Sie sicher, dass Sie sich dessen bewusst sind.

TLP:WHITE wurde in einen meiner Meinung nach viel besseren Begriff geändert, weil Weiß hat all diese unnötigen kulturellen Untertöne, auf die wir in der Moderne verzichten können.

Damit TLP:WHITE ist gerade geworden TLP:CLEAR, was meiner Meinung nach ein viel besseres Wort ist, weil es sagt: „Sie sind bereit, diese Daten zu verwenden“, und diese Absicht wird, ähm, sehr klar zum Ausdruck gebracht. (Entschuldigung, ich konnte dem Wortspiel nicht widerstehen.)

Und es gibt eine zusätzliche Ebene (die Metapher wurde also ein wenig verfälscht – es ist jetzt eine *fünffarbige* Farbampel!).

Es gibt ein spezielles Level namens TLP:AMBER+STRICT, und das bedeutet: „Sie können dies in Ihrem Unternehmen teilen.“

Vielleicht werden Sie zu einem Meeting eingeladen, vielleicht arbeiten Sie für ein Cybersicherheitsunternehmen, und es ist ganz klar, dass Sie dies Programmierern zeigen müssen, vielleicht Ihrem IT-Team, vielleicht Ihren Qualitätssicherungsleuten, damit Sie Nachforschungen anstellen können das Problem oder beschäftigen Sie sich mit der Behebung.

Jedoch müssen auch TLP:AMBER+STRICT bedeutet, dass Sie es zwar innerhalb Ihrer Organisation verbreiten können, aber *bitte sagen Sie es nicht Ihren Kunden oder Ihren Kunden* oder sogar Personen außerhalb des Unternehmens, von denen Sie glauben, dass sie sie wissen müssen.

Halten Sie es zunächst in der engeren Gemeinschaft.

TLP:AMBER, wie zuvor, bedeutet: „OK, wenn Sie das Gefühl haben, dass Sie es Ihren Kunden sagen müssen, können Sie das tun.“

Und das kann wichtig sein, denn manchmal möchten Sie Ihren Kunden vielleicht mitteilen: „Hey, wir haben die Lösung. Sie müssen einige Vorsichtsmaßnahmen ergreifen, bevor der Fix eintrifft. Aber weil es irgendwie sensibel ist, dürfen wir Sie bitten, es der Welt noch nicht zu sagen?

Manchmal spielt es den Gaunern mehr in die Hände als den Verteidigern, es der Welt zu früh zu sagen.

Wenn Sie also ein Cybersecurity-Responder sind, schlage ich vor, dass Sie gehen: https://www.first.org/tlp

---

DOUG.  Und du kannst Lesen Sie mehr darüber auf unserer Website, nakedsecurity.sophos.com.

Und wenn Sie nach einer anderen leichten Lektüre suchen, vergessen Sie die Quantenkryptographie … wir gehen weiter zu Post-Quanten-Kryptographie,Paul!

---

ENTE.  Ja, darüber haben wir schon ein paar Mal im Podcast gesprochen, nicht wahr?

Die Idee eines Quantencomputers, vorausgesetzt, dass ein leistungsstarker und zuverlässig genug gebaut werden könnte, besteht darin, dass bestimmte Arten von Algorithmen gegenüber dem heutigen Stand der Technik beschleunigt werden könnten, entweder um die Quadratwurzel … oder noch schlimmer, die *Logarithmus* des Ausmaßes des heutigen Problems.

Mit anderen Worten, anstatt 2 zu nehmen²⁵⁶ versucht, eine Datei mit einem bestimmten Hash zu finden, können Sie dies möglicherweise in nur („nur“!) 2¹²⁸ versucht, was die Quadratwurzel ist.

Deutlich schneller.

Aber es gibt eine ganze Klasse von Problemen, bei denen es um die Faktorisierung von Produkten von Primzahlen geht, von denen die Theorie sagt, dass sie im *Logarithmus* der Zeit geknackt werden könnten, die sie heute, grob gesagt, benötigen.

Anstatt also beispielsweise 2 zu nehmen¹²⁸ Tage zu knacken [WEIT LÄNGER ALS DAS AKTUELLE ALTER DES UNIVERSUMS], es könnte nur 128 Tage dauern, um zu knacken.

Oder Sie können „Tage“ durch „Minuten“ oder was auch immer ersetzen.

Und leider ist dieser logarithmische Zeitalgorithmus (genannt Shors Quantenfaktorisierungsalgorithmus)… das könnte theoretisch auf einige der heutigen kryptografischen Techniken angewendet werden, insbesondere auf diejenigen, die für die Kryptografie mit öffentlichen Schlüsseln verwendet werden.

Und für den Fall, dass diese Quantencomputer in den nächsten Jahren realisierbar werden, sollten wir vielleicht jetzt damit beginnen, uns auf Verschlüsselungsalgorithmen vorzubereiten, die für diese beiden speziellen Angriffsklassen nicht anfällig sind?

Besonders der logarithmische, weil er potenzielle Angriffe so stark beschleunigt, dass kryptografische Schlüssel, von denen wir derzeit denken: „Nun, das wird nie jemand herausfinden“, zu einem späteren Zeitpunkt aufgedeckt werden könnten.

Wie auch immer, NIST, die National Institute of Standards and Technology in den USA, führt seit mehreren Jahren einen Wettbewerb durch, um zu versuchen, einige öffentliche, nicht patentierte, gut geprüfte Algorithmen zu standardisieren, die gegen diese magischen Quantencomputer resistent sein werden, falls sie jemals auftauchen sollten.

Und vor kurzem haben sie vier Algorithmen ausgewählt, die sie jetzt standardisieren wollen.

Sie haben coole Namen, Doug, also muss ich sie vorlesen: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCON und SPHINCS+. [LACHEN]

Sie haben also zumindest coole Namen.

Aber gleichzeitig dachte sich NIST: „Nun, das sind nur vier Algorithmen. Was wir tun werden, ist, dass wir vier weitere als potenzielle Zweitkandidaten auswählen, und wir werden sehen, ob einer von ihnen ebenfalls durchkommen sollte.“

Es gibt also jetzt vier standardisierte Algorithmen und vier Algorithmen, die in Zukunft standardisiert werden könnten.

Oder es *waren* am 5. Juli 2022 vier, und einer davon war es SIKE, kurz für supersinguläre isogene Schlüsselkapselung.

(Wir brauchen mehrere Podcasts, um supersinguläre Isogenen zu erklären, also werden wir uns nicht darum kümmern. [LACHEN])

Aber unglücklicherweise sieht es so aus, als wäre dieses hier, das mit einer Kampfchance auf Standardisierung dort hing, unwiederbringlich kaputt, obwohl es bereits mindestens fünf Jahre lang der öffentlichen Prüfung ausgesetzt war.

Glücklicherweise, kurz bevor es standardisiert wurde oder werden konnte, fanden zwei belgische Kryptografen heraus: „Weißt du was? Wir glauben, dass wir dies umgehen können, indem wir Berechnungen verwenden, die etwa eine Stunde dauern, auf einer ziemlich durchschnittlichen CPU und mit nur einem Kern.“

---

DOUG.  Ich denke, es ist besser, das jetzt herauszufinden, als es zu standardisieren und in die Wildnis zu bringen?

---

ENTE.  In der Tat!

Ich denke, wenn es einer der Algorithmen gewesen wäre, die bereits standardisiert wurden, müssten sie den Standard aufheben und einen neuen entwickeln?

Es scheint seltsam, dass dies fünf Jahre lang nicht bemerkt wurde.

Aber ich denke, das ist die ganze Idee der öffentlichen Kontrolle: Man weiß nie, wann jemand gerade auf den benötigten Riss trifft, oder den kleinen Keil, mit dem er einbrechen und beweisen kann, dass der Algorithmus nicht so stark ist, wie ursprünglich angenommen.

Eine gute Erinnerung daran, dass, wenn Sie *jemals* daran gedacht haben, Ihre eigene Kryptografie zu stricken …

---

DOUG.  [LACHT] Habe ich nicht!

---

ENTE.  ..obwohl wir Ihnen im Naked Security-Podcast N-mal gesagt haben: „Tu das nicht!“

Dies sollte die ultimative Erinnerung daran sein, dass selbst wenn echte Experten einen Algorithmus veröffentlichen, der fünf Jahre lang in einem globalen Wettbewerb der öffentlichen Prüfung unterzogen wird, dies immer noch nicht unbedingt genug Zeit bietet, um Fehler aufzudecken, die sich als ziemlich schlimm herausstellen.

Dafür sieht es also sicher nicht gut aus SIKE Algorithmus.

Und wer weiß, vielleicht wird es zurückgezogen?

---

DOUG.  Wir werden das im Auge behalten.

Und während die Sonne für unsere Show für diese Woche langsam untergeht, ist es an der Zeit, von einem unserer Leser über die GitHub-Story zu hören, die wir zuvor besprochen haben.

Rob schreibt:

„In den Kommentaren steckt etwas Kreide und Käse, und ich hasse es, das zu sagen, aber ich kann wirklich beide Seiten des Arguments sehen. Ist es gefährlich, lästig, zeitraubend und ressourcenintensiv? Ja, natürlich ist es das. Ist es das, was kriminell gesinnte Typen tun würden? Ja Ja es ist. Ist es eine Erinnerung für jeden, der GitHub oder ein anderes Code-Repository-System verwendet, dass sicheres Reisen im Internet ein gesundes Maß an Zynismus und Paranoia erfordert? Ja. Als Systemadministrator möchte ein Teil von mir die Offenlegung des vorliegenden Risikos begrüßen. Als Systemadministrator für eine Reihe von Entwicklern muss ich jetzt sicherstellen, dass jeder kürzlich alle Pulls nach fragwürdigen Einträgen durchsucht hat.“

---

ENTE.  Ja, danke, RobB, für diesen Kommentar, denn ich denke, es ist wichtig, beide Seiten des Arguments zu sehen.

Es gab Kommentatoren, die nur sagten: „Was zum Teufel ist das Problem dabei? Das ist toll!"

Eine Person sagte, „Nein, eigentlich ist dieser Pentest gut und nützlich. Seien Sie froh, dass diese jetzt aufgedeckt werden, anstatt ihren hässlichen Kopf vor einem echten Angreifer zu erheben.“

Und meine Antwort darauf ist: „Nun, das *ist* eigentlich ein Angriff.“

Es ist nur so, dass jetzt hinterher jemand herausgekommen ist und gesagt hat: „Oh, nein, nein. Keinen Schaden angerichtet! Ehrlich gesagt war ich nicht ungezogen.“

Ich glaube nicht, dass Sie verpflichtet sind, diese Entschuldigung zu kaufen!

Aber wie auch immer, das ist kein Penetrationstest.

Meine Antwort war ganz einfach: „Verantwortliche Penetrationstester handeln immer nur [A] nach Erhalt der ausdrücklichen Erlaubnis und [B] innerhalb ausdrücklich im Voraus vereinbarter Verhaltensgrenzen.“

Sie stellen nicht einfach Ihre eigenen Regeln auf, und wir haben dies bereits besprochen.

Also, wie ein anderer Kommentator sagte, das ist, glaube ich, mein Lieblingskommentar … sagte Ecurb, „Ich denke, jemand sollte von Haus zu Haus gehen und Fenster einschlagen, um zu zeigen, wie ineffektiv Türschlösser wirklich sind. Dies ist überfällig. Jemand springt bitte darauf.“

Und dann, nur für den Fall, dass Sie nicht gemerkt haben, dass das Satire war, Leute, sagt er, "Nicht!"

---

ENTE.  Ich habe die Idee, dass es eine gute Erinnerung ist, und ich habe die Idee, dass es Dinge gibt, die Sie tun können, wenn Sie ein GitHub-Benutzer sind, sowohl als Produzent als auch als Verbraucher.

Wir listen sie in den Kommentaren und im Artikel auf.

Setzen Sie zum Beispiel eine digitale Signatur auf alle Ihre Commits, damit es offensichtlich ist, dass die Änderungen von Ihnen stammen, und es eine Art Rückverfolgbarkeit gibt.

Und konsumieren Sie nicht einfach blind Sachen, weil Sie eine Suche durchgeführt haben und es „aussah“, als wäre es das richtige Projekt.

Ja, wir können alle daraus lernen, aber zählt das eigentlich als Lehre, oder sollten wir das sowieso nur lernen?

Ich denke, das ist *kein* Unterricht.

Es ist einfach *nicht hoch genug*, um als Forschung zu gelten.

---

DOUG.  Tolle Diskussion rund um diesen Artikel und vielen Dank für die Einsendung, Rob.

Wenn Sie eine interessante Geschichte, einen Kommentar oder eine Frage haben, die Sie einreichen möchten, würden wir sie gerne im Podcast lesen.

Sie können eine E-Mail senden tips@sophos.com; Sie können jeden unserer Artikel kommentieren; oder Sie können uns in den sozialen Netzwerken besuchen: @NakedSecurity.

Das ist unsere Show für heute – vielen Dank fürs Zuhören.

Für Paul Ducklin bin ich Doug Aamoth und erinnere Sie bis zum nächsten Mal daran, …

---

BEIDE.  Bleib sicher!

[MUSIKMODEM]