Neue Kriminalitätswelle: Angriff auf mittelständische Websites

(http://www.zdnet.de/magazin/39194140/neue-kriminalitaetswelle-angriff-auf-mittelstaendische-websites.htm)

von Christoph H. Hochstätter, 30. Juli 2008

Cyberkriminelle haben oft schlecht gesicherte Websites von Mittelständlern als Angriffsziel entdeckt. ZDNet erklärt die zum Teil erschreckend einfachen Methoden und zeigt auf, wie dadurch unbeteiligte Nutzer geschädigt werden.

Zur Malwareverbreitung müssen Cyberkriminelle neue Wege einschlagen. Gängige Konzepte, zum Beispiel Phishing[1], verlieren mehr und mehr an Effektivität. Während es vor etwa zwei Jahren noch leicht möglich war, Nutzer mit Spam-Mails zu täuschen und auf eine gefälschte Website einer Bank zu locken, greift dieses Konzept wegen des gestiegenen Sicherheitsbewusstseins der Benutzer kaum noch.

Websites von Banken, Bezahlsystemen und großen Unternehmen stehen dabei nicht im Vordergrund. Die großen Firmen betreiben erheblichen Aufwand, um Einbruchsversuche abzuwehren. Für den Fall, dass es doch einmal gelingt, gibt es ausgeklügelte Monitoringsysteme, die den Einbruch erkennen. Eine Lücke kann binnen weniger Minuten geschlossen werden.

Im Visier der Cyberkriminellen stehen vielmehr Websites kleiner und mittelständischer Unternehmen. Kleine Internethändler erfreuen sich bei den Verbrauchern immer größerer Beliebtheit. Den Kaffeevollautomat kaufen Haushalte gerne im Internet bei einem Fünf-Mann-Unternehmen 30 Prozent unterhalb des Preises einer Fachmarktkette, die laut eigenem Bekunden einst "Geiz geil" fand und jetzt "teuer hasst". Der preisbewusste Verbraucher kauft sein Aspirin beim Apotheker um die Ecke, allerdings bestellt er über das Internet, denn dann bekommt er es beim selben Apotheker um bis zu 50 Prozent günstiger.

Allzu großen Aufwand mit der Sicherheit betreiben die kleinen Händler allerdings nicht. Meist verwenden sie eine konfektionierte Shop-Lösung von einem Hoster. Die optische Gestaltung übernimmt häufig eine kleine Agentur. Solche kleinen Shop-Lösungen sind recht anfällig für einen Hackerangriff.

Doch auch Websites, auf denen nur Information angeboten wird, stehen im Fokus von Cyberkriminellen. Ein Beispiel ist die ARD[2]. Wer sich dort jüngst über das aktuelle Tagesprogramm informieren wollte, wurde per eingeschleustem Javascript[3] auf eine chinesische Website umgeleitet. Dort befand sich eine Malware, die einen Drive-by-Download[4] auslöste.

Die Verantwortlichen haben offenbar die Gefahr unterschätzt, die auch für eine klassische Web-1.0-Anwendung existiert, auf der ausschließlich Informationen zum Abruf angeboten werden. Wie der gefährliche Javascript-Code auf den Server kam, ist im Detail nicht bekannt. Die Möglichkeiten dazu sind allerdings vielfältig.Insbesondere Anbieter von Shops können Opfer einer SQL-Injection-Attacke[5] werden. Sie nutzt mangelnde Sorgfalt beim Wandel eines HTTP[6]-Request in ein SQL[7]-Statement. Löst beispielsweise der Request http://myshop.example.com/showproducts?Warengruppe=1 das SQL-Statement SELECT * from Products Where Warengruppe = 1 aus, so lässt sich das programmiertechnisch dadurch lösen, dass man die "1" aus dem HTTP-Request nimmt und einfach an den Textstring "SELECT * from Products Where Warengruppe =" anhängt.

Auf diese Weise kann ein Angreifer jedoch beliebige SQL-Statements ausführen, wenn er beispielsweise den HTTP-Request http://myshop.example.com/showproducts?Warengruppe=1;UPDATE ... verwendet. So kann er beliebige Felder in der Datenbank mit eigenen Werten belegen.

Es bietet sich für den Angreifer an, die Produktbeschreibung oder den Produktnamen zu verändern. Aus "Dampfbügeleisen" macht der Angreifer einfach "<script>[Bösartiger Code]</script>Dampfbügeleisen". Der Betrachter sieht nach wie vor den gleichen Text. Doch währenddessen wird der eingeschleuste Javascript-Code bereits ausgeführt.

Grundsätzlich gilt, dass der Programmierer der Webanwendung den HTTP-Request so zu untersuchen hat, dass eine Ausführung ungewollter SQL-Befehle nicht möglich ist. Dazu bieten die gängigen Skript-Sprachen, beispielsweise Perl[8] und PHP[9], mittlerweile umfangreiche Hilfestellungen in Form von Parsern[10]. Auch die Datenbankhersteller leisten ihren Beitrag zur Sicherheit mit Prepared Statements[11].

Doch in der Praxis sieht es anders aus. Das Sicherheitsunternehmen ScanSafe[12] stellte im Mai 2008 fest, dass die Anzahl der durch SQL-Injection-Attacken verseuchten legitimen Websites im Vergleich zum Vorjahr um 407 Prozent gestiegen war.

Viele kleinere Shoplösungen sind nach wie vor anfällig für SQL-Injection-Attacken. Die in die Server eingeschleuste Malware ist vielfältig. Den Löwenanteil bildet Malware, die darauf ausgerichtet ist, Besuchern einer Website andere Malware auf den eigenen Rechner zu schleusen, meist klassisch über eine versteckte Umleitung zu Malware-Servern, von denen ein Drive-by-Download gestartet wird.

Eine andere Art von Malware versucht sich auf dem Server einzunisten und dort persönliche Daten der Benutzer zu stehlen. Dies kann dadurch geschehen, dass ein Shell-Statement[13] des jeweiligen Datenbankservers ausgeführt wird. Dann kann der Angreifer beliebigen Code unter dem Sicherheitskontext des Datenbankservers ausführen.

Neben Zahlungsdaten, zum Beispiel Kreditkartennummern, sind vor allem Passwörter von Interesse. Auch kleinere Shop-Lösungen erlauben es den Benutzern meist, eine User-ID anzulegen, um nicht bei jedem Besuch Daten wie Liefer- und Rechnungsanschrift neu eingeben zu müssen.

Da die Anwender meist das gleiche Passwort für mehrere Online-Angebote verwenden, sind Passwörter bei Web-Shops eine wertvolle Beute von Cyberkriminellen. Zu User-ID und Passwort bekommt der Angreifer Namen und Adresse gleich dazu. Oft müssen Benutzer als User-ID eine gültige E-Mail-Adresse verwenden. Der Versuch sich mit diesen Daten in Bezahlsystemen einzuloggen, zum Beispiel PayPal[14], führt nicht selten zum Erfolg.

Unternehmen, die ihre Produkte im Internet anbieten möchten, schützen sich am besten, indem sie einen vorkonfektionierten Shop bei einem großen Hoster anmieten. Ein großer Hoster ist natürlich ein lohnendes Ziel für einen Angreifer. Findet ein Angreifer die Möglichkeit einer SQL-Injection-Attacke, so kann er auf die gleiche Weise viele tausend andere Shops verseuchen.

Dieser Problematik ist sich ein großer Hoster allerdings bewusst und kann aufgrud der Menge an Shops, die er betreibt, Sicherheitsmaßnahmen treffen, die es nahezu unmöglich machen, dass ein SQL-Injection-Angriff zum Erfolg führen kann. Im unwahrscheinlichen Fall einer Verseuchung mit Malware kann sich ein großer Hoster schneller um die Beseitigung eines Problems kümmern.

Käufer bei kleineren Internet-Händlern sollten es vermeiden, ein Benutzerkonto anzulegen. In diesem Fall ist dort auch kein Passwort gespeichert, das in die Hände von Kriminellen gelangen und auf anderen Websites ausprobiert werden kann. Die sichersten Zahlungsmittel sind Vorkasse und Nachnahme. Sie setzen natürlich einen Vertrauensvorschuss an den Internethändler voraus, haben aber den großen Vorteil, dass keine Finanzdaten auf dem Server gespeichert werden, die die Cyberkriminellen abgreifen können.Cross-Site-Scripting[15] (XSS) ist eine Methode, mit der Sicherheitslücken in Webanwendungen ausgenutzt werden, die dazu führen, dass bei dynamisch generiertem Inhalt keine ausreichende Prüfung stattfindet, ob es sich dabei um ein Skript handelt.

Betroffen sind hiervon alle dynamischen Websites, unabhängig davon, ob sie mit  PHP, ASP.NET[16], Perl oder einer anderen Technologie erstellt wurden. Anders als bei einer SQL-Injection-Attacke muss die Website nicht mit einer Datenbank ausgestattet sein.

Man unterscheidet zwischen persistentem und nicht persistentem Angriff. Ein nicht persistenter Angriff kann ausgeführt werden, wenn eine Website eine Benutzereingabe wiederholt. Einfach verständlich wird das am Beispiel einer Shopping-Site. Dort sucht ein Anwender nach dem Begriff "Kaffeemaschine". Als Antwort sieht er auf der Seite unter anderem den Text "Ihre Suche nach Kaffeemaschine ergab 8 Treffer". Das eingegebene Wort "Kaffeemaschine" wird also von der Webanwendung wiederholt.

Gibt der Benutzer als Suchbegriff "<script>[bösartiges Skript]</script>" ein, dann muss die Website zumindest die spitzen Klammern ignorieren oder durch die nötigen HTML-Escape-Sequenzen < und > darstellen, andernfalls wird das bösartige Skript auf dem Rechner des Benutzers ausgeführt.

Entdeckt ein Angreifer eine Website mit einer derartigen Sicherheitslücke, so besteht die Schwierigkeit, ein Opfer davon überzeugen, nach einem entsprechenden Begriff zu suchen. Dies geschieht meist mittels Spam-Mails mit Links, die als eine Sonderform des Phishing[1] angesehen werden können.

Grundsätzlich können Angreifer auch Mails mit Links auf eigene Websites verschicken, die schädliche Skripts enthalten. Wenn jedoch die angegriffene Website einen User-Log-in ermöglicht, so kann der vom Benutzer selbst eingefügte Schadcode das Session-Cookie an den Angreifer schicken. Dieser hat nun die Möglichkeit unter dem fremden Account auf der Website zu agieren.

Begehrtes Ziel sind wie bei der SQL-Injection-Attacke die Nutzerpasswörter. Oft ist es möglich, über die Passwortänderungsfunktion an das Passwort zu kommen. Das Passwort wird zwar meist verdeckt dargestellt, befindet sich jedoch häufig im HTML-Quelltext als Input-Feld vom Typ Hidden. Die Funktion "Ansicht - Quelltext anzeigen" im Browser reicht aus, um das Passwort sehen zu können.

Wesentlich hinterhältiger sind persistente XSS-Angriffe. Den überwiegenden Anteil der angreifbaren Websites machen Diskussionsforen, Blogs und Bewertungsportale aus. Betroffen sind Websites, die es ihren Usern ermöglichen, HTML-formatierten Text einzugeben. Angreifer versehen ihre meist provozierenden oder kontroversen Beiträge mit Javascript-Code.

Es reicht aus, einen solchen Beitrag anzusehen, damit der schädliche Code auf dem eigenen Rechner ausgeführt wird. Neben dem Identitätsdiebstahl eignet sich diese Form des Angriffs insbesondere auch für die Einschleusung von Malware auf den Rechner des Betrachters.

Generell anfällig für jede Art von Cross-Site-Scripting sind Webseiten, die von relativ unerfahrenen Programmierern erstellt werden. Typischerweise sind Websites betroffen, die Internethändler von kleinen Agenturen erstellen lassen. Es existiert meist nicht genug Know-how, die Webseiten sicher vor XSS-Angriffen zu machen.

Eine Auswertung aller Angriffstypen[17] von Mitre[18] im Januar 2007 hat ergeben, dass XSS-Angriffe mittlerweile häufiger verwendet werden als die Ausnutzung von Pufferüberläufen[19]. Das ist nicht weiter verwunderlich, denn die Anbieter von Betriebssystemen und Webservern haben in den letzten Jahren viel Zeit und Geld investiert, Fehler durch Pufferüberläufe zu beheben. XSS-Angriffe werden nicht durch das Betriebssystem oder die Serversoftware ermöglicht, sondern durch Unachtsamkeit der Webentwickler.

So dürfte für Cyberkriminelle klar sein, dass es wesentlich einfacher ist, einen technischen Wettlauf gegen kleine Webagenturen mit PHP-Programmierern zu gewinnen als gegen Microsoft, Novell und Red Hat. Mitres Schätzungen zufolge sind 70 Prozent aller dynamischen Websites anfällig für XSS-Angriffe.Die meisten Hoster bieten einen Standard-FTP[20]-Zugang zu ihren Webhosting-Angeboten, um Content auf den Server zu bringen. Dabei wird das Passwort immer unverschlüsselt übertragen. Auf der Strecke zwischen dem eigenen Computer und dem Hoster können Mitarbeiter des Providers oder der Carrier das Passwort mitschneiden. Verbreiter von Malware sind gerne bereit, längere Listen mit Passwörtern gegen Bares zu kaufen.

FTP wird von den Hostern angeboten, da Windows-Benutzer zur Nutzung dieses Protokolls keine Zusatzsoftware benötigen. Der Windows-Explorer reicht aus. Die Kopieren von Webseiten vom lokalen Rechner auf den Webserver ist so einfach wie das Kopieren von Dateien von einem Verzeichnis ins andere.

Die meisten Hoster bieten sicherere Alternativen dazu an, beispielsweise SFTP[21], FTPS[22] oder WebDAV[23] mittels SSL[24]-Verschlüsselung. Somit wird ein Ausspionieren des Passwortes verhindert. SFTP und FTPS erfordern unter Windows immer die Installation eines zusätzlichen Programms, beispielsweise WinSCP[25]. WebDAV kann ab Windows XP mit einem Explorer-Interface genutzt werden und bietet ähnlichen Komfort wie FTP.

Ein Großteil der Webseiten wird allerdings nach wie vor mit FTP auf die Server gebracht. Gefährdet sind auch Websitebetreiber, die ihre Website von einer Agentur erstellen lassen. Meist haben sie keinen Einfluss darauf, wie die Agentur die Inhalte auf den Server lädt.

Von einem derartigen Passwort-Diebstahl kann jede Website betroffen sein, unabhängig davon, ob es sich nur um eine Web-Visitenkarte oder einen Shop handelt. Das gilt gleichermaßen für private und geschäftliche Websites.Die Cyberkriminellen haben kleine und mittelständische Websites längst für sich entdeckt. Derartige Angriffe bilden mittlerweile einen Schwerpunkt krimineller Aktivitäten.

Neben der Verbreitung von Malware fokussieren sich die Angriffe auf den Identitätsdiebstahl. Das Prinzip dabei ist, dass Anwender häufig die gleichen Log-in-Daten bei vielen Online-Diensten nutzen. Das gestohlene Passwort aus dem Diskussionsforum funktioniert auch beim Bezahldienst.

Hinzu kommt, dass mittlerweile eine echte Wertschöpfungskette für gestohlene Daten existiert. Identitätsdaten sind zu einer handelbaren Ware im Internet geworden. Immer wieder finden Sicherheitsunternehmen "Handelsplattformen[26]" für persönliche Daten im Internet. Ein technisch versierter Hacker, der Kreditkartennummern ausspioniert, hat noch lange nicht das Know-how, die Nummern in Bargeld zu konvertieren. Das ermöglicht ihm nun der Handel im Internet.

Kleine Webshops, mittelständische Agenturen und andere Unternehmen sind für die Abwehr der heutigen Gefahren nicht gerüstet. Sie müssen sich im harten Wettbewerb unter anderem über den Preis definieren und können sich aufwendige Prozeduren, etwa einen Codereview[27], nicht leisten.

Diese neue Angriffsform bedroht durchaus das Wesen des Internets. Das Internet definiert sich dadurch, dass jeder gleichzeitig Anbieter und Abnehmer von Informationen und Dienstleistungen sein kann. Ein kleiner Einzelhändler kann sich im Internet derselben Technologien bedienen wie ein großer Warenhauskonzern.

Die meisten Innovationen sind von kleinen Firmen ausgegangen. Werden kleine Websites jetzt von Cyberangriffen bedroht, kann das Vertrauen in diese Websites sinken. Um dem zu begegnen, ist es wichtig, dass den kleinen Unternehmen Hilfsmittel in Form von Parsern und Testing-Tools zur Verfügung gestellt werden. Gefordert ist hier vor allem die Open-Source-Community.

Dennoch müssen auch kleinste Unternehmen mehr Verständnis für Sicherheit bekommen. Die meisten Angriffsmöglichkeiten mittels XSS- und SQL-Injection-Attacken basieren auf Flüchtigkeitsfehlern von Programmierern, die man auch heute schon abstellen kann.

URLs in diesem Artikel:
[1] = http://www.zdnet.de/itmanager/toolkits/0,39030558,39146033-1,00.htm
[2] = http://www.zdnet.de/security/news/0,39029460,39190803,00.htm
[3] = http://de.wikipedia.org/wiki/Javascript
[4] = http://de.wikipedia.org/wiki/Drive-by-Download
[5] = http://de.wikipedia.org/wiki/SQL-Injection
[6] = http://de.wikipedia.org/wiki/Http
[7] = http://de.wikipedia.org/wiki/Sql
[8] = http://de.wikipedia.org/wiki/Perl
[9] = http://de.wikipedia.org/wiki/Php
[10] = http://de.wikipedia.org/wiki/Parser
[11] = http://de.wikipedia.org/wiki/Prepared_Statement
[12] = http://www.zdnet.de/security/news/0,39029460,39191861,00.htm
[13] = http://de.wikipedia.org/wiki/Betriebssystem-Shell
[14] = http://de.wikipedia.org/wiki/Paypal
[15] = http://de.wikipedia.org/wiki/XSS
[16] = http://de.wikipedia.org/wiki/ASP.NET
[17] = http://cwe.mitre.org/documents/vuln-trends/index.html
[18] = http://www.mitre.org/
[19] = http://de.wikipedia.org/wiki/Pufferüberlauf
[20] = http://de.wikipedia.org/wiki/File_Transfer_Protocol
[21] = http://de.wikipedia.org/wiki/SSH_File_Transfer_Protocol
[22] = http://de.wikipedia.org/wiki/FTPS
[23] = http://de.wikipedia.org/wiki/Webdav
[24] = http://de.wikipedia.org/wiki/Transport_Layer_Security
[25] = http://www.zdnet.de/ftp_utilities_fuer_windows_winscp_download-39002345-40671-1.htm
[26] = http://www.zdnet.de/security/news/0,39029460,39190583,00.htm
[27] = http://de.wikipedia.org/wiki/Code-Review