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

Online
Gäste: 6
Mitglieder: 0
Auf dieser Seite: 1
Mitglieder: 3370, neuestes ist wagner

Follow us on Twitter
Follow us on Twitter

scip_Alerter
16.04.1416.04.14F-Secure Security Gateway Admin Console admin Reflected Cross Site Scripting
15.04.1415.04.14SAP SAProuter Password Authentication passwordCheck schwache Authentisierung
15.04.1415.04.14Oracle MySQL Server Options Handler Denial of Service
15.04.1415.04.14Oracle MySQL Server Federated Handler Denial of Service
15.04.1415.04.14Oracle MySQL Server Replication Handler Denial of Service

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 Microsoft-Umgebungen (MS DOS und Windows) bei Pfad- und Dateinamen nicht zwischen Gross-/Kleinschreibung unterschieden wird? Ganz im Gegensatz zu Unix-Systemen.

Zeige alle Trivias (244 Total)

Zitat des Augenblicks (id 191)
"Das Buch der Natur ist mit mathematischen Symbolen geschrieben." - Galileo Galilei

Zeige alle Zitate (246 Total)

An diesem Tag...
ID 239 2005: Der Linux Distributor SuSE veröffentlicht SuSE Linux 9.3

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.

Psychologische Manipulation im Hypothekarzinsumfeld (Montag, 7. April 2014 - 10:39:41)
[Marc's Blog] Gestern warnte der Blick am Sonntag mit der Schlagzeile Immobilien-Besitzern drohen massiv höhere Zinsen. Die Kernaussage schlug sich wie folgt nieder:

    "In Tiefzinsphasen wie heute sollen [Eigenheimbesitzer] nicht mehr mit dem normalen Zins auf ihrem Hypokredit davonkommen. Neu sollen sie jenen Zins zahlen, mit dem die Banken intern in ihren Sicherheitsmodellen rechnen. Dieser kalkulatorische Zins liegt bei rund fünf Prozent und ist damit mindestens doppelt so hoch wie der Hypothekarzins."


Eine Vielzahl an Zeitungen und Zeitschriften hat diese Implikation und die mit ihr mitschwingende Empörung übernommen. Und diese hat sich sowohl bei den Immobilien-Besitzern als auch bei den Mieter in den dazugehörigen Kommentaren niedergeschlagen. Zu Unrecht, wie ich meine. Hier liegt stattdessen ein wunderbares Beispiel der Manipulation der öffentlichen Wahrnehmung durch die Bankiersvereinigung vor.

Banken waren bisher immer angehalten, die Belehnungsgrenze anhand des durchschnittlichen Zinses von 5% zu berechnen. Wer einen Zinsanstieg bis auf 5% bei seinem Einkommen nicht verkraften kann (der dabei anfallende Hypozins darf ein Drittel des Einkommens nicht übersteigen), der kriegt keine Hypothek. Der Vorschlag der Finma ändert daran gar nichts.

Der folgende Absatz versucht stattdessen zu suggerieren, dass es unmittelbare Nachteile für Immobilien-Besitzer gibt und in erster Linie nur für diese:

    "Die Belastung für Käufer und Besitzer von Wohneigentum steigt massiv. Bei einer Hypothek von 800000 steigen die Kosten um mehr als 10000 Franken pro Jahr (...). Für viele Familien würde Wohneigentum damit wohl unerschwinglich."


Wenn der Zins, wie momentan für eine 10-jährige Hypothek, bei 2% liegt, dann sind 16'000 CHF pro Jahr (oder 1'333 CHF pro Monat) dafür aufzuwenden. Daran wird sich auch beim neuen Vorschlag nichts ändern. Aber stattdessen werden die Kosten auf 5% aufgerundet. Dies entspricht dann 40'000 CHF pro Jahr (oder 3'333 CHF pro Monat). Dabei wird die Differenz von 3% in die Amortisation gesteckt.

Pro Jahr wird also 24'000 CHF gespart. Die Belehnung nimmt damit, wenn man denn ein variables Modell anwendet, stetig ab und damit ebenfalls die Zinsbelastung. Wer sich das nicht leisten kann, der würde auch bei einem realen Anstieg der Hypozinsen auf 5% eben diese nicht tragen können. Und dann wäre die ganze Risikokalkulation, die auf diesen 5% basieren, ein zahnloser Tiger gewesen.

Die Bankiers versuchen mit allen Mitteln die neue Regelung für Immobilien-Besitzer wenig schmackhaft zu machen:

    "Die Banken fürchten, dass ihre Erträge noch stärker unter Druck kommen. Durch die neuen Vorschriften würde das Hypothekargeschäft zu einem Kartell, sagt ein Banker, der anynom bleiben will. Die Institute könnten sich kaum mehr voneinander abheben."


Die Grundaussage ist falsch. Zwar würden überall die gleichen 5% als Zahlung erwartet werden. Die Banken können sich aber durch die Anpassung der Margen und damit der Zuteilung in die Amortisation, voneinander abheben. Der Wettbewerb wird nach wie vor zu Gunsten der Kreditnehmer stattfinden. Und wer Vergleichsofferten für eine Hypothek eingeholt hat weiss, dass es da durchaus Spielraum bei den jeweiligen Instituten gibt.

Das Ziel der Banken ist es, dass Hypotheken möglichst hoch ausfallen und lange bestehen. Denn nur so können sie den anfallenden Hypozins als Einnahme verbuchen. Eine schnell und umfassend zurückbezahlte Hypothek ist gar nicht in ihrem Sinn, da sie daran nichts verdienen.

Zur Zeit wird Eigenheimbesitzern steuerlich der Eigenmietwert als fiktive Einnahme auferlegt. Im Gegenzug können die Hypothekarschulden abgezogen werden. Wer viele Schulden hat, vermag dieses Gleichgewicht zu seinem steuerlichen Vorteil zu verschieben. Ab einer gewissen Stufe des Abzahlens der Hypothek wird ein Punkt erreicht, in dem die Hypozinsbelastung und die Eigenmietwertbelastung möglichst gering sind. Steuerlich lohnt es sich, diesen Grenzwert zu bestimmen und durch Abzahlungen zu erreichen. Die Kalkulation mit einer Steuersoftware (z.B. EasyTax) sind relativ simpel.

Die Banken werden alles daran tun, den Eigenmietwert zu erhalten. Denn er ist der Hauptfaktor, der das Zurückzahlen der Hypothekarschuld unattraktiv macht. Und der Staat ist auch nicht von sich aus interessiert daran, dagegen zu halten. Denn er verdient natürlich an den damit einhergehenden Steuereinnahmen.

Wenn ich persönlich nun entscheiden müsste, ob ich meiner Bank mehr Hypozinsen oder in den Steuern mehr aufgrund des Eigenmietwerts bezahlen müsste, würde ich letzteres wählen. Denn diese Steuern fliessen zurück in die Gemeinde, in der ich lebe. Davon profitiert mein direktes Umfeld und auch ich. Deshalb bin ich sehr stark um das konsequente Abzahlen meiner Hypothek bemüht. Und das will der vom Blick gesteuerte Artikel genau verhindern.

Lese/Schreibe Kommentar: 0 printer friendly

