Latest / Coding Buddies | Tech & Dev-Mindset / Big Software Fails #4 - Als das Vertrauen ins Internet zerbrach

Transcript

Big Software Fails #4 - Als das Vertrauen ins Internet zerbrach · Coding Buddies | Tech & Dev-Mindset

0:02
Wenn du darüber nachdenkst, in welchem System du dich
0:05
tagtäglich anmeldest und welche Daten du regelmäßig über das
0:08
Internet schickst, was würdest du sagen, wenn viele deiner
0:12
sensiblen Daten seit 2 Jahren potenziell in falsche Hände
0:15
geraten konnten? Du sagst, es wäre fatal, fatal,
0:18
richtig und genau mit dieser Information wurden Menschen
0:21
weltweit im Jahr 2014 konfrontiert, wie das passieren
0:25
konnte, das erfährst du in dieser Folge.
0:29
Coating Boys, Dein Podcast rund um Softwareentwicklung und
0:32
aktueller Tech News. Herzlich Willkommen.
0:46
Herzlich Willkommen zur neuen Folge ist Coding Buddies
0:48
Podcast. Schön, dass ihr wieder
0:49
eingeschaltet hast, deine Gastgeber wie immer meine
0:53
Wenigkeit Tino und auch der fantastische Fabi, den ich hier
0:56
schon im Bildschirm sehe. Fabi, Grüße dich was geht ab?
1:01
Tino, Was geht? Schön, dass wir alle wieder
1:04
zusammengefunden haben zu einer neuen Folge.
1:06
Es geht, es geht wieder los. Ja, es geht einfach nahtlos
1:10
weiter, Woche für Woche und wir haben immer noch richtig Bock.
1:14
Also du siehst auch richtig motiviert aus, deswegen habe ich
1:16
umso mehr Bock auf die heutige Folge, weil ich habe ein
1:18
wirklich geiles Thema mitgebracht, wirklich ein
1:20
wahnsinnig geiles Thema und zwar ich bin voll koffein, wir
1:24
können. Loslegen.
1:25
Okay also, das heißt Kaffee, hast du am Start, kann losgehen.
1:28
Eigentlich nur ein. Ich habe heute schon Pause
1:31
getrunken. Pass auf.
1:34
Ich möchte mit dir heute eine neue Folge Big Fails der
1:37
Software Entwicklung machen. Sehr geil und ich will jetzt
1:40
auch nicht direkt spoilern um welchen Bug es sich handelt,
1:44
aber wir. Gehen zurück in das Jahr 2014
1:49
und geben dann noch einen kleinen Blick in die
1:52
Vergangenheit bis ins Jahr 2011 sogar zurück und möchte mit dir,
1:57
ich sag's doch, es geht um den Heartbleed Bug, wir gucken uns
1:59
heute den Heartbleed Bug an, der einfach Apps berühmt ist.
2:03
Und ich hab richtig Bock das mit dir mal zu analysieren und
2:06
deswegen Liebe zu lieber zu sei. Gespannt, das wird ne geile
2:10
Folge ist n absoluter Klassiker, auf jeden Fall muss ich ganz
2:13
ehrlich sagen, also der ist mir auch schon n paar mal über den
2:15
Weg gelaufen, ist aber trotzdem immer wieder spannend.
2:18
Also das ist ja im Endeffekt wirklich n Bug, der damals also
2:23
als er aufgetreten ist beziehungsweise entdeckt wurde
2:26
man ja schon davon reden konnte, dass er so fast das Internet
2:30
zerstört hat, wenn man es richtig dramatisch ausdrücken
2:33
möchte, weil ja einfach sehr, sehr viele davon betroffen waren
2:37
und ich weiß gar nicht genau, ob ich das auch so sehen würde,
2:40
wahrscheinlich schon, weil im Endeffekt ja schon so ein
2:42
bisschen. Der Glauben an das Internet
2:45
untergraben wurde. So würde ich, so würde ich es
2:49
ausdrücken. Ja, man hat auf jeden Fall das
2:51
Vertrauen ein bisschen verloren. Genau, und was du meintest mit
2:55
der fast das Internet zerstört hätte, man muss halt sagen, dass
2:58
er einfach ein enorm hohes Potential hatte Schaden zu
3:02
verursachen. Aber wie es genau dazu kam?
3:08
Werden wir an dieser heutigen Folge analysieren und mal so
3:10
wirklich auseinandernehmen, was auch der Grund war.
3:13
Der technische Grund hinter dem Bug finde ich nämlich, ist auch
3:16
eine super spannende Geschichte und.
3:18
Deswegen würde ich dich bitten, magst du vielleicht einfach mal
3:21
so bisschen unseren Rahmen schaffen, indem wir uns bewegen
3:24
und mal so? Im ganz allgemein erklären, was
3:27
da so vor sich ging. Ja, also erstmal wie gesagt, es
3:30
war ja ein also dieser Bug hat jetzt über 2 Jahre existiert,
3:35
ohne dass er überhaupt wahrgenommen wurde.
3:37
Ne, also der war einfach. Musst du dir vorstellen, es war
3:41
kann man ja schon mal so n bisschen spoilern, ne gewisse
3:43
Art von Sicherheit Lücke die 2 Jahre unentdeckt blieb, das
3:46
heißt wenn du ein Angreifer gewesen wärst und du hättest das
3:51
gewusst, dann hättest du 2 Jahre lang.
3:54
Angriffsvektor nutzen können und das ist echt schon richtig
3:58
krass. Und das.
3:59
Ist eine lange Zeit, ja. Und dieser Bug, der wurde auch
4:02
so, also der, der war deshalb auch, weil er eben so kritisch
4:06
war, richtig populär geworden, weil ich glaube, das war der
4:11
erste Bug so in der Geschichte der Bugs, der auch wirklich so
4:17
ein eigenes Logo und einen eigenen Namen bekommen hat.
4:20
So später wurde. Das ja öfter mal so wieder.
4:22
Also das war dann so Trend, dass es so gehandhabt wurde.
4:27
Aber es war auch ein bisschen dem geschuldet, weil die.
4:30
Bug so kritisch war und auch sehr viele Leute betroffen
4:32
waren, musste. Man das ja irgendwie
4:35
publizieren, irgendwie in die Öffentlichkeit bringen.
4:39
Ja, das kann man ja nicht untern untern Tisch kehren unter den
4:42
Tisch oder unter den Teppich, was sagt man?
4:46
Alles okay und deswegen wurde halt dieses Logo, diese dieses
4:51
nette Logo wurde sozusagen erschaffen, damit es auch ein
4:55
medienfreundlicheres Gesicht bekommen hat als es.
4:58
So nach außen getragen wurde, und das fand ich auf jeden Fall
5:01
total interessant, einfach das mal so diesen Fun Fact zu hören,
5:05
weil das ist so nett, eine nette Zeitnote.
5:09
Ich finde es, was man auch mal so da hinterfragen könnte, ist
5:13
mal angenommen, das wird jetzt in den Medien gezeigt, ob sich
5:15
da. Viele dachten so, oh mein Gott,
5:18
das ist krass, oh, das ist ne krasse Sicherheitslücke gewesen
5:22
oder ist aktuell, falls noch nicht gefixt war oder sich
5:25
denken soll, ja. Mir egal.
5:30
Weißt du, so ich? Glaube also so Normalos, nicht
5:34
IT ler mal so als Normalus bezeichnet.
5:37
Ob die sich dachten OK krass oder sich dachten ja ist mir
5:40
doch egal. Zeig mir die fußballergebnisse.
5:43
Ich glaube, da gibt es so und so wie wie er heutzutage auch ne.
5:46
Also auch wenn heute was auftritt glaub ich gibt es die
5:49
Leute die sich denken oh mein Gott das ist richtig krass und
5:51
andere die sich denken langweilig irgendwas mit
5:54
Computern. Weil ich.
5:56
So aber die Frage. Die Frage, die wir uns jetzt
5:59
eigentlich mal stellen wollen ist, wieso war dieser Bug
6:01
eigentlich so gefährlich und warum hat man da jetzt so n
6:04
riesen Wind drum gemacht? Warum machen wir jetzt noch mal
6:07
so n Wind drum ja. Warum sind wir so gehyped und
6:10
finden das so spannend, dass der war?
6:13
Ja, schafft doch mal bitte den Frame, in welcher Welt wir uns
6:15
jetzt bewegen, um das mal einzuordnen.
6:17
Genau. Also wir müssen erstmal dazu
6:19
einen kleinen Exkurs in die Internet Kommunikation machen
6:22
und zwar hat dieser Heartbleed Bug hat was mit dem TLS Produkt
6:27
zu tun und dieses TLS Protokoll dient dazu.
6:31
Also es ist ein kryptographisches Protokoll was
6:33
dazu dient um Kommunikation. Wie zum Beispiel auch
6:38
Kommunikation im Internet einfach zu verschlüsseln, das
6:41
heißt rein theoretisch, wenn du Daten über das Internet
6:43
verschickst, hättest du ja rein theoretisch die Möglichkeit,
6:47
diese Daten einfach zu lesen und wenn diese Daten nicht
6:52
verschlüsselt sind, würdest du ja alles im Klartext lesen
6:54
können und es ist ja weiß ich nicht, kommt jetzt ein bisschen
6:59
auf die Person drauf an, aber ich würde jetzt mal so weit
7:01
gehen, dass man, dass jeder wahrscheinlich irgendwie so
7:04
bestimmte Geheimnisse hat und die erzählt man ja auch nicht
7:07
jedem einfach. So ne also zum Beispiel sowas
7:10
wie Passwörter. Jetzt im Internetgenre ist ja
7:15
ein gewisses Geheimnis, was du ja gerne für dich behalten
7:17
möchtest, ne und diese dieses TLS Protokoll wird eigentlich
7:21
fast überall verwendet ne also du hast zum Beispiel allein wenn
7:24
du dich irgendwo bei Social Media irgendeinem Social Media
7:27
Kanal einloggst. Wenn du bei Amazon oder anderen
7:30
E Commerce Shops, shoppst, Shops, Shops, Shops.
7:34
Oder Shops. Oder halt auch online Banking
7:37
machst. Also du möchtest ja auf gar
7:38
keinen Fall, zumindest kenne ich eigentlich jetzt keine Person,
7:42
die das gerne möchte, dass man irgendwie, dass das Risiko
7:45
liebt, aber dass das eigene Passwort vom eigenen Online
7:49
Banking irgendwie an andere Personen weitergeht, so und
7:53
Heartbleed, dieser Heartbleed Bug ist jetzt kein Bug oder kein
7:59
Designfehler dieses Protokolls, also dieser ist jetzt genau von
8:03
TLS selbst. Weil das ist ja im Endeffekt nur
8:07
ne Rahmenrichtlinie, wie man sich in der Kommunikation
8:11
verhalten soll ne, sondern dieses Protokoll, also dieses
8:14
diese rahmenrichtlinien wie man kommunizieren soll, das wurde
8:18
umgesetzt, also implementiert. Durch eine Open Source Software,
8:23
genannt Open SSL, so da haben bestimmt einige, kennen das
8:26
vielleicht ein andere vielleicht nicht.
8:29
Und diese Software ist im Endeffekt bis heute weit
8:35
verbreitet, ja damals auch heute auch.
8:38
Nutzt eben dieses Protokoll. Zur Verschlüsselung bei einer
8:44
Kommunikation. Und das wird halt, es ist frei
8:47
zugänglich, weil es ist ja open Source und es wird eben auch von
8:50
vielen genutzt. Also zum Beispiel wird Open SSL
8:54
auf Linux Systemen sehr sehr häufig verwendet, ja und Linux
8:58
Systeme sind ja ein großer Bestandteil oder Linux Server
9:02
sind ja ein großer Bestandteil im Internet, also die mit dem
9:05
Internet verbunden sind. Und genau so.
9:11
Diese Sicherheit, die da geherrscht hat, darauf haben
9:14
sich halt eben auch sehr, sehr viele Leute verlassen und gesagt
9:16
Okay, pass auf, da wird meine Daten werden verschlüsselt,
9:19
alles super, ich bin sicher, ich kann ordentlich im Internet
9:23
kommunizieren, ohne dass irgendjemand meine, ich nenne es
9:26
jetzt nochmal Geheimnisse irgendwie lesen kann und genau.
9:32
Das Ding ist. Dass, wie gesagt, es hat ja
9:36
nichts mit TLS selber zu tun, sondern dieser Bug hat ja in
9:39
dieser Software gesteckt, am Ende, der kam ja irgendwann in
9:42
die Software rein, in diese Open assl Software und.
9:45
Und damit wir aber erst mal verstehen können, ja wie diese.
9:51
Wie dieser Bug überhaupt auftreten konnte, müssen wir
9:54
einmal auch noch mal ganz kurz gucken.
9:56
OK, wie funktioniert denn ein, die die Kommunikation im
9:59
Internet zwischen einem Client, also ein Client ist ja zum
10:02
Beispiel ein Webbrowser wie Firefox oder so und einem Server
10:07
und das kannst du ja mal kurz einmal vielleicht umreißen.
10:11
Ja, also was ich dazu noch anmerken möchte, bis zu dem
10:15
Punkt. Dass diese TLS das TLS Protokoll
10:21
ist ja nicht quasi so in. Auf dem Papier schon eine 10
10:26
gewesen. Klar ist es sowieso die erste
10:28
Version des Protokolls, aber es hat ja eine lange Historie
10:32
gehabt, es gab ja vorher schon die SSL Protokolle in
10:34
verschiedenen Versionen, darauf hat denn TLS aufgebaut, ist
10:37
optimiert, verbessert, das heißt man war eigentlich schon an
10:42
einem Punkt, wo man von Sicherheit sprechen konnte, das
10:45
waren ja nicht so protestypen. Sondern man hatte eigentlich
10:48
wirklich ne gute Basis, auf die man sich auch verlassen hat,
10:51
weil du ja meintest. So, man hat diesen Glauben daran
10:54
verloren zu der Zeit oder man sprach davon, dass Leute den
10:57
Glauben dran verliert, weil es ja wirklich etabliert war und
11:00
jetzt ist die Frage, wie kommt dann?
11:02
So ein kritischer Bug in dieser Open SSL Software wie du gesagt
11:06
hast, rein die quasi dieses Protokoll implementiert und.
11:11
Das lag halt daran. Dass natürlich so ne Protokolle
11:15
sich auch weiterentwickeln, ne, weil wie gesagt, es gab ja auch
11:17
vom SSL Protokoll schon ne Einser zweier dreier Version und
11:21
genauso sollte sich ja auch das TLS Protokoll weiterentwickeln
11:24
und dafür gab es halt, weil du meintest wie sieht so diese
11:28
Kommunikation aus, da gab es halt nämlich das Problem wenn
11:31
ich jetzt quasi als Client, also mit meinem Rechner zu Hause eine
11:35
Verbindung auf so einer Website, also zum Serveraufbau im
11:39
Internet weiß. Ich irgendwas googeln möchte
11:43
ist. Aber ein klassisches Beispiel,
11:45
das macht einfach jeder, glaube ich.
11:48
Dann wird natürlich diese Verbindung aufgebaut und
11:50
verschlüsselt und das kostet halt ja Rechenaufwand und
11:54
Ressourcen und man hat halt sich überlegt, wie kann ich denn
12:00
diese Verbindung effektiv aufrechterhalten ohne immer
12:04
Daten auszutauschen, weil man kann sich das so vorstellen, man
12:06
baut diese Verbindung auf, tauscht diese Daten aus und dann
12:10
in der Regel ist die Verbindung eigentlich erledigt.
12:13
Obsolet, weil die Daten wurden ja ausgetauscht.
12:16
Aber um nicht jedes Mal wieder diese Verbindung aufzubauen, zu
12:20
verschlüsseln hat man sich halt überlegt, wie kann ich denn
12:22
effizient diese Verbindung aufrechterhalten?
12:27
Ohne ständig Daten austauschen zu müssen oder viel Daten
12:31
austauschen zu müssen. Und da gab es halt dieses
12:33
typische Keep Alive Prinzip, das begegnet ja eigentlich in
12:38
sämtlichen Bereichen wieder und deswegen.
12:42
Hat man es auch Heartbeat genannt?
12:43
Das war das heartbeat Update, dass man gesagt hat okay wir
12:46
erweitern unser Protokoll um eine Funktionalität.
12:51
Einem ganz kleinen Datenaustausch zwischen Client
12:55
und Server, was im Endeffekt nichts anderes aussagt.
13:01
Der Client meldet hey, ich bin noch da und der Server antwortet
13:04
sinngemäß Ich bin auch noch da cool, wir haben immer noch eine
13:07
Verbindung, weil du halt sonst keine Gewährleistung hast ob die
13:12
gegenüberliegende Seite noch da ist.
13:14
Das ist ja. Ein ganz simples.
13:19
Problem eigentlich. Was aber gelöst werden muss.
13:21
Mal angenommen man telefoniert also wir beide würden jetzt
13:24
telefonieren und wir sehen uns nicht in dem Sinne, sondern ganz
13:28
klassisches Telefonat, keine Videocall, ne.
13:30
Und wir würden reden und ich würde auf einmal nicht mehr
13:34
antworten. Ja, dann würdest du ja nicht
13:37
wissen oder oder beziehungsweise noch besser wir wir, wir sagen
13:40
einfach, wir schweigen jetzt. Ja.
13:44
Und wie weißt du, ob ich wirklich noch am Telefon bin
13:46
oder wenn ich auflege, ist die Verbindung getrennt okay, aber
13:50
wenn ich einfach nicht mehr antworte.
13:53
Woher willst du wissen, ob ich wirklich noch am Telefon bin
13:55
oder es auf den Tisch gelegt habe und eigentlich gerade im
13:58
Kühlschrank bin oder mir einen Kaffee ziehe?
14:00
So weißt du das ohne zu kommunizieren, das ist ja das
14:02
witzige an der ganzen Geschichte und das Ding ist, wenn man jetzt
14:05
sagt, weil du meintest ja, diese Verbindung wird ja
14:08
aufrechterhalten so lange, weil man kann sich das ja auch so
14:10
vorstellen, ein normales Telefonat funktioniert ja auch
14:13
so, dass ich zum Beispiel, ich rufe dich an, Tino, Na, wie
14:16
geht's dir und du so, ja, mir geht's super, und dann sagen wir
14:19
auch nicht okay wir legen auf dann.
14:21
Rufe ich dich wieder an. Und was hast du heute so
14:23
gemacht? Ja, ich war heute Bouldern, ja
14:25
super okay dann legen wir wieder auf, also dass man sozusagen nur
14:29
diese eine Frage und Antwort absetzen und dann auflegen und
14:32
wieder anrufen, ach was ich noch wissen wollte, was machst du
14:34
morgen, du antwortest, dann lege ich auf und da kann.
14:38
Man ja schon relativ schnell sehen, dass diese Zeit, die du
14:40
zum Auflegen. Zum neu die Telefonnummer
14:44
eintippen, dann tut es, dann geht jemand ran.
14:46
Diese Zeit, die willst du ja ne über im übertragenen Sinne nicht
14:50
bei der serverkommunikation Client Server Kommunikation
14:52
jedes Mal wieder haben. So genau.
14:55
Weil das das Thema ist. Ja, auch das kann man auch gut
14:58
an dem Telefonbeispiel bringen. Angenommen du wärst noch am
15:02
Telefon, dann ist ja deine Leitung blockiert, dann kann ich
15:04
in der Zeit kein anderer Anrufen, aber du weißt
15:07
eigentlich gar nicht, ob du wirklich noch mit mir
15:08
telefonierst, ob ich jetzt je Moment wieder.
15:11
Als dran bin und was sage oder weiter schweige und du hängst am
15:15
Telefon und denkst ja hm, sagt er jetzt noch, was sagt er
15:18
nichts, sind wir fertig. Eigentlich haben wir uns nicht
15:21
nicht wirklich verabschiedet, ich weiß nicht so wirklich,
15:23
weißt du und das blockiert dich aber in der.
15:26
Krankenwagen rufen irgendwann. Und das blockiert dich ja
15:30
derzeit für andere Telefonate und so ist es ja auch beim
15:32
Server. Er kann ja ne gewisse Anzahl an
15:35
Verbindungen entgegennehmen und aufbauen und wenn du jetzt
15:38
anfängst, da diese ganze Verbindung zu blockieren, dann
15:41
kann kein anderer sich mehr verbinden und das sind halt
15:43
alles Gründe warum dieses Keep Alive bzw Heartbeatprinzip in
15:49
sämtlichen Bereichen oft in der Kommunikation halt einfach
15:53
existiert. Um zu sagen, Pass auf, wir
15:56
müssen nicht die ganze Zeit Daten austauschen, aber in einem
15:59
festen Zyklus möchte ich doch bitte noch wissen, ob du noch da
16:03
bist und du mir antwortest. Und da gibt es halt
16:05
unterschiedliche Namen. Es gibt, manche nennen es auch
16:07
Ping Pong Prinzip, das heißt einer sendet ein Ping und der
16:11
antwortet also der andere antwortet mit Pong gibt es ja
16:14
1000 Sachen und Heartbeat ist halt auch sehr gängig, einfach
16:18
nur sinngemäß, dass der Herzschlag noch gefühlt wird, so
16:21
wie sind hier noch da beide. Und ja, aber.
16:24
Das ist ja beim Telefonat genau. Also das Kennwort kennt man ja
16:27
wirklich auch beim Telefonat, also wirklich. 1 zu 1 weil, wer
16:30
hat das nicht schon mal gehabt? Man telefoniert, einer der
16:34
Telefonierenden ist irgendwie gerade beschäftigt und antwortet
16:37
nicht direkt auf die Frage und dann kommt es was noch da genau.
16:43
Ja, und genau das ist es ja. Und dann sagt der andere
16:45
natürlich ja, sorry, was hast du noch da noch mal genau so und
16:50
das ist ab sofort Liebe zu Liebe zuhören, wenn dir das übern Weg
16:54
läuft, das Problem dann immer Ping und Pong.
16:57
Warten, bis ein Pong zurückkommt.
17:01
OK, kleiner Spaß am Rande. Auf jeden Fall wurde denn
17:04
dementsprechend das TLS Protokoll erweitert um diese
17:07
Heartbeatfunktionalität. Und zwar wurde das dann auch in
17:11
der Open SSL Library implementiert.
17:16
Das hat funktioniert. Es hat auf jeden Fall
17:18
funktioniert, die Implementierung, da gab es
17:19
nichts auszusetzen und das ist auch der Grund, warum mit diesem
17:24
Update der Bug in die Software gekommen ist.
17:27
Aber erst 2 Jahre später gefunden wurde, weil es war rein
17:31
funktional kein Bug, das heißt also es hat funktioniert, das
17:36
heartbeat Signal. Trotzdem.
17:41
Gab es ja jetzt diesen Bug als Sicherheitslücke, so gesehen.
17:46
Also das war jetzt kein Fehler in der Implementierung, sie war,
17:50
sagen wir mal, einfach nicht vollständig, ja richtig, und
17:53
magst du da vielleicht mal drauf eingehen?
17:56
Genau also wie das Ganze jetzt ungefähr.
17:58
Also ich versuch das jetzt mal immer grob, ganz, ganz einfach
18:00
verständlich zu erklären. Und zwar ist dieses heartbeat
18:04
Signal was vom Client gesendet wurde um halt eben zu prüfen,
18:07
sind wir noch da haben wir noch ne Kommunikation.
18:10
Wurde gesendet und das können wir uns so vorstellen, dass
18:14
einfach ein Text gesendet wurde, wie zum Beispiel der Text heißt
18:17
jetzt XYZABC, was auch immer ne, also sagen wir mal nur, dass man
18:21
sich es einfacher vorstellen kann, XYZ wird gesendet.
18:25
Und zusätzlich ne, also in der Programmierung ist es ja auch
18:28
so, dass man immer sehr sehr genau ist und das ganze
18:30
vielleicht noch mal checkt oder was auch immer, wurde dazu noch
18:33
gesagt, OK pass auf, ich sende dir jetzt den Text XYZ und der
18:37
hat die Länge 3 so und der Server hat dann diese heartbeat
18:41
Nachricht bekommen vom Client und hat sich gedacht okay ich
18:45
krieg hier gerade die heartbeat Nachricht mit dem Inhalt XYZ die
18:49
Verbindung bleibt offen da werde ich doch mal den Client
18:51
antworten und werde ihm genau diese Nachricht eben auch
18:55
zurücksenden. Er weiß, OK, das ist jetzt auch
18:57
unser kleiner Handhack hier. Und sagt, OK, du bist noch da
19:02
und ich möchte dir mitteilen, dass ich auch noch da bin und
19:04
sende dir das XYZ zurück. So oder Abigail, was auch immer,
19:07
nimm was du möchtest, ne soeben dieser spezifische Text.
19:12
Genau, du sendest quasi genau den gleichen Text zurück, damit
19:15
der Client weiß, OK, es ist auf jeden Fall die heartbeat Antwort
19:20
Antwort, dass der die Gegenstände noch am Leben ist,
19:23
weil es ja die gleiche Nachricht ist, die ich.
19:26
Gesendet hab ne, also dadurch kann ich mir sicher sein, dass
19:30
die Gegenseite auch auf meine Anfrage, also spezifisch auf
19:35
meine Anfrage reagiert hat. Deswegen macht man das mit dem
19:38
Text. Wie sah denn das jetzt n
19:40
bisschen technischer aus? Ja, guter Punkt, da wollt ich
19:43
nämlich gerade drauf eingehen. Lass uns da mal n bisschen
19:46
tiefer eintauchen wie die technische Umsetzung aussieht.
19:49
Also im Prinzip hat das Protokoll.
19:52
Eine Nachricht, ein Nachrichten, also message Format vorgegeben,
19:57
wie quasi so eine heartbeat Nachricht codiert sein muss.
20:03
Das heißt, man hat halt so verschiedene Felder gehabt, die
20:07
es auszufüllen galt, um dann ne gültige Nachricht, dass man
20:11
sagen kann, laut dem TLS Protokoll ist das eine gültige
20:16
heartbeat Nachricht. Ist es wichtig, dass die halt
20:19
auch dem Protokoll entspricht? Deswegen musste man als Client
20:22
die dementsprechend aufbauen, als Server natürlich genauso und
20:25
das sah folgendermaßen aus, dass man gesagt hat, OK, wir haben
20:28
erstmal ein Byte, was quasi belegt ob es sich um eine
20:32
Anfrage. Oder eine Antwort handelt.
20:35
Also im Prinzip stand da codiert mit ich glaube 1 oder 2 waren
20:40
die Werte, die da eingetragen werden konnten, dass.
20:44
Es sich entweder um ein Request handelt, das heißt ich starte
20:49
diesen Handshake, nenn ich es mal diesen heartbeat Austausch
20:52
oder ich antworte, das heißt der andere Wert war denn die
20:55
Response. Beispielsweise der Client sendet
20:59
dann ne 1, weil er die Anfrage an den Server stellt und der
21:02
Server antwortet in dem Feld mit ner 2, weil es die Antwort ist.
21:06
Das ist eigentlich ne relativ einfache Codierung gewesen und
21:09
dafür wurde denn ein Byte in der Nachricht ganz vorne belegt und
21:13
danach und das ist jetzt ein sehr entscheidender Punkt, gab
21:17
es ein 2 Byte Feld für die Payload und Payload ist im
21:22
Prinzip nichts anderes als das was du gerade erklärt hast.
21:24
Und zwar der Text den ich sende. Das ist im Prinzip.
21:27
In mein Content der Nachricht sozusagen.
21:31
Was auch immer ich schicke, das spielt gar keine Rolle, aber es
21:34
ist auf jeden Fall meine Nachricht an sich und diese 2
21:37
Bytes haben darüber entschieden oder mitgeteilt, wie lang diese
21:42
Nachricht ist. Du hattest jetzt glaube ich ABC
21:45
oder XYZ gesagt, also sagen wir mal Länge 3, dann müsste ich in
21:49
diesem Feld eintragen, dass die Payload die Länge 3 hat.
21:54
Das hat den Sinn, dass die Gegenseite weiß, weil sie muss
21:58
ja mit der gleichen Nachricht antworten.
22:01
Muss sie ja wissen, was aus der Nachricht, die du gesendet hast,
22:05
ist jetzt die Pay load und wie lang ist sie und wenn da denn
22:08
steht Länge 3, also beispielsweise also dann 3 Byte
22:13
sozusagen. Weiß sie okay die nachfolgenden
22:17
Bereiche in dieser Nachricht sind die Pay load, also meine
22:20
Nachricht, die ziehe ich mir raus und antworte, ich antworte
22:23
einfach genau mit der gleichen Länge zurück, so vom Prinzip vom
22:27
Protokoll her macht das der absolut Sinn, weil wie gesagt
22:29
das. Der Sinn ist ja, mit der
22:31
gleichen Nachricht zu antworten. Genau, und nach diesem Lenkfeld
22:35
kam denn die eigentliche Payload, also die Nachricht, und
22:38
es gab noch n padding Feld, das spielt jetzt für uns an der
22:41
Stelle nicht so ne große Rolle, nur kurz.
22:44
Der Vollständigkeit halber. Es ist n Feld wo random Daten
22:49
eingetragen werden um einfach diesen Security Aspekt zu
22:53
bedienen. Weil das halt gewisse Angriffe
22:56
erschwert, weil du dann es fällt dann halt schwieriger, also
22:59
schwerer zu erkennen, wo die eigentliche Nachricht liegt.
23:03
Das heißt, du haust wirklich random Daten rein, die einfach
23:06
keinen Sinn ergeben und dadurch kannst du halt.
23:09
Gewisse aber da hast du eine höhere Sicherheit gegenüber ja
23:14
feindlichen Angriffen. Sagen wir es mal so ne aus
23:16
Security Sicht, deswegen macht man das öfter, das heißt
23:20
eigentlich im Prinzip n rauschen was du da mit rein codierst.
23:24
Genau. Und ja, jetzt kann man sich
23:26
vorstellen, ich bau mir diese Nachricht zusammen, nehme ich
23:28
noch mal dein Beispiel. Ich sag in dem typfeld sag ich
23:33
1, weil ich möchte jetzt n request stellen, dann sag ich
23:37
Länge 3 wie du meintest in dem Payload Lengsfeld also die Länge
23:41
des Payloads und dann sende ich die Nachricht ABC an den Server
23:45
der sieht okay es ist request, das heißt ich schalte auf
23:48
Response und der baut jetzt genauso seine Nachricht
23:51
protokollgemäß auf sagt Ok response.
23:55
Länge liest der aus 3 Ah. OK, dann guck ich mir jetzt die
23:58
nächsten 3 Byte an. Ah, da steht ja ABC oder XYZ,
24:02
was hab ich grad gesagt digger ihr wisst was ich meine und ich
24:05
antworte quasi ich zieh mir das da raus und antworte genauso.
24:11
Wieder und schick die Nachricht zurück.
24:13
Genau mit dem Padding. Wie gesagt, das Padding ist
24:15
egal, der kann da selbst random Daten reinhauen.
24:17
Ja ne das ist wirklich auch da ist die Länge auch egal.
24:21
Das ist dann halt einfach nur so zusätzlich dazu aber diese
24:24
ersten 3 Felder sind entscheidend, also der Typ, die
24:27
Länge der Nachricht und die Nachricht das muss ich halt
24:30
einhalten und so wieder als Antwort zurückschicken und dann
24:33
ist quasi dieses heartbeat Protokoll befriedigt sage ich
24:36
mal. Jeder weiß, Hey, der gegenüber
24:39
ist noch da. Ja, ich meine, man kennt das ja
24:41
auch, wenn du keine Ahnung ein online Formular ausfüllst, dann
24:44
hast du ja bestimmte Einträge die du machen kannst und du hast
24:47
bestimmte Restriktionen vielleicht wo du wo es dann
24:49
heißt hier bitte den Namen, da zum Beispiel dein Alter in das
24:52
Alter kannst du keine Buchstaben eingeben sondern nur zahlen und
24:55
vielleicht hast du noch irgendwo ein Freitext.
24:56
So Freitext ist dann keine Ahnung wünsche Anforderungen was
25:00
auch immer ist dann das Padding. Und der Rest ist halt fest
25:04
definiert. So und jetzt hat es, gab es aber
25:07
vielleicht so diese Kleine, das kleine Problem.
25:11
An der Stelle, dass man zum Beispiel, wenn ich jetzt dieses
25:14
online Formular Ding nehme, dass man sagt, so, du konntest jetzt
25:17
aber vielleicht auch. In deinen Alter oder was auch
25:22
immer konntest du jetzt aber zum Beispiel auch.
25:26
Buchstaben eintragen. Also du konntest halt ein
25:28
bisschen schummeln, ne, das ist das, worauf ich hinaus möchte,
25:30
das heißt? Das ist die eigentliche
25:34
Sicherheitslücke an der ganzen Geschichte.
25:36
Du hast die Möglichkeit gehabt zu sagen, XYZ musstest aber
25:40
nicht zwangsläufig sagen, das ist jetzt mein Text ist 3 lang,
25:44
sondern du konntest sagen, ich sende xyz und der Text, den ich
25:51
aber dir schicke ist 100 lang, das bedeutet, dass der Server.
25:58
Das XYZ wieder zurückgibt, aber zusätzlich noch 97 weitere
26:03
Zeichen, die dann im Endeffekt wieder mit zurückkamen und dann
26:07
ist natürlich die Frage, wo kommen diese 97 Zeichen her,
26:10
denkt er sich die aus oder was auch immer und da ist es.
26:15
Im Endeffekt so, dass so ne Anwendung hat ja so n gewissen
26:18
Speicher der Allokiert wird mit dem so n Programm arbeitet.
26:23
Mhm oder dann der Server. Ne der solche Requests
26:26
entgegennimmt. Also angenommen du hast jetzt
26:29
beispielsweise Onlinebanking und bei diesem Onlinebanking kommt
26:32
jetzt irgendwie vorher weiß nicht Lisa Müller und meldet
26:37
sich an mit ihrem Usern. Meldet sich an mit ihrem
26:42
Usernamen und ihrem Passwort. So, und diese Daten werden für
26:47
eine gewisse Zeit in diesem Memory Speicher der Anwendung
26:52
gehalten und wenn du jetzt aber sagst, ich möchte gerne.
26:57
Xyz haben plus 100 weitere Zeichen, dann kann es muss
27:01
nicht, aber es kann durchaus sein, wenn du Glück hast werden
27:05
diese XYZ genommen und gleichzeitig noch 97 weitere
27:09
Zeichen und diese 97 weitere Zeichen, das ist einfach ein
27:12
Bereich der auf den Speicher zugreift und dann Daten aus
27:17
diesem Speicher einfach willkürlich rauszieht und wenn
27:20
du wie gesagt Glück hast als Angreifer kriegst du die
27:23
Credentials, also Username und Passwort von dieser Möglichkeit.
27:26
Und hast dann im Nachhinein halt eben die Möglichkeit, dich beim
27:30
Onlinebanking von Lisa Müller anzumelden.
27:33
Und das ist im Endeffekt genau der Knackpunkt, was das
27:37
eigentliche Problem war in dieser Heartbeat beziehungsweise
27:42
dann deswegen harte Bleed Message am Ende.
27:48
Ja. Gut zusammengefasst, weil das
27:52
ist halt wirklich das gefährliche dabei, weil weil.
27:58
Wir auch anfangs meinten, es hatte Potenzial.
28:02
Sehr sehr viel Schaden anzurichten und Potenzial in dem
28:07
Sinne, wie du so schön erklärt hast.
28:08
Es wird halt unerlaubterweise Speicher oder Inhalt des
28:14
Speichers herausgegeben. An die Anfrage an den Client
28:19
oder beziehungsweise in dem Fall, dann kann man ja sagen an
28:21
den Angreifer. Wenn du Glück hast, sind da halt
28:25
komplett unbrauchbare Daten drin, weil das halt sonst wie
28:29
geschnitten ist im Speicher, dass du halt keine sinnvolle
28:32
Zusammenarbeit. Bekommst aber die Chance war da
28:36
und sie war auch nicht klein, dass du sehr, sehr sensible
28:40
Daten da rausschneiden konntest. Dann ja und rausschneiden im
28:44
Sinne von das hast du ja schon cool erklärt, weil wenn wir es
28:47
dir noch mal kurz technisch machen, dieses Payload lenkfeld
28:53
sagt ja, also dann sagst du quasi gehen wir mal wieder vom
28:57
Client aus oder beziehungsweise jetzt reden wir mal von einem
28:59
Angreifer, du sagst jetzt dem Server.
29:02
Was hast du gesagt? 100 Byte und Sendest ihm aber
29:06
nur Zeichen im Sinne von 3 Byte dann.
29:10
Wird er natürlich sagen. Ok, ich habe jetzt diese 3,
29:14
diese 100 Bytes, die ich zurückgeben muss und er fängt
29:17
an. Vorne und nimmt den Speicher von
29:23
100 Bytes und gibt dir diesen Block zurück.
29:25
So und 3 Byte davon sind aber jetzt quasi eigentlich nur das,
29:29
was du ihm geschickt hast. Wie du ja so schön meintest, das
29:32
heißt du kriegst jetzt 97 sagen wir mal Zeichen oder was auch
29:35
immer, Daten unerklärlich, unerlaubt dabei.
29:38
Und der Server agiert nicht dagegen und duldet das.
29:41
Und er duldet es immer wieder, weil wie gesagt, das ist dieses
29:44
heartbeat Signal, das heißt, es ist ja dieses Keep Alive
29:48
Prinzip, das heißt das ist ja ne ständige Kommunikation, ja.
29:52
Ne, also das kannst du nicht einmal machen.
29:54
Dann Finger Cross im Sinne des Angreifers.
29:57
Hoffentlich ist da was Sinnvolles drin, sondern du
29:58
kannst ja die ganze Zeit. Quasi immer wieder versuchen da
30:03
Daten rauszuziehen. Das ist wie, als würde man
30:06
damals. Kennst du noch die pokémon
30:08
Booster Packs? Ja, du hast einen aufgemacht und
30:11
hast dir gehofft, bitte ne richtig gute Karte, bitte ne
30:13
richtig gute Karte genau so, aber du musstest die ja kaufen,
30:17
aber das war ja quasi der Kiosk stand offen für dich, du
30:20
konntest so viel Booster Packs dir holen, bist du deine goldene
30:24
Superkrasse Karte hattest. Das ist man.
30:29
Muss da gleich und man muss dazu sagen, es ist es handelt ja
30:32
sich, es handelt sich ja hier nicht um einen Zeitraum von 10
30:36
Minuten, sondern um über 2 Jahre, in denen diese
30:39
Sicherheitslücke offen stand, und jetzt kann man sich langsam
30:43
vielleicht. Erschließen, wieso man.
30:47
Wenn man das so mitkriegt, vielleicht so n bisschen den
30:50
Glauben verloren hat oder verlieren könnte, wenn man denn
30:54
sagt, Oh OK, also es ist jetzt hier ein wirklich
30:58
sicherheitskritisches. System, was ja aber über 2
31:03
Jahren Bug hatte und meine ganzen theoretisch meine ganzen
31:07
sensiblen Daten innerhalb von 2 Jahren absnacken könnte.
31:10
Also Angreifer hätten das ne verwenden können und das hätte
31:13
ich genug versuche gehabt, quasi genau und das ist echt krass was
31:17
man sagen muss. Also wie gesagt das sind ja so
31:19
ein bisschen diese Auswirkungen, man kann sich jetzt natürlich
31:22
hinstellen und sagen gut, Open SSL ist eine Software die läuft
31:26
halt auf Linux, also Windows nutzt eigentlich im Normalfall
31:29
nicht Open SSL. Auf jeden Fall weniger als Linux
31:33
und da könnte man sagen ja okay Linux Server sind betroffen okay
31:38
das Problem ist, dass natürlich die meisten Server im Internet
31:41
sind, Linux Server, weil Linux ist ja auch ein Open Source
31:45
Betriebssystem und es kostet nichts, du kannst es einfach
31:49
verwenden, was natürlich viele auch nutzen um halt eben ihre
31:52
Server laufen zu lassen logischerweise und wenn man dann
31:56
aber jetzt denkt okay Windows war bei Safe, also zum Beispiel
32:00
Windows Server, dann ist es halt auch.
32:02
Weit gefehlt. Weil, und das ist auch so ein
32:04
Ding, wenn du. Große Serverfarmen hast und zum
32:08
Beispiel Du hast NE Commerce System und du hast zum Beispiel
32:11
so ne Art. Prime Day, wo ganz viele Leute
32:15
nach Angeboten shoppen und alle greifen auf, zum Beispiel n
32:18
Server zu, dann würdest du ja nicht sagen, ja komm, wir
32:21
probieren mal alle auf den Server zuzulassen 100000000
32:24
Leute die da drauf wollen weil wie du ja auch schon meintest
32:27
Dino diese Kapazität der Leitung ist ja belegt also nicht belegt
32:31
sondern begrenzt. Und da hast du deswegen
32:35
natürlich mehrere Server. So und damit das aber gut
32:39
funktioniert, gibt es meistens sogenannte Load Balancer, die
32:41
diesen Traffic verteilen auf die verschiedenen Server, sodass
32:46
sagen wir mal, wenn 100 000 Leute kommen, dass jeder Server
32:49
1000 Anfragen bekommt, je nachdem wieviel Server man hat
32:52
und selbst wenn du Windows Server hast, ist meistens ist es
32:57
so, dass dieser Load Balancer, der davor sitzt um diese Last zu
33:00
verteilen. Läuft meistens auf einem Linux
33:03
System und damit hast du genau an dieser Stelle wieder diese
33:06
sensiblen Daten, die dort sozusagen drüber laufen.
33:10
Ja, und damit hast du genau wieder diesen Angriff, obwohl
33:13
eigentlich theoretisch man sagen könnte, ja, Windows war dann
33:17
nicht so gefährdet. Und am Ende waren dann doch
33:21
gefühlt wieder alle betroffen davon.
33:22
Ja, richtig und? Es ist ja auch nicht so, dass
33:25
man zum Beispiel sagt, Ja gut, das, es geht jetzt nur um
33:27
Websites, ne, also TLS wird ja von verschiedenen Sachen
33:30
benutzt, also Mails verwenden, TLSVPNS verwenden, TLS Firewalls
33:35
verwenden, TLS, also es gibt sehr sehr viele Komponenten die
33:39
TLS verwenden. Vpn ist zum Beispiel auch ein
33:42
guter Grund gewesen, dieses heartbeat Update umzusetzen,
33:46
weil du halt diese aufrechte Verbindung die ganze Zeit dann
33:48
hast. Ja, das ist schon das ist, das
33:54
ist schon krass, was das für Auswirkungen hatte.
33:56
Ich würde gerne noch einen anderen Punkt eingehen, weil ich
33:59
weiß nicht, wie es dir da ging, aber als ich mich mit dem Bug
34:02
beschäftigt habe, habe ich mich halt gefragt, wie kann es denn
34:05
sein, dass ich jetzt ein Update mache und so eine enorm große
34:10
Sicherheitslücke da reinkommt und vor allem, wie kann es sein,
34:13
dass unerlaubterweise Speicher der Anwendung, also vom Server
34:17
heraus. Gegeben wird und.
34:20
Dann hab ich mir quasi das in Open SSL angeguckt.
34:23
Also findet man ja auch schnell Liebe zu liebe Zuhörer, wenn du
34:27
Bock hast dir das mal anzuschauen, dann Google einfach
34:29
den Bug und sag Source Code dazu oder so, dann findest du auch
34:33
recht schnell genau den Ausschnitt, der dafür
34:35
verantwortlich war, also das Update und die Antwort ist
34:39
eigentlich relativ schnell gegeben, weil Open SSL Inc.
34:42
Entwickelt ist und versteht mich nicht falsch, ich habe auch sehr
34:45
lange in C entwickelt und ich mag die Sprache auch sehr.
34:48
Aber das erklärt Halt auch relativ schnell, wie es denn
34:51
sein kann, dass so so ein Speicher da einfach mal
34:54
rausgegeben wird. So ein klassischer Fall ist ja
34:57
meistens immer die Rede von Memory Leaks, das heißt das
35:01
Speichern nicht mehr freigegeben wird und damit tot ist.
35:03
Aber hier haben wir genau den umgekehrten Fall, dass man sagt,
35:07
Wir geben Speicher wirklich nach außen, also wir liegen die die
35:11
Data dahinter und das fand ich halt total krass und wenn man
35:14
sich diesen Source Code anguckt, das sind wirklich nur ein paar
35:16
Zeilen. Fabi, das ist so krass und das
35:18
ist echt sauberer C Code, das ist nicht nicht schlecht
35:22
programmiert. Also da wirklich kein Blame, nur
35:25
es ist halt so dieses typische Happypass Coding, das heißt es
35:29
ist einfach da man man ging halt davon aus serverseitig, dass der
35:34
Client einem realistische Informationen schickt, also man
35:39
ging davon aus dieses Pay Load Lengfeld ist ein wahrer Wert,
35:45
dass niemand die Absicht hat da was falsches einzutragen,
35:47
sondern wer würde stimmt immer. Wer würde auch sowas tun,
35:52
sondern dass quasi diese angegebene Länge auch immer zur
35:55
Nachricht passt und dementsprechend hat man dann
35:58
ganz ein typischer C Code. Manier ist ja klassische Pointer
36:02
Arithmetik dann man hat sich halt einen Pointer darauf
36:05
gesetzt, hat die Nachricht genauso wie ich es vorhin gesagt
36:08
habe, der ist ja vorgegeben, der Aufbau, das heißt du konntest
36:11
genau sagen erstes Byte gut request oder Response hattest du
36:14
schon mal deine Unterscheidung wie du antwortest, dann hast du.
36:17
Du die nächsten 2 Bytes genommen hast gesagt, aha okay länger.
36:20
Was war es bei dir 3 so dann. Da iteriere ich den Point da
36:25
weiter und gucke auf die Nachricht.
36:26
Schneid mir diese Nachricht der Länge 3 raus.
36:30
Reservier mir n Speicher für meine Nachricht, hau da alles
36:33
rein und ab damit wirklich Straight Forward entwickelt.
36:37
Das heißt du allokierst dir dein eigenen Speicher, dass du genug
36:40
hast, um diese Nachricht aufzubauen und kopierst dann mit
36:43
dieser typischen Ich glaube jeder der man C entwickelt hat,
36:45
kennt die Funktion mit der man copy Funktion sagst.
36:48
Du kopier bitte aus der Speicheradresse von da an zu
36:53
einer anderen die eine Zieladresse.
36:56
Also Quelle und Destination mäßig mit der Länge Pay load
37:00
length, die angegeben war und dann macht die Funktion, dass
37:03
dann sagst du bitte von A nach B 3 Bytes, dann wären genau diese
37:08
3 Bytes die da anfangen bei A nach B gekopiert so und der
37:14
Funktion ist es voll egal was du für eine Länge da übergibst oder
37:18
ob in der ursprünglichen Nachricht überhaupt so viel
37:21
Bytes drin waren, das ist der Funktionär egal.
37:23
Und jetzt genau das ist nämlich das Problem.
37:25
Weil du sagst, jetzt 100 Bytes bitte kopieren, gibst ihm aber
37:30
nur 3, dann allokiert er sich aber den Bereich und sagt jetzt
37:35
an der Stelle 100 Bytes bitte und nach dem vierten Byte sind
37:38
es eigentlich deine eigenen Daten die du da rein schreibst
37:41
und nicht mehr das was du Empfang hast und 97 Bytes deines
37:44
eigenen Speichers schreibst du schön in diese Antwortnachricht
37:48
und ab damit und der Client denkt sich alles klar, ich habe
37:51
3 bytes gesendet, die nächsten 97 mal gucken was drinsteht.
37:56
Da und eigentlich wäre doch genau der fix dann an der Stelle
37:59
und das was vergessen wurde war ja okay du sendest mir 3, sagst
38:04
aber 100, also sende ich dir dann nur maximal 3 so weil mehr
38:09
darf ich dir nicht senden oder? Das wäre doch jetzt die logische
38:12
Konsequenz daraus. Genau, also die Konsequenz ist,
38:15
einfach mal zu überprüfen und so wurde es am Ende auch gefixt.
38:19
Es ist ein Einzeiler gut. Wir 2 mit dem Return noch.
38:24
Es ist eigentlich nur eine If Bedingung am Anfang.
38:26
Dass du sagst, wenn. Payload Lenks, die angegeben
38:32
ist, nicht realistisch ist also nicht gleich der
38:35
Nachrichtenlänge, die ich empfangen hab, ist plus dem
38:40
Overhead von. Also du musst natürlich noch
38:43
drauf rechnen, dass du ein Byte hast für die Typisierung, was
38:47
ich meinte 2 Bytes für die eigentliche Länge, das ist ja
38:50
dieses 16 bit Feld, das rechnest du drauf ja dann aber die
38:53
gesamte Länge der Nachricht muss dann einfach dementsprechend was
38:57
in Payload längs steht und wenn das nicht der Fall ist, dann
39:00
wird es halt verworfen und genauso am Ende sah auch der fix
39:03
aus, das heißt es sind 2 Zeilen die zwischen der absoluten
39:07
Katastrophe und sicherer Software entschieden haben und
39:10
das ist mind blowing finde ich. Ich finde das halt so krass, was
39:14
so 2 Zeilen ausmachen können, vor allem weil wir halt 2 Jahre.
39:17
Sind ja richtig, weil das Halt so eine Riesensicherheitslücke
39:22
ist. Durch 2 Zeilen Code.
39:23
Ich stelle mir das ungefähr so vor, weil das wurde ja dann
39:26
sozusagen per Zufall eigentlich gefunden und dann konnte es auch
39:30
gefixt werden. Dann musste das natürlich
39:32
öffentlich publiziert werden und so weiter aber ich stelle mir
39:35
das ungefähr so vor, als würde man in einer Bank arbeiten.
39:39
Nach 2 Jahren mitkriegen, Ach du Scheiße.
39:44
Die ganze Zeit konnte man einfach in den Safe gehen und
39:47
sich da was rausholen. Ja, so ungefähr so, als du dir
39:51
nach 2 Jahren denkst. Alter.
39:54
Wie kann ich das irgendwem erklären?
39:56
Also weißt du, das ist das ist echt krass und da kommt man
40:00
eigentlich auch n bisschen zu dem Punkt, natürlich, so wie
40:02
konnte das eigentlich überhaupt passieren?
40:04
Also das klingt natürlich jetzt so wie okay, aber warte mal,
40:07
warte mal, warte mal. Also aus heutiger Sicht
40:10
natürlich, wir schreiben Tests, das macht ja hoffentlich jeder
40:14
klare Sache, auf jeden Fall, aber einfach nur die Frage wie
40:19
das passieren konnte und ich finde es auch interessant bei
40:22
Open SSL ist ja eine Open Source Software.
40:25
Und diese Open Source Software wurde eigentlich mehr oder
40:28
weniger von der Hand voll freiwilligen Leute gepflegt und
40:32
Gemain, taint und so weiter und es gab auch nen finanziellen
40:37
Zuschuss. Also es wurde sozusagen
40:40
gespendet dafür, dass so eine Open Source Library, die ja sehr
40:44
sehr wichtig ist, also eine wirklich unglaublich wichtige
40:47
essentielle Software, die für die Sicherheit von Millionen.
40:52
Servern sorgt. Natürlich wird da gespendet und
40:54
es wurde ungefähr jährlich $2000 gespendet, damit diese Software.
41:01
Wird von einer Handvoll Leuten, das ist doch also, das ist krass
41:05
und du musst dir das so vorstellen, dass ein Doktorand.
41:09
Hat diesen Code, also diesen Heartbeat ne, also das genau
41:15
dieses Update, diese Weiterentwicklung ne damit man
41:17
eben genau dieses Problem was wir besprochen hatten mit dieser
41:20
Kommunikation die aufrechterhalten werden kann,
41:23
wurde implementiert von diesem Doktoranden und kleiner Fun
41:27
Fact, es wurde Silvester 2011 committed eine Minute von
41:33
Neujahr. Schön.
41:36
Also ich weiß nicht, was das damit zu tun hat, aber ich
41:38
dachte mir so, vielleicht ist es auch n Learning, dass man
41:41
vielleicht zu Silvester keinen Code mehr schreibt, sondern
41:43
einfach mal. Rausgeht mit n paar Leuten
41:46
Verknaller loslässt. Oh, stell doch covid.
41:48
Das Update muss fertig werden, gleich ist Neujahr, das nehme
41:51
ich nicht mit ins nächste. Jahr und das wurde dann halt von
41:55
einem Mitarbeiter oder von einem anderen zuständigen.
42:00
Sag ich mal approved und das heißt einer committed etwas mit
42:04
diesem kleinen Fehler, einer übersieht es und am Ende hast du
42:07
halt dann einfach ein 2 Jahre lange Sicherheitslücke, die
42:11
absolut krass ist. Und das find ich halt so krass,
42:15
weil man kann jetzt sagen, ja gut, das musst du testen und
42:18
hier warum, wer weiß was da lief.
42:20
An Tests weiß ich jetzt nicht, aber selbst wenn du eine hohe
42:25
Testabdeckung hast oder sehr sorgfältig testet, es ist.
42:29
Auch verständlich, dass so ein Edge Case oder bzw.
42:33
Diese Annahme, dass jemand keine fairen oder echten Daten damit
42:38
schickt, die passen, dass man sonst Fall auch mal übersieht
42:42
das das passiert. Du kannst ihm ja auch keinen
42:44
Vorwurf machen, weil wie gesagt, das war ja nicht schlecht
42:47
gecodet, das war ne saubere Funktion, ich weiß keine Ahnung
42:50
wie lange die da noch drin geblieben ist, ob die noch drin
42:53
ist, ob er da noch quasi contributed drauf weiß ich
42:57
nicht. Ansonsten liebe Grüße.
43:00
Aber Fakt ist, das war eine gut geschriebene C Funktion, nur
43:03
dass dieser eine Fall nicht berücksichtigt wurde und das ist
43:05
absolut legitim, dass das passiert, da kann man niemand
43:09
strikt raus drehen. Ich muss sagen, wenn du das in
43:11
einem unternehmerischen Kontext hättest, glaube ich, dass man
43:15
schon strikt daraus drehen könnte, weil wenn du zum
43:17
Beispiel wirklich in einer großen Firma beispielsweise
43:20
arbeitest und man dann sagt, ja okay, also man sollte solche
43:24
Sicherheitschecks sozusagen machen, also gucken, wo sind
43:27
denn mögliche? Angriffsvektoren, das sollte man
43:31
auf jeden Fall checken und sicherheitsprofil davon
43:34
aufbauen, da bin ich fest von überzeugt.
43:36
Nur man muss ja bedenken und das ist finde ich das was die ganze
43:39
Sache irgendwie entschuldigt, weil erstens ist es guter Code
43:41
gewesen. Meintest und auf der anderen
43:43
Seite waren das Leute, die das freiwillig contributed haben und
43:49
da ist ja sozusagen auch ein bisschen selber schuld, wenn
43:52
alle auf der ganzen Welt eine sehr, sehr wichtige Sicherheits,
43:56
also eine sehr, sehr wichtige Software benutzen, die
43:58
sicherheitsrelevant ist. Für das sage ich jetzt mal das
44:00
gesamte Internet, und dann gibt man aber nur $2000 Spenden
44:05
jährlich an so ein paar Mitarbeiter, die eigentlich nur
44:08
Gutes tun wollen und sozusagen unterstützen wollen.
44:11
Also da kannst du diesen Menschen keinen Strick.
44:14
Aber nee, deswegen ne nur ich finde halt auch.
44:18
Also ich verstehe deinen Punkt, dass man sag ich mal unter
44:20
unternehmerischen Kontext das so nicht passieren darf.
44:23
Es darf allgemein nicht passieren, ganz klar.
44:26
Nur ich finde, die Schwierigkeit ist eher oder was problematisch
44:29
ist, dass das so spät aufgefallen ist.
44:31
Also es ist ja absolut nicht verwerflich, dass man so n Fall
44:34
übersieht, aber man muss es halt relativ schnell mitbekommen und
44:38
fixen, weil 2 Jahre ist einfach zu lang für so ne
44:41
Sicherheitslücke und was ich extrem krass auch dabei finde,
44:45
um das noch mal kurz zu beleuchten, du kannst einfach
44:49
nicht. Ermitteln, wieviel Schaden
44:53
entstanden ist. Du weißt nicht, was innerhalb
44:56
dieser 2 Jahren an Daten abgegriffen wurde?
45:00
Ja, und diese Unbekannte, also dieses, diese Ungewissheit, wer
45:04
weiß jetzt über was Bescheid? Am Ende finde ich ist halt das
45:08
krasse und nahezu schon unheimliche dabei, weil es 2
45:14
Jahre sind lang, das heißt du als Unternehmen, wenn du jetzt
45:17
deine Server hast mit dieser Version.
45:20
Also. Unter dieser Protokoll Version
45:23
laufen lassen hast und diese Sicherheitslücke drin war.
45:26
Du weißt ja nicht ob jetzt einfach sämtliche Firmen interne
45:29
Geheimnisse oder was auch immer auf den Servern war, jetzt nach
45:32
außen gedrungen ist. Ja richtig, das ist auch eine
45:36
Sache, die sehr, sehr einen bitteren Nachgeschmack zurück
45:40
lässt. Was ich noch interessant fand,
45:42
war, dass es dann natürlich Lösungen gab, nachdem es
45:44
aufgedeckt wurde. Das heißt, du konntest natürlich
45:46
eine gefixte Version einspielen. Auf deinen Servern
45:49
logischerweise. Das heißt, dass die Serverseite,
45:51
wenn du aber zum Beispiel ein Client warst und kein Server
45:54
betrieben hast und damit eigentlich nichts am Hut
45:56
hattest, gab es sogar auch Plugins für Browser, die dann im
45:59
Vorfeld, wenn du auf eine Seite gegangen bist, gecheckt haben,
46:02
ist dieser Server, mit dem du gerade kommunizieren möchtest,
46:05
anfällig dafür. Ja, also fand ich auf jeden Fall
46:08
interessant und irgendwie auch ne coole Sache.
46:10
Klar kann man sich jetzt hinstellen und sagen, Ey Pass
46:11
auf, wenn du dieses Plugin hast, dann kann ja n Angreifer auch
46:14
sozusagen die Server scannen und gucken, ob die dafür sozusagen
46:18
anfällig sind, aber das kann man ja auch so.
46:21
Ja, also ausprobieren, im Endeffekt wichtig, dann für die,
46:25
für die Leute. Aber was haben wir denn, also
46:27
was konnte man jetzt denn daraus irgendwie lernen, weil ich
46:31
finde, es ist ja irgendwie wichtig, dass man am Ende noch
46:33
irgendwie n Learning draus zieht und sagt, OK, das ist was
46:35
passiert. Und was können wir damit jetzt
46:40
machen? Am Ende, weil das Kind ist im
46:42
Brunnen gefallen, das Ding ist durch, ne, also da wurden Daten
46:45
abgegriffen über 2 Jahre oder auch nicht, wer weiß es schon.
46:48
Wir wissen nicht was, aber was können wir denn für die Zukunft
46:51
daraus lernen? Ja, also ein großer Punkt, den
46:55
hast du auch angesprochen. Ist das so Open Source Projekte
46:58
echt essentiell sind für unsere ganze Tag Landschaft und es gibt
47:01
so viele davon, die aber auf den Rücken privater Leute aufgebaut
47:06
sind, die das einfach. Ja, freiwillig und aus Spaß an
47:11
der Freude oder so sagt man auch ne machen, weil sie einfach
47:16
dahinter stehen und überzeugt davon sind, aber gar nicht.
47:19
Also man muss. Sich ja überlegen wieviel Zeit
47:23
das benötigt. Sowas zu maintain und wenn dann
47:27
keine finanzielle Förderung dahinter ist oder spenden was
47:31
auch immer Geld einfach Geld dann.
47:35
Wie soll das denn auch alles immer reibungslos laufen?
47:37
Also das muss man auch schon mal wirklich wertschätzen, was diese
47:40
Open Source Projekte bedeuten und ruhig auch mal donaten würde
47:45
ich mal sagen, das kann man ruhig mal auch mal so sagen.
47:49
Weil man sieht, wenn das alles mit Zeitdruck und ja, sie müssen
47:53
nebenbei arbeiten und haben eigentlich gar keine Zeit, das
47:56
zu 100% zu verwalten und dann schnell noch ein Update, was
47:59
sich gewünscht wird hier und da, dann passieren halt Fehler am
48:02
Ende. Also ich bin Fan von Open
48:04
Source. Man muss sich 1 klar machen,
48:06
glaube ich, nur weil jeder Open Source Software.
48:09
Blick drauf werfen kann, bedeutet das noch lange nicht,
48:12
dass es auch jeder tut. Ne.
48:14
Also da wird glaub ich auch oftmals so n bisschen dann sich
48:18
drauf verlassen und gesagt ja Open Source Software, da kann ja
48:22
jeder drauf gucken und so weiter.
48:25
Aber. Das passiert halt nicht immer ne
48:29
und da muss man dann halt gucken, dass man vielleicht so
48:31
bestimmte wirklich kritische Softwarekomponenten, die sowas
48:36
wie halt eben dieses Beispiel zeigt, auch vielleicht mal n
48:40
bisschen genauer unter die Lupe nimmt.
48:41
Deswegen ist es auch immer hilfreich, dass auch jeder zum
48:44
Beispiel. Ne, also liebe Zuhörerin, lieber
48:47
Zuhörer, auch du kannst dir Open Source Code angucken.
48:51
Ja. Absolut.
48:54
Dann find ich so n Learning, was ich dabei auch wieder rausziehe
48:57
ist also hinsichtlich C Code, dass man halt echt ne Menge
49:01
Unfug damit treiben kann. Und Speicher?
49:07
Verwaltung einfach ein riesen Punkt ist, gerade wenn man C
49:09
codet. Das heißt da auch aus Security
49:11
Aspekten ordentlich darauf achtet was man da auf dem
49:14
Speicher macht. Ich finde halt das ist auf jeden
49:17
Fall auch wichtig ist sich vor Augen zu fühlen, egal wo man
49:22
dran codet aber wenn du irgendwo rein theoretisch Schnittstellen
49:26
nach außen hast in deiner Software, dann ist es ein Blick
49:30
wert zu sagen gibt es potenzielle Sicherheitsrisiken
49:32
an dieser Stelle und was könnte sein, da hilft es auch einfach
49:35
mal vielleicht sich ein bisschen zu unterhalten.
49:37
N bisschen in den Austausch zu gehen und zu sagen, du Pass auf,
49:39
ich hab jetzt das und das diesen Sachverhalt, wie sieht es aus,
49:42
könntest du dir vorstellen, dass da irgendein Mist passieren
49:44
könnte? Sowas hilft natürlich auch, ich
49:46
meine es gibt ja auch n Learning, was natürlich auch
49:50
sicherlich jetzt mittlerweile schon überall angekommen ist.
49:52
Das ist die sogenannte 2 Faktor Authentifizierung, das heißt
49:55
wenn jemand ein Username und Passwort hat, bedeutet das noch
49:58
lange nicht, dass man auch wirklich überall reinkommt,
50:01
heißt aber nicht, dass überall 2 Faktor angewendet wird, aber es
50:04
ist natürlich eine Sache, dass dieses 2.
50:06
Faktor immer mehr kommt. Genau aus solchen Gründen, dass
50:09
du halt eben nicht nur über solche Sachen, wenn auch wenn es
50:12
geleakt werden würde, dass man dann trotzdem nicht genau in
50:16
diese Systeme reinkommt oder ein online Banking, was auch immer.
50:24
Sehr gut zusammengefasst. Also ich würde sagen, haben wir
50:26
es auch wieder ausführlich besprochen, aber ich find das
50:28
Thema super spannend und ich find es, ich muss es einfach
50:31
noch mal sagen. Ich find es krass wie 2 Zeilen
50:33
Code über sowas entscheiden können.
50:35
Es ist Zeit und ich find es halt.
50:38
Und wie lange, vor allem und wie riesig dieses Potenzial war für
50:42
Schaden. Die tut man einfach nicht, weiß,
50:44
wieviel Scharen wirklich entstanden ist.
50:46
Find ich auch krass dabei in. Diesem Sinne blutet mein Herz,
50:48
weil die Folge wieder vorbei ist, hart blieb und so.
50:51
Schön schön, Fabi, der war gut. Oh, weil heute bin ich aber
50:55
auch, ja. Muss.
50:57
Ich mich für entschuldigen, aber ich möchte in dem Sinne auf
50:59
jeden Fall sagen, Tino, Es hat mir wieder Spaß gemacht mit dir
51:02
darüber zu reden. Dann gib mal Zuhörer, lass auf
51:06
jeden Fall mal eine Bewertung da empfiehl den Podcast weiter.
51:09
Uns würde brennend interessieren, was du auch zum
51:13
Beispiel selber mitbekommen hast von diesem Heartbleed Bug ist ja
51:17
nicht so lange her 2014 und schreibt uns das gerne oder
51:22
schreibt uns auch dein Feedback gerne über die Podcast Mail wenn
51:25
du sagst ich finde das cool, das macht richtig Spaß hier
51:28
zuzuhören. Die Coding Buddies ist ein
51:30
geiles Projekt, das macht Spaß, dann unterstützt uns gerne auch
51:33
in den Show. Ist ein Link für eine kleine
51:35
Spende, wären wir dir super dankbar für.
51:39
Weil wir wollen alles, was wir darüber bekommen, nehmen wir und
51:42
verbessern unseren Content, damit du noch schöneren Content
51:46
bekommen kannst. Und Yeah.
51:49
Genau und deswegen andere Unterstützung ist halt in dem
51:53
Sinne auch Feedback, konstruktives Feedback, das
51:55
hilft uns auch sehr weiter in dem Sinne würde ich sagen,
51:58
empfehlen den Podcast noch 2 Freunden weiter, wenn er dir
52:00
gefällt und ansonsten sind wir raus für heute.
52:04
Ich wünsch euch noch nen schönen Tag bis zum nächsten Mal deine
52:08
Coding Buddies gemeinsam. Besser.