Mehr Sicherheit und Privatsphäre für Smartphone und Tablet

© AdobeStock /   adam121

© AdobeStock / adam121

Obwohl viele Menschen immer noch zu sorglos mit Smartphones und Computern umgehen, steigt mittlerweile das Bewusstsein für Computersicherheit und Datenschutz. Smartphones und Tablets sind nichts anderes als kleine, mobile Computer. Deshalb gelten für sie die gleichen Grundregeln wie für den PC. Da wir die Mobiltelefone ständig bei uns haben, kommen einige Risiken hinzu. Mit den folgenden Tipps lassen sich Sicherheit und Datenschutz deutlich verbessern.
[Read more…]


Erneute Sicherheitslücke bei ImageMagick sorgt für neues Gefahrenpotential

© Depositphotos /   photovibes1

© Depositphotos / photovibes1

Die so genannten Bildbearbeitungs-Bibliothek ImageMagick sind mit ein paar Funktionen ausgestattet, welche einige Teile des vergebenen Dateinamens über Shell weitergegeben bzw. ausgeführt werden. Für diese Programmierung haben Cyberkriminelle nun eine Möglichkeit entdeckt, wie sie nahezu mühelos Schadcode aus einem System einschleusen können. Von der neuen Sicherheitslücke ist auch die Bibliothek GraphicsMagic in vollem Umfang betroffen. Kurz nach dem Bekanntwerden der neuen Gefahrenquellen haben sich deren Entwickler dazu entschlossen, die Funktionen im Rahmen einer neuer Version 1.3.24 zu entfernen. Nahezu identisch verhält es sich mit ImageMagick: Die Behebung des Security-Problems erfolgt die ab sofort erhältliche Version 7.0.1-7.

Erst vor knapp einem Monat muss ImageMagick harsche Kritik einstecken und empfindlich klingende Schlagzeilen für sich verbuchen, als das Leck CVE-2016-3714 die Runde durchs Internet machte. Damals konnten Angreifer Schadcode jedweder Art auf den jeweils betroffenen Servern ausführen. Zum damaligen Zeitpunkt stieg die Anzahl der Hacker-Attacken innerhalb kürzester Zeit sprunghaft an. Diese unliebsame Situation zeigte einmal mehr, wie grundlegend wichtig es ist, die Bibliotheken möglichst rasch einer Aktualisierung zu unterziehen.

Sicherheitsexperten konnten feststellen, dass insbesondere auf Linux basierende Web-Apps ein begehrtes Ziel für die Einschleusung von Schadcode sind. Foren-Avatare oder andere Bilder, welche der Anwender selbst hochladen darf, stellen in diesem Zusammenhang ein besonders hohes Gefährdungspotential dar. Darüber hinaus nutzen eine Vielzahl unterschiedlicher Desktop-Anwendungen unter Unix/Linux ebenfalls die genannten Bibliotheken.

Sicherheitsforscher von CloudFlare sowie von Sucuri konnten bereits bei der Gefährdung vom vergangenen Monat jede Menge Exploits lokalisieren. Dort handelte es sich in erster Linie um Kommandozeilen-Befehle, sich als harmlose Bilddatei tarnten. Sobald der entsprechende Schadcode auf den Server gelangte, konnte Angreifen die vollständige Kontrolle über diesen an sich reißen.

Administratoren sind derzeit gut damit beraten, die jeweils aktuellsten ImageMagick- und GraphicsMagick-Pakete für ihre eingesetzte Linux-Distribution zu installieren. Für den Download der Bibliotheken stehen zudem die Webseiten der beiden Projekte zur Verfügung.


Magento Sicherheitslücke – tausende Shops betroffen

© Depositphotos / PirenX

© Depositphotos / PirenX

