_
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 107.20.7.65

Online
Gäste: 7
Mitglieder: 0
Auf dieser Seite: 1
Mitglieder: 3347, neuestes ist testhub

Follow us on Twitter
Follow us on Twitter

scip_Alerter
17.06.1317.06.13Apple iOS Mobile Hotspot generateDefaultPassword() schwache Authentisierung
17.06.1317.06.13Cisco ASA CX TCP Packet Handler Denial of Service
16.06.1316.06.13Oracle Java 2D erweiterte Rechte
16.06.1316.06.13Oracle Java Networking erweiterte Rechte
16.06.1316.06.13Oracle Javadoc Spoofing

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...
...in beiden Teilen von "Mission Impossible" mit Tom Cruise ein Computer-Hacker drin vorkam? Im ersten Teil erliegt er einem tragischen Unfall in einem Aufzugsschacht.

Zeige alle Trivias (244 Total)

Zitat des Augenblicks (id 20)
"Es gibt keine ewigen Warheiten, ewige Lügen schon." - Stanislaw Lec

Zeige alle Zitate (246 Total)

An diesem Tag...
ID 398 2004: OpenBeOS wird an der ersten amerikanischen Entwickler-Konferenz WalterCon in Haiku umbenannt
ID 702 2007: Grimme Online Award stellt Preisträger versehentlich zwei Tage zu früh online
ID 705 2007: Ein Hacker namens Gabriel publiziert das vermeintliche Ende von Harry Potter auf Full-Disclosure

