Minimale Container-Images verzichten auf Komponenten wie Shells oder Paketmanager, die zur Laufzeit normalerweise nicht gebraucht werden. Sie sind auch als „distroless“ oder „chiseled“ Images bekannt. Weil weniger Komponenten weniger Schwachstellen bedeuten, reduzieren diese Images die Angriffsfläche und erhöhen dadurch die Sicherheit.
Weiterlesen nach der Anzeige
Dr. Marius Shekow war über 10 Jahre als Forscher und Softwareentwickler bei Fraunhofer tätig. Seit 2022 ist er Lead DevOps- & Cloud-Engineer bei SprintEins in Bonn. Dort baut er für Konzerne und KMUs individuelle Cloud-Umgebungen, inkl. CI/CD-Automatisierung, Observability und Security-Absicherung.
Schlüsselfertige Images für ein Basis-Linux sowie die Sprachen PHP, Python, Java, C# und Node.js hat Teil 2 der Artikelserie vorgestellt. Diese vorkonfektionierten Images passen jedoch nicht immer zu den eigenen Anforderungen und es kann notwendig sein, eigene zu erstellen. Dieser Artikel zeigt, wie Softwareentwicklerinnen und -entwickler eigene minimale Images basierend auf den Angeboten Ubuntu Chiseled, Chainguard/WolfiOS und Azure Linux bauen (siehe die folgende Tabelle).
| Drei Anbieter minimaler Images im Vergleich | |||
| Bewertungskriterium | Ubuntu Chiseled | WolfiOS / Chainguard | Azure Linux |
| Verfügbare Pakete | ~500 | ~3000 | ~3000 |
| Qualität der Dokumentation / Schwierigkeit der Nutzung | ➕➕ | ➕➕➕ | ➕ |
| Integrationsgeschwindigkeit von Paket-Versionsupdates (Upstream) | Langsam | Schnell | Mittel |
| Reproduzierbare Image-Builds / Pinnen der zu installierenden Paket-Versionen | ❌ | ✅ | ❌ |
| Kommerzieller Support | ✅ | ✅ | ❌ |
Canonical verwendet die Bezeichnung „Chiseled“ für minimale, Ubuntu-basierte Images. Ein Blogbeitrag stellt das Chisel-CLI von Ubuntu vor. Chisel ist ein Build-Tool, das Entwickler mit der gewünschten Ubuntu-Version (beispielsweise „24.04“) und einer Liste von „Slices“ aufrufen, die Chisel zu einem neuen Root-Filesystem zusammenbaut. Dieses Filesystem kopiert man anschließend in ein leeres scratch-Image, wie der Ablaufplan in Abbildung 1 verdeutlicht:
Bau eines Chiseled-Image via Multi-Stage Dockerfile (Abb.1)
Das Ubuntu-Team hat einige (jedoch nicht alle) der offiziellen Ubuntu-Pakete in mehrere Slices aufgeteilt und diese auf GitHub veröffentlicht. Falls Slices für ein gewünschtes Paket fehlen, sollte man auf andere im Artikel erwähnte Ansätze wechseln. Denn bestehende GitHub Issues zeigen, dass reine Feature-Requests lange oder gänzlich ignoriert werden, und der Zeitinvest für die Einarbeitung für eigene Pull Requests (PRs) hoch ist.
Weiterlesen nach der Anzeige
Aufbauend auf Chisel stellt Canonical zudem das Rockcraft-Tool zur Verfügung, das auf einer höheren Abstraktionsebene arbeitet.
Bevor Entwickler tiefer in den Build-Prozess von Ubuntu Chiseled-Images einsteigen, sollten sie sich der folgenden zwei Einschränkungen bewusst sein:
Der einfachste Weg, ein Chiseled-Image zu erstellen, ist ein Docker Multi-Stage Build. Wie man für ein Python-Image (mit Python 3.12.3) auf Basis von Ubuntu 24.04 vorgeht, erklärt das offizielle Chisel-Tutorial.
Da Schwachstellenscanner wie Trivy oder Grype die Pakete im frisch gebauten Image leider nicht korrekt identifizieren können, sind weitere Anpassungen am Dockerfile nötig. Der Grund dafür, warum die Scanner relevante Schwachstellen übersehen, geht aus einem GitHub Issue hervor: Ubuntu hat entschieden, für Chisel-Images ein eigenes proprietäres Paket-Manifest-Format zu erfinden, das Scanner wie Trivy bisher nicht verstehen.
Ubuntu versucht daher mit Scanner-Anbietern zusammenzuarbeiten, wie beispielsweise eine GitHub-Diskussion zu Trivy zeigt. Bis es so weit ist, können Entwickler einen Workaround nutzen: Das chisel-wrapper-Skript generiert Metadaten im Standard-Debian-Paket-Format, das Scanner wie Trivy verstehen. Dazu sind im Dockerfile des Multi-Stage-Builds (vom offiziellen Tutorial) folgende Änderungen vorzunehmen:
# Einfügen der folgenden 3 RUN-Zeilen, irgendwo vor dem "chisel cut" Befehl des Tutorials:
# "file" wird vom chisel-wrapper script benötigt
RUN apt-get update && apt-get install -y git file
RUN git clone --depth 1 -b main /rocks-toolbox && mv /rocks-toolbox/chisel-wrapper /usr/local/bin/ && rm -rf /rocks-toolbox
RUN mkdir -p /staging-rootfs/var/lib/dpkg
# Ersetzen der RUN-Zeile, die den "chisel cut" Befehl ausführt, mit folgender Zeile:
RUN chisel-wrapper --generate-dpkg-status /staging-rootfs/var/lib/dpkg/status -- --release "ubuntu-$UBUNTU_RELEASE" --root /staging-rootfs
Ein vollständiges Beispiel für Python 3 liegt im GitHub-Repository des Autors öffentlich parat. Es veranschaulicht den Build einer Flask-basierten Demo-Anwendung. Zudem demonstriert es, wie man ein Problem löst, das dadurch entsteht, dass der Python-Interpreter im Chiseled Basis-Image an einem anderen Pfad liegt als beim python-Image, das in der Build-Stage verwendet wird. Ein weiteres GitHub-Gist des Autors zeigt, wie man ein Chiseled Java JRE-Image erstellt und darin die Springboot-Petclinic-Anwendung ausführt.
Ein weiterer Ansatz, Ubuntu Chiseled Images zu erstellen, ist das Rockcraft-CLI, das auf einer höheren Abstraktionsebene als Chisel arbeitet.
Rockcraft greift intern auf Chisel zurück, um das Root-Filesystem zu erstellen. Über eine von Rockcraft eingelesene YAML-Datei legt man deklarativ die folgenden Aspekte fest:
Mit Rockcraft erstellte, vorgefertigte Images lassen sich mit dem Suchbegriff „chisel“ in der Canonical GitHub-Organisation finden, beispielsweise:
Die größten Nachteile von Rockcraft sind:
ENTRYPOINT für das Image gesetzt wird. Dies ist unnötig, denn im Gegensatz zur Vorgehensweise bei virtuellen Maschinen (VMs) sind Service-Manager bei Containern nicht üblich. In diesen Umgebungen ist es gewollt, dass der gesamte Container beendet wird, wenn das im ENTRYPOINT festgelegte Programm abstürzt. Denn Container Runtimes wie Docker Compose oder Kubernetes überwachen den Container-Status und starten ihn dann neu. Zudem finden Schwachstellenscanner wie Trivy im Pebble-Binary häufig CVEs. Diese stellen zwar meistens keine Bedrohung dar, verursachen allerdings unnötigen Diagnose-Aufwand.Um sichere, minimale Images zu erstellen, ist es daher empfehlenswert, direkt das Chisel-CLI statt Rockcraft zu verwenden. Dennoch lohnt sich ein Blick in die stage-packages-Einträge der rockcraft.yaml-Dateien in den oben gelisteten Repositorys (beispielsweise für Python), um eine Idee dafür zu bekommen, welche Slices im eigenen Image sinnvoll sind.
Eine Sicherheitslücke im schlanken SSH-Server Dropbear ermöglicht Angreifern, ihre Rechte im System auszuweiten. Aktualisierte Softwarepakete schließen die Sicherheitslücke.
Weiterlesen nach der Anzeige
Dropbear kommt aufgrund seiner geringen Größe oftmals auf Single-Board-Computersystemen und Routern zum Einsatz, etwa in OpenWRT. Jetzt haben die Entwickler die Dropbear-Version 2025.89 veröffentlicht und schreiben in der Ankündigung, dass bei älteren Fassungen bis einschließlich Dropbear 2024.84 Angreifer beliebige Programme im System als „root“ starten können, sofern sie eine Sicherheitslücke in Dropbear ausnutzen.
Ursache des Sicherheitslecks ist die Weiterleitung von Unix-Sockets. Andere Programme auf dem System können Unix-Sockets mittels SO_PEERCRED authentifizieren, was bei von Dropbear weitergeleiteten Verbindungen der User „root“ ist, was die Ausweitung der eigenen Rechte ermöglicht, führen die Dropbear-Programmierer aus (CVE-2025-14282, CVSS 9.8, Risiko „kritisch“).
Wer noch nicht aktualisieren kann, kann sich damit behelfen, den Zugriff auf Unix-Socket-Forwarding zu unterbinden. Das erledigt der Aufruf mit Kommandozeilenparameter dropbear -j – das deaktiviert jedoch zugleich auch TCP-Forwarding. Wer Dropbear aus den Quellen selbst baut, kann auch in den Header-Dateien „localoptions.h“ sowie „distrooptions.h“ einen Define passend setzen: „#define DROPBEAR_SVR_LOCALSTREAMFWD 0“ sorgt dafür, dass die anfällige Funktion nicht ausgeführt wird. Die vollständige Korrektur benötigt jedoch weiterreichende Änderungen.
„Die Weiterleitung von Unix-Sockets ist jetzt deaktiviert, wenn erzwungene Befehlsoptionen verwendet werden, da sie Befehlsbeschränkungen umgehen könnten“, erklären die Dropbear-Entwickler. Das stehe nicht direkt mit der Rechteausweitung in Verbindung, aber könnte die Ausführung beliebiger Befehle als korrekter User erlauben.
Die Risikoeinstufung als „kritisch“ der Schwachstelle stammt vom CERT-Bund. Wer Dropbear als SSH-Server einsetzt, sollte nach aktualisierten Paketen Ausschau halten und diese zeitnah installieren. Sofern das noch nicht möglich ist, hilft der vorgeschlagene Workaround, die eigene Installation abzusichern.
Weiterlesen nach der Anzeige
(dmk)
Mehr Europäische Souveränität – weniger Abhängigkeit von großen US-Konzernen. Das ist das zentrale Versprechen des Digitalen Euro. Doch immer wenn über technische Standards beim Digitalen Euro geredet wird, sitzen US-amerikanische Big Tech- und Finanzkonzerne mit am Tisch. Mastercard ist sogar an einem der Unternehmen beteiligt, die den Digitalen Euro zum Leben erwecken sollen.
Der Digitale Euro (D€) soll das grenzüberschreitende Bezahlen möglich machen und damit das Oligopol von Mastercard, Visa und PayPal aufbrechen. Spätestens seit der Rückkehr von Donald Trump ins Weiße Haus begründen Befürworter:innen das Projekt der EZB auch mit Europäischer Souveränität.
So verweist Burkhard Balz, Vorstand der Bundesbank, im Tagesspiegel auf das Schicksal des brasilianischen Richters Alexandre de Moraes, der zuerst den ehemaligen brasilianischen Präsidenten Bolsonaro für seinen Putschversuch verurteilte. Die Trump-Regierung sanktionierte daraufhin den Richter und schloss ihn so de-facto vom Finanzsystem aus. Ähnliche Szenarien seien im europäischen Zahlungsverkehr denkbar. US-Anbieter „können dann darüber entscheiden, ob wir Europäer digital zahlen können oder nicht“, schreibt Bundesbanker Balz.
Weniger Abhängigkeit von US-Firmen ist also das Ziel des D€, insbesondere von Mastercard und Visa, die das bargeldlose Bezahlen in Europa dominieren. Umgesetzt werden soll das auf der einen Seite von EU-Kommission, Ministerrat und Europäischem Parlament – den EU-Gesetzgebern. Sie arbeiten an einem Gesetzespaket zum Digitalen Euro. Auf der anderen Seite arbeitet die Europäische Zentralbank (EZB) bereits an der Umsetzung. Und genau dort wirft der Einfluss von US-Konzernen Fragen auf.
Denn ausgerechnet Mastercard ist auch an einem wichtigen Unternehmen für die Entwicklung des Digitalen Euro beteiligt. Der gleiche Digitale Euro, der uns unabhängiger von Mastercard machen soll.
Denn zur Umsetzung des D€ hat die EZB bereits Aufträge vergeben. Unter Vertrag genommen wurden zehn Unternehmen für insgesamt fünf Aufträge: Alias-System, App und Software Entwicklung, Offline-Lösung, Risko- und Betrugsmanagement sowie sicherer Austausch von Zahlungsinformationen.
Einen Teil der Ausschreibung zur App-Entwicklung gewann die italienische Firma Fabrick. Mastercard hat Anteile an dem Unternehmen, das mehrheitlich zur italienischen Banca Sella Gruppe gehört. Mastercard kaufte sich 2023 in das Unternehmen ein, wie ein Pressemitteilung zeigt, und hält die Anteile bis heute. Wie viele Anteile Mastercard an Fabrick besitzt, ist unklar. Beide Unternehmen haben nicht auf Anfragen von netzpolitik.org reagiert.
Bruno de Conti von der NGO Positive Money führt die Beteiligung von Mastercard auf die hohe Konzentration und Vernetzung innerhalb des Finanzmarkts zurück, er sei daher nicht überrascht gewesen, dass Mastercard an einem der Unternehmen beteiligt gewesen sei. „Dennoch stellt das ein Risiko dar“, warnt de Conti. Es brauche einen möglichst transparenten Prozess und eine starke EZB, die das Gemeinwohl verteidige.
Rechtsprofessor Andreas Kerkemeyer von der TU Darmstadt findet die Minderheitsbeteiligung von Mastercard zumindest überraschend: „Es ist wichtig für das Gelingen des Digitalen Euros, dass die Unternehmen, mit denen die EZB zusammenarbeitet, um die Kernfunktionen bereitzustellen, ihren Sitz in Europa haben, in europäischer Hand sind und auch nicht von nicht-europäischen Unternehmen aufgekauft werden.“
Die EZB teilt auf Anfrage mit, dass die Verträge und Ausschreibungen eine Bedingung beinhalten, um die europäische Autonomie zu sichern. Dieser Bedingung zur Folge müssen alle Dienstleister des Digitalen Euro europäisch kontrolliert sein, also von einem Unternehmen mit Sitz in der EU oder einem EU-Bürger. Die EZB schreibt:
Kontrolle’ bedeutet die Möglichkeit, direkt oder indirekt über ein oder mehrere zwischengeschaltete Unternehmen einen entscheidenden Einfluss auf ein Unternehmen auszuüben. Die Kontrolle kann in einer der folgenden Formen ausgeübt werden: direkte oder indirekte Beteiligung von mehr als 50 % des Nennwerts des ausgegebenen Aktienkapitals der betreffenden juristischen Person oder Mehrheit der Stimmrechte der Aktionäre oder Gesellschafter dieser Person.
Die Minderheitsbeteiligung von Mastercard habe „offenbar keine ‚Kontrolle‘ über den Anbieter zur Folge und wirkt sich daher nicht auf die Eignung des Anbieters aus, Arbeiten und Dienstleistungen für die EZB zu erbringen“, antwortet die EZB auf netzpolitik.org-Anfrage.
Neben der Unternehmensbeteiligung ist Mastercard noch an einer anderen Stelle in der Umsetzung des Digitalen Euro mindestens involviert – ebenso wie einige US-amerikanische Big Tech-Konzerne.
Denn ein wichtiger Teil der D€-Umsetzung geschieht in der Rulebook Development Group (RDG). Diese arbeitet ein Rulebook („Regelwerk“) aus, in welchem einheitliche Regeln und technische Standards festgelegt sind. Besonders relevant ist das für die Unternehmen, die die zukünftigen Zahlungsprozesse abwickeln, etwa Banken oder andere Zahlungsdienstanbieter. Nach Auskunft der Bundesbank wurde die RDG „ins Leben gerufen, um eine Branchenperspektive auf den Entwurf des Regelwerks für den digitalen Euro zu gewinnen.“
Doch mit am Tisch sitzen auch Verbände, deren Mitglieder große US-amerikanischen Unternehmen sind, also genau die, von denen die EZB die europäische Abhängigkeit reduzieren möchte.
Bundesbank und EZB verteidigen auf Anfrage die indirekte Präsenz von US-Konzernen in der RDG. So schreibt die EZB: „Alle derzeitigen RDG-Mitglieder aus dem privaten Sektor stammen aus einem europäischen Verband oder sind mit privaten Institutionen/Unternehmen mit Sitz in der EU verbunden.“ Das schließt allerdings auch Tochterunternehmen nicht-europäischer Konzerne mit ein.
Zudem seien die in der RDG ausgehandelten Regeln nicht verbindlich. „Die Rolle der RDG-Mitglieder ist beratend“, schreibt die Bundesbank auf netzpolitik.org-Anfrage. Die Verantwortung und Eigentümerschaft des Regelwerks bleibe beim Eurosystem. Auch die EZB betont, dass die letztendliche Entscheidung bei ihr liege: „Ein endgültiger Entwurf des vorläufigen Regelwerks wird einer öffentlichen Konsultation unterzogen. Anschließend wird das Regelwerk für den digitalen Euro dem EZB-Rat zur Prüfung und anschließenden Genehmigung vorgelegt.“
Expert:innen aus der Zivilgesellschaft sehen die indirekte Beteiligung von großen US-Konzernen kritischer. So sagt Carolina Melches zu netzpolitik.org: „Dass US-Unternehmen indirekt mit am Tisch sitzen, zeigt die problematische Allgegenwärtigkeit dieser Unternehmen im europäischen Zahlungsverkehr. Will man wichtige Stakeholder dabeihaben, kommt man an den US-Anbietern kaum vorbei.“
Bruno de Conti von der Nichtregierungsorganisation Positive Money Europe warnt, dass es beim Rulebook um „wesentliche Entscheidungen“ gehe. Die Einbindung von privaten Firmen bei Projekten wie dem Digitalen Euro sei auch eine Strategie der Zentralbanken, „um die Zurückhaltung vieler privater Unternehmen in Bezug auf digitale Zentralbankwährungen zu verringern“, schreibt de Conti auf Anfrage.
US-Digitalkonzerne könnten versuchen, auf einen möglichst unattraktiven Digitalen Euro hinzuarbeiten, aber es könnte auch auf eine interoperable Lösung hinauslaufen, so de Conti weiter. Die Frage nach der Problematik der Beteiligung von großen US-Konzernen „betrifft also weniger die Einbeziehung an sich, sondern vielmehr den Einfluss, den sie in den Gesprächen hatten – etwas, über das wir erschreckend wenig wissen.“
Professor Andreas Kerkemeyer ist von der mindestens indirekten Beteiligung der US-Konzerne an der RDG nicht beunruhigt. „Da der Zugang zum Digitalen Euro für die Nutzer nicht über die EZB oder das Eurosystem erfolgt, sondern über (digitale) Zahlungsdienstleister, macht es schon Sinn mit all denjenigen zusprechen, die in diesem Markt aktiv sind“, sagt der Jura-Professor im Gespräch mit netzpolitik.org.
Für Kerkemeyer „besteht immer die Gefahr eines ‚regulatory capture‘, wenn die Vertreter von Firmen an Rechtsregeln mitarbeiten.“ Regulatory capture meint das Kapern einer Institution, die eigentlich dem Gemeinwohl dienen soll, durch einzelne Lobbygruppen.
„Allerdings steuert die EZB den Prozess maßgeblich, sie hat den Vorsitz und das Sekretariat der RDG inne und am Ende entscheidet sie über das Rulebook“, so Kerkemeyer. Außerdem habe die RDG noch mehr Mitglieder als die oben angesprochenen Verbände.
Dass der Digitale Euro gelinge, sehen alle drei Expert:innen auch in der Verantwortung von Parlament und Rat, diese beraten aktuell über das Gesetzespaket zum Digitalen Euro. So sagt Andreas Kerkemeyer: „In der Verordnung werden die wesentlichen Entscheidungen über den Digitalen Euro getroffen. Es ist klar, dass sich das Rulebook innerhalb des Rahmens der Verordnung bewegen muss.“
Carolina Melches von Finanzwende betont: Der Digitale Euro könne nur dann ein echtes Gegengewicht zu US-amerikanischen Anbietern werden, „wenn Infrastruktur und Betrieb bei seiner Einführung rein europäisch sind“. Hierfür müssten sich auch die EU-Gesetzgeber einsetzen.
Aus Sicht von Positive Money Europe ist das Europäische Parlament aktuell die größte Hürde, um Abhängigkeiten von den USA abzubauen. De Conti bezieht sich damit auf den Entwurf von Berichterstatter Navarrete, der im November im Wirtschaftsausschuss diskutiert wurde. Navarrete hatte vorgeschlagen, einen Online-D€ nur dann einzuführen, wenn bis zu seiner Einführung keine privat-wirtschaftliche pan-europäische Alternative bereitstünde.
Dieser Ansatz sei „kurzsichtig“, kritisiert de Conti: „Würde ein solches System letztendlich von einem Nicht-EU-Unternehmen aufgekauft, stünden wir wieder am Anfang – nur mit einer noch größeren Verzögerung bei der Entwicklung eines umsetzbaren und zuverlässigen Plans und einer weiteren Konsolidierung der Marktmacht in den Händen von Nicht-EU-Unternehmen.“
Das Berliner Unternehmen Outfittery wirbt mit einem innovativen Konzept: Kunden bekommen individuell auf sie abgestimmte Outfits statt einzelner Kleidungsstücke. Seit Anfang Dezember gibt es obendrein jedoch auch Phishing-Versuche. Diese verweisen auf offizielle Outfittery-Domains und stammen offenbar aus den Systemen des Unternehmens selbst. Eine persönliche Spurensuche.
Weiterlesen nach der Anzeige
In der Vorweihnachtszeit trudeln allerlei Newsletter und Angebote im digitalen Postfach ein: Da möchte ein Versand auf seine Bestellfristen vor dem Fest hinweisen, ein Onlineshop hat Geschenkideen für die Lieben und ein dritter bittet um dringende Aktualisierung der Zahlungsdaten. So weit, so normal, doch halt: Irgendwas ist komisch an der E-Mail von Outfittery.
Die Aufmachung der Nachricht, die am 5. Dezember um 9:20 vormittags in meiner Inbox eintrudelte, erinnert stark an die Designsprache von Outfittery: Vor pastellfarbenem Hintergrund bewegen sich modische, aufeinander abgestimmte Kleidungsstücke. Auf Englisch werde ich – mit Vornamen angesprochen – auf ein Problem mit meiner Bezahlmethode aufmerksam gemacht und gebeten, über einen blau markierten Link eine Aktualisierung vorzunehmen. Nur so könne meine Mitgliedschaft weitergehen.
Phishingmail von Outfittery: Bitte dringend Zahlungsdaten ändern
Allein: welche Mitgliedschaft? Schließlich habe ich den Dienst nie wirklich genutzt, sondern lediglich einmal ein Outfit zusammengestellt und somit auch nie Zahlungsdaten hinterlegt. Die E-Mail war zudem an die mit meinem Facebook-Konto verbundene Mailadresse adressiert – für echte Kundenkonten verwende ich individuelle Adressen.
Weiterlesen nach der Anzeige
Ein genauerer Blick auf die URL, die hinter dem blauen Button, aber auch alle anderen Links in der E-Mail hinterlegt ist: Sie zeigt auf http://lnk.stylist.outfittery.com/ls/click?upn=, kann also auch dem Unternehmen zugeordnet werden, das international tätig ist. Dass der Trackinglink per HTTP-URL aufgerufen wird und somit offenbar zu den letzten unverschlüsselten Webseiten der Welt gehört – geschenkt. Beim Klick lande ich jedoch an einer unerwarteten Stelle: Zunächst wird der HTTP- auf einen HTTPS-Link umgebogen (ich fühle mich gleich viel sicherer), dann jedoch auf die kryptische Adresse weitergeleitet. Dort befand sich zunächst eine Phishing-Seite (registriert am 2. Dezember), aktuell die Sperrseite eines Hosters namens CloudAccess.
Betrug erkannt: Der Hoster sperrte die Outfittery-Phishingseite.
Offenbar hatten Kriminelle also zumindest kurzzeitig Zugriff auf das System, mit dem Outfittery Tracking-Links für seine Marketingmails erstellt. Sie haben einen Link erstellt, der sein wahres Ziel maskiert und ihm den Ruch der Legitimität verleiht – und das bis heute: Auch am 18. Dezember, fast zwei Wochen nach der E-Mail, funktioniert die böswillige Weiterleitung.
Und woher kam die E-Mail? Dem leidgeprüften Mailserver-Veteranen bleibt der reflexartige Griff zur Tastenkombination Strg-U, um die Quellansicht zu öffnen und die Mailheader zu begutachten. Und die zeigen: Die Mail wurde über einen Server versandt, der als legitime Quelle von E-Mails der Firma Outfittery gilt. Das beweisen die gültigen DKIM-Header. Die Rückwärtsauflösung passt zum DNS-Eintrag, die IP gehört zum Maildienstleister Twilio (früher Sendgrid). Zudem ergibt die E-Mail keine Hinweise auf simple Header-Fälschtricks, wie Spammer sie seit Jahrzehnten verwenden.
Kurze Wege: Der Mailserver von Outfittery kippte die Phishingmail direkt bei meinem ein. Das erleichtert die Rückverfolgung.
Nach der Analyse wird klar: Da wurde eine E-Mail über Outfitterys technische Plattform versendet, sie enthält einen Link zur offiziellen Domain des Unternehmens, verweist aber auf einen Phishing-Link. Das deutet auf einen Sicherheitsvorfall hin. So schätzten auch mehrere Leser die Sachlage ein, die uns im Laufe der vergangenen Woche von gleichlautenden E-Mails berichteten. Ein Einzelfall scheint also ausgeschlossen, unklar bleibt jedoch die Quelle des Vorfalls. Gab es einen Einbruch in die Systeme von Outfittery oder des Maildienstleisters? Sind womöglich personenbezogene Daten abgeflossen?
Es wurde Zeit, bei Outfittery nachzufragen. Am 9. Dezember stellte ich dem Unternehmen die üblichen Fragen: Woran hat et jelegen, welche Daten wurden kompromittiert und welche Gegenmaßnahmen traf Outfittery? Auf meine Anfrage an die Support- und Datenschutzadresse antwortete das Unternehmen nicht. Eine Woche später hakte ich nach und nahm die mutmaßliche Adresse des Datenschutzbeauftragten der Konzernmutter, dpo@outfittery.com, in den Verteilerkreis auf. Diese Adresse antwortete mir umgehend: mit einer Unzustellbarkeitsnachricht.
Ansonsten herrschte Funkstille, obwohl ich um Antwort bis zum gestrigen 17. Dezember bat. Auch telefonisch macht Outfittery sich rar: Unter der Berliner Telefonnummer, die in der Datenschutzerklärung hinterlegt ist, hört der geneigte Redakteur lediglich eine Bandansage, man habe den Telefonsupport leider eingestellt. Das Unternehmen wechselte kürzlich den Besitzer: Im März verkündete der Geschäftsführer des spanischen Unternehmens Lookiero gemeinsam mit Julia Bösch, der Gründerin des Berliner Unternehmens eine Fusion. Bösch sowie der Prokurist schieden im August dieses Jahres aus der Geschäftsführung aus, die seitdem in spanischer Hand ist.
Dennoch bleibt unklar, was genau vorgefallen ist – auch unsere Leser berichten, auf ihre Anfragen ans Unternehmen keine Antwort erhalten zu haben. Licht ins Dunkel kann nun wohl nur noch eine Anfrage bei der Berliner Datenschutzbeauftragten liefern.
(cku)
Illustrierte Reise nach New York City › PAGE online
Aus Softwarefehlern lernen – Teil 3: Eine Marssonde gerät außer Kontrolle
Top 10: Die beste kabellose Überwachungskamera im Test
SK Rapid Wien erneuert visuelle Identität
Kommandozeile adé: Praktische, grafische Git-Verwaltung für den Mac
Neue PC-Spiele im November 2025: „Anno 117: Pax Romana“
Donnerstag: Deutsches Flugtaxi-Start-up am Ende, KI-Rechenzentren mit ARM-Chips
Arndt Benedikt rebranded GreatVita › PAGE online
