Foodblog – Schadcode?

Die Lücke war nicht das Backend. Dazu habe ich keine Fehlermeldungen erhalten. Die Lücke ist entweder das Update des Themes. Oder das Update eines Plugins. Difool hat da schon zwei angesprochen, JetPack und der Videoplayer. Beide mal nicht mehr updaten, beim Videoplayer könnte ich auch auf ein anderes Plugin umsteigen.
 
Difool schrieb:
Such mal in deinem root nach: suurl.php
Code: 
https://onclickgenius.com/script/suurl.php

In einem „script“-Ordner.
Zum Vergrößern anklicken....
Nicht vorhanden. Da ich der Datensuche auf dem Webspace nicht traue, habe ich den Webspace auf meinen Rechner geladen und dort auch gesucht. Auch ohne Erfolg. Auch die einzelne Datei suurl.php wird nicht gefunden.
 
tocotronaut schrieb:
Wenn du jetzt ein backup einspielst kann es natürlich sein, das die ausgenutzte Lücke noch offen ist...
Zum Vergrößern anklicken....
Korrekt.

@thobie
Soweit habe ich gesehen, werden dir da im <head></head> diverse Scripte reingesetzt.

Kontrolliere erstmal die index.php und header.php Dateien deines Themes – ob da irgendwelche Scripte drin sind:
- im Theme
- im Child-Theme.

Meist sind das Scripte mit base64-kodierungen. Base64 sieht dann so aus:
Javascript: 
TGllYmVyIExlc2VyLCBsaWViZSBMZXNlcmluIQ0KDQpJY2ggaG9mZmUsIGRh3yBkaWVzZSBF
cmzkdXRlcnVuZ2VuIHZlcnN05G5kbGljaCBzaW5kIHVuZCBkYXMgSmF2YXNjcmlwdA0KZmVo
bGVybG9zIGZ1bmt0aW9uaWVydCB1bmQgaGlsZnJlaWNoIGlzdC4gTG9iLCBLb21tZW50YXJl
IHVuZCBGZWhsZXJtZWxkdW5nZW4NCnNlbmRlbiBTaWUgYml0dGUgcGVyIGVNYWlsIGFuOiBh
cm5kdC5icnVlbm5lckB0LW9ubGluZS5kZQ0KDQpCZXN0ZSBHcvzfZSwNCklocg0KQXJuZHQg
QnL8bm5lcg==

Checker: https://gc.de/gc/base64/

Hattest du dein Child-Theme selbst angelegt oder haste das „irgendwo“ runtergeladen?
Manchmal sind diese Downloads halt auch mit einem „Schläfer“, einer Art Backdoor kompromittiert.

Dann ersetzt du von einem frischen Download von WP die grün markierten Dateien und Ordner (Anhang-Bild) auf deiner Installation:
https://de.wordpress.org/latest-de_DE.zip

Die Core Dateien von Wordpress kannst du gefahrlos einfach „drüberkopieren“.
Das ist quasi ein „manuelles Update“.

– deine wp-config.php und Ordner „wp-content“ nicht ersetzen ! –
( aber die config.php ist in dem zip auch nicht drin. )

wordpress-6.5-de_DE.png


Lösche dieses Player Plugin – auch deaktivierte Plugins sind ein Sicherheitsfaktor.
Videofiles spielt WP auch so ab.
 
Difool schrieb:
Korrekt.

@thobie
Soweit habe ich gesehen, werden dir da im <head></head> diverse Scripte reingesetzt.

Kontrolliere erstmal die index.php und header.php Dateien deines Themes – ob da irgendwelche Scripte drin sind:
- im Theme
- im Child-Theme.

Meist sind das Scripte mit base64-kodierungen. Base64 sieht dann so aus:
Javascript: 
TGllYmVyIExlc2VyLCBsaWViZSBMZXNlcmluIQ0KDQpJY2ggaG9mZmUsIGRh3yBkaWVzZSBF
cmzkdXRlcnVuZ2VuIHZlcnN05G5kbGljaCBzaW5kIHVuZCBkYXMgSmF2YXNjcmlwdA0KZmVo
bGVybG9zIGZ1bmt0aW9uaWVydCB1bmQgaGlsZnJlaWNoIGlzdC4gTG9iLCBLb21tZW50YXJl
IHVuZCBGZWhsZXJtZWxkdW5nZW4NCnNlbmRlbiBTaWUgYml0dGUgcGVyIGVNYWlsIGFuOiBh
cm5kdC5icnVlbm5lckB0LW9ubGluZS5kZQ0KDQpCZXN0ZSBHcvzfZSwNCklocg0KQXJuZHQg
QnL8bm5lcg==

