Was ist Sicherheit

In den vorhergehenden Grundlagen habe ich einige wichtige Aspekte der Sicherheit genannt. Nun geht es darum, was Sicherheit eigentlich ist und wie wir Sicherheit erlangen.

Beispielsweise sind Verschlüsselungen nur solange sicher, solange wir gute Schlüssel und Schlüsselkomponenten wählen. Denn ein unklug gewählter Schlüssel lässt die beste Verschlüsselung brechen.

Wie sicher ist der Zufall in der Informatik. Wie wir wissen, sind Computersysteme, auch Rechner genannt, sehr gut in der Berechnung. Doch wie sieht es mit der Erzeugung von Zufallszahlen aus? Kann man den Zufall berechnen? Denn Computer können immer nur bestimmte Eingaben zusammenrechen und daraus eine „Zufallszahl“ mittels bekanntem Algorithmus generieren.

Wird die Zufalls zahl nicht wirklich zufällig gewählt, so ist das beste Verschlüsselungssystem knackbar. So wie im Fall im Debian Betriebsystem.

https://www.debian.org/security/2008/dsa-1571.de.html

Hier war der berechnete Zufall berechenbar.

Pseudozufallsgeneratoren:
https://de.wikipedia.org/wiki/Pseudozufall

Wie können wir Sicherheit überprüfen?
Hierbei gibt es zwei grundlegende Frage zur Integrität:
Integrität des Ursprungs: Woher weiss ich, dass die Nachricht vom genannten Absender stammt?
Integrität der Korrektheit: Woher weiss ich, dass die Nachricht nicht verändert wurde?

Signaturen

Digitale Signaturen und deren Verfahren:
Das Prinzip hinter einer digitalen Signatur ist relativ simpel, der Absender hat eine Nachricht und signiert diese um damit die Herkunft und die Korrektheit (Unveränderbarkeit) zu gewährleisten.

Das Prinzip baut wieder auf dem bekannten Publik Key Verfahren auf, das heisst Sender und Empfänger haben jeweils einen privaten Schlüssel (sk: secret key) und einen öffentlichen Schlüssel (pk: public key).
Der Absender erstellt eine Signatur zu seiner Nachricht / Datei mittels seines privaten Schlüssels Sign(sk,m) und erstellt somit eine Signatur. Nun Übersendet er die Nachricht / Datei und die zugehörige Signatur.
Der Empfänger kann nun die empfangene Nachricht mittels Signatur und dem öffentlichen Schlüssels des Absenders auf Integrität überprüfen.
Veri(pk,m,Sig) ist die Nachricht unverändert.

Formal: Veri(pk,m,Sign(sk,m)) = 1

Die beiden bekanntesten und meistverbreiteten Hash-and-Sign Signaturverfahren sind RSA-basierte und DSA-basierte (Digital Signatur Algorithm), betzterer basiert auf dem diskreten Logarithmus Verfahren.

Hash-and-Sign Verfahren:
Dabei wird aus einer Nachricht m mittels einer Hash-Funktion H ein Hash-Wert der Nachricht m generiert, welcher dann mittels Privatem Schlüssel (sk) im Kern-Signaturverfahren zu einer Signatur der Nachricht m wird.

Probleme des Hash-and-Sign Verfahren:
Da eine Hash-Funktion von einer unendlichen Menge immer auf eine endliche Menge (160Bit, 256Bit, 384Bit oder 512Bit) abbildet, kommt es gezwungener Massen immer zu einer Kollision. Diese Kollision ist ein Angriffspunkt der Integrität. Eine Kollision ist aus mathematischem Grund nicht ausschließen, es soll aber sichergestellt werden, dass eine Kollision sehr schwer zu finden ist.

Kollisionsresistenz:
Eine Kollision in einer Hash-and-Sign Funktion ist, wenn ich mit einer veränderten Nachricht m‘ durch die Hash-Funktion die selbe Signatur erstellen kann, welche durch die original Nachricht erstellt wurde. Denn dann kann ich den Inhalt der Nachricht „beliebig“ abändern, denn dann wäre die Signatur der geänderten Nachricht ebenso gültig.

