Hackback: Zurückhacken ist keine Lösung, sondern riskanter Blödsinn

1. GegenangriffHackback

Der Ukraine-Krieg befeuert mal wieder die Diskussion über Hackbacks. Ganz einfach formuliert ist ein Hackback ein digitaler Gegenschlag/Gegenangriff nach einem Hackerangriff. Unter anderem soll mit einem Hackback bspw. ein im Ausland stehender Server bzw. IT-System unbrauchbar gemacht werden, wenn von ihm Angriffe ausgehen. Für den Laien klingt das erstmal toll – vor allem, wenn Hackbacks dann noch als »aktive Cyberabwehr« bezeichnet werden. Um es ganz klar zu sagen: Ein Hackback ist keine defensive Maßnahme und sollte daher auch nicht mit dem Wort »Abwehr« geframt werden. Nachfolgend möchte ich anhand einiger Punkte aufzeigen, weshalb Hackbacks bei genauerer Betrachtung keine Lösung sind, sondern riskanter Blödsinn:

  • Legitimierung Hackback: Werten wir bereits den unbedachten Klick bzw. die Ausführung eines E-Mail-Anhangs, der anschließend die komplette Festplatte verschlüsselt und Lösegeld erpresst (Ransomware), als einen Angriff? Was zählt demnach als Angriff, der einen Hackback legitimiert?
  • Zeitnahe Reaktion: Damit ein Hackback überhaupt eine Wirkung erzielt, müsste eine zeitnahe Reaktion erfolgen, um das Risiko einzuhegen. Voraussetzung dafür ist allerdings, dass wir in der Lage sind, solche Angriffe überhaupt zu erkennen. Für Betreiber Kritischer Infrastrukturen (KRITIS) ist im IT-Sicherheitsgesetz bspw. eine Meldepflicht verankert, die Betreiber verpflichten, IT-Störungen (und damit auch Angriffe) an das BSI zu melden. Das Problem: Vor einer Meldung muss man in der Lage sein, eine IT-Störung bzw. Angriff überhaupt zu erkennen. Genau dazu sind viele Betreiber leider überhaupt nicht in der Lage. Oftmals bleiben Angriffe auf eine IT-Infrastruktur vollkommen unbemerkt. Bedauerlicherweise ist das auch keine Ausnahme, sondern die Regel.
  • Angreifer bestimmen (Attribution): Es ist nicht möglich, eindeutig zu beweisen/bestimmen, wo der Ursprung eines Angriffs ist. Waren es die Chinesen, die Russen, die Israelis, die US-Amerikaner? Das Auffinden einer IP-Adresse in einem Logfile eines kompromittierten Systems ist kein Beweis, sondern als Zuordnungsmerkmal schlichtweg wertlos. Selbst erfahrene IT-Forensiker können anhand der Vorgehensweise eines Angreifers bzw. seinen hinterlassenen Spuren (Schadcode etc.) lediglich Einschätzungen darüber abgeben, wo der Ursprung eines Angriffs sein könnte. Ein Angreifer könnte auch vorsätzlich eine falsche Fährte legen, um den Verdacht auf eine bestimmte Organisation/Geheimdienst etc. zu lenken.
  • Wer ist zuständig für den Gegenangriff?: Wer führt in Deutschland einen Hackback überhaupt durch? Ist dafür nun der Bundesnachrichtendienst (BND), der Verfassungsschutz (BfV), das Bundeskriminalamt (BKA) oder die Bundespolizei (BPOL) zuständig? Die Genannten kann man wohl aus den unterschiedlichsten Gründen alle ausschließen. Bleibt also noch die Bundeswehr. Damit die Bundeswehr überhaupt tätig werden darf, muss es sich um einen Spannungsfall oder Verteidigungsfall handeln. Womit wir wieder beim Punkt »Angreifer bestimmen« wären. Wen soll ich denn angreifen, wenn ich nicht mal eindeutig bestimmen kann, wer mich überhaupt angreift? Nein, auch die Bundeswehr kommt eigentlich nicht infrage, um Gegenangriffe durchzuführen, denn dies würde einer Militarisierung des »Cyberraums« gleichkommen, die eher zu einer Eskalation von Konflikten beiträgt. Davon abgesehen fehlt es den staatlichen Institutionen schlichtweg an qualifiziertem Personal. Am Ende bleibt die Erkenntnis, dass niemand von staatlicher Seite geeignet ist, die digitalen Gegenangriffe überhaupt durchzuführen und zu verantworten.
  • Schwachstellen zurückhalten: Damit ein Hackback gelingt, ist die Ausnutzung einer Schwachstelle erforderlich – also die Schwäche eines Systems, an dem es verwundbar sein kann. Solche Schwachstellen sind grundsätzlich in allen (IT-)Systemen vorhanden. Unter anderem durch sog. Exploits ist es nun möglich, solche Schwachstellen systematisch ausnutzen. Das Wissen über Schwachstellen in häufig verwendeter Hard- und Software bzw. anwendbare Exploits sind demnach eine Voraussetzung für den digitalen Gegenangriff. Und hier entsteht nun ein moralischer Konflikt. Soll eine gefundene Schwachstelle für einen digitalen Gegenangriff genutzt werden, anstatt den Softwarehersteller auf verwundbare Stellen aufmerksam zu machen? Was bspw. passieren kann, wenn Schwachstellen wissentlich zurückgehalten werden, anstatt diese zu melden, führen Vorfälle/Veröffentlichungen wie Vault 7 oder The Shadow Brokers eindringlich vor Augen. Das Zurückhalten von gefundenen Schwachstellen ist schlichtweg unmoralisch und stellt eine allgemeine Gefährdung der Informationssicherheit dar, die jeden (be-)treffen kann.
  • Förderung des Exploit-Handels: Das Auffinden von Schwachstellen bzw. das Entwerfen von Exploits benötigt (meist) fundierte Kenntnisse der Informationssicherheit. Da wir davon ausgehen können, dass es einer staatlichen Institution in Deutschland an ausreichend qualifiziertem Personal fehlt, ist die Frage, woher dieses Wissen kommen soll. Die Lösung: Der Aufkauf von sogenannten Zero-Day-Schwachstellen, also einer bis dahin noch nicht bekannten Lücke. Allerdings ist dies nicht nur kostspielig, sondern fördert letztendlich einen (illegalen Schwarz-)Markt für IT-Sicherheitslücken. Anstatt die gefundenen Sicherheitslücken an die Hersteller zu melden, floriert der Handel mit Zero-Day-Exploits. Klar, es ist lukrativer, die Exploits an den Meistbietenden zu verkaufen, anstatt moralisch/korrekt (Responsible Disclosure) zu handeln.
  • Weitere Angriffe verhindern: Befürworter von Hackbacks argumentieren gerne damit, dass dies weitere Angriffe verhindern würde. Dieser Argumentation kann ich mich nicht im Geringsten anschließen. Eher das Gegenteil wird der Fall sein. Ein Hackback wird immer eine Gegenreaktion hervorrufen und in den seltensten Fällen einfach unbeantwortet bleiben. Zu glauben, Hackbacks würden also weitere Angriffe verhindern, ist reines Wunschdenken.

