DevSecOps – der nächste Hype nach DevOps und Containern?
Seite 2: Checklisten und Datenbanken
Damit Sicherheitsexperten, Entwickler und Anwender weltweit bei der Beseitigung von Sicherheitsschwachstellen zusammenarbeiten können, ist ein einheitliches Schema zur Identifizierung von Schwachstellen erforderlich.
Die Common Vulnerabilities and Exposures (CVE) sind hierfür seit 1999 ein unverzichtbarer Industriestandard. Im Wesentlichen ist das eine Datenbank, die verschiedene Abfragen ermöglicht. Zunächst ist ein CVE-Eintrag nur eine erkannte Schwachstelle. Er sagt nichts über das Risiko, dass diese Schwachstelle auch ausgenutzt werden kann, und über die Auswirkungen eines Ausfalls auf ein Unternehmen oder seine IT-Infrastruktur. Es ist daher das Risiko, das die Schwachstelle oder das Risiko der CVEs definiert, und nicht deren Anzahl.
Aber auch hier gibt es einen Ansatz, der den Sicherheitsverantwortlichen das Leben etwas einfacher macht – das CVSS (Common Vulnerability Scoring System). Je einfacher eine Schwachstelle auszunutzen ist, desto geringer ist die zu überwindende Hürde und desto höher ist der Risikofaktor der Schwachstelle. Er erreicht Werte von 0 bis 10, wobei 10 den höchsten Wert darstellt.
Mit diversen Tools lässt sich prüfen, ob es für eine Software bekannte Schwachstellen gibt. Der CVE-Record beschreibt dabei oft auch einen konkreten Angriffsvektor. Das ist vor allem deswegen wichtig, weil es gerade damit einfach ist, Angriffe schnell und im großen Stil zu realisieren, denn ein Großteil der Lücken bleibt lange ungepatcht. Außerdem lohnt ein Blick in die OWASP Top 10, die die häufigsten und kritischsten Schwachstellen in Webanwendungen auflistet.
Generell sollte man die diversen Hacking-Tools nicht auf seinem regulärem Computer installieren. Am besten nutzt man Whonix oder Kali-Linux in einer VM. Im Folgenden wird Kali-Linux genutzt. Das Schöne dabei ist: Es sind bereits die meisten Tools installiert und direkt nutzbar. Alternativ kann man ein Docker-Image verwenden, was auch in diesem Artikel der Fall ist.
Noch ein Hinweis zur Nutzung von Tor: Es ist brauchbar für den Aufruf von Webseiten, wenn es aber um die Verwendung von Hacking-Tools wie nmap, sqlmap und nikto geht, die Tausende von Anfragen verarbeiten, verlangsamt Tor die Übertragung zu sehr.
Auch wenn Hollywood es anders darstellt: Hacker verbringen oft mit der Vorbereitung der Attacke mehr Zeit als mit dem eigentlichen Hack. Dabei geht es primär um das Sammeln von Informationen: Domain-Einträge mit fierce auslesen, Whois-Abfragen von IP-Adressen und Domain-Namen und Reverse-Whois-Abfragen, um alle IP-Adressbereiche und Domain-Namen zu finden, die mit einer Organisation verbunden sind. Hier ein Beispiel für eine Fierce-Abfrage für holisticon.de:
root@kali:~# fierce -DNS holisticon.de
DNS Servers for holisticon.de:
ns6.kasserver.com
ns5.kasserver.com
Trying zone transfer first... (1)
Testing ns6.kasserver.com
Request timed out or transfer not allowed.
Testing ns5.kasserver.com
Request timed out or transfer not allowed.
Unsuccessful in zone transfer (it was worth a shot)
Okay, trying the good old fashioned way... brute force
Checking for wildcard DNS... (2)
** Found 99752187575.holisticon.de at 85.214.158.97.
** High probability of wildcard DNS.
Now performing 2280 test(s)... (3)
85.214.38.253 blog.holisticon.de
81.169.187.209 cms.holisticon.de
195.201.92.152 honeypot-wp.holisticon.de
81.169.173.205 wiki.holisticon.de
Subnets found (may want to probe here using nmap or unicornscan):
195.201.92.0-255 : 1 hostnames found.
81.169.173.0-255 : 1 hostnames found.
81.169.187.0-255 : 1 hostnames found.
85.214.38.0-255 : 1 hostnames found.
Done with Fierce scan: http://ha.ckers.org/fierce/
Found 4 entries. (4)
Have a nice day
Zunächst wird versucht, per Zone Transfer mehr Informationen (AXFR Request) über das Netzwerk zu erhalten. Das wird im Großteil der Fälle nicht funktionieren.
- Nun sucht Fierce, ob ein Wildcard-Eintrag existiert, und ist fündig geworden.
- Anschließend werden per Brute Force weitere Subdomains gefunden.
- Insgesamt wurden 10 Einträge gefunden.
Mit Whois-Abfragen kann man nun beginnen, mehr über den Anbieter herauszufinden, der die Domain registriert hat und vermutlich auch betreibt:
root@60808f78e55d:/# whois 85.214.65.25
...
inetnum: 85.214.16.0 - 85.214.139.255
netname: STRATO-RZG-DED2
org: ORG-SRA1-RIPE
descr: Strato Rechenzentrum, Berlin
country: DE
admin-c: SRDS-RIPE
...
Nun können die Leser per Reverse-Whois-Suche nach weiteren Adressen fahnden. Da diese aber Geld kosten, können sie ihr Glück auch mit Google versuchen. Dazu einfach folgende Suchbegriffe eingeben:
"Strato Rechenzentrum, Berlin" inurl:ip-address-lookup
"Strato Rechenzentrum, Berlin" inurl:domaintools
Da in dem Fall kein direkter Whois-Eintrag vorliegt, sondern nur der des Hosters, werden hier zu viele IP-Bereiche gelistet. Das kann aber je nach Konfiguration und Set-up der Firma stark variieren. Letztlich dient die Reverse-Suche dazu, die Liste an interessanten IPs/Domains zu erweitern.
An dieser Stelle noch ein Hinweis zur Sicherheit von Cloud-Anbietern: Versucht man bei AWS mehr Informationen per DNS zu erhalten, gestaltet sich das nicht so einfach:
root@kali:~# fierce -DNS cloudci.net
DNS Servers for cloudci.net:
ns-999.awsdns-60.net
ns-1802.awsdns-33.co.uk
Trying zone transfer first...
Testing ns-999.awsdns-60.net
Request timed out or transfer not allowed.
Testing ns-1802.awsdns-33.co.uk
Request timed out or transfer not allowed.
Unsuccessful in zone transfer (it was worth a shot)
Okay, trying the good old fashioned way... brute force
Checking for wildcard DNS...
Nope. Good.
Now performing 2280 test(s)...
Subnets found (may want to probe here using nmap or unicornscan):
Done with Fierce scan: http://ha.ckers.org/fierce/
Found 0 entries.
Die Fierce-Abfrage findet hier keine Einträge, obwohl diese registriert und erreichbar sind.
Hier zeigt sich ein Vorteil großer Anbieter wie Amazon. Deren Angebote bieten weniger Angriffsfläche, um Informationen abzugreifen, und das kann schon viele Angreifer abhalten.
