hbauer.net

Hintertüren über das NTP Protokoll

Wed, 02 Nov 2022 00:00:00 +0100

NTP ist das Protokoll mit dem die Uhren auf Servern und Clients aktuell gehalten werden. In vielen Fällen werden in Firmen einfach öffentliche Zeitserver für NTP verwendet. Dies führt natürlich dazu das dieser Port auf der Firewall freigegeben wird.

Falls Sie diesen Ansatz auch gewählt haben sollten Sie das dringend überdenken. Dieser Port kann von Angreifern zum Beispiel mit dem Werkzeug sandman verwendet werden um ein Backdoor einzurichten

Angriffe auf das WLAN mit Drohnen

Wed, 19 Oct 2022 00:00:00 +0200

Was man ausser ein paar lustigen Videos noch alles mit Drohnen machen kann ist aktuell im Ukrainekrieg zu beobachten.

Das allerdings Drohnen auch gut für Angriffe auf die Informationssicherheit verwendet werden können kam für mich dann doch überraschend. Wo das geschehen ist wird hier berichtet und hat aus meiner Sicht reale Folgen für die Sicherheit von Organisationen.

Kurz gesprochen: Sie müssen Ihre Dächer überwachen.

Was ist geschehen? Ein Angreifer hat mit einer Drohne ein Hardware auf dem Dach einer Firma positioniert und damit einen Angriff auf das WLAN durchgeführt. Viele Risikoabschätzungen zur Sicherheit von WLANs beinhalten die Annahme das die Reichweite des WLANs eingeschränkt ist und kein dauerhaftes mitlesen möglich ist.

Das ist auch weiterhin richtig, wenn man jetzt die Dächer auch mit einer Kamera überwacht.

Schützen Sie auch Domänen die keine Mails versenden

Fri, 16 Sep 2022 00:00:00 +0200

Jede Organisation hat vermutlich Internet Domänen die für Webseiten verwendet werden von denen aber keine Mails versendet werden. Diese Domänen haben aber sprechende Namen und werden damit gerne von Spammern verwendet.

Um das Risiko zu minimieren das diese Domänen von unberechtigten Organisationen zum Versand von Mails verwendet werden kann man die gleichen Werkzeuge wie zum Schutz der Maildomänen verwenden.

Das sind

DKIM
SPF
DMARC
MX Records

Die britische Regierung hat hier eine Anleitung dafür erstellt.

Databreach Nachbereitungen

Fri, 09 Sep 2022 00:00:00 +0200

Der Youtuber Martin Hauschmid ist immer wieder eine gute Quelle für interessante Fälle. In diesem Video beschreibt er den Fall von Bombardier

Eigentlich ein “normaler” Ransomwarevorfall. Ein Unternehmen ist Opfer einer Ransomware, bezahlt kein Lösegeld sondern restauriert aus Backups und dann werden Daten im veröffentlicht.

So weit so gut. Interessant sind hier zwei Aspekte

Es wurden auch private Kennwörter veröffentlicht.
Mit Hilfe der Kennwörter konnte man auch nach der Wiederherstellung der System auf öffentlich zugängliche Systeme zugreifen

Eigentlich so weit “logisch” aber für Unternehmen bedeutet dies das im Falle einer Ransomwareattacke auch alle internen Kennwörter geändert werden müssen die vielleicht in externen Systemen verwendet werden. Und natürlich sollte man allen Mitarbeitenden empfehlen auch private Kennwörter zu ändern wenn diese auf dienstlichen Rechnern gespeichert sein sollten.

Informationsklassifizierung

Tue, 09 Aug 2022 00:00:00 +0200

Organisation sollten intern eine klare Klassifikation für Dokumente festlegen. Hierzu gibt es keine klare Vorgabe in den unterschiedlichen Standards und viele Firmen haben so einige Schwierigkeiten damit.

Wenn Sie auf der Suche nach einer Klassifikation sind dann sollten Sie vielleicht einen Blick auf das sogenannte Traffic Light Protocol (TLP) werfen. Die Informationssicherheitscommunity verwendet den TLPD-Standard, um vertrauliche Informationen auszutauschen.

An vielen Stellen wird zwar eine 3 stufige Einteilung empfohlen aber ich finde diese Stufen leicht verständlich und die Analogie zur Ampel hilft vielleicht vielen diese im Alltag zu verwenden.

Behördliche Mailserver Messies

Wed, 03 Aug 2022 00:00:00 +0200

Ich denke über eins herrscht Einigkeit in unserer Gesellschaft.

Spam und Phishing schadet allen

Wie kann es denn dann sein das ein einfaches und kostengünstiges Werkzeug zur Vermeidung nicht genutzt wird? DMARC und die Basistechnologien sind technisch einfach zu realisieren und schützen