Wieder einmal wird das Shop-System Magento angegriffen. In der nahen Vergangenheit wurden bereits mehrmals Viren, Trojaner und Malware auf die Onlineshops von Magento los gelassen. Dabei haben diese dann nicht nur Inhalte des Shops verändert und alles durcheinander gebracht, sondern sie sind auch an sensible Daten der Kunden gekommen. Jetzt ist das wieder der Fall. Die Angreifer jubeln den Kunden der Shops ein sogenanntes Exploit-Kit unter und fischen dann damit auf deren Rechnern Kartendaten und Logins für Bezahldienste ab. Fast 8.000 Shops sollen aktuell davon betroffen sein.

Immer wieder Magento
Magento wurde in der Vergangenheit immer mal wieder Opfer von eigenen Sicherheitslücken. Der Grund, wieso sich die Angreifer bereits zum wiederholten Male Magento als Angriffsziel aussuchen, liegt auf der Hand: Zum Einen scheint Magento doch immer wieder für Sicherheitslücken anfällig zu sein und zum Anderen lohnen sich die Online-Shops für die Angreifer besonders, da zu erwarten ist, dass dort sensible Kundendaten, wie beispielsweise Logins für Bezahlsysteme oder Daten der Bankkarten, vorliegen. Diese können die Angreifer dann abrufen und an sich reissen. Mozilla und Google haben auf Grund des weit um sich fassenden Schadens mittlerweile die bekanntgewordene Domain gesperrt. Der Schadcode wurde bereits auf fast 8.000 Magento-Seiten verteilt. Allerdings können die Angreifer nun ihre Attacken theoretisch über andere Domains fahren. Dazu ist aber noch nichts weiter bekannt geworden. Ob Ihr Online-Shop ebenfalls auf Magento basiert, können Sie unter http://syscheck.net herausfinden. Einfach den Link zum Shop eingeben und schon wird die Information ausgegeben, um welches System es sich dabei handelt.

Der Infektionsweg ist weiterhin unbekannt
Noch beängstigender als das Problem sowieso schon ist, macht das Ganze die Tatsache, dass der genaue Infektionsweg noch immer nicht wirklich bekannt ist. Magento arbeitet derzeit an Patches, um die Sicherheit wieder zu gewährleisten. Gleichzeitig wird aber auch nach dem wirklichen Problem gesucht. Ob eine aktuelle Lücke in der Software als Einfallstor dient ist nämlich überhaupt noch nicht geklärt. Klar ist nur, dass die Angreifer das Shop-CMS infizieren. Die Shopbetreiber und vor allem auch die Besucher sollten daher in der nächsten Zeit besonders vorsichtig sein und genau beobachten. Häufig verraten sich Viren, Trojaner und Malware allgemein sehr leicht. Fällt Ihnen etwas ungewöhnliches auf, beispielsweise bei der Abfrage Ihrer Daten, sollten Sie skeptisch sein.