Checker: https://gc.de/gc/base64/

Hattest du dein Child-Theme selbst angelegt oder haste das „irgendwo“ runtergeladen?
Manchmal sind diese Downloads halt auch mit einem „Schläfer“, einer Art Backdoor kompromittiert.

Dann ersetzt du von einem frischen Download von WP die grün markierten Dateien und Ordner (Anhang-Bild) auf deiner Installation:
https://de.wordpress.org/latest-de_DE.zip

Die Core Dateien von Wordpress kannst du gefahrlos einfach „drüberkopieren“.
Das ist quasi ein „manuelles Update“.

– deine wp-config.php und Ordner „wp-content“ nicht ersetzen ! –
( aber die config.php ist in dem zip auch nicht drin. )

Anhang anzeigen 433451

Lösche dieses Player Plugin – auch deaktivierte Plugins sind ein Sicherheitsfaktor.
Videofiles spielt WP auch so ab.
Zum Vergrößern anklicken....
Child-Theme mit Orbisius Plugin erstellt.

Videoplayer gelöscht.

Die Dateien ersetze ich jetzt und dann sehen wir weiter …
 
Jupp, und dann schaust du in die htaccess, ob da irgendwas drin ist, was dir die urls im Main-Menu „umbiegt“ –
das kann aber auch in der header.php oder nav.php sein.
Evtl. in der functions.php.

Suche mal danach:
Javascript: 
<!-- Quantcast Choice. Consent Manager Tag v2.0 (for TCF 2.0) -->
<script type="text/javascript" async=true>
(function() {
  var host = 'www.themoneytizer.com';
  var element = document.createElement('script');
  var firstScript = document.getElementsByTagName('script')[0];
  var url = 'https://cmp.quantcast.com'
    .concat('/choice/', '6Fv0cGNfc_bw8', '/', host, '/choice.js');
  var uspTries = 0;
  var uspTriesLimit = 3;
  element.async = true;
  element.type = 'text/javascript';
  element.src = url;

  firstScript.parentNode.insertBefore(element, firstScript);

  function makeStub() {
    var TCF_LOCATOR_NAME = '__tcfapiLocator';
    var queue = [];
    var win = window;
    var cmpFrame;

    function addFrame() {
      var doc = win.document;
      var otherCMP = !!(win.frames[TCF_LOCATOR_NAME]);

      if (!otherCMP) {
        if (doc.body) {
          var iframe = doc.createElement('iframe');

          iframe.style.cssText = 'display:none';
          iframe.name = TCF_LOCATOR_NAME;
          doc.body.appendChild(iframe);
        } else {
          setTimeout(addFrame, 5);
        }
      }
      return !otherCMP;
    }

    function tcfAPIHandler() {
      var gdprApplies;
      var args = arguments;

      if (!args.length) {
        return queue;
      } else if (args[0] === 'setGdprApplies') {
        if (
          args.length > 3 &&
          args[2] === 2 &&
          typeof args[3] === 'boolean'
        ) {
          gdprApplies = args[3];
          if (typeof args[2] === 'function') {
            args[2]('set', true);
          }
        }
      } else if (args[0] === 'ping') {
        var retr = {
          gdprApplies: gdprApplies,
          cmpLoaded: false,
          cmpStatus: 'stub'
        };

        if (typeof args[2] === 'function') {
          args[2](retr);
        }
      } else {
        if(args[0] === 'init' && typeof args[3] === 'object') {
          args[3] = { ...args[3], tag_version: 'V2' };
        }
        queue.push(args);
      }
    }

    function postMessageEventHandler(event) {
      var msgIsString = typeof event.data === 'string';
      var json = {};

      try {
        if (msgIsString) {
          json = JSON.parse(event.data);
        } else {
          json = event.data;
        }
      } catch (ignore) {}

      var payload = json.__tcfapiCall;

      if (payload) {
        window.__tcfapi(
          payload.command,
          payload.version,
          function(retValue, success) {
            var returnMsg = {
              __tcfapiReturn: {
                returnValue: retValue,
                success: success,
                callId: payload.callId
              }
            };
            if (msgIsString) {
              returnMsg = JSON.stringify(returnMsg);
            }
            if (event && event.source && event.source.postMessage) {
              event.source.postMessage(returnMsg, '*');
            }
          },
          payload.parameter
        );
      }
    }

    while (win) {
      try {
        if (win.frames[TCF_LOCATOR_NAME]) {
          cmpFrame = win;
          break;
        }
      } catch (ignore) {}

      if (win === window.top) {
        break;
      }
      win = win.parent;
    }
    if (!cmpFrame) {
      addFrame();
      win.__tcfapi = tcfAPIHandler;
      win.addEventListener('message', postMessageEventHandler, false);
    }
  };

  makeStub();

  var uspStubFunction = function() {
    var arg = arguments;
    if (typeof window.__uspapi !== uspStubFunction) {
      setTimeout(function() {
        if (typeof window.__uspapi !== 'undefined') {
          window.__uspapi.apply(window.__uspapi, arg);
        }
      }, 500);
    }
  };

  var checkIfUspIsReady = function() {
    uspTries++;
    if (window.__uspapi === uspStubFunction && uspTries < uspTriesLimit) {
      console.warn('USP is not accessible');
    } else {
      clearInterval(uspInterval);
    }
  };

  if (typeof window.__uspapi === 'undefined') {
    window.__uspapi = uspStubFunction;
    var uspInterval = setInterval(checkIfUspIsReady, 6000);
  }
})();
</script>
<!-- End Quantcast Choice. Consent Manager Tag v2.0 (for TCF 2.0) -->

Und falls du da einen Account und das Snippet reingesetzt haben solltest,
dann wäre es auch möglich, dass die Kanäle mit Schadcode beliefert werden.
 
Killerkaninchen schrieb:
Hätte @thobie nicht verraten, um welche Website es sich handelt, wäre man mal wieder mit Gebrüll auf ihn los nach dem Motto "lass dir doch nicht alle Informationen aus der Nase ziehen".

Würde ich ein Forum missbrauchen wollen, um auf meine private Homepage aufmerksam zu machen, dann würde ich das doch nicht tun, indem ich auf einen Schadcode ebenda hinweise!

Wie man's macht, macht man's falsch …
Zum Vergrößern anklicken....
Zumindest sollte man den Link hier nicht klickbar hinterlegen, bis klar ist, was als Problem vorliegt.

thobie schrieb:
1. Die Thematik Grafik- und Webdesign ist breit gestreut. Da kann man nicht alles wissen.
Zum Vergrößern anklicken....
Das ist schon richtig, aber dann solltest Du vielleicht Partnerschaften bilden, um deine offensichtlichen Schwächen zumindest in den kritischen Bereichen auszugleichen.

edit: Danke @Difool für das Anpassen des Links
 
Zuletzt bearbeitet:
Difool schrieb:
Jupp, und dann schaust du in die htaccess, ob da irgendwas drin ist, was dir die urls im Main-Menu „umbiegt“ –
das kann aber auch in der header.php oder nav.php sein.
Evtl. in der functions.php.

Suche mal danach:
Javascript: 
(…)

Und falls du da einen Account und das Snippet reingesetzt haben solltest,
dann wäre es auch möglich, dass die Kanäle mit Schadcode beliefert werden.
Zum Vergrößern anklicken....
Die .htaccess enthält keinen solchen Code.

Die header.php des Sydney-Child-Themes auch nicht.

Eine nav.php finde ich nicht.

Die functions.php enthält auch keinen solchen Code.

Ich habe den Ordner meines Webspaces auf "quantcast" durchsucht, aber nichts gefunden.
 
Zuletzt bearbeitet:
Das Ersetzen der grün markierten Ordner und Dateien gegen dieselben aus einem aktuellen WP-Installationsordner hat leider keinen Erfolg gezeigt.
 
thobie schrieb:
Das Ersetzen der grün markierten Ordner und Dateien gegen dieselben aus einem aktuellen WP-Installationsordner hat leider keinen Erfolg gezeigt.
Zum Vergrößern anklicken....
Dann ist es in einem Plugin, im Theme und/oder Child-Theme oder halt in der Datenbank.

Zumindest hatte ich festgestellt, dass es u.a. ein Script gibt, welches mit Zeitintervallen auf pageviews diese Urls-Ersetzungen macht.
Mit Wordfence kannst du auch scannen lassen.

Das Fiese ist ja, dass es auch durch ein vermeintliches .png zum Beispiel per Upload durch einen Slider reingebracht worden sein kann.
Und dieses .png ist halt keins, sondern ein ausführendes Script, welches Dateien anlegen kann o.ä.

Sonst suche mal in der Datenbank:
https://fatcatservers.com/durchsuchen-einer-datenbank-mit-phpmyadmin/
 
Ich habe mit Wordfence gescannt. Es gibt nur die Fehlermeldungen:
Publicly accessible config, backup, or log file found: .user.ini. Oder debug.log. Beide Dateien sind aber seit Jahren nicht mehr geändert worden.
Ansonsten noch der Hinweis auf diverse Plugins, die aus wordpress.org herausgenommen wurden.

Ich hatte schon einmal in der Datenbank gesucht.
Suche nach aliexpress: 0 Treffer
Suche nach temu: 5 Treffer.
1x wp_options, 2x wp_wfFileChanges, 2x wp_wfKnownFileList
Suche nach quantcast: 2 Treffer
1x wp_feed_subscribers, 1x wp_options

Ich hänge die Datenbankeinträge einmal an.

Die Einträge der Suche nach temu verweisen alle auf das Plugin BackWPup, das ich aber nicht nutze. Ich habe es gelöscht. Ohne Erfolg.
 

Anhänge

  • Datenbanksuche_nach_quantcast.jpg
    Datenbanksuche_nach_quantcast.jpg
    36,8 KB · Aufrufe: 40
  • Datenbanksuche_nach_temu.jpg
    Datenbanksuche_nach_temu.jpg
    52,1 KB · Aufrufe: 40
Der Schadcode steckt somit in einem Plugin, (Child-)Theme oder in der Datenbank.

Ich habe den Schadcode erst nach einem Update des Themes Sydney festgestellt.

Würde das Wechseln auf das Parenttheme helfen? Oder auf ein anderes Theme? Oder sogar das Löschen von Sydney und später Neuinstallation des Themes?
 
1. Diverse Plugins, die installiert sind, aber nicht aktiv, gelöscht. Keine Änderung.

2. Theme alternativ auf das Parenttheme Sydney und auch Magazin Basic oder Twentytwentyfour geändert. Keine Änderung.

3. In meinem Kundenkonto bei meinem Hoster eine neue Datenbank angelegt.
Alte Datenbank vom 23.6. in diese Datenbank erfolgreich importiert.
Wp-config.php mit den neuen Datenbankzugangsdaten angepasst.
Mit der neuen Datenbank allein keine Änderung.
Backup des Webspaces des Blogs vom ebenfalls 23.6. wiederhergestellt.
Die einzige Änderung, die sich ergeben hat, ist, dass die Überschrift „Archive“ verschwunden ist, die eigentlich nur bei einer Archivseite erscheint, nicht bei der Startseite mit den aktuellen Beiträgen.
Die URL-Weiterleitungen beim Klicken auf Temu und Aliexpress sind weiterhin vorhanden.

Die Datenbank enthält das Wort „temu“ jetzt nicht 5x, sondern nur 2x, das Wort „quantcast“ wie bisher 2x und das Wort „aliexpress“ 0x.

Was mich ein wenig irritiert, ist das folgende:
Ich habe das Backup der Datenbank vom 23.6. wiederhergestellt. Ebenso den Webspace des Blogs vom 23.6. Das Blog mit diesen beiden Inhalten enthält aber dennoch das Rezept vom 25.6., also eigentlich 2 Tage danach. Eventuell scheint da mit der Bezeichnung der Backups beim Hoster etwas nicht zu passen.

Aber jetzt ist die Frage: Was mache ich, um den Schadcode zu entfernen? Weiter zurückgehen mit den Backups? Eines wählen, das eine Woche zurückliegt?
 
Das hast du aktuell noch im <head> drin:
HTML: 
<script async="" type="text/javascript" src="https://cmp.inmobi.com/tcfv2/53/cmp2.js?referer=www.themoneytizer.com"></script>
<script async="" type="text/javascript" src="https://cmp.quantcast.com/choice/6Fv0cGNfc_bw8/www.themoneytizer.com/choice.js"></script>
^ Die hast du ja wohl nicht da rein gesetzt, oder?
Diese Frage hattest du bisher nicht beantwortet.

.concat('/choice/', '6Fv0cGNfc_bw8', '/', host, '/choice.js');
Wenn man nach dieser ID „6Fv0cGNfc_bw8“ googlet, findet man übrigens eine Menge „food-blogs“.
Könnte auch sein, dass irgendein „recipes“-Plugin betroffen sein könnte.

Dieses bereits genannte SpiderVPlayer-Plugin hast du entfernt?
Darüber kann man SQL-Injection betreiben – bedeutet, das es möglich ist, über dieses Plugin Code in der Datenbank zu platzieren.

Falls du irgendwo eine „getarnte Backdoor“ liegen hast und die nicht erkennst, dann ist das eh so eine Sache mit den Backups einspielen.
Eine „backdoor-shell“ für Wordpress sieht z.B. einfach so aus und könnte irgendwo bei dir abgelegt worden sein:
https://github.com/backdoorhub/shell-backdoor-list/blob/master/shell/php/wordpress.php
( Und die backdoor muss dann nicht unbedingt „wordpress.php“ heissen, sondern eher „unauffällig“, wie bsw. „wp-tags.php“ oder so. )

Daher musst du quasi überall mal reingucken, ob da irgendwelche Dateien sind, die da nicht hingehören.
Sonst wird einfach erneut eingeschleust, wenn beseitigt.

Als Beispiel:
Einmal hatte ein Angreifer eine header.php editiert, indem er auf den ersten Blick alles so gelassen hat, wie es vorher war –
allerdings hatte er an Ende des normalen Codes ca. 1000 Absätze eingefügt und dann erst seinen Code.
Und da der reguläre Inhalt der Datei recht wenig und kurz war, sah alles „wie immer aus“.

PS:
Es ist übrigens immer auch zu empfehlen im Update-Manager von Wordpress die Meldungen und Hinweise der Plugin Autoren zu lesen.
Hatte gerade heute, dass eine Site nur noch „error mit white screen“ gab, weil der Plugin-Ersteller was „verdaddelt hatte“ –
was man dann per Aktualisierung reinlud und sich dadurch die Website abschoß.
Logs lesen und vorne anfangen bis nach unten durcharbeiten, bis der Fehler gefunden ist.
Im Supportforum las ich dann dessen „sorry …“-Hinweis. :hehehe:

Auch ist es so möglich, dass ein Server eines Plugins infiltriert worden sein kann und man sich dann kompromittierte Updates zieht.
… usw.
 
Zuletzt bearbeitet:
Difool schrieb:
Das hast du aktuell noch im <head> drin:
HTML: 
<script async="" type="text/javascript" src="https://cmp.inmobi.com/tcfv2/53/cmp2.js?referer=www.themoneytizer.com"></script>
<script async="" type="text/javascript" src="https://cmp.quantcast.com/choice/6Fv0cGNfc_bw8/www.themoneytizer.com/choice.js"></script>
^ Die hast du ja wohl nicht da rein gesetzt, oder?
Diese Frage hattest du bisher nicht beantwortet.
Zum Vergrößern anklicken....
Nein, das habe ich nicht dort hinein gesetzt. In der header.php des Themes ist dieser Code auch nicht enthalten. Wo steckt der, wie kommt der da hinein und wie bekomme ich ihn weg?
Difool schrieb:
.concat('/choice/', '6Fv0cGNfc_bw8', '/', host, '/choice.js');
Wenn man nach dieser ID „6Fv0cGNfc_bw8“ googlet, findet man übrigens eine Menge „food-blogs“.
Könnte auch sein, dass irgendein „recipes“-Plugin betroffen sein könnte.

Dieses bereits genannte SpiderVPlayer-Plugin hast du entfernt?
Darüber kann man SQL-Injection betreiben – bedeutet, das es möglich ist, über dieses Plugin Code in der Datenbank zu platzieren.
Zum Vergrößern anklicken....
Ja. Dieses Plugin habe ich gelöscht.
Difool schrieb:
Falls du irgendwo eine „getarnte Backdoor“ liegen hast und die nicht erkennst, dann ist das eh so eine Sache mit den Backups einspielen.
Eine „backdoor-shell“ für Wordpress sieht z.B. einfach so aus und könnte irgendwo bei dir abgelegt worden sein:
https://github.com/backdoorhub/shell-backdoor-list/blob/master/shell/php/wordpress.php
( Und die backdoor muss dann nicht unbedingt „wordpress.php“ heissen, sondern eher „unauffällig“, wie bsw. „wp-tags.php“ oder so. )

Daher musst du quasi überall mal reingucken, ob da irgendwelche Dateien sind, die da nicht hingehören.
Sonst wird einfach erneut eingeschleust, wenn beseitigt.

Als Beispiel:
Einmal hatte ein Angreifer eine header.php editiert, indem er auf den ersten Blick alles so gelassen hat, wie es vorher war –
allerdings hatte er an Ende des normalen Codes ca. 1000 Absätze eingefügt und dann erst seinen Code.
Und da der reguläre Inhalt der Datei recht wenig und kurz war, sah alles „wie immer aus“.

PS:
Es ist übrigens immer auch zu empfehlen im Update-Manager von Wordpress die Meldungen und Hinweise der Plugin Autoren zu lesen.
Hatte gerade heute, dass eine Site nur noch „error mit white screen“ gab, weil der Plugin-Ersteller was „verdaddelt hatte“ –
was man dann per Aktualisierung reinlud und sich dadurch die Website abschoß.
Logs lesen und vorne anfangen bis nach unten durcharbeiten, bis der Fehler gefunden ist.
Im Supportforum las ich dann dessen „sorry …“-Hinweis. :hehehe:

Auch ist es so möglich, dass ein Server eines Plugins infiltriert worden sein kann und man sich dann kompromittierte Updates zieht.
… usw.
Zum Vergrößern anklicken....
 
Wenn ich mal ganz vorsichtig hoffe, könnte es sein, dass ich das Problem behoben habe.

Ich habe die Dateien des Webspace des Blogs, die ich komplett vom Server des Hosters herunterkopiert habe, nach dem in den von Dir genannten Skripten genannten Begriff "cmp" durchsuchen lassen.

Und als Ergebnis bekomme ich einige Skripte genannt, siehe Screenshot.

Drei Daten gehören zu JetPack, drei zu TheMoneytizer, mit dem ich auch mein Foodblog zum Teil monetarisiere.

Nach einzelnem Deaktivieren und Aktivieren steht der Übeltäter fest: TheMonetizer. Ist das Plugin deaktiviert, ist die URL-Weiterleitung nicht mehr vorhanden.

Da hat jemand deren Plugin kompromittiert.

Ich verfolge das jetzt die kommenden Tage und werde dann überlege, ob und wie ich TheMoneytizer kontaktiere.
 

Anhänge

  • Skripte.png
    Skripte.png
    150,8 KB · Aufrufe: 48
Generell finde ich „moneytiser“ doch recht fragwürdig.
Mag sein, dass dir „die Inder“ bzw. inmobi.com da einfach Mist ausgelifert haben; dafür sind die u.a. bekannt.

the_moneytiser hat ja seine eigene ads.txt, die sie mit einem Script automatisch aktualisieren können.
https://www.nudelheissundhos.de/wp-content/plugins/the-moneytizer/core/inc/template_ads_tm.txt
Und wenn du deine ads.txt anguckst, bzw. mal nach inmobi dort suchst, findet die sich da:
https://www.nudelheissundhos.de/ads.txt
Nimm' die da raus: inmobi.com

Ruf diese beiden Links von dir mal auf ^

Und wie du bemerkt haben könntest, können Plugins „von extern erreichbar“ sein, wenn man weiß wie und wo.
Wenn so z.B. ein kostenpflichtiges Plugin irgendwo „von dubioser Quelle“ runtergeladen wird, weil „umsonst“,
dann hat man i.d.R. zu 90% irgendeine Backdoor-Shell oder ähnliches mit drin.
Selbes bei Templates / Themes usw.

„moneytiser“ ist übrigens auch bei den Ad- und Scriptblockern generell auf der Liste, der zu blockenden Sites.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Ähnliche Themen

thobie
Datenbank meines Foodblogs hat maximale Größe erreicht
2 3 4
Antworten
62
Aufrufe
3.265
Difool
Difool
Zurück
Oben Unten