Seite wählen

NETWAYS Blog

How I met your C2 : Basic Operational Security for Defense and Offense

Throughout this blogpost I want to share some awareness on search engines and current trends of fingerprinting. Some parts have tags for defense and offense. In the following Black Hats are considered evil and destructive, whereas Red Teams simulate Black Hats, allowing organizations to test their effective defenses by Blue Teams.

Warning: Make sure to follow your countries jurisdiction on using Shodan and Censys. In most countries querying keywords is not an issue for public available data, as it is public and has been harvested and tagged by the search engine itself already. This is just like google dorking something like Grafana intitle:Grafana – Home inurl:/orgid, private Keys: site:pastebin.com intext:“—–BEGIN RSA PRIVATE KEY—–“ , or AWS Buckets: site:http://s3.amazonaws.com intitle:index.of.bucket .

Browser fingerprinting & custom malware

Sites like amiunique directly show how WebGL and other metadata tracks us. This is why TOR disables Javascript entirely and warns you about going fullscreen.

Offense:

Beef  and Evilgophish would be two OSS frameworks for fishing and victim browser exploitation, which have profiling included.

Defense:

You could use:
1) User Agent Spoofer for changing your Operating System
2) Squid in Paranoid Mode, to shred as many OS & hardware details as possible
3) Proxychains with Proxybroker to collect and rotate IPs. KASM allowing containerized throw away workspaces would also throw many attackers off conveniently.

Infrastructure tracking

Shodan has a list of filters to set, depending on your payment plan. Often advanced payment planes are not necessary (but you are limited to a number of queries/day), more so the correct hashes and keywords.

Recently Michal Koczwara a Threat Hunter, shared some great posts on targeting Black Hat infrastrastructure.

JARM TLS Fingerprinting

Firstly, what is a C2? It is a Command & Controll server that has Remote Code Execution over all the malware agents. Cobalt Strike is one of the top two C2 for Red Teamers and Black Hats. An analogy to monitoring would be an Icinga Master, which has visibility, alerting & code execution over multiple monitoring agents.

Defense:

Salesforce JARM is an amazing way to fingerprint the TLS handshaking method. This is because a TLS handshake is very unique, in addition to bundled TLS ciphers used. A basic Shodan query for this would be: ssl.jarm:“$ID-JARM“. Of course C2 developers could update their frameworks (but most don’t).

Below you see a query of Cobalt Strike JARM C2s and the top countries it is deployed in. Of course servers are individually visible too, but at this point I try to not leak the IPs.

.

This also works for Deimos C2, or any other C2.

You can find various lists of JARM hashes, and all you need to do is run JARM against an IP and port, to create your own lists. This could scale greatly tcpdump, Elastic or my little detector collecting IPs, and alert on the very first TCP connection (basically on the first stager phase of the malware, before any modules are pulled off the C2).

Offense:

Put your C2 behind a proxy, make sure to select a good C2 for operational security, and add randomization for the JARM.

Http.Favicon Hashes

For Favicons: Use Hash Calculators like this one here. This is quite common in bounty hunting to avoid Web Application Firewalls if the server has internet access without a full WAF tunnel. A basic Shodan query would be look this: http.favicon.hash:-$ID.

Http.html Hashes

There are even more OSINT indicators like those ones by BusidoUK which show http.html hashes impact on Metasploit http.html:“msf4″ or Miners http.html:“XMRig“. Some Black Hats or Red Teamers don’t even bother to put any authentication on their C2s at all?

 

Http.hml Hashes are brutal! You even find literally anything online, even defensive products like Nessus http.html:“nessus“

or Kibana http.html:“kibana“.

Fingerprinting Honeypots

Interestingly the chinese Version of Shodan, Zoomeye, is also offering fingerprinting honeypot detection in the VIP and Enterprise models. Some honeypots should really work on their Opsec, but of course this is an expensive cat and mouse game, and pull requests are always welcome right.

As of now I am diving more into honeypots with Elastic backends, and even complete Active Directory Honeypots, to help you as our customers more in the future.

In case you’re interested in consultancy services about Icinga 2, Elastic or another of our supported applications feel free to contact us at any time!

 

NWS – Unsere Infrastruktur und SLAs

Es gab wahrhaftig schon mal einfachere Zeiten:

Zuerst bringt die Corona-Pandemie das öffentliche Leben über Jahre hinweg zum Erliegen und treibt die Leute in die Isolation. Zugegeben: uns als Hosting Provider kam der durch das Homeoffice gestiegene Bedarf an virtuellen Kommunikationsmitteln durchaus auch zu Gute. Die ständige Ungewissheit und die Sorge um die Gesundheit im persönlichen Umfeld waren aber dennoch eine immense Belastung für uns alle.

Und als ob das nicht schon genug gewesen wäre, hebt der Krieg in der Ukraine nun auch noch unsere wirtschaftlichen und sozialen Grundfesten aus den Angeln. Die Preise für Energieträger jeglicher Art steigen explosionsartig und die Unternehmen müssen diese gestiegenen Kosten entsprechend weitergeben – die Folge: die Inflationsrate steigt unermüdlich und die Konsumlaune lässt nach. Die Leute sorgen sich, was der kommende Winter mit sich bringen wird.

Diese Sorge betrifft nicht nur die privaten Haushalte. Auch bei den Unternehmen macht sich eine gewisse Unruhe breit.

 

Diese Fragen erreichen uns häufig

Wir registrieren in den vergangenen Monaten vermehrt Anfragen, die sich um die Sicherheit unserer Hosting Services und der zu Grunde liegenden Infrastruktur drehen. Wie hoch sind unsere zugesicherten Verfügbarkeiten? Welche Reaktionszeiten haben wir? Was passiert bei Stromausfällen? Wo stehen unsere Rechenzentren? Wie sind diese gesichert?

Daher möchte ich im Folgenden noch einmal einen Überblick über die wichtigsten Punkte bezüglich unserer DSGVO- und Sicherheitsthemen geben.

 

Rechenzentren

Wir nutzen für unsere Kunden zwei ISO27001-zertifizierte Rechenzentren in Nürnberg, welche von Partnern betrieben werden. Da sämtliche Subunternehmer deutsche Unternehmen sind, befinden sich die Daten unserer Kunden stets im deutschen Rechtsraum und verlassen diesen zu keinem Zeitpunkt! Die Liste unserer Subunternehmer ist hier einsehbar.

 

Hardware und Infrastruktur

Beide Rechenzentren werden von uns völlig autark mit eigener Infrastruktur genutzt (Firewalls, Load Balancer, Switches etc.). Unsere Rechenzentren sind untereinander redundant mit 10.000 MBit/s per Glasfaser angebunden, sodass bei Problemen ein Failover auf den jeweils anderen Standort stattfinden kann. Die Unterverteilung innerhalb des Rechenzentrums erfolgt über 10.000 MBit/s Switches und jeweils zwei Ports pro Kundensystem.

Bezüglich der Hardware sind alle Komponenten redundant aufgebaut: vom Netzteil an jedem Server bis zu den Top of Rack Switches ist alles immer mindestens zwei Mal vorhanden. Gleiches gilt für alle Firewall-, Netzwerk und Spamfiltersysteme. Auch der Stromkreislauf ist immer über zwei verschiedene Stromkreisläufe abgebildet, welcher wiederum an der USV hängt.

 

Stromversorgung

Für den Fall einer Unterbrechung der Primärenergieversorgung werden Online-USV-Systeme vorgehalten, welche eine Autonomiezeit von über 10 Minuten gewährleisten. Gleichzeitig verfügen die RZs über für den Dauerbetrieb ausgelegte Netzersatzanlagen, welche redundant aufgebaut sind. Die hierfür erforderliche, auf Heizöl basierende Energiebevorratung erlaubt – abhängig vom Standort – einen Inselbetrieb von bis zu 72 Stunden. Ergänzt wird diese Bevorratung um entsprechende Lieferverträge mit einer Belieferungszusage von unter 24 Stunden.

An allen Standorten werden unvermindert monatliche Testläufe aller Netzersatzanlagen und jährliche Netzausfalltests durchgeführt.

 

Aufbau der Kunden-Systeme

Unsere Kunden können sich ihre Systeme immer hochverfügbar aufbauen, indem sie die jeweiligen Instanzen stets auf beide Availabiltiy Zones (RZ1 und RZ2) verteilen.