Bekannte Hash-Funktionen:
MD5 (Message-Digest Algorithm 5) erzeugt aus einer beliebigen Nachricht einen 128-Bit-Hashwert (absolut unsicher!)

SHA1 (Secure Hash Algorithm 1) bildet auf einen 160-Bit-Hashwert ab
SHA2 (Secure Hash Algorithm 2) bildet auf 224,256,384 oder 512-Bit-Hashwert ab
SHA3 (Secure Hash Algorithm 3) bildet auf 224,256,384 oder 512-Bit-Hashwert ab

RSA-Signatur:
Die RSA-Signatur funktioniert wie folgt, eine zu signierende Nachricht wird mittels einer Hash-Funktion auf einen Hashwert abgebildet, welcher dann auf die RSA Länge kodiert wird um im letzten Schritt diesen Wert mir RSA zu verschlüsseln.
Formal: sig = (Enc(H(m))) mod N

RSA-Verifikation:
Hierbei wird ähnlich wie bei der Signierung vorgegangen. Zuerst wird die zu überprüfende Nachricht mittels Hash-Funktion auf einen Hashwert abgebildet. Danach wird analog zum Signierungsprozess dieser Wert wieder auf die RSA Länge kodiert und verschlüsselt. Ist der erhaltene Wert identisch mit der Signatur der Nachricht, war die Verifikation erfolgreich.
Formal: (Enc(H(m))) mod N = signatur der Nachricht

DSA-Verifikation (Digital Signature Algorithmus):
DSA ist schneller für die Signaturerzeugung, aber langsamer für die Validierung, langsamer beim Verschlüsseln, aber schneller beim Entschlüsseln. Sicherheit kann als äquivalent betrachtet werden, verglichen mit einem RSA-Schlüssel gleicher Schlüssellänge.

Die Sicherheit des RSA-Algorithmus beruht auf der Tatsache, dass die Faktorisierung großer Ganzzahlen bekanntermaßen „schwierig“ ist, während die DSA-Sicherheit auf dem Problem des diskreten Logarithmus beruht. Der schnellste bekannte Algorithmus zum Faktorisieren großer Ganzzahlen ist heute das General Number Field Sieve, auch der schnellste Algorithmus zur Lösung des diskreten Logarithmusproblems in endlichen Feldern, modulo einer großen Zahl p, wie für DSA spezifiziert.

Der DSA-Schlüssel muss genau 1024 Bit lang sein, um mit den FIPS 186-2 von NIST kompatibel zu sein. Obwohl theoretisch längere DSA-Schlüssel möglich sind (FIPS 186-3 erlaubt dies explizit auch), sind Sie immer noch auf 1024 Bit beschränkt. Dennoch sollte man berücksichtigen, dass Schlüssellängen von 1024 Bit für RSA oder DSA als mehr sicher sicher gelten.

Bekannte Angriffe auf DSA:
2010 wurde bekannt, dass Sony die DSA-Signierung falsch angewendet hat, in dem Sony immer den selben Zufallswert zur Generierung der Signatur für Updates benutzt haben. Dadurch gelang es, die Signatur zu brechen und Fremden Code auf die Playstation 3 zu laden.
*Kleine Erklärung, Systeme wie z.B. die Playstation überprüfen im Normalfall Systemupdates / ausführbaren Code mittels einer Signatur, um sicher zu stellen, dass dieser nicht Schadhaft ist.

Durch einfache Mathematik lies sich der private Schlüssel von Sony berechnen. Hierbei wurden zwei DSA-Signaturen mit gleichem Zufallswert für den DSA Algorithmus gleichgesetzt und aufgelöst.

Auch eigener Recherche vieler Artikel kann ich folgende Aussage treffen:
Verwenden Sie niemals DSA oder ECDSA, die Schlüssellänge ist zu kurz.
Ed25519 ist mathematisch wahrscheinlich am stärksten (und auch am schnellsten), aber leider noch nicht weit verbreitet. Zusätzlich verfügt Ed25519 standardmäßig über eine stärkere Verschlüsselung durch den privaten Schlüssels als andere Schlüsseltypen.
Und RSA ist die beste Wahl, wenn Sie Ed25519 nicht verwenden können.

Raffael Haberland

Zertifikate

Ein Zertifikat ist ein digitaler Datensatz, der bestimmte Eigenschaften von Personen oder Objekten bestätigt und dessen Authentizität und Integrität durch kryptografische Verfahren geprüft werden kann. Das digitale Zertifikat enthält insbesondere die zu seiner Prüfung erforderlichen Daten. Die Ausstellung des Zertifikats erfolgt durch eine offizielle Zertifizierungsstelle, die Certification Authority (CA).
Quelle: Wikipedia

Zertifikate sollen uns ermöglichen die Integrität zu überprüfen. Denn stammt die Nachricht und die zugehörige Signatur wirklich von dem Absender? Wie kann man überprüfen, ob der Öffentliche Schlüssel wirklich dem Absender gehört? Denn schliesslich könnte ja auch ein Man-in-the-Middle auf der Leitung sitzen und sich zwischen den Sender und den Empfänger agieren.

Möglichkeiten der Überprüfen:
Direkter Schlüsselaustausch:
Man kennt und trifft den Sender persönlich um den öffentlichen Schlüssel auszutauschen. Das heisst man muss im direkten Kontakt mit dem Sender sein, der dann den Schlüssel übergibt und bestätigt.

Indirekter Schlüsselaustausch „Web-of -trust“:
Ähnlich dem direkten Schlüsselaustausch müssen Sie wiederum jemanden kennen, den Sie für vertrauensvoll kennen und der wiederum den Sender kennt oder eine für sich vertrauensvollen Kontakt hat um den Schlüssel weiter zu geben. Also eine Kette von vertrauensvollen Verbindungen. Schlecht ist hierbei, wenn man verschiedene Ansichten von einer vertrauensvollen Quelle hat und sich somit ein falscher öffentlicher Schlüssel in das Netz gelangt ist.

Zertifikate:
Hierbei hat man eine zentrale Zertifizierungstelle, welche den Absender und dessen öffentlichen Schlüssel beglaubigt und dafür ein Zertifikat ausstellt. Diese Zertifizierungstelle überprüft die Plausibilität der Person und des öffentlichen Schlüssels. Nun, kann jeder Empfänger sich an die Zertifizierungstelle wenden um einen öffentlichen Schlüssel eines Senders zu validieren.

Aufbau eines Zertifikates:
Inhaber: Name der Person oder Organisation für die das Zertifikat ausgestellt wurde.
Aussteller: Die Instanz, wleche das Zertifikat ausgestellt hat und beglaubigt.
Seriennummer:
Gültigkeit: von wann bis wann das Zertifikat gültig ist.

Bekannter Angriff auf Zertifikate:
Einbruch in Zertifizierungsstelle DigiNotar, dort wurden dann falsche unter Zertifikate unteranderem für Google, Microsoft, Skype und auch staatliche Public-Key-Infrastruktu ausgestellt um mit diesen falsche Server zu betreiben. DigiNotar hat wenige Tage nach dem Einbruch Insolvenz angemeldet.

MD5-Zertifikatskollisionen, Zertifikate welche mittel zu schwacher Hash-Fingerprint ausgestellt wurden können leicht durch die Zertifikatskollision manipuliert werden. Darum sollten keine MD5 oder Sha1 Zertifikate mehr akzeptiert werden. Gängige Browser überprüfen das automatisch und warnen beim Aufbau dieser Verbindung.

Test zur Überprüfung: https://sha1-intermediate.badssl.com/

• 

• 

• 

Auf Grund dieser Problematik gibt es auch eine Certificate Revocation Lists (CRLs) welche falsche Zertifikate revoziert.

Revoziertes Zertifikat: https://revoked-demo.pca.dfn.de/

Juristische Bedeutung elektronischer Signaturen

1997 und 2001 gab es eine Gesetzesanpassung im BGB bezüglich der Rechtssicherheit für elektronische Signaturen, welches besagt, dass elektronische Signatur (als Daten verknüpft), der Authentisierung dienen. Die Signatur dem Unterzeichner zuzuordnen ist und der Unterzeichner das Mittel zur Erstellung unter alleiniger Kontrolle hat um damit mit unterzeichnete Daten sicher zu verknüpfen. Auch dient die qualifizierte Signatur wie eine fortgeschrittene Signatur und qualifiziertes Zertifikat und sichere Signaturerstellungseinheit auch im digitalen Schriftverkehr.

