Januar 14, 2022
Kommentieren

Das neue Gravity

Wir haben das User Interface von Gravity überarbeitet. Die wichtigsten Änderungen im Überblick:

  • Das Sidebar-Menu ist nun besser zugänglich und Sie können zwischen minimaler und voller Breite auswählen.
  • Alle Dialoge wurde überarbeitet und neu designed, so dass man generell weniger scrollen muss.
  • Design wurde homogenisiert.

Wir freuen uns sehr über das Ergebnis. Die Änderungen betreffen jedoch nicht nur den Look & Feel. Durch die Aktualisierung auf die neusten Technologien (v.a. im Bereich JavaScript) haben wir den Weg bereitet, um Gravity weiterhin effizient und kundenorientiert weiter zu entwickeln.

Damit haben wir einen weiteren wichtigen Schritt getan, um unsere Strategie der Benutzerfreundlichkeit konsequent umzusetzen. Wir wünschen Ihnen ebenfalls viel Freude mit dem neuen Design und freuen uns wie immer über jedes Feedback.

Dezember 13, 2021
Kommentieren

Log4j / log4shell

Mit der Schwachstelle in der Java Library log4j ist erneut eine Sicherheitslücke mit erheblichen Konsequenzen aufgetaucht. User-Eingaben, welche an den Logging Dienst geschickt werden, können so manipuliert werden, dass auf dem Server Befehle ausgeführt werden (Remote Code Execution).

Weitere Informationen:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228

Gravity erkennt die Schwachstelle, allerdings ist sie nicht immer abschliessend und zuverlässig zu diagnostizieren, da man sich darauf verlassen muss, dass die Callbacks zur Verifizierung funktionieren und nicht unterwegs geblockt werden. Der Scanner schickt eine Payload, welche log4j dazu veranlasst, eine ldap Anfrage beim Scanner zu starten, falls die Verwundbarkeit besteht.

Verlässlicher funktioniert es über privilegierte Scans. In diesem Fall sucht der Scanner lokal auf dem System nach der betroffenen Library. Doch der Erfolg hängt auch davon ab, wo die Library liegt (z.b. nested jar oder speziell restriktive Verzeichnisse) und welche Credentials genutzt werden.

Empfehlung:

Daher empfehlen wir zusätzlich zum Scanning ein Inventar-basiertes Assessment durchzuführen, um festzustellen, welche Ihrer Java-Applikationen oder Komponenten User-Input verarbeiten und an eine betroffene Version von log4j senden.

Vorgehen:

  1. Fokussieren Sie sich zuerst auf die vom Internet her erreichbaren Systeme.
  2. Verzögert sich die Abklärung, sollten Sie den Zugang zu verdächtigen Applikationen sperren oder zumindest stark einschränken (Port schliessen oder auf IP-Bereiche einschränken).
  3. Führen Sie mit Gravity einen Web Scan oder, falls Sie spezielle Ports verwenden oder nicht sicher sind, einen PCI-DSS Scan durch. Falls Sie einen eigenen Scanner verwenden, stellen Sie sicher, dass dessen TCP und UDP Ports 53 und 389 vom getesteten System aus erreichbar sind. Darüber wird die Schwachstelle zu verifizieren versucht.
  4. Falls privilegierte Scans möglich sind, führen Sie zudem einen kompletten privilegierten Scan durch. Insbesondere die Testgruppen «Misc» und «Web Servers» sollten aktiviert sein, damit nach der betroffenen Bibliothek gesucht werden kann. Erstellen Sie hierfür eine neue Policy und hinterlegen Sie einen gültigen User mit administrativen Privilegien.
  5. Parallel zu den Scans konsultieren Sie Ihr Software-Inventar und identifizieren Sie sämtliche Java-Applikationen, die möglicherweise User Input bzw. untrusted Input loggen. Sehen Sie beim Security Advisory des Herstellers nach, ob Ihre Version betroffen ist. Ist dies nicht möglich, stellen Sie sicher, ob log4j genutzt wird und welche Version, indem Sie sich die Bibliotheken anschauen (siehe auch log4j_checker_beta).
  6. Stellen Sie sicher, dass log4j aktualisiert wird oder konfigurieren Sie dies gemäss https://logging.apache.org/log4j/2.x/security.html um die schädlichen Anfragen zu unterbinden.
  7. Wenden Sie sich danach internen Systemen zu.