Als Storage-System bieten wir Ceph Cluster als Alternative zu local Disks direkt auf dem Hypervisor an. Hier wird der Storage von Haus aus immer dreifach redundant verteilt über unsere beiden Standorte auf NVMEs gespeichert. Man kann dadurch im Desaster-Fall die einzelnen VMs von dem ausgefallenem RZ auf das intakte evakuieren und hier dann den Storage einhängen.

Sind meine Dienste also entsprechend redundant aufgebaut, kann der Komplettausfall eines Rechenzentrums jederzeit problemlos verkraftet werden, ohne, dass meine gehosteten Services in ihrer Funktion beeinträchtigt sind!

 

Service Level Agreements

Dieser robuste Aufbau der Infrastruktur spiegelt sich auch in den zugesicherten Verfügbarkeiten unserer Hosting Services wider.

Aufgeteilt nach den jeweiligen Services können wir dementsprechend folgende Verfügbarkeiten zusichern:
Rechenzentrumsinfrastruktur (Stromversorgung, Klimatisierung): 99,99%
Netzinfrastruktur (Uplink Router, Cloud Gateways, TOR-Switches): 99,95%

Für Services und Ressourcen:
Virtuelle Maschinen “volume“: 99,9%
Virtuelle Maschinen „local disk“: 99,5%
VPC Gateway: 99,9%
Block Storage: 99,9%
S3 Storage: 99,9%
LBaaS: 99,5%
VPNaaS: 99,5%
K8s Control Plane: 99,5%
Managed Database: 99,5%
SaaS Produkte: 99,0%

In der detaillierte Beschreibung zu unseren Service Level Agreements findet Ihr auch ausführliche Infos zu unseren zugesicherten Reaktionszeiten und vielem mehr!

 

Gibt es noch offene Fragen?

Wir haben auf unserer Homepage auch noch mal eine Gesamtübersicht über alle DSGVO-Themen erstellt – dort finden sich all unsere Regelungen zu den AGBs, AVV, TOMs, SLAs und der Liste der Subunternehmer.

Sollten dennoch Fragen zum Thema ungeklärt geblieben sein, dann könnt Ihr Euch einfach via sales@netways.de an uns wenden! Wir freuen uns auf Euch!

Stefan Schneider
Stefan Schneider
Account Manager

Vor seiner Zeit bei NETWAYS hat Stefan als Projektmanager in einer Nürnberger Agentur dabei geholfen, Werbeprojekte auf die Straße zu bringen. Seit Juni 2017 ist er nun stolzes Mitglied der NETWAYS-Crew. Hier war er zuerst der Ansprechpartner für unserer Schulungen und kümmert sich aktuell um alle Anfragen rund um unser Hostingangebot. Die Freizeit vertreibt sich Stefan am liebsten mit Sport. Vom Joggen über Slacklining bis zum PennyBoard fahren ist er für alles zu haben.

Detector OSS IDS: How to Shellscript Your Own Little Free Intrusion Detection System

Today I’ll show you a side project I’ve been working on the past month to defend my personal systems and practice shell-scripting and forwarding logs. It is just a proof-of-concept that is work in progress. I have decided to share my project, because Open Source = Open World! You can find detector here on Github.

This small project follows 3 basic goals: a) minimal b) trustable c) modular & customizable:

  • Required Binaries for Checks: AWK, SED & GREP (en masse), Inotify-Tools, Tracee, TS, USBGuard, SocketStats, Dialog, (Nethogs)
  • Just run the ./install.sh or ./uninstall.sh
  • Comment or uncomment the execution of the scripts/modules in the central/privacy directories as you like

How it basically works:

– Runner: Create a 1) Systemd service with a timer, calling a 2) Watchdog with a timer, 3) calling a main (separating Operating Systems and module choices), 4) calling the modules

– Modules: 5) run checks 6) grep for exit codes  6) append a time-stamp 7) append a module tag (with a possible KV – filter for Logstash-Pipelines) ->> write to detecor-logfile | Optional:  9) output to Elastic (via Filebeat -> Logstash-Pipelines) 10) output to Icinga 2 (via passive-checks for more logic & free alerting)

Detector currently (2022/08/01) covers:

Dropping & tracking honeypots via inotifywait:

Tracking USBGuard:

Checking Camera & Microphone Activation:

Tracking Shells and Sub-Shells:

Tracking Established and Listening Sockets with their relevant Programs and PIDs, plus provided DNS-Servers and Wireguard:

Using Tracee from Aquasecurity with 4 cool flags: TRC-2 Anti-Debugging , TRC-6 kernel module loading, TRC-7 LD_PRELOAD, TRC-15 Hooking system calls:

Tracking Kernel-Symbol counters for changes on module export tables:

Now we can be happy, but why not send it to Elastic and do some more magic there?

Or add even more logic and alerting via Icinga 2! (All we have to do is create a template for a passive check, apply the passive check over a (Linux)-hostgroup and set up an API-User with the „actions/process-check-result“. Our icinga-pumper.sh POC Code gets automatically executed in the $central directory, and we save ourselves the Icinga 2 agent installation, while Icinga 2 authentication happens over a certificate deployed via Nextcloud or the likes. :

TrippleCross and badbpf are some very cool offensive projects with eBPF implants I’ll try to understand and study until the next blogpost. See you by then!

If you want to learn from the people that tought me to pull such a side-project off, mostly Dirk and Thomas, then come and join us!

DockerCon 2022: Wie geht Containersecurity?

Buzzwords wie Software Supply Chain, Container Security Scanning oder Software Bill of Materials (SBOM) sind in den vergangenen zwei Jahren vermehrt in aller Munde, nicht zuletzt aufgrund des anhaltenden Trends zur Containerisierung vormals monolithischer Anwendungen und deren Betrieb als sog. Microservices. Allerdings kann nach wie vor nicht jeder, der auf die ein oder andere Weise mit Docker oder Containern im Allgemeinen zu tun hat, etwas mit diesen Begriffen anfangen. Aus diesem Grund habe ich den Fokus meines virtuellen Besuchs der diesjährigen DockerCon auf genau diesen Themebereich – Containersecurity – gelegt und möglichst viele Best Practices für Dich zusammengefasst.

 

Die Ausgangslage

Die großen Sicherheitslücken der vergangenen zwei Jahre, sei es der Solarwinds-Breach oder die Log4J/Log4Shell-Exploits haben einmal mehr schmerzlich bewusst gemacht: In fast jedem Softwareprodukt, egal ob proprietär oder Open Source, befinden sich zahlreiche mehr oder weniger gut gepflegte Abhängigkeiten verschiedenster Maintainer – in vielen Applikationen stecken bis zu 80% Open Source Code, die es „auf dem Schirm“ zu behalten gilt. Dies gilt natürlich auch für Container(-images), die letzten Endes nichts anderes tun, als die Applikation zu bündeln und (weitestgehend) losgelöst vom ausführenden Hostsystem ausführbar zu machen.

Dennoch gelten Container paradoxerweise oft als besonders sicher, sei es aufgrund der von außen wahrgenommenen „Kapselung“ oder der geringen Größe – soviel potentiell vulnerable oder bösartige Software kann da doch gar nicht drinstecken, oder? Mögen diese Wahrnehmungen in der Theorie und im Bestfall auch stimmen, sieht die Praxis in den allermeisten Fällen anders aus, wie die ein oder andere Keynote im Rahmen der DockerCon gezeigt hat.

Laut SysDig, einem Spezialisten für Cloudsecurity, laufen 58% der in den einschlägigen Containerregistries (DockerHub, Google, Github, etc.) verfügbaren Containerimages als root, anstatt einen geeigneteren, unprivilegierten Nutzer zu verwenden. Außerdem beinhalten selbst die offiziellen, von den Registries kuratierten Containerimages beliebter Frameworks oder Distributionen dutzende detektierbare Schwachstellen.

Offensichtlich gibt es also zum Einen ein falsches Gefühl von Sicherheit innerhalb der Nutzergemeinschaft von Containern, zum Anderen aber schlichtweg keine Blaupause oder „OneFitsAll“-Lösung, die für beliebige Container(-images) absolute Sicherheit verspricht. Nur eine Sache ist klar: „Hinten“ anzufangen, ist nicht rentabel – Container einfach zu deployen und dann im Betrieb nach Sicherheitslücken zu suchen, ist teuer, erzeugt vermeidbaren zusätzlichen Aufwand und nimmt Flexibilität. Die Absicherung der Container muss „nach links“ geschoben werden, möglichst an den Beginn der Containerisierung. Doch wo ansetzen?

 

Die Möglichkeiten

Um den Ursprung für Schwachstellen in Container(-images) und damit einhergehend mögliche Ansatzpunkte zur Absicherung zu identifizieren, muss man die „Lebensphasen“ eines Container(-images) verstehen. Diese lassen sich kurz und bündig wie folgt darstellen:

 

  • Bau des Images (lokal oder via CI/CD)
  • Distribution des Images – Push in eine Registry (Self-hosted oder bei einem Anbieter), Pull von Usern/Programmen
  • Deployment des Images (Openshift, (Managed) Kubernetes, etc.) und Betrieb des Containers

 

An dieser Stelle wird hoffentlich klar, warum ich permanent „Container(-image)“ schreibe – abhängig von der betrachteten Lebensphase haben wir es beim Thema Containersicherheit entweder mit einem erstellten Image oder mit einem laufenden Container, quasi einer Instanziierung dieses Images zu tun. Mit dieser Aufschlüsselung in verschiedene Abschnitte können wir uns nun mögliche Schritte zur Absicherung unserer Container anschauen.

Containerimages werden entweder lokal von Entwickler:innen, DevOps-Engineers, etc. auf Grundlage eines sog. Dockerfiles gebaut – alternativ lässt sich dieser Vorgang aber auch von CI/CD Pipelines umsetzen, wenn man den Dockerfile und andere benötigten Ressourcen bspw. in GitLab eincheckt. Die meisten Möglichkeiten zur Absicherung des späteren Container(-images) ergeben sich bereits in diesem ersten Schritt – der Quellcode der zu containerisierenden Applikation liegt vor, ebenso die Definition des Containers selbst, und auch möglicherweise vulnerable oder bösartige Abhängigkeiten wurden noch nicht in das spätere Containerimage eingebettet.

Ist das Containerimage lokal oder in einer Pipeline gebaut worden, muss man es zur späteren Nutzung in Produktion in eine Containerregistry übertragen. Diese kann entweder selbst gehosted werden, als private, aber gemanagte Instanz in der Cloud laufen oder öffentlich von jedem beliebigen Nutzer einsehbar sein. Auch bei diesem Vorgang gibt es Möglichkeiten, die Supply Chain zwischen Entwickler und Endnutzer abzusichern.

Auch wenn im Dockerfile gewisse Best Practices befolgt werden, kann der Container diese in vielen Fällen beim Deployment überschreiben – das letzte Wort haben hierbei immer Kubernetes, Openshift, Docker Desktop und Konsorten. Aus diesem Grund müssen einige der Überlegungen, die in der Build-Phase des Containerimages stattgefunden haben, auch hier noch einmal herangezogen, betrachtet und evaluiert werden, um die für die konkrete Nutzung besten Einstellungen und Kompromisse zu finden.

Ist der Container erst einmal deployed, gibt es nicht mehr viele Möglichkeiten, ihn „von innen“ weiter abzusichern. Dennoch kann und sollte man sich fortlaufend Gedanken bspw. um die Erreichbarkeit innerhalb des Clusters, des Netzwerkes, der Cloud etc. machen, Regeln nachziehen wo nötig und natürlich auch Update- und Backupstrategien im Hinterkopf behalten. Am Ende des Tages merkt man spätestens jetzt: Nach dem Deployment eines Containers seine Sicherheit zu überprüfen und zu garantieren, ist nicht sinnvoll – wir brauchen einen Left Shift.

 

Die Umsetzung

Buildphase

Nach viel Theorie und Konjunktiv können wir uns jetzt konkrete Umsetzungsmöglichkeiten der besprochenen Ansätze anschauen. Beginnen werden wir „ganz links“ beim Bau der Containerimages. Vieles lässt sich hier über verschiedene Direktiven im genutzten Dockerfile festlegen – Docker listet alle möglichen Direktiven sowie sinnvolle Best Practices und Caveats in der Docker Dokumentation auf. Für uns besonders interessant sind die Direktiven ADD, COPY und USER. Wie eingangs erwähnt, nutzen mehr als die Hälfte aller Containerimages per Default den root Nutzer innerhalb des Containers, obwohl das in vielen Fällen gar nicht notwendig wäre – auf einem klassischen Server läuft ein Apache2 Webserver schließlich auch als User apache, warum sollte/müsste das innerhalb eines Containers bspw. auf Debian-Basis anders sein?

Die anderen beiden erwähnten Direktiven beziehen sich auf die Abwägung, ob man gewisse Verzeichnisse und Dateien aus seiner Entwicklungsumgebung denn tatsächlich im endgültigen Container braucht – oder ob man die Applikation direkt lokal baut, und lediglich die fertige Binary via COPY in das Containerimage überträgt. In diesem Fall muss man natürlich darauf achten, dass etwaige zur Laufzeit benötigte Tools (ich meine dich, curl) und Bibliotheken sich auch im endgültigen Containerimage befinden. Alternativ kann man innerhalb eines Dockerfiles eine build und eine run Umgebung schaffen – auf diese Weise kann man die Applikation innerhalb des Containers bauen und im Anschluss lediglich die benötigten binären Artefakte und andere benötigten Ressourcen in das Lauzeitimage kopieren. Für diese Vorgehensweise würde es sich anbieten, das Entwicklungsrepository via ADD in die build Umgebung des Containerimages zu übertragen.

Diese Vorgehensweise bringt uns direkt zur nächsten „beliebten“ Unsicherheit in Container(-images): Lokal hinterlegte Credentials, Entwicklertokens, Cloudzugänge etc. Es gibt vermutlich keine Art von geheimen Daten, die nicht bereits versehentlich in Containerimages „vergessen“ wurde. Das kann schnell passieren – ein Entwickler nutzt ein Shellscript mit Zugangsdaten, um von seiner Entwicklungsumgebung in ein Testcluster zu deployen, eine .yaml-Datei, um Daten aus einer Entwicklerdatenbank zu lesen etc. Im „schlimmsten Fall“ überträgt er wissentlich eine Datei mit Zugangsdaten, die die containerisierte Applikation später in Produktion nutzen soll, oder hinterlegt sensible Daten im Containerimage als Umgebungsvariable mittels ENV.

Zur Bewältigung dieser Problematik gibt es die Möglichkeit, ähnlich wie eine .gitignore Datei für Git-Repositories eine .dockerignore Datei für den Buildvorgang eines Containerimages zu hinterlegen. Alle in dieser Datei aufgeführten Dateien und Verzeichnisse werden vom Dockerdaemon bei der Verarbeitung des Build-Contexts, von ADD und von COPY Direktiven ignoriert und finden sich somit zu keinem Zeitpunkt im Containerimage wieder. Dringend benötigte Umgebungsvariablen zur Konfiguration der containerisierten Applikation können auch zum Zeitpunkt des Deployments noch übergeben werden, bspw. mittels des Parameters -e via Docker-CLI oder dem Einlesen von Secrets als Umgebungsvariablen in Kubernetes.

Grundlegende Maßnahmen wie die Nutzung eines passenden Base-Images in der FROM Direktive (es muss nicht immer debian:buster oder ubuntu:20.04 sein), das Vermeiden der Öffnung unbenötigter Ports via EXPOSE sowie der Nutzung sog. Kannibalen-Tags (latest zeigt nach jedem Imageupdate auf eine neue Version) sollten darüber hinaus natürlich immer befolgt und beachtet werden.

Distributionsphase

Haben wir nun lokal oder in der Pipeline ein in sich möglichst sicheres Containerimage gebaut, muss es auf die eine oder andere Art und Weise seinen Weg in eine Containerregistry finden, um von anderen Nutzern heruntergeladen und deployed werden zu können. Für diese Vorgänge werden einem von den meisten Containerregistries Werkzeuge an die Hand gegeben, mit deren Hilfe wir den Prozess des Up-/Downloads von Containerimages absichern können.

Letzten Endes sind Containerregistries nichts anderes als APIs mit der Fähigkeit, Nutzer zu authentifizieren und zu authorisieren, Containerimages in Empfang zu nehmen, zu speichern und deren Versionierung im Blick zu behalten. Wie immer, wenn man über das Internet mit einer API spricht, gilt: HTTPS ist Pflicht! Darüber hinaus bieten Registries verschiedene Möglichkeiten, zusätzliche Maßnahmen gegen die Verbreitung unsicherer Images oder die Manipulation vorhandener Containerimages zu treffen. So können Imageregistries oftmals alle verwalteten Containerimages auf bekannte Schwachstellen scannen und den Download solcher Images durch Endnutzer untersagen. Auch die digitale Signierung von verwalteten Containerimages ist oftmals möglich, z.B. mittels sigstore und cosign.

Deploymentphase

Wird unser Containerimage nun im Rahmen eines Kubernetes-Deployments oder Docker-CLI-Befehls aus der Registry gepulled und deployed, haben wir einmal mehr die Möglichkeit, Sicherheit zu forcieren: Wie bereits erwähnt, können wir zum Einen die Voreinstellungen in Hinblick auf Umgebungsvariablen, User- und Gruppenkontext uvm. überschreiben, zum Anderen bietet natürlich auch die Absicherung der ausführenden Infrastruktur selbst die Möglichkeit, dass Deployment so sicher wie möglich zu gestalten.

Hierzu zählen z.B. die Nutzung sog. rootless Container, die von einem Container Runtime Interface (CRI) wie Docker oder containerd ausgeführt werden, die selbst nicht im root Kontext laufen. Auch die Nutzung restriktiver Netzwerk- und Firewallpolicies kann dabei helfen, die Risiken durch möglicherweise vulnerable oder bösartige Container zu minimieren. Konfiguration und Forcierung dieser Maßnahmen innerhalb eines Clusters können schnell zur Sisyphusarbeit werden – hier kann ein gemanagtes Kubernetes-Cluster von Vorteil sein, bspw. Managed Kubernetes von NETWAYS Web Services. Darüber hinaus sollte man eine nachhaltige Update-Strategie für seine Containerimages verfolgen: Es gilt, einen guten Kompromiss zwischen regelmäßigen Updates zu finden, aber nicht sofort jede neue Version (und deren evtl. neu eingeführte Schwachstellen) in Produktion zu deployen.

 

Das Fazit

Container(-images) sicher zu erstellen, zu verwalten und zu deployen ist ein langer Weg voller Stolpersteine. Wie so oft beim Thema Sicherheit wird man die 100% aller Voraussicht nach nicht erreichen – Nichtexistenz von Sicherheitslücken lässt sich nun einmal nicht beweisen. Dennoch habe ich Dich hoffentlich für das Thema und die teils falschen, gängigen Annahmen und Praktiken sensibilisieren können und nebenbei einige Best Practices an die Hand gegeben, die das Risiko durch vulnerable Container deutlich verringern.

Solltest Du nun mehr über den Vorgang des Imagebaus, den Betrieb von Containern in Kubernetes oder Containerisierung im Allgemeinen erfahren wollen, schau Dir doch einmal unser Kubernetes Schulungsangebot von NETWAYS an. In diesem eintägigen Workshop vermittle ich Dir praxisnah und einsteigerfreundlich alles, was Du für die ersten eigenen Schritte mit Docker und Kubernetes wissen musst. Ich freue mich auf Dich!

Daniel Bodky
Daniel Bodky
Platform Advocate

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und beriet zwei Jahre lang Kunden zu den Themen Icinga2 und Kubernetes, bevor es ihn weiter zu Managed Services zog. Seitdem redet und schreibt er viel über cloud-native Technologien und ihre spannenden Anwendungsfälle und gibt sein Bestes, um Neues und Interessantes rund um Kubernetes zu vermitteln. Nebenher schreibt er in seiner Freizeit kleinere Tools für verschiedenste Einsatzgebiete, nimmt öfters mal ein Buch in die Hand oder widmet sich seinem viel zu großen Berg Lego. In der wärmeren Jahreszeit findet man ihn außerdem oft auf dem Fahrrad oder beim Wandern.

OpenBugBounty.org – was ist das?

So wie es heise und anderen auch schon passiert ist, hatten wir kürzlich zwei Mails von openbugbounty.org im Postfach.

Im ersten Moment wunderten wir uns, was das denn für ein Laden sein könnte, aber am Ende gestaltete sich das ganze jedoch positiv.

 

Kommt erstmal überraschend

Über die nicht-kommerzielle Plattform haben uns unabhängig voneinander zwei IT-Security Spezis kontaktiert. Beide hatten unterschiedliche Lücken auf einer unserer WordPress-Installationen entdeckt und anstatt diese auszunutzen (sehr niedriger Impact) oder zu verkaufen (so sie denn Käufer:innen gefunden hätten), wählten sie den Weg des Responsible Disclosure mit einer Frist von 90 Tagen. Dieses Verhalten ist vergleichbar zum bekannteren Google Project Zero.

Responsible Disclosure wird oft kritisiert

Im Grunde gibt dieses Vorgehen den Betroffenen Zeit, den Fehler zu beheben, bevor dieser öffentlich gemacht wird und somit vielleicht auch einen größeren Schaden allein durch die Reichweite anrichten kann. Sobald der Fehler behoben ist, wird der Report veröffentlicht, damit auch andere Betroffene entsprechende Maßnahmen ergreifen können.

Einschub: oft wird Responsible Disclosure kritisiert, gerne auch Bug Bounty allgemein. Zum einen nimmt man den Betroffenen aus der Pflicht sofort zu handeln, wobei je nach Schwere der Lücke Zeit ein durchaus entscheidender Faktor sein kann. Und es ist ja auch nicht gesagt, dass nur exakt eine wohlmeinende Person diese Lücke findet und kein Schindluder damit treibt. Zudem könnte sich eine gewisse Laxigkeit im Bezug auf Datensicherheit einstellen, wenn ja eh ein zusätzlicher Feedbackkanal zur eigenen verhunzten Installation zur Verfügung steht. Und solange von der Seite kein Input kommt, kann das eigene System ja keine sooo schweren Lücken haben, oder?

Wie reagieren?

Wir standen am Anfang auch erst vor der Frage „wie reagieren?“, aber NETWAYS-typisch haben wir dann halt einfach mal gemacht. Also via Twitter bei openbugbounty.org eingeloggt (was machen eigentlich Leute ohne Twitter-Account? Solche soll es ja mittlerweile auch in NETWAYS-orange geben) und die Kontaktdaten der Spezln geholt.

Eine kurze Mail später hatten wir die Details, den möglichen Impact und eine Behebung für die Lücke im Postfach. Natürlich wurde das nochmal verifiziert, wobei seitens openbugbounty.org bereits eine Verifikation erfolgt. Die Fehlerbehebung war dann auch schnell erledigt und wir konnten die Lücken auch gleich noch auf unseren anderen WordPress-Installationen überprüfen.

Der längste Teil der Geschichte war am Ende die Entscheidung, was tun wir mit der Meldung, wie belohnen wir die beiden am besten und schreibe ich diesen Blogpost auf deutsch oder englisch.

Die Plattform selbst war bei diesem Prozedere nur als Kontaktvermittlerin involviert und hat von uns exakt nichts außer diesen Blogpost erhalten. Ihre Eigenpräsentation hat das Projekt auch hochgeladen. Unsererseits war die Erfahrung also gut, die Kommunikation war immer schnell und offen und es besteht hier wirklich kein Grund zur Furcht.

Details zu den Lücken

Wer bis hier hin durchgehalten hat, ist sicher auch neugierig, was das denn nun für Lücken waren. Die erste ermöglichte es, via WordPress API alle User unserer Installation abzufragen (nur GET, kein POST). Also im Grunde diese coolen Nasen – das NETWAYS-Team.

In der zweiten hätte die WordPress-RPC Funktion ausgenutzt werden können um bspw. DDoS-Attacken auszuführen. Details zu beiden Lücken finden sich bei openbugbounty.org unter den Meldungen 1777708 und 1814148.

Wenn Du Lust auf weitere solche und ähnliche Geschichten hast, schau bei unseren Trainings oder Events  vorbei. Mindestens in den Pausen werden immer Erlebnisse aus der IT Welt verglichen, manchmal auch die Länge der Pipelines oder Größe der Cluster.

Du willst davor eigene Erfahrungen sammeln? Klick Dir hier Deinen eigenen K8s-ClusterOpenStack oder GitLab-Server.

Wenn Du und Deine offene Fehlerkultur allerdings auch mal via WordPress-API angezogen werden sollen, ist jobs@netways.de der richtige Einstiegspunkt. Wir freuen uns darauf, den nächsten Bug Report mit Dir zusammen zu beheben!

Tim Albert
Tim Albert
Senior Systems Engineer

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert. Seit Anfang 2016 ist er bei uns tätig. Zuerst im Managed Services Team, dort kümmerte Tim sich um Infrastrukturthemen und den internen Support, um dann 2019 - zusammen mit Marius - Gründungsmitglied der ITSM Abteilung zu werden. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr – als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit...