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,
}
\clubpenalty = 10000
\widowpenalty = 10000
\displaywidowpenalty = 10000

\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 frei 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 19. 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}
\newpage
\section{Methodik}
In die Untersuchungen waren folgende Personen involviert:
\begin{itemize}
	\item Robert Führicht (\url{fuerob@gmail.com})
	\item Tobias Höller
	\item Michael Preisach (\url{michael@preisach.at})
\end{itemize}
Alle genannten sind bei SIGFLAG (\url{www.sigflag.at}) tätig.

\subsection{Informationsgewinnung}
Ziel dieser Analyse war, 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
	\item DiG 9.14.10
	\item testssl.sh 3.0
\end{itemize}

\subsection{3 Kategorien der Informationssicherheit}
Jede Schwachstelle wird in der folgenden Analyse in die drei Kategorien der Informationssicherheit eingeordnet.
Diese Kategorien sind:
\begin{enumerate}
	\item Vertraulichkeit/Confidentiality (C) -- Ein Service muss den Zugriff auf Daten auf das notwendige beschränken.
	Das bedeutet, dass die Daten dieses Services nur von den autorisierten Benutzern gelesen werden darf.
	Ein Service darf seine Daten nur an autorisierte Benutzer weitergeben.
	Unautorisierte Dritte müssen zuverlässig vom Zugriff auf diese Daten ferngehalten werden.
	Dies gilt auch für die Übertragung zum Benutzer und Speicherung der Daten abseits vom System (z.~B. Für ein Backup)
	\item Integrität/Integrity (I) -- Der Service muss sicherstellen, dass die Daten unverändert und vollständig vorgehalten werden.
	Es muss also verhindert werden, dass die Daten von nicht autorisierten Benutzen oder durch unerwartetes Verhalten des Services modifiziert werden können.
	\item Verfügbarkeit/Availability (A) -- Der Service muss verfügbar sein, wenn dieser benötigt wird.
	In diesem Fall sind vor Allem Maßnahmen gegen Denial-of-Service (DoS) Angriffe zu berücksichtigen.
\end{enumerate}

\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
\end{itemize}
Im Laufe der Untersuchungen wurden noch weitere Services gefunden:
\begin{itemize}
	\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}
Im folgenden werden die genannten Services analysiert.
Mit den angegebenen Handlungsempfehlungen ist es möglich die ausgeführten Probleme umfassend zu lösen.

\subsection{Webserver}
Firefox kann in den Developer Tools die Metadaten des Serverantwort analysieren. 
Im Server-Tag finden sich 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.

Weiters wird die Unterstützung von TLS Versionen vor TLS1.2 noch im Laufe des Jahres 2020 von den Browserherstellern abgeschaltet.
\\[2ex]
\textbf{Informationssicherheit:}
\begin{itemize}
	\item Confidentiality: Daten können bei Übertragung in beide Richtungen beliebig eingesehen werden.
	\item Integrity: Daten und Inhalte können in beide Richtungen beliebig verändert werden, es findet keine Integritätsprüfung an den Daten statt.
	\item Availability: Einem Angreifer ist es möglich ein unverschlüsseltes Passwort beim Login abzufangen und damit den kompletten Webauftritt bzw.\@ den Server zu übernehmen.
\end{itemize}
\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 
\begin{itemize}
	\item ein TLS-Proxy vorgeschalten werden,
	\item ein Reverse-Proxy TLS terminieren oder
	\item oder die Website auf einen Server mit aktueller Software umgesiedelt werden.
\end{itemize} 


\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 stellt eine Möglichkeit dar, Drive-By-Exploits an Personen, die dieser Website vertrauen, auszuliefern.
\\[2ex]
\textbf{Informationssicherheit:}
\begin{itemize}
	\item Confidentiality: Benutzer könnten auf gefälschten Webseiten vertrauliche Daten weiter geben.
	\item Integrity: Die eingegebenen Daten auf den gefälschten Webseiten werden wahrscheinlich nicht den Weg in die korrekte Datenbank finden.
	\item Availability: Durch das Laden von Inhalten anderer Seiten kann recht zuverlässig. verhindert werden, dass die vorgesehenen Inhalte tatsächlich angezeigt werden.
\end{itemize}
\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{Informationssicherheit:}
\begin{itemize}
	\item Confidentiality: Keine Auswirkungen.
	\item Integrity: Die Integrität der ausgelieferten Webseite ist nicht gegeben.
	\item Availability: Die ausgelieferte Webseite ist unvollständig und daher eingeschränkt bis gar nicht benutzbar.
\end{itemize}

\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 weitergeleitet.
	\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 dieser zuverlässig und immer gleich.

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 protokolliert, 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{Informationssicherheit:}
\begin{itemize}
	\item Confidentiality: Informationen über den Server, dessen Benutzer und anderer Webseiten werden ohne autorisierung frei gegeben.
	\item Integrity: Unsicher, da nicht klar ist, ob die CGI-Skripte Datenbanken verändern oder nicht.
	\item Availability: Keine Auswirkung.
\end{itemize}
\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. 

