A Study in … Viagra

Sherlock Holmes zum Zweiten. Der Blogpost von Jürg über gehackte TYPO3-Seiten hat viel Staub aufgewirbelt worauf mehrere SOS-Rufe von betroffenen Seitenbetreibern bei uns eingetroffen sind. Das Problem war, dass einige ältere TYPO3 Betreiber plötzlich unwissentlich potenz-steigernde Pharmazeutika verkauften. Seit wir auf dieses Problem aufmerksam geworden sind, stossen wir regelmässig auf neue Opfer des „Pharmahacks“. TYPO3 ist dabei übrigens bei weitem nicht das einzige geplagte System. Perfiderweise ist der Hack auf den ersten Blick nicht sichtbar – er wird nur wirksam, wenn der Surfer via Google auf die Seite stösst. Dann wird server-seitig neuer Text in die Webseite gerendert und beim Klick auf den Link von Google aus, gelangt der Kunde nicht auf die eigentliche Seite, sondern wird auf eine (meist russische) Seite weitergeleitet. Die verkauft Viagra – oder etwas anderes blaues.
Neulich erhielten ich erneut den Auftrag, den Verkauf blauer Pillen auf der Seite eines Dritten zu unterbinden. Diesmal wurde das Problem mit „Medikamentenhack“ beschrieben.

Hier folgt ein Bericht meiner Spurensuche in der Hoffnung, dass Anderen mit den selben „Krankheitssymptomen“ geholfen werden kann.
Als erstes habe ich mich auf dem System, im TYPO3 Backend und auf dem Server etwas umgesehen. Dabei handelte es sich nicht um eine „verwahrloste“ Webseite sondern um eine recht gut ausgebaute Plattform mit einem relativ aktuellen TYPO3 Core und einem sauberen Aufbau und umfangreicher Funktionalität. Ein eher grosser Auftritt.

Gefährliche Extensions

Auf Anhieb sind mir jedoch einige potenziell (sehr) gefährliche Extensions aufgefallen, die auf einem Live-System nichts verloren haben: „t3quixplorer“ – erlaubt die Navigation auf dem Filesystem mehr oder weniger uneingeschränkt und ermöglicht das Bearbeiten von PHP-Scripts direkt über das Webinterface – der reinste Security-Alptraum. Es ist nicht auszuschliessen, dass diese Extension von einem der Angreifer installiert wurde. „devlog“ ist eine Extension welche zu Entwicklungszeiten nützlich sein kann – jedoch nicht in einem Live-System. Ein anderer Kandidat, welcher jedoch nicht installiert war, ist die „phpmyadmin“ Extension, welche oft aus Bequemlichkeit installiert wird. Auch diese Extension stellt ein beträchtliches Sicherheitsrisiko dar. Im übrigen beinhaltete das System einige „handgemachte“ Extensions – schnell zu erkennen an fehlenden Icons und der aussagekräftigen Versionsnummer 0.0.0 – Stable? Ja genau!

Backend-User

Ich habe ausserdem alle Backend-User überprüft und mit dem Kunden zusammen sichergestellt, dass keine unbekannten Nutzer registriert waren. Sollte dies der Fall sein, würde ich empfehlen, alle User neu anzulegen und neue, sichere Passwörter zu vergeben.

Spurensuche im Dateisystem

