Jakiś czas temu na Niebezpieczniku pojawił się wpis Jeden 0day na WordPressa i leżymy! Co do zasady muszę się zgodzić z prezentowanym w tym wpisie stanowiskiem, ale... No właśnie, czy tak musi być?
Jeden 0-day i...
Dziś pojawiła się informacja o dość istotnym błędzie w Serendipity, który spowodował wydanie wersji 1.5.5. Czy musiałem się rzucić do aktualizacji oprogramowania? Nie, nie musiałem. I wcale nie kosztowało mnie to jakoś strasznie wiele wysiłku.
Jakiś czas temu napisałem wpis Bezpieczniejszy hosting i po raz kolejny okazało się, że podejście typu defence-in-depth się sprawdza. Sam atak mógłby wyglądać następująco:
- atakujący znajduje (nieużywany) komponent,
- za pomocą tego komponentu przekazuje plik na serwer (jakiś shell),
- odwołuje się do tego shella i ma (pełny) dostęp do serwera,
A jak się broni konfiguracja, z której korzystam? Mniej więcej tak:
- konfiguracja serwera (.htaccess) pozwala na dostęp tylko do tych zasobów, które są używane,
- brak jest praw do zapisu, nie można przekazać pliku shella,
- nawet jeśli plik by się udało przekazać (w kilku miejscach prawo do zapisu jest wymagane), nie można się odwołać do tego zasobu (patrz: Uczmy się na błędach: apache.org incident report, sekcja W^X),
Swoją droga podatność ta jest dobrym przykładem na to, że bezpieczeństwo aplikacji nie zależy tylko od (jej) kodu, ale również od bezpieczeństwa wszystkich wykorzystywanych (albo i nie) przez nią modułów.
Oczywiście nie oznacza to, że mój blog jest niezniszczalny. Pokazuję jedynie, że zastosowanie pewnych środków zaradczych powoduje, że nawet 0-day nie musi oznaczać końca świata... W końcu w bezpieczeństwie nie chodzi tylko o ograniczenie ilości podatności, ale również o ograniczenie skutków wykorzystania tych podatności, których nie uda się znaleźć, zanim zrobią to ONI.
Przy okazji przypomnę o moim wyzwaniu: Lekcja 25: Wyzwanie V. Jak na razie dotarł do mnie jeden raport, a podatności do znalezienia jeszcze kilka zostało.
Tak w ogóle, to warto byłoby zebrać zestaw takich "dobrych praktych" dla blogerów, mając na uwadze TOP5 popularnych CMS-ów (WP, Joomla, Drupal, ...? ). To jak, robimy to?
Co do drugiej części Twojego komentarza - robić możemy, tylko wymaga to trochę pracy by się z taką aplikacją zapoznać Może w jakimś innym, nieco mniej gorącym okresie niż Q4 i początek Q1.
Druga sprawa jest taka, czy na coś takiego jak mój blog VPS jest rzeczywiście potrzebny. Owszem, ilość rzeczy poza moją kontrolą jest spora, ale przecież ten blog ma być dla mnie rozrywką, a nie dokładać mi więcej pracy. W końcu teraz poniekąd sporo pracy związanej z takim normalnym utrzymaniem deleguję na firmę hostingową.
Podejście defence-in-depth zawsze się sprawdza i moim zdaniem jest wręcz konieczne, choćby po to, aby zyskać trochę czasu w sytuacji pojawienia się 0daya. Czasami (bo przecież nie zawsze) może się zdarzyć, że za pomocą jednej metody hardenującej wyeliminujemy zupełnie daną podatność.
...
Również chciałem skomentować wpis Piotrka Koniecznego, ale jakoś o tym zapomniałem. Zgadzam się z Tobą Pawle, że wcale nie musi być tak, że "jeden 0day i leżymy".
Od czego mamy firewalle aplikacyjne? Od czego mamy firewalle bazodanowe?
Zdaję sobie sprawę, że poprawne skonfigurowanie powyższych wymaga co najmniej 2x większego nakładu pracy, ale jak już ostatnio gdzieś pisałem "zawsze coś za coś". Dobrym rozwiązaniem, które np. ja stosuję jest także ograniczenie dostępu do paneladminów/cmsów tylko do konkretnych IP (no bo niby po co mają one być publicznie dostepne?)
Wszyscy korzystamy z oprogramowania tworzonego przez innych i z jednej strony musimy mieć do niego zaufanie, z drugiej strony - trzeba się liczyć z faktem, że oprogramowanie może (w zasadzie - musi) zawierać błędy. Owszem, możemy starać się zmniejszyć prawdopodobieństwo udanego wykorzystania jakiejś podatności, ale nigdy nie jesteśmy w stanie osiągnąć okrągłej wartości "0".
Ogólnie to temat na dłuższy wpis, więc na razie komentarz przerwę w tym miejscu
So, why is their website so insecure? Ettercap's message board is
hosted at Sourceforge, so they share a server with thousands of other
customers. Every single customer is able to execute commands and
access the other project directories. Pretty stupid, eh? You only need
to find one hole in one hosted site and you can access ALL the project
databases. Of course that isn't ALoR's fault, it's Sourceforge's
fault. Regardless, people who care about security and data integrity
wouldn't use such a shitty provider, would they?
....
Just look at the process list, horrible. Even the worst perl bots
(scax) get access. If such a poorly written bot can own this box, everyone can.
I jak tu mówić o kwestiach bezpieczeństwa? Chyba każdy z nas ściągał soft z sourceforge'a, a wg autora powyższego linka, serwer ten jest już 5 lat zbackdoorowany.
Paweł, masz rację, to temat na naprawdę długi wpis:)