Botnet oparty o sieć XMPP
Jak wygodnie i nowocześnie zaprojektować całkowicie zdecentralizowany botnet którym łatwo zarządzać? Standardowe struktury - boty "żyjące" na irc, które dodatkowo się porozumiewają w wewnętrznej sieci (np. opartej o ssh) i w ten sam sposób kontrolowane - to staroć. Owszem, w niektórych wypadkach jest to wygodne, tylko za jaką cenę? Po pierwsze, wszystkie boty muszą być połączone z jedną siecią irc (przez huby, leafy, bezpośrednio, przez własne proxy między sieciami - obojętnie) tak by właściciel mógł tam wejść i walnąć !ddos yahoo.com ;-). Po drugie, tworzenie i posiadanie botnetu jest z reguły i definicji nielegalne, dlatego też boty trzeba w miarę często przenosić do innej sieci (z reguły jest to jakiś mały i lekki ircd instalowany na niektórych zainfekowanych komputerach) co wiąże się z niewygodą, czasową niedostępnością części botnetu, problemami z synchronizacją itd. Oczywiście można całość zautomatyzować, jednak należy pamiętać by następne generacje botów również kierować do nowych sieci, a nie tych sprzed trzech miesięcy.
Wpadłem ostatnio na pomysł jak rozwiązać część problemów. Tak patrzyłem na swoją listę PSI, patrzyłem i w końcu wymyśliłem - botnet działający po sieci Jabber! Tak jest - dokładnie. Nie wiem czy istnieje jakakolwiek sieć botów tego typu. Jak się temu przyjrzeć, to sieć Jabber jest ku temu wręcz stworzona. Po pierwsze, otwartość sieci - każdy może sobie dołączyć własny serwer do sieci i wszystkie inne bardzo chętnie będą współpracować. O ile eksperyment z otwarciem sieci IRC to było kompletne fiasko, o tyle w sieci Jabber jest to świetne rozwiązanie - wiadomo, jeden chce mieć host taki, inny host taki. Drugim istotnym elementem specyfikacji tej sieci jest, wydawałoby się, banalna sprawa: zasób. Taki sobie tekst który zwykle określa z jakiego klienta korzystamy. Na szczęście można to sobie chyba dowolnie zmienić. A dlaczego to takie istotne, już za chwilę. Trzecim elementem, nie mniej istotnym, jest to, że nasza lista kontaktów jest trzymana wyłącznie po stronie serwera, a my natychmiast się dowiemy o fakcie dodania nas do czyjejś listy kontaktów. Ostatnim elementem który decyduje o łatwości i wygodzie tego rodzaju sieci jest po raz kolejny otwartość - tym razem w sensie GNU-sowskiej wolności: każdy z łatwością znajdzie RFC dotyczące sieci Jabber, każdy może stworzyć klienta opierając się na doskonałej dokumentacji, wielu różnych bibliotekach czy wreszcie lepszych czy gorszych tutorialach.
Dlaczego tak ważna jest dla nas ta banalna, trywialna rzecz jaką jest zasób? Niektórzy się pewnie domyślają - decentralizacja! Łącząc razem cztery fakty które wymieniłem, ujrzymy idealne połączenie, całkowicie i doskonale niewidoczne dla osób postronnych.
Otóż każdy bot niech będzie tak naprawdę prostym, podstawowym serwerem Jabbera. Każdy niech umożliwia logowanie do sieci, ustawianie swojego zasobu, opisu (to się może przydać później do innych celów, np. identyfiacja podsieci, wersji bota), pisanie i odbieranie wiadomości. Należy jednak zwrócić uwagę, że logowanie nie będzie logowaniem w sensie jaki znamy ze zwykłych serwerów - logujemy się na swoje konto, bierzemy swoją listę kontaktów. Tutaj logowanie będzie polegało wyłącznie na autoryzacji do użycia sieci botów - autoryzacja jako inny bot lub jako właściciel, gość czy jakikolwiek inny poziom autoryzacji. Jeśli bot-serwer stwierdzi że autoryzacja się nie powiodła - delikwent jest rozłączany i po krzyku. Nie zobaczy ile jest botów w sieci, nie pozna ich hostów, nie dowie się NICZEGO. Z zewnątrz taki bot będzie zwykłym serwerem Jabberowym który nie umożliwia rejestracji kont i do którego nie mamy loginu. Jeśli jednak bot-serwer przyjmie kombinację login/hasło - klient otrzyma pełny roster - nie swój, ale globalny. Każdy klient będzie używał jednego i tego samego rostera - jeden klient doda kontakt, dodany zostanie do listy innego klienta. Oczywiście w tym momencie trzeba się zatrzymać i zaimplementować podział na grupy użytkowników, ale to jest zadanie domowe ;-).
Każdy bot powinien być też jednocześnie klientem Jabbera. Niech po pierwsze, łączy się sam ze sobą, po drugie próbuje się łączyć ze wszystkimi osobami z listy. Wracając do ZASOBU - tam ma być po prostu port na którym działa serwer w danym komputerze. W ten sposób bot, łącząc się z samym sobą otrzyma, w zależności od implementacji, sytuacji, przemyśleń programisty itd: listę osób które mają go w swoim rosterze, listę osób które on miał poprzednio w rosterze. W zależności od liczebności botnetu, listy będą się często pokrywać w np. 99% - to nic. Wystarczy to odpowiednio odfiltrować, połączyć się z jednym z botów które są dostępne - otrzymując w ten sposób jego roster (a on się połączy z nami - otrzyma nasz roster). W ten sposób, po pewnym czasie, wszystkie boty będą połączone ze wszystkimi - niekiedy bot będzie wyłącznie klientem do innych botów-serwerów (bo jest np. za firewallem), niekiedy będzie jednocześnie serwerem dla innych i klientem u innych. Losowe wartości portów są z jednej strony zaletą, z innej wadą. Wadą jest to, że żaden zewnętrzny serwer się z nami nie połączy, bo będzie szukał standardowego portu serwera. Można zatem zastosować standardowy port w pierwszych dniach, godzinach, minutach? działania sieci, natomiast po wstępnej synchronizacji pierwszych botów - ustawić porty na losowe wartości. Można też tak zrobić że bot będzie się łączył np. tylko z co dziesiątym serwerem z listy - losowo. Bardzo wiele rzeczy zależy tylko od inwencji programisty, im dłużej piszę tym więcej mam pomysłów.
Taka struktura sieci oznacza całkowitą i idealną decentralizację. Oczywiście, przy samym starcie sieci należy podać jakiś publiczny JID z którym mogą się komunikować by otrzymać roster (np. założone konto z jakimś hasłem/loginem). Po kilku dniach, gdy sieć się rozrośnie i zsynchronizuje, konto to będzie można zamknąć. Później, znając choć 2-3 hosty na których działa serwer (i nie jest filtrowany), następna generacja botów będzie się już z nimi łączyła, nie z publicznymi sieciami, więc nie musimy się obawiać o Gniew Admina (tm) :-) Przy okazji - jeśli gdzieś na drodze pakietów stanie firewall, IDS czy cokolwiek w tym guście - prawdopodobnie uzna nasze pakiety za zwykłą Jabberową transmisję danych i je radośnie przepuści (do czasu, oczywiście).
Należy jednak wziąć pod uwagę że wymienione tu zalety i sposoby mogą szybko stać się wadami, jeśli ilość botów podłączonych w obrębie konkretnego botnetu przekroczy jakąś wartość krytyczną. Wtedy może się zdażyć że nowy bot, próbując się łączyć, padnie ofiarą DDoS reszty sieci - po prostu nagle nastąpi informacyjny BOOM - inne boty, widząc obecność nowego "brata" spróbują się z nim połączyć by zsynchronizować rostery. Także mając dwa różne botnety, można przez nieuwagę doprowadzić do katastrofy, dodając kontakt bota z drugiej sieci do rostera bota z pierwszej. Wtedy oba botnety zaczną się zasypywać listami kontaktów, wizytówkami itd. Myślę że tego typu implementacja, dzięki której każdy bot byłby połączony z każdym bezpośrednio, boty by się wymieniały po dosyć wymagającym pod względem transferu protokole opartym o XML, sprawdzi się jedynie w stosunkowo niewielkich sieciach, liczących średnio 20-30 komputerów jednocześnie podłączonych. Myślę że to nie jest problemem - taka ilość oznacza łącznie ok. kilkanaście gigabajtów pamięci, kilkanaście terabajtów miejsca na dyskach, kilkadziesiąt GHz mocy procesorów i kilkunasto-kilkudziesięcio megabitowe łącze. Do prywatnych celów to więcej niż można sobie wymarzyć. A botnetów można mieć kilka, kilkanaście, ile dusza zapragnie. Co więcej, na upartego, można te małe sieci łączyć razem programami-kontrolerami - łączą się ze wszystkimi sieciami ale nie wymieniają się rosterami, nikt się z nimi nie próbuje łączyć itd. Stosując tą technikę, można stworzyć jedną, dwie... N niewidzialnych warstw które umożliwią zarządzanie wszystkimi komputerami jednocześnie.
Jak wiadomo, protokół XMPP polega na odpowiednio sformatowanych dokumentach XML. Z jednej strony to jest niesamowita wygoda, łatwość i elastyczność podczas pisania oprogramowania. Z drugiej strony, format ten jest 2-3 razy bardziej transferożerny niż sieci oparte o przesyłanie danych typowo binarnych. To z kolei oznacza, że w miarę możliwości należy boty połączyć również innym protokołem, najchętniej właśnie binarnym, dobrze też jeśli obsługuje szyfrowanie i kompresję danych. Idealne będzie otwarcie dodatkowego, zapasowego kanału "szybkiego ruchu", najlepiej imitującego inny znany protokół lub też nawet go używający - np. SSH. O ile niekoniecznie musimy tego używać do wszystkiego (bo w końcu po to tworzymy oprogramowanie wyglądające i działające jak sieć Jabber by używać wygodnego klienta którym by można siecią zarządzać, z każdego miejsca, choćby i przez komórkę) - nadal implementacja zapasowego transportu jest mile widziana. Może na przykład krytyczne momenty powinny być obsłużone tym protokołem - momenty typu Burst kilkuset kontaktów do wszystkich z listy? Może powinno być to użyte gdy padnie hasło "zwijamy się"? To już inna historia...
W następnych odcinkach serii "do zobaczenia w sądzie", postaram się opisać jak to wyszło w praktyce, jak się zabezpieczyć przed Złem, czyli kradzieżą sieci (haha - zbudować botnet i dać go sobie ukraść :-)) i może wymyślę i spłodzę jakiś wygodny system aktualizacji.
ps. Nie lubię ani spamerów, ani idiotów atakujących byle jakie strony z byle powodu. Dla mnie botnet to po prostu dostęp do większej mocy obliczeniowej, nie sposób zemsty, ot co.
pps. Terminów "Jabber" oraz "XMPP" używałem zamiennie, wiadomo o co chodzi.
wada jest taka, ze bot jest grubszy o kilkadziesiat KB, bo zeby polaczyc sie z IRCem wystarcza tylko proste sockety.
Do Jabbera też, tylko trzeba sobie napisać małą i wygodną bibliotekę. Standardowe, ogólnodostępne, to owszem, może być spory balast - ale one są przecież ukierunkowane na bycie użytecznymi, nie małymi. Poza tym, przy dzisiejszych łączach i dyskach te kilkadziesiąt kilobajtów balastu to żaden problem - wystarczy dobry preloader, który ściągnie najnowszą wersję i ją zainstaluje. Przy okazji może ją po drodze dodatkowo szyfrować, hashować itd - prawie jak polimorfia ;)
puppy - wirus, bot, to wszystko musi byc male i dzialac w ukryciu, a nie zajmowac tyle zasobow co okienkowy program.
Ależ wiem, wiem, tylko że jedna sprawa to rzeczywisty rozmiar, a inna sprawa rozmiar który widać ;) ostatnie zdanie było zresztą jedynie takim przypomnieniem - jak za duże, można to rozbić na dwa - preloader może zajmować kilkanaście kilobajtów i umożliwić instalację "pełnego" oprogramowania. Co nie zmienia faktu, że prawdą jest - bot powinien mieć 10-30 kb (tak na mój gust) a w systemie się w ogóle nie pojawiać. Jedyne co mnie naprawdę martwi to "bloat" całego protokołu, gdzie wysyłając jedno słowo, tak naprawdę wysyłamy całą serię znaczników XML..
puppy - 10-30 ? jak masz skryptowy jezyk z parserem po drugiej stronie to nawet w 5-6 da sie zmiescic
Trochę ciężko budować taki "prawdziwy" botnet w oparciu o takie języki, szczególnie że tak naprawdę botnety celują w znakomitej większości w system Windows, w którym nie uświadczysz żadnego poważnego języka zaraz po instalacji (Hm. muszę sprawdzić czy ten VBS ma jakiś dostęp do socketów, ew. możliwość ładowania DLL). Oprócz tego kompilacja umożliwia lepsze "ukrycie" kodu programu i dostęp do nieco niższych warstw systemu.
puppy - zawsze mozna infekowac serwery botami w PHP :D
a co do VBS to fuckt, trzeba by sie zainteresowac.
No ba, były czasy że miałem po 10-15 botów serwerowych - software w PHP :) zabawa fajna (małe IRC-war w prywatnej sieci, taki Codewar - kto napisze lepszego "wojownika" lub też "armię wojowników", hehe), Raz nawet jeden admin wpadł na IRC pogadać (nie złościł się ani nic, choć bota usunął dziad jeden) :)
VBS z tego co pamiętam obsługuje socety i jest do tego dość zgrabny i prosty w użyciu ocx.
Jednak kur*%#, rozumiem robienie botnetu na ircu (lans, gangsta flo et cetera), no ale używanie XMPP to trochę przerost formy nad treścią, chociaż może to być dość ciekawa zabawa, dla zabawy.
"Dla mnie botnet to po prostu dostęp do większej mocy obliczeniowej, nie sposób zemsty, ot co."
Chyba większej puli ip, nie znam ani jednej osoby która liczyła coś na botnecie :). NO ale władza dla samej władzy to piękna rzecz ;).
W ogóle to przypomniały mi się stare czasy i się wzruszyłem.
wh1t3en - po prostu o latwiejsza kontrole chodzi, bo mozesz polecenia z poziomu IRCa wydawac
D4rky, rozumiem robienie botnetu na IRCu! No ale na XMPP to już nie takie przyjemne.
wh1t3en - no juz bardzo nie, chyba, ze z serwerami koordynujacymi, ale to tez troche bez sensu. Ot' najlepiej stary dobry IRC
Łączenie wszyscy z wszystkimi - nie jest to dobry pomysł właśnie z uwagi na użycie łącza. Prędzej co któryś bot, ten o odpowiednich warunkach (łącze, brak firewalla, być może stosunkowo długi uptime) jako serwer, reszta jako klienci.
Użycie protokołu jabber potępiam, bo może doprowadzić do jego blokowania. Za to można użyć czegoś działającego analogicznie. Plus szyfrowanie SSL. Plus działanie na standardowych portach WWW, nie losowo - wydaje mi się, że większa dostępność będzie.
Tyle luźnych szybkich przemyśleń.
@rozie: Dlatego botnet by trzeba podzielić na pod-sieci po kilka-kilkanaście komputerów; i oczywiście nie trzeba używać takiego akurat protokołu - można samemu stworzyć taki, który zawiera wymienione przeze mnie cechy (czy może raczej - botnet który to realizuje).
A taki Jabberowy botnet również umożliwia w miarę łatwą kontrolę - można używać serwerów kontrolujących; wewnętrznej pod-sieci (wtedy wiadomość do któregoś bota byłaby automatycznie tą siecią wysyłana, taki broadcast); można komendy wydawać statusami; et cetera, to tylko kwestia wyobraźni.
IRC, owszem, fajny, tylko gorzej jak chcesz przenieść botnet na inny serwer - zabawa przednia :-)
Jeszcze trochę nad tym pomyślę i napiszę jakiś prototyp.
Zastanawia mnie jak zamierzasz chronić swój botnet przed przejęciem. Z tego co wyczytałem to zamierzasz udostępniać całą listę wszystkim komputerom w podsieci. Wówczas wystarczy że przejmie się jeden z tych komputerów i już ma się listę pozostałych komputerów w sieci. Utrata kilkunastu komputerów nie jest miła szczególnie gdy tak ciężko jest je dzisiaj zdobyć.
Wart zauważenia jest również fakt ze z jabbera korzystają głównie informatycy lub osoby mające jako takie pojęcie o komputerach. Łatwiejszym celem wydaje się siec gg. W internecie znaleźć można opis protokołu, jest nawet implementacja prostego serwera że o klientach nie wspomnę.
Zaczynając od końca – Wiem że można używać sieci gg (co byłoby zresztą lepsze, bo mniej bajtów zjada niż protokół po XML-u) jednak to, kto używa danej sieci jest bez znaczenia, przecież użytkownik by nie wiedział o zombie na jego komputerze. Druga sprawa, moim targetem są bardziej serwery, wolę 10 serwerów które będą stabilne, zawsze dostępne i z reguły na lepszym łączu oraz lepszym sprzęcie, niż 1000 komputerów które mi się będą ciągle rozłączać.
Ochrona? Sposobów jest wiele, chyba tyle ile botnetów w całej historii. Mi się najbardziej podoba … trzymanie botnetu wyłączonego. Po co utrzymywać aktywne łącze, śmiecić w ew. logach itd? Lepiej botnet trzymać zawsze wyłaczony. Jeśli będzie potrzebny, zawsze można właczyć tyle komputerów ile trzeba (w końcu to serwery :))
Botnetu takiego nie zrobiłem, bo ostatecznie wynik był zbyt toporny i niewygodny, zostaję przy komunikacji własnym, szyfrowanym protokołem, z keyringiem rozproszonym po sieci, aktualizowanym codziennie; do tego trzeba tylko mieć mały program zarządzający, działający jako bot irc (na localhost) i wsio gra :)
Innym ciekawym, acz nierozważnym sposobem jest ten stosowany przez Storma – jak ktoś mataczy w sieci, trzeba go zbombować :D
A tekst miał głównie służyć głównie jako przechowalnia pomysłów, choć może też ktoś jeszcze na nim zyska :)