Manuelle Firewall Rule Reviews - Bitte nicht! (Montag, 17. März 2014 - 14:12:41)
[Marc's Blog] Firewall Rule Reviews sind ein wichtiger Bestandteil von Sicherheitsüberprüfungen. Bei diesen wird das Regelwerk einer Firewall auf Schwachstellen hin untersucht. Welchen Herausforderungen hierbei mit welchen Ansätzen entgegnet werden kann, habe ich in verschiedenen Fachpublikationen und Vorträgen illustriert.

Da wir eine Vielzahl solcher Prüfungen durchführen, waren wir stetig um die Professionalisierung derer bemüht. Eine solche bedingt, dass ein formales System zum Einsatz kommen kann, das sich computergestützt anwenden lässt. Computergestützt bedeutet in diesem Zusammenhang, dass das Regelwerk zu grossen Teilen automatisch eingelesen, in das für die Analyse bestmögliche Format umgewandelt und schon auf gewisse Anhaltspunkte hin untersucht wird. Dadurch können wir sehr effizient und effektiv vorgehen.

So mancher Kunde ist aber nicht so freizügig, wenn es um die Herausgabe des Regelwerks geht. Da heisst es dann plötzlich, dass es nicht in elektronischer Form und stattdessen nur auf Papier herausgegeben werden darf. Oder noch schlimmer, dass es nur beim Kunden vor Ort oder gar auf der Management-Konsole eingesehen werden kann. Eine computergestützte Analyse wird im ersten Fall massgeblich erschwert - Und im zweiten Fall wird sie gänzlich unmöglich gemacht.

Da heisst es also dann "zurück auf Start": Die Analyse muss manuell - quasi mit Papier und Bleistift - erfolgen. Dies mag bei einem relativ simplen Regelwerk mit weniger als 30 Rules durchaus möglich sein. Kommen aber mehrere Dutzend oder gar Hunderte von Regelsätzen zum Einsatz, wird es eine sehr aufwendige und bisweilen nervenaufreibende Aufgabe.

Meines Erachtens stellt es den komplett falschen Ansatz dar, die Arbeit eines Analysten in derartiger Weise zu behindern. Einerseits kann er sein Expertentum nur mit erheblichem Aufwand einbringen. Ein Grossteil der Zeit geht für stumpfsinnige Arbeiten, die keinen Nutzen bringen, drauf.

Andererseits wird übersehen, dass das Regelwerk im Report ja bestmöglich dokumentiert werden soll. Wenn denn die Daten gar nicht erst mitgenommen werden können, wird die Dokumentation eher mager ausfallen. Im besseren Fall kann man auf die Regeln verweisen, was es jedoch unmöglich macht, den Report ohne das Konsultieren der Regeln nachvollziehen zu können. In jedem Fall verlieren alle Beteiligten.

Lese/Schreibe Kommentar: 0 printer friendly

Kritik an Proxies als Massnahme (Montag, 3. März 2014 - 12:41:33)
[Marc's Blog] Im klassischen Firewalling werden die beiden Technologien Packet Filter und Application Gateway vorgesehen. Letztere ist durch das Anbieten dedizierter Application Level Proxies für einzelne Anwendungsprotokolle darum bemüht, eine Entkoppelung eines Dienstes vorzunehmen. Als Common Point of Trust wird das Sicherheitselement zwischen Client und Server geschaltet:

Client ↔ Proxy ↔ Server


Ein Proxy ist darum bemüht, die Unstimmigkeiten einer Kommunikation zu erkennen, einzuschränken und zu protokollieren. Wird also eine deformierte HTTP-Anfrage über einen Webproxy geschickt, sollte er entsprechend darauf reagieren können. Die Angriffsmöglichkeit gegenüber dem Zielsystem – dem eigentlichen Server -, soll durch das vorgeschaltete Element abgefangen und neutralisiert werden. Im besten Fall erreicht der Angriffsversuch also nie das angegriffene System, unabhängig von einer etwaigen Verwundbarkeit dessen:

Client → Proxy ↛ Server


Gehen wir nun davon aus, dass auf dem Server eine Schwachstelle existiert. Diese kann durch eine böswillige HTTP-Anfrage ausgenutzt werden. Ein Direktzugriff führt also zum Erfolg der entsprechenden Attacke. Der Proxy erkennt jedoch die Deformierung und kann den Angriff frühzeitig abblocken. Damit übernimmt er eine zentrale Aufgabe, die eigentlich dem Server hätte zuteil werden sollen. Denn eigentlich ist letzterer selbst dafür zuständig, sich selbst sicher anzubieten. Durch einen Proxy kann damit eine mehrschichtige Sicherheit (Multilevel Security) erreicht werden.

Mit diesem Prinzip gehen jedoch Einschränkungen einher. Weist zum Beispiel das vorgeschaltete Sicherheitslement eine Schwachstelle auf – sei dies nun eine programmtechnische Verwundbarkeit oder ein versehentlich eingeführter Fehler in den Konfigurationseinstellungen -, kann dieses seine Aufgabe nicht mehr wahrnehmen. Wird auf das Erreichen des gewünschten Sicherheitsstands auf der Applikation verzichtet, ist diese trotz Sicherheitselement – aufgrund seiner Transparenz – angreifbar. Es ist also wichtig, eine echte mehrschichtige Sicherheit zu erreichen, indem auf allen Ebenen Massnahmen angestrebt werden.

Client ↔ Proxy mit Schwachstelle ↔ Server


Das zweite Problem besteht in einem grundlegenden Missverständnis, welches Proxy-Lösungen entgegengebracht wird. Es wird oftmals fälschlicherweise per se angenommen, dass diese Angriffe pauschal erkennen und verhindern können. Tatsächlich ist es jedoch in erster Linie nur die Aufgabe des Proxies, Verletzungen der Standardisierung des eingesetzten Protokolls anhand eines wohldefinierten Prototyping zu erkennen. Dies können zum Beispiel fehlerhafte Werte in einer Header-Zeile sein.

Wird jedoch ein Angriff angestrebt, der keine Verletzungen dieser Art erfordert, kann der Proxy nicht ohne weiteres reagieren. Ein durch ihn erlaubter Zugriff wird voraussichtlich auch durch den Server als solchen wahrgenommen (das gleiche Problem haftet seit jeher Antiviren- und IDS-Lösungen an):

Client ↔ Proxy erlaubt Zugriff ↔ Server erlaubt Zugriff


Es ist wichtig zu verstehen, dass Proxies a) in erster Linie als ergänzende Massnahme im Rahmen einer mehrschichtigen Sicherheitslösung eingesetzt werden sollten und b) netzwerk- und applikationsindividuelle Anpassungen an der Installation vorgenommen werden müssen. Hierzu muss sowohl die Funktionsweise der Proxylösung als auch jene der zu schützenden Dienste umfassend verstanden und eingeschränkt werden. Oftmals ginge mit einem solch durchdringenden Verständnis ebenfalls die Möglichkeit einer umfassenden Absicherung des Endpunkts einher. Und dadurch generiert sich das klassische Dilemma:

    "Ein Proxy ist erst dann von echtem Nutzen, wenn er nicht mehr erforderlich wäre. q.e.d."


Ein Proxy-Element kann dann von unweigerlichem Nutzen sein, wenn keine direkte oder mittelfristige Möglichkeit besteht, den Server bzw. die darauf angebotene Applikation sicher zu machen. Zum Beispiel, weil eine geschlossene Lösung eingesetzt wird, die man nicht nach Belieben anpassen kann. Oder weil die Betreuung der betroffenen Komponenten durch eine externe Firma vorgenommen wird, und man deren Massnahmen nicht beeinflussen kann. In solchen Momenten vermag ein Proxy-Element ein gewisses Mass an Flexibilität und Unabhängigkeit zu erlangen.

Mit dem Einführen eines Proxies wird aber – abgesehen von der Gefahr einer falschen Sicherheit bei einer fehlerhaften Nutzung – ebenfalls eine zusätzliche Komplexität eingeführt. Diese kann zu Problemen im Betrieb führen, die sich ebenfalls direkt oder indirekt auf die Sicherheit der Umgebung auswirken können. Ein typisches und nicht zu unterschätzendes Beispiel ist die versehentliche Abschaltung der Proxy-Komponente, wodurch ungwollt eine unmittelbare Exponierung der (potentiell) verwundbaren Dienste stattfindet. Schon so manches Unternehmen musste in schmerzvoller Weise erfahren, dass damit die errichtete Sicherheit nur von temporärem Nutzen war.

Dieser Beitrag ist ursprünglich in den scip Labs erschienen.

Lese/Schreibe Kommentar: 0 printer friendly

Archiv
*Problem von OS Fingerprinting Kaskadierung17. Feb 14 : 09:56Marc's Blog
*Grundlegende RFID-Sicherheit28. Jan 14 : 10:08Marc's Blog
*Chancen verpassen13. Jan 14 : 12:22Marc's Blog
*Widerstand ist zwecklos17. Dez 13 : 09:33Marc's Blog
*Heuristik durch Zwischenaktivitäten umgehen02. Dez 13 : 09:28Marc's Blog
*Iterative Sicherheit19. Nov 13 : 08:43Marc's Blog
*Walled Garden - Ziele und Möglichkeiten21. Okt 13 : 15:59Marc's Blog

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


News Categories

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

Render time: 0.2788 second(s).