Datenleck bei Facebook und SMS-Spam (updated)

Seit einigen Tagen erhalte ich teilweise mehrmals täglich SMS-Nachrichten, die thematisch immer den gleichen Inhalt haben:

  • Ihr Paket wird heute zugestellt.
  • Ihr Paket liegt zur Abholung bereit.
  • Ihr Paket wird in 30 Minuten zugestellt.
  • Ihr Paket wurde zum Absender zurück geschickt.

Natürlich in schlechtem Deutsch und ohne weitere Angaben. Gefolgt von einem verdächtigen Link, bei dem schon die Domain vollkommen abwegig aussieht. Hier hat sich also jemand nicht mal die Mühe gemacht, die Domains der großen Logistiker nachzuahmen. Teilweise fordern die SMS auch auf, dass man die eigenen Angaben vervollständigen müsse. Und immer: Man soll doch unbedingt auf den Link klicken.

Medienberichten zu folge betrifft dies eine Vielzahl von Handynutzern in Deutschland. Das BSI meldet, dass sich hinter dem Link in der Regel der Android-Trojaner FluBot verbirgt und man solle selbstverständlich keinesfalls den Link anklicken. Aber woher kommt diese Spam-Welle?

Nur wenige Tage zuvor wurden die Daten von 533 Millionen Facebook-Nutzern öffentlich. Neben persönlichen Informationen sind dabei auch die Telefonnummern der User veröffentlicht worden. Es ist allerdings nicht so einfach herauszufinden, ob man selbst von dem Datenleck betroffen ist. Facebook jedenfalls hat bereits mitgeteilt, dass sie NICHT die User darüber informieren möchten, ob sie betroffen sind.

Was kann man jetzt machen? Auf der Webseite https://fbleak.freddygreve.com/ kann man anhand des Links zur eigenen Facebook-Profil-Seite prüfen, ob man betroffen ist von dem Datenleck. Und nun? Kann man eigentlich wenig machen. Den Link nicht anzuklicken und die SMS zu löschen ist ja selbstverständlich. Leider hat man sonst nicht viele Möglichkeiten. Um sicherzugehen, nicht in eine Abofalle zu tappen, empfiehlt F. Greve die Drittanbietersperre beim Provider einzurichten. Problem ist dann nur, dass dann auch legitime Abbuchungen über die Mobilfunkrechnung nicht mehr möglich sind.

Den Umgang Facebooks mit dem Datenleck sehe ich kritisch. Es wirkt so, als würde es Facebook nicht im Ansatz interessieren, dass Ihnen Daten abhanden gekommen sind. Angeblich ist dies auf eine Sicherheitslücke zurückzuführen, die 2019 geschlossen wurde und damit ist der Fall für Facebook abgeschlossen. Zumindest eine umfassende Information der betroffenen User hätte ich von Facebook erwartet. Es sind schließlich nicht alle User so technik-affin und können die Fake-SMS als solche identifizieren.

Update:
Der SMS-Spam hat bei mir vor einigen Tagen plötzlich stoppt. Bisher habe ich noch keine Meldung gefunden, ob es hier ggf. ein Eingreifen der Provider gab oder was nun dafür gesorgt hat, dass die SMS aufhören.

100 Days of Hacking ?

Derzeit überlege ich, wie ich mein Wissen und meine Fähigkeiten im Bereich Penetration Testing zielgerichtet und strukturiert weiter ausbauen kann. Es gibt da diese Herausforderung #100daysofX, die sich an alle möglichen Verhaltensänderungen richtet. Bei der Challenge geht es darum, 100 Tage am Stück ohne Unterbrechung an einem Thema zu arbeiten. Dabei soll man jeden Tag mindestens 1 Stunde investieren und seinen Fortschritt idealerweise via Twitter öffentlich dokumentieren.

Die Idee finde ich gut, nur überlege ich gerade wie ich das am besten starten kann. Viele haben diese Challenge als 100 Days of Code gemacht. Bei Programmieren geht das vielleicht etwas leichter. Man kann sich immer wieder ein neues Framework oder eine fiktive Aufgabe überlegen und an dieser arbeiten.

Ich plane mir das erstmal etwas durch. Eine Idee wäre, kontinuierlich an alten HackTheBox VMs zu arbeiten. Mir ist das allerdings zu unstrukturiert. Beim TryHackMe Advent of Cyber habe ich gemerkt, dass man bei diesen CTF-ähnlichen Challenges zwar sehr schnell mit sehr vielen Tools und Konzepten in Berührung gebracht wird, aber selten wirklich den Funktionsumfang, bspw. von Gobuster, betrachtet. Oder was kann man mit nmap alles machen und welche Konsequenzen haben die verschiedenen Scanoptionen?

Eine weitere Idee ist, dass ich mich an einem Buch orientiere. Zum Geburtstag habe ich mir das Buch „Exploit!“ von Gebeshuber, Teiniker und Zugaj schenken lassen. Alternativ habe ich aus dem selben Verlag noch das Buch „You’ve been hacked“ von Eilers hier, in das ich bisher auch nur punktuell reingelesen habe. Der Plan wäre dann das Buch durchzuarbeiten von Seite 1 bis zum Ende. Jeden Tag eine Stunde. Und dann werde ich ja sehen, wo ich zeitlich lande.

Humble Bundle Hacker 101

Es ist Dezember und damit wieder die Zeit der Geschenke. Geschenkt bekommt man zwar nichts im aktuellen Humble Bundle, jedoch ist der Preis so niedrig, dass es fast wie geschenkt ist.

Humble Bundle hat mit dem „Hacker 101“ Bundle mal wieder einige Klassiker aus dem Bereich der IT-Sicherheit von No Starch Press als E-Book im Angebot. Neben klassischen Büchern, wie Jon Ericksons „Hacking: The Art of Exploitation“ in der 2. Auflage, gibt es bei der aktuellen Aktion auch aktuellere Bücher wie „Black Hat Go“ von Steele, Patten und Kottmann (1. Aufl., 2020) oder „Web Security for Developers“ von Malcom McDonald (1. Aufl., 2020). Generell finde ich die Bücher von No Starch Press im Bereich IT-Security besonders gut und kaufe daher gerne auch die neuen Publikationen von diesem Verlag, weshalb ich hier auch auf dieses Humble Bundle hinweisen möchte.

Auch wenn ich einige der Bücher bereits in gedruckter Form besitze, hat sich das Bundle für mich gelohnt und ich habe für den Preis zugeschlagen. Für etwas mehr als 15 € erhält man alle 16 Fachbücher der Aktion. Einige davon hatte ich sowieso schon auf meiner Wunschliste. Und nebenbei unterstützt man auch einen guten Zweck. Einen Teil der Kosten kann man direkt an die National Coalition Against Censorship spenden.

Wer sich dafür interessiert, hier ist der Link zu diesem IT-Security- und Hacking-bezogenen Humble Bundle: https://www.humblebundle.com/books/hacking-101-no-starch-press-books

Achja, dies ist selbstverständlich nur eine Empfehlung und keine Aufforderung zum Kauf! (#unbezahlteWerbung) 🙂

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