andere davor SPAM unter dem eigenen Namen zu empfangen
die eigenen Mitarbeiter vor Phishing Attacken durch Mails mit internen Absendern.

Das der Schreiner oder der Lackierer um die Ecke das nicht macht kann ich ja noch verstehen. Aber warum wird das Thema bei den öffentlichen Organisationen so ignoriert? Hier eine nicht repräsentative Auswertung

Bundesbehörden

;_dmarc.bund.de.                        IN      TXT
_dmarc.bund.de.         600     IN      TXT     "v=DMARC1; p=none; rua=mailto:bund.de@dmarc.reports.bund.de;"
;_dmarc.bmwi.de.                        IN      TXT
_dmarc.bmwi.de.         600     IN      TXT     "v=DMARC1; p=none; rua=mailto:dmarc_rua@bmwi.de; ruf=mailto:dmarc_ruf@bmwi.de; fo=1;"
;_dmarc.bundeswehr.de.          IN      TXT
_DMARC.nomail.bwehr.de. 3600    IN      TXT     "v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:Postmaster-DMZ.report@bundeswehr.org; ri=604800; fo=0; rf=afrf; adkim=s; aspf=s;"
;_dmarc.bfdi.de.                        IN      TXT
;_dmarc.auswaertiges-amt.de.    IN      TXT
_dmarc.auswaertiges-amt.de. 300 IN      TXT     "v=DMARC1; p=none; sp=none; rua=mailto:auswaertiges-amt.de@dmarc.reports.bund.de,mailto:dmarc-report@auswaertiges-amt.de;"
;_dmarc.bmf.de.                 IN      TXT

Landesbehörden

;_dmarc.stk.nrw.de.             IN      TXT
;_dmarc.stk.bayern.de.          IN      TXT
;_dmarc.sk.sachsen.de.          IN      TXT
;_dmarc.bremen.de.              IN      TXT
_dmarc.bremen.de.       900     IN      TXT     "v=spf1 ip4:194.95.254.0/23 ip4:193.168.236.0/23 ip4:195.37.102.0/22 ip4:94.186.185.248/29 ip4:94.186.131.0/24 ip4:185.228.148.7/32 ip4:185.228.148.8/32 ip6:2a00:12d0:4001::/48 ip6:2001:638:70f:10::/64 -all"
;_dmarc.saarland.de.            IN      TXT
;_dmarc.stk.brandenburg.de.     IN      TXT
;_dmarc.stk.hessen.de.          IN      TXT

Städte

;_dmarc.koeln.de.               IN      TXT
;_dmarc.hamburg.de.             IN      TXT
;_dmarc.bonn.de.                        IN      TXT
_dmarc.bonn.de.         300     IN      TXT     "v=DMARC1; p=none; pct=1; rua=mailto:dmarc@bonn.de;"

Universitäten

;_dmarc.srh.de.                 IN      TXT
_dmarc.srh.de.          3600    IN      TXT     "v=DMARC1; p=none; sp=none; rua=mailto:dmarc@mailinblue.com!10m; ruf=mailto:dmarc@mailinblue.com!10m; rf=afrf; pct=100; ri=86400"
;_dmarc.uni-hamburg.de.         IN      TXT
_dmarc.uni-hamburg.de.  43200   IN      TXT     "v=DMARC1; p=none; sp=none; adkim=r; aspf=r; rua=mailto:dmarc-reports.rrz@uni-hamburg.de"
;_dmarc.uni-paderborn.de.       IN      TXT
_dmarc.uni-paderborn.de. 1800   IN      TXT     "v=DMARC1; p=none; rua=mailto:postmaster@uni-paderborn.de; ruf=mailto:postmaster@uni-paderborn.de; fo=0; adkim=r; aspf=r;
pct=100; rf=afrf; ri=84600; sp=none"
;_dmarc.hs-duesseldorf.de.      IN      TXT

Da wo kein “v=DMARC1” steht hat man sich noch gar keine Gedanken gemacht. Da wo ein “p=none” steht macht man sich vielleicht schon Gedanken. Nur im BMVG steht “p=reject”

Was ist nach meiner Meinung die Ursache?

Ignoranz
fehlender Überblick über die Mailserver

Ich denke in den meisten Fällen wird es einfach die Unordnung und der fehlende Überblick über die Server die Mails versenden dürfen sein. Die nenne ich Mailmessies

Risikomanagement für Lieferketten

Fri, 22 Jul 2022 00:00:00 +0200

Das National Institute of Standards and Technology (NIST) hat seine Leitlinien zur Cybersicherheit zum Umgang mit Risiken in der Software-Lieferkette aktualisiert und bietet maßgeschneiderte Sicherheitskontrollen für verschiedene Interessengruppen an. Das Identifizieren von Sicherheitsrisiken in der Lieferkette ist schwierig, da viele Akquisitionen niemals eine Lieferantenrisikobewertung durchführen, sodass das Unternehmen besonders anfällig sind.

Diese “Lieferkettenangriffe” haben in der letzter Zeit einige Schlagzeilen erzeugt. Angriffe über Dienstleister wie Solarwinds oder eine Softwarekomponente Log4Shell sind die bekanntesten in der letzten Zeit. Sicherheitsexperten haben wiederholt Bedenken hinsichtlich der Sicherheit von Open-Source-Komponenten und Bibliotheken von Drittanbietern geäußert, die in einer Vielzahl verschiedener Anwendungen verwendet werden.

Die neueste Veröffentlichung von NIST bietet eine Anleitung zum Risikomanagement für Rollen wie Cybersicherheitsspezialisten, Risikomanager, Systemingenieure und Einkäufer und empfiehlt eine Reihe von Methoden. Zum Beispiel die Implementierung von Sicherheitskontrolle und regelmäßigen Audits bei der Verbindung mit Lieferanten.

Zero Trust: Never trust - always verify.

Thu, 14 Jul 2022 00:00:00 +0200

Den Begriff von “Zero Trust” gibt es schon einige Jahre. Besonders an Beachtung gewonnen hat er allerdings mit der sogenannten Executive Order

To keep pace with today’s dynamic and increasingly sophisticated cyber threat environment, the Federal Government must take decisive steps to modernize its approach to cybersecurity, including by increasing the Federal Government’s visibility into threats, while protecting privacy and civil liberties. The Federal Government must adopt security best practices; advance toward Zero Trust Architecture; accelerate movement to secure cloud services, including Software as a Service (SaaS), Infrastructure as a Service (IaaS), and Platform as a Service (PaaS); centralize and streamline access to cybersecurity data to drive analytics for identifying and managing cybersecurity risks; and invest in both technology and personnel to match these modernization goals.

Es wird auch klar gesagt, auf welche Definition von “Zero Trust” sich der Präsident sich bezieht NIST

develop a plan to implement Zero Trust Architecture, which shall incorporate, as appropriate, the migration steps that the National Institute of Standards and Technology (NIST) within the Department of Commerce has outlined in standards and guidance, describe any such steps that have already been completed, identify activities that will have the most immediate security impact, and include a schedule to implement them

Begleitet wird die präsidiale Anordnung durch eine Vielzahl von Initiativen, z.B. dem CISO

Jetzt kann man natürlich die Meinung vertreten, dass hier nur präsidiales Buzzword Bingo gespielt wird. In der Mehrheit wird hierin aber ein energischer Ansatz gesehen, das Thema Cybersecurity in den Bundesbehörden zu verbessern.

Auch in Deutschland scheint dieses Themengebiet an Sichtbarkeit zu gewinnen.

Insbesondere die mit der Hackerattacke auf den Bundestag bekannt gewordenen Netze des Bundes müsse der Staat so aufstellen, “dass wir schrittweise in Richtung Zero-Trust-Architektur gehen”, erklärte Andreas Könen, Leiter der Abteilung Cyber- und IT-Sicherheit im Bundesinnenministerium (BMI)

Ich bin mir sicher, das wir alle versuchen müssen dem US Beispiel zu folgen. Deswegen hier ein Versuch einer schnellen Charakterisierung als Einstieg in das Thema.

Für mich der einfachst Weg das Konzept von Zero Trust schnell zu verstehen, beginnt mit einer Betrachtung der heutigen Netzwerke. Menschen, die seit den frühesten Tagen in der IT tätig sind, werden sich an die frühen Zeiten erinnern. Wir hatten nicht wie heute Zugriff auf viele Tools in der Cloud. Wir nutzten für unsere Arbeit digitale Ressourcen und Anwendungen, die jedoch nur über interne Netzwerke und PCs/Laptops zugänglich waren. Der wesentliche Ansatz sich vor Bedrohungen von außen zu schützen, bestand darin einen digitalen Zaun zu errichten. Dieser digitale Zaun sollte das System und die Geräte eines Unternehmens vor Zugriffen von außen schützen. Alle eingehenden “Zugriffe” auf authentifizierte und autorisierte Quellen wurden über einen einzigen Einstiegspunkt geleitet werden. Das war im Allgemeinen lange Zeit eine gute Strategie.

Das funktioniert allerdings heute allerdings nicht mehr.

