9:38
13/9/2010

Kilkanaście dni temu, w artykule “Cholera, tego błędu nie naprawimy” opisywaliśmy atak na Widnows wykorzystujący podrzucanie bibliotek .DLL jako metodę zdalnego wprowadzenia kodu na maszynę ofiary. Dziś okazuje się, że oprócz dll-ek podrzucać można również pliki .exe, a ostatnio wprowadzone przez Microsoft zabezpieczenia nie radzą sobie z tą wersją ataku.

Binary planting

Windowsowy błąd w kolejności przeszukiwania ścieżek znajduje się nie tylko w funkcji LoadLibrary* (dll planting), ale również CreateProcess*, ShellExecute*, WinExec, LoadModule, _spawn*p* i _exec*p*. Poniżej ścieżki i kolejność przeszukiwania dla kilku z powyższych funkcji (nie wszystkie są dokładnie udokumentowane, ale można je “wyczytać” przy pomocy narzędzi do monitorowania procesów):

    CreateProcess*, WinExec, LoadModule:

  1. Katalog z którego została odpalona aplikacja
  2. Current Working Directory (CWD)
  3. 32-bit (Windows\System32)
  4. 16-bit (Windows\System)
  5. Katalog Windows
  6. Zmienna PATH

Powyższa kolejność pokazuje, że jeśli aplikacja będzie chciała uruchomić np. Kalkulator Windows przy pomocy CreateProcess(NULL,”calc.exe”,…), to odpowiednio zmodyfikowany calc.exe umieszczony w CWD zostanie odnaleziony i uruchomiony wcześniej niż systemowy oryginał. Przypominamy, że CWD z reguły jest ustawiany na katalog, w którym znajduje się uruchamiany przez aplikację plik (np. na pendrive) i może być ustawiony także na zasób sieciowy (Samba, WebDAV).

Przykład ataku EXE planting

Bardziej praktyczny przykład, podawany w advisory, to odpalenie podstawionego pliku .html w przeglądarce Safari. Plik zawiera link file://malware.exe. Safari automatycznie otwiera wtedy Windows Explorera (korzystając w/w funkcji) — i niestety, zamiast systemowego explorer.exe odpala się podstawiony w katalogu z plikiem .html “fałszywy” explore.exe.

DEMO ataku

Niegroźną demonstrację ataku możecie wypróbować na sobie, podążając za tą instrukcją.

EXE planting groźniejszy od DLL plantingu

DLL planting wymagał załadowania “nieobecnej” w systemie DLL-ki (bo CWD znajdował się dopiero na 4-tym miejscu, a więc pierwsze 3 próby poszukiwania dllki musiały zakończyć się niepowodzeniem). W powyższym przypadku, EXE planting działa z istniejącymi plikami wykonywalnymi, o ile nie znajdują się one w katalogu aplikacji, która ma je wywołać.

Lista podatnych na atak aplikacji (a raczej hashy z plików) znajduje się tutaj.

Ochrona

Na razie brak. Wprowadzona przez Microsoft’s poprawka CWDIllegalInDllSearch blokuje tylko CWD dla wywołań LoadLibrary*, a więc nie uchroni nas przed podstawieniem pliku exe. Pewnym sposobem mogłoby być siłowe ustawienie CWD na początku wykonywania programu na jakąś bezpieczną lokalizację, ale ta praca musi zostać wykonana przez deweloperów każdej podatnej na atak aplikacji, a nie developerów Windowsa…

Przeczytaj także:

26 komentarzy