Zeige alle Einträge (711 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.

MD5 ist tot? Das hättest Du wohl gern! (Montag, 10. Juni 2013 - 16:04:56)
[Marc's Blog] Es gab nur wenige Fächer in der Schule, für die ich mich begeistern konnte. Eines davon war der Deutschunterricht. Mitunter trug hierzu mein quirrliger Deutschlehrer, Herr Baumgartner, bei. Der Mann mit deutschen Wurzeln war ein Verfechter der geschickten Wortwahl. Und er stiess sich unglaublich daran, wenn ein gemeiner Schreiberling mit seinem Halbwissen ein grammatikalisches und interpunktuelles Massaker veranstalten sollte.

Auch in meinem Fachbereich kann ich diesen Unmut nachvollziehen. Wenn bezüglich Malware und Kryptologie mal wieder Halbwahrheiten herumgereicht werden. Und dies mit der Folge, dass damit das allgemeine Niveau in diesen Bereichen abnimmt.

Eine der Halbwahrheiten, die ich immerwieder sehe, ist die Aussage, dass MD5 tot sei. Wieso? Es sei unsicher. Wieso unsicher? Weil SHA-1 sei viel sicherer. Wieso ist SHA-1 viel sicherer? Na, weils halt einfach sicherer ist als MD5.

Ja, MD5 ist mathematisch unsicherer als SHA-1. Das kann man nicht abstreiten und das soll man auch nicht abstreiten. Aber nur weil MD5 unsicherer ist als SHA-1, heisst es nicht, dass MD5 per se unsicher ist. Ja, MD5 gilt als gebrochen. Aber genauso gibt es verschiedene Angriffstechniken auf SHA-1. In hochsicheren Umgebungen ist auch SHA-1 oftmals nicht die richtige Wahl.

Und dies führt schon zum nächsten Kritikpunkt über. Die zu erwartende Sicherheit ist relativ. Ein MD5-Hash reicht vollkommen aus, um die Session-ID für einen Ad-Service im Web bereitzustellen. Innerhalb eines Core Bankings sind die Anforderungen jedoch bedeutend höher. Hier reicht vielleicht noch nicht mal SHA-1 aus.

Es gibt viele Halbwahrheiten, die in ähnlicher Form widerlegt werden können. Dazu gehören: Linux ist sicherer als Windows, auf Mac/Linux gibt es keine Malware, viele Patches für eine Software deuten auf schlechte Qualität hin (im Gegensatz zu Produkten ohne Patches), Salts in Passwort-Hashes machen diese sicher, Antivirus ist Snake-Oil, als Security-Consultant muss man programmieren können, ein echter Hacker/Pentester benutzt keine Tools, nur Blackbox-Tests spiegeln die echte Sicherheit wieder, Security by Obscurity ist richtig/falsch (beides kann zutreffen).

Man bedient sich diesen "fachspezifischen Klischées", um in polemischer Weise vermeintlich starke Positionen vertreten zu können. Komplexe Sachverhalte werden so reduziert, ohne den Kontext - und teilweise neue Erkenntnisse - zu berücksichtigen. Das Leben ist halt sehr einfach, wenn man es auf ein paar simple Regeln reduzieren vermag. Und es kann schlagartig wieder schwierig werden, wenn man sich auf den falschen Axiomen abstützt!

Lese/Schreibe Kommentar: 0 printer friendly

Normalisierung von Nachrichten-Informationen (Montag, 27. Mai 2013 - 08:02:26)
[Marc's Blog] Die Verteilung von Nachrichten ist ein zentraler Bestandteil der modernen Informationsgesellschaft. Dies geschieht über verschiedene Kanäle. Darunter fallen traditionelle Medien wie Zeitungen, Radio und Fernsehen. In multimedialer Weise spielt mittlerweile das Internet eine grosse Rolle, das über Nachrichtenportale, Twitter, RSS und andere Dienste bzw. Technologien zur Verbreitung von Neuigkeiten beiträgt.

Klassischerweise werden dabei Informationen so aufbereitet, wie man sich dies seit Menschengedenken gewohnt ist. Eine Information wird in eine Aussage gepackt, die dann dem entsprechenden Medium gerecht weitergetragen wird. Eine solche Mitteilung könnte beispielsweise lauten: "Regierungskritischer Journalist wurde in Moskau verhaftet".

Das Problem hierbei ist, dass diese Information sehr stark an die entsprechende Sprache gebunden ist. Sie ist in Deutsch gehalten und orientiert sich an den grammatikalischen und orthografischen Regeln dieser Sprache. Eine automatisierte Weiterverarbeitung ist nicht ohne erheblichen Aufwand möglich. Dies zeigt sich deutlich am Aufwand, der für eine Übersetzung betrieben werden müsste. Zwar stehen mittlerweile computergestützte Übersetzungen bereit. Diese können jedoch ohne menschliche Moderation in keinster Weise die gewünschte Qualität aufrecht erhalten.

Aber auch eine im Kontext der Originalsprache angestrebte Weiterverarbeitung wird schwierig. Es gibt nur eine endliche Anzahl an Nachrichten, die durch verschiedene Nachrichtenstellen weiterverbreitet werden möchten. Zwangsweise müssen sie sich auf andere Stellen, im Idealfall natürlich die Primärquelle, beziehen. Schlussendlich wird aber immer stetig das Gleiche geschrieben, vielleicht ein bisschen angepasst und im besten Fall um eine eigene Einschätzung erweitert.

Diese Einschränkungen können eliminiert und damit das Nachrichtenwesen massgeblich vorwärtsgetragen werden, wenn sich auf eine abstrahierte Form der Informationssammlung geeinigt wird. Anstelle ganzer Aussagen, wie die im Beispiel genannte, sollten die einzelnen Informationselemente gesondert dokumentiert werden. Hierzu kann eine baumähnliche Struktur zum Tragen kommen, um die einzelnen Objekte und ihre Eigenschaften zu charakterisieren:

    Code:
    {
    "activity": "arrest",
    "subject":
    {
    "sex": "male",
    "occupation": "journalist",
    "attitude": "government-critical"
    }
    "location":
    {
    "country": "Russia",
    "city": "Moscow"
    }
    }


Durch diese Notation wird es möglich, die Kerninformationen von Emotionen losgelöst und damit ohne weiteren Ballast zur Weiterverarbeitung bereitzustellen. Eine in dieser Art aufgemachte Quelle lässt sich ohne weiteres heranziehen und durch eigene Recherchen bereichern. Die gewünschte Nachricht lässt sich dann durch das Zusammenfügen der Elemente generieren:

    Code:
    {subject.attitude} {subject.occupation} wurde in {location.city} {activity}


Ebenso werden Übersetzungen möglich, da die Kernelemente direkt übersetzt und in den Kontext der neuen Sprache eingebunden werden können (durch eine relationale Datenbank lässt sich dies sehr effizient realisieren). Traditionelle Übersetzungen bestehender Beiträge werden damit überflüssig.

Lese/Schreibe Kommentar: 0 printer friendly

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

Archiv
*Eine Ode an die RFCs30. Apr 13 : 09:02Marc's Blog
*Mit Risiken leben15. Apr 13 : 08:09Marc's Blog
*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

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


News Categories

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

Render time: 0.6725 second(s).