Folgen: Mit dieser Gesetzesänderung darf der (neue) Personalausweis, welcher zur Zertifizierung zugelassen wurde fortan nicht mehr in dritte Hände gegeben werden. Somit darf vom Ausweisinhaber zu keiner Zeit mehr der Personalausweis als Pfandgut zur Hinterlegung verlangt werden.

Die elektronische Signatur dient nun auch zu weiteren Authentisierungsarten, wie elektronische Siegel (für juristische Personen/Services), Zeitstempel Zustellungsservices und zur Webseitenauthentisierung.

Symmetrische Signaturen

MAC (Message Authentication Codes):
Bei dieser Signatur verwenden beide Seiten den selben Schlüssel, was bedeutet, dass der Schlüssel genau einer Person zuzuordnen ist.
Prinzip: Gleicher Schlüssel zur Erzeugung und Verifikation einer Nachricht.
Funktionale Korrektheit: Verif(k, m, MAC(k,m)) = 1

Plausible Deniability (Abstreitbarkeit): Wenn man eine Authentifizierung mittels MACs macht, kann man kryptographisch nicht beweisen welche Seite eine Nachricht geschickt hat, da beide Seiten der Symmetrie wegen den gleichen MAC erzeugen kann.

Geschwindigkeit: Ein anderer Grund für den Einsatz von MACs ist, dass wie schon vorher genannt eine symmetrische Verschlüsselung viel einfacher und damit auch viel schneller ist (ca. um den Faktor 20).
Erklärung: Der One-Time Overhead von eingesetzten Public-Key Signaturen liegt bei ca. 50.000 Taktzyklen, zusätzlich kommt die Verarbeitung durch die vorgeschaltete Hash-Funktion dazu. Die zugehörige Verifikation einer Nachricht ist analog genauso rechenintensiv.
Ein (H)-MAC für eine vergleichbare Nachricht benötigt ca. 2.400 Taktzyklen auf derselben CPU. Zusätzlich haben moderne Prozessoren speziell für diesen Zweck Spezialinstruktionen welche die symmetrische Verschlüsselung, die auf AES basieren (CBC-MAC) nochmal stark beschleunigen.

Ein Anschauliches Beispiel ist hierbei der nPA Personalausweis

Abstreitbarkeit Personalausweis

Eine Funktion des neuen Personalausweises (nPA) ist, dass wir damit Signieren können, das heisst, wir können diesen beispielsweise online für Geschäftsabwicklungen und Behördengänge nutzen. Doch welche Probleme bringt diese Funktion noch mit sich? In Hinblick auf die Abstreitbarkeit ist eine Signatur mittels Publik-Key Verfahren sehr kritisch anzusehen. In dem Moment, in dem man mir dem nPA eine Nachricht signiert, ist diese Nachricht nicht mehr abstreitbar. In Hinblick auf Grenzkontrollen in autoritären Ländern stellt dies ein großes (politisches) Problem dar.
Betritt eine vom Bundesnachrichtendienst eine nachrichtendienstliche Verbindung ein Land über eine Grenzkontrolle, bei der, der elektronische Reisepass (ePass) oder neue Personalausweise (nPA), das Betreten durch eine Challagne (Aktuelles Datum und Lokalität) mittels Publik-Key Verfahren Signiert, so ist die Abstreitbarkeit dass diese Person jemals im Land war unmöglich. Denn nur genau dieser Personalausweis mit genau dieser Signatur kann genau diese Nachricht signieren. Eine Möglichkeit wäre eine symmetrische Signatur mittels MAC, bei der die Grenzkontrolle und der Pass den selben Schlüssel besitzen. Hierbei ist die Abstreitbarkeit gegeben, denn dann ist die Signatur abstreitbar, da der Schlüssel auch der Grenze bekannt und von dieser erstellt sein könnte.

Authentifizierte Verschlüsselung: Hierbei wird neben der Vertraulichkeit auch die Authentizität und die Integrität sicherstellt.

Authentisierung

Die Authentisierung kann durch verschiedene Arten durchgeführt werden. Beispielsweisse durch:
Wissen: also Logindaten wie: Benutzername und zugehöriges Passwort
V

Hardware: z.B. eine Zugangskarte in Form von einer Magnet,Chip oder NFC

Biometie: Fingerabdruck, Iris oder Venen

Zwei-Faktor-Authentisierung (2FA)
Eine einfache Umsetzung des Identitätsnachweises mittels Kombination unterschiedlicher Komponenten, Sozusagen eine Art Challenge-Response-Verfahren. Hierzu wird beispielsweise beim Loginprozess eine Pusch-Nachricht, SMS oder ein automatisierter Anruf auf ein Mobilgerät getätigt, welcher einen Code zum Login übermittelt. Dadurch wird ein nicht autorisierter Login zwar nicht ausgeschlossen aber um einen Faktor erhöht. Auch kann man beispielsweise eine lokale Abfrage integrieren, so dass eine Push Nachricht nur dann versendet wird, wenn sich das Smartphone in einem bestimmten Gebiet befindet. Weiterer Sicherheitssfaktor ist, dass man voraussetzt, dass das Smartphone in Besitz des korrekten Eigentümers ist und zusätzlich noch beispielsweise über einen Pin geschützt ist.

Biometrische Authentisierung

Wie sicher sind unsere biometrische Daten? Man darf bei den biometrischen Daten nicht ausser Acht lassen, dass diese relativ einfach öffentlich einsehbar sind und vor allem nicht veränderbar sind. Zudem wurde auch schon vom CCC gezeigt, wie einfach man eine Kopie eines Fingerabdrucks anfertigen kann. Nicht weniger einfach sieht es bei der Kopie einer Iris aus. Kleiner Einwurf, dank der sehr großen Wahlplakate und der damit verbundenen Auflösung ist die Authentifizierung mittels Iris-Scan für führende Politiker nicht mehr möglich.

Sicherheit auf Servern

Oft ist nichtmal der Benutzt sondern der Betreiber eines Dienstes ein Sicherheitsrisiko, wenn beispielsweise Datenbestände einer Firma geklaut werden, welche Logindaten beinhalten. Aktuelle Liste der gehackten Dienste / Unternehmen. Darum ist es wichtig, dass man für jeden Dienst ein eigens dafür gültiges Passwort hat, bestenfalls sogar separate e-Mailadressen und oder Usernamen.

https://www.troyhunt.com/the-773-million-record-collection-1-data-reach/

Ein Betreiber sollte niemals Logindaten in Klartext speichern oder übertragen. Eine der besten und elegantesten Lösungen ist die Anmeldung mittels One-Way-Funktionen. Diese Funktionen erstellen aus den Logindaten einen einmaligen Wert, welcher dann (sollte trotzdem verschlüsselt) an den Server übertagen werden. Hash-Funktionen wie SHA-2, SHA-3 gelten als One-Way-Funktion. Zusätzlich sollten die Logindaten nicht einfach nur durch diese Funktionen gehasht werden, sonder sollten noch zusätzliche Faktoren (salted Hash) beinhalten, so dass ein Angriff mittels Rainbow-Tables nicht möglich ist.

Rainbow-Tables sind Tabellen, welche ganze Wörterbücher und gängige Passwörter in gehashter Form beinhalten. Sollte also ein Betreiber die Passwörter seiner Benutzer einfach nur simpel gehasht haben, kann ein Angreifer durch den Vergleich mittels dieser Tabellen das Passwort nachschlagen.

Was aber wenn der Serviceanbieter alle Sicherheitsvorkehrungen richtig getroffen hat, wie würde dann ein Angriff aussehen? Folgendes Szenario: Der Dienstanbieter speichert nur den Hashwert der Logindaten und beim Loginprozess auf der Webseite werden die eigegebenen Logindaten des Users direkt gehascht und erst danach zum Server zur Überprüfung verschlüsselt gesendet. Bis hierhin scheint alles Sicher zu sein.