Neben Gravity können Sie folgende Tools bei der Behebung unterstützen:

https://github.com/rubo77/log4j_checker_beta

https://github.com/Neo23x0/log4shell-detector

Oktober 13, 2016
Kommentieren

Kostenlose SSL Zertifikate im Praxistest

Let’s encrypt ist ein Projekt aus dem Mozilla-Umfeld und wohl auch Albtraum vieler etablierter Certificate Authorities. Das Ziel des Projekts ist es, die Verschlüsselung im Web voranzutreiben . Die Strategie: Kostenlose Zertifikate und einfache Installation.

Wir haben den Service getestet und sind begeistert, wie schnell man an ein Zertifikat kommt. Hierzu mussten wir lediglich ein Paket auf dem Server installieren und der Wizard übernahm den Rest.

Installation

Es gibt verschiedene Methoden, wir haben uns dafür entschieden, den Webserver kurz zu stoppen. Anschliessend mussten wir folgenden Befehl ausführen:

# sudo letsencrypt certonly --standalone -d domain.ch -d www.domain.ch

Für die Validierung wird temporär ein Service auf Port 80 und 443 gebunden. Danach befinden sich im Verzeichnis /etc/letsencrypt/live/domain.ch alle notwendigen Files inkl. korrekt gesetzter Berechtigungen. Wir mussten nur noch die Konfiguration des Server anpassen, und schon war das Zertifikat live. Die Gültigkeit dieser Zertifikate ist auf 90 Tage beschränkt. Da es aber einfach ist, diese zu erneuern, sollte das kein Problem darstellen. Auch aus technischer Sicht fanden wir bisher nichts zu bemängeln.

Nicht für jede Site geeignet

Wie Sie sehen, lassen wir diesen Blog jetzt mit dem Let’s encrypt-Zertifikat verschlüsseln und berichten gerne weiter von unseren Erfahrungen. Natürlich ist die Wahl der CA Vertrauenssache, und das Risiko sollte entsprechend analysiert werden. Wir empfehlen Webseiten oder Applikationen mit hohem Schutzbedarf nicht mit Letsencrypt zu verschlüsseln. Hier sollten Sie weiterhin auf kostenpflichtige Dienste mit Extended Validation (EV) zurückgreifen.

Oktober 4, 2016
Kommentieren

Security Benchmark berechnen

netsense Gravity verwendet neben dem komplexeren RAV nach OSSTMM einen einfachen Security Benchmark, um die Sicherheit eines Systems zu messen. Aus Gründen der Transparenz legen wir den Algorithmus hier gerne für die freie Verwendung offen.

Penalties

Zuerst werden die Penalties berechnet. Jeder Host bekommt allein schon aufgrund seiner Existenz einen Abzug, da es bekanntlich keine hundertprozentige Sicherheit gibt:

penalties = 0.05

Weiter werden die offenen Ports mit einer Gewichtung von 1/30 hinzugefügt, was die potenzielle Angriffsfläche widerspiegelt. Danach folgen die tatsächlich entdeckten Schwachstellen nach Kategorisierung gewichtet. Informative Findings haben keinen Einfluss.

penalties += open_ports/30
penalties += exposures/50
penalties += concerns/10
penalties += weakness/2
penalties += vulnerabilities

Security Degredation

Ein System, das lange nicht gescannt wird, wird ebenfalls abgestraft, das es ein Risikofaktor ist. Hierzu verwenden wir die Anzahl Tage seit dem letzten Scan:

penalties += last_scan_days/200

Skala

Die Penalties werden auf 999 beschränkt und auf einer logarithmischen Skala mit der Basis 1000 gelegt:

missing = Math.log(penalties+1)/Math.log(1000)
security_benchmark = (1 - missing) * 100

Gerne sind wir bereit, den Algorithmus durch Ihren Input weiter zu entwickeln. Er soll aber einfach bleiben und nicht den Risk Assessment Value nach OSSTMM ersetzen, den Sie in Gravity unter Reports finden.

September 21, 2016
3 Kommentare

SSL Check für Ihre Website

netsense bietet ab sofort einen kostenlosen SSL Check für Ihre Website an. Damit können Sie schnell und unkompliziert feststellen, ob Ihre SSL Server und Zertifikate sicher konfiguriert sind.

 

ssl check output

Beispiel: Ergebnisse des SSL Checkers

Der Test funktioniert ohne Anmeldung und prüft auf:

  • Sichere SSL/TLS Versionen
  • Gültigkeit und Vertrauenswürdikeit des Zertifikats
  • Sichere Verschlüsselungsalgorithmen
  • Sicheres Hashing
  • Diffie-Hellmann Gruppen (Logjam)
  • Weitere Schwachstellen wie Heartbleed und POODLE
  • Secure Renegotiation

 

Dieser kostenlose SSL Test dient zur unverbindlichen Überprüfung und ist auf TCP Port 443 beschränkt . Die dahinter liegende Applikation wird nicht geprüft. Für detaillierte Sicherheitstests verwenden Sie bitte unsere Vulnerability Management Lösung.

September 19, 2016
Kommentieren

Neue Website

Wir haben unsere Webseite überarbeitet und auch optisch aufgefrischt. Unser Fokus lag in der Vergangenheit stark auf der Verbesserung von Gravity, weshalb wir diese Seite ein wenig stiefmütterlich behandelt haben. Auch dieser Blog wird in naher Zukunft ins neue Design integriert.

Wir hoffen, dass auch Ihnen das neue Design gefällt und freuen uns auf jedes Feedback.

Dezember 22, 2015
Kommentieren

Schwachstellen automatisch schliessen

Mit dem Rescan haben Sie in netsense Gravity die Möglichkeit, nur auf vorhandene Schwachstellen zu testen. Falls eine Schwachstelle nicht mehr gefunden wird, wird sie automatisch als geschlossen markiert.

Unter *Settings/Advanced* können Sie nun Auto-Rescan aktivieren. Gravity führt dann bei jedem geplanten Scan (Scheduled Scan) automatisch einen Rescan durch.

November 12, 2014
Kommentieren

BOLL gewinnt Disti Award

Das Fachmagazin Swiss IT Reseller verleiht aufgrund einer representativen Umfrage jedes Jahr den Best Distributor Award. Wir gratulieren unserem Partner Boll Engineering herzlich zur erneuten Auszeichnung!

Für CEO Thomas Boll ist das erreichte Resultat ein klares Zeichen für die hohe Wertigkeit der kunden- und wertefokussierten Geschäftsstrategie. «Wir freuen uns, den ersten Platz des Disti Awards 2014 gewonnen zu haben und danken den zahlreich teilnehmenden Resellern für ihre positiven Wertungen. Der Podestplatz ist uns Verpflichtung, für unsere Kunden auch zukünftig Höchstleistungen zu erbringen, sie in ihrer Tätigkeit massgeschneidert zu unterstützen und gemeinsam innovative Wege zu gehen. Wir bedanken uns herzlich für das geschenkte Vertrauen und freuen uns, unsere Channel-Partner in ihrem Tun langfristig zu unterstützen, denn sind unsere Kunden erfolgreich, sind wir es auch.»

Oktober 15, 2014
1 Kommentar

POODLE Schwachstelle in SSLv3

Am 14. Oktober 2014 wurde eine Design-Schwäche in der SSL Version 3 publik. POODLE (Padding Oracle On Downgraded Legacy Encryption), erlaubt es in Zusammenhang mit einem Man in the middle, verschlüsselte Informationen auszulesen.

Wie schon beim Vorgänger SSLv2 wird nun empfohlen, SSLv3 komplett zu deaktivieren und nur noch via TLS zu verschlüsseln.

Weitere Informationen:

September 26, 2014
Kommentieren

ShellShock

Die ShellShock Verwundbarkeit ist dieses Jahr nach Heartbleed bereits die zweite Sicherheitslücke, die eine breite Medien-Abdeckung erhielt. Vor allem in Verbindung mit einem schlechten Design (CGIs) kann es vorkommen, dass man über diesen Bug beliebige Kommandos im User-Kontext ausführen kann.

Wenn Sie Ihre Systeme auf diese Schwachstelle testen wollen, muss der Scanner über einen privilegierten Zugang zu den Systemen verfügen. Es gibt zwar Tests, die eine Erkennung via http / https versprechen, diese sind jedoch kaum aussagekräftig.

Alternativ können Sie zum Testen auf ShellShock auch folgendes Kommando manuell ausführen:

env check='Not vulnerable' x='() { :;}; check=Vulnerable' bash -c 'echo $check'

Das obige Kommando gibt entweder ‹Vulnerable› oder ‹Not vulnerable› aus.