Nicht-Programmierer sind immer skeptisch, wenn ehrliche Entwickler die Techniken von Black-Hat-Hackern erlernen. Natürlich müssen wir viele ihrer Tricks lernen, damit wir unsere eigene Sicherheit auf dem neuesten Stand halten können.
Inwieweit muss ein ehrlicher Programmierer Ihrer Meinung nach die Methoden bösartiger Programmierer kennen?
Antworten:
Ich komme zu spät, da ich gerade im Podcast davon gehört habe. Ich werde jedoch meine Meinung als jemand abgeben, der im Sicherheitsteam eines Softwareunternehmens gearbeitet hat.
Wir haben die Entwicklerausbildung sehr ernst genommen und so viele Entwicklerteams wie möglich in Grundbildung für sichere Entwicklung geschult. Das Nachdenken über Sicherheit erfordert wirklich eine Abkehr vom Denken von der normalen Entwicklung. Daher würden wir versuchen, Entwickler dazu zu bringen, in einer Denkweise zu denken, wie man Dinge kaputt macht. Eine Requisite, die wir verwendeten, war einer dieser Heimtresore mit der digitalen Tastatur. Wir würden Entwickler es von innen und außen untersuchen lassen, um zu versuchen, einen Weg zu finden, wie sie darin einbrechen können. (Die Lösung bestand darin, Druck auf den Griff auszuüben, während der Safe oben scharf geschlagen wurde, wodurch der Bolzen an seiner Feder im Magneten abprallte.) Wir würden ihnen zwar keine speziellen Black-Hat-Techniken geben, aber wir Ich würde über die Implementierungsfehler sprechen, die diese Sicherheitslücken verursachen - insbesondere über Dinge, auf die sie zuvor möglicherweise noch nicht gestoßen sind. wie Ganzzahlüberläufe oder Compiler, die Funktionsaufrufe optimieren (wie Memset zum Löschen von Passwörtern). Wir haben intern einen monatlichen Sicherheits-Newsletter veröffentlicht, in dem Entwickler aufgefordert wurden, sicherheitsrelevante Fehler in kleinen Codebeispielen zu erkennen, die sicherlich zeigten, wie viel sie vermissen würden.
Wir haben auch versucht, den Sicherheitsentwicklungszyklus von Microsoft zu verfolgen, bei dem Entwickler dazu gebracht werden, über die Architektur ihrer Produkte zu sprechen und die Assets und möglichen Möglichkeiten zum Angriff auf diese Assets herauszufinden.
Für das Sicherheitsteam, das hauptsächlich aus ehemaligen Entwicklern bestand, war es uns sehr wichtig, die Black-Hat-Techniken zu verstehen. Wir waren unter anderem dafür verantwortlich, Sicherheitswarnungen von Dritten zu erhalten, und zu wissen, wie schwierig es für einen schwarzen Hut sein würde, eine gewisse Schwäche auszunutzen, war ein wichtiger Teil des Triage- und Ermittlungsprozesses. Und ja, gelegentlich habe ich einen Debugger durchlaufen, um Speicherversätze anfälliger Routinen zu berechnen und ausführbare Binärdateien zu patchen.
Das eigentliche Problem ist jedoch, dass vieles davon über die Fähigkeiten der Entwickler hinausging. Jedes Unternehmen mit angemessener Größe wird viele Entwickler haben, die gut genug darin sind, Code zu schreiben, aber einfach nicht über die Sicherheitsmentalität verfügen. Meine Antwort auf Ihre Frage lautet also: Die Erwartung, dass alle Entwickler über Black-Hat-Kenntnisse verfügen, wäre eine unerwünschte und nachteilige Belastung, aber jemand in Ihrem Unternehmen sollte über dieses Wissen verfügen, sei es ein Sicherheitsaudit- und Reaktionsteam oder nur leitende Entwickler .
Letztendlich ist nichts, was die "schwarzen Hüte" wissen, kriminelles Wissen, sondern nur, wie das Wissen angewendet wird. Ein tiefes Verständnis für jede Technologie ist als Programmierer wertvoll. So holen wir das Beste aus dem System heraus. Es ist heutzutage möglich, ohne Kenntnis der Tiefen auszukommen, da wir immer mehr Frameworks, Bibliotheken und Komponenten haben, die mit diesem Wissen geschrieben wurden, damit Sie nicht alles wissen müssen, aber es ist immer noch gut, von Zeit zu Zeit zu graben.
Ich werde ein bisschen ketzerisch sein und mich auf die Beine stellen und sagen:
Wenn Sie ein Programm schreiben, präsentieren Sie eine (hoffentlich) nahtlose, reibungslose Schnittstelle zu $ {was auch immer-sonst-akzeptiert-Ihre-Programme-E / A}. In diesem Fall kann es sich um einen Endbenutzer oder um einen anderen Prozess auf einem anderen Computer handeln, dies spielt jedoch keine Rolle. Gehen Sie IMMER davon aus, dass der "Client" Ihrer Anwendung möglicherweise feindlich eingestellt ist, unabhängig davon, ob es sich um eine Maschine oder eine Person handelt.
Glaubst du mir nicht? Versuchen Sie, eine kleine App zu schreiben, die Kundenaufträge von Verkäufern entgegennimmt, und legen Sie dann eine Unternehmensregel fest, die Sie über diese App durchsetzen müssen. Die Verkäufer versuchen jedoch ständig, sich fortzubewegen, damit sie mehr Geld verdienen können. Allein diese kleine Übung zeigt, wie ein motivierter Angreifer - in diesem Fall der beabsichtigte Endbenutzer - aktiv nach Wegen sucht, um entweder logische Fehler auszunutzen oder das System auf andere Weise zu spielen. Und das sind vertrauenswürdige Endbenutzer!
Multiplayer-Online-Spiele befinden sich ständig im Krieg gegen Betrüger, da die Serversoftware normalerweise dem Client vertraut. In allen Fällen kann und wird der Client gehackt, was dazu führt, dass Spieler das System spielen. Denken Sie darüber nach - hier haben wir Menschen, die sich einfach amüsieren und extreme Maßnahmen ergreifen, um bei einer Aktivität, bei der es nicht darum geht, Geld zu verdienen, die Oberhand zu gewinnen.
Stellen Sie sich die Motivation eines professionellen Bot-Herders vor, der auf diese Weise sein Geld für seinen Lebensunterhalt verdient ... Malware schreibt, damit er die Maschinen anderer Leute als Einnahmequellen nutzen und seine Botnets an den Höchstbietenden für massive Spam-Fluten verkaufen kann ... ja , dies wirklich nicht passieren .
Unabhängig von der Motivation bleibt der Punkt bestehen, Ihr Programm kann und wird irgendwann angegriffen werden. Es reicht nicht aus, sich vor Pufferüberläufen , Stapelzerstörung , Stapelausführung (Code-as-Data wird in den Stapel geladen, dann erfolgt eine Rückgabe zum Entladen des Stapels, was zur Ausführung des Codes führt), Datenausführung , standortübergreifend zu schützen Skripterstellung , Eskalation von Privilegien , Rennbedingungenoder andere "programmatische" Angriffe, obwohl es hilft. Zusätzlich zu Ihrer "Standard" -Programmabwehr müssen Sie auch in Bezug auf Vertrauen, Überprüfung, Identität und Anmeldeinformationen denken - mit anderen Worten, sich mit dem befassen, was Ihre Programmeingabe liefert und was die Ausgabe Ihres Programms verbraucht. Wie verteidigt man sich beispielsweise aus programmatischer Sicht gegen DNS-Vergiftungen ? Und manchmal können Sie Dinge im Code nicht vermeiden - es ist ein Beispiel, Ihre Endbenutzer dazu zu bringen, ihre Passwörter nicht an Kollegen weiterzugeben.
Integrieren Sie diese Konzepte in eine Methodik für Sicherheit und nicht in eine "Technologie". Sicherheit ist ein Prozess, kein Produkt . Wenn Sie darüber nachdenken, was "auf der anderen Seite" Ihres Programms ist und welche Methoden Sie anwenden können, um diese Probleme zu mindern, wird viel klarer, was richtig und was schrecklich falsch laufen kann.
Größtenteils. Sie müssen wie ein Verbrecher denken, oder Sie sind nicht paranoid genug.
Inwieweit muss ein ehrlicher Programmierer Ihrer Meinung nach die Methoden bösartiger Programmierer kennen?
Sie müssen mehr als sie wissen .
Ich arbeite als Sicherheitsbeamter, nicht als Entwickler, und aufgrund meiner Erfahrung kann ich einfach sagen, dass Sie nicht so gut lernen können wie schwarze oder professionelle weiße Hüte, es sei denn, es ist Ihr zweiter Beruf. Es ist einfach zu zeitaufwändig.
Das Wichtigste ist jedoch, einige Bösewichte oder Profis beim Handeln zu sehen und zu verstehen, welche Möglichkeiten und Auswirkungen unsicherer Code bietet.
Wenn man also einige Tricks lernt, aber viele davon, kann man das Gefühl eines "falschen Sicherheitsgefühls" bekommen, weil er oder sie nicht hacken kann. Obwohl ein besser ausgebildeter Angreifer innerhalb von Minuten dasselbe hacken könnte.
Trotzdem denke ich, sobald Sie dies bedenken, ist es gut, einige Angriffe zu lernen, die Spaß machen und ziemlich lehrreich sind, um zu lernen, wie man Dinge kaputt macht.
Lerne auf jeden Fall die dunkle Seite. Auch wenn Sie die tatsächlichen Techniken nicht lernen, bemühen Sie sich zumindest zu lernen, was möglich ist.
Gute Ressourcen, um die Tricks des Handels zu lernen, sind Reversing: Geheimnisse des Reverse Engineering und Hacking: Die Kunst der Ausbeutung . Sie sind für beide Seiten geschrieben - diese könnten verwendet werden, um zu lernen, wie man hackt, aber sie geben auch Möglichkeiten, um diese Art von Angriffen zu verhindern.
Es lohnt sich, so "unschuldig wie Tauben und so weise wie Schlangen" zu sein und Techniken zu lernen, die Leute mit schändlichen Absichten anwenden. Trotzdem sollte dieses Wissen sorgfältig genutzt werden. "Mit großer Macht kommt große Verantwortung".
Ein Wort der Vorsicht: Bundesstaat Oregon gegen Randal Schwartz .
Nachdem ich nur einen kleinen Teil der Untersuchung von zwei verschiedenen Vorfällen auf unserer Website durchgeführt habe, würde ich sagen, dass die Chancen, etwas über einen Exploit zu erfahren, bevor er gegen Sie eingesetzt wird, verschwindend gering sind. Wenn Sie Ihre Karriere dem Thema "Weißer Hut" widmen, bleiben Sie möglicherweise über alle potenziellen Lücken in den meisten gängigen Hardware- / Software-Stacks auf dem Laufenden. Für einen normalen Programmierer ist es jedoch wahrscheinlicher, dass Sie sich im Reaktionsmodus befinden.
Sie haben die Verantwortung zu wissen, wie Ihre eigene Software gehackt werden kann, und die Verantwortung, mit Software von Drittanbietern einigermaßen auf dem neuesten Stand zu bleiben. Es wäre gut, einen Notfallplan zur Bewältigung eines Angriffs zu haben, insbesondere wenn Sie ein hochkarätiges oder wertvolles Ziel sind. Einige Orte möchten sofort ein Loch schließen, aber auf unserer Website bleiben bestimmte Löcher offen, um die Strafverfolgung bei der Aufdeckung der Täter zu unterstützen. Das IT-Sicherheitsteam kündigt gelegentlich intern an, dass es einen Port-Scan durchführen wird, damit SAs nicht darüber ausflippen.
Eine Fähigkeit, die oft übersehen wird, ist Social Engineering.
Viele Menschen erkennen einfach nicht, wann sie betrogen werden. In einem früheren Unternehmen führte ein Vizepräsident einen Test durch, bei dem drei (weibliche) Zeitarbeiter in einem Konferenzraum Programmierer und Systemadministratoren anriefen und anhand eines Skripts versuchten, jemanden dazu zu bringen, Zugriff zu gewähren oder Passwörter preiszugeben. Jeder der Zeitarbeiter hatte in der ersten Stunde des Anrufs Zugang zu etwas.
Ich wette, wenn ein ähnlicher Test bei einem mittelgroßen bis großen Unternehmen durchgeführt würde, würden sie die gleichen Ergebnisse erzielen.
Ich denke, ein Teil des defensiven Codierens beinhaltet das Kennen bösartiger Techniken, aber gleichzeitig müssen Sie nicht unbedingt alle Techniken kennen, um sich effektiv gegen sie zu verteidigen. Das Wissen über Pufferüberlaufangriffe ist beispielsweise nicht der Grund, Ihre Puffer vor Überlaufen zu schützen. Sie schützen sie vor Überlaufen, da dies in Ihrem Programm zu Chaos führen kann, unabhängig davon, ob es sich um einen Fehler oder einen Angriff handelt.
Wenn Sie sehr gründlich überprüften und gut strukturierten Code schreiben, können die böswilligen Angriffe nicht eindringen, da eine gute Architektur Nebenwirkungen und unbefugten Zugriff automatisch ausschließen sollte.
In diesem letzten Absatz wird jedoch davon ausgegangen, dass wir einen perfekten Job haben, bei dem wir unglaublich viel Zeit haben, um unseren Code genau richtig zu machen . Da es einen solchen Job nicht gibt, ist es eine gute Abkürzung, die schädlichen Techniken zu kennen, da dies bedeutet, dass Sie, obwohl Ihr Code nicht perfekt ist, für diese Exploits "Un-Workarounds" erstellen können, um sicherzustellen, dass sie nicht erhalten werden durch. Aber diese verbessern den Code nicht und sie verbessern die Anwendung nicht.
Letztendlich ist es gut, sich über böswillige Exploits im Klaren zu sein, aber 95% davon werden abgedeckt, indem Sie einfach sicherstellen, dass Sie die Best Practices einhalten.
Design für das Böse . "Wenn das Gute dumm ist, wird das Böse immer triumphieren."
Kurz gesagt, wenn Sie nicht wie ein Verbrecher denken, heißt das nicht, dass die Verbrecher dies nicht tun.
Eine der Techniken, die die White Hats lernen müssen, ist das Testen / Abschwächen / Denken in Bezug auf Social Engineering, da die größte Sicherheitsbedrohung die Menschen sind.
Weiße Hüte sind gut darin, Teile zu manipulieren, aber Menschen werden viel häufiger von den schwarzen Hüten manipuliert.
Ich werde die kontroverse Haltung einnehmen und sagen, dass es einige Black-Hat-Kenntnisse gibt, dass Sie kein guter White-Hat-Hacker sein müssen. Ein Arzt muss nicht wissen, wie man ein Virus gentechnisch verändert, um Krankheiten effektiv zu behandeln.
Wir weißen und grauen Hüte müssen in einer Million Dingen gut sein. Diese schwarzen Hüte und Skiddies müssen nur mit einer Sache erfolgreich sein
Grundsätzlich sind fast alle von Hackern verwendeten Sicherheits-Exploits Fehler im Code, die durch einen schlechten Programmierstil oder schlechte Disziplinen verursacht werden. Wenn Sie Code schreiben, um sich vor fehlerhaften Daten und ungültigen Anrufvorgängen zu schützen, blockieren Sie die meisten Sicherheitslücken in Ihrem Code.
Wenn Sie daran interessiert sind, Ihren Code vor Hacking / Missbrauch / etc. Zu schützen. Sie werden viel zu viel Zeit damit verbringen. Kaufen Sie einfach ein Paket, um die Grundlagen zu schützen, und fahren Sie fort.
Sie müssen die Methoden verstehen, die die "bösen Jungs" anwenden, daher ist ein gewisses Verständnis erforderlich.
Für den durchschnittlichen Entwickler reicht es meiner Meinung nach aus, das Grundprinzip seiner Arbeit zu verstehen, um zu vermeiden, dass in ihren Projekten Schwachstellen entstehen.
Für jemanden, der in einem sicherheitsrelevanten Bereich arbeitet (Bankgeschäfte oder Kreditkartendaten aus einem Online-Shop), ist ein tieferes Verständnis erforderlich. Diese Entwickler müssen „unter die Haube“ gehen, wie ein „Bösewicht“ funktioniert und welche Techniken er verwendet.
Bis zu dem Punkt, an dem er durch das Erlernen ihrer Wege beginnt, in ihre Richtung zu denken. Und dann muss er wählen, zu welcher Seite er "gehören" will.
Die Technologie selbst enthält nichts Bösartiges ... Wissen ist rein ... es ist die Art und Weise, wie Sie es verwenden, die bestimmt, wie es betrachtet werden soll.
2 Seiten derselben Münze. Anders als Vorsatz - was ist die Frage? Gleiche Fähigkeiten, unterschiedliche Umsetzung.
Wenn ich das Wort Blackhat höre, denke ich an jemanden, der Computerkenntnisse nutzt, um in Banken einzudringen und andere schelmische Dinge zu tun. Ein Whitehat weiß alles , was der Blackhat weiß, macht aber nichts Schlechtes damit.
Daher ist es Ihnen egal oder Sie wissen nicht , was ein "Blackhat" ist, um sicher zu sein ...
Zu wissen, wie ein Blackhat denkt , wenn Sie bereits ein gleichwertiger Weißhut sind, hilft nicht, in die Hocke zu gehen. Es ist wie zu wissen, "John will in mein Haus einbrechen und meine iPod-Musik stehlen". Wenn Sie sich wirklich für Ihre iPod-Musik interessiert haben, sollten Sie sie trotzdem sicher haben.