Pass-the-Hash-Angriffe (PtH)
Hierbei verschafft sich der Angreifer Zugang auf das System des Clienten, der sich bereits auf der Webseite des Dienstanbieters eingeloggt hat. Das Betriebsystem bzw. der Browser sichert im Hintergrund die gehashten Logindaten für einen erneuten Zugang, damit der Nutzer diese nicht erneut eingeben muss. Auch Login Session genannt, bekannt bei Webmail Anbietern, Amazon, Facebook usw. (Diese Sessions laufen im Gegensatz zu denen bei einer Bank nicht so schnell ab.) Der Angreifer muss nun nur gezielt nach diesen schon gehashten Zugangsdaten suchen und kann diese dann auf seinem/anderem System (wieder) verwenden, da der Server die gehashten Logindaten akzeptiert.

Tokens

Token-basiertes Authentisieren:
Tokens können entweder softwarbasiert sein oder als Hardware vorliegen. Der bekannteste Token ist z.B. der Autoschlüssel, der über eine Funkverbindung die Türen entriegelt.

Tokens können statisch oder dynamisch sein, ein statischer Token übersendet einfach immer das selbe Geheimnis. Somit kann ein Angreifer das Signal aufzeichnen und immer wieder verwenden. Z.B. alte Garagentore nutzen einen statischen Token zum Öffnen und Schliessen.

Eine Neuerung sind Rolling-Codes welche momentan Anwendung in der Automobilindustrie finden. Basierend auf einem gemeinsamen Geheimnis zwischen Sender und Auto („symmetrischer Schlüssel“). Hierbei generiert das Auto eine Liste mit endlichen vielen Codes, welche im Betrieb (z.B. bei der Autofahrt) dem Schlüssel überliefert werden. Bei jeder Interaktion (Schliessen oder Öffnen) hängt der Schlüssel von einen Code aus der Liste an. Jeder Code ist nur einmal gültig und wird nacheinander abgearbeitet. Das Auto setzt einen Pointer auf seine Liste um sicherzustellen, dass die Reihenfolge eingehalten wird. Drückt der Benutzer in Abwesenheit n-mal auf den Sender und danach ein weiteres mal in Anwesenheit des Autos auf den Schlüssel, so springt der Pointer n+1 Stelle in der Liste weiter. Alle Codes im Bereich n-1 sind ab jetzt nicht mehr gültig. Dies soll vor Replay-Attacken schützen.

Angriff auf Rolling-Codes geschieht indem beispielsweise beim Schliessen oder öffnen des Autos dieser Code abgefangen wird, der Benutzer denn ein weiteres Mal auf den Sender drückt und einen weiteren Code schickt. Auch dieser wird dann vom Angreifer abgefangen und zugleich der zuerst Abgefangene Code vom Angreifer an das Auto gesendet. Jetzt ist der Angreifer in Besitz des zweiten und noch gültigen Codes.

Ein dynamischer Token dagegen berechnet noch etwas in den Token hinein (Challenge-Response), somit kann ein Angreifer den Token nicht einfach abfangen und beliebig kopieren / benutzen. Hierbei findet im Hintergrund eine „Kommunikation“ statt, also der Token spricht zum Beispiel die Tür an, dass diese bitte entsperrt werden soll. Darauf sendet die Tür eine Challenge an den Token, die dieser erfolgreich beantworten muss (Response). Ist die Response richtig, entriegelt die Tür, ist die Response falsch verwirft die Tür die Anfrage.

Fängt nun ein Angreifer das Signal ab, und sendet dieses erneut an die Tür, bekommt er einen neue zufällige Challenge, die der Angreifer im Normalfall nicht lösen kann. Somit ist jede Anfrage einmalig und eine Response ist nur einmal gültig.

Die Implementierung geschieht hierbei meist darüber, dass der Empfänger an den Sender einen zufälligen Wert übermittelt und diesen Wert vom Sender signiert bekommen möchte. Der Sende empfängt den Wert, signiert diesen und sendet den signierten Wert zurück. Nun überprüft der Empfänger, ob die Signatur gültig ist.

