Oskar K.: Sicherheit bei freien Scripten?

Tach zusammen.
Bin mal wieder entrüstet, was mein kleiner Server gerade bekommen hat...
Ok. Nimbda macht meinem Indianer nix aus. Aber in der access.log sind so 100 Zeilen wo versucht wird, alle möglichen Programme aufzurufen.
Ein kleiner Auszug:

GET /cgi-bin/get32.exe HTTP/1.0" 404 283
GET /cgi-bin/auktion.cgi?menue=../../../../../../../../../etc/passwd HTTP/1.0" 404 285
GET ///index.php?chemin=..%2F..%2F..%2F..%2F..%2F..%2Fetc HTTP/1.0" 404 277
GET /cgi-bin/index.php?chemin=..%2F..%2F..%2F..%2F..%2F..%2Fetc HTTP/1.0" 404 283
GET ///edit_image.php?dn=1&userfile=/etc/passwd&userfile_name=%20;ls;%20 HTTP/1.0" 404 282
GET /cgi-bin/eshop.pl?seite=;cat%20/etc/passwd| HTTP/1.0" 404 282

Auch hier: nichts gefunden=nichts passiert.

Es gibt im Internet so viele gute Programme frei verfügbar. (Ich setze als Forum phpBB ein). Ich kann doch nicht jede einzelne Programmzeile auf ihre Sicherheit oder Schlupflöcher überprüfen?

Wie macht Ihr das? Vertrauen und hoffen, oder alles selber schreiben und 80% der Arbeit auf die Sicherheit der Programme verwenden?

Grüssle ok

  1. use Mosche;

    Es gibt im Internet so viele gute Programme frei verfügbar. (Ich setze als Forum phpBB ein). Ich kann doch nicht jede einzelne Programmzeile auf ihre Sicherheit oder Schlupflöcher überprüfen?

    Wie macht Ihr das? Vertrauen und hoffen, oder alles selber schreiben und 80% der Arbeit auf die Sicherheit der Programme verwenden?

    http://security.xwolf.de sind (bzw. sollen) alle Sicherheitslücken bei freien Scripten aufgeführt werden.

    Tschoe qw(Matti);

    1. use Mosche;

      http://security.xwolf.de sind (bzw. sollen) alle Sicherheitslücken bei freien Scripten aufgeführt werden.

      Tschoe qw(Matti);

      Hab´s mir angesehen. Da steht ja gleich alles drin, wie ich die Software hacken kann. Find ich nicht so toll. Ich glaube, dass die Hackversuche von solchen Typen kommen, die diese Listen benutzen. Klar anzeigen muss man sie. Aber gleich aufzeigen wie das hacken geht?

      Grüssle ok

      1. Moin!

        Hab´s mir angesehen. Da steht ja gleich alles drin, wie ich die Software hacken kann. Find ich nicht so toll. Ich glaube, dass die Hackversuche von solchen Typen kommen, die diese Listen benutzen. Klar anzeigen muss man sie. Aber gleich aufzeigen wie das hacken geht?

        Nur wenn _DU_ weißt, wie Sicherheitslücken entstehen, kannst du sie stopfen.

        Zwar setzt sich mehr und mehr die Ansicht durch, beim Entdecken einer Sicherheitslücke zuerst mal nur eine Warnung an die Öffentlichkeit zu setzen und den Hersteller mit den Details zu informieren, aber irgendwann wird die Lücke sicher komplett veröffentlicht - für alle die, die es bislang immer noch nicht geschafft haben, ein Update einzuspielen, sicherlich nicht unbedingt super, aber im Prinzip die einzige Möglichkeit, Bugfixes zu erzwingen.

        Sicherheit ist aufwendig und unbequem. Du kannst entweder darauf pfeifen und Probleme ignorieren (und mußt dann mit den Konsequenzen leben), oder du bemühst dich, mit einem bestimmten Aufwand deine Anwendungen sicher zu machen und zu erhalten. Der beste Beweis, daß Sicherheit nicht egal ist, lieferte gerade GMX: Die schicken künftig alle zwei Monate die Aufforderung, sein Paßwort zu ändern, und lassen auch nur noch relativ sichere Paßworte zu, in denen verschiede Buchstaben, Zahlen und Sonderzeichen vorkommen müssen.

        - Sven Rautenberg

        1. Tach!

          Nur wenn _DU_ weißt, wie Sicherheitslücken entstehen, kannst du sie stopfen.

          Zwar setzt sich mehr und mehr die Ansicht durch, beim Entdecken einer Sicherheitslücke zuerst mal nur eine Warnung an die Öffentlichkeit zu setzen und den Hersteller mit den Details zu informieren, aber irgendwann wird die Lücke sicher komplett veröffentlicht - für alle die, die es bislang immer noch nicht geschafft haben, ein Update einzuspielen, sicherlich nicht unbedingt super, aber im Prinzip die einzige Möglichkeit, Bugfixes zu erzwingen.

          Sicherheit ist aufwendig und unbequem. Du kannst entweder darauf pfeifen und Probleme ignorieren (und mußt dann mit den Konsequenzen leben), oder du bemühst dich, mit einem bestimmten Aufwand deine Anwendungen sicher zu machen und zu erhalten. Der beste Beweis, daß Sicherheit nicht egal ist, lieferte gerade GMX: Die schicken künftig alle zwei Monate die Aufforderung, sein Paßwort zu ändern, und lassen auch nur noch relativ sichere Paßworte zu, in denen verschiede Buchstaben, Zahlen und Sonderzeichen vorkommen müssen.

          • Sven Rautenberg

          Stimmt. Kleines Beispiel: Ich hab n kleinen SMS-Pager fürs Intranet in PHP geschrieben. Die Auswahl der freigegebenen Handy-Nummern per PullDown realisiert. Klappt ja prima. Ohh Gott!! NEIN. Quelltext lokal speichern, <option> Einträge ändern, und schon kann jeder machen was er will. Jetzt werden nur noch Index-Einträge an den Server übertragen.
          Ob einer meiner Jungs (150) draufgekommen wäre?

          grusseliges Grüssle ok

          1. Moin!

            Stimmt. Kleines Beispiel: Ich hab n kleinen SMS-Pager fürs Intranet in PHP geschrieben. Die Auswahl der freigegebenen Handy-Nummern per PullDown realisiert. Klappt ja prima. Ohh Gott!! NEIN. Quelltext lokal speichern, <option> Einträge ändern, und schon kann jeder machen was er will. Jetzt werden nur noch Index-Einträge an den Server übertragen.
            Ob einer meiner Jungs (150) draufgekommen wäre?

            Stimmt, sowas hatte ich auch mal entdeckt (und war zum Glück nicht verantwortlich für die Erstellung, habs dem Zuständigen dann aber gemeldet - man ist ja kein Unmensch):

            Im Intranet konnte jeder Mitarbeiter seine persönlichen Daten und sein Paßwort ändern. Die Änderungsseite erhielt man durch Angabe seiner Login-Daten auf einer vorgeschalteten Seite.

            Und diese Änderungsseite enthielt nur noch die Datensatznummer der Datenbank. Einfach ändern, und schon konnte man alle Paßwörter der Mitarbeiter umändern.

            Ich hab erstmal heftig gelacht, als ich den HTML-Quelltext gelesen hab und mir das ganze klarwurde. :)

            - Sven Rautenberg

      2. Hi!

        Hab´s mir angesehen. Da steht ja gleich alles drin, wie ich die Software hacken kann. Find ich nicht so toll.

        "Bitte beachten Sie, daß die Betreiber dieses Dienstes neue Bugs erst nach einer gewissen Schutzzeit von mindestens 3 Tagen veröffentlichten, um den Herstellern von betroffenen Programmen Zeit zur Reaktion zu geben."

        So long

      3. use Mosche;

        http://security.xwolf.de sind (bzw. sollen) alle Sicherheitslücken bei freien Scripten aufgeführt werden.

        Hab´s mir angesehen. Da steht ja gleich alles drin, wie ich die Software hacken kann. Find ich nicht so toll. Ich glaube, dass die Hackversuche von solchen Typen kommen, die diese Listen benutzen. Klar anzeigen muss man sie. Aber gleich aufzeigen wie das hacken geht?

        Du schreibst leider noch Unsinn, weil du dich damit noch nicht so auskennst.
        Was dort beschrieben wird -übrigens ist es in den meisten Fällen nur die deutschsprachige Übersetzung aus dem englischen Orginal aus der Mailingliste BugTRaq, welche ca. 100 mal gemirrort wird (!)- beschreibt in der Tat nur den Fehler und warum es ein Fehler ist.

        Dies ist deswegen notwendig, da man ansonsten jede beliebe Software und damit jede Firma diskredieren könnte.
        So ähnlich wie bei den Hexenprozessen im Mittelalter braucht man nur noch auf ein Skript zu zeigen, "Yehowa" rufen, und schon gilt es als mies programmiert, unsicher und und und.

        Man muss es daher schon belegen können, wenn man sagt es ist unsicher.
        Ansonsten ist es nur ein Gerücht.

        Ein Hackertool ist es dadurch aber nicht. Was du meinst sind wahrscheinlich Exploids. Dabei handelt es sich um vorgefertigte Programme, die die beschriebenen Fehler im Skript geziehlt ausnutzen um irgendwelche Kommandos zu bezwecken.
        Solche Exploids werden oft gebundelt in einer Software. Und die macht dann sowas, was du ganz oben in der Logfile siehst: Ein geziehlter Angriff auf einen ganzen Satz an moeglichen Sicherheitslücken.

        Diese Exploids sind wenige Tage nach dem ersten bekanntwerden von Sicherheitslöchern im Netz.
        (Die guten Exploids jedoch sind die, die noch unbekannte Fehler ausnutzen.)

        Solche Exploids und Sites die diese einfach so an jeden Skriptkiddie verbreiten gibt es massig ins Netz. Das ist das größere Problem an der Sache. Nicht eine zeitverzögerte Veröffentlichung eines -unter richtigen Hackern- längst bekannten Bugs.

        Lange Rede, kurzer Sinn: Zum Hacken brauchst du die Info nicht.
        Wenn du dich gut in der jweiligen Sprache und der Problematik auskennst, dann brauchst du nur zu lesen "ungeparste Variablen", und schon weisst du alles was du brauchst.

        Was PHP- und CGI-Skripten angeht ist es ja auch leider so, dass die allermeisten Bugs *nicht* gemeldet werden.
        Ich persönlich schätz, dass 80% *aller* freien Skripten, die man auf Skriptarchiven finden kann, Löcher haben.
        Veröffentlicht sind jedoch nur ein winziger Bruchteil an Problemen!

        Ein letztes Problem noch, wenn man keine Details angibt:
        Die Hersteller und die User glauben einen nicht.
        Da kann doch schliesslich jeder ankommen, und irgendeinen Bla faseln.

        Siehe aktuelle Diskussion um Handy- und Mobiltelefonsmog.
        Jeder Physiker und Biologe kann nachweisen, dass es da EInwirkungen
        gibt. Es gibt tausende Artikel und *Indizien*.
        Aber genauso wie bei der Klimaerwärmung gibt es dafür keinen Beweis, also *gibt es sowas nicht*.

        Eher wird man vorgeladen vor Gericht, weil man durch irgendwelche
        Behauptungen die Herstellerfirma im Ruf geschadet haben könnte.

        Ciao,
          Wolfgang