_
Hauptmenu
News
Verwundbarkeitsdatenbank
Downloads
- Dokumente
- Software
- Filme
- Guides
Projekte
- Attack Tool Kit
- codEX
- ComInt
- Compupedia
- Computec Online Adventure
- eLearn
- Entropia
- httprecon
- Tractatus
Forum
Statistiken
- Webseite
Links
FAQ
Impressum

Willkommen 23.20.196.179

Online
Gäste: 6
Mitglieder: 0
Auf dieser Seite: 1
Mitglieder: 3346, neuestes ist derchrist

Follow us on Twitter
Follow us on Twitter

scip_Alerter
16.05.1316.05.13EMC RSA Authentication API Encryption Key Information Disclosure
15.05.1315.05.13Cisco Secure Access Control System Web Interface schwache Authentisierung
15.05.1315.05.13Python ssl.match_hostname() Denial of Service
14.05.1314.05.13Mozilla Firefox/Thunderbird nsContentUtils::RemoveScriptBlocker Pufferüberlauf
14.05.1314.05.13Mozilla Firefox/Thunderbird nsFrameList::FirstChild Pufferüberlauf

Zeige aktuelle Schwachstellen

Neueste 5 Downloads
915 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.
914 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.
913 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.
912 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.
911 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)

Schon gewusst, dass...
...Back Orifice 2000 eines der ersten Remote-Control-Tools war, das auch unter Microsoft Windows NT lauffähig war?

Zeige alle Trivias (244 Total)

Zitat des Augenblicks (id 182)
"Fehlendes Verständnis oder Wissen muss nicht zwingend ein Nachteil für die Sicherheit einer Umgebung sein." - Marc Ruef, 23. Oktober 2005 in Marcs Blog

Zeige alle Zitate (246 Total)

Google Werbung

 
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.

Risiken und ihre Akzeptanz (Montag, 13. Mai 2013 - 12:44:10)
[Marc's Blog] Unser Job ist es, Risiken aufzuzeigen und bisweilen sie zu beweisen. Zu diesem Zweck identifizieren wir mögliche Angriffspunkte, setzen diese in Relation zu einem Angriffsszenario und bewerten dieses in Bezug auf Aufwand und Möglichkeiten. Typischerweise weisen wir das Risiko anhand einer Skala mit den Werten Low, Medium, High und Emergency aus (siehe auch).

Wenn wir checklistenbasierte Prüfungen durchführen, wird zusätzlich die Einstufung Passed verwendet. Diese kommt immer dann zum Einsatz, wenn ein Angriffsvektor als nicht gegeben erachtet wird. Zum Beispiel suchen wir in Webapplikationen nach Cross Site scripting-Schwachstellen. Bleiben diese aus, wird für diese Angriffstechnik ein Passed vergeben. Das ist der sicherheitstechnische Idealzustand.

Im Rahmen unserer Prüfungen werden oftmals Schwachstellen gesucht, die der Laie gerne als "trivial" wahrnimmt. Zum Beispiel, ob ein Zielsystem mittels ICMP-Anfragen erreichbar ist. Oder ob sich die Entry-URL einer Webapplikation im Index gängiger Suchmaschinen findet. Schwachstellen dieser Art werden meist mit dem Risiko Low ausgewiesen. Sie stellen keine direkten Gefahren dar, können jedoch in Kombination mit weiterführenden Auswertungs- und Angriffstechniken eine erfolgreiche Attacke begünstigen.

Mancher Kunde besteht darauf, dass diese Schwachstellen auf ein Passed heruntergestuft werden: Entweder weil das Risiko verschwindend gering sei - Oder weil man dieses zu vernachlässigende Risiko akzeptieren will.

Selbstverständlich kann ein Kunde eine Umstufung von Findings durchführen. Dies hat aber nur in den wenigsten Fällen direkten Einfluss auf unsere Einstufung. Nur weil ein Risiko vermeintlich gering ausfällt, ist es nicht gänzlich eliminiert. Und nur weil ein Risiko durch den Kunden akzeptiert wird, ist es auch nicht eliminiert.

Aus diesem Grund bleiben derlei Risiken - und auch solche eines anderen Schweregrads - in der ausgewiesenen Form bestehen. Es ist am Kunden, eine interne Umstufung unserer Risikodeklaration vorzunehmen. Ob Risiken angegangen oder akzeptiert werden, hat keinen Einfluss darauf, ob sie zum Zeitpunkt des Tests gegeben waren oder nicht.

Ein wichtiges Qualitätsmerkmal unserer Arbeit ist, dass wir mit den Kunden zusammenarbeiten. Will ein Kunde dediziert Risiken akzeptieren und dies in unserem Report explizit so dokumentiert haben, kann er uns entsprechendes Feedback liefern. Sodann bringen wir den entsprechenden Vermerkt unter oder verschieben die betroffenen Findings in ein dediziertes Kapitel schon behandelter Risiken.

Lese/Schreibe Kommentar: 0 printer friendly

Eine Ode an die RFCs (Dienstag, 30. April 2013 - 09:02:19)
[Marc's Blog] Als ich 1997 meine Ausbildung zum Reiseberater, eine kaufmännische Lehre, anfing, steckte die Kommerzialisierung des Internets noch in den Kinderschuhen. Ich sah mich damals in der Lage, als einer der ersten in der Schweiz, über ein Kabelmodem (InternetPLUS) ins weltweite Netz gelangen zu können. Bei meiner Arbeitsstelle wurde damals aber noch kein Internetzugang angeboten. Emails konnten nur innerhalb der Filiale verschickt werden. Heute wohl undenkbar.

Manchmal hatte ich nicht viel zu tun und so war ich dann darum bemüht, möglichst viel zu lesen. Zu diesem Zweck habe ich mir zu Hause technische Dokumentationen auf eine Floppydisk geladen und im Büro zu Gemüte geführt. Bevorzugt steckte ich meine Nase in RFCs. RFC steht für Request for Comments. Hierbei handelt es sich um offene Dokumente, die eine Netzwerktechnologie spezifiziert oder gar standardisiert. In der Regel beschreibt ein einzelnes RFC eine einzelne Technologie und RFCs werden durchnummeriert. Zum Beispiel beschreibt RFC791 das Internet Protocol. RFC821 führt das Simple Mail Transfer Protocol ein und RFC1945 diskutiert den Kern des Hypertext Transfer Protocol.

RFCs sind nicht immer leicht zu lesen, da sie in erster Linie die Spezifikationen ausformulieren. Doch sie bilden einen wahren Schatz an Informationen. Sie gelten als die zentrale Wahrheit der besprochenen Technologien. Wer sie aufmerksam liest, der wird schlussendlich - wenigstens auf theoretischer Ebene - alles zum Thema wissen. Und wer zwischen den Zeilen lesen kann, der entdeckt bisweilen mögliche und interessante Angriffsszenarien.

Mittlerweile gibt es gar einige RFCs, die sich konkret mit Angriffsmöglichkeiten auf Protokollarchitekturen und Dienste auseinandersetzen. Zum Thema Denial of Service gibt es eine ganze Reihe von Beiträgen, wie zum Beispiel RFC2267, RFC3882, RFC4732 und RFC4987. Spezifischer Angriffstechniken wird sich zum Beispiel anhand von TCP-Spoofing in RFC4953 gewidmet und Angriffstechniken mittels ICMP gegen TCP sind ausführlich in RFC5927 beschrieben.

Für mich ist es immer eine wahre Freude, wenn ich etwas lesen darf, das nur so vor Substanz und Erfahrung strotzt. So unglaublich einfach scheint es in solchen Momenten, seinen Horizont erweitern und von den Gedanken anderer profitieren zu können. Was will ein aufgeweckter Geist mehr im Leben?

Lese/Schreibe Kommentar: 0 printer friendly

Mit Risiken leben (Montag, 15. April 2013 - 08:09:44)
[Marc's Blog] Manche Menschen sind sehr vorsichtig. Zum Beispiel ich. Gefährliche Dinge behagen mir nicht. Egal, welche Möglichkeiten sie auftun. Dafür bin ich eigentlich dankbar. Denn ansonsten würde ich wohl als Drogenhändler mein Dasein fristen. Die ständige Angst, für meine Vergehen geahndet zu werden, würden der Helligkeit meines Gemüts kaum zuträglich sein.

Und trotzdem denke ich, dass ich nicht unbedingt ein ängstlicher Mensch bin. Ich bin durchaus bereit, Risiken einzugehen. Doch ein Risiko muss immer berechenbar sein. Ich würde beispielsweise nicht bei einem Bahnhof mit mehreren Gleisen über eben diese rennen. Ich habe schon zu viele Bahnunfälle bzw. das traurige Resultat eben dieser gesehen, alsdass ich mich diesem Risiko aussetzen wollen würde.

Ein Risiko ist unbestritten dann kalkuliert, wenn man zu "verlieren" bereit ist. Wenn ich mich zum Beispiel entscheide, an einem Glücksspiel teilzunehmen - sei dies nun Roulette oder Devisenhandel -, dann muss ich bereit sein, meinen gesamten Einsatz zu verlieren. Ist dies nicht der Fall, dann ist das Glücksspiel eine schlechte Wahl. Vor allem bei jenen Spielen, bei denen die Gewinnchance statistisch weniger als 50% beträgt.

Schlechtes Risikomanagement ist dann gegeben, wenn unnötige Risiken eingegangen werden und man mit dem Eintreten des Worst Case Szenarios nicht leben kann. Also wenn ich über 20 Jahre hinweg mühsam gespart habe und dann all mein Geld an der Börse verliere.

Manche Menschen sind sehr schlecht darin, Risiken nachvollziehen und richtig mit diesen umgehen zu können. Autofahrer, die in einer 80er Zone mit mehr als 100 km/h Stunde über die Strasse bretten, zum Beispiel. Dies ist ein unnötiges Risiko, das man auf sich nimmt und ebenfalls seinen Mitmenschen aufbürdet. Der minimale Zeitgewinn steht in keinem Verhältnis zu der Gefahr, die mit ihr einher geht.

Lese/Schreibe Kommentar: 0 printer friendly

Archiv
*Sind Firewalls unnötig?02. Apr 13 : 08:49Marc's Blog
*Schlecht gelebte Paranoia18. Mär 13 : 09:13Marc's Blog
*Jumping to Conclusions04. Mär 13 : 08:42Marc's Blog
*Audit nach Forensik - Die Nadel im Heuhaufen18. Feb 13 : 12:19Marc's Blog
*Wenns bei Full-Disclosure um Leben und Tod geht28. Jan 13 : 08:30Marc's Blog
*Websecurity mal anders07. Jan 13 : 09:59Marc's Blog
*2012: Was war? 2013: Was wird?24. Dez 12 : 08:06Marc's Blog

Wechsle zur Seite [1] 2 3 ... 38 39 40


News Categories

1997-2012 © Marc Ruef: Alle Rechte vorbehalten - Kopieren erlaubt!

Render time: 0.2427 second(s).