Po błędach typu “ups,nie naprawimy tego” z podkładaniem DLL i EXE gdzie czeka nas pewnie kolejny rewrite kodu przy Windows 9-10 lub nadzieja na to,że żaden z twórców setek aplikacji,które wykorzystujemy nie popełni tego typu zaniedbań.W najnowszej wtorkowej aktualizacji doszło nam buszujące na wolności zdalne wykonanie kodu/elewacja uprawnień z powodu błędnej kontroli przez usługę spooler praw dostępu użytkowników. Na szczęście jak Microsoft zapewnia drukarki sieciowe nie są udostępniane w żadnej domyślnej instalacji Windows. Uff , a już się martwiliśmy. Nie mniej ważny jest upubliczniniony błąd w IIS. Ale co robić gdy nie możemy zaktualizować od razu aplikacji, bo jeszcze nie ma poprawki, którą możemy zastosować? Oczywiście poza wyłączeniem jej.
Poziom wykorzystania błędów znalezionych w nowych systemach operacyjnych będzie rósł w miarę powszednienia nowo zaimplementowanych zabezpieczeń. Zabezpieczenia typu DEP,ASLR,SAFESEH itp. często nie są dużą przeszkodą w przejęciu systemu dzięki zmianie podejścia i wykorzystaniu np “return oriented programing”.
Ale nie jesteśmy bezbronni i nie trzeba być najszybszym człowiekiem na świecie aby nie złapał nas niedźwiedź, trzeba być tylko szybszym od tego, którego niedźwiedź złapie. Analogicznie z zabezpieczeniami.Nie każdego będzie atakował jakiś stary wyjadacz ciasteczek ze stosu. Możemy znacznie utrudnić życie chcącym wykorzystać exploita w naszym systemie jeżeli stworzymy niestandardowe warunki lub zabierzemy jeden z elementów niezbędnych dla zadziałania exploita.
Możemy ograniczyć środowisko (Sandboxie, Joebox, BufferZone, VMLite VirtualApps Player, EMET, VMware, chroot, jaile i inne) , w którym funkcjonuje aplikacja.Stosując wirtualizacje,sandboxa lub wprowadzając do niej niestandardowe zabezpieczenia wprowadzamy kolejną zmienną, którą twórca exploita musi przewidzieć. Uruchomienie w ten sposób podatnej aplikacji na pewno dostarczy dodatkowej warstwy ochronnej ograniczając poziom potencjalnego wtargnięcia lub znacznie podnosząc trudność wykorzystania błędu.
Jeżeli nie zrobimy tego jeszcze pozostaje nam uniemożliwienie dotarcia exploita do wrażliwej usługi (na przykład firewallem aplikacyjnym). Ciekawym przykładem jest tu zestaw reguł wciąż żyjącego i dobrze mającego się Snorta wydawanych przez zespół VRT. Uwzględniają wtorkowe poprawki Microsoftu w dniu ich wydania i rozpoznają próby ich wykorzystania wewnątrz sieci. Poza Microsoftowymi publikacjami podatności uwzględniają setki zasad, które pomogą obronić nasze aplikacje. Reguły są dostępne do pobrania dla zarejestrowanych użytkowników po 30 dniach od ich publikacji nieodpłatnie. A roczna subskrypcja dla domu/edukacyjna umożliwiająca bieżące aktualizowanie kosztuje około 100 zł.
Warto zobaczyć:
http://technet.microsoft.com/en-us/security/ff859539.aspx
http://isc.sans.edu/diary.html?storyid=9547
http://www.corelan.be:8800/index.php/2009/09/21/exploit-writing-tutorial-part-6-bypassing-stack-cookies-safeseh-hw-dep-and-aslr/
http://www.snort.org/snort-rules/
