 Wir haben mindestens einen Vortrag, der euch Nightmares über euer Mobiltelefon gibt. Bitte ein herzliches Willkommen an Donkwan und Kim Hong Il. Guten Abend. Ich bin Hong Il Kim aus Korea. Südkorea, nicht Nord. Das ist meine erste Kongress hier und es ist mir eine große Ehre, unsere Arbeit zu präsentieren. Heute, mein Kollege Donkwan, werden über Dissecting-Voltee sprechen, Voice over LTE ausnahderehmen. Es ist eine neue Technologie. Wir werden euch zeigen, wie man verschiedene Vulnerabilitäten exploiten kann. Wir sind beide Postgraduate-Studien in KAIST. Es geht um Mobile Device Security. Wir arbeiten an Sicherheitsanrichtungen für LTE-Komponenten. Ich bin Hong Il. Es gibt verschiedene Felder von Sicherheitsproblemen. Hong Il wird das grundlegende Konzept beschreiben und ich werde Details beschreiben. Los geht's. Stimme über LTE ist eine neue Technologie im Mobilfunknetzwerk. Das Deliver Data for Voice and Data is separated into all IP-Based Data to provide better data delivery. So as both the Voice and Data in LTE are delivered as a data flow. Die Sprache wird in LTE über Datenpakete übertragen. Sorry, ich verstehe ihn kaum. LTE is adopted for your IP system, which is widely used in our network. So by adopting both LTE users, they can get high Voice quality and faster quality of time. Voice over LTE kann man eine hohe Sprachqualität erreichen. Die Betreiber können die Kosten reduzieren und viele Multimedia Services anbieten, die in 3G noch nicht angeboten werden konnten. Lasst uns mehr Details ansehen, wie das bei 3G und 4G aussieht, wie sich die Sprachanquote verbessert hat. Im Fall von 3G wird Daten und Sprache unterschiedlich übertragen. Daten werden Paket übertragen und Sprache wird Netz übertragen. Daten werden über das Package Switching Core übertragen und Sprache über das Circle Switching Core. Wenn man jetzt telefoniert, läuft das über das Circle Switching Core. In 4G werden Daten und Sprache über das Package Switching Core übertragen. Also braucht man das Circle Switching Core gar nicht mehr für 4G. Die 4G funktioniert wird dann im IMS implementiert. Lasst uns mehr Details ansehen, wie die Services in LTE angeboten werden. Alle Services wie Daten, Sprache und Video werden als Datenkanäle, die auch Barras genutzt werden. Der Barras ist ein virtueller Kanal, der das verbindet. Wie man hier sehen kann, ist der 3GPP-Standard definiert mehr Barras. Je nach Zweck des Services wählt man einen dieser Barratypes aus. Jeder Barratype hat unterschiedliche Charakteristikäden, wie zum Beispiel eine garantierte Bitrate, eine Paketverzögerung oder die Paketverlustrate. Wie man hier sehen kann, gibt es 2 Barras für Vault, einer mit einer hohen Priorität und einer mit einer niedrigeren Priorität für die Barras Performance. Für Voice Over LTE. Wenn das Gerät auf der Räder ist, kann man die Räder auf der Räder sehen. Für Voice Over LTE. Wenn das Gerät eingeschaltet ist für einen bestimmten Dienst, der default Barras zwischen Device und dem, erhält eine neue IP-Adresse. Der Standard Barras hat jetzt keine garantierte Bitrate. Wenn der Dienst eine spezifische Qualitätsstufe erfragt, dann gibt es einen default Barras. Der Traffic wird durch Protokollnummer gefiltert. Also 2 Barras, 2 Träger werden gebraucht. Einer ist für Kontrolle, für Kontrollebene und einen für die Data-Ebene. Wenn also der Voice Over LTE Service verwendet wird, wird der default Barras erst mal hergestellt, die Verbindung mit dem default Barras. Dieser default Barras oder dieses Gerät authentifiziert sich zunächst beim IMS über bestimmte Nachrichten. Wenn ein User einen Anruf macht oder einen empfängt, dann wird ein spezifischer Barras hergestellt, innerhalb des default Barras. Die Sprachdaten zwischen den beiden Anrufen werden üblicherweise übertragen in RTP-Pakete eingepackt. Weil jetzt Voice Over LTE völlig neu ist als Feature, verglichen mit normalen Switch-Anrufen. Wenn jetzt eine Implementierung nicht... Und ratet mal... ... ... ... ... ... Wir fanden mehrere Sicherheitsschifflücken in jeder dieser Komponenten. Danke. Diese Sicherheitsprobleme... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... Selbst eine Schädigte kann nicht auf die Kommunikationsprozessor zugreifen. Jede App in der AP muss sich eine Call-Fone-Permission holen, um auf den Kommunikationsprozessor zugreifen zu können. Deswegen können 3G-Telefone die Sprache nicht analysieren, die schädlichen Apps. Hingegen in LTE-Geräten wird die Sprache im Anwendungsprozessor arbeitet. Deswegen könnte eine Nutzerapplikation die Sprache analysieren. Z.B. in einem Android-System gibt es zwei Netzwerksnitzstellen. Nur wenn man guckt, welche Anwendung gerade läuft, können wir herausfinden, welches Interface für das Vault verwendet wird. Hier haben wir einen Port, der genau für das Sprachsignal verwendet wird. Wir können schliessen, dass ein App sogar einen Call ausführen, sogar ohne die Erlaubnis, soweit man die Netzwerksockets für Voice over LTE bekommen kann. Wir haben eine komplizierte Abrechnungsinfrastruktur und das zweite Problem ist das Delegieren von dem Sprachsignalisieren über IP. Wir analysierten jetzt zuerst den 3G-PP-Standards in Bezug auf den Voice over LTE-Service, aber Detailimplementierungen werden jetzt den Chipsetherstellern überlassen. Um jetzt also eine Checklist von möglichen verwundbaren Punkten zu machen, wir haben das gemacht und es gab etwa 60 verschiedene Einträge für die Kontrolle und die Datenebene. Wir haben in fünf größeren betriebbefindlichen Netzwerken eine Analyse durchgeführt, zwei US- und drei in Südkorea, und wir haben auch Betreiber in Europa in Betracht gezogen, aber es gibt keine Betreiber in Europa, die Voice over LTE anbieten. Wir haben jetzt gehört, dass jetzt ein Launch in Deutschland von zwei Betreibern bevorsteht. Wenn ihr euch also fragt, wie sicher diese deutschen Betreiber sind mit ihrem Voice over LTE-Service, dann sprecht uns bitte an, schauen wir dann zusammen dort hinein mit euren Smartphones. Also um zusammenzufassen, die Ergebnisse. Wir haben vier freie Datenkanäle gefunden, die durch die komplizierten Accounting-Funktionen herrühren und fünf Sicherheitsprobleme und meinen Kollege Dong Guan wird das jetzt erklären. Hi, ich bin Dong Guan. Fangen wir mal von hier an. Beginnen wir mit dem freien Datenkanal mit dem Voice over LTE-Protokoll. Um solche freien Datenkanäle zu nutzen, müssen wir zunächst verstehen, wie Voice over LTE tatsächlich funktioniert. Wenn ein Anrufer, ein angerufender Person macht, dann gibt es eine Einladungsnachricht. Diese Einladungsnachricht enthält die Telefonnummer von beiden Seiten und sieht so aus. Um meine Privatsphäre zu erhalten, habe ich hier meine eigenen Informationen entfernt. Aber wie ihr merkt, ist dieses Paket fast so wie HTTP. Wir haben hier statt GET und POST für HTTP-Methoden, haben wir jetzt in weit. Und es gibt viele Methoden in SAP und auch Telefonnummern von angerufendem und angerufendem. Wenn diese Nachricht empfangen wird auf der anderen Seite, fängt das Telefon an zu klingeln. Und wenn der Benutzer dann diesen Anruf beantwortet, annimmt, gibt es eine OK-Nachricht zurück an den Anrufer. Und es wird ein Barer hergestellt zwischen beiden Seiten der spezielle Barer. Und darin werden dann RTP-Pakete ausgetauscht. Wie können wir das mit freien Datenkanälen nutzen? Sehr einfach. Wir können hier einfach Daten in die Header oder Body von der Invite-Message hineintun. Und wir haben jetzt die OK-Nachricht mit die Kleine ersetzt, wie ihr merkt, um immer mehr Invite-Messages zu erhalten. Außerdem kann man Daten in den RTP-Payload hineintun, wie normale Sprachdaten. Wir haben tatsächlich beide Methoden implementiert. Man könnte denken, dass das einfach zu einfach ist, aber die Implementierung war es tatsächlich nicht. Lass mich irgendwie nicht die Details erklären. Auf der rechten Seite haben wir den Anrufer und auf der anderen Seite die angerufenen. Und wir haben also zwei Absender und Empfänger für alle Methoden. Wenn der Anrufer Nachrichten sendet, gibt es RTP-Pakete, die zu IMS transferiert werden. Und IMS-Daten werden dann auf der angerufenen Seite SIP-Pakete empfangen, aber nicht RTP-Pakete. Dies ist das Problem, das schwierige Teil. Denn die RTP-Pakete werden zuerst in CP verarbeitet und nur die SIP-Daten werden an den AP übertragen. Und deswegen können die RTP-Pakete ja nicht mit AP gelesen werden. Wir müssen einen anderen Weg finden. Während wir durch uns suchten, fanden wir ein Diag-Kommando. Diag ist ein nicht offenes Protokoll. Das Diag-Kommand stellt verschiedene Funktionsverfügungen wie Speicherlesen schreiben, SMS-Lesen schreiben. Und ein Dump. Man kann Signale dampen zwischen dem Telefon und dem Funkmast, was üblicherweise durch Betreiber für Performance-Tests, sogenannte Feldtests, benutzt wird. Und ihr seht hier das rechte Diagramm. Das ist ein Beispiel für ein diagnostisches Werkzeug. Die Software ist hier auf dem Laptop. Und um diese Software zu nutzen, braucht man einen Schlüssel, der in USB gespeichert ist. Könnt ihr euch den Preis dieser Software vorstellen? Die ist wirklich teuer. Über 16.000 Dollar. Also, weil wir Studenten sind, haben wir nicht das Geld, um dies zu kaufen. Wir müssen also das Reverse-Engineering, das Protokoll selbst, und wir haben verschiedene Operations-Codes gefunden, wie hier in der linken Tabelle gezeigt, über 100 Kommandos, aber nur einige davon sind hier aufgelistet. Es gibt ein Log-Kommando hier. Und wenn man das Log-Kommando nutzt, konnten wir direkt RTP-Pakete im AP über den Diag-Device-Triper im Linux-Körnel erfassen. Einfach den Device-Triper öffnen, dieses Kommando schicken, und dann kann man RTP-Pakete direkt lesen. Also, können wir die RTP-Pakete und die RTP-Pakete ohne Verlust bekommen und deswegen beide Tunnelmethoden benutzen dadurch. In dem Fall von direkter Kommunikation ist es sehr einfach. Man muss einfach nur einen Socket öffnen mit der IP-Adresse für das Voice-over-LTE-Interface und dann Daten über das Internet so verschicken. Auch andere Teilnehmer im Mobilfunknetz das schicken. Wir können das Voice-Interface benutzen und das Daten-Interface benutzen, so wie es hier gezeigt ist. Wir können das an einen anderen Menschen schicken, der auch Wort das verwendet. Wir haben das nicht getestet, aber vielleicht könnt ihr das mal ausprobieren. Wir haben freie Datenkanäle getestet in fünf Betreibernetzen, zwei in den USA und fünf drei in Südkorea. Die Implementation war unterschiedlich. SIP-Tunneling und Media-Tunneling waren bei allen Betreibern vorhanden. Die direkte Kommunikation war unterschiedlich je nach der Policy des Betreibern. Nicht, dass KR-1 der beste Betreiber ist für freie Datenkanäle. Aber ich denke, einige von euch wundern sich jetzt vielleicht, dass ihr später vielleicht mal nach Korea fahrt, solltet ihr KR-1 benutzen. Aber nachdem wir die Sicherheitslücken gemeldet haben, haben sie das gepatched und jetzt ist das so. Von den zwei US-Betreibern, weil wir koreanische Studenten sind, konnten wir den nicht in den USA testen, weil das uns zu viel Geld gekostet hätte. Wenn wir vielleicht Glück haben, können wir das später vielleicht noch mal testen. Wir haben den Datendurchsatz in der direkten Kommunikation gemessen und der war relativ hoch. Wie Honkel das vorher beschrieben hat, hat unsere Vault-Internicht-Schnittschnelle, ist diese Schnittstelle nützlicher für uns. Wir haben auch den Durchsatz für das Media-Tunneling gemessen, aber der war relativ niedrig, weil er von den Betreibern limitiert wird. Für das Media-Tunneling Beschneiden Sie die Bandbreite, weil Sie denken, es reicht, hohe Qualität beim Sprache zu geben. Aber später wird die Leistung dort vielleicht auch noch erhöht. Ich werde das später noch mal erklären, in den späteren Folien. Bei einem koreanischen Betreiber haben wir 1.000 Invite-Nachrichten geschickt, in einer Sekunde, zwei oder drei Stunden später, haben wir von diesem Netzbetreiber einen Anruf bekommen. Wir haben das später noch mal erklärt. Ich habe jetzt über die vierfreien Data-Kanale gesprochen, jetzt geht es um die Fünf-Sicherheits-Isschüs. Zunächst einmal, alle deine Sprachpakete sind unverschlüsselt. Nur auf der anderen Seite haben wir die fünf-Sicherheits-Isschüs, die wir in der letzten Sekunde haben. Wir haben die fünf-Sicherheits-Isschüs, die wir in der nächsten Sekunde haben. Alle deine Sprachpakete sind unverschlüsselt. Nur ein US-Betreiber verschlüsselte die Daten, die die Sprachsignalpakete. Und selbst hier waren die eigentliche Sprachdaten nicht verschlüsselt, sodass die Unterhaltung tatsächlich abgehört werden konnte. Hier wurde IPsec verwendet, um das die Voice-Signalpakete zu verschicken. Ich habe die IP-Adressen für diesen Operator entfernt und die anderen Operatoren haben einfach TCP-UDP ohne jede Verschlüsselung benutzt. Also eure Sprachdaten sind offen. Einige von euch fragen sich vielleicht, ob das Abhören wirklich möglich ist. Ein Beispiel ist hier. Ihr könnt hier über Femtosellen anstellen. Es gibt viele Femtosellen, fast alle Betreiber bieten Femtosellen an oder benutzen Femtosellen. Wenn Femtosellen nun komprimitiert werden, dann sind alle Verbindungen zu dieser Femtoselle durch diese Verwundbarkeit betroffen. Und einige Betreiber bieten auch Wi-Fi-Anrufe an. Wenn wir nun Wi-Fi-Calling nutzen, gehen alle Sprachpakete über ein WLAN Access Point und das Internet zum Kernnetzwerk. WLAN Access Points zu komprimitieren ist sehr viel einfacher als Femtosellen. Also in diesem Szenario ist auch alle Sprachkommunikation abhörbar. Um jetzt also zum ersten Folie zurückzukehren, in dieser Situation selbst der eine Operator fokussiert nur sich auf die Signaldaten für die Verschlüsselung. Und wir denken, dass die Betreiber auch die Sprachdaten verschlüsseln sollten. Das nächste Problem ist, obwohl die SIP-Server-Dini-Nachricht, es gab keine Authentifizierung, kein Session-Management. Man kann also einen Anruf mit einer gefälschten Telefonnummer machen oder man kann verschiedene Inweitnachrichten gleichzeitig an mehrere User schicken. Dann werden mehrere Call- und Anruf-Sessions aufgebaut. In einem normalen Anruf kann natürlich nur eine Person, eine andere Person anrufen. Aber durch diese Verwundbarkeit kann man irgendjemanden gleichzeitig, viele Leute beliebig viele gleichzeitig anrufen. Ein Anrufer kann also die Ressourcen ausnutzen und verglichen mit den Problemen im Call-Netzwerk. Wir brauchen jetzt nur noch weniger Geräte, um das Call-Netzwerk zu killen. Deswegen bekam ich diese Anrufe von den Betreibern. Wir haben eine Demo hier vorbereitet. Das ist ein normaler Call. Ein Anrufer ruft den angerufenen Angreifer. Nun ruft auch den angerufenen Anrufer mit der gleichen Telefonnummer gefälscht. Schauen wir uns das mal an. Auf der rechten Seite sehen wir den normalen Anrufer und den angerufenen. Wir haben hier unsere Fotos eingesetzt. Das ist ein normaler Anruf. Wir kommunizieren und beenden den Anruf. Nun ist der Angreifer mit ADB verbunden, nur zur Bequemlichkeit. Er ruft jetzt den Anrufer an mit der Anrufer mit der Nummer des angerufenen Anrufens. Ah, Gangnam Style. Das haben wir zu lange nicht mehr gehört. Der Anruf geht jetzt vom Angreifer zum angerufenen. Der Anruf verweist nicht einmal, dass ein Telefonnummer missbraucht wurde. Wir haben hier den berühmten Koreanischen Song Gangnam Style verwendet. Aber wir könnten natürlich irgendeine irgendwelche Daten schicken. Irgend beliebige Audiodaten. Das kann also für Voice Fishing genutzt werden. Zum Beispiel kann man Geld verdienen durch die Freunde, indem man diese Verwendbarkeit ausnutzt. Das nächste Problem, es gibt keine Regeln in den Gateways. In einer normalen Situation werden alle Sprachpakete, sollten alle Sprachpakete durch IMS durchgehen. Aber wir haben herausgefunden, dass die Pakete auch direkt zum anderen Telefon gespürt werden können. Es gibt dann keine Authentifizierung, kein Sessionmanagement wieder. Also wieder kann hier gefälscht werden. Ein anderes Problem ist, es gibt ein Problem im Android-System. Zufuhr sind alle Anwendungen, mussten Corephone-Permission haben, um Anrufe tätigen zu können, weil Wohnt jetzt erst neu ist. Die Anrufprozedur ist jetzt nicht mehr im Kommunikationsprozessor, sondern im Anwendungsprozessor. Im Android-Erlaubnismodell gab es Probleme. Die Corephone-Permission ist sehr standardmäßig. Also fast jede Anwendung auf dem Telefon hat die Interneterlaubnis. Fast jede Anwendung kann dieser Angriff durchführen. Sie können die Anrufe blockieren, teure Videoanrufe zu anderen machen. Das kann eine teure Rechnung geben. Die Dinal-of-Service-Anrufe, die schädigende Anwendung, arbeitet im Hintergrund beim Opfer und es hinterlässt keine Spuren, sodass das Opfer nicht das erkennen kann. Die Anwendung macht einen Anruf an den Attacker und blockiert den Anruf des normalen Anrufers. In einem normalen Fall kann die Anwendung diesen Anruf abschneiden. Lassen wir uns die Demo an des Anrufblockens. Die Hintergrundanwendung ruft den Angreifer an. Das ist die Nachricht, dass der Leitung besetzt ist in Korea. Man kann also jeden Anruf blockieren. Das ist die Abschneidetemonstration. Das ist ein normaler Anruf. Und die schädliche Anwendung auf dem Opfer kann jetzt den Anruf abschneiden, indem sie den Angreifer anruft. Jede Anwendung mit der Interneterlaubnis kann das durchführen. Um das zusammenzufassen, haben wir diese Tabelle erstellt. Wir haben jetzt mehrere Möglichkeiten, das zu beheben. Zum einen sollte man die Sprachpakete verschlüsseln. Mit IPsec oder TLS kann man die Signalnachrichten verschlüsseln oder die Sprachdaten mit SRTP verschlüsseln. Das Problem der fehlenden Authentifizierung kommt von den Betreibern, weil sie nur die Nutzer mit dem SIP-Header authentifizieren. Also die SIP-Packets, die kann jeder manipulieren. Wir schlagen vor, um das zu verhindern, wie ich es vorher schon gesagt habe. Jedes Wollt-Schnittstelle hat das Cornetswerk kann das originale Paket erkennen. Für das vernünftige Sessionmanagement sollte man vernünftige Regeln auf den Anigate-Vents aufstellen. Um das Android-Problem zu beheben, sollte man strenge die Sockets zu den Datenschnittstellen verbinden. Das Problem im Android-System ist, wenn eine Anwendung ein Socket öffnet, setzt man die Ziel-IP-Adresse im IMS die SIP-Adresse und das Android-System routet dann automatisch durch das Wortsystem. Wir haben das an Google gemeldet und Sie haben das folgendermaßen gepatched. Im November haben Sie einen Flag gesetzt für die IMS-Möglichkeit. Sie testen jetzt, ob eine Anwendung ohne die Systemanlaubnis das durchführt und dann blocken Sie diese Anwendung. Um SIP-Mediatalling zu verhindern, kann man die Packet-Inspection verwenden, aber Mediatalling ist nicht so einfach zu lösen, weil die Daten, kann man genauso wie die Sprachdaten, verschlüsselt. Aber ich glaube nicht, dass die Betriebe das so machen werden, weil sie um ihr Profite besorgt sind. Sie werden weiterhin die zeitbasierte Abrechnung verwenden und nicht die weitbasierte Abrechnung. Das ist jetzt Ihre Sache, was Sie wählen. Während wir diese Untersuchung gemacht haben, haben wir gefunden, dass wir zwei KPP-Spezifikationen Probleme haben. Die Spezifikation war so abstrakt und hat die Details zu sehr den Betreibern überlassen. Die Betreiber haben die Spezifikation falsch verstanden und falsch implementiert. Die wichtigen Sicherheitsfunktionen in den Spezifikationen waren bloß Vorschläge und nicht Pflicht. Und die Betreiber haben das dann einfach nicht befolgt. Wir haben das an die Betreiber und an Google im Mai gemeldet. Google hat geantwortet. Die beiden US-Betreiber haben uns einfach nicht geantwortet. Nur zwei der drei koreanischen Betreiber haben etwas gepatched mit uns zusammen. Einer der koreanischen Betreiber hat uns nicht einmal eine Bestätigung der Meldung gegeben. Wir wissen nicht, was bei dem anderen koreanischen Betreiber so passiert ist, obwohl wir koreaner sind. Während wir das getan haben, waren wir sehr beeindruckt von den US-Surts, wie Sie das, wie die Schwachstechende Stellen behandelt haben. Sie haben sogar vulnerability Notes herausgegeben. Und als wir Ihnen die Berichte von uns geschickt haben, haben Sie unseren Bericht an alle US-Betreiber und Google und Apple gesendet. Und Apple hat uns gemeldet, dass das iPhone zu dieser Schwachstelle nicht angreifbar ist. Also ich denke nämlich mal an, dass Sie die Sockets zu den Interfaces streng sind. Deswegen denke ich mal, ist das iPhone nicht angreifbar. Obwohl wir junge Studenten sind, obwohl das ein sehr moderates Level ist, es ist ein Anfangspunkt und wir denken, dass das Problem trotzdem interessant ist. Danke schön. Glaubt ihr, dass das Voice over IP System noch sicher ist? Richtig. Weil manche Leute glauben vielleicht, dass das Voice over IP System sicher genug ist, aber die Sicherheit von Voice over IP ist schon mehrere Jahre studiert worden. Wir haben das aber einmal auf einem System getestet und es war auch angreifbar. Also wir denken, wenn Wort mit Voice over IP verbunden ist, dann ist das ein weiteres Interessantes Untersuchungsfeld. So, um das nochmal zusammenzufassen, wir haben zwei Funde aus dem Vault Interface. Wir haben vier freie Datenkanäle gefunden und fünf Sicherheitsprobleme. Und ich denke, diese Probleme sind verbunden mit allen beteiligten Parteien, mit der 3KBP, mit den Netzbetreibern. Ich denke, jedes System hat Schwachstellen, da Vault relativ neu ist. Das haben wir Vault uns vorgenommen. Und da mehr und mehr Systeme, die zellulären Netzwerke werden werden, sollten wir einen holistischen Ansatz für Wort verwenden. Vielen Dank und ich bin jetzt bereit für Fragen. Okay, wir haben relativ viel Zeit für Q&R. Also bitte geht an die Mikrofone. Falls ihr jetzt den Raum verlassen müsst, macht das bitte leise. Okay, ich wohne mit zwei. Okay, hi, das war sehr interessant. Ich habe einige Fragen hier über den Spoofing-Angriff. Was ihr da tut, ist wie wir es nicht in ihr Schickpakete direkt zum anderen Telefonen. Okay, ja. Das Netzwerk hat keine Filterung, wie im frühen Internet, keine Live-Filterung. Ja, da gibt es wirklich keinen Filter. Du kannst einfach nur deine Telefonnummer verändern, zu der das zielt. Habt ihr Spoofing versucht, auch die IP-Adresse zu spufen? Ist das möglich? Du meinst IP-Spoofing? Wir haben das nicht versucht. Aber wenn, als wir das vor einigen Monaten ausprobiert haben auf den koreanischen und US-amerikanischen Betreibern, waren sie aber nicht angreifbar über IP-Spoofing. Danke. Falls ihr auf dem Stream gerade seid, könnt ihr auch IRC verwenden, um Fragen zu stellen übers Internet. Meine Frage hat der Betreiber, irgendwelche Gründe MediatunLink zu blockieren. Es ist nicht teurer, Daten durch Voice over LTE zu tunnen, als nicht einfach die, was für Dich Service ist zu nutzen. Okay. Im Moment ist das MediatunLink, ist die Bandbreite sehr gering. Wir glauben, dass der Betreiber dieser Angriff nicht unterstützt, aber tatsächlich werden die Betreiber in der Zukunft vielleicht die Bandbreite dort größern oder einen anderen Bearer verwenden. Denn sie werden vielleicht noch versuchen, andere Dienste zur Verfügung zu stellen, mit größerer Bandbreite. In diesem Fall wäre MediatunLink dann möglich. MediatunLink ist aber nicht einfach. Nummer vier, bitte. Glückwunsch für eure Ergebnisse. Ich glaube, dass ihr einige Zeit lang in das Diak-Interface hineingeschautet von Quarkom. Was ihr da zeigt im Wesentlichen, ist das Kommand, mit dem man lesen und schreiben kann zu jeder Speicheradresse. Und dann tun können, was immer man will. Das gibt euch also RCE, Remote Code Execution. Ist das jetzt auf jedem Quarkom-Basement? Die Antwort ist nein. Denn um Diakom zu setzenden, muss das Telefon verbunden sein mit deinem Laptop oder deinem PC. Man kann die RCE-Angriffe nicht durchführen. Wenn aber dort Schwachstellen auf diesem System sind, kann man das lokal ausnutzen. Was ich meine ist, wir haben genommen, man hat Route Permission auf dem Android und man möchte jetzt tief in den Base Memory gehen. Da kann man Diakommandasort hinschicken und dann lesen und schreiben. Tatsächlich haben wir das probiert, aber einige der Diakommandos wurden blockiert. Und wir konnten zum Beispiel nicht die Speicheradressen verändern. Aber das Diak System blockiert einfach diese Kommandos. Danke. Nummer zwei. Hi. Ich habe früher Sicherheitsforschung betrieben über Voice over IP. Und viele der Verwundbarkeiten, die hier beschreibt, beziehen sich auf traditionelles Voice over IP für Voice over IP gibt es Sicherheitsstandards. Und es scheint mir so zu sein, dass die Provider in Korea und in den USA die Sicherheitsrichtlinien nicht installiert haben, um diese Angriffe abzuwehren, oder? Weil wir nicht die Betreiber sind, wissen wir das nicht genau. Aber als wir das getestet haben, also diese Schwachstellen waren da. Also ich bin mir nicht sicher. Mit unserer Responsible Disclosure haben Sie versucht, nachdem wir das berichtet haben, haben Sie etwas gepatched. Aber Sie haben Ihre Richtlinien auch etwas geändert. Danke. Nummer eins. Ja, ich habe mich gefragt. Ich habe mich über das Corm Session Management mir Gedanken gemacht, wie Ihre Sourcenintensive sein kann. Gibt es da irgendwelche Ideen, wie man das löst? Um das Session Management zu lösen? Auf der Server Seite. Auf der Server Seite. Ich denke, es ist relativ einfach. Denn wenn irgendein Nutzer einen Anruf macht, dann wird die SCP Nachricht, wird ein SCP Inval zum Server geschickt und der SCP Server weiß, welcher Nutzer er gerade anruft. Wenn du den Status des Nutzers prüfst, dann kannst du nach der Invalid Message... Ich glaube nicht, dass das Problem löst. Ja, ich frage mich nur über die Ressourcinternität, denn dies ist für den Betreiber so viele Sessions oder Inseit zu behandeln. Danke. Nummer drei, bitte. Meine andere Frage ist, ihr habt gesagt, dass ihr euch ein bisschen universe Engineering bemüht habt beim Direct Protocol. Habt ihr seit der Lage, eure Ergebnisse open source zu stellen und wenn ja, wo können wir dies finden? Also, weißt du, da gibt es mehrere Dokumente, die du auf dem Google finden kannst. Wir haben diese Kommandos gefunden, in denen wir gegoogelt haben. Wir haben das USB Protocol reverse engineered, indem wir die USB-Pakete einfach mit gesnifft haben. Später haben wir das System komplett analysiert, aber wir können das nicht veröffentlichen. Signal Engel. Danke. Ist es möglich, den IMS des Betrebers überhaupt nicht zu benutzen? Kann man sein eigenes Voice over IP-Netzwerk konfigurieren und mit Freunden über Direktes IP dann sprechen? Kannst du das bitte nochmal wiederholen? Ist es möglich, das IMS des Betrebers nicht zu benutzen, einfach das eigene Voice over IP, die eigene Anwendung aufsetzen und mit den Freunden sprechen? Ja, das kannst du machen. Du kannst das eigene freie Voice over IP-System benutzen. Aber da der Betreiber das Wort System bereitstellt, wollen sie noch höhere Prioritätssysteme zur Verfügung stellen. Wenn du dein eigenes Voice over IP-System benutzt, dann benutzt du das Dateninterface, wie ich vorher begrenzt habe. Das Sprachinterface hat eine höhere Priorität als das Dateninterface. Keine Qualitätssicherung auf dem Interface, keine Qualitie of Service auf dem Interface. Die Antwort ist also, du kannst dein eigenes System implementieren, aber du kannst keine Garantie bekommen für die Bandbreite oder sowas. Nr. 4 bitte. Ich bin interessiert an den Argumenten, die ihr mit den Betreibern ausgetauscht habt, damit sie das Problem lösten. Denn während wir diese Verwundbarkeiten berichtet haben, die Betreiber haben sich nicht darum gekümmert, weil die Zeit, die sie verwenden müssten, sie denken, dass sie gegen ihre Konkurrenten Verluste erleiden. Wie kann man Betreiber zwingen, auf die Verwundbarkeiten zu reagieren? Ich bin mir nicht sicher, ob es da rechtliche Probleme gibt, dass die Surds nicht die Betreiber zwingen können, das zu patchen. Aber die Tatsache, dass die koreanischen Betreiber das sehr schnell gepatched haben, da gibt es ein koreanisches Nachrichtensystem, wo man Nachrichten empfängt. Gibt es mehrere Bürger, die das schnell gepatched haben? Die Macht der Bürger hat das vielleicht etwas beschleunigt. Ich weiß nicht, ob da Klagen vielleicht genannt wurden. Internet, bitte. Frage, wenn du deine Nummer fälst, wird dann nicht auch das headerfeld, das p-certed-identity-Feld, bitte den Nachrichterschießen, wenn ihr eure Nummer fälst mit eurer Anwendung, wird dann auch das p-certed-identity-Headerfeld gesetzt oder wird das überschrieben? Ich bin mir nicht sicher. Es gibt nur Telefonnummern, und im SAP-Header kann man nur die Telefonnummer austauschen, kann man auch die IP-Headerasse verändern, wenn man das kann, dann kann man auch Callerspuffing werden. Haben wir weitere Fragen? Es gibt auch dort hinten ein Mikrofon, das ihr jetzt nicht bemerkt habt. Okay, dann bitte noch einmal Danke an die beiden Redner.