 Ich stelle euch heute der weakest link vor, das ist eine Sammlung an Cross-Site-Request-Fortuary-Schwachstellen in den Web-Applegationen von Mobilfunkbetreibern. Der weakest link deswegen, weil sich auch im Jahr 2020 noch immer Mobilfunkbetreiber als das schwächste Glied einer Sicherheitskette erweisen. Besonders dramatisch ist bei diesen Sicherheitslücken, dass es sehr einfach auszunützende Sicherheitslücken sind. Also im Gegensatz zu anderen, die schon beim Mobilfunkbetreibern aufgezeigt worden sind, wie zum Beispiel SS7-Sicherheitslücken. Braucht man hier keinen Zugang zu irgendeinem Gateway, man braucht auch kein spezielles Know-how über das Core-Netzwerk von Mobilfunkbetreibern, weil es relativ simple, triviale Sicherheitslücken in den Web-Applegationen sind. Grundsätzlich beginnt sehr viel mit einem langweiligen Newsletter, den man zugeschickt bekommt. Wie ihr hier seht, habe ich im Jahr 2020 26-mal einen Newsletter mit dem Titel Treppenlift aktuell zugeschickt bekommen. Das ist jetzt nur ein Beispiel, dieser Treppenlift-Newsletter hat mich nicht gehackt, aber es ist ein Beispiel für einen langweiligen und nervigen Newsletter. Die ersten zwei Male, wenn man so etwas bekommt, ignoriert man es noch. Wenn man so etwas 26-mal bekommt, wird jeder von euch oder die meisten von euch, glaube ich, schwach. Und klicken dann irgendwann einmal drauf, scrollen ganz runter bei dem Newsletter und finden dann den erlösenden Ansubscriber-Link. Und wenn man dann draufklickt auf Ansubscribe, kommt so eine Website, oft von irgendeinem Newsletter-Tool, wo dann einfach drauf steht, sie haben sicher erfolgreich von dem Newsletter abgemeldet. Und in dem Fall denkt man dann, dass man nie mehr wieder von diesen Treppenlift-Leuten hört. Es kann nur dann sein, einige Zeit später, wenn man sich versucht zum Beispiel in seinem Google-Account oder woanders anzumelden, findet der Passwort-Manager plötzlich kein richtiges Passwort und man ist von seinem Google-Account ausgelockt. Wenn man jetzt diesen Bezug herstellen kann, man hat gerade da auf einen Ansubscriber-Link geklickt und direkt darauf hin wurde man auf unserem Google-Account ausgesperrt, dann kann man vielleicht sich diese Seite, die man da angeklickt hat oder die sich geöffnet hat, noch genauer ansehen. Und wenn wir hier einmal in den Source-Code von der Website uns das anschauen, sehen wir hier ein Formular. Das war nicht sichtbar, es ist ein unsichtbares Formular mit zwei unsichtbaren Feldern. Und wie ihr hier schon seht, es geht hier Hot.at, es ist ein Mobilfunkbetreiber, es geht hier um den EPI Endpoint Z Call Forwarding Extended und dann wird hier eine Telefonnummer 4.30, die Vorwahl von Österreich und dann 6.80, vom Betreiber Bob, eine Telefonnummer, wird hier anscheinend eine Rufumleitung gesetzt. Das geht eben völlig im Hintergrund, ein unsichtbares Formular wird in ein unsichtbares Iframe geladen und dieses Formular wird, sobald man die Seite geöffnet hat, automatisch abgesendet. Bei Google ist es so aber auch bei vielen anderen Betreibern, dass sie einen dazu bewegen eindringlich zum Schutz ihres Kontos, schreiben sie hier, wir verwenden Ihren Nummer zum Schutz ihres Kontos, soll man sie doch eintragen, eine Telefonnummer, wenn man sein Passwort vergisst, kann man über diese Telefonnummer dann seinem Google-Account wieder zurücksetzen. Gehen wir jetzt einmal kurz einen Schritt zurück und schauen wir uns an, was geht es denn da eigentlich? Das sind sogenannte CSIF-Schwachstellen, das ist grundsätzlich überhaupt nichts Neues. Schon in den 80er Jahren hat jemand das Confused Deputy Problem beschrieben. Da geht es grundsätzlich darum, dass ein Programm mit weniger Privilegien, ein Programm mit mehr Privilegien dazu bringt, etwas auszuführen. Seit wir das Web haben, wird diese Schwachstelle, wenn der Confused Deputy der Web-Browser ist, als CSRF abgekürzt, manchmal CSERF ausgesprochen oder XSRF und in den meisten Fällen geht es darum, vor allem aus Sicht der angreifenden Person um Session Riding, weil es um Sessions geht, die mit Cookies funktionieren. Das muss aber nicht sein, das werden wir da noch ein bisschen später sehen. Man kann auch eine Authentifizierung mit der Bierdressen machen, aber in den meisten Fällen ist CSRF auch Session Riding. Wir schauen uns das jetzt noch einmal ein bisschen schematisch an. Hier sehen wir ganz links unten einen Hacker oder eine Hackerin. Das sieht man jetzt nicht so, weil natürlich die Person eine Maske und eine Kapuze trägt, wie sich das gehört. Und im ersten Schritt sendet diese Person, einer Zielperson einen Link. Das muss aber auch nicht unbedingt ein Link sein. Es geht darum, dass man irgendeine Zielperson bringt, eine kompromittierte Seite zu besuchen. In dieser Seite, im besten Fall und in normalen Fall ist das die eigene Seite, aber es kann auch ein Vorraum oder irgendeine andere Seite sein, wo man HTML Content einfügen kann. Im zweiten Schritt sendet die Zielperson einen GetRequest an die kompromittierte Seite und bekommt dann im dritten Schritt den Payload in der Form, wie wir vorher gesehen haben, zum Beispiel eines Formulas zurück. Und das Formular wird dann, sobald die Seite geöffnet ist, abgeschickt. Und zwar eine andere Seite. Und in dem Fall sind das Mobilfunkbetreiber, wo die Zielperson bereits authentiziert ist. Und dadurch, dass dann der Server, auf dem die letzte Anfrage stattfindet, glaubt, dass die Zielperson diesen Anfrage geschickt hat, wird dieser Befehl die Anfrage auch ausgeführt. Grundsätzlich, wie ich das zum ersten Mal Personen erzählt habe, haben viele ein bisschen verwundert, geschaut und gesagt, da gibt es doch die SameOrigin-Policy, die sich da verschützt, dass solche Cross-Site-Requests gemacht werden. Wie kann denn das passieren oder wie kann das im Jahr 2020 noch sein, dass so etwas durchgeführt wird? Das ist anscheinend ein sehr übliches Missverständnis. Es ist grundsätzlich so, dass SameOrigin-Policy im Webbrowser durchgesetzt wird. Natürlich nicht im Server. Und die sorgt dafür, dass Inhalte nicht gelesen werden können, die Cross-Sites geschickt werden. Eine Anfrage wird aber trotzdem ausgeführt. Das heißt, CSRF betrifft nur sogenannte Zustandsverändernde Anfragen. State-Changing-Requests und Nicht-Anfragen, bei denen einfach irgendeine Information ausgelesen wird. Wir sehen jetzt hier zwei Beispiele für State-Changing-Requests. Also eine Nicht-Zustandsverändernde Anfrage ein Beispiel. Das ist zum Beispiel einfach hier Action ist gleich Info und dann wird man als Antwort die E-Mail-Adresse, Telefonnummer, alles Mögliche zu einem User bekommen. Diese erste eben Nicht-Zustandsverändernde Anfrage ist nicht CSRF anfällig, weil man die Antwort nicht lesen kann und weil sich sonst dadurch nichts verändert aufgrund dieser Anfrage. Das heißt, das einzige Ziel dieser Anfrage ist, dass Inhalte ausgegeben werden. Bei der Zustandsverändernde Anfrage, die wir jetzt hier als zweites Beispiel sehen, wird E-Mail ist gleich attacker.evil.com als neue E-Mail-Adresse eingesetzt. Das heißt, hier wird der Zustand verändert, hier wird nicht einfach nur etwas aus einer Datenbank ausgelesen, sondern etwas in eine Datenbank geschrieben. Die Antwort kann hier zum Beispiel Response ist gleich Success oder irgendetwas sein. Die Antwort kann eine attackierende, eine angreifende Person auch nicht lesen, braucht sie aber nicht, weil der Schaden ja schon angerichtet ist. Die E-Mail-Adresse wurde in dem Fall in der Datenbank von example.com geändert. Das heißt ganz wichtig, CSRF betrifft nur State Changing Request zustandsverändernde Anfragen. Wir sehen uns jetzt das Ganze einmal in einer ersten Demo an. Bei dieser Demo geht es um Ventocom. Ventocom ist ein sogenannter Mobile Virtual Network Enabler. Das heißt, diese Firma ermöglicht zum Beispiel Supermärkten, einem Supermarkt, einem Fußballclub und einem Kabelnetzbetreiber ihre eigene Mobilfunkmarke zu betreiben. Das ist in dem Fall HOT. HOT ist Hofer Telekom für Deutsche. Hofer ist eine Tochterfirma von Aldi Süd. Gibt es eben in Österreich und in Slowenien. Das heißt HOT.at und HOT.se ist davon betroffen. Und ist davon aber auch betroffen Rapid Mobile. Also, das ist RapidVenus ein Fußballclub und LeaVest Mobile. Das ist der Linzer-Kabelbetreiber. Insgesamt betroffene Accounts. Man weiß nicht genau, wie viele Personen das betroffen sind. Weil eine Person kann mehrere SIM-Karten haben. Aber welche betroffene SIM-Karten sind auf jeden Fall mehr als eine Million in Österreich und mehr als 100.000 in Slowenien. Das werden wahrscheinlich schon um einiges mehr wieder sein. Aber das sind die letzten Zahlen, die dazu offiziell bekannt gegeben worden sind. So, jetzt schauen wir mal hier uns das bei der Demo an. Und ich öffne den Browser. Am besten zeige ich jetzt noch einmal, wie man sich hier auch einlockt. Und zwar locken ist grundsätzlich gar nicht so blöd gelöst. Es ist praktisch hier Passwort frei. Was nicht unintelligent ist, weil die Leute vergessen natürlich ihre Password. Und wenn sie sie nicht vergessen, haben sie meistens sehr, sehr einfache, simple Password, die schon hundertmal geliegt worden sind. Und das könnte man dann mit Passwortrecycling schneller mal so in einen Account übernehmen. Was sie dadurch verhindert haben, dass man in dem Fall sich nur einlocken kann mit dem Book-Code oder mit einem Einmalkode, den man auf das Telefon sich schickt, oder bei E-Mail. Wir machen das jetzt einmal bei E-Mail. Wir haben hier Zielpersonen 523, die E-Mail-Workroom als E-Mail-Adresse hinterlegt. Und wir bekommen dann ein E-Mail von HOT und können uns über diesen Link ganz einfach anmelden. In dieser Kundenzone von HOT kann man alle möglichen Änderungen vornehmen. Grundsätzlich ist es so, wenn man ein Kundenkennwort ändert, dann ist es hier sehr intelligent gemacht. Man muss das alte Kundenkennwort eingeben, um dann ein neues Kundenkennwort setzen zu können. Das ist relativ standard. Allerdings, wenn man seine E-Mail-Adresse ändert, wie wir gerade gesehen haben, man kann sich einfach mit der E-Mail-Adresse einlocken, dann muss man hier nichts eingeben. Das heißt, man muss kein Passwort eingeben, sondern kann einfach die E-Mail-Adresse ändern. Was sehr kundenorientiert ist, allerdings sehr unsicher, weil hier auch keinerlei Antisiers AF-Token, wenn wir später besprechen, hier mitgeschickt werden. Jetzt muss ich nur noch die E-Mail-Adresse wieder auf die alte umändern, damit wir kaum nichts vorwegnemen. Die alte E-Mail-Adresse ist Zielperson 523 at G-Mapbock. Wenn wir uns hier noch weitere Funktionen ansehen, dann kann man hier unter anderem eine Rufumleitung einrichten. Die Rufumleitung ist grundsätzlich das, was wir uns hier besonders ansehen. Grundsätzlich können wir das jetzt mal schließen. Und ich zeige jetzt hier Boring Newsletter Nr. 1. Wenn die Zielperson hier auf klick hier durch Ansubscribe klickt, kommt, wie wir schon vorher gesehen haben, eine Listmanage.email-slash irgendwas steht dann User Successfully Unsubscribed. You will no longer receive e-mailmarketing from this list. Was hat sich jetzt hier getan? Vielleicht sehen wir das am besten jetzt aus Sicht des Angreifers schon. Ich habe jetzt hier ein privates Fenster aufgemacht. Aus Sicht des Angreifers. Und wenn wir hier jetzt die alte E-Mail-Adresse eingeben, dann sollte die nicht mehr gefunden werden. Das sind 523 und es kommt eine Fehlermeldung. Diese E-Mail ist uns nicht bekannt. Das ist sehr gut. Und wenn ich jetzt die E-Mail-Adresse von der angreifenden Person eingebe, das ist jetzt eine Protomail-Adresse, dann steht hier, sie haben eine E-Mail mit dem Zugangslink erhalten. Und das kann jetzt natürlich einige Sekunden dauern, aber ist schon da. Und wenn wir diese öffnen, sehen wir, wir sind im gleichen Account wie vorher. Das heißt, wir haben uns jetzt mit der neuen E-Mail-Adresse hier einloggen können. Und was wir auch sehen können, ist, dass die Hofumleitung jetzt plötzlich gesetzt ist. Das ist vorher, war hier keine Hofumleitung und hier sieht man jetzt, wie seine Hofumleitung auf diese plus 43680-Nummer gelegt. Jetzt braucht sich der Angreifer-Nummer bei Gmail mit Zielperson 523-Ads-Gmail.com-Versuchen einzulocken. Das Passwort kennen wir natürlich nicht. Wir können hier auf Passwort vergessen klicken, auf andere Optionen wählen. Und dann können wir hier auswählen, wie wollen Sie ein Bestätigungschord abrufen und in dem Fall, weil wir die Hofumleitung von dieser mit 66 änderten Telefonnummer auf die andere Telefonnummer eingerichtet haben, können wir jetzt diesen Anruf anfordern und jetzt müsste das Telefon gleich leuten. Ja, perfekt. Das ist jetzt eine US-Nummer aus Washington DC, wie man hier sieht. Und... Vielen Dank, dass Sie die telefonische Bestätigung für Google verwenden. Eben Sie diesen Code unter keinen Umständen an jemand anderen weiter. Mitarbeiter von Google fragen grundsätzlich nicht nach diesem Code. Ihr Code lautet REX. Auf Wiederhören. Vielen Dank. Und wir können jetzt hier einfach ein neues Passwort einsetzen, das Passwort speichern. Und vielen Dank. Wir als Angreifen der Person nicht nur die Telefonnummer und den Account bei HOT übernommen, sondern wir haben auch den Gmail-Account übernommen und damit natürlich Zugriff auf sehr viel. So, das war jetzt die erste Demo. Und ich gehe jetzt wieder auf die Folie. Zusammenfassend zu dieser ersten Demo als Voraussetzung. Die Zielperson besucht eine komprimente Seite. Es ist schon ein gültiges Session Cookie vorhanden. Das heißt, die Zielperson hat sich davor einmal eingeloggt und die Session ist nicht abgelaufen. Und, und das ist jetzt relativ speziell, bei dieser Variante, wo im Hintergrund ein Post-Request in ein Iframe geladen wird und man gar nichts davon mitbekommt, das funktioniert derzeit nur bei Safari, sowohl jetzt auf iOS als auch auf MacOS, Firefox, Mobil, also auch Desktop, Samsung, Internet, der auch noch ungefähr 3-5% Marktanteil hat und ja, Opera Mobile und Internet Explorer ist auch nicht sicher. Wir haben gleich gesehen, warum nur diese Browser betroffen sind und natürlich als letzte Voraussetzung, wenn man auch noch einen anderen Account übernehmen will, muss natürlich die Telefonnummer für die Account-Wiederherstellung irgendwo eingetragen sein. Ansonsten würde aber auch hier behaupten, natürlich kann man nur die Rufumleitung benutzen, irgendeinen Telefonat abzufangen. Man kann aber dadurch, dass man auch Persistenz bekommt, also man hat den kompletten Account übernommen und kann die Rufumleitung auch wieder abstellen und das ermöglicht jemanden, Telefonate komplett mitzuschneiden, weil man kann sobald ein Telefonat bei uns angekommen ist, kann man die Rufumleitung abschalten und dann diese Telefonnummer anrufen und die Gespräche weiterleiten. Das ist sobald man das hat, dass man die Rufumleitung, wann man will, außen einschalten kann, kann man eben auch sämtliche Gespräche mit hören. Also man braucht jetzt nicht unbedingt das für einen Google Accounts und es reicht auch sonst schon, um einen Schaden anzurichten. Warum geht das nur bei speziellen Browsern? Das liegt daran, dass es etwas relativ Neues gibt. Diese Spezifikation wurde 2016 das erste Mal vorgestellt und in der Form, in der sie jetzt zumindest Chrome übernommen hat, erst Mitte 2019, wurde das präsentiert. Wenn man ein Cookie in den Headers von einer Anfrage setzt, mit diesem Set Cookie Befehl, kann man eben noch ein Same-Site-Attribut dranfügen. Das gibt es in drei verschiedenen Formeln, das ist gleich Non, Same-Site ist gleich Lux und Same-Site ist gleich Strict. Wie ihr hier seht, wird bei Strict gar kein Cookie Cross-Site weggeschickt, also mitgeschickt. Das bedeutet aber auch, wenn man einen Link schickt, das wäre zum Beispiel bei Facebook, wo man bei anderen sozialen Netzwerken, wo man einen Link schickt in einem Bereich, den nur spezielle Leute, die eingeloggt sind, sehen können, dann wäre dieses Same-Site-Strict-Attribut zu streng, weil sich alle dann neu einloggen müssen, um diesen Content dann auch wirklich zu sehen. Beim Same-Site ist gleich Lux-Attribut, werden nur Post-Requests geblockt, also dass die Cookies mitgeschickt werden bei Post-Requests, Cross-Site Post-Requests, genauso wie bei iFrames, wenn man es in einem Image-Tag einfügt. Same-Site ist gleich Non, kann man auch extra definieren. Früher war es auf jeden Fall so, dass Same-Site Non auch gültig war für alle, die überhaupt kein Same-Site-Attribut definiert haben. Und genau hier gibt es eben den Unterschied zwischen verschiedenen Browsern. Chrome hat im Sommer dieses Jahres, und dadurch wurde noch Edge und Opera Desktop, haben das auch übernommen, haben jetzt das Same-Site ist gleich Lux-Attribut als Standard-Wert genommen. Das heißt, wenn wir noch mal zurückgehen, es werden jetzt, wenn sobald Same-Site überhaupt nicht definiert ist, und das ist bei fast allen Seiten so, dadurch, dass das noch nicht sehr bekannt ist, dieses Same-Site-Attribut, wird als Standard-Wert angenommen, dass man Same-Site ist gleich Lux-Will, und dadurch werden Cookies nicht mehr mitgeschickt. Das ist eine große Verbesserung in der Sicherheit, die jetzt Browser-Seitig zumindest von Chrome und Co. durchgesetzt wurde, um Developer, aber auch natürlich die Userinnen und User vor diesen CSF-Angriffen zu schützen. Und das große Problem ist aber, das hat sich noch nicht verbreitet, das ist jetzt auch so, dass es nicht einheitlich unter den Browsern funktioniert, aber es wäre auf jeden Fall gut, wenn Safari, Fire, Fox und Co. das auch übernehmen würden, weil das schon auf jeden Fall einen sehr hohen Schutz bietet, damit viele dieser CSF-Attacken ins Leere laufen. Es ist aber nicht so, dass damit alles ausgemerzt ist oder alle CSF-Attacken unmöglich gemacht werden, nämlich dann, wenn zustandsverändernde Anfragen über Get-Requests geschickt werden. Das sollte man eigentlich nicht als Developer machen, aber es ist trotzdem oft leider so, dass zustandsverändernde Get-Anfragen existieren. Wie zum Beispiel bei dem zweiten Thema, das wir jetzt sehen, bei dem Mobilfunkbetreiber 3. Das ist jetzt kein virtueller Mobilfunkbetreiber, sondern in Österreich eine Tochterfirma von einem sehr großen Konzern in Hongkong mit, glaube ich, momentan 8 Ländern, in denen 3 seine Dienste anbietet. Und in Österreich sind hier allein 3,9 Millionen Accounts betroffen. Ich will Personen, das kann man nicht ganz genau sagen, aber es sind auf jeden Fall ein bisschen weniger, weil es einige Menschen gibt, die mehrere SIM-Karten haben. Schauen wir uns jetzt dieses zweite Demo an. Aus Sicht der Zielperson, hier müssen wir mit dem neuen Passwort, das wir vorher geändert haben, nochmal einloggen müssen, was hat funktioniert. Und schauen wir jetzt den Boring-Newsletter Nummer 2 an. Ja, vielleicht, bevor wir das machen, bevor wir hier draufklicken, zeige ich euch kurz, wie das bei 3 funktioniert. Und zwar sieht man hier jetzt schon, dadurch, dass ich mit dem 3, über das 3-Net im Internet bin, identifiziert mich 3 sofort. Also Sie wissen, ohne dass ich jetzt vorher eingeloggt war, schreiben Sie Hallo, wir haben die Rufnummer 660 und so weiter erkannt. Wollen Sie mit dieser Nummer auf diesem Gerät und Browser immer automatisch erkannt und in der Kundenzone eingeloggt werden. Und wenn wir uns das jetzt kurz anschauen, was hier passiert, sagen wir mal ja, immer automatisch einloggen. Das heißt, wir müssen hier kein Passwort eingeben oder uns über den Link über die E-Mail-Adresse einloggen, sondern 3 erkennt, dass man über das 3-Netz sich einloggen will und ermöglicht so passwortloses Einloggen. Und das Einzige, was bei diesem Auto-Login passiert, ist, dass ein Post-Request an diesen Endpoints 3AT-Selfcare-Autologin.du gesendet wird und der Request-Payload ist einfach Submit Yes, also Submit Yes ist gleich und dann leer. Das heißt, es muss eben kein Passwort nichts mitgeschickt werden, sondern man muss einfach nur sagen Yes Autologin. Was die ganze Geschichte natürlich um einiges einfacher macht, wenn wir uns hier kurz anschauen bei den Einstellungen, sollte hier jetzt keine Rufumleitung eingestellt sein, wenn das jetzt noch nicht vom letzten Test. Hier seht ihr, alle Anrufe umleiten ist auf Ausgestellt und wenn ich das jetzt wieder schließe und gezielt bei so einem Klick hier auf diesen 2. langweiligen Newsletter, dann sieht das schon ein bisschen anders aus einmal, weil hier 2 Befehle ausgeführt werden. Heißt, wie ihr gesehen habt, nochmal extra wollen Sie wirklich unsubscribing, unsubscribing klickt und hier wurden jetzt 2 Dinge ausgeführt. Mit diesem Klick auf unsubscribe wurde dieser Autologin-Befil abgesendet und im Hintergrund wurde dann einfach ein Gatschrequest ausgeführt, der die Rufumleitung gesetzt hat. Wir können uns doch jetzt hier noch einmal im Source Call ansehen. Da waren wir jetzt noch einmal die Rufumleitung gesetzt. Okay, das Problem ist, das geht jetzt leider oder nicht dadurch, dass die Weiterleitung passiert ist, aber ihr seht grundsätzlich, was passiert ist und wenn wir jetzt hier uns das noch einmal ansehen, dann steht es hier bei alle Anrufe umleiten wieder unsere 0680 330797 Telefonnummer. Das heißt, es geht extrem einfach, so eine Rufumleitung zu setzen. Die Voraussetzungen als Zusammenfassung sind wieder auf jeden Fall eine Zielperson besucht, eine Kompromille der Seite und dann ist entweder ein gültiges Session Cookie vorhanden, weil sich die Zielperson davor schon bei dieser 3 Kontenzone angemeldet hat oder ein Autologin wird mit diesem 2. Klick, also wo auf dieser unsubscribe-Seite set, klicken Sie bitte hier noch auf unsubscribe um Ihre Abmeldung zu bestätigen oder mit diesem 2. Klick wird der Autologin eingeführt. Das heißt, in dem 2. Fall muss sich eine Person niemals davor bei der Kundenzone angemeldet haben. Es muss kein Session Cookie vorhanden sein und man kann trotzdem eine Telefonnummer, eine Rufumleitung setzen auf eine Telefonnummer und dann wie, das habe ich jetzt nicht gezeigt, wie vorher zum Beispiel einen Gmail-Account übernehmen. Was hier bei 3 nicht funktioniert, ist, dass man nicht Persistenz hat. Das heißt, man hat nicht die Möglichkeit, sich immer wieder einzulocken und alles Mögliche zu verändern, sondern das würde immer nur gehen, wenn eine Person auf die Seite, also auf den Link klickt und eine kompromidierte Seite besucht. Das heißt, dieses Abhören von Telefonaten funktioniert hier nicht. Was man hier machen kann, weil es der einzige Betroffene ist, der betroffen ist, ist, dass man die Rufumleitung setzt. Die Zuverlässigkeit ist allerdings um einiges höher. Man muss sich nur vorstellen, wenn man das direkt am Smartphone öffnet, dann ist relativ klar, dass man über das Heim-Netzwerk, über das Dreienetzwerk, ins Internet geht und dann betrifft das alle Menschen, bei denen dieser Autologin nicht extra deaktiviert ist und der ist praktischerweise standardmäßig für alle aktiviert. Das heißt, die Zuverlässigkeit bei diesem zweiten Angriff ist auf jeden Fall, ich habe es nicht statistisch ausprobiert, aber sie wird auf jeden Fall sehr, sehr hoch sein. Was wir allerdings sehen, dass bei drei nicht möglich war, das Ganze im Hintergrund zu laden, das heißt, was wir gesehen haben, ist, dass sobald die Person klickt hat, sie auf eine Dreiseite weitergeleitet wurde. Das kann natürlich auffällig sein. Wenn man allerdings einen Newsletter schickt, der so aussieht als wäre von drei, würde sich vielleicht jetzt niemand große Sorgen oder großer Gedanken machen, wenn man beim Umstellen der Newsletteroption auf eine Dreiseite weitergeleitet wird. Warum das so ist, ist, weil in den Headers die X-Frame-Options definiert worden, die kann man entweder auf Deni oder auf Same Origin definieren und damit wird es generell, also blockiert, es blockiert nicht nur Cookies, sondern es wird generell verhindert, dass eine Seite in andere Seiten eingebettet wird. Diese X-Frame-Options kann man natürlich für alle Seiten, die das brauchen, dass man sie in andere Seiten einbetten kann, klassischerweise Video-Seiten, wie YouTube, aber auch media.cc.de, da sehen sie natürlich überhaupt nicht zu gebrauchen, sondern das sollte man auf das Same-Site-Attribut gehen, wenn man ein Cookies setzt. Ich nehme an, dass die Seite schon so alt ist oder die Republikation von drei, dass es damals einfach nur diese X-Frame-Options gegeben hat und noch nicht das Same-Site-Attribut. Also diese X-Frame-Options sind auch nicht dafür gedacht, dass sie gegen Cross-Site-Regressed-Forge reschützen, sondern ursprünglich checken gedacht. Wir haben noch einen dritten Anbieter, wie der Mobile-Virtual-Network-Enabler im A1-Konzern. Also einen dritten Anbieter in Österreich, der betroffen ist. Weil ich Kunde von Jes bin, habe ich das als Erstes entdeckt, dass es mehrere CSI-Sprachstellen gibt. Das Problem ist auch, es sind insgesamt zehn virtuelle Mobilfunkbetreiber betroffen. Also es betrifft zum Beispiel die Marken von zwei großen Tageszeitungen, Kurier und Krone von einem Energieanbieter, von einem sehr großen und mehrere andere Marken auch noch. Das heißt, insgesamt sind hier zehn Mobilfunkmarken betroffen und die Besonderheit ist hier gewesen, dass man über CSI Web-SMS schicken kann, was einerseits für Spamming ein Problem sein kann, aber andererseits ist es auch eine Besonderheit, weil man so einen Feedback-Kanal hat. Also das, was wir vorher gesehen haben, dieses Success-Nachricht kann man sich so selbst über Web-SMS als Angreiferin schicken und das Dramatisch da war aber jetzt, dass man das Kunden-Kennwort ändern konnte. Und mit dem Kunden-Kennwort, das ist jetzt nicht das Passwort für die Web-Applications, sondern das Kunden-Kennwort, mit dem man die gesamte Rufnummer auf einen anderen Anrufer partieren kann und wenn man die Rufnummer auf einen anderen Anrufer partiert, dann kann man auch SMS klarerweise lesen wie zum Beispiel Twitter-Count und so weiter, kann man damit zurücksetzen. Bei jetzt habe ich eine Responsible Disclosure gemacht und das wurde mittlerweile schon geschlossen, deshalb mache ich ich euch heute kein Live-Demo mehr zeigen, aber jetzt war ich auch betroffen und als Übersicht allein in Österreich und ich habe eben nur Österreich getestet, ein slowinischer Anbieter ist da mit reingerutscht, aber allein in Österreich sind mehr als 5,4 Millionen Betroffene, also da geht es wieder um betroffene SIM-Karten oder betroffene Accounts, mindestens 15 Unternehmen bzw. Marken sind eben allein im österreichischen Mobilfunkmarkt davon betroffen. Ich habe nicht alle ausgetestet, aber auf jeden Fall die meisten. Es gibt auch einige, die safe sind und muss natürlich auch dazu sagen wie zum Beispiel die Mobile Österreich Magenta, wie sie jetzt heißen. Allerdings betrifft es dann auch nur die Hauptmarke und nicht die virtuellen Betreiber, die in diesem Netz angemeldet sind, weil die, wie zum Beispiel, Hot ist auch in dem Netz, die haben eigene Verproduktionen. Und meine große Frage an euch auch ist, wie sieht das denn in anderen Ländern aus? Österreich ist jetzt nicht das größte Entwicklungsland bei Technologie, ein kleines Land, aber wenn hier, geschätzt, werden an die 40% der Österreicher davon betroffen sein, dann wird das wahrscheinlich in anderen europäischen Ländern nicht viel anders sein. Ich nehme an, dass bei größeren Ländern, weil die höhere Pages haben für Plattformen, dass es besser aussieht, aber im Durchschnitt kann man wahrscheinlich schätzungsweise davon ausgehen, dass es einige Dutzende Millionen, also Dutzende Millionen Europäerinnen und Europäer betrifft und schaut euch das vielleicht selbst an, wenn ihr in einem anderen Land seid oder eine Sim-Karte von einem anderen Land als Österreich habt und schickt mir vielleicht eine Information, vor allem schickt dem Hilfungbetreiber eine Information, dass sie diese Schwachstellen schließen sollen. Als Lösung wie kann man das in Zukunft verhindern? Die erste, die ich ansprechen würde sind die Politik oder ist die Politik, beziehungsweise die Verwaltung. Wir haben nämlich eigentlich eine sogenannte Nies-Richtlinie, wo so ein Netzwerk und Informationssicherheit geht auf EU-Ebene und die Richtlinie schreibt dann vor, dass einzelne Mitgliedstaaten Gesetze erlassen sollen. Unter anderem wird da vorgeschrieben, dass kritische Infrastruktur und Telekommunikationsunternehmen sinnkritische Infrastruktur müssen sich Sicherheitsstandard haben, die dem Stand der Technik entsprechen. Und gravierende CSI-F-Schwachstellen in Web-Applikationen, die man sehr schnell finden kann, entsprechen definitiv nicht dem Stand der Technik. Und hier ist die Frage, es ist ja gesetzlich geregelt, es ist verboten, solche Schwachstellen zu haben. Warum kann es sein, dass sie trotzdem anscheinend jahrelang in vielen, vielen Anbietern in Österreich existieren? Warum kann es sein, dass es keine Strafen gibt, dass die Sanktionen zu niedrig sind und dass es auch keinerlei Haftung gibt? Ich bin mir ziemlich sicher, dass z.B. die Tageszeitungen Krone und Kurier in Österreich, ihre Mobilfunkangebote an ihre Leserinnen und Leser bewerben, dass sie sich nicht im Klaren darüber waren, auch wenn diese Lücke draußen wurde, dass sie Produkte bewerben, die massive Sicherheitslücken haben. Sie werden es wahrscheinlich nie mitkriegen, außer wenn sie diesen Talk hören oder davon erfahren, dass sie Produkte vertreben haben, die solche Sicherheitslücken haben. Das heißt, es muss eine, es müssen strengere Sanktionen und in irgendeiner Weise Haftungen existieren, damit so etwas nicht passiert und es sollten aber auch die Rahmenbedingungen für eine Responsible Disclosure verbessert werden, ich kann mir nicht vorstellen, bei 4,5 Millionen Betroffenen an Accounts, dass ich der erste bin, der darauf gekommen ist, dass diese Sicherheitslücke existiert. Es ist, wie gesagt, wahnsinnig schwer zu entdecken und jahrelang müssen sie existiert haben. Nur wer schon mal eine Responsible Disclosure gemacht hat, weiß, dass man dann nicht mit Dank überschüttet wird, wenn man eine Sicherheitslücke meldet, sondern dass die Firmen meistens überhaupt keine Policy dafür haben, also sie wissen gar nicht, wie sie damit umgehen sollen und auch wenn sie die haben, dann ist die Responsible Disclosure Policy und sie können uns gerne, wenn sie das und das und das einhalten, können sie uns gerne die Sicherheitslücken melden, die sie erfahren haben und als Dank dafür klagen wir sie nicht. Und das ist natürlich kein hoher Anreiz, dass man tatsächlich dann etwas meldet und wenn man darauf kommt und nicht nebenan, das haben vor mir auch schon Leute, sind da draufgekommen, dann wird man einfach im besten Fall gar nichts machen. Würde es hier ein Backbound-Tippogramm geben, wo Personen die Sicherheitslücken melden vielleicht noch ein bisschen belohnt werden mit irgendeinem Preis, dann wären, wie man das ja bestehenden Backbound-Tippogrammen von großen Firmen, internationalen Firmen sieht, dann wären solche Sicherheitslücken innerhalb von ein paar Wochen nicht mehr fahren. Das heißt auch da sollten die Rahmenbedingungen verbessert werden, und sie ist das rechtlich auf jeden Fall eine Hölle in so vielen verschiedenen Richtungen. Da verstehe ich auch die Konzerne, warum sie es nicht machen. Also ein Arbeitsrechtlich wie soll man jemandem bezahlen, der eigentlich gar keinen Vertrag mit dem Unternehmen hat. Die Lösungen auf der Seite der Developerinnen wäre die Standardlösung der Stand der Technik seit Jahren ist Anti-CSRF-Tokens zu implementieren. Da auf jeden Fall auch klarerweise wie immer keine Lösungen selbst stricken, sondern auf schon abrupte und bekannte Bibliotheken zurückgreifen gibt es praktisch für jede Programmiersprache. Was eben neu ist, und meiner Meinung nach ist das eben so gut wie Anti-CSRF-Tokens ist das same-Side-Strict oder vielleicht sogar same-Side-Lacks Attributes selbst zu setzen. Es geht viel einfacher, weil man das eigentlich nur im Server definieren muss mit einer Zeile in einem HDXS-File oder direkt in den Web-Server-Einstellungen. Das geht irrsinnig einfach und ist vielleicht sogar die bessere Lösung, aber da würde ich vielleicht auch gerne euer Feedback hören, ob ihr auch so denkt. Die allerbeste Lösung und auf jeden Fall die bei wichtigen zustandsverändernden Anfragen auch Standard sein sollte ist die Passwortabfrage, wenn es wichtige Änderungen gibt. Also wenn ich mein Passwort ändere, dann muss ich mein altes Passwort eingeben. Wenn ich jetzt meine E-Mail-Adresse ändern kann, mit der ich mein Passwort zurücksetzen kann, dann sollte man natürlich auch hier eine Passwortabfrage machen. Und obwohl das beim ersten Standard ist, also beim Passwort erinnern, dass man das Passwort eingeben muss, ist es bei der E-Mail-Adresse nicht Standard und das ist eigentlich völlig, entspricht nicht der Logik und klarerweise beim Mobilfunkbetreibern sollte man so etwas auch bei der Rufumleitung machen. Die Lösung von der Browser-Seite haben wir schon diskutiert. Es wäre auf jeden Fall höchste Zeit, dass alle Browser dieses same-seites-gleich-lacks als Standard-Wert nehmen. Chrome hat das jetzt schon seit ungefähr 6 Monaten implementiert. Das Internet ist nicht auseinandergebrochen. Chrome hat einen Marktenteil von ungefähr 50, manchen Ländern 60%. Das heißt, mittlerweile sollten auch alle Seiten bereit sein dafür, dass auch alle anderen Browser das als Standard-Wert nehmen. Ich glaube, Firefox hat das schon vor. Man kann es zumindest schon aktiv in den Einstellungen ändern. Besser Fahre, die doch auch einen hohen Marktenteil haben, wäre das auf jeden Fall höchste Zeit, das in Angriff zu nehmen. Es gibt aber auch eine Lösung für Betroffene. Die gute Nachricht ist, ihr müsst euch nicht darauf verlassen, dass andere diese Sicherheitslücken schließen. Ihr könnt euch auch selber davor schützen. Und zwar, das erste ist auf jeden Fall nehmt keine Telefonnummern zur Herstellung von euren E-Mail-Accounts. Also es ist, wie gesagt, der wieges Link das schwächste Client in der Sicherheitskette Sinn, die Mobilfunk nehmt für eure E-Mail-Adressen eine zweite E-Mail-Adresse, mit der ihr Account Recovery machen könnt. Weil grundsätzlich sind Web Security und generell Inter praktisch, wenn man sich kein Passwort merken muss. Aber es ist eine massive Sicherheitslücke nicht nur, was CSF Schwachstellen betrifft. Auch die Telefonnummer als Account Recovery da geht es nicht nur um CSF Schwachstellen, wie wir schon auch beim CSF in anderen Jahren gehört haben, gibt es andere Schwachstellen, die ausgenutzt werden können. Das ist generell eine schlechte Idee. Was jetzt CSF betrifft, kann man das ganz einfach umgehen, indem man sich bei wichtigen Accounts nicht mit seinem Standard Browser einlockt. Das ist der Standard Browser, der sich automatisch eröffnet, wenn ihr irgendeinen Link klickt. Nehmt für wichtige Accounts einen anderen Browser oder zumindest, das war früher üblich, dass man auch aufgefordert würde. Jetzt wollen die meisten Services, dass man immer eingelockt bleibt, weil das auch Datensammel technisch für die Anbieter gut ist. Aber lockt euch immer aktiv aus, wenn ihr ein Service nicht mehr braucht. Ja, das war's von meiner Seite. Vielen Dank und ich freue mich auf eure Fragen. Ja, vielen Dank für den interprofessanten Vortrag. Manche der Fragen, die gestellt worden sind, hast du tatsächlich in den letzten fünf Minuten teilweise schon beantwortet. Eine Frage ist, sind die Lücken schon an die jeweiligen Anbieter gemeldet worden? Und wie haben die darauf reagiert? Also du hast gesagt, die Lücke bei Jes nicht vorführen, weil die schon zu ist. Aber wie viele von den 14 anderen haben da vernünftig reagiert? Bisher habe ich nur die Lücke bei Jes gemeldet, weil der Mutterkonzerner eins eine Responsible Disclosure Policy hat. Dadurch auch einen Kontakt. Die anderen beiden Betroffenen haben überhaupt keinen Security-Kontakt und dadurch ist es denen nicht bekannt. Bei Jes haben sie das, also ich habe sie am 12. Oktober gemeldet und am 13. November wurde es geschlossen. Da ist es relativ professionell auch abgelaufen. Also innerhalb von 24 Stunden wurde das auch bestätigt, die Lücke. Es hat dann ein Monat deswegen gedauert, weil das ein externer Dienstleister für software, weil ob man zuständig ist und dadurch hat die Probleme mit Jürgen ein bisschen leger gedauert. Ja, dann eine andere Frage ist, wie bei diese Schwachstellen, jetzt allein Schwachstellen von den Anwendungen sind oder wie weil Schulter auch die Browser trifft. Du hast ja die Samside Policy erwähnt und so was und im Sommer hat Firefox auch auf SamsideLux als Default umgestellt, zum Beispiel wurde angemerkt ist das ein Auserproblem, ein reines Anwendungsproblem? Also grundsätzlich ist es schon in der Verantwortung der Anwendungen dass diese Lücken existieren. Allerdings tatsächlich ist es so, dass die Browser eigentlich jetzt mittlerweile alle die gleiche Policy übernehmen wie Chrome. Man hat jetzt in den letzten Monaten gemerkt, dass keine Nachteile gebracht hat für bestehende Anwendungen. Da kann man auch sagen, dass es mittlerweile ein Browser-Problem ist, zumindest bei den gravierensten Lücken wo im Hintergrund die Befehle ausgeführt werden. Und eine Frage, ob statt einem anderen Browser auch ein anderer Multi-Account Container Plug-in denkbar wäre, ist eine Lösung? Das wäre natürlich auch eine Lösung, ist vielleicht nicht für alle Userinnen und User die einfachste Lösung aber das wäre natürlich durchaus eine Lösung. Ja, und wie schwierig es dann gewesen so eine Schwachstelle zu finden? Also gefunden können solche Schwachstellen innerhalb von weniger als einer Stunde auf jeden Fall werden. Das ist die meiste Zeit, die anfälligen Endpoints finden und dann sieht man sehr schnell, dass sie auch wirklich CSF-Lücken bestehen. Das heißt eben, es ist jetzt keine Raketenwissenschaft solche Lücken zu finden und umso mehr liegt es in der Verantwortung der Betreiber solche zu schließen.