Danach habe ich mich etwas vertieft auf die Spurensuche gemacht. Aus Erfahrung weiss ich mittlerweile, wonach ich suchen muss. Eine Suche im Filesystem nach „base64_decode(“ führt meist zu verdächtigen Code-Zeilen oder Dateien:

find . -name "*.php" -print | xargs grep "eval(base64_decode("

Meist sind infizierte Dateien im Ordner typo3conf/ zu finden. Darin befinden sich die von TYPO3 auszuführenden Extensions. Der Code darin kann potenziell schädlich sein.
Auf diese Weise bin ich auf zwei verdächtige Dateien gestossen. Eine Datei war in einer nicht öffentlichen, für Kundenbedürfnisse entwickelten Extension enthalten. Die andere im ./uploads/ Ordner der bekannten Newsletter-Extension tx_directmail.

./uploads/tx_directmail/trololo.php:<?php eval(base64_decode("ZXZhbChiYXNlNjRfZGVjb2RlKCJaWFpoYkNoaV
lYTmxOalJmWkdWamIyUmxLQ0phV0Zwb1lrTm9hVmxZVG14T2FsSm1Xa2RX
YW1JeVVteExRMHBoVjBad2IxbHJUbTloVm14WlZHMTRUMkZzU20x…

In beiden Fällen war es dem Angreifer möglich, über ein ungenügend geschütztes Formular PHP-Dateien auf das System zu laden. Geschieht dies, und sind diese Dateien auch ausführbar, hat man verloren.
Bei genauerem Hinsehen habe ich in der handgestrickten Extension gleich noch mehr zerstörerische Dateien gefunden welche die unscheinbaren Namen „class.php“ und „footer.php“ trugen. Ich musste erst beim Dienstleister des Kunden nachfragen, um sicher zu stellen, dass es sich wirklich um bösartige Dateien handelte. In diesen Fällen hatten die Angreifer ganze Arbeit geleistet – auch das Erstelldatum war ein weit zurückliegendes. Oft kann man im System auch einfach nach Files suchen, die im Zeitraum des Hacks verändert wurden. Ich konnte diesen durch verdächtige Files auf etwa 76 Tage zurückliegend vermuten und bin mit dem Befehl

find . -iname "*.cache" -mtime -77 -mtime +75 -type f

auf weitere verdächtige Dateien gestossen. Da im Ordner typo3conf während dem Betrieb eigentlich keine Dateien geändert werden sollten, sind dies zumindest dort, nur eine Hand voll. Mein Tipp: in typo3conf/ext/ darf auf einem Live-System gar nichts geändert werden können. Dem Server (Apache) sollen also alle Schreibrechte auf typo3conf/ext/ entzogen werden. Auch localconf.php darf nie verändert werden – damit wird es für einen Angreifer sehr schwer, nachträglich Extensions zu installieren, ohne dass er Serverzugriff hat.

Bereits erwähnte class.php war mehrfach base64 encoded und nachdem ich diese mehrfach decodiert hatte wurde ihr Zweck offensichtlich. Sie leitet die Benutzer welche von viagra-verseuchten Google-Resultaten kommen auf die russischen Verkaufsseiten weiter:

Ja ist denn heut‘ schon Weihnachten?

Bei der Analyse von ./uploads/tx_directmail/trololo.php wurde ich leicht überrascht. Ebenfalls nach mehrmaligem encoden kam folgendes zum Vorschein:


Ein ausgewachsenes Backdoor! Inklusive Passwortschutz. Klar russischen Ursprungs. Mit diesem Tool kann man auf einem Server so ziemlich alles machen. Dateien erstellen, löschen, bearbeiten, Rechte setzen. Damit kann man die localconf.php auslesen – dort steht (meist) der MySQL User und das Passwort im Klartext. Somit kann der Angreifer auch auf die Datenbank zugreifen. Doppelt dumm, wenn der gleiche User auf mehrere Datenbanken Zugriff hat. Wenn man localconf.php nicht schreibgeschützt hat, kann er ausserdem ein neues Install-Tool Passwort erstellen. Damit kann er sich dann einen Backend-Administrator erstellen – etwas einfacher als direkt über die DB. Netterweise nennt TYPO3 bei einer missglückten Anmeldung am Install-Tool auch gleich den dazu benötigten MD5 Hash den man dann nur noch im localconf.php eintragen braucht.
Das Backdoor in Action:

Und weiter geht’s…

Nachdem ich die Suche bereits abbrechen wollte – es war mittlerweile schon spät – bin ich im fileadmin/ in den Templates der Webseite auf eine weitere mysteriöse Datei gestossen – eine PHP Datei unter den CSS Files; en.php
Diese enthielt neben den verdächtigen base64 Codes auch noch folgenden aufschlussreichen Text:

Codz by angel(4ngel)
Make in China
Web: http://www.4ngel.net

Die Chinesen waren also auch am Werk! Nach erneut mehrmaligem Encodieren und Entfernen eines Passwortschutzes wurde offensichtlich, dass die Chinesen den Russen mittlerweile – zumindest im Design – voraus sind. Ebenfalls eine mächtige Hintertüre – einmal in schön.

Fazit, Suche, Massnahmen

Abschliessend konnten wir den Grossteil des Hacks wohl innerhalb einiger Stunden finden und entfernen. Nach dem der übliche Selbstheilungsprozess von Google eingesetzt hatte sind nun die Suchresultate wieder frei von Viagra. Für die Suche nach infizierten Files benutzen wir die Dateisystemsuche nach den Begriffen eval() und base64_decode(), Datumsangaben, verdächtige PHP-Dateien an unüblichen Orten – PHP-Files im uploads Ordner oder in andern Ordnern mit normalerweise statischen Inhalten. Auch eine Hilfe für das schnelle Finden von Schadcode kann sein, wenn die TYPO3 Temp-Files im typo3conf/ Ordner nach base64_decode durchsucht werden. Diese Dateien werden von Typo3 geladen und enthalten einen Zusammenzug vieler ausgeführter Dateien. Oft sieht man dort schnell, ob, und wo ungefähr, ein System vom „Pharmahack“ befallen ist. Handgemachte Extensions die nie den Weg ins TYPO3 Repository gefunden haben sind ein erhöhtes Sicherheitsrisiko. Alle Formulare mit Upload-Funktionalität sind ein möglicher Angriffspunkt. Auch in die Datenbank sollte man einen Blick werfen. Es kann sein, dass in den Tabellen von RealURL unerwünschte Weiterleitung enthalten sind. Auch in tt_content oder in der pages Tabelle kann nach Viagra gesucht werden. Ausserdem sollte man alle Cache-Tabellen leeren.

Die befallenen Dateien und Extensions werden gesäubert oder entfernt. Nicht (mehr) benötigte Extensions sollten vom System gelöscht werden – nicht nur deaktiviert! Unnötige Backend- und Frontend-User sollten ebenfalls gelöscht und die Passwörter sicherheitshalber angepasst werden.
Alle Schreibrechte für den Server sollten auf typo3conf/ext und auf der localconf.php entfernt werden. Dies gilt selbstverständlich auch für den ganzen TYPO3-Core. Sicherheitshinweise von TYPO3 sollten ernst genommen werden:

Das Install-Tool kann auf dem Live-System entfernt werden und der Zugriff auf das Backend nur für einen bestimmten IP-Range, vielleicht über eine spezielle Sub-Domain und zusätzlich mit einem .htaccess Schutz, versehen werden. Auch HTTPS für das Backend schadet kaum.
Natürlich sollte darauf geachtet werden, dass TYPO3 und verwendete Extensions auf einem aktuellen Stand sind. TYPO3 Bug-Fix Releases sollten wenn möglich immer installiert werden da diese Security-Fixes enthalten und normalerweise problemlos zu installieren sind.

20 Gedanken zu “A Study in … Viagra

  1. Hey Noël – herzlichen Dank für den ausführlichen Post! Und ich vermute, dass Deine „Titelwahl“ einiges an Suchmaschinentraffic bringt… evt. sollten wir auch mal in den Handel einsteigen ;-)

  2. Danke Noël – cooles Investigation-Protokoll.

    Interessant ist, dass in Russland und China TYPO3 praktisch nicht verwendet wird (< 1% aller Domains), wohl dort aber das Nachfragepotential nach einschlägigen Pillen in Europa erkannt wurde. ;-)

  3. Hallo,

    grundsätzlich danke für den Beitrag, aber ich will hier als Mitglied des TYPO3 Security Teams bisschen was klarstellen.

    ad „Gefährliche Extensions“
    t3quixplorer weist aus unserer Sicht keine Sicherheitslücken auf und kann nur dann genützt werden, wenn ein Admin sich im Backend befindet. Ist das der Fall, kann ohnedies alles geändert werden – da muss man dann kein Hacker mehr sein! Bitte um etwas Vorsicht bei der Wortwahl! Dass ein Angreifer diese Extension installiert hat, ist eher sehr unwahrscheinlich.

    Das gleiche gilt für devlog. Auch bei dieser sind uns keine Sicherheitslücken bekannt. Mag sein dass das auf einem Live-System nichts verloren hat, aber auch dieser Umstand führt nicht dazu, dass eine TYPO3-Installation gehackt werden kann.

    Weiters gilt dies für phpmyadmin. Es ist hier kein direkter Einstieg in die Datenbank möglich. Auch wenn es reglemäßige Sicherheitsupdates der Extension gibt, so gelten diese für das phpmyadmin package darin. Es mag sein, dass man hier CSRF-Attacken darüber fahren kann, aber es ist uns kein Weg bekannt, hier direkt von außen bzw ohne die notwendigen Rechte (=Admin) die Datenbank zu manipulieren.

    Zu den Extensions mit Version 0.0.0. Grundsätzlich sollte man sich die Extensions als erstes anschauen, da das aussagt, dass die Extensions nicht via TER installiert wurden. Es sagt aber schon nicht mehr aus und natürlich kann eine solche Extension stable sein und natürlich kann sie sicher sein.

    ad „Backend-User“
    Die Viagra-Attacken sind aus meiner Sicht noch nie über diesen weg gefahren worden und falls doch und der User hätte Zugriff auf das Backend als Admin gehabt, ja dann wäre auch der komprimittierte User schon lange entfernt gewesen.

    ad „Spurensuche im Dateisystem“
    Ob die Files in typo3conf/ schreibbar sind oder nicht verbessert nicht unbedingt die Sicherheit des Systems. Gewisse Ordner müssen immer schreibbar sein, typo3temp reicht hier auch schon aus usw. Aber natürlich: es spart einem Zeit bei der Suche.
    Grundsätzlich sollte man sich aber hier dann die Logfiles anschauen, die geben doch am genauesten Auskunft über den Angrifspfad.
    Ob die localconf.php schreibgeschützt ist oder nicht ist egal wenn der User PHP-Files uploaden kann, da er dann einfach direkt ins Backend kommt und/oder die DB manipuliert. Ein Angreifer braucht keine Extension hiefür.

    ad „trololo.php“.
    Das ist das beste Beispiel warum man kein Backend benötigt: Via einem einzigen File hat man ohnedies Zugriff auf alles. Auch hier nochmals der Hinweis (auch wenn selbst erwähnt): Install-tool ist wirklich uninteressant sobald man eine backdoor hat ;)

    ad „Fazit, Suche, Massnahmen“
    Suchen sollte man natürlich in allen Tabellen bzw wenn hier sensible Daten gespeichert werden, so ist der Kunde (zumindest in AT) verpflichtet, auch die User zu informieren. Auch wenn bei Viagrahacks eher die Weiterleitung eiene Rolle spielt, kann man hier nicht davon ausgehen, dass die Daten nicht kopiert wurden.

    Angriffspunkte sind wie richtig beschrieben Formulare mit Upload-Funktion, aber natürlich jeder DB-Zugriff und vieles andere, sei es XSS, XSRF, Remote file inclusion usw usw ;)

    „TYPO3 Security Releases“ sind als solches gekennzeichnet und werden auch so „beworben“, man muss also definititiv nicht jedes Bugfix-Release mitmachen.

    Schlusspunkt meinerseits:
    Am wichtigsten ist auf einen guten Integrator/Entwickler zu setzen.

    Wenn man glaubt, Sicherheitslücken in Extensions des TER oder des Cores gefunden zu haben, *nicht* darüber zu bloggen sondern das Security Team unter security@typo3.org informieren!
    Danke!

  4. Hallo Noël
    Interessanter Artikel, offenbar geht es vielen TYPO3-Agenturen gleich! Wir haben dieselben Sachen auch schon erlebt, einmal sogar auf einer Uralt-Website eines Kunden von uns (ja, mit einer unsicheren Extension).

    @Georg
    Danke für Deinen Hinweis und die Rückendeckung für TYPO3. Allerdings muss ich hier anfügen (und ja, wir sind eine TYPO3-Agentur, die davon lebt), dass Noël durchaus Recht hat mit gewissen Aussagen. Auch bei uns war die Ext. t3quixplorer installiert worden und auch bei uns gab es neue BE-User. Die Angreifer haben sich über einen SQL-Inject ins BE eingeloggt, den t3quixplorer installiert und sich dann die Backdoor eingerichtet. Dummerweise kamen sie dann nicht mehr viel weiter, da auf dem Server System-Befehle unterbunden waren. Noëls Bericht ist aus unserer Sicht also durchaus realistisch und ich finde es ganz gut, wenn jemand darüber schreibt und sein Know-How veröffentlicht. Zudem war ja nie davon die Rede, dass TYPO3 ein unsicheres oder schlechtes System sei.

    Als zusätzliche Sicherheitsmassnahme von unserer Seite sehen wir sicher noch die Deaktivierung von PHP System-Funktionen, wenn diese nicht verwendet werden (passthru, exec, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec, system).

  5. @Lukas: Nun wie gesagt: für quixplorer brauchts schon Admin-Rechte, da ist der komplette Webspace inkl Datenbank ohnedies schon eingenommen. Ob man hier nun den quixplorer verwendet, die dateiliste oder den kickstarter oder was anderes ist *komplett* egal. Das Problem ist hier die SQL-Injection gewesen bzw dann im Anschluss wohl die Nicht-Verwendung von saltedpasswords.

    Ich will einfach nur relativieren, dass es eben nicht an diesen genannten Extensions liegt sondern an komplett etwas anderem. TYPO3 ist eben nicht sicherer wenn man die Extenison nicht verwendet, aber ja diese Extension gehören nicht in ein Produktivsystem, sqlI aber noch weniger

  6. Hallo miteinander, vielen Dank für das Feedback.

    @Lukas, vielen Dank für die zusätzlichen Tipps.

    @Georg, danke Georg für Deine Anmerkungen. Es ist wahr, genannte Extension weisen (momentan) keine Sicherheitslücken auf – das habe ich auch nicht behauptet – es bedeutet jedoch nicht, dass sie kein erhöhtes Risiko auf einem Produktivsystem darstellen. Eine geladen Pistole mag auch keine Mängel aufweisen – dennoch lässt man sie nicht auf dem Wohnzimmer-Tisch herumliegen.

    Es ist durchaus möglich, dass ein Angreifer sich Backen-Zugriff verschaffen kann, ohne dass er PHP Dateien hochladen konnte (SQL-Injection, Social-Hacking…) – wenn er dann diese beiden Extension vorfindet, stehen Tür und Tor offen. Im Gegensatz zu deiner Aussage bin ich der Meinung, dass, wenn jemand Admin-Zugriff hat, diese Person NICHT alles machen kann. Fileadmin erlaubt kein Upload von PHP Dateien, Extension Installation kann unterbunden werden, Editieren von Dateien über den Extension Manager auch. Wenn das sauber durchgezogen wurde, ist der Schaden den der Angreifer so anrichten kann beschränkt. Die Daten sind kompromittiert.

    Selbst wenn der Angreifer nicht über das Backend oder einen User auf das System gelangte – es ist dennoch möglich, dass er sich darauf selber einen User angelegt. Daher sollte man dies prüfen.

    Grundsätzlich ist kein System todsicher. Auch Saltedpasswords sind nicht 100% sicher. Wenn ich das Salt kenne – oder es manipulieren kann, kann ich Passwörter erstellen oder mit genügend Zeit und Rechenpower nachrechnen. Es stellt sich für einen Angreifer immer die Frage nach Aufwand und Ertrag – besonders beim Viagrahack wo es darum geht, damit Geld zu verdienen und keine ideologischen Beweggründe vorhanden sind. Irgendwann lohnt es sich einfach nicht mehr, ein System zu hacken weil der Aufwand zu gross ist. Wenn man dem Angreifer aber das Werkzeug zu Füssen legt, dann muss man sich nicht wundern, wenn er damit die Türe aufbricht.

    Hat das Security-Team mal einen Beitrag darüber geschrieben, wie man infizierte Seiten bereinigen kann? Ich denke es gibt genügend Opfer um das Problem auch von offizieller Seite zu behandeln.

  7. Hallo Noël,

    von Anfang an: Wenn jemand eine SQL-Injection findet, sind mal die kompletten Daten der DB komprimittiert. Wird kein saltedpasswords verwendet, also nur md5(), so kommt der Angreifer zu 100% ins Backend (egal welches Passwort verwendet wurde). Hier liegt die Problematik, alles andere ist nur noch simpel.

    Natürlich kann sich der Angreifer dann eine Extension installieren (sofern die Rechte stimmen), HTML-Files uploaden (auch damit kann man schon genügend anstellen), denn es geht ja nicht in 1. Linie darum viel Schaden anzurichten sondern darum dass man lange unentdeckt bleibt. Der Angreifer könnte auch via TS anderen Content ausliefern. Daher bleib ich bei der Meinung, ein Admin kann alles machen ;)

    @ Saltedpasswords: Nun das salt ist *pro* Installation unterschiedlich, man müsste also pro Installation eine rainbow-Table haben da ja das gleiche Passwort pro Installation auch anders aussieht, zahlt sihc nicht aus.

    Jedem Entwickler, Integrator, … ist der Security Guide ans Herz gelegt: http://typo3.org/documentation/document-library/extension-manuals/doc_guide_security/current/ und hier gibts auch ein Kapitel “ Detect, Analyze and Repair a Hacked Site“

  8. Womit sich die Ernsthaftigkeit und der Sinn des Artikels zeigt. Finde ich schade, wenn Artikel nur mit dem Focus geschrieben werden. Schade, schade.

  9. @Tibor und @Manuel: ich denke nicht, dass es Noël darum ging.

    Die Diskussion um sichere WCMS ist wertvoll und wichtig.

    Sie schärft den Blick (nicht nur der Techies) darauf, während der Planung, Entwicklung und dem Betrieb umfassend auf die Security einzugehen. Dabei geht es nicht nur um das Verriegeln (Hardening) des Systems, sondern auch darum, schon im Vorfeld der Umsetzung zu entscheiden, was auf ein Live-System gehört und was nicht. Beispiele dafür sind u. a. das Autorensystem selbst, Plugins und Extensions und andere Tools, die man mal eben schnell benötigt.

    Wiederkehrende Security Audits können anschliessend helfen, das laufende System auf Schwachstellen zu prüfen, bspw. unsichere Formulareingaben, URL Querystrings usw.

    Dran bleiben! :-)

  10. Pingback: Eintrag "Google Conditional Hack, Teil 2" beim Webrocker

  11. Hi, wir kämpfen auch gerade aktuell mit diesem Hack.
    „bei uns“ sind die „bösen“ Funktionen, vor allem preg_replace, durch diverse Tricks verschleiert worden, so dass die Suchmuster nach dem Klartextnamen der Funktion nichts bringen.
    Zum einen wird der Name zufällig konkatiniert und in eine Variable gepackt, die dann als Funktionsaufruf dient:
    $abc = „pre“.“g_“.“rep“.“lac“.“e“;$abc(…);
    zum anderen zb mit str_rot13:
    $abc = str_rot13(‚cert_ercynpr‘);$abc(…);
    Das Gleiche dann auch mit base64_encode, gzinflate etc.
    Extrem glitschig, das Ganze :-/

  12. Wir hatten noch lustige PHP-Dateien mit der Berechtigung 600 (rw——-). Ich habe mir jetzt ein Shell-Skript geschrieben, welches täglich das Filesystem nach gewissen verdächtigen Mustern absucht. Das eigentliche Loch zu finden ist bei mehreren hundert Domains schwieriger :-).

  13. Warum verwendet ihr nicht SVN?
    also wir haben aktuell auch einen Angriff, aber haben alles unter svn, so dass ein „svn st“ direkt zeigt wo der Bösewicht sitzt….

  14. @Thomas das ist sicher ein sehr guter Tipp – auch mit GIT geht das super. Bei alten Installationen ist sowas aber häufig noch nicht vorhanden – zumal wir es nicht in allen Fällen mit Seiten zu tun hatten, die Namics auch umgesetzt hat.

  15. Pingback: First day | noelboss

  16. Pingback: Pharmacy Spam | Kathrin Braungardts Blog

  17. @Georg: Ich weiß, dieser Post ist schon älter. Ich muss allerings @Lukas Recht geben:
    Wir verwenden diese Erweiterung t3quixplorer nirgendwo. Im Gegenteil, sie war uns bis vor etwa einem Jahr völlig unbekannt. Plötzlich hatten wir in zwei TYPO3 Installationen den Viagra-Hack und auch die EXT t3quixplorer. Diese wurde definitiv vom Angreifer installiert. Wie er in die Lage kam ist uns bislang nicht klar.
    Heute wurde eine unserer TYPO3 Installation angegriffen. Was das Ziel war, ist noch unbekannt. Es wurden zumindest gezielt Admin-Usernamen der Installation ausprobiert; würde gerne wissen, wo man die auslesen oder abgreifen kann. Nichtsdestotrotz wurde auch hier der t3quixplorer installiert.
    Es mag sein, dass die EXT nicht per se unsicher ist, sie wird jedoch definitiv von Hackern verwendet.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*

*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>