Wie der Schadcode entdeckt werden kann
Die Seiten der Shops mit Magento übertragen die Schadsoftware über kleine sogenannte iFrames, die zur Domain namens Guruincsite.com führen. Deshalb wird die ganze Problematik international auch guruincsite infection genannt. Die Verlinkung konnte im Klartext erkannt werden, es gibt jedoch auch eine weitere Variante, die den Link durch Nutzung von ASCII-Code statt Klartext-Zeichen verbirgt. Meist lassen sich die infizierten iFrames in der Datenbank-Tabelle core_config_data unter design/footer/absolute_footer finden. Empfohlen wird allerdings, die gesamte Datenbank abzusuchen und zu scannen, entweder nach „function LCWEHH(XHFER1){XHFER1=XHFER1“ oder der Bezeichung „guruincsite“. Google konnte nur anhand dieser Entdeckung die Verlinkungen zu den fast 8.000 bisher betroffenen Magento Shops sperren. Weichen die Angreifer jetzt aber auf einen alternativen Domain aus, muss dieser erst wieder gefunden werden. Deshalb hat es nun höchste Priorität, die wirkliche Ursache dafür zu entdecken.


Webseite gehackt – was nun (Ratgeber)

©  Depositphotos /   stevanovic

© Depositphotos / stevanovic

Der Alptraum für jeden Webmaster oder Serveradministrator – ein Hacker im System. Manchmal bemerkt man es sehr schnell durch z.B. eine abgeänderte Startseite, in der Regel erfahren viele Betreiber davon aber erst durch Abuse Meldungen von verärgerten Fremdadministratoren das etwas nicht mit rechten Dingen vor sich geht. Sehr oft wird dabei der Betrieb der Seite zunächst nicht beeinflusst, unbemerkt werden vom eigenen Server/Webspace aber im Hintergrund dutzende Spammails verschickt oder automatisierte Brute Force oder DOS Attacken gefahren.

In einem solchen Fall hat man es sogar noch relativ leicht, schlimmer wird es wenn z.B. Kundendaten gestohlen werden oder Pishingwebseite auf dem eigenen Webserver abgelegt werden die zu einer Sperre durch Google führen (Warnmeldung und SEO Verlust). Bemerkt man verdächtige Aktivitäten ist das wichtigste:
Ruhe bewahren. Nichts ist schlimmer wie eine panische Reaktion, denn meist verliert man durch Schnellschüsse die Möglichkeit den Angriff zu rekonstruieren und kann damit die Lücke nicht mehr Schließen.

Was ist zu tun wenn ein Hackerangriff bemerkt wurde?

Diese Frage ist schwer zu beantworten, hängt sie doch von unzähligen Faktoren ab. Zunächst sollte man sich einen schnellen Überblick verschaffen und gleichzeitig ein Fullbackup des aktuellen Standes schaffen. Das Backup hilft später beim Vergleich mit dem letzten nicht infizierten Backup und ist ein wichtiges Instrument den Infektions-/ oder Einbruchsweg nachvollziehen zu können (hierzu später mehr). Ist das Backup gestartet geht es zunächst darum weiteren Schaden zu minimieren und auch hier gilt es wiederum clever vorzugehen. Taucht z.B. ein unbekannter Prozess auf ist die Versuchung groß ihn mit einem „kill“ abzuschiesen, jedoch nimmt man sich damit die Chance ihn zu analysieren und er kann jederzeit wider kommen. Besser ist es ihm zunächst die Angriffsmöglichkeiten zu nehmen. Was er genau tut weiß man in der Regel schon aus den eintrudelden Abusemeldungen, fährt er z.B. eine DOS Attacke gegen einen bestimmten Server blockt man dessen Remote IP, fährt er Bruteforce Attacken auf eine Liste von fremden Webservern ist es ratsam remote Port 80 zu Blocken, bei SSH Port 22 usw. Im Falle des Spamversandes hilft es Remote alle SMTP Ports zu blocken. Diese Methode hat den Vorteil das das Angriffsscript in der Regel nicht
bemerkt das es entdeckt wurde und davon ausgeht das der Remoteserver einfach die IP des gekaperten Servers geblockt hat. Für den Fall von installierten Phising Scripts auf dem Server empfielt es sich die Dateien zu überschreiben, aber nicht zu löschen. Oft prüfen Prozesse im Hintergrund ob die Dateien  noch vorhanden sind und erstellen sie ggf. neu.

Der Angriff wurde unterbunden – was nun?

Das wichtigste nachdem die aktiven Auswirkungen unterbunden wurden ist zunächst die Schadsoftware zu finden und danach den Infektionsweg zu erkunden. Einen guten Anhaltspunkt gibt der noch laufende Prozess, so kann man mittels „strace -p“ sehr gut sehen auf z.B. welche Dateien der Prozess zugreift und diese dann suchen. Ein noch wichtigster Anhaltspunkt sind bei bei einem Webserver mit vielen Webseiten sowie unterschiedlichen Nutzern der Prozesseigentümer. Nach und nach tastet man sich nun ran. Die häufigsten Einfalltore sind dabei ungepatchte Open Source Lösungen wie WordPress, Joomla oder auch nur ein Plugin wie z.B. WYSIWYG Editoren. Besonders interessant beim heran tasten sind die Erstellungszeitpunkte der Schadsoftwaredateien, so kann man hier das access.log des Webservers zu diesem Zeitpunkt genauer prüfen. Wer hier nichts findet schaut sich die Bugtracinglisten der verwendeten Software an und versucht von dieser Seite aus zu erkunden welche Lücke genutzt werden konnte.

Was tun wenn die Lücke gefunden wurde?

Wieder einmal kann man es nicht pauschal sagen, zunächst sollte man sofern vorhanden den noch laufenden Schadprozess killen und die Schaddateien löschen. Hierbei ist Vorsicht geboten, denn es könnte Fallbackscripts geben. Wenn möglich wäre ein Deaktiveren des Webservers sowie Kontrolle der Cronjobs ratsam.

Danach heißt es aufräumen. Wenn ein nicht betroffenes Backup verhanden ist und der Datenverlust kein Problem darstellt -> Backup einspielen und danach sofort die Lücke patchen (evt. manuell die fehlenden Daten aus dem Backup mit Schadsoftware auffüllen). Ist das Rückspielen des Backups keine Option wird nun das Backup des Standes der betroffenen Version wichtig, hier empfielt es sich alle Dateien die sich verändert haben miteinander
Abzugleichen um evt. versteckte Fallbackroutinen zu erkennen und zu beseitigen. Danach sollte das System sicher sein.

Und dann? Das Aufräumen nach dem Aufräumen.

Nachdem die Auswirkungen auf dem eigenen Server beseitigt wurden heißt es die externen Faktoren prüfen. Bei einen Spamangriff sind es in erster Linie die RBL Listen die geprüft und eine Austragung im Positivfall beantragt werden sollte. Bei Phising oder Drive-By-Download Veränderungen der Webseite sind es in erster Linie die Google Webmaster Tools, aber auch Warnportale wie WOT (World of Trust) die gecheckt und wenn nötig entsprechende Austragungen beantragt werden sollten.

Der Umgang mit Chefs oder Kunden in solch einer Situation:

Der vermutlich schlimmste Teil an der Sache ist der sich in der Regel ins unermessliche steigende Druck von Chefs oder Kunden in solch einer Situation. Diese wollen es in der Regel – sofort – bereinigt haben und vergreifen sich auch schnell mal im Ton. Jedem sollte klar sein, auch auf diesem
liegt unter Umständen ein gewaltiger Druck, kosten solche Ausfälle in der Regel viel Geld mit jeder Minute die vergeht. Versuchen Sie es sachlich kurz zu
erklären, machen Sie keine kurzfristigen Versprechungen wann es wieder geht und  sichern sie ihrem Gegenüber schon vom Anfang an eine detailierte
Fehleranalyse zu… machen sie ihm aber auch klar das sie in den nächsten Stunden absolute ruhe brauchen um das Problem schnellstmöglich lösen zu können.
Geben Sie alle 30-60min eine kurze Sachstandmeldung mit, diese muss für den Chef / Kunden nicht unbedingt verständlich sein, er will in der Situation nur
issen das etwas passiert. Bei einem penetrant agierenden Gegenüber machen sie sich unerreichbar (aktivieren eines Anrufbeantworters etc.). Wichtig ist das
sie sich auf die oben genannten Vorgehensweisen konzentrieren und sie gewissenhaft ausführen. Auch wichtig: kommen sie alleine nicht weiter holen Sie sich externe Hilfe von Fachpersonen die mit dem Problem vertraut sind. Auch wenn die Behebung mal einige hundert oder sogar tausende Euro kostet, ein Ausfall der noch schlimmer Vertrauensverlust kann deutlich teurer kommen. Im  Angestelltenverhältnis ist es bei der Einreichung der Fehleranalyse auch der richtige Zeitpunkt mit Ihrem Chef über mögliche Fortbildungen im Bereich IT Sicherheit zu  sprechen… kurz nach einem solchen Ereignis ist die Erleichterung meist groß und er dafür sicherlich offener.