Walkthrough – Lame (HTB)

In diesem Beitrag beschreibe ich meine erste Maschine, die ich bei Hack The Box gelöst habe. Da es meine erste Box war, brauchte ich leider an einer Stelle einen Hinweis. Dennoch war es interessant diese einfache Maschine zu lösen.

Recon

Nach dem Start der VM ist diese über das VPN von Hack The Box erreichbar. Mittels ping sehe ich, dass ich die Maschine unter der IP 10.10.10.3 erreichen kann.

Ein Scan der Ports mit nmap bringt mir:

PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
139/tcp open netbios-ssn
445/tcp open microsoft-ds
3632/tcp open distccd

139 und 445 sind Ports für samba. Ein erster Verbindungsversuch klappt leider nicht. Der Befehl unten bringt nur eine Fehlermeldung.

Nach Recherche zu dem Fehler habe ich herausgefunden, dass die Maschine vermutlich SMBv1 verwendet, die seit langem deprecated ist. Mit der folgenden Option im Befehl kann man aber SMBv1 erzwingen:

Damit kann man sich mit der Maschine verbinden und bekommt folgende Infos:

Enter WORKGROUP\root’s password:
Anonymous login successful

Reconnecting with SMB1 for workgroup listing.
Anonymous login successful

In die einzelnen Verzeichnisse kann man sich entweder als anonymer User nicht verbinden oder es sind keine interessanten Daten enthalten, bspw. in /tmp .

smb: > dir
. D 0 Tue Jul 14 09:39:02 2020
.. DR 0 Sun May 20 20:36:12 2012
5118.jsvc_up R 0 Tue Jul 14 09:09:05 2020
.ICE-unix DH 0 Tue Jul 14 09:07:57 2020
.X11-unix DH 0 Tue Jul 14 09:08:22 2020
.X0-lock HR 11 Tue Jul 14 09:08:22 2020

7282168 blocks of size 1024. 5678808 blocks available

Exploit

Die Maschine nutzt also SMBv1. Dies ist die Stelle, an der ich Hilfe brauchte. Wenn man nach CVEs sucht zu SMBv1, findet man extrem viele und mir fiel es im ersten Moment schwer, hier etwas brauchbares zu finden in der Menge.

Der CVE-2007-2447 ist die richtige Adresse. Denn zu diesem CVE gibt es ein fertiges Modul in Metasploit. Der folgende Befehl startet das Modul in Metasploit:

Mit „show options“ werden die Parameter angezeigt und „set RHOSTS 10.10.10.3“ legt die Ziel-IP-Adresse fest. Der Befehl „exploit“ führt das Script anschließend aus und liefert direkt eine root-Shell auf dem Opfer-System.

Hier finden sich dann die Flags in /home/makis (user-flag) bzw. in /home/root (root-flag).

Zusammenfassung

Das grundsätzliche Problem des Opfer-Systems ist das veraltete Samba. In der Version 1, die auch seit längerem deprecated ist, finden sich viele Sicherheitslücken und das Metasploit-Modul funktioniert erschreckend einfach. Dass man damit sofort eine root-Shell auf dem Zielsystem hat, ist als besonders kritisch anzusehen.

Meine erste Bug Bounty Meldung – ausgerechnet bei Facebook

Gestern ist mir -mehr durch Zufall als durch bewusstes Suchen- ein Sicherheitsproblem bei Instagram aufgefallen, als ich jemanden helfen wollte. So beginnt meine erste Sicherheitsmeldung im Rahmen eines Bug-Bounty-Programms und dann ausgerechnet bei Facebook.

Instagram gehört zu Facebook und es gibt von Facebook ein offizielles Bug-Bounty-Programm. Weitere Infos kann man hier finden. Wenn man der Meinung ist, dass man ein Sicherheitsproblem gefunden hat, kann man dieses hier melden. Das Formular zum Melden ist relativ überschaubar. Man gibt an, was man gefunden hat, welche Auswirkungen dies hat und wie man den Fehler reproduzieren kann. Bedingung von Facebook ist, dass man das gefundene Problem nicht veröffentlicht, bis es von den Security Engineers von Facebook geprüft und behoben wurde. Im Gegenzug stellt Facebook dem Melder eine Belohnung (Bounty) in Aussicht. Laut Beschreibung mind. 500 $, kann aber je nach schwere der Sicherheitslücke auch mehr werden. Darüber hinaus wird man auf einer Art Wall of Fame namentlich genannt – ok, geschenkt. 😉