Alternativ würde dies auch mittels Verschlüsselung gehen, hierbei verschlüsselt der Empfänger einen zufälligen Wert und schickt diesen an den Sender. Der Sender entschlüsselt diese Nachricht und sendet den Inhalt dann an den Empfänger zurück. Der Empfänger Vergleicht und agiert dann.

CAPTCHAs

Completely Automated Public Turing test to Tell Computers and Humans Apart sollen zur überprüfung verwendet werden, um festzustellen, ob eine Eingabe / Tätigkeit durch einen (menschlichen) Benutzer oder automatisiert durch einen Computer geschieht. Hierbei verweise ich auch nochmal auf den Turing-Test. Bei der Vermeidung automatisierter Interaktionen sollen beispielsweise auch die in der Vergangenheit oft verwendeten DoS- und dDoS-Angriffe verhindert werden. Also massenhafte Anfragen auf einen Server, der dann der Verarbeitung nicht mehr in Stande ist und unter der Last der Anfragen nicht mehr Antworten kann.

• 

• 

• 

• 

• 

CAPTCHAs werden automatisiert (mittels Filter) erstellt und sollen per menschlicher Eingabe gelöst werden. Einer der bekanntesten Ersteller von CAPTCHAs ist Google, wiederum hat Google dadurch das Know-How um genau diese maschinell lösen zu können. So wurde letztes Jahr bekannt, dass Googledienste dazu genutzt wurden Google eigene CAPTCHAs maschinell zu knacken.

https://www.google.com/recaptcha/intro/v3.html
https://www.googlewatchblog.de/2019/01/mit-waffen-uncaptcha-recaptcha/
https://computerwelt.at/news/google-algorithmus-knackt-captchas/

noCAPTCHA, reCAPTCHA

eine Weiterentwicklung der CAPTCHAs ist reCAPTCHA, hierbei werden verschiedene Faktoren zur Überprüfung, ob der Client ein Mensch oder ein Computer ist mit einbezogen. Unter anderem wird die IP Adresse des Clienten überprüft, ob diese zu einem Server gehört und ob die IP Adresse zuvor schon durch auffälliges Surfverhalten aufgefallen ist. Auch Browser-Informationen, Cookies und Mausbewegungen werden hier mit einbezogen. Besteht der Verdacht, dass es sich bei der Anfrage um eine automatisierte Anfrage durch einen Rechner handeln könnte, wird bei reCAPTCHA wieder eine Lösung eines CAPTCHA verlangt.

Bild- und auch Audiobasierte CAPTCHAs werden heute schon relativ einfach per Deep Learning gebrochen.

DoS und dDoS Angriffe

Ein Denial of Service (DoS) Angriff ist ein Angriff, der darauf abzieht ein System mit Anfragen zu überflutet, dass das System nicht mehr in der Lage ist, andere Interaktionen durchzuführen oder andere Anfragen zu beantworten. Das Angegriffene System ist dann mit dem Protokollieren der Anfragen so beschäftigt, dass es keine Recourcen mehr frei hat um zu anworten. Hierbei können einzelne Server wie auch ganze Netzwerke lahmgelegt werden. Kleines Beispiel, wird ein Router von einem Angreifer mit vielen Anfragen kontaktiert und ist gegen diesen Angriff nicht gewappnet, so kann er Anfragen von anderen Nutzern in seinem Netz nicht mehr beantworten. Daraus folgt, dass alle anderen Nutzer keinen Datenaustausch durchführen können. In letzter Vergangenheit waren beispielsweise Netflix, Twitter, Sporitfy, New York Times und auch das Wall Street Journal zeitweise nicht erreichbar.

DDoS Attacke

Bei der DDoS Attacke handelt es sich dabei um eine Attacke von mehreren Systemen ausgehend, also das d steht für distributed. Hier kommen vorzugsweise Bots zum Einsatz, welche auf einem zuvor infizierten System „schlummern“ und auf ihren Einsatz / Angriff warten. Ruft der „Master“ seine Bots zum Angriff auf, so agieren diese selbständig und führen eigenständig unzählige Anfragen auf eine IP oder ein ganzes Netz durch.

PING of Death

Früher war es möglich, einen Computer von der Netzwerkkommunikation auszuschliessen, in dem man diesem viele und vor allem große PING-Anfragen geschickt hat. Alte und rechenschwache Computer sind dabei sogar abgestürzt, weil der Puffer des Empfängers dabei so geflutet wurde, dass dies zum sogenannten „Buffer Overflow“ führte. PING ist eigentlich ein Diagnose Tool, um eine Verbindung zu einer IP zu messen. Ping sendet ein ICMP-„Echo-Request“-Paket an die Zieladresse und wartet auf die Antwort, der Zieladresse um die Übermittlungsqualität zu überprüfen. Übermittlungsdauer und Erreichbarkeit.

Teardrop Attack

Hierbei sendet ein Angreifer falsch fragmentierte Pakete mit überlappenden Offset-Feldern. Sobald der Zielkomputer diese Fragmente zusammengefügt, kann er abstürzen. Dieser Angriff nutzt die Möglichkeit, dem IP-Layer ein übergroßes Paket zu senden und nutzt dadurch den Schwachpunkt bei der Wiederherstellung von IP-Paketfragmenten aus. Diese DoS-Attacke blockiert durch die Sendung von IP-Fragmenten den Zielrechner. Es werden fragmentierte IP-Pakete mit einer negativen Fragment-Länge versendet.

Heute ist (sollte) dies nicht mehr Möglich sein, dafür kann man aber ein System immer noch mittels DoS Attacke fluten, dass dieses nicht mehr zum Antworten kommt. Der dadurch entstandene Schaden kann je nach Dienst enorm sein. Beispielsweise Echtzeitanwendungen laufen nicht mehr synchron. Oder ein wirtschaftlicher Schaden durch die nicht-Erreichbarkeit eines Dienstes kann die Folge sein. Wenn die Webseite von Amazon nichtmehr oder auch nur zeitweise nicht mehr erreichbar ist, kann in dieser Zeit kein Kauf getätigt werden, dadurch entgehen Amazon Gewinne.

Smurf Attacke

In einem lokalen Netz führt der Angreifer eine gefälschte PING-Anfrage an alle Teilnehmer im Netz durch, wobei er jedoch als Antwort-Adresse nicht seine sondern die des Opfers angibt. Dadurch antworten alle Netzteilnehmer auf die Adresse des Opfers und fluten diesen mit Datenpaketen. Besteht ein Netzwerk beispielsweise nur aus 100 Geräten und erfolg eine Antwort mit nur 30 Datenpaketen, so muss das Opfer 3000 Datenpakete bearbeiten.

SYN-ACK-Flooding Attacke

Hierbei wird die „Freundlichkeit“ des Transmission Control Protokoll TCP zum Angriff ausgenutzt. Bei einer TCP-Verbindung „bittet“ der Client mittels SYN-Anfrage den Server um Kommunikationkontakt. Der Server öffnet darauf dem Client ein Kommunikationsport und schickt diesem ein SYN-ACK und wartet darauf auf eine eingehende Verbindung des Clients. Dieses Vorgehen wird auch Handshake genannt.

Bei der SYN-ACK-Flooding Attacke, welche typischerweise durch ein Bot-Netz (viele Bots) durchgeführt wird, stellen die Bots ganz viele SYN Anfragen dem Server. Dieser stellt dann Ports zur Übertagung bereit und wartet dann (eine bestimmte Zeit) auf eingehende Verbindungen. Sind alle freien Ports durch das SYN-ACK-Flooding belegt, kann der Server keine neuen Anfragen bearbeitet und weist darum diese ab.

SYN-ACK Flood Reflection Attack

Hierbei wird wie bei der SYN-ACK-Flooding Attacke vorgegangen, jedoch mit dem Unterschied, dass der Angreifer SYN-Anfragen in einem Netz an alle Nutzer stellt in der er als Absender die IP des Opfers schreibt. Jetzt werden alle Geräte im Netz eine SYN-ACK-Nachricht an das Opfer schicken und dieses damit überfordern, d das Opfer jetzt freundlicherweise mit einer RST-Nachricht jeder SYN-ACK-Nachricht antwortet.