2. Cyber-Resilienz anstatt Hackbacks

Nein, wir brauchen keine verfassungsrechtlich hochproblematischen Hackbacks. Was wir brauchen, ist Folgendes:

  • Insbesondere die Software bei KRITIS sollte ausnahmslos auf Open-Source basieren
  • Befreiung von der Abhängigkeit durch Tech-Konzerne wie Microsoft, Google und Co.
  • Für IT-Berufe, die im Umfeld der Softwareentwicklung arbeiten, muss eine Ausbildung zur sicheren Entwicklung von Software verpflichtend sein
  • Verpflichtung für staatliche Akteure, bekannt gewordene Schwachstellen zu melden (Responsible Disclosure)
  • Obwohl ich den Begriff nicht mag, inhaltlich kann ich mich anschließen: Cyber-Resilienz
  • Eine Bildungspolitik, die Kernkompetenzen wie Medienkompetenz nicht nur zu einem zentralen Bildungsziel erklärt, sondern dies auch ernsthaft umsetzt
  • […]

Der Kuketz-Blog ist spendenfinanziert!

Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.

Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.

Mitmachen ➡

3. Fazit

Ich glaube, es ist an der Zeit, die Ampel-Koalition an den Koalitionsvertrag (S. 16) zu erinnern:

[…] Wir verpflichten alle staatlichen Stellen, ihnen bekannte Sicherheitslücken beim BSI zu melden und sich regelmäßig einer externen Überprüfung ihrer IT-Systeme zu unterziehen. Das Identifizieren, Melden und Schließen von Sicherheitslücken in einem verantwortlichen Verfahren, z. B. in der IT-Sicherheitsforschung, soll legal durchführbar sein. Hackbacks lehnen wir als Mittel der Cyberabwehr grundsätzlich ab. Nicht-vertrauenswürdige Unternehmen werden beim Ausbau kritischer Infrastrukturen nicht beteiligt.

Daran sollte auch der Ukraine-Krieg nichts ändern. Und allen, die Hackbacks befürworten, möchte ich entgegen: Cybert euch doch selbst!

Bildquellen:

Cyber Attack: Smashicons from www.flaticon.com is licensed by CC 3.0 BY

Über den Autor | Kuketz

Mike Kuketz

In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.

Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.

Mehr Erfahren ➡

SpendeUnterstützen

Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.

Folge dem Blog

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡


Diskussion

2 Ergänzungen zu “Hackback: Zurückhacken ist keine Lösung, sondern riskanter Blödsinn”

  1. Comment Avatar Max sagt:

    Ein weiterer Punkt:
    – Man kann sich nicht einfach auf Befehl oder Knopfdruck irgendwo reinhacken – das erfordert Zeit und Geduld. Das bedeutet, dass man entweder nicht handlungsfähig ist, weil jeder Hackback mit Glück Tage, in der Regel jedoch Wochen bis Monate dauert, oder dass man sich vorab in sämtliche auffindbaren Systeme hacken müsste, was einem digitalen Angriffskrieg gleichkommt.

  2. Comment Avatar Markus sagt:

    Fefe hatte genau zu dem Thema schon im Herbst 2019 ein paar Folien mit dem Titel „Hackback — tolle Idee?“ gemacht und die sind auch heute noch aktuell (Navigation mit den Pfeiltasten): https://ptrace.fefe.de/Hackback/

HilfeWenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-Forum

Abschließender Hinweis

Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.

Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.