Ich denke meine gefundene Schwachstelle ist nicht extrem kritisch, trotzdem war ich überrascht, dass sie überhaupt existiert. Sobald Facebook meine Meldung geprüft hat, kann ich hier hoffentlich mehr ins Detail gehen. Gleichzeitig bin ich natürlich gespannt, wie schnell meine Anfrage bearbeitet wird von Facebook und ob diese tatsächlich als Sicherheitslücke eingestuft wird. Ich werde hier auf jeden Fall berichten, egal wie die Geschichte am Ende ausgeht.

Authentifikation vs. Autorisation

In meinem ersten Beitrag hatte ich angekündigt, dass ich mich als erstes mit den Begriffen Authentifikation und Autorisation beschäftigen möchte. Mir fällt immer wieder auf, dass diese beiden Begriffe oft zusammen auftauchen, aber von vielen Menschen falsch oder sogar synonym verwendet werden. Dies führt im (Arbeits-)Alltag häufig zu Missverständnissen bei allen Beteiligten. Daher möchte ich hier mal grundlegend die beiden Begriffe voneinander abgrenzen und den Unterschied verständlich darstellen.

Authentifikation

Die Authentifikation lässt sich bspw. mit der Passkontrolle am Flughafen vergleichen. Bevor ich in ein Land einreisen kann, muss meine Identität geprüft und bestätigt werden. Ich könnte ja einfach sagen, ich bin übrigens Herr Schmidt aus Berlin. Der Beamte wird mir das aber nicht glauben, weil das könnte ja jeder behaupten. Stattdessen muss er meine Identität feststellen. Mir als Person kann er nicht vertrauen, aber er vertraut anderen Staaten, die Reisedokumente ausstellen. Anhand von meinem (gültigen) Reisepass kann ich nun meine Identität bestätigen und der Grenzbeamte kann dies auch überprüfen.

Bei Informationssystemen (bspw. Webanwendungen), muss ebenfalls meine Identität festgestellt werden. Die Authentifikation kann dabei mittels verschiedener Faktoren erfolgen. Der bekannteste Authentifikationsfaktor ist sicher Benutzername und Passwort. Das bedeutet man geht davon aus, dass jemand, der den Benutzernamen und das dazugehörige Passwort kennt, sicher die Identität ist, die der Anwender vorgibt zu sein. Wenn jemand anderes dieses Passwort kennt oder errät, kann er in dem Fall die Identität des Anwenders annehmen. Weitere Faktoren, die zur Authentifikation dienen können, sind Client-Zertifikate, zusätzliche zur Anmeldung notwendige Sicherheitscodes per SMS oder mobiler App, oder auch biometrische Merkmale wie Fingerabdruck oder Gesicht. [1]

Autorisation

Bei der Authentifikation geht es somit ausschließlich um die Indentitätsfeststellung des Anwenders. Es wird dabei nicht entschieden, welche Rechte oder Zugriffe innerhalb der Anwendung für den Anwender möglich bzw. verboten sind. Die Steuerung von Zugriffen und das Erteilen von Berechtigungen ist die Autorisation. [2]

Oft hängt die Autorisation mit der Authentifikation zusammen. Nur wenn die Anwendung weiß, wer der Anwender ist, kann die Entscheidung getroffen werden, welche Funktionen und Informationen der Anwender aufrufen darf. Die Berechtigung kann dabei direkt mit der Identität des Anwenders zusammenhängen (bspw. Zugriff auf eigenes/persönliches Bankkonto) oder mit einem anderen Merkmal verknüpft sein, wie bspw. einer Rollen- oder Gruppenzuordnung (Datenbank-Administratoren, die auf alle Bankkonten zugreifen können). Das Festlegen und Erteilen von Zugriffsberechtigungen ist somit zwar abhängig von der Authentifikation ist aber je nach Applikation sehr spezifisch und muss daher separat davon betrachtet werden.

tl;dr

Die Authentifikation ist die Feststellung der Identität. Die Autorisierung ist die Festlegung, welche Zugriffe für die authentifizierte Identität möglich sind. Die beiden Begriffe hängen zwar zusammen, sollten aber bei der Entwicklung von Systemen und Anwendungen einzeln betrachtet werden. Auf jeden Fall muss darauf geachtet werden, dass diese Begriffe keine Synonyme sind.

Quellen

  1. Eckert, Claudia (2014): IT-Sicherheit, 9. Auflage, S. 8 
  2. Eckert, Claudia (2014): IT-Sicherheit, 9. Auflage, S. 5