16:02
5/3/2012

Formularz aktualizacji klucza publicznego w serwisie GitHub zawierał podatność, którą wczoraj jeden z użytkowników wykorzystał do przejęcia kontroli nad hostowanym na GitHubie projektem Ruby on Rails. Atakujący mógł równie dobrze przejąć każdy inny projekt z GitHuba…

Na czym polega błąd “mass assignment”?

Podatność, którą do ataku wykorzystał Egor Homakov to znany od lat problem nazywany mass assignment). Ten występujący w Railsach błąd programistyczny, przypomina trochę PHP-owe problemy z “register globals”.

Błąd pozwala na nieautoryzowaną zmianę wartości pewnych parametrów obiektu. W skrócie, chodzi o sytuację, w której programista używa metody update_attributes(params[:foo]) bez uprzedniej definicji atrybutów, które mają podlegać tzw. masowemu przypisaniu przy pomocy attr_accessible.

Co zrobił Homakov?

Homakovowi udało się za pomocą w/w podatności dodać swój klucz publiczny do projektu Rails, czyli krótko mówiąc stał się administratorem projektu. Mógł robić wszystko; kasować pliki, modfikować je, itp. Na szczęście wykonał tylko jeden zabawny commit o treści:

rails-commit

Nieautoryzwany commit do Railsów

Reakcja GitHuba

GitHub natychmiast po wykryciu ataku unieważnił “wstrzyknięty” klucz publiczny i zawiesił konto atakującego. Załatano także podatność. Obecnie trwa analiza logów.

Dziura pomimo użycia frameworka??? Niemożliwe!!!

Powyższe zdarzenie to wspaniałe ucieleśnienie jednego z argumentów, którymi posługujemy się w dysputach z pewnymi siebie programistami w trakcie wykonywanych przez nas testów penetracyjnych aplikacji webowych. Często bowiem zdarza się, że developerzy jeszcze przed startem testów penetracyjnych zadziornie stwierdzają:

my korzystamy z frameworku X, on za nas myśli w kwestiach security, nie ma szans, że znajdziecie w naszym kodzie jakiś błąd!

Niestety, praktycznie zawsze pomimo wykorzystania superframeworku, błędy się znajdują… warto mieć świadomość tego, że o ile framework znacząco wspiera tworzenie bezpieczniejszego kodu, to niestety nie rozwiązuje automagicznie wszystkich problemów z tzw. “bezpieczeństem” aplikacji.

PS. Część z tych nierozwiązywalnych frameworkiem problemów poruszamy na naszym szkoleniu z Ataku i Ochrony Webaplikacji — na termin marcowy pozostało jeszcze kilka miejsc, a na hasło GitHub przygotowaliśmy zniżkę ;)

Przeczytaj także:

34 komentarzy

Dodaj komentarz
  1. Zapłacili mu za powiadomienie o tym błędzie, tak jak prosił? :P

    • @Spiewak
      Masz przecież białe^W#CCCCCC na #121315, że zapłacili:
      “GitHub natychmiast po wykryciu ataku unieważnił “wstrzyknięty” klucz publiczny i zawiesił konto atakującego. Załatano także podatność. Obecnie trwa analiza logów.”

    • Blokada konta i pewnie pozwem w sadzie ;)… Gdyby powiedzial im co jest nie tak zamiast ich haczyc moze by i mu zaplacili. Watpie ale mimo to byloby lepiej dla niego…

      Gdyby do mnie przyszedl kolo i powiedzial “sluchaj jestem dobry i chce przeprowadzic audyt bezpieczenstwa Twojego serwera / sieci / whatever” usiadlbym z nim i patrzyl mu na rece i sluchal co do mnie mowi. Gdyby przyszedl do mnie i powiedzial “Hacknalem ci serwer – zaplacisz mi za audyt bezpieczenstwa?” ochrona wyniosla by go z budynku po tym jakby go okopala w windzie ;)… a potem prawnicy zajeli by sie jego sprawa…

      Pozdrawiam.

      Andrzej

    • @AndrzejL właśnie dlatego totalnie nie ma sensu zabawa w white hata. zamiast zdawać się na łaskę twojego widzimisię lepiej puścić ci z dymem pół infrastruktury, co powinno skłonić cię do rozmyśleń nad stanem zabezpieczeń.

      oczywiście przejaskrawiam, ale mam nadzieję, że przesłanie jest jasne.

    • a bug bounty nie brzmi rozsądnie?

    • znaczy: wpadnij do nas, zapłacimy ci za tego exploita (a potem obijemy twarz w windzie i wezwiemy dzielnicowego)? :)

    • @asq pokaż mi przypadek, w którym FB czy Google tak zrobiło.

    • ja się odnosiłem do case’a opisanego w komentarzu. bug bounty jest ok, każde podejście jest ok, jeśli reguły są jasne dla zgłaszającego *przed*. nie ma chyba takiej firmy w PL, która by publikowała jakąś politykę dot. zgłoszeń incydentów (cert.pl to nie firma).

    • W skrócie: koleś zgłosił buga (w railsach). Bug został zamknięty (czytaj: olany). Koleś zademonstrował wykorzystanie buga w praktyce. W githubie zablokowali mu konto, sprawdzili czy nic innego nie zostało zrobione, po czym konto zostało odblokowane. Luka poprawiona.

      Zamiast chrzanić w komentarzach o sądach, audytach i obijaniu mord, przeczytalibyście źródła newsa.

    • @AndrzejL:
      Skopanie ryja to należy się jedynie takim jak ty.

    • @Kerai: masz jakiś powód potwierdzający twoją tezę czy trollujesz, bo nic lepszego nie potrafisz?

    • Trochę więcej szczegółów:
      Egor Homakow jakiś czas temu zgłosił ten problem w projekcie Rails (tak naprawdę to nie jest to błąd frameworka, poprostu domyślnie wszystkie atrybuty mogą być użyte przy mass assignment i można je wrzycić na czarną listę jeżeli są sensitive) i chciał żeby domyślnie wszystko było na czarnej liście. Po kilku dniach core-team uznał że to nie jest potrzebne i zamknęli ticket, traktując go trochę jak trolla.

      Egorowi nie spodobało się to, więc zaczął działać. Zorientował się że programiści GitHuba nie wrzycili niektórych wrażliwych atrybutów na czarną listę i zaczął się bawić (m.in. pisał komentarze z datą w przyszłości, w przeszłości, usuwał tickety, pisał komentarze jako DHH – twórca Railsów). W międzyczasie powiadomił GitHub o dziurze, po czym po (bodajże) jednym dniu, kiedy dziura nie była jeszcze załatana, dodał swój klucz SSH do użytkownika Rails. Uzyskał przez to prawa m.in do całego projektu Rails, a następnie wykonał ww. commit. Po godzinie z kawałkiem Zach Holman z GH spatchował kod w produkcji, łatając dziurę.

      Konto GH Egora zostało zawieszone, po kilku godzinach jednak zostało przywrócone.

      Parę godzin po całym zajściu M. Koziarski wykonał ciekawy commit do Rails: wyłączył w configu nowej aplikacji opcję aby wszystkie atrybuty były dostępne – teraz aby korzystać z mass assignment będzie trzeba je dodawać do white list. Oprócz tego jednak dodał też kod do generatorów modeli, tak że wszystkie wygenerowane pola będą automatycznie na białej liście – różnica jest taka, że po prostu w kodzie będziemy widzieli które pola mogą być użyte przy mass assignment.

      Ciekawostka: za trochę ponad miesiąc paru ludzi z Rails core teamu oraz Zach H. z GitHub’a przyjadą do Krakowa na konferencję, więc będzie możliwość dowiedzenia się trochę więcej :)

  2. Railsy dostały już patch włączający `attr_accessible` domyślnie.

  3. Czy bardziej to wina? GH czy twórców RoR?

    • Jak zawsze, developera, który nie wiedział, testera, który przeoczył i project managera, który dopuścił ;)

    • Jest to zdecydowanie błąd programisty. Railsy są bezpieczne, możecie spać spokojnie :]

  4. Człowiek robi darmowy audyt a oni mu konto blokują. GitHub logic.

  5. dobrze ze go nie podali na policje

  6. Dokładnie tego typu dziury pokazywałem na niedawnym OWASP jako jedne z najpowszechniejszych w RoR:

    http://prezi.com/zn6ixh6n4obl/bad-coding-with-ruby-on-rails/

    • Prezi ssie.

    • Poproszę prezentację która nie wymaga uruchamiania niewolnego kodu na głównym CPU. (hint: Fla$h)

  7. A ten Pan ma taki tatuaz :)
    http://homakov.blogspot.com/2011/07/octocat-tattoo.html

    • Chyba wolałbym coś ze Space Invaders :)

    • Z henny. Peace.

  8. Hmm, dokładnie taka sama podatność jest w wielu frameworkach dla Javy. Na podstawie przesłanych parametrów automatycznie wypełniane są pola obiektu. Jeżeli atakujący jest w stanie określić nazwy pól, które nie są widoczne w formularzu to może przypisać im wybrane wartości.

  9. Przypomina mi to stwierdzenia wielu osób w stylu “Wykorzystuję w mojej aplikacji PDO, nie ma możliwości przeprowadzenia na niej SQL injection” a potem po audycie 500 podatności :) Nie użyta technologia a rozum i zdrowy rozsądek pozwalają na tworzenie (w miarę) bezpiecznego oprogramowania.

  10. Istnieją frameworki, w których można przyjąć całą listę parametrów, a można wskazać white list, black list lub obie. Nie ma czegoś takiego w RoR?

  11. a mnie ciekawi czy czasem nie bylo wczesniej ludkow ktore zmienily kod w roznych projektach – tylko bez informowania kogokolwiek… zobaczymy co wykaza analizy logow…

  12. W takim razie cieszę się, że Symfony2 ma już taki audyt kodu za sobą ( http://symfony.com/blog/symfony2-security-audit ), może dzięki temu nie będzie problemów w przyszłości. :)

    • Przeczytaj wpis ponownie. Dziękuję.

  13. @rightDriver, oczywiście, że jest, coś takiego w ROR, nazywa się attr_accessible (tylko zdeklarowane pola będą zapisane).

    Po prostu ktoś z githuba mógł już dawno temu dodać przykładowe pole (np. public_key) do ‘białej listy’.

  14. Ta blodada konta mnie serdecznie ubawila. Zachowali sie jak ratlerek chcacy pogryzc nogawki spodni.
    @AndrzejL to jest tylko twoj scenariusz tej historii. Niektorzy ludzie pokroju hexa maja problem z komunikacja interpersonalna. Nie oceniaj pijanego skoro nie wiesz, dlaczego sie upil.

    PS. @Piotr Konieczny. “w/w” juz nie piszemy. Od konca lat ’90 piszemy “ww.”. ;-)

    Pzdr

  15. oto takiego maila od nich dostałem: A security vulnerability was recently discovered that made it possible for an attacker to add new SSH keys to arbitrary GitHub user accounts. This would have provided an attacker with clone/pull access to repositories with read permissions, and clone/pull/push access to repositories with write permissions. As of 5:53 PM UTC on Sunday, March 4th the vulnerability no longer exists. While no known malicious activity has been reported, we are taking additional precautions by forcing an audit of all existing SSH keys. # Required Action Since you do not have any SSH keys associated with your GitHub account, you were not at risk, and no action is required. # Status We take security seriously and recognize this never should have happened. In addition to a full code audit, we have taken the following measures to enhance the security of your account: – We are forcing an audit of all existing SSH keys – Adding a new SSH key will now prompt for your password – We will now email you any time a new SSH key is added to your account – You now have access to a log of account changes in your Account Settings page Sincerely, The GitHub Team

  16. Taa… wyciek 4.03, news 5.03, a mail od GitHub-a siódmego wieczorem: A security vulnerability was recently discovered that made it possible for an attacker to add new SSH keys to arbitrary GitHub user accounts. This would have provided an attacker with clone/pull access to repositories with read permissions, and clone/pull/push access to repositories with write permissions. As of 5:53 PM UTC on Sunday, March 4th the vulnerability no longer exists. While no known malicious activity has been reported, we are taking additional precautions by forcing an audit of all existing SSH keys. # Required Action Since you have one or more SSH keys associated with your GitHub account you must visit https://github.com/settings/ssh/audit to approve each valid SSH key. Until you have approved your SSH keys, you will be unable to clone/pull/push your repositories over SSH. # Status We take security seriously and recognize this never should have happened. In addition to a full code audit, we have taken the following measures to enhance the security of your account: – We are forcing an audit of all existing SSH keys – Adding a new SSH key will now prompt for your password – We will now email you any time a new SSH key is added to your account – You now have access to a log of account changes in your Account Settings page Sincerely, The GitHub Team

Twój komentarz

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