19:26
6/10/2014

O poważnej dziurze w Bashu informowaliśmy już ponad tydzień temu. Niekończące się pasmo poprawek dla Basha, szeroka powierzchnia ataku (podatne są tak znane projekty jak git, OpenVPN, NAS-y od QNAP, i w zasadzie wszystko co korzystało z CGI) oraz ospałość administratorów w kontekście aktualizacji sprawia, że o tym błędzie jeszcze nie raz usłyszymy. Dziś za jego pomocąpomocą exploita na Shell Shock zhackowano Yahoo, chociaż Yahoo nie było na Shell Shocka podatne. Ale nie tylko z tego powodu historia jest ciekawa…

ShellShock

ShellShock

Zgłosił błąd do Yahoo, ale go zignorowano

Jak na Reddicie informuje jeden z badaczy bezpieczeństwa, Jonathan Hall, przesłał on wcześniej do Yahoo zarówno opis podatności ShellShock, jak i szczegółowe informacje jak za jej pomocą można przejąć kontrolę nad serwerami Yahoo — mało tego, zauważył on, że ktoś już próbuje atakować te same serwery, które on przejął.

Yahoo jednak nie odpowiedziało na jego zgłoszenie od razu (być może dlatego, że twittował do Marrisy Mayer, i pisał jej długaśne e-maile, zamiast pisać na alias security@yahoo.com…). Dopiero kontakt z mediami i FBI skłonił firmę do odpowiedzi, w ramach której Yahoo przyznało, że ich serwery zostały w istocie zhackowane.

Odpowiedź Yahoo na zgłoszenie błędu

Odpowiedź Yahoo na zgłoszenie błędu

Badacz ma jednak pretensję do Yahoo o to, że firma nie uznała jego odkrycia jako kwalifikującego się do programu Bug Bounty.

Na czym polegał bł�??d?

Jonathan udostępnił opis ataku na swojej stronie internetowej (obecnie nie działa, ale kopia jest tutaj). Podobnie jak przestępcy, za pomocą Google Dorków odnajdował strony WWW korzystające ze skryptów cgi-bin, a następnie przesyłał im znany payload nawiązujący połączenie zwrotne ze swoim hostem. Jak informuje badacz, większość ze “złowionych” w ten sposób hostów była już zainfekowana — w katalogach /tmp znajdowały się exploity na roota i paczki z IRC-botami podpinającymi ofiarę do botnetu wykonującego ataki DDoS.

Badacz twierdzi, że w trakcie jego eksperymentu ktoś zaczął skanować jego maszynę pod kątem podatności w Bashu. Kiedy sprawdził adres IP atakującego, okazało się, że jest to serwer z domeny WinZip.com. Johnatan odpowiedział atakiem, i za pomocą podatności w bashu podejrzał procesy. Znalazł na hoście bota i przeanalizował jego kod a następnie podpiął się do serwera IRC, z którego korzystał bot.

Wtedy zauważył, że na liście ofiar są oprócz WinZip.com tak znane domeny jak właśnie Yahoo.com. W przypadku Yahoo wszystko mało zacząć się od serwera dip4.gq1.yahoo.com (63.250.204.25), który dzięki podatności na ShellShock umożliwił dostęp do wewnętrznej sieci Yahoo, w tym do api118.sports.gq1.yahoo.com (10.212.240.43). Oba hosty, które mają być związane z usługą sporty i gier on-line, zostały zrootowane przez atakujących — według Jonathana — pochodzących z Rumunii.

WinZip na jednym obrazku

WinZip na jednym obrazku

Analiza incydentu po stronie Yahoo wciąż trwa. WinZip do tej pory nie udzielił żadnego komentarza. Jeśli w ostatnich dniach pobieraliście coś z serwerów Yahoo (zwłaszcza dotyczących gier i sportu) lub domeny WinZip.com, sprawdźcie swój komputer pod kątem złośliwego oprogramowania. Niewykluczone, że włamywacze podmienili część danch na przejętych przez siebie serwerach.

Powyższa historia pokazuje, że wciąż nie wszystkie firmy zidentyfikowały wszystkie podatne na shell shock hosty — a przestępcy nie śpią i masowo skanują internet w poszukiwaniu łatwych celów. Można się tylko cieszyć, że większość grup włamywaczy korzysta z banalnych pod kątem analizy botów, które umożliwiają przejrzenie ich misternego planu i podejrzenie liczby ofiar.

