sternwarte/tex/writeup.tex

\documentclass[10pt]{scrartcl}

\usepackage{slantsc}
\usepackage[utf8]{inputenc}
\usepackage[naustrian]{babel}
\usepackage[paper=a4paper, left=25mm, right=25mm, top=25mm, bottom=30mm]{geometry}
\usepackage{fancyhdr}
\usepackage{listings}
\usepackage{eurosym}
\usepackage{multirow}
\usepackage{graphicx}
\usepackage{url}
\usepackage{DejaVuSans}
\usepackage{DejaVuSerif}
\usepackage{DejaVuSansMono}
\usepackage[T1]{fontenc}
\usepackage{textcomp}
\usepackage{microtype}

\lstset{
	language=,				%language, can be changed dynamically
	basicstyle=\footnotesize\ttfamily,	%common font style
	keywordstyle=\bfseries,
	commentstyle=\itshape,
	stringstyle=\ttfamily,
	showstringspaces=false,
	xleftmargin=8pt,
	numbers=left,						%line numbers
	numberstyle=\tiny,
	numberfirstline=true,
	stepnumber=1,
	numbersep=5pt,
	breaklines=true,
	tabsize=2,							%size of tabulator	
	columns=flexible,
	upquote=true,
	literate=							%Umlauts in source files
	{Ö}{{\"O}}1
	{Ä}{{\"A}}1
	{Ü}{{\"U}}1
	{ß}{{\ss}}2
	{ü}{{\"u}}1
	{ä}{{\"a}}1
	{ö}{{\"o}}1,
}

\newcommand{\mytitle}{Bericht für \emph{www.sternwarte.at}}
\newcommand{\myfoottitle}{Bericht sternwarte.at}

\newcommand{\mysecondtitle}{}
\newcommand{\mythirdtitle}{}
\newcommand{\mydelivery}{}
\newcommand{\myauthor}{Michael Preisach, SIGFLAG}
\newcommand{\mydate}{\today}

\title{\includegraphics[width=3cm]{resources/logo_flat.png}\\[1ex]\textbf{\mytitle}\\[1ex]\normalsize{\mysecondtitle}}
\author{\textbf{\mythirdtitle}}
\date{\mydate}

\pagestyle{fancy}
\fancypagestyle{plain}
{
	\fancyhf{}
	\fancyfoot[L]{\scriptsize{\myfoottitle}}
	\fancyfoot[C]{\scriptsize{}}
	\fancyfoot[R]{\scriptsize{Seite \thepage}}
	\renewcommand{\headrulewidth}{0pt}
	\renewcommand{\footrulewidth}{0.5pt}
}
\fancyhf{}
\fancyfoot[L]{\scriptsize{\myfoottitle}}
\fancyfoot[C]{\scriptsize{}}
\fancyfoot[R]{\scriptsize{Seite \thepage}}
\renewcommand{\headrulewidth}{0pt}
\renewcommand{\footrulewidth}{0.5pt}

\setlength{\parindent}{0mm}

\begin{document}
\maketitle
\section*{Disclaimer}
Dieser Bericht stützt sich ausschließlich auf Daten, die unauthentifiziert abrufbar sind.
Es wurden weder Login-Daten mittels Bruteforce ermittelt, noch per Login geschützte Daten kopiert oder verwendet.

\section{Zusammenfassung}
Tests wurden im Zeitraum von 15. Jänner 2020 bis 17. Februar 2020 vorgenommen. 
Ziel dieses Tests war die Ermittlung der Angriffsoberfläche von \url{www.sternwarte.at}, der verwendeten Infrastruktur sowie eine Analyse der verwendeten Programme um schließlich eine Handlungsempfehlung zu formulieren.
Im Rahmen des Test wurden neben dem Server der Sternwarte auch andere Services gefunden. 
Sofern sich diese im IP-Adressbereich in unmittelbarer Nähe befunden haben, wurden diese Server ebenfalls analysiert.

Im Folgenden werden die wichtigsten Erkenntnisse kurz dargestellt 
\begin{enumerate}
  \item Keine TLS-Verschlüsselung der Website obwohl auf der Website Formulare angeboten werden, die vertrauliche Daten abfragen. 
  	Auch der Admin-login ist unverschlüsselt und kann daher sehr einfach in einem überwachten Netzwerk abgefangen werden.
  	
  \item Unauthentifiziert einsehbare Log-Datei, die Server-Fehler ausgibt.
  \item Der FTP-Server ist auf dem Standardport verfügbar und es ist mutmaßlich verwundbar auf Bruteforce-Attacken.
  \item Die Webseite kann durch modifizierte URLs in der Darstellung verändert werden. Die Daten auf dem Server müssen dafür nicht verändert werden.
  \item Die verwendete Software (4D Webstar 2004) wird vom Hersteller nicht mehr unterstützt.
  Die Tatsache, dass keine dokumentierten Sicherheitslücken existieren ist der mangelhaften Verbreitung und nicht der Qualität der Software zuzuschreiben.
  
\end{enumerate}

\section{Methodik}
In die Untersuchungen waren folgende Personen involviert:
\begin{itemize}
	\item Robert Führicht
	\item Tobias Höller
	\item Michael Preisach
\end{itemize}
Alle genannten sind bei SIGFLAG (\url{www.sigflag.at}) tätig.

\subsection{Informationsgewinnung}
Ziel dieser Analyse ist Informationen über das System hinter \url{www.sternwarte.at} zu finden.
Für die gefundenen Services sollen möglichst alle frei zugänglichen Daten gefunden und ausgewertet werden.
Daraus ergeben sich dann Handlungsempfehlungen, die im Folgenden Teil des Berichts erläutert sind. 

\subsection{Verwendete Programme}
\begin{itemize}
	\item Firefox 72
	\item Nmap 7.80
	\item Dirsearch 0.3.9
	\item TOR Web Browser (Firefox 68)
	\item ftp 1.9.4
	\item OpenBSD netcat 1.206 Debian Patchlevel 1
\end{itemize}

\section{Erkenntnisse}
Über einen einfachen NMap-Scan können folgende Services auf dem Zielhost ermittelt werden:
\lstinputlisting[caption=Ergebnis des Portscans von NMap]{resources/200217-nmap-sternwarte.log}
Daraus ergibt sich folgende Service Liste für \url{sternwarte.at}
\begin{itemize}
	\item Port 21 und 8000: FTP Server und Rumpus FTP Webinterface
	\item Port 80 und 8080: Webstar 4D Webserver
	\item Mail-Service für den Zivilschutzverband Oberösterreich (nur Clientverbindungen)
	\item Mailserver für \url{sternwarte.at}, der auf 2 anderen Hosts angeboten wird.
\end{itemize}
Die folgende Analyse wird in die genannten Services unterteilt.

\subsection{Webserver}
Firefox kann in den Developer Tools die Metadaten des Response Headers analysieren. 
Dort findet sich im Server-Tag die Information des Webservers:

\begin{lstlisting}[numbers=none, caption=HTTP Response Header von \texttt{www.sternwarte.at}]
HTTP/1.1 200 OK
Server: 4D_WebStar_D/2004
Date: Sun, 02 Feb 2020 21:08:44 GMT
Content-Length: 12281
Last-Modified: Sun, 02 Feb 2020 21:08:44 GMT
Connection: Keep-Alive
Content-Type: text/html
\end{lstlisting}

\begin{itemize}
	\item Installierter Server: 4D WebStar\_D/2004, vermutlich installiert auf Mac OS X
\end{itemize}

\subsubsection{Kein TLS}
Die Webseite bietet neben statischen Inhalten auch Anmeldeformulare für Events des Vereins an.
Im Sinne der §§24 ff DSGVO müssen geeignete technische Maßnahmen getroffen werden, damit persönliche Daten nicht an eine unbestimmte Zahl dritter Personen zugänglich gemacht werden kann.
Daher muss eine Verschlüsselung der Kommunikation eingeführt werden, um mit diesen Bestimmungen konform zu werden.
\\[2ex]
\textbf{Handlungsempfehlung:} \\
Einführung von TLS1.2 oder höher für zumindest die Formularseiten, aber auch für das restliche Angebot des Vereins. Da dies aufgrund der veralteten Software nicht direkt unterstützt wird, muss entweder ein TLS-Proxy vorgeschalten werden oder die Website auf einen Server mit aktueller Software umgesiedelt werden.

\subsubsection{Beliebige Frames per URL laden}
Die Darstellung der Webseite gliedert sich in 2 Frames, Verzeichnis und Inhaltsframe. \verb|start.html| stellt dabei den Inhalt dar und \verb|default.html| kümmert sich um das Verzeichnis.
Nun ist es aber möglich, die Homepage mit einer beliebigen zusätzlichen URL aufzurufen:
\begin{center}
	\url{http://www.sternwarte.at/default.html?https://jku.at}
\end{center}
Das Beispiel lädt die Seite der JKU in den Hauptframe anstelle der vorgesehenen Startseite.
Weiters kann auch die eigene Seite geschachtelt aufgerufen werden:
\begin{center}
	\url{http://www.sternwarte.at/?/?/?/}\\ 
\end{center}
Hier wird vier Mal \verb|default.html| aufgerufen und in den Inhaltsframe des vorherigen Aufrufes dargestellt.
Diese Schwachstelle eine Möglichkeit Drive-By-Exploits an Personen, die dieser Website vertrauen, auszuliefern.
\\[2ex]
\textbf{Handlungsempfehlung:} \\
\verb|default.html| darf nur eine definierte Liste an Links entgegennehmen - die der vorhandenen Subseiten (Whitelisting).

\subsubsection{Fehlerhafte Auslieferung spezieller Subseiten}
Es gibt Subseiten, die sich in einem Unterverzeichnis auf dem Server befinden.
Ein aktuelles Beispiel ist:
\begin{center}
	\url{http://www.sternwarte.at/planetenweg/}
\end{center}
Damit dieser Aufruf korrekt erfolgt, muss das Arbeitsverzeichnis auf dem Server gewechselt werden.
Es ist aber möglich, dies zu verhindern, indem der letzte / in der URL weggelassen wird:
\begin{center}
	\url{http://www.sternwarte.at/planetenweg}
\end{center}
Nun können referenzierte Objekte, wie Bilder und Stylesheets nicht mehr geladen werden.
Zusätzlich wird für jedes nicht gefundene Objekt eine Zeile im error.log erzeugt.
\lstinputlisting[linerange={253-278}, caption=Erzeugte Fehler durch fehlerhaften Seitenaufruf]{resources/200217-error.log}

\textbf{Handlungsempfehlung:} 
\begin{itemize}
	\item Aliasing für diese Endpunkte einführen (wie es auch bei den anderen Webauftritten auf diesem Server der Fall ist).
	Damit wird der Browser automatisch auf den richtigen Endpunkt weiter geleitet.
	\item absolute Referenzen in der Seite verwenden oder immer aus dem gleichen Arbeitsverzeichnis den Webauftritt ausliefern.
\end{itemize}

\subsubsection{Öffentlich zugängliche Dateien mit Metainformationen}
Dirsearch traversiert die zugänglichen Seiten auf dem Server, indem es die URL errät.
Dazu hat Dirsearch eine Liste von Verzeichnissen aller gängiger Webserver.
Das Ergebnis dieser Suche:
\lstinputlisting[caption=Mittels DirSearch Gefundene Endpoints]{resources/dirsearch.log}

Die HTTP Statuscodes zeigen, dass einige URLs mit Code 500 antworten.
Bei Aufruf dieser Seiten ist zuverlässig und immer gleich.
Daher ist es sehr wahrscheinlich, dass der \emph{Internal Server Error} nur eine Verschleierungstaktik ist.

Des Weiteren findet sich in Zeile 15 der Ausgabe \verb|.DS_Store| welches auf dem MAC zum Speichern von Metadaten der in diesem Verzeichnis abgelegten Dateien genutzt wird.

Viel Aussagekräftiger ist das \verb|error.log|, das mutmaßlich beim Blacklisting übersehen wurde.
Dieses Log wird wöchentlich in der Nacht von Samstag auf Sonntag gelöscht.
Es werden alle Dateiaufrufe am Server geloggt, die einen Rückgabewert ungleich 0 haben.
Dieses Log bietet eine Vielzahl an Meta-Informationen, die hier nur beispielhaft aufgezählt sind:
\begin{itemize}
	\item Wann sich der Administrator (vermutlich) eingeloggt oder ausgeloggt hat (Rückgabewert > 0)
	\item Dazugehöriger Pfad zum Login des Backends (wieder unverschlüsselt!)
	\item Welche Dateien geöffnet wurden (aber Rückgabewert = 15)
	\item Fehler anderer Webauftritte auf diesem Server \footnote{\url{www.kalendermanufaktur.at}} \footnote{\url{www.baer.co.at}}
	\item Fehlerhaft eingegebene URLs auf diesem Server (alte Seiten auf dem Server oder Metainformationen zu den Besuchern)
	\item Rückgabewerte der Datenbank und der hinterlegten Skripte - Damit kann der Ordner \verb|/4dcgi| durchsucht, bzw. dessen Inhalt aus dem Log ausgelesen werden.
	\item Fehler des Mailservers geben Hinweis auf die Aufgaben des selben. Mehr dazu im Kapitel zu Mailserver
\end{itemize}

Es wurden dank der Dokumentation für 4D WebStar, die noch immer online verfügbar ist\footnote{\url{http://www.island-data.com/downloads/books/4D_Web_Companion.pdf}}, weitere gültige Pfade gefunden:
\begin{itemize}
	\item \verb|/4dstats| - Abrufstatistiken
	\item \verb|/4dhtmlstats| - Abrufstatistiken
	\item \verb|/4dcacheclear| - Leeren des Caches
	\item \verb|/4dwebtest| - Informationen über den verbundenen Client
	\item \verb|/4dblank| - Leere Seite
	\item \verb|/4dmethod| - Kann nicht aufgerufen werden, die URL wird aber erweitert auf beispielsweise\\ \url{http://www.sternwarte.at/4dmethod//%23%231997692744.0}
	\item \verb|/4dssi| - Verbotene Anfrage
\end{itemize}
Alle diese Seiten erzeugen keinen Log-Eintrag und sollten nicht direkt aufgerufen werden können.

Zusätzlich lassen sich die Skripts im Ordner \verb|/4dcgi|, die beispielsweise für das Erfassen der Formulardaten genutzt werden, direkt per URL ausführen, ganz ohne Parameter. Durch das Log können auch per Erraten der Namen weitere Skripte gefunden werden.
\\[2ex]
\textbf{Handlungsempfehlung:} \\
Im Arbeitsverzeichnis des Webservers sollten sich nur Dateien befinden, die mit der Auslieferung der Seite direkt zu tun haben. 
	Für Log-Dateien gibt es eigene Verzeichnisse. 

\subsubsection{Sehr alte Version des Servers}
Der zurzeit laufende Webserver scheint zumindest gegen dokumentierte Schwachstellen geschützt zu sein, die letzten bekannten Bugs CVE 2004-0696 und CVE 2006-6131 haben keinen Erfolg gezeigt.
Die Software wird aber vom Hersteller nicht mehr unterstützt.
Wenn also neue Bugs auftreten, werden diese nicht mehr repariert.
Daher sollte die Webseite auf einem Server betrieben werden, der von den Entwicklern noch mit Updates versorgt wird.
\\[2ex]
\textbf{Handlungsempfehlung:} 
\begin{itemize}
	\item Update der verwendeten Software auf aktuell gewartete Versionen.
	\item Regelmäßige bzw. automatische Updates (zumindest bei reinen Sicherheitsupdates)
\end{itemize}

\subsection{FTP-Server}
Port 21 auf dem Server war zum Zeitpunkt der ersten Untersuchung noch erreichbar.
Der Server bot unverschlüsseltes FTP an und verlangte Username und Passwort.
Wie schon beim Webserver kann hier der Login über das Netzwerk abgefangen werden.

Das gleiche Problem hat auch der Rumpus FTP Server, der über
\begin{center}
	\url{http://www.sternwarte.at:8000}
\end{center}  
erreichbar ist.
Abgesehen von der unverschlüsselten Übermittlung von Login-Daten scheint dieser Service aber aktuell zu sein.
Die dokumentierte Schwachstelle CVE-2019-19368 \footnote{\url{https://github.com/harshit-shukla/CVE/blob/master/CVE-2019-19368 (Un-authenticated).md}}
ermöglicht Cross-Site-Scripting über die URL.
Die Resultierende URL
\begin{center}
	\url{http://www.sternwarte.at:8000/Login?!%27%3E%3CsVg/OnLoAD=alert`1`//}
\end{center}
blieb ohne Effekt.
\\[2ex]
\textbf{Handlungsempfehlung:}
\begin{itemize}
	\item FTP ausschließlich über eine verschlüsselte Verbindung anbieten.
	Einerseits kann dafür Secure FTP verwendet werden, was inzwischen die meisten FTP Server anbieten.
	Andererseits bietet auch SSH einen File Transfer Modus an, der in den Einstellungen des SSH aktiviert werden kann.
	\item Passwort-Authentifizierung durch Key-Based Authentication ersetzen.
	FTP over SSH bietet zusätzlich die Möglichkeit, die Authentifizierung über Public/Private Keys zu machen, um Bruteforce-Attacken auf Passwörter zu unterbinden.
	\item Fail2Ban aktivieren. Damit können Firewall-Regeln dynamisch angepasst werden, wenn ein Client zu oft versucht, sich mit falschen Login-Daten zu authentifizieren.
	\item WebFTP ausschließlich über TLS anbieten (gleiche Handlungsempfehlung, wie bei Webserver weiter oben).
\end{itemize}

Nachtrag: Zumindest auf dem Server, der \url{www.sternwarte.at} ausliefert, ist eine Firewall aktiviert worden, die Anfragen auf diesen Port droppt (keine Antwort zurückschickt). 
Etwas später zeigt NMap wieder, dass der Port 21 zwar offen ist, allerdings antwortet der Server nicht auf Anfragen.
Es ist daher nicht ganz klar, ob hier eine Firewall eigenartige Verbindungszustände hervorruft oder der Service zurzeit nicht ordnungsgemäß läuft.

\subsection{Mail-Server}
Hier sind zwei verschiedene Services entdeckt worden, die im folgenden behandelt werden.
\begin{itemize}
	\item Mailserver, die für die Domain \url{sternwarte.at} im DNS eingetragen sind
	\item Der SMTP-Server, der direkt auf dem Server läuft
\end{itemize}

\subsubsection{Mailserver, der laut DNS zuständig ist}
\lstinputlisting[caption=Mittels DirSearch Gefundene Endpoints]{resources/dig-mx-sternwarte.log}
Im DNS stehen zwei Server als Mail-Server (MX) zur Verfügung: 
\begin{itemize}
	\item \url{nihal.mag.eu} (85.126.106.144) 
	\item \url{mizar.mag.eu} (85.126.106.142) 
\end{itemize}
Beide Hosts haben laut NMap-Bericht Port 25 für SMTP offen:
\lstinputlisting[caption=NMap Portscan auf \texttt{nihal.mag.eu}]{resources/200217-nmap-nihal.log}
\lstinputlisting[caption=NMap Portscan auf \texttt{mizar.mag.eu}]{resources/200217-nmap-mizar.log}
Bei der ersten Analyse dieses Services war nur eine unverschlüsselte Verbinudung möglich.

Inzwischen wurde auf diesen Servern STARTTLS aktiviert.

\subsubsection{Mailserver auf \texttt{sternwarte.at}}
Im Errorlog des Webservers ist am 28. Jänner ein Fehler des internen Mailservers aufgetreten:
\lstinputlisting[caption=Fehler des Mailservers auf \texttt{sternwarte.at}, linerange={166-188}]{resources/200131-error.log}

Dies dokumentiert die Funktion des Services für \url{sms.zivilschutz-ooe.at}.
Der DNS-Eintrag für diese Domain zeigt auf 85.126.106.150, was die \emph{benachbarte} IP-Adresse zu \url{sternwarte.at} ist.
Es ist nicht nachvollziehbar, warum diese Fehlermeldung im error.log der Sternwarte-Website auftritt.
Am wahrscheinlichsten ist, dass hinter beiden IPs der selbe Server läuft und es keine Trennung der Services voneinander gibt.

Diese Vermischung unterschliedlicher Services darf in einem Produktivsystem nicht passieren.
\\[2ex]
\textbf{Handlungsempfehlung:}
\begin{itemize}
	\item Sofern der Betrieb unterschiedlicher Domains auf einem Host erforderlich ist, sollten zumindest alle Ressourcen der verschiedenen Services auf dem Server (User, Dateien, Berechtigungen) möglichst weitgehend voneinander getrennt werden.
	\item Stand der Technik ist die Trennung der Webseiten auf Service-Ebene (z.~B. Docker), Betriebssystem-Ebene (mittels virtueller Maschinen) oder getrennte Hardware. Letzteres wäre in diesem Fall sogar recht einfach möglich, da schon 2 unterschiedliche IPs eingerichtet sind.
\end{itemize}

\end{document}