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