| Online | Gäste: 16
Mitglieder: 0
Auf dieser Seite: 2
Mitglieder: 2966, neuestes ist hacbunny |
| Neueste 5 Downloads |  Sophos A bis Z der Computersicherheit
Sophos, Allgemein (Dokumente), 20. Jul 08 : 12:10
Dieses Büchlein wird von Sophos zu Werbezwecken verdient. Es stellt in einem ersten Teil die Bedrohungen von A bis Z, wie man sie im Internet antrifft, vor. In gleicherweise werden im zweiten Teil Schutzmassnahmen erwähnt. Kurz und bündig wird so der Leser an die Materie herangeführt. Technische Details und weiterführende Diskussionen fehlen, so dass es wirklich nur als seichte Unterhaltung und Einführung gedacht ist.
eBay Hack (S.M.)
S.M. (aka. SevenUp), Social Hacking (Dokumente), 20. Jul 08 : 12:03
Dieses nicht unumstrittene Dokument bespricht Schritt für Schritt, wie ein technisch gestütztes Phishing per HTML-Email und PHP-Skript durchgeführt werden kann, um Login-Informationen für eBay abzufangen. Der Beitrag weist einige technische Fehler auf und ist zu grossen Teilen veraltet. Aus diesem Grund wird ihm primär nur noch historisches Interesse entgegengebracht.
Angriff und Verteidigung in Computernetzen
Alexander Koch, Allgemein (Dokumente), 20. Jul 08 : 11:57
Die leider etwas karge Präsentation beleuchtet verschiedene Gesetzesartikel, die auf Computerangriffe und Strike-Back-Verfahren angewendet werden können. Dabei werden sowohl die deutsche als auch die schweizerische Rechtssprechung berücksichtigt. Ein interessanter Beitrag, der die Gefahren von automatisierten Schutzmechanismen auf einer nicht-technischen Ebene zu verdeutlichen in der Lage ist.
Cross-Site Scripting (Compass)
Ivan Bütler, Webserver (Dokumente), 20. Jul 08 : 11:49
In diesem einfachen Artikel werden die Grundlagen von Cross Site Scripting-Attacken aufgezeigt. Dabei werden sowohl serverseitige als auch clientseitige Varianten besprochen und zudem darauf hingewiesen, dass sich dies mit jeglicher Art von Scripting (JavaScript, VBscript, etc.) durchsetzen lässt. Die Einfachheit des Papiers macht es vor allem für Einsteiger leicht zu lesen.
Internet Networking - Measuring Distance and Bandwidth between Hosts
Werner König, Netzwerke (Dokumente), 01. Apr 08 : 21:43
In dieser Seminararbeit werden diverse Algorithmen zur Berechnung von Bandbreiten bestimmter Verbindungen zwischen Hosts besprochen. Es werden Troughput, Pathchar und vor allem Packet Pair beschrieben sowie ihre Vor- und Nachteile dargestellt. Ein interessantes Gebiet, welches ausserhalb akademischer Bereiche fast keine Beachtung findet.
Zeige alle Downloads (902 Total) |
| An diesem Tag... |  2006: Gericht weist einstweilige Verfügung gegen Wikimedia Deutschland wegen dem Namen von Tron ab
2006: eBay prüft erstmals Sicherheit von Kunden-Passwörtern und informiert die Kunden darüber
Zeige alle Einträge (711 Total) |
| Buchtipp | 
Internetworking with TCP/IP, Volume 3: Client-Server Programming and Applications (Linuxposix Sockets Version)
von Douglas E. Comer und David L. Stevens |
| | Sie sind zur Zeit nicht angemeldet und haben deshalb nur Gast-Privilegien. Einige Funktionen (z.B. Postings, Kommentare, Bewertungen, Statistiken) sind deshalb deaktiviert. Zudem ist für Gäste in einigen Bereichen Werbung geschaltet.
Melden Sie sich an und loggen Sie sich ein, um Zugriff auf sämtliche Bereiche zu erhalten. |
| Sicherheitsüberprüfungen als Prozess (Montag, 8. Februar 2010 - 07:53:39) |
 [Marc's Blog] Im Bereich der Informationssicherheit geniesst wohl kein Zitat solche Bekanntheit, wie jenes von Bruce Schneier:
"Security is not a product; it's a process."
Dieses lässt sich in zweierlei Hinsicht auf Sicherheitsüberprüfungen übertragen. So ist eine Sicherheitsüberprüfung als solche kein Produkt, welches erstellt und ohne Aufwände immerwieder genutzt werden kann. Viel mehr ist das Vorbereiten und Durchführen einer Sicherheitsüberprüfung ein fortwährender Prozess, der die individuellen Eigenarten des Auftrags (unterschiedliche Bedürfnisse) sowie die technischen Entwicklungen der Zeit zu berücksichtigen hat.
Zudem sind Sicherheitsüberprüfungen nicht nur durch die Sammlung von und das Zurückgreifen auf Software und Tools definiert. Der intelligente Einsatz der jeweiligen Werkzeuge entscheidet massgeblich über die Qualität der jeweiligen Sicherheitsüberprüfung.
Eine Sicherheitsüberprüfung generiert sich aus einem Bedürfnis. Das Bedürfnis ist oftmals, dass eine potentielle Bedrohung und das daraus resultierende Risiko verifiziert/falsifiziert werden will. Es gilt zu prüfen, ob und inwiefern die Auswirkungen eintreten können, wie mit diesen umgegangen werden kann und ob man sich den damit verbundenen Risiken aussetzen will. Als erstes gilt es sich sodann zu fragen, aus welchem Bedürfnis eine Sicherheitsüberprüfung angestrebt wird. Durch das Ermitteln des Bedürfnisses kann sodann der Modus der Überprüfung abgeleitet werden:
* Identifikation von möglichen Schwachstellen.
* Verifikation von erwarteten Schwachstellen.
* Identifikation von Auswirkungen erwarteter Risiken.
Es gibt drei unterschiedliche Herangehensweisen, wie sodann eine Sicherheitsüberprüfung durchgeführt werden kann. Die gern diskutierte Variante sieht vor, dass die Auditoren keinen Kontakt zu den zuständigen Stellen der zu prüfenden Umgebung halten. Damit will ein Real-World Szenario generiert werden, welches die Voraussetzungen für einen echten Angriff schafft. Dieser Ansatz führt jedoch verschiedene Probleme mit sich. Auf technischer und wirtschaftlicher Ebene kann mit diesem Blackbox-Ansatz niemals die Performance einer intelligenten Zusammenarbeit erreicht werden. Die Auditoren müssen sich in mühsamer Weise mit den Eigenarten der Zielumgebung auseinandersetzen. Das technische Wissen kann erst nach einer langwierigen Datensammlung zum Zug kommen.
Um diese Einschränkungen zu umgehen, empfehlen wir in den allermeisten Fällen eine sogenannte Whitebox-Herangehensweise. Dabei wird die direkte Zusammenarbeit mit den zuständigen Stellen realisiert. Diese werden über die anstehende Prüfung informiert. Dadurch wird es möglich, dass sie die Auditoren schon früh auf potentielle Mängel hinweisen können. Zusätzliche Informationen zur Zielumgebung erlauben es den Auditoren, sehr schnell und effizient die effektiven Probleme aufspüren und sich diesen widmen zu können.
Je nach Definition können sodann verschiedene Testobjekte bestimmt werden. Dies können zum Beispiel das Netzwerk, Sicherheitskomponenten im Netzwerk (z.B. Router und Firewall), Betriebssystem, Server-Dienste, Applikationen oder Applikationsfunktionen sein. Es sollte hierbei eine klare Abgrenzung stattfinden. Bei einem Web Application Penetration Test wird sich zum Beispiel auf eine Webapplikation und auf Teile des Webservers konzentriert. Die Funktionalität des Betriebssystems ist zweitrangig und wird in der Regel nicht berücksichtigt. Diese klare Abgrenzung verhindert es, dass bei einem Test Diskussionen entstehen, warum Probleme in einer bestimmten Komponente, die nicht Teil der Prüfung war, nicht gefunden wurden.
Die Testreihen können sodann in granularer Weise ausgearbeitet werden. Zum Beispiel kann eine Webapplikation aus Sicht eines anonymen Benutzers ohne Benutzerkonto analysiert werden. Oder aus Sicht eines legitimen Benutzers mit funktionierenden Zugangsdaten und einem normalen Benutzerstatus. Jenachdem werden hier also unterschiedliche Angreifertypen und mit ihnen Szenarien definiert.
Sind die Testreihen definiert worden, generieren sich aus diesen unweigerlich die durchzuführenden Zugriffe und die dafür einzusetzenden Tools. Bei einem reinen Web Application Penetration Test werden zum Beispiel erweiterte Funktionen von nmap als Portscanner nicht benötigt. Stattdessen rücken Addons für Mozilla Firefox oder CGI-Scanner in den Mittelpunkt.
Die technische Durchführung einer Sicherheitsüberprüfung richtet sich nach den technischen Gegebenheiten der Zielumgebung und den anzuwendenden Tests. Diese können hier nicht in angemessenem Umfang diskutiert werden. Wir empfehlen das Konsultieren entsprechender Fachliteratur.
Unabhängig davon, ob eine Blackbox- oder Whitebox-Herangehensweise gewählt wird, sollten die Betreiber der angegangenen und tangierten Umgebungen über die Prüfungen informiert werden. Durch ein explizites Definieren eines Zeitfensters können die nötigen Stellen die erforderliche Bereitschaft herstellen, um bei Problemen unmittelbar reagieren zu können (z.B. Neustart eines Systems bei einem Absturz). Durch das An- und Abmelden bei den zuständigen Stellen wird für alle Beteiligten Transparenz erreicht. Dies dient auch zum Schutz des Auditors, der bei Problemen nach einem Test darauf verweisen kann, dass diese erst nach der Abmeldung erfolgt sind und deshalb nicht direkt auf die Testzugriffe zurückzuführen sind.
Wird eine Blackbox-Herangehensweise angestrebt, bei der die Arbeit von Personen geprüft wird, die nicht vorinformiert werden sollen (z.B. weil sie sonst kurzeitig Massnahmen ergreifen, die das Mass der bereitgestellten Sicherheit manipuliert), ist dennoch eine Absprache erforderlich. In diesem Fall sollten die vorgesetzten Stellen informiert werden, so dass der Test (juristisch) legitimiert wird. Dies kann zum Beispiel der zuständige Abteilungsleiter sein, der das Wissen um den Test nicht weiterzugeben kann. Bei Problemen und politischen Reibereien liegt die Verantwortung sodann bei ihm, mit seinem Team zu reden und die Probleme anzugehen. Ein Test ohne Vorinformation wird sich früher oder später immer zu Ungunsten des Auditors entwickeln.
Eine Sicherheitsüberprüfung versucht Schwachstellen und Sicherheitslücken in einem System zu identifizieren. In der Regel wird das Vorgehen und die Resultate einer solchen Analyse in einem Report festgehalten. Dieser wird einerseits verwendet, um die Transparenz und Nachvollziehbarkeit der Prüfung mitzuführen.
Zeitgleich wird der Report jedoch ebenfalls genutzt, um die gefundenen Mängel adressieren zu können. So werden die jeweiligen Punkte den zuständigen Stellen zugewiesen. Diese können und müssen sodann Stellung zu den Findings beziehen:
* Akzeptieren: So kann es sein, dass das Risiko einer Schwachstelle aufgrund technischer oder wirtschaftlicher Komplikationen akzeptiert wird. In diesem Fall werden keine Gegenmassnahmen angegangen.
* Adressieren: Soll das Risiko nicht akzeptiert werden, da Eintrittswahrscheinlichkeit und Auswirkungen zu gross sind, wird das Problem mit Massnahmen vermindert oder ganz behoben.
Das Beheben eines Problems kann auf verschiedenen Ebenen stattfinden. Dies kann zum Beispiel konzeptionelle oder architektonische Änderungen an einem Produkt zur Folge haben. Oder es werden vom Hersteller bereitgestellte oder selber entwickelte Patches installiert. Können Probleme nicht direkt gelöst werden, werden sie mit flankierenden Massnahmen auf einer anderen Ebene adressiert. Dies kann zum Beispiel der Einsatz eines vorgeschalteten Firewall-Elements oder das Deaktivieren von Funktionalitäten sein.
Das Umsetzen von Gegenmassnahmen kann und darf nicht Teil der Aufgabe der Auditoren sein. Aufgrund des Prinzips der Gewaltentrennung weist der Auditor lediglich auf die Mängel hin. Es ist dem Besitzer bzw. Administrator des betroffenen Produkts überlassen, ob er die Gegenmassnahmen selber umsetzen oder dies einer dritten Stelle (z.B. andere Abteilung oder Drittfirma) überlassen will.
Nach dem Umsetzen der empfohlenen Gegenmassnahmen, kann ein Re-Check (wird auch als Follow-Up bezeichnet) veranschlagt werden. Bei diesem werden die zuvor kritisierten Punkte erneut geprüft, um die Funktionalität und Auswirkungen der Gegenmassnahmen zu bestätigen. Im Idealfall ist die Schwachstelle nicht mehr vorhanden und damit das Problem gelöst. Es kann jedoch auch sein, dass durch das Applizieren von Massnahmen neue Probleme aufgetan oder diese nur partiell behoben wurden (z.B. werden zwar Cross Site scripting-Attacken mit script-Tags verhindert, jedoch können diese noch immer mit Javascript-Events durchgesetzt werden). Das Durchlaufen des iterativen Prozesses Analyse-Behebung ist so lange zu wiederholen, bis das Problem gänzlich behoben wurde.
|
| Von Zensur und Doppelmoral (Montag, 1. Februar 2010 - 09:23:39) |
[Marc's Blog] In frühester Kindheit habe ich mich mit Träumen auseinandergsetzt. Fortwährend von wirren Geschichten verfolgt, stiess ich schon bald auf die jeweiligen Schriften Sigmund Freuds. Durch die Sekundärliteratur zu seinen Traumdeutungen in meinem Interesse bestärkt, begann ich mich alsbald für den Mann hinter den Analysen zu interessieren. Die Biographie des Juden Freuds war eine der ersten, die ich gelesen habe.
Durch die Hintergründe seines Lebens beschäftigte ich mich bald mit dem Dritten Reich. Dass zur damaligen Zeit Greueltaten im Sinne der nationalen Politik vorangetrieben wurden, bestreiten heute wohl nur noch die wirrsten Geister (Holocaustleugnung). In ganz besonderer Weise hat mich eine eigentlich doch eher unspektakuläre Aktion der Nazis erschüttert: Die Bücherverbrennung von 1933 auf dem damaligen Opernplatz.
Bücher, die von Untermenschen oder solchen, die mit diesen sympathisierten, geschrieben wurden, wurden den Flammen geopfert. Damit brachten die Mannen unter Adolf Hitler die Verachtung zum Ausdruck, die sie diesen Arbeiten beizumessen pflegten. Und, vielleicht war es so, sollte dieser Akt die in vielen Bereichen überragenden Leistungen der Untermenschen zu unterdrücken in der Lage sein. Man wollte ja schliesslich nicht eingestehen, dass auch "das minderwertige Volk der Juden" zu guten Leistungen fähig sei.
Erschüttert war ich im Herzen. Damals wie heute ist es mir unbegreiflich, wie eine Gesellschaft ihren Hass in so plumper Weise auf eine Gruppe fokussieren kann, in der Hoffnung, damit die sozialen Probleme ihrer Zunft zu lösen. Die Bücher von Grössen wie Thomas Mann, Albert Einstein oder Erich Kästner hatten wohl nur wenig damit zu tun, dass Europa zu dieser Zeit so war, wie es halt eben zu sein schien.
In der heutigen Zeit wird eine anderen Form der "Bücherverbrennung" gewährt. Totalitäre und pseudo-demokratische Staaten folgen dem Prinzip der Informationszensur auch auf digitaler Ebene. Populärstes Beispiel die Volksrepublik China, in der Zugriffe auf IP-Adressen limitiert und Webseiten gefiltert werden. Die Daten werden also durch eine Firewall verbrannt - Eher still und heimlich, weder pompös und werbeträchtig. Der Iran tat es bei den umstrittenen Präsidentschaftswahlen gleich, stellte sich denn schnell heraus, dass vor allem Twitter das unliebsame Tor zur freien Meinungsäusserung aufstossen sollte.
Frei nach dem Postulat Immanuel Kants, dass die Erkenntnis ein Erzeugnis aus These, Antithese und Synthese darstellt, kann das Einschränken des Informationsaustauschs eigentlich nie der Wahrheitsfindung dienlich sein. Derjenige, der Zensur anstrebt, will also die Verbreitung der Wahrheit verhindern, um sich wohlmöglich selbst einen Vorteil zu verschaffen. China ist nicht das einzige korrupte System, das mit derartigen Mitteln gegen die Oppositionen vorzugehen pflegt. Mit Vladimir Putin und Silvio Berlusconi haben auch Europa ihre Medien-Diktatoren.
Informationsfreiheit ist also wichtig und richtig. Immer? Obschon Zensur in westlichen Ländern (z.B. in Deutschland die "Vorzensur") per Gesetz untersagt ist, kommen unter dem Deckmantel von Jugendschutz und der Rassismus Strafnorm immerwieder derartige Vorgehen zum Tragen. Die Liste der zensierten und auf dem Index festgehaltenen Publikationen ist lang.
Meines Erachtens bleibt es fragwürdig, ob Titel wie "Mein Kampf" des ehemaligen Reichskanzlers wirklich verboten sein sollten. Derjenige, der sich kritisch mit dem Werk auseinandersetzen möchte, der solle dies tun. Dann wird er die Hintergründe und Widersprüche selber erfahren und damit die Synthese seiner Erkenntnis erlangen können. Eine Zurückhaltung der Informationen als Bevormundung des Bürgers bleibt nicht wünschenswert. Wir dem widerspricht, zweifelt an der Mündigkeit des Volkes.
Verständnis für "Zensur" zu Gunsten des Jugendschutzes, wo er denn angebracht ist, kann ich eher aufbringen. Es erscheint mir klar, dass pornographisches Material der härtesten Sorte nicht Kindern und Jugendlichen zugänglich gemacht werden sollte. Doch, so frage ich mich, wieso seit jeher der anonyme Bezug von Zigaretten über entsprechende öffentliche Automaten gebilligt wird, obschon die negativen Auswirkungen klar belegt sind.
Sämtliche Gesellschaften sind geprägt durch Doppelmoral. Ein Suizid gilt im Islam (wie auch im Christentum) als Sünde. Dem Sündiger würde der Eintritt ins Paradies verwehrt bleiben. Durch einen Freitod innerhalb eines Heiligen Kriegs die "Feinde des Glaubens" mitzureissen, wird jedoch von Extremisten als lobenswerte Aufopferung verstanden. Als Belohnung würde das Paradies und haufenweise Jungfrauen warten.
In anderen Gruppen gilt die aufrichtige Selbsttötung als Ehre und letzter Ausweg. Der heldenhafte Suizid wird in der traditionellen asiatischen Kultur der erniedrigenden Gefangennahme vorgezogen. Die Handlung ist stets die gleiche. Vielleicht auch die Absichten. Aber das Umfeld bestimmt, ob die Tat verachtens- oder lobenswert bleibt. Ort und Zeit haben Einfluss darauf, in welchem Licht die Dinge erscheinen.
Die Juristen und Politiker werfen in einer Diskussion zu komplexen Themen gerne den Begriff der "Verhältnismässigkeit" in den Raum, um Entscheide und Handlungen zu rechtfertigen. Dass diese Relationierung jedoch von höchst subjektiver Natur ist, wird nur selten öffentlich zugegeben. Ein böser Nachgeschmack von Willkür bleibt. Was vor 50 Jahren als schicklich galt, wird heute verpönt, vielleicht gebilligt. Und genauso wird es uns in 50 Jahren ergehen.
|
| Es wäre aufgefallen, dass ... (Montag, 25. Januar 2010 - 09:07:41) |
[Marc's Blog] Schweizer haben traditionell eine besondere Art, wie sie mit ihren Mitmenschen umgehen. In der Regel sind sie darum bemüht, sich rücksichtsvoll einem Konsens hinzugeben. Dabei wird sich normalerweise davor gescheut, auf Gedeih und Verderb seine eigenen Büdürfnisse auf Kosten anderer durchzusetzen. Der Grund hierfür ist einfach: Unser Land ist sehr klein und man begegnet sich mindestens zwei Mal im Leben - Eine grundlegende Verträglichkeit macht das Leben somit einiges einfacher.
Über die Jahre habe ich jedoch gelernt, dass man es nicht allen Menschen recht machen kann. Es gibt früher oder später immer diametral entgegengesetzte Bedürfnisse, die sich so nicht unter einen Hut bringen lassen. In der neuen Zeit werden manipulative und irreführende Mittel eingesetzt, um seinen eigenen Willen durchzusetzen. Und es ist deshalb nicht immer leicht, an seinen ritterlichen Grundsätzen festzuhalten. Doch auch wenn man es tut, man macht sich - hat man denn ein Rückgrat - nicht immer beliebt.
Im Rahmen einer Source Code Analyse wurde der externe Partner eingespannt und schon bei der Kickoff-Sitzung merkte ich in offensichtlicher Weise, dass man unsere Tätigkeit nicht begrüssen würde. Als Schmach und Schande wurde es verstanden, dass sich hier eine externe Firma erdreistet, das wichtige Produkt der Firma in Frage zu stellen. Dass wir lediglich einen Auftrag im Rahmen der Geschäftsprozesse der nicht näher genannten Bank erhalten haben, schien unsere Gegenüber nicht zu interessieren.
So verlief das Projekt dann auch mit einer Vielzahl an Sticheleien, die ich mit stoischer Ruhe über mich ergehen liess. Ich musste mir immer wieder einreden, dass ich die Unfähigkeit und Einfältigkeit der Entwickler bezüglich angewandter Computersicherheit im Rahmen des Projekts nicht auch noch nebenher umbiegen könnte. Also liess ich sie gewähren und machte meinen Job. Zwar mit eher geminderter Freude, doch ich machte ihn.
Die erste Fassung unseres Reports wurde abgegeben und durch den Kunden sowie seinen Partner besprochen. Wir warteten auf Feedback, um die finale Version erstellen und damit das Projekt abschliessen zu können. Ich wusste, dass hier je nachdem politische Mittel eingesetzt werden würden, um die Qualität unserer Arbeit herunterzuspielen, um über die eigenen Unpässlichkeiten hinwegtäuschen zu können. Und so war es dann auch, obschon das Ausmass der hinterhältigen Manipulation erstaunlich gering blieb.
Jedoch wurde uns ein Statement zugespielt, in dem auf "fachliche Fehler" im Report hingewiesen wurden. Wir bemängelten, dass an verschiedenen Stellen im Code Zahlenwerte in String-Konstanten abgelegt wurden. Längerfristig könnten sich diese nutzen lassen, um Injection-Angriffe ansetzen zu lassen. Die Gegendarstellung begann sodann mit den Worten:
"Wäre die Datenbankstruktur der Applikation betrachtet worden, dann wäre aufgefallen, dass die meisten betroffenen Datenfelder lediglich in Spalten mit dem Datentyp Integer abgespeichert werden."
Obwohl diese Aussage technisch korrekt ist, widerspricht sie mir in zweierlei Hinsicht. Zum einen haben wir eine klar abgegrenzte Source Code Analyse vorgenommen. In einer solchen wird die Datenbankstruktur nicht betrachtet. Sie wäre Teil einer Configuration Review, die explizit offeriert, jedoch durch den Kunden nicht bestellt wurde.
Und zum zweiten wird mit dem Datentyp in der Datenbank höchstens persistente Type-2 Cross Site scripting-Schwachstellen eliminiert. Reflektive Type-1 Cross Site scripting-Schwachstellen sowie alle anderen Arten von Injection-Angriffen (z.B. vorzugsweise SQL-Injection) bleiben bestehen. Und zwar zu grossen Teilen deshalb, weil wie bemängelt keine starke Typisierung im Programmcode erzwungen wird.
Die Konsequenz des nicht zu Ende gedachten Gegenstatements hat nun zur Folge, dass wir wiederum eine Gegendarstellung aushändigen müssen. In dieser werden die Details des "Missverständnisses" aufgezeigt, was dem Partner sicher nicht gefallen wird. Schliesslich illustriert dieser Schriftwechsel sein Unverständnis für das gegebene Problem. Ich komme also nicht darum herum, mir hier einmal mehr Leute zu "Feinden" zu machen. Schade, denn ich werde ihnen vielleicht wieder einmal begegnen. Aus diesem Grund bleibt mir nichts anderes übrig, als ständig gute und damit unangreifbare Arbeit zu leisten.
|
|