Dodaj komentarz
  1. Przecież to nic specjalnie odkrywczego. Uniksowcy wiedzą od dawna, że nie należy “.” umieszczać w $PATH, a już na pewno nie na początku $PATH i jakimś absurdem się wydaje pomysł, żeby system szukał plików wykonywalnych w aktualnym katalogu jeszcze przed $PATH…
    Inna sprawa, że ten „absurdalny pomysł” zastosowali np. twórcy Pythona do ładowania modułów (da się obejść i często się to robi, nie tyle ze względów bezpieczeństwa, ale aby uniknąć innych „dziwnych błędów”)…

  2. Hehe a to ciekawy rozwój wypadków :)

    Co ciekawe, tym razem faktycznie ta klasa błędów była już znana na *nixach. Z tego co kojarze były dwa warianty jeśli chodzi o samo system():
    1. system(“date”); — jeśli PATH zawierało . (czyli CWD), to date było odpalone z CWD
    2. system(“/bin/date”); — w tym wypadku oprócz . w PATH należało jeszcze zmienić IFS (Internal Field Separator aka znaki oddzielające argumenty programu) na “/” (slash), czyli dostawało się program “bin” z parametrem “data”, ofc szukany w CWD
    AFAIR to pierwsze działało również w przypadku exec*.

    I wygląda na to, że klasa błędów przywędrowała na windowsa… interesting :)

    • Microsoft wreszcie zaczął brać przykład z porządnych systemów :), ale zaczął od nieodpowiedniej strony.

  3. To ja czekam na kolejny mroczny advisory, który tym razem będzie dotyczył parametru lpApplicationName funkcji CreateProcess. Hint: sekcja “Security Remarks” w dokumentacji wspomnianej funkcji: http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx

    Nie mogę się powstrzymać: http://xkcd.com/293/

    • A gdyby spojrzeć na to z innej strony? Takiej bardzije paranoiczno-teoretyczno-spiskowej :> Może te wywołania powstały dokładnie w tym celu? :> Domyślne ustawienie kiepskie (celowo?) pod kątem security, natomiast w dokumentacji jest, że da się zmienić coś tu, coś tam i będzie działać bezpieczniej (plausible deniability)… por. https://niebezpiecznik.pl/post/konkurs-podstepnego-programowania-w-c/

  4. Poprawka do systemu:

    http://support.microsoft.com/kb/2264107

    • @Jacek: ta poprawka nie naprawia tego błędu… (exe planting trochę wychodzi poza dll planting, czytałes w ogóle tekst powyżej? :>)

  5. Jasny gwint. Taki atak to może każdy jeleń przeprowadzić, byle mieć exeka malware’u. Zmieniamy na notapad, wrzucamy razem z plikiem tekstowym na pendraka i idziemy do kumpla.
    Widzę drobną ochronę przed niektórymi próbami ataku – mieć skojarzone typowe pliki (jak .txt) z jakąś nietypową aplikacją. Np. ja do .txt używam edytora NoteTab, więc taka próba z plikiem tekstowym akurat nie zadziała (jeśli dobrze rozumiem zasadę?).

  6. hmmm, a ja myslalem ze cos odkrywczego znalezliscie
    problem znany i wykorzystywany, najczesciej z rodziny Fake.Av, i innych badziew
    panowie sezon ogorkowy juz sie dawno skonczyl – czy mozna prosic o cos konkretniejszego ?

  7. Powiedzcie mi proszę, dlaczego programiści, którym przecież się za to płaci, żeby dobrze programowali, nie czytają dokumentacji? To kojarzy mi się z lekarzem, który nie przeczytał jak stosuje się defiblirator.

  8. @WinFixxr: bo w większości przypadków programistom się płaci za to, by program działał, a nie za to, by był napisany poprawnie. Programiści nie dostają dodatkowej premii za “wartość artystyczną” napisanego kodu.

    Co ciekawe w trakcie testów bezpieczeństwa aplikacji internetowych niejednokrotnie trafiłem na podatność, której “wzorzec” mogłem później znaleźć na stronach z przykładami dla programistów. Jeśli ktoś opublikuje złe rozwiązanie jakiegoś problemu, z dużym prawdopodobieństwem można założyć, że istnieje niepusty zbiór programistów, którzy z niego skorzystają…

  9. –quote–
    Paweł Goleń 2010.09.13 09:59 | #
    To ja czekam na kolejny mroczny advisory, który tym razem będzie dotyczył parametru lpApplicationName funkcji CreateProcess. Hint: sekcja “Security Remarks” w dokumentacji wspomnianej funkcji: http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx
    –quote–

    Hehehe to będzie zabawne ;) c:\Program.exe ;D

    Hmm, w jednym z exploitów na Windowsa XP korzystaliśmy z j00ru z tego, że jeśli mamy katalog c:\katalog oraz plik c:\katalog.exe, to niektóre funkcje do odpalania (stawiam na ShellExecute etc) wywołane z parametrem “c:\katalog” odpalały c:\katalog.exe zamiast okna explorera z widokiem na c:\katalog.
    Ciekawe czy to może posłużyć do exe plantingu ;)

  10. To jak już lecimy pomysłami w ramach ciekawostki proponuję prześledzić co się dzieje (jakie pliki są otwierane), gdy w konsoli się wpisze np. “test”. Albo inaczej, jeśli jest w katalogu test.exe i test.com, to który plik zostanie uruchomiony? A test.cmd i test.bat? :)

  11. Cóż, od długiego czasu (przynajmniej od czasu win 95) programiści zamieszczali potrzebne im dllki razem z aplikacją, nie wiem czy M$ wprowadził to z myślą o takim zastosowaniu ale często było to stosowane żeby aplikacja używała “dobrej” wersji biblioteki.

    Jak wiadomo windows od wieków nie ma czegoś co by można nazwać “systemem zarządzania pakietami” więc instalacja nowej wersji biblioteki polegała na nadpisaniu starej (nie jak w linuksie, dodanie libcostam-1.2.3 + uaktualnienie symlinka tak że stare programy mogą dalej korzystać z libcostam-0.8.1 albo libcostam-1.1.0)

    I taki programmers (jeżeli używa popularnego liba) może albo dodać go do instalatora (ale wtedy inny program może potrzebowac starszej wersji, albo mu zmieni na nowszą), albo “na chama” wsadzić je do katalogu z execiem, więc usunięcie tego “buga” nawet jakbym M$ chciał, popsułoby sporo aplikacji.

    Sam atak jest staaary (http://blogs.msdn.com/b/david_leblanc/archive/2008/02/20/dll-preloading-attacks.aspx a pewnie znajdzie się i coś starszego) tylko jakoś nikt go wcześniej nie nagłaśniał

  12. @Paweł Goleń:
    Pamiętam jeszcze jak miałem komputer z dosem (koło 98 dostałem starego złoma, miałem wtedy 9 lat) – wtedy sama idea odpalania *.exe *.com *.bat BEZ wpisania tegoż rozszerzenia wydawała mi się bez sensu. I o ile pamiętam to leciało to tak -> com, exe, bat. Czy od czasów Windowsów coś pozmieniali, i gdzie wepchali cmd na listę – nie wiem w sumie. Zakładam, że wykonałeś test o którym mówisz – podziel się rezultatem.

    A tak przy okazji tego arta – przypomniało mi się, że mi windows update nie pokazał się już ze 2 miesiące.. Spadam sprawdzić co z nim :P Dzięki za art.

  13. @XANi,
    Przeczytałem Twój komentarz i.. faktycznie – nieraz widziałem takie rzeczy pod Win3.1 – przykład – program “Biorytmy” bodajże – który musiał mieć własną wersję jakiejśtam dll-ki bo były problemy.
    Swoją drogą takie rozwiązanie jest zastosowane np. w.. GTA San Andreas. W folderze z plikiem exe znajdziemy:
    d3d9.dll
    d3dx9_26.dll
    d3dx9_33.dll
    A wiem, że usuwanie tego na ogół nie robi problemów, ale czasem, gdy gra nie działa to ludzie wymieniają się nawet tymi dll-kami i wrzucają do folderu z grą – a gra magicznie zaczyna działać. Czyli zakładam, że jak ktoś rozwiązał problemy z nią w ten sposób – to po aktualizacji przestaje to działać :P

  14. @XANi
    a o winsxs slyszal? Jak o czyms piszesz to wez przrynajmniej sprawdzaj czy nie masz starych informacji

  15. @dzek: Według dokumentacji (http://support.microsoft.com/kb/811528) będą sprawdzone rozszerzenia z listy %PATHEXT%. Empiryczne sprawdzenie wskazuje na to samo.

  16. O tak co za disaster
    Czytałem kiedyś ksiażke o wirusach , ona ma jakieś 10 lat jak nie więcej
    i tam ten pan ekspert też pisał o tym że jest pewna dziwna kolejność podczas uruchamiania
    aplikacji na windołsach . Brana jest po uwagę nie tylko ścieżka ale nawet (Achtung !!!) typ pliku
    Tylko że on nie nazywał się HD MUR i przeszło bez echa

  17. W Win3.1 ;) były pliki *.ini, a w jednym z nich była lista rozszerzeń, które były uznawane za “uruchamialne”. Ciekawostka, po usunięciu exe z konfiguracji, Windows nie był w stanie odpalić żadnego pliku z takim rozszerzeniem. Może gdzieś w przepastnych rejestrach nadal coś takiego jest… ;)

  18. @Klapki
    Hehe widać wtedy było jeszcze za wcześnie na tego typu akcje ;)
    Btw, nie wiem czy exe planting zostało nagłośnione przez HD Moora czy przez kogoś innego.

    @kostuch
    Afair nadal jest coś takiego w rejestrze. Wiem że malware z tego korzysta (korzystał parę lat temu), szczególnie taki który lubi infekować exeki – afair przypisuje program malware.exe dla odpalania innych plików .exe ;p

  19. @Piotr
    “A gdyby spojrzeć na to z innej strony? Takiej bardzije paranoiczno-teoretyczno-spiskowej :> Może te wywołania powstały dokładnie w tym celu? :> Domyślne ustawienie kiepskie (celowo?) pod kątem security, natomiast w dokumentacji jest, że da się zmienić coś tu, coś tam i będzie działać bezpieczniej (plausible deniability)… por. https://niebezpiecznik.pl/post/konkurs-podstepnego-programowania-w-c/

    Wyczuwam, że piszesz pół serio. ;)

    A moim zdaniem wynika to po prostu z niechlujstwa i z pośpiechu. Windows od początku był tworzony “na kolanie”. I zawsze w pośpiechu, bo taka była potrzeba rynku. Chłopcy z MS, by zdążyć musieli stosować prowizoryczne rozwiązania, z nadzieją, że kiedyś się to poprawi…

    • bkr: Dobrze wyczuwasz ;-) Oczywiście tamten mój komentarz to próba poFUDowania z paranoików i miłośników aluminiowych czapeczek na głowie :-)

  20. @Gynvael Coldwind
    W Win3.1 usunięcie exe z pliku konfiguracyjnego oznaczało, że takiego pliku nie można było uruchomić. To o czym piszesz, to przypisanie aplikacji do rodzaju rozszerzenia i jest to już jednak inna bajka. gdyby mechanizm był identyczny w nowszych wersjach Windows, to po usunięciu typu exe jako uruchamialny, program malware.exe też nie mógłby się uruchomić. Krótko mówiąc ochrona doskonała ;)

  21. Widzę, że wszyscy są dobrze poinformowani tutaj. Jeśli ktokolwiek z Was przeczytałby Secure Code (http://www.amazon.com/Writing-Secure-Code-Strategies-Applications/dp/0735617228) wiedziałby o takim postępowaniu od lat, to nie jest nic nowego. Nowe jest co najwyżej to, że starą (i doskonale znaną) lukę zaczęli wykorzystywać script kiddies. Podobnie @XANi błysnął swoją (nie)wiedzą czy też ignorancją jeśli chodzi o Windows – winsxs, czy wykonanie side-by-side to jest nowość dla Ciebie ;)

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.