Ist die Trennung von Log-Dateien und den auszuliefernden Webinhalten nicht möglich, muss entweder das Blacklisting um die entsprechenden Endpunkte erweitert werden oder ein vorgeschaltener Webproxy diese Aufgabe übernehmen. 

\subsubsection{Sehr alte Version des Servers}
Der zurzeit laufende Webserver scheint zumindest gegen dokumentierte Schwachstellen geschützt zu sein, die letzten bekannten Bugs \emph{CVE-2004-0696} und \emph{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 einer Version des Produkts (4D) betrieben werden, die von den Entwicklern noch mit Updates versorgt wird.
\\[2ex]
\textbf{Informationssicherheit:}
\begin{itemize}
	\item Confidentiality: Die verwendete Software ist nicht mehr in der Lage, die Daten vertraulich zu halten.
	\item Integrity: Undokumentierte Schwachstellen können jederzeit Daten kompromittieren.
	\item Availability: Die gleichen Schwachstellen können auch die Verfügbarkeit des Servers stören.
\end{itemize}
\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 \emph{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{Informationssicherheit:}
\begin{itemize}
	\item Confidentiality: Die übermittlung der Daten zwischen Server und Client sind nicht geschützt. Das gilt für das Rumpus Webinterface als auch für den FTP-Port.
	\item Integrity: Die Daten können während der Übertragung beliebig verändert werden.
	\item Availability: Wenn der Angreifer das unverschlüsselte Passwort bei der Übertragung abfängt, kann dieser wahrscheinlich den Webauftritt beliebig verändern.
\end{itemize}
\textbf{Handlungsempfehlung:}\\
Es gibt mittlerweile eine große Zahl an Argumenten, FTP nicht mehr zu verwenden.
Der folgende Link fasst die Argumente anschaulich zusammen:
\begin{center}
	\url{http://mywiki.wooledge.org/FtpMustDie}
\end{center}
Die moderne Alternative zu FTP ist SFTP, also FTP over SSH.
SFTP kann alle Funktionen von bisherigen FTP übernehmen und sollte daher ersatzlos zum Einsatz kommen.
Folgende Punkte sind zusätzlich zu beachten:
\begin{itemize}
	\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 (Rumpus) 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=Mail Extension DNS Eintrag für \texttt{sternwarte.at}]{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.
Eine Analyse mit TestSSL zeigt (siehe Anhang), dass der Server SSLv3 anbietet.
Dieses Protokoll wird schon seit längerem als unsicher gesehen.
Für TLS 1.0 und 1.1 gilt das schon beim Webserver Beschriebene.
\\[2ex]
\textbf{Informationssicherheit:}
\begin{itemize}
	\item Confidentiality: SSLv3 kann die Vertraulichkeit der Daten bei Übertragung nicht mehr gewährleisten.
	Bei den älterene TLS Versionen ist dies auch nur bedingt der Fall.
	\item Integrity: Wie bei der unverschlüsselten Übertragung kann auch hier die Integrität der Daten nur mit funktiostüchtiger Kryptogrfie sichergestellt werden.
	\item Availability: Die Veränderung der Daten kann auch die Verfügbarkeit des Services beeinträchtigen.
\end{itemize}
\textbf{Handlungsempfehlung:}\\
Wie beim Webserver sollte auch für den SMTP-Service die Verschlüsselung auf den Stand der Technik gebracht werden.


\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.
\\[2ex]
\textbf{Informationssicherheit:}
\begin{itemize}
	\item Confidentiality: Die Anzeige von Fehlern eines komplett unabhängigen Services darf nicht passieren.
	\item Integrity: Schwachstellen fremder Services wirken sich auf die Integrität des Webauftritts der Sternwarte Linz aus.
	\item Availability: Die gleichen Schwachstellen können auch die Verfügbarkeit des Webauftritts beeinträchtigen.
\end{itemize}
\textbf{Handlungsempfehlung:}\\
Trennung des Services für die Sternwarte von den anderen, die auf diesem Server zurzeit laufen.
	

\section{Zusammenassung}
Im Folgenden sind die wichtigsten Handlungspunkte zusammengefasst:
\begin{itemize}
	\item Software aktualisieren
	\item Webauftritt nur über TLS anbieten und die TLS-Konfiguration auf Stand der Technik bringen
	\item FTP-Server durch SFTP ersetzen
	\item TLS-Konfiguration am Mailserver auf den Stand der Technik anpassen
	\item Trennen der Inhalte der unterschiedlichen Webauftritte.
	Alle Inhalte von \url{sternwarte.at} sollten auf einem eigenen System gehostet werden und sich mit anderen Inhalten nicht überschneiden.
\end{itemize}

\appendix
\section{TestSSL Ergebnisse der Mailserver}

\lstinputlisting[caption=TestSSL Ergebnis für \texttt{nihal.mag.eu}]{resources/200219-testssl-nihal.log}
\lstinputlisting[caption=TestSSL Ergebnis für \texttt{mizar.mag.eu}]{resources/200219-testssl-mizar.log}
\end{document}