Wir alle wissen das die Welt heute anders aussieht. Die meisten von uns arbeiten remote auf mobilen Geräten. Die Daten werden in privaten, öffentlichen oder hybriden Cloudumebungen gehalten. Mit dieser Erweiterung sind natürlich auch die Cybersicherheitslücken gewachsen. Jetzt gibt es mehr Angriffspunkte und mehr Bereiche, in denen Hacker in Ihr System eindringen können. Es ist besonders wichtig, Ihr Netzwerk vor Eindringlingen zu schützen, die bereits Zugriff darauf haben – wie Ihre Mitarbeiter oder Ex-Mitarbeiter.

In den meisten der aktuellen großen Databreaches haben sich Hacker zunächst mithilfe gestohlener Zugangsdaten Zugang zum internen Netzwerk der Organisation verschafft. Dann wurde ein Malware-Paket eingeschleust, das sich wie eine Hintertür zur Datenexfiltration installierte. Von dort aus haben die Angreifer ihre Privilegien erweitert, um auf verschiedene Informationssysteme zuzugreifen.

Die klassische Absicherung an den Netzwerkgrenzen reicht also nicht mehr. Es gilt der Grundsatz: Die Angreifer sind schon drin.

Hier kommt die wesentliche konzeptionelle Neuheit im Ansatz von Zero Trust auf den Plan. Egal von wo aus ich wo hin auf Netzwerkressourcen zugreife, immer gilt die Forderung. “ich vertraue Dir nicht und muss dich prüfen”. Das ist ein fundamentaler Wechsel der bei allen zukünftigen Planungen in Betracht zu ziehen.

Das ist für mich der Hauptunterschied zu den früheren Ansätzen. Dazu kommen natürlich viele technische Anforderungen die viele Organisationen teilweise schon kennen. Aber das ist Technik die in der neuen Denkwelt eingeführt werden muss.

Weitere Details und Vorteile werde ich in weiteren Artikel verdeutlichen

Log4Shell und kein Ende

Tue, 05 Jul 2022 00:00:00 +0200

Im Dezember des letzten Jahres gab es eine große und berechtigte Aufregung um eine Sicherheitslücke in einer Java Bibliothek mit dem Namen Log4Shell. Schnell waren Patches für die meisten relevanten Softwarepakete verfügbar und eigentlich sollte das keine Thema mehr sein.

Aber leider scheint dieser Sicherheitslücke immer noch nicht in allen Organisationen beseitigt worden zu sein. Und zwar nicht in irgendwelchen verstaubten uralten Javaprogrammen. Die US amerikanische “BSI” warnt immer noch vor “erfolgreichen” Angriffen auf VMWare Virtualisierungskomponenten für die es schon seit langem Patches gibt.

Malicious Cyber Actors Continue to Exploit Log4Shell in VMware Horizon Systems

Vor allem die folgende aus meiner Sicht berechtigte Aussage sollte langsam für etwas Wallung in den IT Abteilungen sorgen:

If updates or workarounds were not promptly applied following VMware’s release of updates for Log4Shell in December 2021, treat all affected VMware systems as compromised.

Wer also heute noch Server im Internet mit den genannten Produktversionen fährt sollte den Notfallplan für diese Systeme aktivieren.

Und für alle die glauben das da schon nichts passiert werden auch gleich reale Beispiele von gehackten Unternehmen mit geliefert.

Lunasec, CC BY-SA 4.0 CC BY-SA 4.0, via Wikimedia Commons

Lehren aus NotPetya bei Maersk

Tue, 21 Jun 2022 00:00:00 +0200

Heute kann man lesen das es zu Cyberangriffen von russischen Hackergruppen auf Server in Litauen kommt.

Gegenüber der Nachrichtenagentur Reuters bestätigte ein Sprecher der pro-russischen Cybergang Killnet, für die Angriffe verantwortlich zu sein. Die Angriffe würden weitergehen, bis Litauen die Blockade der Warenlieferungen nach Kaliningrad aufhebe.

Man sagt zwar “Geschichte wiederholt sich nicht” aber ich möchte an dieser Stelle auf den Fall NotPetya und die Reederei Maersk hinweisen.

Als Reaktion auf einen Cyberangriff musste sich die weltgrößte Containerreederei durch die Neuinstallation von über 4.000 Servern, 45.000 PCs und 2500 Anwendungen über einen Zeitraum von zehn Tagen restaurieren. Ein Firma in der alle 15 Minuten ein Schiff mit 20.000 Container anläuft.

Ausgelöst durch einen Finanz PC in der Ukraine.

Das größte Problem war:

If we can’t recover our domain controllers,we can’t recover anything.”

Ohne einen AD Server in Ghana, der wegen eines Stromausfalls nicht online war, wäre genau dieser Fall eingetreten.

Ich gebe Ihnen eine Aufgabe mit.

Übernächste Woche Samstag eine Übung in der alle AD Server abgeschaltet werden und ein neuer AD Server wird von einem Offline Backup installiert und in Betrieb genommen. Sollte ja kein Problem sein.