Luka Zero Day we wszystkich wersjach Microsoft IIS! [Aktualizacja]
- Dodano: 25 grudnia 2009
- Wprowadził: hcsl.pl
- Komentarze: 20
Soroush Dalili, brytyjski specjalista od bezpieczeństwa aplikacji internetowych oraz systemów operacyjnych z rodziny Windows, opublikował informacje dotyczące nowej luki Zero Day odkrytej przez siebie we wszystkich wersjach Microsoft Internet Information Services.
Odkryty błąd ma związek ze sposobem, w jaki serwer IIS przetwarza nazwy plików zawierające znak średnika. Wiele serwisów zezwalających użytkownikom na przesyłanie do serwera własnych plików (np. plików .jpg służących jako awatary) odrzuca potencjalnie niebezpieczne formaty, takie jak choćby pliki zawierające aktywne strony ASP (.asp). Odkryta luka pozwala na łatwe obejście takiego mechanizmu zabezpieczającego, poprzez dodanie do nazwy potencjalnie niebezpiecznego pliku znaku średnika wraz z akceptowanym przez serwer rozszerzeniem (np. avatar.asp;.jpg). Taki plik zostanie zaakceptowany i pobrany przez serwer tak jak zwykły plik .jpg. Jednak w momencie jego otwarcia, plik taki zostanie przez IIS zinterpretowany jako kod ASP i wykonany przez moduł asp.dll.
Ze wstępnych informacji wynika, że wszystkie serwery IIS pozbawione dodatkowej kontroli formatu pliku są w wyniku powyższej luki podatne na wykonanie dowolnego kodu. Secunia, duńska firma zajmująca się między innymi śledzeniem oraz klasyfikowaniem nowych zagrożeń, potwierdziła do tej pory istnienie błędu w pełni zaktualizowanym systemie Windows Server 2003 R2 SP2 (IIS 6). Przedstawiciel firmy Microsoft zapewnił natomiast, że gigant z Redmond rozpoczął już analizę zgłoszonego problemu.
Wobec braku poprawki zamykającej lukę lub oficjalnego poradnika zabezpieczeń firmy Microsoft, administratorzy serwerów IIS powinni rozważyć odebranie praw wykonania z lokacji, do których trafiają pliki ładowane przez użytkowników serwisów.
[Aktualizacja]
Soroush Dalili zaktualizował swą publikację. Z najnowszych informacji wynika, że błąd obecny jest w IIS w wersji 6 oraz starszych. Wersja 7.5 nie jest podatna na opisany atak, natomiast wersja 7 nie została jeszcze do końca przetestowana.
Informacje na temat najnowszej luki Zero Day w Microsoft IIS, jako pierwszy w Polsce opublikował serwis HARD CORE SECURITY LAB!
Więcej informacji: http://soroush.secproject.com/downloadab...report.pdf
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
20 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
No to klopsik.
Ciekawe jak szybko będzie łata i czy w ogóle będzie łata do starszych wersji IIS.
Już jest nie oficjalna poza tym jak ktoś się zna na asp wie jak łatwo się, przed tym ustrzec – a procesy IIS można też zamknąć w osobnym środowisku. Taka dziura, nie dziura.. jak administrator sierota to nawet najwymyślniejsze zabezpieczenia zbyteczne
LOL.
Niewątpliwie błąd jest po stronie serwera IIS, jednak to robiący serwis pozwala na jego wykorzystanie. Jak można się przekonać przy lekturze "Secure file upload in PHP web applications Alla Bezroutchko June 13, 2007" zrobienie bezpiecznego uploadu plików na serwer nie jest trywialną sprawą. Ograniczanie się do sprawdzania rozszerzenia pliku od zawsze było słabym pomysłem…
Ale robiący serwis pozwala jedynie na wgranie pliku jpg. I jest tego *pewien*, że jest plik z rozszerzeniem .jpg, więc *na pewno* nie wykonywalny skrypt.
To, że kretyni z microsoftu zrobili tak, że plik "avatar.asp;.jpg" interpretowany jest przez serwer jako plik z rozszerzeniem .asp to ich, i tylko ich, wina.
Współczuje, administratorowi, który musiałby wspołpracować z koderem prezentującym Twój tok myślenia. Zawsze winny, ktoś inny niż ja, w udostępnianiu usług jest jedna zasada udostępniamy tyle ile konieczne + zasada ograniczonego zaufania.. jeśli koder i administrator ich nie odpuści to dziury softu nie straszne, jednak gdy choć jeden odpuści i pojawi się jakaś dziura w oprogramowaniu to los serwera może być nie ciekawy..
"I jest tego *pewien*, że jest plik z rozszerzeniem .jpg, więc *na pewno* nie wykonywalny skrypt."
LOL.
Nie można polegać tylko i wyłącznie na rozszerzeniu pliku.
Zresztą wydawało mi się, że zmiana nazwy plików na coś równie sensownego jak hash starej nazwy, daty uploadu i jakiegoś losowego badziewia jest standardem, który zabezpiecza przed takim atakiem…
Wina MS polega na tym, że wcześniej tego nie znaleźli sami. Udany atak na jakiś serwis stojący na iis będzie w 85% winą dewelopera, który nie czytał wystarczająco dużo o web szejkjurity i nie wie, że licho nie śpi.
Mechanizmy zabezpieczeń są żeby je używać. Po to przeca są. Jak musisz wynaleźć koło od nowa to już twoja sprawa. Ale faktycznie serwis który opiera się tylko na sprawdzeniu rozszerzenia i tak polegnie na czymś innym
W artykule brakuje kilku istotnych faktów:
Microsoft Internet Information Services ‐ IIS (All versions Work successfully on IIS 6 and
prior versions – IIS7 has not been tested yet – does not work on IIS7.5)
Z tego co widzie u mnie na 6.5 dziury nie ma – albo mam źle skofigurowany IIS
For Web Developers:
o Highly Recommended: Use a completely random string as a filename and set its extension
by the web application itself (by using a “switch‐case or select‐case” for example) and never
accept the user’s input as the filename.
o Only accept alpha‐numerical strings as the filename and its extension.
For Webmasters:
o Remove “execute” permission from the upload directories (folders).
Więc o nazwaniu tego poważną dziurą.. to hmm.. kto średnio rozgraniety daję uprawnienia do wykonania uploadowanym plikom?
Aha w Windows Server 2008 R2 domyslnie jest ISS7.5 nie wiem skąd Ci szwedzi wcisnęli tam IIS 6 i nazwali to zaktualizowana wersja :/ Bajkopisanie autora?
Napisałem wyraźnie, że błąd został potwierdzony do tej pory przez Secunię w Windows Server 2003 R2 SP2 (IIS 6), nie pisałem nigdzie o Windows Server 2008 R2.
Natomiast, to o czym pisze Najek (All versions Work successfully on IIS 6 and prior versions – IIS7 has not been tested yet – does not work on IIS7.5) zostało dodane w publikacji dopiero po opublikowaniu tego newsa, wcześniej było tam "All versions".
Zrobię za chwilę update do newsa.
Ta, a w nagłówku dalej:
Zero Day odkrytej przez siebie we wszystkich wersjach Microsoft Internet Information Services.
W treści dalej:
Ze wstępnych informacji wynika, że wszystkie serwery IIS pozbawione dodatkowej kontroli formatu pliku są w wyniku powyższej luki podatne na wykonanie dowolnego kodu.
"powinni rozważyć odebranie praw wykonania z lokacji, do których trafiają pliki ładowane przez użytkowników serwisów."
WTF? Kto średnio inteligetny pozwala na wykonywanie uploadowanych plików na swoim serwerze? Co tu jest do rozważania?!
Z tym Windows Server 2008 R8 faktycznie moja wtopa (Niemniej dla 2003 też jest IIS 6.5/7
), reszta wtopa autora.
1) W tytule masz [aktualizacja], co zachęca do przeczytania aktualizacji w tekście, zawierającej nowe fakty. Trudno przerabiać cały artykuł, który był przecież pisany zgodnie ze stanem na daną chwilę, tylko dodaje się aktualizację wyjaśniającą nowe fakty.
2) "Ze wstępnych informacji wynika, że wszystkie serwery IIS" ze wstępnych informacji tak właśnie wynikało, więc to zdanie będzie zawsze prawdziwe.
3) prawa wykonania – zdarzają się różne najprostsze błędy, w przypadku odkrycia tego typu luki, warto sprawdzić, czy wszystko z prawami w tego typu katalogach jest OK.
"Taki plik zostanie zaakceptowany i pobrany przez serwer tak jak zwykły plik .jpg. Jednak w momencie jego otwarcia, plik taki zostanie przez IIS zinterpretowany jako kod ASP i wykonany przez moduł asp.dll."
Trzymając się tego przykładu z "obrazek.asp;.jpeg," mam pewne niejasności – rozumiem, że sparsowana nazwa pliku przez IIS to "obrazek.asp", ale:
1. samo otwarcie pliku w sensie programowym to nie to samo co otwarcie w sensie użytkowym. Dlatego zastanawiam się w jakim celu serwer miałby otwierać plik w sensie użytkowym przez aplikację skojarzoną w systemie z rozszerzeniem jpeg ?
2. Rozumiem, że przykładowy obrazek np. trzeba przetworzyć – ale wyobraźni mi nie starcza, by uwierzyć, że może ktoś może przekazywać plik do przetworzenia przez:
ShellExecute("OPEN", "nazwa_pliku_sparsowana_przez_ISS") czy
CMD->start "nazwa_pliku_sparsowana_przez_ISS"
a nie przez np.
ShellExecute( "imageprocessor.exe", "nazwa_pliku_sparsowana_przez_ISS") czy
CMD->imageprocessor.exe "nazwa_pliku_sparsowana_przez_ISS"
Niemniej jednak programistom od IIS należy się powyciąganie za uszy, gdyż systemowe funkcje windy do obsługi ścieżek(shlwapi) poprawnie parsują takie galimatjasy ze średnikami w nazwach, wiec po kiedy parsować to swoim kodem ?
Ja rozumiem, że chodzi o to że:tworzymy serwis, gdzie możnaumieszcząc np. zdjęcia (coś a'la flickr). Użytkownik wysyła plik ASP o nazwie evil.asp;.jpg. Serwer sprawdza rozszerzenie (.jpg – OK) i umieszcza plik gdzieś w katalogu dostępnym przez WWW. Następnie użytkownik chce pobrać plik, przez co odwiedza w przeglądarce stronę http://example.com/upload/evil.asp;.jpg W tym momencie serwer myśli "hoho, toż to plik ASP, trzeba go uruchomić". Bęc!
Dokładnie, o to chodzi!
A od kiedy się daje +x do plików graficznych?
To Windows. Inne zwyczaje, inne tradycje! (mimo, że technologia miejscami nawet bardzo dobra)
Żeby niektórzy się tu nie podniecali niezdrowo: w takim Linuksie pod Apache np. skrypty PHP też nie muszą mieć +x, i też rozpoznawane są na podstawie rozszerzenia.
"(…)Bęc!"
Teraz rozumiem – dzięki
Polecam artykuł na niebezpieczniku (o niebo lepszy):
http://niebezpiecznik.pl/post/dziura-w-microsoft-…
oraz link z komentarza:
http://isc.sans.org/diary.html?storyid=6139