WEBVTT
00:00:00.000 --> 00:00:19.665
36C3 Vorspannmusik
00:00:19.665 --> 00:00:22.867
Herald: Willkommen zum nächsten Vortrag.
Ich muss ja sagen, aus persönlicher
00:00:22.867 --> 00:00:26.660
Erfahrung, dass der Kongress für mich
gerade deswegen so schön ist, weil er so
00:00:26.660 --> 00:00:30.359
traumhaft familienfreundlich ist. Wir sind
diesmal wieder mit zwei Kindern da, und da
00:00:30.359 --> 00:00:35.250
ist natürlich das Kids-Space absolut
goldwert, aber, und das glaubt man gar
00:00:35.250 --> 00:00:40.080
nicht, dieses Ding hier, das DECT-Telefon,
das macht diesen Kongress auch für mich
00:00:40.080 --> 00:00:44.570
extrem kinderfreundlich, weil wir eben
schon vor vielen Jahren unseren Sohn mit
00:00:44.570 --> 00:00:48.940
so einem DECT-Telefon einfach laufen
lassen konnten und der konnte den Kongress
00:00:48.940 --> 00:00:53.554
für sich selbst entdecken und wir konnten
unseren Sohn später wiederentdecken. Das
00:00:53.554 --> 00:00:57.480
ist sehr, sehr hilfreich. Deswegen, so
eine Technologie macht eben auch eine
00:00:57.480 --> 00:01:03.950
Konferenz viel, viel wertvoller. Ich bin
zugegebenerweise nur Dummer, aber
00:01:03.950 --> 00:01:08.030
dankbarer Nutzer, aber die jungen Herren,
die wir jetzt hier haben, die können uns
00:01:08.030 --> 00:01:12.530
etwas sagen, was mit dieser Technologie
noch möglich ist. Wir begrüßen nämlich
00:01:12.530 --> 00:01:16.850
Zivillian und ST, die sind beide
Mitglieder im Eventphone-Team, und wir
00:01:16.850 --> 00:01:21.170
haben einen Gast-Hacker mit LaForge und
die werden jetzt den Vortrag halten.
00:01:21.170 --> 00:01:25.870
Hashtag #mifail oder: Mit Gigaset wäre das
nicht passiert! Oder der Untertitel, der
00:01:25.870 --> 00:01:29.930
mir sehr gut gefällt, DECT ist korrekt.
Vielen Dank!
00:01:29.930 --> 00:01:37.654
Applaus
00:01:37.654 --> 00:01:41.671
ST: Ja, vielen Dank. Wir sind total
überrascht, weil wir ja dachten, das ist
00:01:41.671 --> 00:01:45.820
ein Nischen-Vortrag, da haben wir mit 20
Leuten gerechnet, jetzt sind doch 40
00:01:45.820 --> 00:01:54.870
gekommen, das ist richtig krass. Ja, im
Prinzip ist die Vorstellung durch. Was
00:01:54.870 --> 00:01:58.930
machen wir heute? Wir müssen uns auf jeden
Fall beeilen, weil es ist sehr sehr viel.
00:01:58.930 --> 00:02:04.560
Ganz kurz werden wir etwas dazu erzählen,
was ist das POC eigentlich genau. Was
00:02:04.560 --> 00:02:08.569
machen die so? Was benutzen wir für
Technologie? Deswegen haben wir auch am
00:02:08.569 --> 00:02:14.200
Anfang diesen komplizierten Aufbau, dass
wir uns hier direkt die Hardware live
00:02:14.200 --> 00:02:19.160
angucken können. Wie das alles
funktioniert. Dann kommen wir zu dem
00:02:19.160 --> 00:02:27.250
eigentlichen Problem, dass es dort, ja,
eine kleine Sicherheitsschwankung gab, die
00:02:27.250 --> 00:02:33.580
wir herausgefunden haben, LaForge wird das
genau erklären, wir werden Euch erzählen,
00:02:33.580 --> 00:02:39.970
wie der Hersteller damit umgegangen ist
und was wir dann daraus gebaut haben und
00:02:39.970 --> 00:02:44.810
wie wir sozusagen mit dieser
Sicherheitsschwankung mehr Features
00:02:44.810 --> 00:02:51.540
implementiert haben und noch mehr für die
User tun können. Weiter geht's dann mit
00:02:51.540 --> 00:02:56.090
den Metadaten, wie sind wir eigentlich
dazu gekommen und dann zeigen wir Euch
00:02:56.090 --> 00:03:03.390
dann nochmal live hier auf dem Tisch, wie
man unwillige Geräte willig bekommt und am
00:03:03.390 --> 00:03:08.660
Ende gibts noch einen Ausblick. Dann
fangen wir mal damit an... Was ist
00:03:08.660 --> 00:03:14.209
eigentlich das POC wer oder was ist das
Eventphone und dann haben wir geguckt, was
00:03:14.209 --> 00:03:18.720
sagt eigentlich dieses Internet? Und das
Internet sagt, das Phone Operations Center
00:03:18.720 --> 00:03:22.950
ist ein integriertes Hard- und
Softwareprojekt, welches es ermöglicht,
00:03:22.950 --> 00:03:26.490
auf Grossveranstaltungen ein
fläschendeckendes und funktionsfähiges
00:03:26.490 --> 00:03:32.459
DECT-Netz zu realisieren. Steht in der
Wikipedia, muss ja stimmen und in der Tat,
00:03:32.459 --> 00:03:38.260
das ist so und sehr schön finden wir auch
"Eventphone, ein bedeutender Anbieter von
00:03:38.260 --> 00:03:44.400
drahtloser Kommunikation für
Großveranstaltungen". Bedeutend, ja. Das
00:03:44.400 --> 00:03:49.569
freut uns natürlich. Nun zu unserem One-
Pager, Was machen wir wirklich wirklich?
00:03:49.569 --> 00:03:55.650
Also klar, Infrastruktur für drahtlose
Telefone, das wisst Ihr wahrscheinlich
00:03:55.650 --> 00:04:00.550
alle. Wer von Euch hat ein DECT? Könnt ihr
mal Handzeichen geben? Oh, ja, ja, da ist
00:04:00.550 --> 00:04:07.188
ja der Raum sagen wir mal die Hälfte. Dann
machen wir Leih-Telefone für Orga- und
00:04:07.188 --> 00:04:11.550
Infrastruktur-Teams, die bereiten wir im
Wesentlichen vorher schon vor.
00:04:11.550 --> 00:04:15.840
Provisionieren die, stellen den Betrieb
sicher, nehmen die zurück und reinigen die
00:04:15.840 --> 00:04:23.080
dann auch wieder. Der Telefondesinfizierer
ist das Stichwort. Dann haben wir SIP und
00:04:23.080 --> 00:04:27.569
Premium. SIP-Server, die wir betreiben,
Premium-SIP tatsächlich, die haben
00:04:27.569 --> 00:04:32.139
wikrlich andere Funktionen, zum Beispiel
das CERT, die sichere Leitungen brauchen,
00:04:32.139 --> 00:04:36.819
die möglichst nicht ge-DDoS-sed werden
haben andere Server und man kann, hat dort
00:04:36.819 --> 00:04:40.689
mehr Rechte, kann zum Beispiel
raustelefonieren. Das EP-VPN betreiben
00:04:40.689 --> 00:04:45.749
wir, also ein VPN, was auch außerhalb der
Events funktioniert. Das integrieren wir
00:04:45.749 --> 00:04:50.620
immer in die Netze der Veranstaltungen.
Das Rufnummern- und Token-Handling, wer
00:04:50.620 --> 00:04:54.409
quasi ein DECT angemeldet hat, der weiß,
da muss man ein Token eingeben, das machen
00:04:54.409 --> 00:05:00.580
wir alles. Unser GURU, der Generic User
oder das Generic User Registration
00:05:00.580 --> 00:05:04.819
Utility, das Self-Service-Portal, dort wo
ihr Eure Nummern anlegen könnt, wo ihr Eure
00:05:04.819 --> 00:05:09.599
Geräte verbinden könnt. Und so. Das ist
auch von uns. Auch sozusagen der Link zum
00:05:09.599 --> 00:05:15.909
GSM-Team, deren Rufnummern verwalten wir
auch. Dial-In/Dial-Out, also das Ihr
00:05:15.909 --> 00:05:20.110
angerufen werden könnt von Außen und das
Ihr Euch auch raustelefonieren könnt.
00:05:20.110 --> 00:05:25.219
Special Services, zum Beispiel die
Anbindung der Chaos-Vermittlung. Es gibt
00:05:25.219 --> 00:05:30.349
Spiele, Witze-Hotline, die Uhrzeit oder
eine automatische Annahmestelle für Lärm-
00:05:30.349 --> 00:05:34.919
Beschwerden.
Gelächter
00:05:34.919 --> 00:05:39.720
Weiterhin haben wir noch eine neue
Abteilung, die Ausbildung in
00:05:39.720 --> 00:05:48.559
Medienkompetenz. Wo wir Euch immer wieder
vor Augen halten. Guckt alles kritisch an
00:05:48.559 --> 00:05:55.309
und nehmt nicht alles so für bare Münze,
was Ihr so in diesem Internet seht und
00:05:55.309 --> 00:06:04.335
hört. Und, wir sind in diesem Jahr
volljährig geworden.
00:06:04.335 --> 00:06:13.569
Applaus
Und dazu muss ich noch drei Sekunden etwas
00:06:13.569 --> 00:06:18.029
sagen, nämlich es gibt eine Person, die
das tatsächlich seit 18 Jahren schon macht
00:06:18.029 --> 00:06:22.319
und wirklich auf jedem Event, nicht nur
Kongresse, auch in der Sommer-Events und
00:06:22.319 --> 00:06:27.650
dazwischen immer dabei war, der, egal ob
krank oder nicht, sich für das Telefonnetz
00:06:27.650 --> 00:06:31.461
eingesetzt hat und das ist Sascha. Und an
der Stelle wollte ich noch mal ganz, ganz
00:06:31.461 --> 00:06:36.401
lieben Dank sagen, 18 Jahre Eventphone,
für Dich...
00:06:36.401 --> 00:06:49.210
Applaus
So, kürzen wir das ab. Kurzum, man ist
00:06:49.210 --> 00:06:53.830
überall erreichbar, auch im Schwimmbad.
Wer die Kampagne kennt, wer sie nicht
00:06:53.830 --> 00:06:59.012
kennt, der QR-Code im Nachgang, sehr gern.
So, dann. Worum geht es heute nicht? Noch
00:06:59.012 --> 00:07:03.939
einmal ganz konkret, wir haben auf dem
35C3 einen langen Vortrag gehalten,
00:07:03.939 --> 00:07:07.099
darüber, wie ist das Eventphone
entstanden, was gibt es für Geschichte und
00:07:07.099 --> 00:07:10.699
so weiter und so fort. Das werden wir
heute nicht besprechen. Und auch auf dem
00:07:10.699 --> 00:07:14.919
Easterhegg haben wir sozusagen dieses neue
Telefonsystem nochmal im Detail erklärt,
00:07:14.919 --> 00:07:20.439
also warum sind wir von dem alten Alcatel-
System auf dieses neue Mitel-System
00:07:20.439 --> 00:07:25.830
umgestiegen? Und was gehört da alles
dazu. Das alles heute nicht, könnt ihr im
00:07:25.830 --> 00:07:31.509
Nachgang euch anschauen. Heute geht es
wirklich nur um diese rote Linie, nämlich
00:07:31.509 --> 00:07:38.150
die Verbindung von dem Open Mobility
Manager, dem OMM, und den RFPs, den Radio
00:07:38.150 --> 00:07:47.699
Fixed Parts, also den umgangssprachlichen
Antennen. Dann werden die Techjungs ganz
00:07:47.699 --> 00:07:51.409
viele Abkürzungen benutzen, und die würde
ich nochmal ganz schnell einmal
00:07:51.409 --> 00:07:56.509
durchgehen. OMM haben wir gerade gesehen
auf der Folie davor. Open Mobility
00:07:56.509 --> 00:08:02.379
Manager, das ist das Stück Software von
Mitel. RFP das sind diese Radio Fixed
00:08:02.379 --> 00:08:09.919
Parts, also die Antennen und die PPs das
ist so DECT-Sprech, dass ist alles, was
00:08:09.919 --> 00:08:15.180
mobil ist. Da klingelt schon wieder eins.
Sehr schön, unser System läuft. Alles, was
00:08:15.180 --> 00:08:21.189
sich bewegen kann, PPs Portable Parts,
normale DECT-Endgeräte, aber eben auch
00:08:21.189 --> 00:08:29.259
solche kleinen Headsets. Dann wisst ihr,
was damit gemeint ist. Dann werden wir ein
00:08:29.259 --> 00:08:33.410
paar Abkürzungen verwenden, die
IPEI und ihr seid ja alle sicherlich im
00:08:33.410 --> 00:08:37.970
Netzwerksegment ein bisschen firm:
International Portable Equipment
00:08:37.970 --> 00:08:42.020
Identifier. Das könnt euch vorstellen,
dass ist sowas ähnliches wie die MAC-
00:08:42.020 --> 00:08:48.000
Adresse. An dem Beispiel seht ihr auch
dort ist ein Teil kursiv geschrieben. Der
00:08:48.000 --> 00:08:52.340
ist sozusagen der Herstellerteil. Das ist
auch wie bei der MAC-Adresse. Der ist fest
00:08:52.340 --> 00:08:56.100
zugewiesen. Daran kann man den Hersteller
erkennen, und danach ist einfach ein
00:08:56.100 --> 00:09:01.920
Zähler. Ebenso kann man einen
Netzwerkvergleich herstellen mit der IPUI
00:09:01.920 --> 00:09:07.860
der International Portable User Identity.
Das ist so etwas ähnliches wie die IP-
00:09:07.860 --> 00:09:14.140
Adresse, die wird sozusagen von dem System
ausgegeben, was es sozusagen betreibt,
00:09:14.140 --> 00:09:19.490
also der DHCP-Server vom NOC vergibt
IP-Adressen und wir vergeben diese IPUIs und
00:09:19.490 --> 00:09:26.580
dann werden die ETSI kennenlernen, das
European Telecommunications Standards
00:09:26.580 --> 00:09:32.170
Institute, das verabschiedet im Prinzip
Standards, wie der Name sagt, in Europa.
00:09:32.170 --> 00:09:39.330
Und da gehört, ganz wichtig, auch DECT
dazu. Die IPUI, noch ganz kurz hinterher,
00:09:39.330 --> 00:09:42.730
die gibt es in mehreren Formaten. Also das
Beispiel, was dort steht, das muss nicht
00:09:42.730 --> 00:09:48.500
unbedingt so sein. Das ist nicht so
einfach, wie bei der IT, genormt. So, und
00:09:48.500 --> 00:09:54.050
jetzt gucken wir uns mal ganz genau an,
wie denn hier soein SIP-DECT
00:09:54.050 --> 00:09:59.420
zusammengestellt ist und Zivillian wird
euch das erklären und ich verfolge das
00:09:59.420 --> 00:10:05.321
hier mal mit der Kamera.
zivillian: Genau. Anleitung zum
00:10:05.321 --> 00:10:08.860
Selbermachen ist der Titel. Wir wurden
schon oft gefragt, was genau macht ihr da?
00:10:08.860 --> 00:10:12.740
Wie funktioniert das? Kann ich das auch
machen? Ich will Hotel-VPN machen äh
00:10:12.740 --> 00:10:19.310
Hotel-DECT machen. Was genau muss ich
dafür tun? Ihr braucht natürlich eine
00:10:19.310 --> 00:10:24.710
Antenne, ein Radio Fixed Part. Die gibt's
in verschiedenen Generationen. Wir
00:10:24.710 --> 00:10:29.880
empfehlen euch Generation 3 oder höher.
Die sind relativ einfach zu erkennen. Zum
00:10:29.880 --> 00:10:33.890
Einen haben die Generation-3-Antennen,
Lüftungsschlitze auf der Rückseite, und
00:10:33.890 --> 00:10:36.500
zum Anderen haben die
Generation-3-Antennen auch einen
00:10:36.500 --> 00:10:39.710
USB-Anschluss. Das heißt, wenn ihr euch
irgendwo sowas kaufen wollt und nicht
00:10:39.710 --> 00:10:43.680
sicher seid, was das ist, dann guckt
einfach drauf. Generation 2 oder darunter
00:10:43.680 --> 00:10:49.250
empfehlen wir nicht mehr. Die Geräte gibt
es unter Anderem beim Hersteller, aber man
00:10:49.250 --> 00:10:54.131
kann die natürlich auch gebraucht kaufen.
Die gibt's meistens für unter 100 Euro.
00:10:54.131 --> 00:10:58.780
Wenn sie mehr als 100 Euro kosten, dann
ist es ein bisschen überteuert. Dazu
00:10:58.780 --> 00:11:03.280
braucht er eine Lizenz, weil das ist
natürlich keine Open-Source-Software von
00:11:03.280 --> 00:11:08.890
Mitel, sondern ein kommerzielles Produkt.
Da gibts eine Besonderheit: Bis zu fünf
00:11:08.890 --> 00:11:11.540
Antennen können mit der integrierten
Lizenz betrieben werden, die bei der
00:11:11.540 --> 00:11:14.280
Software mit dabei ist. Das heißt, für
kleine DECT-Installationen, wie zum
00:11:14.280 --> 00:11:19.180
Beispiel für unser Aufbau-DECT, braucht
man keine Lizenz. Das hat nur fünf
00:11:19.180 --> 00:11:24.571
Antennen. Das kann man einfach kostenlos
nutzen. Wenn man telefonieren möchte, also
00:11:24.571 --> 00:11:29.460
nicht nur zwischen den Geräten, sondern in
Richtung SIP, mit Dial-Out oder Dial-In,
00:11:29.460 --> 00:11:32.630
dann braucht man natürlich noch einen SIP-
Server dahinter. Wir empfehlen an der
00:11:32.630 --> 00:11:38.560
Stelle immer den Yate, den wir selber auch
einsetzen in unserer Installation. Und wir
00:11:38.560 --> 00:11:43.060
haben da in den Slides auch das Cookbook
für Yate verlinkt. Das ist auch in dem QR-
00:11:43.060 --> 00:11:45.790
Code nochmal zu finden. Das sind relativ
hilfreiche Anleitungen, wenn man da
00:11:45.790 --> 00:11:49.540
keinerlei Erfahrungen hat, um
reinzukommen. Damit kann man sich auf
00:11:49.540 --> 00:11:54.020
jeden Fall auch einen eigenen SIP-Server
installieren. Den OMM, den ST schon
00:11:54.020 --> 00:11:58.760
erwähnt hat, braucht man natürlich auch,
weil der steuert die Antennen. Da gibt es
00:11:58.760 --> 00:12:03.090
zwei Möglichkeiten, wie man den betreiben
kann. Die eine Möglichkeit ist, den direkt
00:12:03.090 --> 00:12:07.070
auf der Antenne laufen zu lassen. Da läuft
auch nur ein abgespecktes Linux drauf. Da
00:12:07.070 --> 00:12:11.090
kann man auch den OMM laufen lassen. Das
haben wir selber nie ausprobiert, deswegen
00:12:11.090 --> 00:12:15.340
haben wir da keinerlei Erfahrung.
Alternativ reicht irgendwas, wo ein CENTOS
00:12:15.340 --> 00:12:19.250
läuft. In unserem Beispiel bei dem Aufbau-
DECT ist das halt so eine kleine Hardware-
00:12:19.250 --> 00:12:24.540
Appliance. Für die Anlage, die wir hier
auf der Veranstaltung betreiben, haben wir
00:12:24.540 --> 00:12:31.410
beim NOC einen Server stehen, wo die als
VM drauf läuft. Hier nochmal hübsch
00:12:31.410 --> 00:12:35.080
visualisiert: Wenn man den OMM auf der
Antenne laufen lässt, dann ist die erste
00:12:35.080 --> 00:12:38.720
Antenne gleichzeitig auch der OMM, und
alle weiteren werden dann einfach per IP
00:12:38.720 --> 00:12:43.590
mit dieser ersten Antenne verbunden. Und
der OMM braucht dann halt die Verbindung
00:12:43.590 --> 00:12:47.730
zu dem Yate, zu dem SIP-Server. Der
Nachteil davon ist, dass man in dieser
00:12:47.730 --> 00:12:53.270
Minimalinstallation, wenn man keinen
eigenständigen OMM betreibt, maximal 512
00:12:53.270 --> 00:12:56.840
Endgeräte anmelden kann und wenn ihr auf
unser Dashboard schaut, dann seht ihr,
00:12:56.840 --> 00:13:02.340
dass das für hier nicht funktionieren
würde. Des Weiteren kann man maximal 256
00:13:02.340 --> 00:13:06.128
Antennen anschließen. Das ist dann schon
eine etwas größere Installation. Aber da
00:13:06.128 --> 00:13:10.510
gibts halt ein hartes Limit. Wenn man den
standalone betreibt, kann man deutlich
00:13:10.510 --> 00:13:15.920
mehr Antennen anschließen, bis zu 4096,
und in den aktuellen Versionen werden dann
00:13:15.920 --> 00:13:21.420
auch 10.000 Benutzer bzw. Geräte
unterstützt. Jetzt haben wir den OMM schon
00:13:21.420 --> 00:13:26.590
mehrfach erwähnt. Die spannende Frage ist:
Wie kommt man daran? Offizielle Antwort
00:13:26.590 --> 00:13:30.430
von Mitel ist: Wenn man sich so eine
Antenne kauft, dann bekommt man
00:13:30.430 --> 00:13:34.210
entsprechende Zugangsdaten als Mitel-Kunde
und kann sich dann in dem Download-Portal
00:13:34.210 --> 00:13:37.940
von Mitel anmelden und die Software
herunterladen. Wenn man die Antenne auf
00:13:37.940 --> 00:13:42.240
dem Gebrauchtmarkt kauft, dann hat man
natürlich keine Mitel-Zugangsdaten, aber
00:13:42.240 --> 00:13:46.240
die Release Notes enthalten Download-
Links. die Release-Notes sind teilweise
00:13:46.240 --> 00:13:49.860
öffentlich verfügbar und über
Suchmaschinen auffindbar. Und wir haben
00:13:49.860 --> 00:13:52.690
euch da mal so ein paar Suchbegriffe an
die Hand gegeben, falls ihr Interesse
00:13:52.690 --> 00:13:59.800
daran habt. Ja, jetzt, wo ihr wisst, wie
das geht, stellt sich natürlich die Frage:
00:13:59.800 --> 00:14:06.450
Was macht man damit? Das, was Hacker
machen, ist halt sich Sachen anschauen und
00:14:06.450 --> 00:14:10.540
auch mal ein bisschen tiefer ins Detail
schauen. Und das ist das, was euch LaForge
00:14:10.540 --> 00:14:18.220
jetzt erzählen wird.
LaForge: Ist dieses Mikro ... ja jetzt ist
00:14:18.220 --> 00:14:23.490
es offen. Gut, Firmware-Analyse, ja. Man
guckt sich also ... Ich mein für mich ist
00:14:23.490 --> 00:14:27.370
das normal: Warum guckt man sich Firmware
an? Ist eigentlich klar: Jedes Gerät, was
00:14:27.370 --> 00:14:30.150
ich einen Finger habe, gucke ich mir an,
was will ich denn sonst mit dem Gerät?
00:14:30.150 --> 00:14:33.470
Irgendwie, ja ich will ja verstehen, was
es macht und wie es tut und wie es
00:14:33.470 --> 00:14:37.970
aufgebaut ist und was für Bauteile
verwendet sind und so weiter. Also ist es
00:14:37.970 --> 00:14:40.540
für mich eigentlich normal, dass ich mir
Geräte, die ich irgendwie habe anschaue.
00:14:40.540 --> 00:14:43.690
Jetzt hatte ich da gerade zu dem Zeitpunkt
keine so eine Antenne. Aber ich habe mich
00:14:43.690 --> 00:14:47.270
vor zehn Jahren schon mal mit DECT
intensiver beschäftigt als Teil des
00:14:47.270 --> 00:14:52.900
Projekts, was damals deDECTed hieß. Wir
hatten da Schwachstellen entdeckt,
00:14:52.900 --> 00:15:01.630
entDECT. Ja, entDECT, genau. So, ja und
außerdem ist DECT ja auch, wie wir gerade
00:15:01.630 --> 00:15:04.980
schon gehört haben, eine ETSI-
Spezifikation und ich habe ja mit ETSI-
00:15:04.980 --> 00:15:08.730
Spezifikationen seit über zehn Jahren
quasi täglich zu tun. Zwar jetzt nicht
00:15:08.730 --> 00:15:12.360
DECT, aber andere. Aber prinzipiell sind
eigentlich alle mal ganz interessante
00:15:12.360 --> 00:15:17.240
Lektüre. Ich mein das ist Geschmacksfrage.
Ich mag sowas halt. Und DECT ist ja auch
00:15:17.240 --> 00:15:23.940
immer noch weit verbreitet und gibt ja
auch jetzt hier auch DECT-ULE für
00:15:23.940 --> 00:15:27.270
irgendwelche Internet-of-Things-Dinge, da
werden wir später nochmal drauf
00:15:27.270 --> 00:15:32.620
zurückkommen. Und ich hatte eben gehört,
dass jetzt seit dem letzten Jahr oder seit
00:15:32.620 --> 00:15:37.776
einiger Zeit das POCsich entschieden hat,
auf ein neues System umzustellen. Eben auf
00:15:37.776 --> 00:15:42.820
dieses Mitel-IP-DECT/SIP-DECT-System. Und
letztes Jahr bin ich im November umgezogen
00:15:42.820 --> 00:15:46.570
und dachte mir "Nee, Dezember Kongress,
das ist zu viel Stress. Dann bleib ich mal
00:15:46.570 --> 00:15:48.960
daheim", und dann war ich daheim an
Weihnachten über den Kongress und dachte
00:15:48.960 --> 00:15:55.990
mir "Ach, guck ich mir mal diese DECT-
Geschichte an". Und ja, dann guckt man
00:15:55.990 --> 00:15:59.930
sich natürlich erstmal die Hardware an.
Ging eben auch um diese Generation 3, die
00:15:59.930 --> 00:16:03.960
schon mal erwähnt wurde. Macht/guckt sich
die Platine an: Was sind da so für
00:16:03.960 --> 00:16:08.150
Bauteile drauf? Da findet man dann ein
Marvell Kirkwood ARM System-on-a-Chip,
00:16:08.150 --> 00:16:12.400
der, wie man sich die Firmware anguckt,
tatsächlich ein fast Mainline-Linux laufen
00:16:12.400 --> 00:16:17.560
lässt. Und der hat zwei Ethernet-Ports.
Falls jemand jetzt mit diesem Begriff
00:16:17.560 --> 00:16:20.570
Marvell-Kirkwood nichts anfangen kann, der
ist in ganz vielen Network-Attached-
00:16:20.570 --> 00:16:24.790
Storage-Devices drin. Auch Shiva-Plug, und
wie sie nicht alle irgendwie heißen, da
00:16:24.790 --> 00:16:29.080
gibts jede Menge Devices, die den
verwenden, der hat zwei Ethernet in dieser
00:16:29.080 --> 00:16:34.330
Konfiguration hier in dem RFP drin. Ein
Ethernet-Port ist jener, der Richtung OMM
00:16:34.330 --> 00:16:36.970
spricht, also der, der auch nach außen
herausgeführt ist am Gerät auf der
00:16:36.970 --> 00:16:40.640
RJ45-Buchse. Und dann gibts einen zweiten
Ethernet-Port. Ein zweiter Ethernet-Port:
00:16:40.640 --> 00:16:44.270
Was machen Sie denn damit? Und Sie haben
tatsächlich diesen eigentlichen DECT-
00:16:44.270 --> 00:16:48.650
Prozessor über Ethernet angebunden. Das
heißt, also man hat einmal Ethernet von
00:16:48.650 --> 00:16:51.841
diesem ARM-System-on-Chip, einmal Ethernet
Richtung dem DECT-Prozessor und einmal
00:16:51.841 --> 00:16:56.440
Ethernet nach außen und man hat serielle
Konsole für Uboot und Linux und das
00:16:56.440 --> 00:16:59.990
Passwort wird vom OMM gesetzt. Und das ist
auch in der offiziellen Doku dokumentiert,
00:16:59.990 --> 00:17:04.029
dass das da gesetzt wird, wenn man den
konfiguriert. Das heißt, man kann da auch
00:17:04.029 --> 00:17:07.809
prima drauf und sich das anschauen und so
weiter. Also als legitimer User oder
00:17:07.809 --> 00:17:12.740
Anwender sozusagen dieses Geräts kann man
sich dann einloggen, kann sich umschauen.
00:17:12.740 --> 00:17:15.720
Unten ist das mal schematisch dargestellt
diese unterschiedlichen Verbindungen. Es
00:17:15.720 --> 00:17:21.860
ist dann auch noch ein UART da und andere,
paar GPIOs und so weiter. Wenn man sich
00:17:21.860 --> 00:17:25.610
dann die Software anguckt, die da drauf
läuft, ist, wie gesagt, ein ziemlich,
00:17:25.610 --> 00:17:29.260
erstaunlicherweise ein sehr, sauberer
Mainline-Kernel. Ganz wenig Patches nur
00:17:29.260 --> 00:17:33.780
drin. Und letztlich ist es so, dass im
Kernel eigentlich gar nichts DECT-
00:17:33.780 --> 00:17:37.910
spezifisches ist.Das ist ein ganz normaler
Kernel. Es sind keine komischen Treiber
00:17:37.910 --> 00:17:40.575
oder irgendwas, sondern sie haben dann
eben ein Programm, eben hier dieses
00:17:40.575 --> 00:17:45.679
/opt/ip_rfp/ip_rfp, was Pecket-Sockets
aufmacht auf diesem Ethernet-Device zum
00:17:45.679 --> 00:17:50.119
DECT-Prozessor, und die ganze Verarbeitung
der Kommunikation erfolgt dann in einem
00:17:50.119 --> 00:17:53.710
Userspace-Programm. Dann gibt es noch ein
paar Bibliotheken und andere interessante
00:17:53.710 --> 00:17:57.159
Dinge, die man da so findet in der
Firmware, aber es ist eigentlich erstmal
00:17:57.159 --> 00:18:02.509
ein ziemlich handelsübliches Linux mit
eben diesen proprietären Komponenten, die
00:18:02.509 --> 00:18:07.639
hier Packet-Sockets aufmachen und
derartige Dinge tun. Interessant ist dann
00:18:07.639 --> 00:18:11.360
auch, das man sieht, da habe ich jetzt
nicht auf der Slide drauf, aber man findet
00:18:11.360 --> 00:18:16.549
dann andere, man entdeckt dann auch noch
andere Dinge. Zum Beispiel hatte ich
00:18:16.549 --> 00:18:20.360
gesehen: Da ist Video-for-Linux in dem
Kernel drin. Ich denk mir so: Was, Video-
00:18:20.360 --> 00:18:23.269
for-Linux in einer DECT-Basisstation? Was
hat da jemand vergessene Configuration
00:18:23.269 --> 00:18:27.919
auszuschalten? Nein, es ist tatsächlich so
man kann an diesem USB-Port eine UVC
00:18:27.919 --> 00:18:31.789
Kamera anschließen, also so eine USB
Videoclass Kamera und kann dann auf seinem
00:18:31.789 --> 00:18:39.009
DECT Telefon, sofern es videofähig ist das
Kamerabild über DECT sich anschauen. Sehr
00:18:39.009 --> 00:18:43.129
interessante Funktion. Dann findet man
auch noch ein Bluetooth Chip drin. Aha,
00:18:43.129 --> 00:18:47.579
man kann also offensichtlich irgendwie
Bluetooth Beacons virtuell erzeugen. Auf
00:18:47.579 --> 00:18:51.639
diesen DECT-Basisstationen vielleicht um
irgendwelche Location Services in Museen
00:18:51.639 --> 00:18:55.440
oder irgendwas zu implementieren. Auf den
ersten Blick siehts erst mal komisch aus,
00:18:55.440 --> 00:18:59.860
was man da so findet im Kernel. Aber macht
dann Sinn. Sie haben tatsächlich irgendwie
00:18:59.860 --> 00:19:06.669
usecases dafür. So! Dann findet man binary
images für die Firmware dieses DECT
00:19:06.669 --> 00:19:10.629
Prozessors einmal einen Bootloader, der
über tatsächlich die serielle
00:19:10.629 --> 00:19:14.600
Schnittstelle, die verbunden ist zwischen
diesem DECT Prozessor und dem ARM erst
00:19:14.600 --> 00:19:19.320
einmal drüber geschoben wird. Also über
GPIO wird der Reset losgelassen, dann wird
00:19:19.320 --> 00:19:22.840
diese Firmware da reingeladen und diese
Firmware, also der Bootloader. Der kann
00:19:22.840 --> 00:19:26.499
dann über Ethernet die eigentliche
Firmware nachladen dieses "rfpng.bin",
00:19:26.499 --> 00:19:29.240
oder so dann gibt's noch einen
"macmoni.bin" was wohl offensichtlich ein
00:19:29.240 --> 00:19:34.529
MAC Monitor sein soll. Was genau er tut,
habe ich zumindest mir nicht angeguckt.
00:19:34.529 --> 00:19:39.330
Ja, nun guckt man sich das so an, da hat
man dieses Ethernet Device. Und was macht
00:19:39.330 --> 00:19:41.539
man mit einem Ethernet? Man macht
natürlich erst mal ein ".pcap" File und
00:19:41.539 --> 00:19:45.470
schaut sich an, was irgendwie auf diesem
Ethernet unterwegs ist. Also dieses
00:19:45.470 --> 00:19:48.490
interne Ethernet auf dem Gerät.
Interessanterweise sieht man da nur rohe
00:19:48.490 --> 00:19:53.390
Ethernet Frames. Es gibt da
unterschiedliche Subsysteme. Der Ethernet-
00:19:53.390 --> 00:19:58.929
type unterscheidet dann, was für
Subsysteme da gerade sprechen. Guckt man
00:19:58.929 --> 00:20:02.279
sich das so ein bisschen an, und mit dem,
was man über DECT weiß und probiert so ein
00:20:02.279 --> 00:20:05.269
bisschen das eine oder andere aus auf
einem Telefon, das da angeschlossen ist,
00:20:05.269 --> 00:20:11.669
und versucht, das zu verstehen. Und ich
hab dann so einen minimalistischen
00:20:11.669 --> 00:20:15.669
Wireshark disector für die Teile des
Protokolls, die ich verstanden habe,
00:20:15.669 --> 00:20:20.890
gebaut. Irgendwann war dann klar ab einem
gewissen Punkt, wo die eigentlichen DECT
00:20:20.890 --> 00:20:26.590
standardisierten Pakete sich befinden, und
dafür gibts dann, obwohl es nichts
00:20:26.590 --> 00:20:30.340
properiäres ist, leider auch kein
Wireshark-disector. Ich hab da auch ein
00:20:30.340 --> 00:20:33.799
bisschen was angefangen, aber nur ganz
minimalistisch, damit man halt irgendwie
00:20:33.799 --> 00:20:37.499
so ein bisschen seine Ergebnisse
bestätigen kann. Dann kommen die höheren
00:20:37.499 --> 00:20:39.769
Schichten und so weiter. Da gibts dann
auch wieder keine Wireshark-disektoren da
00:20:39.769 --> 00:20:45.591
habe ich dann aufgehört, das wird dann
uferlos das zu beschreiben. Im Grunde
00:20:45.591 --> 00:20:50.070
sieht der Split der Funktionen. Wenn man
sich den DECT Netzwerkstack anschaut so
00:20:50.070 --> 00:20:53.529
aus. Ich werde jetzt nicht ins Detail
gehen. Wer sich da mehr dafür
00:20:53.529 --> 00:20:57.070
interessiert. Ich hatte einen
ausführlicheren, technischen Vortrag
00:20:57.070 --> 00:21:01.820
gehalten auf der Osmo-Defcon Anfang April
diesen Jahres. Der ist auch bei
00:21:01.820 --> 00:21:08.200
"media.ccc.de" verlinkt. Aber das ist
sozusagen der Split. Im OMM läuft also der
00:21:08.200 --> 00:21:15.200
Data DLC layer, der NWK Layer und was dann
oben drüber kommt und im Radio teil, ist
00:21:15.200 --> 00:21:19.720
eigentlich nur der PHY und der MAC Layer
und an der Schnittstelle zwischen DLC und
00:21:19.720 --> 00:21:24.200
MAC Layer. Da ist dieses Protokoll, was
man sieht über diesen RAW-Ethernet Frames,
00:21:24.200 --> 00:21:28.150
die da vorhanden sind. So! Dann war das
irgendwie so ein bisschen klar, was da
00:21:28.150 --> 00:21:34.659
passiert. Dann guckt man weiter in
Richtung dieses OMM RFP Protokolls. Das
00:21:34.659 --> 00:21:38.440
sieht man. Da wird eine TCP Verbindung
aufgebaut, und dann guckt man im Wireshark
00:21:38.440 --> 00:21:41.850
und sieht... Naja, das ist irgendwie
alles, sieht ziemlich random aus, die
00:21:41.850 --> 00:21:44.820
Entropie ist sehr hoch, muss also
irgendwie verschlüsselt oder zumindest
00:21:44.820 --> 00:21:49.700
verschleiert sein. Man kann dann in dem
RFP und dem OMM ziemlich viel logging
00:21:49.700 --> 00:21:53.309
einschalten, und da macht es dann auch
irgendwann Hex-dupms. Aber die Hex-dumps
00:21:53.309 --> 00:21:55.679
haben überhaupt nichts damit zu tun mit
dem, was über diese TCP-Verbindung geht.
00:21:55.679 --> 00:22:00.029
Ist also irgendwie verschlüsselt. Ist aber
auch kein TLS. Dann guckt man mal, die
00:22:00.029 --> 00:22:04.710
Symboltabellen an, findet, da ist Blowfish
drin. Und zwar wird quasi Blowfish
00:22:04.710 --> 00:22:11.030
Funktionen aus openssl benutzt, und dann
kann man ja, wenn es dynamisch gelinkt
00:22:11.030 --> 00:22:15.293
ist, kann man ja so mit LD-preload andere
Bibliotheken hinladen, die die gleichen
00:22:15.293 --> 00:22:18.980
Symbole anbieten. Und das waren dann 2
Bibliotheken eine "libtracefish", die
00:22:18.980 --> 00:22:23.489
sozusagen cypher Text und plain Text
jeweils als Hex-dump am ausgegeben hat,
00:22:23.489 --> 00:22:28.241
damit man sieht, was da passiert. Und dann
als nächstes die "libnullfish", die
00:22:28.241 --> 00:22:34.270
einfach jeden call auf die Blowfish Funktion durch
ein memcopy ersetzt. Und dann hat man eben
00:22:34.270 --> 00:22:39.410
den plain Text auf der anderen Seite und
sieht das da. Was man erkennt, ist, dass
00:22:39.410 --> 00:22:43.330
viele der rohen Ethernet Frames, die man
auf der Seite Richtung DECT-Prozessor
00:22:43.330 --> 00:22:47.480
gesehen hat, einfach 1 zu 1 durchgereicht
werden, die man halt enkapsuliert zusammen
00:22:47.480 --> 00:22:50.870
mit vielen anderen Dingen über dieses TCP-
Protokoll. Da werden wir noch mehr drüber
00:22:50.870 --> 00:22:54.590
hören, gleich dann im Anschluss, das haben
sich die Leute von Eventphone dann wieder
00:22:54.590 --> 00:23:01.690
näher angeguckt. Was wichtig an der Stelle
noch ist. Ja gut, dann kann man diese
00:23:01.690 --> 00:23:06.710
Verschlüsselung abschalten. Aber Dieter
Spahr, bekannt auch aus dem osmocom
00:23:06.710 --> 00:23:09.770
Projekt, hat sich dann die Verschlüsselung
nochmal ein bisschen näher angeguckt, die
00:23:09.770 --> 00:23:12.929
da passiert. Und die, ich meine Blowfish
ist natürlich klar. Aber die Schlüssel
00:23:12.929 --> 00:23:15.310
Generierung im Speziellen, und es war dann
ziemlich schnell klar, dass es ein
00:23:15.310 --> 00:23:20.610
statischer, für alle Geräte global
einheitlicher statischer Key ist, der da
00:23:20.610 --> 00:23:26.830
verwendet wird. Und das ist natürlich
schlecht, wenn man irgendwie einen global
00:23:26.830 --> 00:23:30.529
auf allen Geräten identischen Key hat, den
man dann da auch rauspopeln kann aus der
00:23:30.529 --> 00:23:34.230
Firmware. Damit kann man natürlich auch
die Kommunikation anderer Geräte
00:23:34.230 --> 00:23:39.299
entschlüsseln. Und das bringt uns dann
eigentlich zu dem entdeckten Security
00:23:39.299 --> 00:23:46.389
Problem. Und ich gebe zurück.
zivillian: Wie LaForge gerade schon sagte
00:23:46.389 --> 00:23:50.990
Das ist ein statischer Key, der für alle
Installationen genutzt wird. Das ist
00:23:50.990 --> 00:23:54.909
insofern ein bisschen kritisch, dass
jemand, der in der Lage ist, eine man-in-
00:23:54.909 --> 00:23:59.439
the-middle Attacke durchzuführen, die
Kommunikation entschlüsseln kann, mitlesen
00:23:59.439 --> 00:24:04.529
kann, potenziell manipulieren kann. Wir
haben uns dann überlegt Naja, wie kann man
00:24:04.529 --> 00:24:12.209
denn so eine man-in-the-middle Position
erreichen? Habe hier mal ein Foto. Danke
00:24:12.209 --> 00:24:14.590
roter Kreis.
Gelächter
00:24:14.590 --> 00:24:18.019
zivilian: Wir haben dann da noch ein
bisschen rangezoomt. Die hängt jetzt
00:24:18.019 --> 00:24:20.539
glücklicherweise relativ tief. Manchmal
werden diese Außen-Antennen noch deutlich
00:24:20.539 --> 00:24:24.369
höher angebracht, zum Beispiel an
Baumärkten. Da braucht man dann noch eine
00:24:24.369 --> 00:24:32.200
Leiter. Und naja, diese vier schwarzen
Punkte, das sind halt
00:24:32.200 --> 00:24:37.429
Kreuzschlitzschrauben. Und
Gelächter
00:24:37.429 --> 00:24:41.169
zivilian: Wenn man die dann aufschraubt,
dann ist da irgendwie ganz schön viel
00:24:41.169 --> 00:24:45.159
Platz. Und da ist so eine RJ45-Buchse. Da
geht doch was!
00:24:45.159 --> 00:24:56.603
Gelächter
Applaus
00:24:56.603 --> 00:25:01.179
Wenn man jetzt keine Motivation hat Nachts
im Dunkeln, draußen bei Regen am Baumarkt.
00:25:01.179 --> 00:25:04.679
Es gibt auch Indoor Geräte, die werden
ganz gerne zum Beispiel in Hotels
00:25:04.679 --> 00:25:13.220
eingesetzt. Die hängen dann da von der
Decke. Das Problem an der Stelle ist.
00:25:13.220 --> 00:25:18.340
Dieses Foto stammt aus einem Hotel in der
Nähe von Paris. Das ist also kein Problem,
00:25:18.340 --> 00:25:23.429
das nur in Deutschland besteht. Dass es
diese mitel-SIP-DECT Basen haben eine
00:25:23.429 --> 00:25:26.976
weltweite Installations-Basis. Die werden
überall eingesetzt, die werden in
00:25:26.976 --> 00:25:30.500
Größenordnungen eingesetzt, wo es nicht
nur darum geht, drei, vier, fünf Antennen
00:25:30.500 --> 00:25:35.070
zu haben, hauptsächlich in Konferenz,
Gebäuden, Veranstaltungsorten, was auch
00:25:35.070 --> 00:25:41.529
immer oder eben Hotels. Und das führte uns
dann zu der Überlegung. Okay, können wir
00:25:41.529 --> 00:25:47.559
so nicht lassen. Wenn wir das können,
können das auch andere. Und wir haben
00:25:47.559 --> 00:25:51.129
gelernt Responsible Disclosure. Man sagt
dem Hersteller vorher Bescheid und gibt
00:25:51.129 --> 00:25:55.779
ihm die Möglichkeit, das Problem zu lösen.
Deswegen haben wir auch ein wunderhübschen
00:25:55.779 --> 00:26:03.289
CVE bekommen. Die Frage ist Wie hat der
Hersteller darauf reagiert? Wir haben da,
00:26:03.289 --> 00:26:06.779
um das Transparent zu machen, einmal eine
kurze Timeline. Erste Kontaktversuche
00:26:06.779 --> 00:26:11.470
gab's Mitte/Anfang Oktober. Wir haben beim
Support von Mitel angerufen, weil wir auf
00:26:11.470 --> 00:26:15.470
der Webseite nur eine E-Mail-Adresse
gefunden hatten, die sehr generisch
00:26:15.470 --> 00:26:19.509
aussah. Haben uns da durch dieses Telefon-
menü durchgeklickt. Und hatten dann
00:26:19.509 --> 00:26:21.740
irgendwann einen Mitarbeiter am Apparat
und haben ihm erklärt, wir würden ganz
00:26:21.740 --> 00:26:27.451
gerne mit jemandem über Security bei SIP-
DECT reden. Die Antwort war SIP-DECT habe
00:26:27.451 --> 00:26:32.269
ich schon mal gehört, aber von Security
habe ich keine Ahnung. Wir haben dann als
00:26:32.269 --> 00:26:37.570
Alternative unseren, oder einen, Mitel
Partner kontaktiert, zu dem wir einen sehr
00:26:37.570 --> 00:26:40.499
guten Kontakt hatten, und haben ihm
gesagt, der Chaos Computer Club würde
00:26:40.499 --> 00:26:45.639
gerne Mitel Bescheid geben, bevor er einen
Vortrag hält. Das war am 11.10.. Das ist
00:26:45.639 --> 00:26:50.960
ein Freitag. Am 14.10 hatten wir eine
E-Mail von dem Produktmanager Wireless,
00:26:50.960 --> 00:26:55.730
der doch mal um ein Gespräch bzw. einen
vorort Termin bat. Dieser vorort Termin
00:26:55.730 --> 00:26:59.309
hat eine Woche später stattgefunden, und
wir haben mit dieser Aufbau Installation,
00:26:59.309 --> 00:27:02.450
die ja auch auf dem Tisch liegt,
präsentiert, was wir gemacht haben, wie
00:27:02.450 --> 00:27:07.730
das aussieht und wo das Sicherheitsproblem
aus unserer Sicht ist. Wir haben uns
00:27:07.730 --> 00:27:11.759
darüber unterhalten, wie man das Problem
lösen kann, haben erklärt, relativ
00:27:11.759 --> 00:27:17.049
umfangreich erklären müssen, was
Eventphone ist. Und haben dann abgewartet
00:27:17.049 --> 00:27:21.391
und einen Monat später nachgefragt und
hatten dann die Zusage bekommen. Ja, wir
00:27:21.391 --> 00:27:25.109
haben eine Lösung. Wir testen die gerade
noch im Lab. Aber es wird ein Update gegen
00:27:25.109 --> 00:27:28.050
bis zum Congress, sodass unsere
Installation von diesem Problem nicht mehr
00:27:28.050 --> 00:27:34.000
betroffen ist. Ein Tag später haben wir
uns dann vor Ort getroffen und den
00:27:34.000 --> 00:27:38.769
Lösungsansatz besprochen. Und der
Lösungsansatz war: Ihr kriegt eine Custom-
00:27:38.769 --> 00:27:42.460
Firmware. Die hat einen anderen Blowfish-
Key.
00:27:42.460 --> 00:27:52.009
Gelächter und Applaus
Das hat uns natürlich nicht gefallen, wir
00:27:52.009 --> 00:27:56.909
haben uns intensiv Gedanken gemacht, eine
Woche später unseren eigenen Lösungsansatz
00:27:56.909 --> 00:28:01.370
übermittelt und haben dann kurz vor
Weihnachten die Zusage bekommen: Okay, wir
00:28:01.370 --> 00:28:04.909
haben uns beeilt, ihr kriegt ein
ordentliches Update aber erst in Q1 2020.
00:28:04.909 --> 00:28:10.429
Da haben wir gesagt: Na gut, dann relesen
wir unser Tooling nicht, aber wird schon
00:28:10.429 --> 00:28:15.519
irgendwie gehen. Und am 20. 12., einen Tag
später, gabs einen Anruf. Ja, nee, das
00:28:15.519 --> 00:28:20.159
kommt doch bis zum Vortrag. Das Product
Security Incident Response Team aus Kanada
00:28:20.159 --> 00:28:23.770
hat sich eingeschaltet, und augenscheinlich
ist das Problem größer als erwartet.
00:28:23.770 --> 00:28:26.622
Gelächter
00:28:26.622 --> 00:28:31.850
Seit zwei Tagen ist das Update verfügbar.
Wie vorhin schon gesagt im Download Center
00:28:31.850 --> 00:28:37.180
von Mitel, nachdem man Zugangsdaten
eingegeben hat, die wir nicht haben. Es
00:28:37.180 --> 00:28:42.789
gibt auch einen Security Advisory auf der
Webseite. Und wir haben dem Hersteller
00:28:42.789 --> 00:28:46.600
gesagt, oder möchten dem Hersteller die
Möglichkeit gegeben, dass er auch die
00:28:46.600 --> 00:28:51.519
Sicht aus... Die Dinge aus seiner
Sicht einmal darstellen kann.
00:28:51.519 --> 00:28:56.679
Deswegen haben wir zwei Folien von Mitel.
Bitte nicht blenden lassen, die sind sehr
00:28:56.679 --> 00:29:03.580
hell. Hab ich den ausgemacht?
ST: Es gibt nen Krassen Hack.
00:29:03.580 --> 00:29:11.229
Gelächter
zivillian: Na gut. Aus Sicht von Mitel
00:29:11.229 --> 00:29:16.520
tritt das Problem halt nur auf, wenn man
eine man-in-the-middle Position erhält und
00:29:16.520 --> 00:29:22.299
das ist ja in Firmen-Netzwerken sehr
schwer möglich. Und hier auch nochmal Das
00:29:22.299 --> 00:29:25.549
Update IST verfügbar, das kann
heruntergeladen werden. Sind auch nochmal
00:29:25.549 --> 00:29:31.559
die Download Links und der Link auf das
Security Advisory. Für die Leute, die kein
00:29:31.559 --> 00:29:37.130
Englisch verstehen, gibt's das ganze auch
nochmal in Deutsch. Und bei Fragen soll
00:29:37.130 --> 00:29:41.489
man sich an den Support von Mitel wenden
bzw. an den technischen Support der Mitel
00:29:41.489 --> 00:29:45.729
Partner.
ST: Trotzdem muss man sagen In unter 90
00:29:45.729 --> 00:29:51.320
Tagen von Reporten bis Bugfix ist für so
einen großen Konzern, schon mal so
00:29:51.320 --> 00:29:53.779
schlecht nicht, das haben wir schon
schlechter gesehen.
00:29:53.779 --> 00:30:07.330
Applaus
zivillian: Ja, Geht wieder? Genau am Anfang
00:30:07.330 --> 00:30:12.190
hatte ST schon erwähnt rfpproxy, was ist
das? Das ist halt ein transparenter, zwei
00:30:12.190 --> 00:30:18.070
Wege Verschlüsselung, Entschlüsselung,
Maschine-in-the-middle Proxy. Warum? Naja,
00:30:18.070 --> 00:30:22.869
wenn schon man-in-the-middle, dann
richtig. Der kann halt sämtliche
00:30:22.869 --> 00:30:26.159
Kommunikation verschlüsseln,
entschlüsseln. Der kümmert sich um das Re-
00:30:26.159 --> 00:30:29.809
keying was in diesem Protokoll noch mit
drin ist, da werden regelmäßig die
00:30:29.809 --> 00:30:34.549
Blowfish-keys ausgetauscht. Der bietet
eine Möglichkeit, selektiv Nachrichten zu
00:30:34.549 --> 00:30:38.659
manipulieren. Man kann Nachrichten
unterdrücken, man kann eigene Nachrichten
00:30:38.659 --> 00:30:44.700
einschleusen und um die Stabilität unserer
Anlage insbesondere auf diesem Event nicht
00:30:44.700 --> 00:30:48.379
zu gefährden, findet sämtliche
Verarbeitungen, also das eigentliche
00:30:48.379 --> 00:30:54.399
Verändern der Kommunikation, extern statt.
Um euch das zu veranschaulichen, so sieht
00:30:54.399 --> 00:31:00.809
das normalerweise aus. Man hat halt die
Antenne die redet per TCP auf Port 12621
00:31:00.809 --> 00:31:05.419
mit dem OMM. Wir haben halt auf unserer
Installation neben dem OMM noch den
00:31:05.419 --> 00:31:09.070
rfpproxy laufen. Der lauscht auf einem
anderen Port. Gibt es so eine kleine
00:31:09.070 --> 00:31:14.749
iptables Regel und ip Transparent Proxy.
Und dann ist da auf einmal der Proxy
00:31:14.749 --> 00:31:18.789
dazwischen, und der reicht dann bei Bedarf
die Kommunikation über einen Sockel wieder
00:31:18.789 --> 00:31:23.039
raus und man kann kleine Tools da
dranhängen. Hier beispielhaft Motorola,
00:31:23.039 --> 00:31:27.129
ein Loggingtool, was auch ".pcap"
schreiben kann in dem Format, was da noch
00:31:27.129 --> 00:31:31.729
Richtung Baseband-Management Controller
gesprochen wird, also in der Antenne. Man
00:31:31.729 --> 00:31:37.919
kann Audio Verarbeitungen damit
manipulieren oder die LEDs steuern. An der
00:31:37.919 --> 00:31:46.080
Stelle zur Klarstellung noch mal diese
Antennen sind dumm. Sämtliche DECT
00:31:46.080 --> 00:31:49.740
spezifische Verarbeitungen, was nicht
Audio ist, also der gesamte DECT Protokoll
00:31:49.740 --> 00:31:54.700
Stack läuft im OMM. Und die Antennen sind
so dumm, die wissen noch nicht einmal, wie
00:31:54.700 --> 00:32:03.389
sie ihre eigenen LEDs anmachen. Ja, wenn
man diesen Proxy jetzt benutzen möchte,
00:32:03.389 --> 00:32:07.249
dann hat man immer noch das Problem, dass
er da nicht nur der spezifizierte DECT-Standard
00:32:07.249 --> 00:32:10.499
drüber gesprochen wird, sondern
auch die proprietären Hersteller
00:32:10.499 --> 00:32:15.809
spezifischen Informationen wie z.B.: wie
steuert man LEDs? Da gab es einen relativ
00:32:15.809 --> 00:32:19.169
hohen reverse-Engineering Aufwand, um das
mit den Logdateien und dem Tracing zu
00:32:19.169 --> 00:32:24.340
korrelieren. Dafür braucht man Daten. Da
darf ST noch mal dran.
00:32:24.340 --> 00:32:32.590
ST: Wie haben wir jetzt diese Daten
bekommen? Mein Kollege Zuckerberg und ich
00:32:32.590 --> 00:32:38.929
sagen da immer, woher Daten nehmen ohne
die User zu beklauen. Wir haben das ernst
00:32:38.929 --> 00:32:43.299
genommen und haben gedacht Ja, wenn wir
jetzt auf irgendeinem Event einfach mal
00:32:43.299 --> 00:32:47.970
Daten mitschneiden und die auswerten, dann
werden wir hier geteert und gefedert.
00:32:47.970 --> 00:32:53.029
Deswegen haben wir das einfach mal
transparent gemacht. Wer von euch war auf
00:32:53.029 --> 00:32:58.809
dem letzten EsterHegg 2019? Ok, wenige.
Dann erkläre ich das mal, vor dem
00:32:58.809 --> 00:33:02.359
EsterHegg haben wir einen Blogeintrag
geschrieben, dass wir Metadaten erheben
00:33:02.359 --> 00:33:07.780
wollen. Dass wir im Prinzip alle Daten,
die irgendwas mit den Geräten und der
00:33:07.780 --> 00:33:12.700
Kommunikation zu tun haben, außer die
Sprache mitschneiden wollen bei den DECT-
00:33:12.700 --> 00:33:17.239
Geräten. Man musste das im GURU, wenn man
sich eine Nebenstelle für das EsterHegg
00:33:17.239 --> 00:33:21.440
geklickt hat, noch einmal bestätigen. Es
war auch sehr unangenehm, weil wir einfach
00:33:21.440 --> 00:33:26.179
wollten, dass es jeder mitbekommt. Und Wir
haben auch ehrlich damit gerechnet, dass
00:33:26.179 --> 00:33:30.230
da irgendein Shitstorm gibt, wenn wir da
sagen Ja, wir speichern da alles. Dass da
00:33:30.230 --> 00:33:35.729
irgendwer sagt: ne, macht das mal nicht.
Wir haben aber eben im Vorfeld ganz genau
00:33:35.729 --> 00:33:39.410
aufgeschrieben wozu und warum. Und
offensichtlich haben wir es geschafft, den
00:33:39.410 --> 00:33:44.720
Leuten zu erklären, dass es dazu ist, um
die Daten später zu analysieren und dann
00:33:44.720 --> 00:33:48.720
Fehler zu finden oder Unregelmäßigkeiten
zu finden. Wir haben ja selbst nicht
00:33:48.720 --> 00:33:52.590
gewusst, wonach wir eigentlich suchen. Wir
haben halt erst mal irgendwie diese
00:33:52.590 --> 00:33:59.190
Müllhalde voll gemacht um dann da drin
herum zu schnüffeln. Und mit dieser Taktik
00:33:59.190 --> 00:34:03.259
hat das dann funktioniert. Es gab auch
eine Alternative: Man konnte sich SIP-
00:34:03.259 --> 00:34:07.960
Nebenstellen, klicken, mit denen man
sozusagen von SIP zu SIP telefonieren
00:34:07.960 --> 00:34:14.200
konnte. Da hätten wir dann keine
Metadaten erhoben. Aber das hat total gut
00:34:14.200 --> 00:34:17.880
funktioniert. Wir haben das auch insofern
transparent gemacht. Wir haben alle Daten,
00:34:17.880 --> 00:34:22.200
die wir nochmal extra gespeichert haben,
oder diese die Daten haben wir extra
00:34:22.200 --> 00:34:26.310
nochmal gesichert, und verschlüsselt auf
den verschlüsselten Filesystemen
00:34:26.310 --> 00:34:31.980
gespeichert. Es hatten auch nur ganz
wenige Leute Zugriff vom POC da über haupt
00:34:31.980 --> 00:34:35.290
darauf. Das war alles ganz genau
reglementiert. Wir sind also im Prinzip so
00:34:35.290 --> 00:34:41.240
rangegangen, wie wir uns das vorstellen
würden, wenn man mit unseren Daten umgeht.
00:34:41.240 --> 00:34:46.761
Und dann, Am Ende haben wir uns natürlich
auch Gedanken darüber gemacht: wie werden
00:34:46.761 --> 00:34:55.270
wir die jetzt wieder los? Und auch da war
unsere große maximale Transparenz.
00:34:55.270 --> 00:35:00.980
Vielleicht hat das auf dem Camp der eine
oder andere mitbekommen. Wir haben das
00:35:00.980 --> 00:35:05.500
auch in ein Video gegossen. Wir können das
leider nicht abspielen, weil es gibt ja so
00:35:05.500 --> 00:35:11.560
Verwertungsgesellschaften. Deswegen hier
nur ein Screenshot und ein QR-Code. Es gab
00:35:11.560 --> 00:35:16.060
auf jeden Fall bei den Daten
Vier-Augen-Prinzip. Bei allem Spaß. Ich bin
00:35:16.060 --> 00:35:19.990
auch tatsächlich Datenschutzbeauftragter,
betrieblicher, und hab mir alles genau
00:35:19.990 --> 00:35:24.950
angeguckt und auch mit den Entwicklern
zusammen die Daten mit dem oder nach dem
00:35:24.950 --> 00:35:28.670
Vier-Augen-Prinzip gelöscht. Was uns heute
auch ein bisschen auf die Füße gefallen
00:35:28.670 --> 00:35:31.400
ist, weil wir wollten noch ein paar
statistische Daten hinterher schmeißen.
00:35:31.400 --> 00:35:34.590
Aber wir haben halt einfach schlicht
nichts mehr davon. Wir können nicht mal
00:35:34.590 --> 00:35:40.699
mehr sagen, wie viele Daten das waren und
wie groß die waren. Ja so ist das. Aber
00:35:40.699 --> 00:35:44.240
ich glaube, das ist nicht besonders
schlimm. Deswegen nocheinmal Vielen Dank
00:35:44.240 --> 00:35:48.330
auch an alle User, die das Spiel auf dem
EsterHegg mitgemacht haben. Das hat uns
00:35:48.330 --> 00:35:53.530
sehr, sehr viel geholfen und war richtig
richtig informativ. Wir konnten dann
00:35:53.530 --> 00:35:58.400
nämlich auch ganz tolle neue Features
daraus bauen, weil wir das eben anhand
00:35:58.400 --> 00:36:08.809
dieser Daten analysieren konnten. Und das
erste tolle Feature zeigt uns zivillian.
00:36:08.809 --> 00:36:10.691
zivillian: Genau ich hatte ja gerade schon
gesagt die Antennen können nichtmal ihre
00:36:10.691 --> 00:36:15.260
eigenen LEDs steurern. Das heißt in diesem
Protokolll gibt es eine SysLED-Nachricht,
00:36:15.260 --> 00:36:19.961
die diese vier verschiedenen LEDs die an
so einer Antenne dran sind, zentral ein-
00:36:19.961 --> 00:36:24.120
und ausschaltet, gibts verschiedene
Patterns, in denen die blicken können. Uns
00:36:24.120 --> 00:36:29.190
ist aufgefallen, dass eine Pattern, wenn
man die dritte LED rot-grün blinken lässt.
00:36:29.190 --> 00:36:36.740
Legst einfach aufs aufbau DECT. Wenn man
die dritte LED rot-grün blinken lässt,
00:36:36.740 --> 00:36:40.280
dann blinkt die nicht nur, sondern das
setzt auch noch das Busy-bit im BNC-
00:36:40.280 --> 00:36:44.901
Controller. Damit verweigert die Antenne
jegliche DECT Kommunikation, also über die
00:36:44.901 --> 00:36:49.870
Lampe wird da auch Funktionalität
gesteuert. Die vierte LED ist
00:36:49.870 --> 00:36:54.170
normalerweise fürs WLAN. Das dürfen wir
hier nicht, weil da würde uns das NOC
00:36:54.170 --> 00:36:57.120
hauen, deswegen ist die vierte
LED überall aus auf dem Event.
00:36:57.120 --> 00:37:00.950
ST: ja. Aber warum blinkt die denn?
zivillian: Die blinkt, weil in diesem
00:37:00.950 --> 00:37:09.570
Aufbau DECT ein Tool von uns läuft, was
morsen kann, weil wir brauchen die ja nicht.
00:37:09.570 --> 00:37:16.690
Applaus
00:37:16.690 --> 00:37:20.850
zivilian: Ihr könnt ja mal schauen
Irgendwo auf der Veranstaltung wird sicher
00:37:20.850 --> 00:37:24.330
auch noch ein paar blinkende LEDs geben.
Das einzige Problem ist Sie können nur mit
00:37:24.330 --> 00:37:30.810
einem Herz blinken. Ihr müsst also ein
bisschen Zeit mitbringen. Magst du wieder
00:37:30.810 --> 00:37:38.090
auf die Folien schallten? Genau eine
zweite interessante Nachricht, die wir
00:37:38.090 --> 00:37:41.050
gefunden haben, ist Mediatone. Wenn ihr
den Hörer abnehmt, hört ihr ja
00:37:41.050 --> 00:37:44.460
normalerweise so ein Freizeichen bzw. Wenn
euer Gesprächspartner fertig ist und
00:37:44.460 --> 00:37:49.270
auflegt, dann hört ihr schon ein hübsches
Tuten. Das wird direkt in den Antennen
00:37:49.270 --> 00:37:51.800
generiert. Dafür gibt's eine eigene
Nachricht, die da hingeschickt wird, die
00:37:51.800 --> 00:37:56.060
sagt: bitte spiel mal folgende Frequenzen
parallel in folgender Reihenfolge so und
00:37:56.060 --> 00:38:02.950
so lange. Dieses Protokoll kann bis zu 256
Einträge. Dieses Protokoll kann bis zu
00:38:02.950 --> 00:38:09.110
vier Töne gleichzeitig. Dieses Protokoll
kann Schleifen. Wir dachten uns, naja
00:38:09.110 --> 00:38:12.910
warum nur so langweilige Töne? Also gibt
es jetzt einen MIDI Konverter, der Midi
00:38:12.910 --> 00:38:16.920
Files nach Antenne konvertieren kann. Das
möchte ich gern einmal vorführen.
00:38:16.920 --> 00:38:25.950
Applaus
ST: Das ist nicht meins.
00:38:25.950 --> 00:38:29.260
zivillian: Das ist meins. Wähl doch mal
die 4502!
00:38:29.260 --> 00:38:36.050
ST: Lieber Mann vom Audio kannst du mich
mal Muten, bitte?
00:38:36.050 --> 00:38:40.920
zivilian: Ah, es klingelt.
ST (durch DECT) Hallo?
00:38:40.920 --> 00:38:44.590
zivilian: hört ihr das?
ST (DECT): Ja, Test Test.
00:38:44.590 --> 00:38:46.470
zivilian: sehr schön.
unverständlich
00:38:46.470 --> 00:38:50.690
Brummen
zivilian: Da bist du wohl zu weit weg.
00:38:50.690 --> 00:38:53.670
ST(DECT): Oh entschuldigung!
zivilian: Ja die Reichweite ist ein
00:38:53.670 --> 00:38:56.080
bisschen begrenzt. So dann mach doch mal
Tetris an.
00:38:56.080 --> 00:39:00.800
ST(DECT): Ja also wir haben ja eine ganz
normale Telefonverbindung. Das hört man
00:39:00.800 --> 00:39:04.940
jetzt. Und Jetzt tippe ich mal Tetris.
Moment.
00:39:04.940 --> 00:39:12.585
DipDupDipDopDop
leises Gelächter
00:39:12.585 --> 00:39:15.560
zivilian: fehlt da nicht noch einer?
ST(DECT): Haben wir vorhin doch getestet.
00:39:15.560 --> 00:39:17.915
Jetzt.
Dop
00:39:17.915 --> 00:39:21.210
ST: Geil. Richtig Gutes Zeug, warte.
lachen aus dem Publikum
00:39:21.210 --> 00:39:31.340
DipDupDipDapDapDap
Tetris Melodie aus dem DECT
00:39:31.340 --> 00:39:43.430
Applaus
zivillian: Ja, ihr habt das Telefon von ST
00:39:43.430 --> 00:39:50.920
gerade schon gesehen. Das ist ein
wunderhübsches Motorola S120x, irgendwas 1
00:39:50.920 --> 00:39:55.260
bis 4 hintendran steht für die Anzahl der
Geräte, die in der Schachtel sind. Warum
00:39:55.260 --> 00:40:00.400
dieses? Naja, das ist halt das billigste
Gerät, wenn man nach DECT sucht. Es ist
00:40:00.400 --> 00:40:05.940
bunt, also das ist orange. Das gibts aber
auch in Türkis, in Rosa, in Grün. Laut
00:40:05.940 --> 00:40:09.220
Hersteller, wie man auf der rechten Seite
sieht, ist es GAP kompatibel. Das ist
00:40:09.220 --> 00:40:11.870
immer ein wichtiges Feature.
ST: Und GAP-Kompatibilität erreicht man
00:40:11.870 --> 00:40:14.770
übrigens nicht, indem man es nur auf die
Schachtes schreibt.
00:40:14.770 --> 00:40:18.660
Gelächter
zivillian: Und das beste Feature von dem
00:40:18.660 --> 00:40:22.280
Telefon Es lässt sich nicht anmelden. Wir
hatten auf vielen Veranstaltungen auf dem
00:40:22.280 --> 00:40:25.680
EasterHegg auf dem letzten Kongress immer
wieder Leute, die sich gerade neu dieses
00:40:25.680 --> 00:40:29.680
Telefon nur für uns gekauft haben und sehr
traurig waren, dass es nicht funktioniert.
00:40:29.680 --> 00:40:34.490
Wir haben nicht mehr viel Zeit. Wir
versuchen es aber. Mit dem Proxy konnten
00:40:34.490 --> 00:40:40.420
wir da mitlesen. Wie redet denn das
Telefon mit dem OMM? Und wenn man so ein
00:40:40.420 --> 00:40:44.300
Telefon anmeldet, dann muss man die Pin
eingeben, und ganz am Ende gibts dann eine
00:40:44.300 --> 00:40:48.610
AccessRightsAccept Nachricht. Und da
kriegt das Telefon dann seine UserIdentity
00:40:48.610 --> 00:40:52.920
zugewiesen. Die endet hier auf "df". Und
wenn das Telefon dann telefonieren möchte,
00:40:52.920 --> 00:40:57.670
dann sagt es. Ich bin übrigens dieses
Telefon, und dann schickt es die IPUI mit.
00:40:57.670 --> 00:41:04.260
Die endet nicht mehr auf "df". Und die
Antwort darauf ist: IPUI not Accepted. Im
00:41:04.260 --> 00:41:10.100
ETSI Standard oder bzw. in dem GAP
Standard ist definiert Requirement N. 18:
00:41:10.100 --> 00:41:14.820
So und so hat die Anmeldung abzulaufen.
Das verweist wiederum auf den DECT
00:41:14.820 --> 00:41:18.000
Standard, in dem steht: wenn da so eine
"Acces-Rights-Accept" Nachricht kommt,
00:41:18.000 --> 00:41:21.700
dann soll das Telefon das abspeichern. Das
tut es wahrscheinlich auch, weil da steht
00:41:21.700 --> 00:41:25.970
nichts von wieder mitsenden. Aber keine
Ahnung. Und da ist definiert, dass so eine
00:41:25.970 --> 00:41:29.610
IPUI bis zu 60 Bit lang sein darf. Das,
was wir da gerade gesehen haben, waren in
00:41:29.610 --> 00:41:35.820
dem Rahmen. Diese IPUI-O hat vorne vier
Bit "Portable User Type" dran stehen, dass
00:41:35.820 --> 00:41:41.020
es halt eine IPUI-O ist. Und danach kommen
bis zu 60 Bit "Portabel User Number". Wir
00:41:41.020 --> 00:41:44.900
haben ja die IPUI nochmal farblich
aufbereitet. Hintendran das "df", Das ist
00:41:44.900 --> 00:41:49.920
das, was gerade eben verloren gegangen
ist. Und Mitel hat eine Besonderheit, die
00:41:49.920 --> 00:41:54.870
nutzen für diese User Identity einfach die
IPEI, also die Seriennummer von dem Gerät
00:41:54.870 --> 00:42:01.140
wieder. Und sagen dem Telefon, Du bist
immer noch du. Und die IPEI hat eine Länge
00:42:01.140 --> 00:42:05.150
von 36 bit, das ist definiert. Und wenn man
sich das hier anschaut, dann gibt's da
00:42:05.150 --> 00:42:10.490
vorne so 4 bit, oder diese beiden roten
Nullen, die definitiv nicht genutzt
00:42:10.490 --> 00:42:14.070
werden, zumindest nicht an einer Mitel
SIP-DECT Anlage. Und daher kam dann auch
00:42:14.070 --> 00:42:22.740
der Lösungsansatz, dieses Telefon
kompatibel zu machen. Wir verschieben
00:42:22.740 --> 00:42:26.910
einfach die relevanten Daten um, ein Byte
nach vorne in Richtung Telefon und wenn
00:42:26.910 --> 00:42:30.540
sich das Telefon meldet, dann schieben wir
sie einfach wieder zurück. Und dann ist
00:42:30.540 --> 00:42:34.770
der OMM glücklich. Und deswegen
funktionieren seit diesem Jahr auch diese
00:42:34.770 --> 00:42:46.990
Telefone an unserer Anlage.
Applaus
00:42:46.990 --> 00:42:52.340
zivilian: Und auf dem Event haben wir dann
festgestellt, nein anderesherum. Wir
00:42:52.340 --> 00:42:55.460
verschieben die Sachen, um sicherzugehen,
dass es nur diese Telefone betrifft,
00:42:55.460 --> 00:42:58.560
nutzen wir den Hersteller Code, der bei
der IPEI vorne dran steht, um diese
00:42:58.560 --> 00:43:02.890
Telefone zu identifizieren. Das heißt, wir
müssen das für jedes Telefon, was diese
00:43:02.890 --> 00:43:07.170
Fehler hat, individuell anschalten. Aber
stellen damit sicher, dass wir nicht nicht
00:43:07.170 --> 00:43:10.571
so viel kaputtmachen. Wir haben an der
Stelle natürlich auch den Hersteller
00:43:10.571 --> 00:43:15.190
informiert. Ende September haben wir alle
Informationen per Mail geschickt. Die
00:43:15.190 --> 00:43:19.920
haben das nach China weitergeleitet. Wir
haben einen Monat später nachgefragt.
00:43:19.920 --> 00:43:24.760
Wir haben nichts gehört. Vielleicht passiert
noch etwas. Auf dem Event, da wir dann
00:43:24.760 --> 00:43:30.410
leider feststellen müssen, dass dieses
Telefon nicht das einzige ist. Wir haben
00:43:30.410 --> 00:43:34.600
dann die Liste der Hersteller, Präfixe,
die auf der Whitelist stehen, deutlich
00:43:34.600 --> 00:43:38.970
erweitern müssen, damit auch die T-Sinus
Telefone funktionieren, damit das Belgacom
00:43:38.970 --> 00:43:48.157
Telefon funktioniert. Also Wir haben da so
um die 20 Geräte inzwischen.
00:43:48.157 --> 00:43:53.630
ST: Audio Visuelles Marketing, mit
Marketing haben Sie es ja nicht so. Aber
00:43:53.630 --> 00:43:56.960
vielleicht haben Sie was mit Ihren
Telefonen?
00:43:56.960 --> 00:44:00.370
zivilian: Ja, wer unseren Blog liest. Wir
hatten das letztes Jahr schon Ende letzten
00:44:00.370 --> 00:44:04.900
Jahres. Das Problem mit dem AVM Telefon,
weswegen wir auch immer von FritzFon
00:44:04.900 --> 00:44:09.780
abgeraten haben. An unserer Anlage wurde
nicht angezeigt, wer anruft. Es stand
00:44:09.780 --> 00:44:13.780
immer nur intern. Wir haben das im Blog im
Detail beschrieben. Aber da wir jetzt die
00:44:13.780 --> 00:44:17.640
Nachrichten nicht nur mitlesen, sondern
auch manipulieren können. Naja, flippen
00:44:17.640 --> 00:44:22.280
wir halt ein Bit, und dann steht da, wer
es ist.
00:44:22.280 --> 00:44:31.240
Gelächter und Applaus
zivilian: Wir haben ja noch was Positives
00:44:31.240 --> 00:44:35.130
zu AVM. Wir haben uns eine Fritzbox
gekauft und waren sehr glücklich, weil die
00:44:35.130 --> 00:44:40.330
Fritzbox kann nicht nur TCPdump, sondern
die Fritzbox kann auch DTrace. Das D steht
00:44:40.330 --> 00:44:44.510
für DECT. Unter der URL die da auch
angegeben ist, findet ihr in jeder
00:44:44.510 --> 00:44:48.542
handelsüblichen Fritzbox dieses Capture
Interface. Da gibts dann ganz am Ende den
00:44:48.542 --> 00:44:53.030
Eintrag. Und das Spannende ist: Die
Gigaset Telefone können an einer Fritzbox
00:44:53.030 --> 00:44:57.980
das Telefonbuch anzeigen. Das geht an
unserer Anlage noch nicht, und wir haben
00:44:57.980 --> 00:45:07.443
ein wenig die Hoffnung, dass wir das
ändern können.
00:45:07.443 --> 00:45:10.990
ST: Ausblick.
zivillian: Was machen wir damit? Unser
00:45:10.990 --> 00:45:15.770
Wunsch wäre Leute, die sich für DECT
interessieren, Leute, die Interesse an
00:45:15.770 --> 00:45:19.970
einer Mitel Installation haben, die sich
auch damit beschäftigen, dass wir nicht
00:45:19.970 --> 00:45:25.300
die einzigen sind. Wir hoffen, dass ihr
mit den Informationen loslegen könnt. Wir
00:45:25.300 --> 00:45:29.740
würden uns freuen, wenn der Wireshark
Dissector den LaForge angesprochen hat,
00:45:29.740 --> 00:45:32.340
weiterentwickelt wird, weil der würde uns
auf jeden Fall helfen, dort tiefer ins
00:45:32.340 --> 00:45:38.720
Detail zu gehen. Spielt mit der Hardware
spielt mit der Software! Und ich, Du hast
00:45:38.720 --> 00:45:40.720
noch was?
ST: Ja ich hab noch was, und hier DECT
00:45:40.720 --> 00:45:44.510
ULE, wir hatten es vorhin auch von LaForge
gehört. Kann man auch mal genauer drauf
00:45:44.510 --> 00:45:53.470
guchen. Wir haben auch gehört es gibt EC-
Terminals die über DECT funktionieren. Und
00:45:53.470 --> 00:46:00.690
unsere Bitte, wir sammeln immernoch Daten,
und das hatten wir auch auf dem EsterHegg
00:46:00.690 --> 00:46:05.660
schon mal angesprochen. Hier nochmal in
großer Runde. Crowdsourcing ist das
00:46:05.660 --> 00:46:11.520
Stichwort. Wenn ihr wisst, was ihr für ein
DECT Telefon habt und was für ein Modell,
00:46:11.520 --> 00:46:17.680
und uns das verraten wollt, dann könnt ihr
das im GURU eintragen. Daswürde uns extrem
00:46:17.680 --> 00:46:23.430
helfen, weil nämlich wir bei der ETSI nach
dieser sogenannten EMC Liste nachgefragt
00:46:23.430 --> 00:46:30.390
haben Equipment Manufacturers Code,
sozusagen das was ich kursiv auf dieser
00:46:30.390 --> 00:46:33.750
Folie dargestellt hatte, Woran man
erkennen kann, welcher Hersteller es ist.
00:46:33.750 --> 00:46:40.227
Und da war die Antwort: die ist geheim.
Gelächter
00:46:40.227 --> 00:46:44.440
ST: Also es wäre total super, wenn Ihr
euer Modell da eintragt, das hilft uns
00:46:44.440 --> 00:46:47.550
extrem, weil dann können wir das auch
zuordnen. Im Zweifelsfall, wenn wir Fehler
00:46:47.550 --> 00:46:51.750
haben. Genau und wenn ihr das, das war im
Prinzip alles, was wir von euch noch
00:46:51.750 --> 00:46:57.632
wollen. Und wir können da im Prinzip nur
sagen Viele Dank! Und du hast auch noch
00:46:57.632 --> 00:47:00.930
was?
LaForge: vielleicht zum Proxy, wegen
00:47:00.930 --> 00:47:04.070
veröffentlichen und so weiter. Soll ich
dazu noch was sagen?
00:47:04.070 --> 00:47:06.503
ST: Ach so richtig, ja, der Proxy, der ist
noch nicht veröffentlicht. Magst du noch
00:47:06.503 --> 00:47:09.890
was sagen, warum wir das nicht
veröffentlichen?
00:47:09.890 --> 00:47:12.480
zivillian: Ich hatte das ja in der
Timeline schon dargestellt. Wir haben
00:47:12.480 --> 00:47:16.870
sehr, sehr kurzfristig die Zusage
bekommen, dass der Fehler behoben wird.
00:47:16.870 --> 00:47:20.210
Wir fanden es unverantwortlich, unser
Tooling zu veröffentlichen, nicht nur,
00:47:20.210 --> 00:47:23.410
weil dann unsere Anlage betroffen ist,
sondern weil es irgendwie mit zwei zeilen
00:47:23.410 --> 00:47:27.080
Code möglich wäre, jede SIP-DECT
Installation weltweit zu kompromittieren.
00:47:27.080 --> 00:47:32.230
Wir sind in Abstimmung mit dem Hersteller.
Wir wollen das Tooling veröffentlichen. Wir
00:47:32.230 --> 00:47:34.220
wollen euch das zur Verfügung stellen,
sodass ihr auch selber reinschauen könnt,
00:47:34.220 --> 00:47:38.950
wenn ihr so eine SIP-DECT Installation
habt. Der aktuelle Plan ist, dass im
00:47:38.950 --> 00:47:44.080
ersten Quartal nächsten Jahres zu machen.
Sobald die bestehenden Installationen die
00:47:44.080 --> 00:48:00.460
Chance hatten, das Update einzuspielen.
Applaus
00:48:00.460 --> 00:48:02.720
Herald: Vielen, Vielen Dank, für die
schöne Präsentation, ich bin mir sicher,
00:48:02.720 --> 00:48:07.490
dass ihr Lust habt, mit uns noch ein wenig
zu diskutieren. Ich schau mal, ob ich
00:48:07.490 --> 00:48:13.151
schon Fragen hier sehe. Wir haben Mikros
aufgestellt im Saal, die eins, die zwei und die
00:48:13.151 --> 00:48:18.020
drei stellt euch da einfach dran, und wir
haben auch Fragen aus dem Internet. Aber
00:48:18.020 --> 00:48:21.650
wir fangen sofort hier mit der zwei an.
Deine Frage bitte.
00:48:21.650 --> 00:48:27.320
Frage: Ihr habt gesagt, es gab erst ein
Update von Mitel und das habt ihr
00:48:27.320 --> 00:48:31.930
beanstandet. Und dann wurde gesagt es gibt
eine bessere Lösung. Was ist denn jetzt
00:48:31.930 --> 00:48:33.930
die bessere Lösung? Wie wird der Key denn
jetzt generiert?
00:48:33.930 --> 00:48:39.570
zivilian: Die Antennen müssen initial
einmal mit der Installation gekoppelt
00:48:39.570 --> 00:48:45.080
werden. Der Vorgang nennt sich Capture.
Die Annahme, die wir getroffen haben, ist,
00:48:45.080 --> 00:48:48.250
dass dieser Vorgang in einer
vertrauenswürdigen Umgebung stattfindet.
00:48:48.250 --> 00:48:52.470
Und im Rahmen dieses Capture Vorgangs wird
individuelles Schlüssel Material zwischen
00:48:52.470 --> 00:48:56.530
dem OMM und der Antenne ausgehandelt und
für die weitere Kommunikation genutzt. Das
00:48:56.530 --> 00:48:59.700
heißt, jede DECT Antenne hat einen eigenen
Blowfish-Key.
00:48:59.700 --> 00:49:06.760
Herald: Da machen wir die Frage von meinem
Signal Angel, also aus dem Internet.
00:49:06.760 --> 00:49:10.740
Signal-Angel: Wussten die Leute vom Baumarkt,
dass da an der Außenantenne gebastelt
00:49:10.740 --> 00:49:14.990
wurde.
zivilian: Das könnte auch gephotoshopt
00:49:14.990 --> 00:49:19.661
gewesen sein. Ich kann das weder
bestätigen noch verneinen.
00:49:19.661 --> 00:49:29.210
Applaus
Herald: Die 2 bitte.
00:49:29.210 --> 00:49:33.480
Frage: Euren Tetris Hack da kann man den
nutzen, um zum Beispiel bei den eigenen
00:49:33.480 --> 00:49:37.060
Extensions eine eigene MIDI-Melodie zu
setzen. Das heißt, wenn ich jemanden
00:49:37.060 --> 00:49:42.337
anrufe wird der zumbeispiel gerickrolled?
zivilian: ich glaube rickroll, wär zu
00:49:42.337 --> 00:49:48.250
lang, weil 256 Töne ist das Limit. Das
Hauptproblem ist, dass die 256 Töne nur
00:49:48.250 --> 00:49:52.421
auf den 2G Antennen funktionieren. Mitel
hat bei den 3G Antennen an der Hardware
00:49:52.421 --> 00:50:00.750
gespart. Die können nur noch sechs Töne.
Das reicht nicht mehr.
00:50:00.750 --> 00:50:03.430
Herald: Okay, ich schau nochmal zu meinem
Signal Angel haben wir noch Fragen aus dem
00:50:03.430 --> 00:50:08.180
Netz?
Signal-Angel: Ja eine kommte gerade noch
00:50:08.180 --> 00:50:14.418
rein: wo genau kann man seine Telefon
Gerätenummer melden?
00:50:14.418 --> 00:50:17.770
zivilian: magst du?
ST: Im GURU. Eventphone, bzw.
00:50:17.770 --> 00:50:24.050
guru3.eventphone.de, wenn du dich dort
einloggst in deinen Account hast so bei
00:50:24.050 --> 00:50:30.410
deinem Gerät sozusagen ein Schlüssel,
quatsch nicht Schlüssel, einen Stift. Da
00:50:30.410 --> 00:50:35.150
kannst du das eintragen. Das ist ja auch
auf der Folie zu sehen. Genau, auf den
00:50:35.150 --> 00:50:39.480
Schlüssel klicken, Dann kannst du dein
Handset editieren, und dort kannst du unten
00:50:39.480 --> 00:50:46.880
bei Model das Modell eingeben und den
Hersteller. Du kannst dem sogar einen
00:50:46.880 --> 00:50:51.170
Namen geben, was den Vorteil hat, wenn du
das das nächste Mal benutzt, dann kannst
00:50:51.170 --> 00:50:55.320
du eine Nebenstelle registrieren und unten
gleich das DECT zuweisen, dann musst du
00:50:55.320 --> 00:50:58.580
auch den Token nicht mehr eingeben,
sondern kommst auf die Veranstaltung und
00:50:58.580 --> 00:51:03.600
das Telefon funktioniert einfach.
LaForge: Vielleicht wenn ich da noch kurz
00:51:03.600 --> 00:51:08.960
ergänzend, oh das mikro ist offensichtlich
wieder aus. Ergänzend nachdem die Frage ja
00:51:08.960 --> 00:51:14.830
aus dem Netz kam. Das geht natürlich hier
nur für die Leute, die bei Eventphone ihr
00:51:14.830 --> 00:51:17.740
Telefon eingebucht haben. Das ist damit
das in Ruhe registriert ist, Dann ist die
00:51:17.740 --> 00:51:21.480
Nummer ja mit dem Account entsprechend
assoziiert. Also wenn jetzt jemand
00:51:21.480 --> 00:51:25.030
irgendwo da draußen im Internet, der nicht
auf einer CCC-Veranstaltung war oder eine
00:51:25.030 --> 00:51:28.000
Eventphone-Veranstaltung war, der kann das
natürlich so nicht machen. Das wollte ich
00:51:28.000 --> 00:51:30.300
noch vielleicht ergänzen.
ST: Ist bestimmt nur jemand in der
00:51:30.300 --> 00:51:35.130
Assembly, der zu faul ist, herzukommen.
Gelächter
00:51:35.130 --> 00:51:37.800
Herald: Die drei Bitte.
Frage: Wenn ich es richtig verstanden
00:51:37.800 --> 00:51:42.030
habe, dann sind für gebraucht-verkaufte
Stationen bisher keine Downloads möglich.
00:51:42.030 --> 00:51:46.640
Muss oder will Mitel da auch nachbessern,
um das Update zur Verfügung zu stellen?
00:51:46.640 --> 00:51:50.380
zivillian: Das kann ich leider nicht
beantworten. Das weiß ich nicht.
00:51:50.380 --> 00:51:54.610
LaForge: Die Kontaktdaten stehen ja in
diesem Advisory drin. Das kann man ja
00:51:54.610 --> 00:51:58.810
durchaus mal den Leuten nahelegen, dass
man an die Users vielleicht auch denkt in dem
00:51:58.810 --> 00:52:02.490
Kontext.
Herald: Dann die Zwei Bitte!
00:52:02.490 --> 00:52:07.410
Frage: Ihr habt jetzt die Kommunikation
zwischen den Antennen und dem OMM
00:52:07.410 --> 00:52:10.840
angeschaut, gibts auch Bestrebungen, die
Antenne oder den OMM weiter durch
00:52:10.840 --> 00:52:14.780
OpenSource oder Eigenentwicklungen zu
ersetzen, gerade wenn hier osmocom Leute
00:52:14.780 --> 00:52:20.650
anwesend sind.
LaForge: Naja, ist halt immer so eine
00:52:20.650 --> 00:52:26.030
Frage der Zeit. Die Zahl der Projekte
wächst über die Zeit. Die Zahl der Leute,
00:52:26.030 --> 00:52:31.380
die an den Projekten arbeiten, wächst
leider nicht entsprechend mit. Von daher
00:52:31.380 --> 00:52:36.940
sehr gerne. Ich wäre der erste, der da
"Hurra" schreit, aber es müssten sich halt
00:52:36.940 --> 00:52:40.160
auch Leute irgendwie einbringen.
Dementsprechend. Ich denke ein guter
00:52:40.160 --> 00:52:45.360
Startpunkt für etwaige spätere OpenSource
Entwicklungen, oder überhaupt Arbeit mit
00:52:45.360 --> 00:52:51.210
DECT wäre, wenn Leute zu dem DECT
Wireshark Dissektor beitragen würden. Ja,
00:52:51.210 --> 00:52:55.130
das ist ja alles Zeug was in der DECT-
Spezifikation steht. Also man muss diese
00:52:55.130 --> 00:52:58.700
Specs lesen, man muss sie verstehen, was
man sowieso muss, wenn man an OpenSource
00:52:58.700 --> 00:53:02.200
in dem Kontext arbeiten will. Zumindest
eben isolierte Teile davon, und das kann
00:53:02.200 --> 00:53:05.660
man dann in Wireshark Dissector
ausdrücken. Und dann hätte man schon mal
00:53:05.660 --> 00:53:12.560
eine bessere Ausgangsbasis. Also Sehr
gerne. Aber, ja, Contributions brauchen
00:53:12.560 --> 00:53:17.630
wir.
Herald: Ok, Im Saal sehe ich keine
00:53:17.630 --> 00:53:21.891
weiteren Fragen, ich schaue nochmal zu
meinem Signal Angel. Auch keine. Dann
00:53:21.891 --> 00:53:25.770
bedanke ich mich bei euch erst einmal für
die lebhafte Diskussion bei euch dreien
00:53:25.770 --> 00:53:31.140
bzw. bei allen von Eventphone für eure
Arbeit. Vielen vielen Dank!
00:53:31.140 --> 00:53:39.768
Applaus
00:53:39.768 --> 00:53:50.690
36c3 Abspannmusik
00:53:50.690 --> 00:54:07.000
Untertitel erstellt von c3subtitles.de
im Jahr 2021. Mach mit und hilf uns!