Aktualizacja 7.10.2014
Co ciekawe, dyrektor Yahoo do spraw zarządzania bezpieczeństwem informacji wyjaśnia, że serwery, które przejęli atakujący wcale nie były podatne na Shell Shocka… ale exploit z którego korzystali włamywacze spowodował wykonanie kodu po stronie narzędzia do monitorowania logów z serwerów. Innymi słowy, atak zadziałał, ale podatność była w zupełnie innym miejscu. Nie wiadomo co było powodem RCE po stronie narzędzia do analizowania logów ani czy było ono autorskim rozwiązaniem.

Przeczytaj także:


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

22 komentarzy

Dodaj komentarz
  1. No i niby dlaczego miałby się kwalifikować do bug bounty?

    • Bo nie jest dziurą w serwisie a bashu?

    • @Altair, przeczytałeś co on napisał?

    • Aj, sorry, z rozpędu nie zauważyłem braku przeczenia

  2. Wszystko ok, ale “exploity na roota” też muszą korzystać z jakiejś podatności. Jakieś info?

    • Zazwyczaj niepozorny blad konfiguracji typu skrypt crona uruchamiany z roota z dostepem do zapisu przez usera ;)

  3. Gwarancja do wypłaty bug bounty przez korporacje, jest tak samo pewna jak nagroda 1mln dolarów dla mężczyzny, który zajdzie w ciążę.

    • Nagrodą było bodajże milion funtów i już została wycofana, bo pierwszy mężczyzna zaszedł w ciążę – wszczepiono mu zarodek w powłokę brzuszną, który zaczął się rozwijać, po czym nastąpiła aborcja… ;]

  4. Jak zwykle, najwięcej problemu leży w (leniwym) czlowieku ;p
    btw powinno się linkować do tego artykułu pod każdym przyszłym postem mówiącym “to jest bezpieczne bo linux / bo opensource”

    • System operacyjny , nieważne, Linux, BSD czy Solaris, może
      być tylko tak bezpieczny, jak jego administrator kumaty.

      Od dawna są w Linuksie mechanizmy mogące zablokować ataki wykorzystujące podobną podatność basha, php, perla czy pyththona, typu np Selinux, Tomoyo czy Apparmor, czy choćby Grsecurity-RBAC tylko trzeba któryś dobrze znać i porządnie skonfigurować na taką okoliczność, potrzebna jest też podstawowa wyobraźnia. ;)

  5. Debian, modem komórkowy, Avast i jestem bezpieczny, a Ty?

    • Kalkulator i Avast. Też jestem bezpieczny.

    • Kartka papieru, długopis, i latarka do wysyłania danych binarnych.
      Avast nie jest potrzebny.

    • notebook generalicji z Korei Północnej. Pełne bezpieczeństwo, brak ulotu elektromagnetycznego

    • @rav
      Też tak myślałem, dopóki mój 2-letni pełzacz nie zhakował mi kartki ^^

    • Można też użyć gołębia pocztowego – jak tu kilka lat temu (ale pewnie niewiele się zmieniło :-) – http://www.reuters.com/article/2009/09/09/us-safrica-pigeon-idUSTRE5885PM20090909

      Wtedy to już tylko ptasia grypa …

  6. Witam,

    Jakie typy serwisów muszą poprawić ten błąd?

  7. Avast zamiast głowy ..dobre

  8. news.ycombinator.com/item?id=8418809 polecam zaktualizować artykuł, pośpiech nie popłaca :(

    • Artykuł od wczesnych godzin porannych jest zaktualizowany o tą informację. Polecam czytać do końca ;)

    • Zwracam honor :)

  9. a pomyśleć że dobrze skonfigurowany firewall (z default policy DROP na OUTPUT i konkretną listą wyjątków które mogą inicjować połączenia wychodzące, najlepiej jeszcze tylko na konkretne hosty) – nie uchroniłby co prawda systemu przed samym atakiem, ale wrzucony malware nie byłby w stanie się skomunikować ze światem zewn. Do tego selinux i nawet z podatnym bashem znacznie ciężej skorzystać z takiego hosta…

Twój komentarz

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

RSS dla komentarzy: