Zauważyłem, że pojawia się to podczas logowania do systemu. Opis błędu znalazłem na stronie http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555625. Wystarczy otworzyć plik /etc/default/ssh i zamienić opcję SSHD_OOM_ADJUST=-17 na SSHD_OOM_ADJUST=.Jul 29 08:13:59 borekfalecki sshd[3844]: error writing /proc/self/oom_adj: Operation not permitted
czwartek, 29 lipca 2010
Błąd poczas logowania
Ostatnio na moim serwerze zainstalowałem Snorta wraz z całym oprogramowaniem wspomagającym sprawdzanie logów. Oprogramowanie Ossec zaczęło wysyłać mi na maila non stop informacje o tym, że w /var/log/auth.log pojawia się informacja tego typu:
środa, 28 lipca 2010
Błędy w serwerach i stronach rządowych
Ostatnio dużo piszę się o problemach z serwerami i stronami WWW instytucji rządowych. Zastanawiałem się nad tym problemem i rozmyślałem dlaczego tak jest, że tak ważne miejsca w Sieci jak te należące do włodarzy naszego państwa są tak źle zabezpieczone. Doszedłem do wniosku, że problemem jest sam sposób myślenia ludzi, którzy zatrudniają osoby od obsługi serwera czy pisania web aplikacji. Uważam, że dla rządzących miarą ludzkich umiejętności jest posiadane wykształcenie. W momencie gdy pojawia się oferta pracy na webmastera aplikacji internetowych czy administratora sieci, pierwsze miejsce mają ludzie z posiadanym wykształceniem, a nie ci, którzy mają duże doświadczenie lecz nie mają wykształcenia. Jednak w polskich uczelniach nie uczy się jak radzić sobie z problemami bezpieczeństwa komputerowego. Pomimo, że nasi studenci są świetnymi programistami to wydaje mi się, że w większości przypadków nie mają oni zbyt dużego doświadczenia w obronie przed buffer overflow czy SQL injection. W dobie informatyzacji społeczeństwa jest to bardzo poważna sprawa. Zwłaszcza mając na uwadze możliwość przeprowadzania głosowania drogą elektroniczną. Znam wielu ludzi, którzy nie posiadają wykształcenia a są wysokiej klasy specjalistami od administrowania czy znajdowania błędów w oprogramowaniu. Niech zmieni się zatem sposób myślenia rządzących bo w dobie zagrożeń cyberatakami na infrastrukturę rządową może to być poważna wada.
poniedziałek, 26 lipca 2010
Problem z ClamAV - aktualizacja
We wczorajszym poście (http://seprob.blogspot.com/2010/07/problem-z-clamav.html) napisałem o pewnym problemie z ClamAV. Wydawało się, że go rozwiązałem jednak dzisiaj podczas uruchamiania ClamAV, pojawił się ten sam monit. Solucja, którą opisałem już nie działała. Lecz znalazłem inny sposób na rozwiązanie tego problemu:
# echo "deb http://volatile.debian.org/debian-volatile lenny/volatile main contrib non-free" >> /etc/apt/sources.listPo tym już wszystko powinno śmigać dobrze :)
# apt-get update
#apt-get install clamav
# apt-get upgrade
niedziela, 25 lipca 2010
Sepscan
Prezentują kod bardzo prostego skanera portów mojego autorstwa:
/* SEPSCAN (SEProb's SCANner) - is a ordinary port scanner
* Author: Bartlomiej "seprob" Korpala
* Information about author: http://seprob.damned.pl/
* E-mail: seprob@poczta.fm
*
* Standard compilation: gcc sepscan.c -o sepscan */
#include <stdio.h>
#include <unistd.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <sys/types.h>
#include <string.h>
#include <errno.h>
#include <netdb.h>
#include <time.h>
extern int h_errno; /* Variable in which gethostbyname() function stores information about errors*/
/* error_errno() function give contents of error based on value attributed errno variable and finishes program */
void error_errno(const char *what);
/* error_h_errno() function give contents of error based on value attributed h_errno variable and finishes program */
void error_h_errno(const char *what);
/* error_none() function inform about error and finishes program */
void error_none(const char *what);
main(int argc, char *argv[])
{
int sd; /* Socket descriptor */
int port; /* Number of scanning port */
int help_v; /* Hel variable */
char *n_addr; /* Host address */
struct sockaddr_in in_addr; /* Structure for fulfillment */
struct servent *ss; /* Structure included information from /etc/services file */
struct hostent *sh; /* Structure included information from gethostbyname() function */
int port_tab[26208]; /* Table in which are stored values saying or port is active */
char buf_conn[128]; /* Buffer for data get after telnet connect on give port */
time_t now, now_two; /* Wanted times dor account of period of scanning */
if (argc == 1)
error_none("Bad syntax. More you will get taking davantage --help option of program");
else if (argc == 2)
{
if (!strcmp(argv[1], "--help"))
{
printf("Syntax: %s [Network Address]\n", argv[0]);
printf(" %s --help (Information about usage of scanner)\n", argv[0]);
printf(" %s --about (Information about program)\n", argv[0]);
printf(" %s --more [Network Address] (Give more information about scanning host)\n", argv[0]);
printf(" %s --telnet-conn [Network Address] (Display information which are gotted after telnet connect with active ports\n", argv[0]);
exit(0);
}
else if (!strcmp(argv[1], "--about"))
{
printf("SepScan (Seprob's Scanner) is a network scanner writed by seprob [http://seprob.damned.pl/]\n");
exit(0);
}
else
sh = gethostbyname(argv[1]);
}
else if (argc == 3)
{
if (!strcmp(argv[1], "--more"))
sh = gethostbyname(argv[2]);
else if (!strcmp(argv[1], "--telnet-conn"))
sh = gethostbyname(argv[2]);
else
error_none("Bad syntax. More you will get taking davantage --help option of program\n");
}
else if (argc = 4)
{
if (!strcmp(argv[1], "--more") && !strcmp(argv[2], "--telnet-conn"))
sh = gethostbyname(argv[3]);
else if (!strcmp(argv[1], "--telnet-conn") && !strcmp(argv[2], "--more"))
sh = gethostbyname(argv[3]);
else
error_none("Bad syntax. More you will get taking davantage --help option of program\n");
}
else
error_none("Bad syntax. More you will get taking davantage --help option of program");
if (sh == NULL)
error_h_errno("GETHOSTBYNAME");
n_addr = inet_ntoa(*(struct in_addr *)sh->h_addr_list[0]);
printf("SepScan - Seprob's Scanner by seprob [http://seprob.damned.pl/]\n");
printf("\n");
time(&now); /* Get time from 1th February 1970 */
memset(&port_tab, 0, sizeof(port_tab));
/* Beginning of loop which checks all ports number */
for (port = 1; port <= 26208; port++)
{
memset(&in_addr, 0, sizeof(in_addr)); /* Fulfillment zeros of addr structure */
in_addr.sin_family = PF_INET; /* PF_INET familly address */
in_addr.sin_port = htons(port); /* Convert from host byte order to network byte order */
help_v = inet_aton(n_addr, &in_addr.sin_addr); /* Attribution IP address */
if (help_v == 0)
error_none("Bad address");
sd = socket(PF_INET, SOCK_STREAM, 0); /* Creation of new socket */
if (sd == -1)
error_errno("SOCKET");
help_v = connect(sd, (struct sockaddr *)&in_addr, sizeof(in_addr));
if (help_v != -1)
{
port_tab[port] = 1; /* Give port is active */
ss = getservbyport(htons(port), "tcp");
if (ss != NULL)
printf("%s/%d/%s\n", ss->s_name, htons(ss->s_port), ss->s_proto);
else
printf("unknown/%d/tcp\n", port);
}
close(sd);
}
if (argc == 3 || argc == 4)
{
if (!strcmp(argv[1], "--more") || !strcmp(argv[2], "--more"))
{
printf("\n");
printf("Official name of host: %s\n", sh->h_name);
printf("Type of host address: %s\n", sh->h_addrtype == PF_INET ? "PF_INET" : "PF_INET6");
printf("Aliases:\n");
for (help_v = 0; sh->h_aliases[help_v] != 0; help_v++)
printf("%s\n", sh->h_aliases[help_v]);
printf("List of address:\n");
for (help_v = 0; sh->h_addr_list[help_v] != 0; help_v++)
printf("%s\n", inet_ntoa(*(struct in_addr *)sh->h_addr_list[0]));
}
if (!strcmp(argv[1], "--telnet-conn") || !strcmp(argv[2], "--telnet-conn"))
{
printf("\n");
memset(buf_conn, '\0', sizeof(buf_conn));
for (port = 1; port < 26208; port++)
{
if (port_tab[port] == 1)
{
memset(&in_addr, 0, sizeof(in_addr));
in_addr.sin_family = PF_INET;
in_addr.sin_port = htons(port);
inet_aton(n_addr, &in_addr.sin_addr);
sd = socket(PF_INET, SOCK_STREAM, 0);
if (sd == -1)
error_errno("SOCKET");
help_v = connect(sd, (struct sockaddr *)&in_addr, sizeof(in_addr));
if (help_v != -1)
{
help_v = read(sd, &buf_conn, sizeof(buf_conn));
if (help_v == -1)
error_errno("READ");
printf("After telnet connect on %d port I have received following information:\n", port);
printf("%s\n", buf_conn);
printf("\n");
memset(buf_conn, '\0', sizeof(buf_conn));
}
}
}
}
}
time(&now_two);
printf("\n");
printf("Time of scanning: %.2f\n", difftime(now_two, now));
printf("Scanned %d ports on host %s\n", port, n_addr);
return 0;
}
void error_errno(const char *what)
{
fprintf(stderr, "%s: %s\n", what, strerror(errno));
exit(1);
}
void error_h_errno(const char *what)
{
fprintf(stderr, "%s: %s\n", what, hstrerror(h_errno));
exit(1);
}
void error_none(const char *what)
{
fprintf(stderr, "ERROR: %s\n", what);
exit(1);
}
Praca maturalna
W tym poście chciałem zamieścić moją pracę maturalną na temat "Teksty piosenek rapowych - mowa potoczna czy poezja śpiewana? Zanalizuj wybrane teksty".
1. Wersja pełna
2. Wersja skrócona
1. Wersja pełna
1. Czym jest rap? Rap jest częścią kultury zwanej hip hopem do której zalicza się właśnie rapowanie, break dance, DJ-ing oraz grafitti. Powstał w latach siedemdziesiątych 20. wieku w Nowym Jorku. Za pioniera hip hopu uważany jest DJ Kool Herc. W Polsce zaś pionierami byli Liroy, Kaliber 44 oraz Wzgórze Ya-Pa-3. Charaketerystyczne dla rapu jest przede wszystkim to że teksty są rymowane do jednostajnego rytmu czyli beatu. Wywodzi się z muzyki bluesowej i jazzowej. 2. Charakterystyka tekstów rapowych Jak już wspomniałem teksty rapowe charakteryzuje to że występują w nich rymy śpiewane do beatu. Pozatym nie ma innych reguł. Można dowolnie "płynąć" po beat'cie. Piosenki te są przykładem mowy potocznej pełnej slangowych określeń i którą to mowę zwykle mogą zrozumieć ludzie, którzy z hip hopem mają dużo wspólnego lub żyją wsród ludzi, którzy komunikują się między sobą za pomocą slangu. Teksty te zawierają w sobie mnóstwo ekspresji, wulgaryzmów oraz metafor. Wszystko zależy od tego do jakiej grupy ludzi chce dotrzeć raper. Rymują oni o różnych rzeczach począwszy od aktualnej sytuacji politycznej, przez historię swojego przyjaciela aż po przykładowe imprezy jakie miewają. Teksty te twórzą zwykle monolog czyli tekst mówiony w stylu artystycznym. 3. Analiza wybranych tekstów utwórów muzycznych a) utwór Kaliber 44 - Plus i minus jako przykład psychorapu Kaliber 44 powstał w roku 1994 w Katowicach a jego członkami byli Abradab, Joka, Magik oraz DJ Feel-X. Byli oni jednymi z pionierów rapu w Polsce. Na pierwszej płycie o nazwie "Księga tajemnicza. Prolog" zaprezentowali styl zwany psychorapem. Styl ten charakteryzuje się mocno tajemniczą atmosferą w utworze oraz mocno ekspresyjnymi tekstami, które podczas wymowy trudno zrozumieć. Sprawia to że słuchacz popada w silny stan refleksji i utożsamia się z raperami. Biorąc pod uwagę zespół Kaliber 44 to sposób wypowiadania się na ich pierwszej płycie jest idiolektem. Utwór "Plus i minus" opowiada o przeżyciach Magika jakie towarzyszyły mu przed udaniem się na sprawdzenie wyników na obecność wirusa HIV. Plus i minus oznacza odpowiednio wynik pozytywny oraz negatywny. Podmiotowi lirycznemu towarzyszył wtedy wielki strach co świetnie wyraża w swojej piosence. Miał wtedy 18 lat. Układy rymów w pierwszej zwrotce tekstu to głównie rymy okalające, np. "Czas sie bać, nadszedł czas, sprawdź to, sprawdź" lub "Ale strzał, ile ja bym dał, mieć znów chciał" lecz występują tutaj również najcześniej spotykane rymy parzyste, np. "Idę tam, idę sam w tą czarną chwile. Tyle myśli w sekund tyle". W drugiej zwrotce pojawiają się również podobne układy ale w trzeciej występuje układ przeplatany, np. "I - dryn - telefon dzwoni i jak co dzień. Może tym razem wreszcie sie dowiem. Dziś nadszedł ten dzień, dziś nadszedł dzień. Może będzie mym najlepszym dniem, a może nie". Jeżeli chodzi o refren to jest to przykład układu parzystego. W tekście możemy napotkać przykład słownictwa ekspresywnego dodatniego, np. "doktorku", które odnosi się do doktora badającego Magika. Dopiero w drugiej zwrotce zwraca się do niego "doktorku" a nie "doktorze". Może to oznaczać że ma już dość oczekiwania na wynik i wariuje już od tego. Slangowe określenia to w tym tekście rzadkość, aczkolwiek można tutaj znaleźć wyraz "ścierwo" oznaczający amfetaminę. Kolejnym przykładem budowy tekstu jest onomatopeja "dryn" oznaczająca dźwięk dzwoniącego telefonu. Ma ona zapewne pobudzić słuchacza i wczuć w sytuację Magika który wiele dni oczekiwał na telefon. Apostrofy "doktorze" oraz "Boże" pojawiające się w tekście odnoszą się do jedynych osób w których podmiot liryczny widzi nadzieję na swoje ozdrowienie. Pod koniec utworu Magik znów zwraca się do Boga w podzięce że jest zdrowy. Refren to próba pokazania odbiorcom jak czuł się Magik. W jego głowie znajduje się tylko plus i minus, nie może się nad niczym skupić i zastanawia się czy umrze. Pod koniec mamy przykład dialogu Magika z doktorem, gdy udał się na sprawdzenie wyniku. Tekst ten pełni funkcję informująco-puczającą - podmiot liryczny opowiada o swoich przeżyciach i jednocześnie daje do zrozumienia żeby uważać na to co się robi i nikomu nie życzy aby przechodził przez to co on. b) utwór "Mes i Numer Raz - Rok później (Oczy otwarte 2)" jako przykład dissu Najpierw musimy sobie odpowiedzieć na pytanie czym jest diss? Diss jest w przypadku raperów atakiem słownym w którym obraża się przeciwnika wytykając jego wady i słabości wpływając tym samym na psychikę i próbując złamać przeciwnika. Może to być przykład parodii. Beefem z kolei nazywam konflikt pomiędzy przedstawicielami środowiska hip hopowego. Przykładem właśnie takiego beefu jest Mes z Numer Raz przeciwko Mezowi. W swoim utworze "Rok później (Oczy otwarte 2)" który znalazł się na składance Kodex 2 dokonują dissu. Mes uważa że Mezo skopiował jego pseudonim. Razem z Numer Raz uważa także że Mezo jest przedstawicielem nowej fali w środowisku muzycznym o nazwie hip hopolo. Jest to styl który łączy w sobie elementy hip hopu i disco polo (śpiewanie o miłości, itp.). Uważają że jest to hańba zarówno dla nich jak i dla hip hopu. Rymy w tym tekście są ułożone w układzie końcowym parzystym przez wszystkie zwrotki utworu, np. "To jakbyś rozdzielał syjamskie bliźnięta, ale Mes to ten typ w niedzielę i święta". Jedynie budowa refrenu pod względem rymów jest inna, ponieważ tylko w środkowej części wyrazy się rymują. Występują w nim za to onomatopeje "tararappa, parararappa, o o". Pojawiają się w kontekście tego że dla Mesa i Numer Raza "rap to coś wiecęj niż" te zacytowane onomatopeje oznaczające jakieś bezsensowne śpiewanie beż żadnego przesłania. Piosenka ta jest jedną wielką apostrofą skierowaną do Meza. Znaleźć tutaj możemy kilka wyrazów zapożyczonych jak np. "oldschoolowo" co wzięło się z angielskiego "old school" co oznacza starą szkołę czyli w tym wypadku w starym stylu. Innym przykładem jest "MC" z angielskiego "master of ceremony" czyli mistrz ceremonii co oznacza rymującego rapera, który zabawia publiczność. Pod koniec piosenki mamy przykład funkcji fatycznej; "Aha, pokażę Ci jak się gra, słyszysz?", która ożywia nieco słuchacza bo chociaż jest już koniec utworu to jednak twórcy chcą aby jeszcze posłuchał co mają do powiedzenia. Występuje tutaj dużo slangów, m.in. "psy" dla określenia policjantów czy "przemalować na sino" czyli pobić i tym samym podbić oczy. W tekstach rapowych rzadko mamy doczynienia z archaizacją jednak znajduje się tutaj przykład wyrazu "bluźnię" czyli ubliżać komuś, obrażać kogoś. Następnie można się doszukać przykładu groteski "To jakbyś rozdzielał syjamskie bliźnięta". Odnosi się to do Mesa w kontekści tego że Mezo skopiował częściowo jego pseudonim i dla tego pierwszego jest to jak rozdzielenie syjamskich bliźniąt czyli właściwie niemożliwe i absurdalne. Podobnie jak poprzedni utwór, "Rok poźniej (Oczy otwarte 2)" ma funkcję informująco-pouczającą. c) utwór "DJ 600V feat. K.A.S.T.A. Skład - Wychylylybymy" jako przykład baunsu Słowo bauns wzięło się od angielskiego słowa "bounce" oznaczającego podskakiwać lub energia życiowa. W kontekście rapowym oznacza utwory zawierającego mnóstwo niskotonowych brzmień, nadające się świetnie na imprezy a teksty zaś mówią o zabawie, używkach czy kobietach. Utwór o którym mowa znalazł się na płycie DJ-a 600V pt. "600 stopni Celsjusza". K.A.S.T.A. to skrót od Konfederacja Absolwentów Szkoły Technicznej Artykulacji. Zespół ten został założony we Wrocławiu a jego członkami są Wall-E, Donguralesko, DJ Kut-O oraz O.M.A. Jak zwyklę zacznę od najważniejszej części tekstów rapowych czyli rymu. Tutaj bez zmian w budowie - jak zwykle są to rymy parzyste, np. "600 stopni Celsjusza w twoich uszach. Łbem beat rusza, rym mknie jak Katiusza". Jest to najprostszy styl rymowania i dlatego tak dużo utworów jest budowanych w ten sposób. Przykładem apostrofy jest tutaj "Świeży powiew, yo, Volt puść to w obieg" gdzie Wall-E zwraca się do twórcy podkładu DJ-a 600V, w kontekście wydania tego utworu gdyż jest to całkiem nowy przykład dobrego rapu o zabarwieniu baunsowym. Innym przykładem budowy tekstu jest personifikacja "Łbem beat rusza, rym mknie jak Katiusza". Oznacza to że Donguralesko uwielbia ten podkład a jego głowa rusza się w takt muzyki który leci z siłą wystrzelonego pocisku. Jeżeli chodzi o wyrazy zapożyczone to występuje tutaj słowo "mixtape" co oznacza zmiksowane przez DJ-a utwory do których zwykle rymują raperzy lub "track" czyli ścieżka dźwiękowa. Znajduje się tutaj dość dużo slangowych określeń dlatego dla laika trudno ten tekst zrozumieć, np. tytuł utworu "wychylylybymy" co prawdopodobnie oznacza wypić jakiś alkohol do dna lub inny slang "wypasiony" co oznacza wspaniały. Ilość tych slangów oznacza że raperzy chcą dotrzeć tylko do tej grupy która wie o co chodzi. Piosenka ma funkcję estetyczną. Można zauważyć również w niej mnóstwo porównań, np. "Beat gorący jak romans Clintona z Monicą. Robię to z tym jak Rutkowski z paniką". Muzycy K.A.S.T.A. Skład bardzo często używają różnorakich porównań w swoich utworach. d) utwór "Nagły Atak Spawacza - Czujesz jak ja" jako przykład hardcore rapu Hardcore rap jest to nurt w muzyce hip hopowej gdzie myślą przwodnią jest ofensywa i agresja przeciwko ludziom którzy w jakiś sposób zirytowali raperów. Nagły Atak Spawacza to poznański skład założony w 1995 roku. Członkami są Fazi, Kaczmi, Kamień, Kaczor oraz Goślina. Zespół jest dosyć kontrowersyjny i nagrał dużo płyt w których ostro krytykuje ludzi i rzeczywistość. Ich najsłynniejszym utworem jest diss przeciwko raperowi Liroyowi pt. "Antyliroy". Jest to jeden z najpełnieszych przekleństw utwór hip hopowy ale nie on będzie przedmiotem mojej analizy a piosenka "Czujesz jak ja". Raperzy mówią w nim o swojej miłości do hip hopu. Do tego co kochają i do tego czego nienawidzą. Standardowo rozpocznę od kwestii rymów. Dwie pierwsze zwrotki tworzą rymy parzyste w trzeciej zaś występują rymy okalające, np. "I tak ma być, nie można się z poglądami kryć". Ilość slangów w tym utworze jest znikoma ale pod koniec utworu Kamień używa stwierdzenia "kumasz?" czyli "rozumiesz?" a także "mnie to wali" czyli "mnie to nie obchodzi" ale w bardzo agresywnym odniesieniu. Doszukać się tutaj można pewnego związku frazeologicznego mianowicie "co tu jest grane" oznacza on "o co tutaj chodzi". Funkcję fatyczną w tej piosence pełni sam refren "czujesz to tak samo jak ja? Lubisz jak ja gdy muzyka gra?". Refren jak wiadomo występuje kilkakrotnie w utworze a przez to że posiada w nim funkcję fatyczną staje się niezwykle żywy i pobudzający. Piosenka ma funkcję estetyczną gdyż odnosi się do uczuć słuchacza. e) utwór "Firma - M.O Faya" jako przykład nielegalu Firma jest to krakowski zespół reprezentowany przez Kaliego, Tadka, Bosskiego, Pomidora oraz Popka. Powstał on w 2000 roku i jest przykładem muzyki undergroundowej czyli działającej w podziemiu. Nielegal jest utworem muzycznym nie wydanym w żadnej komercyjnej wytwórni muzycznej a publikowanym w Internecie lub na zasadzie "z ręki do ręki". Piosenki takie nagrywane są zazwyczaj na domowym komputerze. Przykładem właśnie takiej twórczości jest Firma z Krakowa. Wprawdzie ich popularność sięga całego kraju lecz nadal działają w podziemiu. W swoich utworach wyrażają głównie nienawiść do policji i donosicieli a także opowiadają o szacunku, oddaniu i zwykłych szarych dniach krakowian z blokowisk. Utwór "M.O Faya" odnosi się właśnie do policji. Każdy z raperów opowiada w nim także o sobie. Tym razem zacznę od budowy tytułu. MO to skrót od Milicja Obywatelska która w czasach PRL pełniła funkcję dzisiejszej policji. Jest to przykład parodii i do tego dochodzi wulgarne określenie "faya" co dodatkowo ośmiesza i oczernia funkcjonariuszy. Jeżeli chodzi o slangi to jest ich tutaj cała masa. Nielegale charakteryzują się w dużej mierze tym że jest tam mnóstwo slangów. Jest to język ulicy a raperzy z Firmy utożsamiają się właśnie z ulicą. Jako przyład można wymienić chociażby "społeczniara" co jest także słownictwem ekpresywnym ujemnym od "społeczniak" co oznacza konfidenta, człowieka który śledzi ludzi i donosi. Innym przyładem jest "gad" na określenie policjanta lub "radiola" co oznacza wóz policyjny. Rymy w tym utworze są bez zmian czyli rymy parzyste. Piosenka pełni raczej funkcję informująco-pouczającą. Utwór zawiera mnóstwo przekleństw co podkreśla jego przesłanie w stronę policji i donosicieli, których autorzy nienawidzą. 4. Wniosek a) trudność jednoznacznego określenia czy teksty rapowe to przykład mowy potocznego czy poezji śpiewanej: Trudno jednoznacznie stwierdzić czy teksy rapowe to przykład mowy potocznej lub poezji śpiewanej. - argumenty za mową potoczną: Jak wspomniałem na początku jest to przykład mowy potocznej ponieważ mówi się tam o zdarzeniach, potrzebach, doznaniach, uczuciach w kontaktach z ludźmi. Słowa te są układane w taki sposób w jaki raperzy mówią na codzień. Są czasami piękne, czasami wulgarne a czasami niepoprawne. - argumenty za poezją śpiewaną: Rymy w rapie są układane zwykle w obrębie wersu a jest to charakterystyczne dla rymów w poezji. Teksty są śpiewane więc mamy poezję śpiewaną. b) kompilacja obu typów: Rap jest moim zdaniem kompilacją mowy potocznej z poezją śpiewaną.
2. Wersja skrócona
1. Czym jest rap? Rap jest częścią kultury zwanej hip hopem do której zalicza się właśnie rapowanie, break dance, DJ-ing oraz grafitti. Powstał w latach siedemdziesiątych 20. wieku w Nowym Jorku. Za pioniera hip hopu uważany jest DJ Kool Herc. Charaketerystyczne dla rapu jest przede wszystkim to że teksty są rymowane do jednostajnego rytmu czyli beatu. 2. Charakterystyka tekstów rapowych Piosenki te są przykładem mowy potocznej pełnej slangowych określeń i którą to mowę zwykle mogą zrozumieć ludzie, którzy z hip hopem mają dużo wspólnego lub żyją wsród ludzi, którzy komunikują się między sobą za pomocą slangu. Teksty te zawierają w sobie mnóstwo ekspresji, wulgaryzmów oraz metafor. Wszystko zależy od tego do jakiej grupy ludzi chce dotrzeć raper. Twórzą zwykle monolog czyli tekst mówiony w stylu artystycznym. 3. Analiza wybranych tekstów utwórów muzycznych a) utwór "Kaliber 44 - + i -" jako przykład psychorapu Kaliber 44 powstał w roku 1994 w Katowicach. Na pierwszej płycie o nazwie "Księga tajemnicza. Prolog" zaprezentowali styl zwany psychorapem. Styl ten charakteryzuje się mocno tajemniczą atmosferą w utworze oraz mocno ekspresyjnymi tekstami, które podczas wymowy trudno zrozumieć. Sprawia to że słuchacz popada w silny stan refleksji i utożsamia się z raperami. Biorąc pod uwagę zespół Kaliber 44 to sposób wypowiadania się na ich pierwszej płycie jest idiolektem. Utwór "Plus i minus" opowiada o przeżyciach Magika jakie towarzyszyły mu przed udaniem się na sprawdzenie wyników na obecność wirusa HIV. Plus i minus oznacza odpowiednio wynik pozytywny oraz negatywny. Układy rymów w pierwszej zwrotce tekstu to głównie rymy okalające, np. "Czas sie bać, nadszedł czas, sprawdź to, sprawdź" lecz występują tutaj również najcześniej spotykane rymy parzyste, np. "Idę tam, idę sam w tą czarną chwile. Tyle myśli w sekund tyle". W drugiej zwrotce pojawiają się również podobne układy ale w trzeciej występuje układ przeplatany, np. "I - dryn - telefon dzwoni i jak co dzień. Może tym razem wreszcie sie dowiem. Dziś nadszedł ten dzień, dziś nadszedł dzień. Może będzie mym najlepszym dniem, a może nie". W tekście możemy napotkać przykład słownictwa ekspresywnego dodatniego, np. "doktorku", które odnosi się do doktora badającego Magika. Slangowe określenia to w tym tekście rzadkość, aczkolwiek można tutaj znaleźć wyraz "ścierwo" oznaczający amfetaminę. Kolejnym przykładem budowy tekstu jest onomatopeja "dryn" oznaczająca dźwięk dzwoniącego telefonu. Apostrofy "doktorze" oraz "Boże" pojawiające się w tekście odnoszą się do jedynych osób w których podmiot liryczny widzi nadzieję na swoje ozdrowienie. Refren to próba pokazania odbiorcom jak czuł się Magik. W jego głowie znajduje się tylko plus i minus, nie może się nad niczym skupić i zastanawia się czy umrze. Tekst ten pełni funkcję informująco-puczającą - podmiot liryczny opowiada o swoich przeżyciach i jednocześnie daje do zrozumienia żeby uważać na to co się robi i nikomu nie życzy aby przechodził przez to co on. b) utwór "Mes (Flexxip)/ Numer Raz (Warszafski deszcz) - Rok później (Oczy otwarte 2)" jako przykład dissu Najpierw musimy sobie odpowiedzieć na pytanie czym jest diss? Diss jest w przypadku raperów atakiem słownym w którym obraża się przeciwnika wytykając jego wady i słabości wpływając tym samym na psychikę i próbując złamać przeciwnika. Może to być przykład parodii. Beefem z kolei nazywam konflikt pomiędzy przedstawicielami środowiska hip hopowego. Przykładem właśnie takiego beefu jest Mes z Numer Raz przeciwko Mezowi. W swoim utworze "Rok później (Oczy otwarte 2)" który znalazł się na składance Kodex 2 dokonują dissu. Mes uważa że Mezo skopiował jego pseudonim. Razem z Numer Raz uważa także że Mezo jest przedstawicielem nowej fali w środowisku muzycznym o nazwie hip hopolo. Jest to styl który łączy w sobie elementy hip hopu i disco polo (śpiewanie o miłości, itp.). Uważają że jest to hańba zarówno dla nich jak i dla hip hopu. Rymy w tym tekście są ułożone w układzie końcowym parzystym przez wszystkie zwrotki utworu, np. "To jakbyś rozdzielał syjamskie bliźnięta, ale Mes to ten typ w niedzielę i święta". W refrenie pojawiają się onomatopeje "tararappa, parararappa, o o" w kontekście tego że dla Mesa i Numer Raza "rap to coś wiecęj niż" te zacytowane onomatopeje oznaczające jakieś bezsensowne śpiewanie beż żadnego przesłania. Znaleźć tutaj możemy kilka wyrazów zapożyczonych jak np. "oldschoolowo" co wzięło się z angielskiego "old school" co oznacza starą szkołę czyli w tym wypadku w starym stylu. Innym przykładem jest "MC" z angielskiego "master of ceremony" czyli mistrz ceremonii co oznacza rymującego rapera, który zabawia publiczność. Pod koniec piosenki mamy przykład funkcji fatycznej; "Aha, pokażę Ci jak się gra, słyszysz?", która ożywia nieco słuchacza bo chociaż jest już koniec utworu to jednak twórcy chcą aby jeszcze posłuchał co mają do powiedzenia. Występuje tutaj dużo slangów, m.in. "psy" dla określenia policjantów czy "przemalować na sino" czyli pobić i tym samym podbić oczy. W tekstach rapowych rzadko mamy doczynienia z archaizacją jednak znajduje się tutaj przykład wyrazu "bluźnię" czyli ubliżać komuś, obrażać kogoś. Następnie można się doszukać przykładu groteski "To jakbyś rozdzielał syjamskie bliźnięta". Odnosi się to do Mesa w kontekści tego że Mezo skopiował częściowo jego pseudonim i dla tego pierwszego jest to jak rozdzielenie syjamskich bliźniąt czyli właściwie niemożliwe i absurdalne. Podobnie jak poprzedni utwór, "Rok poźniej (Oczy otwarte 2)" ma funkcję informująco-pouczającą. c) utwór "DJ 600V feat. K.A.S.T.A. Skład - Wychylylybymy" jako przykład baunsu Słowo bauns wzięło się od angielskiego słowa "bounce" oznaczającego podskakiwać lub energia życiowa. W kontekście rapowym oznacza utwory zawierającego mnóstwo niskotonowych brzmień, nadające się świetnie na imprezy a teksty zaś mówią o zabawie, używkach czy kobietach. Utwór o którym mowa znalazł się na płycie DJ-a 600V pt. "600 stopni Celsjusza". K.A.S.T.A. to skrót od Konfederacja Absolwentów Szkoły Technicznej Artykulacji. Zespół ten został założony we Wrocławiu. Jak zwyklę zacznę od najważniejszej części tekstów rapowych czyli rymu. Tutaj bez zmian w budowie - jak zwykle są to rymy parzyste, np. "600 stopni Celsjusza w twoich uszach. Łbem beat rusza, rym mknie jak Katiusza". Przykładem apostrofy jest tutaj "Świeży powiew, yo, Volt puść to w obieg" gdzie Wall-E zwraca się do twórcy podkładu DJ-a 600V, w kontekście wydania tego utworu gdyż jest to całkiem nowy przykład dobrego rapu o zabarwieniu baunsowym. Innym przykładem budowy tekstu jest personifikacja "Łbem beat rusza, rym mknie jak Katiusza". Oznacza to że Donguralesko uwielbia ten podkład a jego głowa rusza się w takt muzyki który leci z siłą wystrzelonego pocisku. Jeżeli chodzi o wyrazy zapożyczone to występuje tutaj słowo "mixtape" co oznacza zmiksowane przez DJ-a utwory do których zwykle rymują raperzy lub "track" czyli ścieżka dźwiękowa. Znajduje się tutaj dość dużo slangowych określeń dlatego dla laika trudno ten tekst zrozumieć, np. tytuł utworu "wychylylybymy" co prawdopodobnie oznacza wypić jakiś alkohol do dna lub inny slang "wypasiony" co oznacza wspaniały. Ilość tych slangów oznacza że raperzy chcą dotrzeć tylko do tej grupy która wie o co chodzi. Piosenka ma funkcję estetyczną. Można zauważyć również w niej mnóstwo porównań, np. "Beat gorący jak romans Clintona z Monicą. Robię to z tym jak Rutkowski z paniką". Muzycy K.A.S.T.A. Skład bardzo często używają różnorakich porównań w swoich utworach. d) utwór "Nagły Atak Spawacza - Czujesz jak ja" jako przykład hardcore rapu Hardcore rap jest to nurt w muzyce hip hopowej gdzie myślą przwodnią jest ofensywa i agresja przeciwko ludziom którzy w jakiś sposób zirytowali raperów. Nagły Atak Spawacza to poznański skład założony w 1995 roku. Zespół jest dosyć kontrowersyjny i nagrał dużo płyt w których ostro krytykuje ludzi i rzeczywistość. Raperzy w piosence "Czujesz jak ja" o swojej miłości do hip hopu. Do tego co kochają i do tego czego nienawidzą. Standardowo rozpocznę od kwestii rymów. Dwie pierwsze zwrotki tworzą rymy parzyste w trzeciej zaś występują rymy okalające, np. "I tak ma być, nie można się z poglądami kryć". Ilość slangów w tym utworze jest znikoma ale pod koniec utworu Kamień używa stwierdzenia "kumasz?" czyli "rozumiesz?" a także "mnie to wali" czyli "mnie to nie obchodzi" ale w bardzo agresywnym odniesieniu. Doszukać się tutaj można pewnego związku frazeologicznego mianowicie "co tu jest grane" oznacza on "o co tutaj chodzi". Funkcję fatyczną w tej piosence pełni sam refren "czujesz to tak samo jak ja? Lubisz jak ja gdy muzyka gra?". Refren jak wiadomo występuje kilkakrotnie w utworze a przez to że posiada w nim funkcję fatyczną staje się niezwykle żywy i pobudzający. Piosenka ma funkcję estetyczną gdyż odnosi się do uczuć słuchacza. e) utwór "Firma - M.O Faya" jako przykład nielegalu Firma jest to krakowski zespół powstały on w 2000 roku będący przykładem muzyki undergroundowej czyli działającej w podziemiu. Nielegal jest utworem muzycznym nie wydanym w żadnej komercyjnej wytwórni muzycznej a publikowanym w Internecie lub na zasadzie "z ręki do ręki". Piosenki takie nagrywane są zazwyczaj na domowym komputerze. Przykładem właśnie takiej twórczości jest Firma z Krakowa. W swoich utworach wyrażają głównie nienawiść do policji i donosicieli a także opowiadają o szacunku, oddaniu i zwykłych szarych dniach krakowian z blokowisk. Utwór "M.O Faya" odnosi się właśnie do policji. Każdy z raperów opowiada w nim także o sobie. Tym razem zacznę od budowy tytułu. MO to skrót od Milicja Obywatelska która w czasach PRL pełniła funkcję dzisiejszej policji. Jest to przykład parodii i do tego dochodzi wulgarne określenie "faya" co dodatkowo ośmiesza i oczernia funkcjonariuszy. Jeżeli chodzi o slangi to jest ich tutaj cała masa. Nielegale charakteryzują się w dużej mierze tym że jest tam mnóstwo slangów. Jest to język ulicy a raperzy z Firmy utożsamiają się właśnie z ulicą. Jako przyład można wymienić chociażby "społeczniara" co jest także słownictwem ekpresywnym ujemnym od "społeczniak" co oznacza konfidenta, człowieka który śledzi ludzi i donosi. Innym przyładem jest "gad" na określenie policjanta lub "radiola" co oznacza wóz policyjny. Rymy w tym utworze są bez zmian czyli rymy parzyste. Piosenka pełni raczej funkcję informująco-pouczającą. Utwór zawiera mnóstwo przekleństw co podkreśla jego przesłanie w stronę policji i donosicieli, których autorzy nienawidzą. 4. Wniosek a) trudność jednoznacznego określenia czy teksty rapowe to przykład mowy potocznego czy poezji śpiewanej: Trudno jednoznacznie stwierdzić czy teksy rapowe to przykład mowy potocznej lub poezji śpiewanej. - argumenty za mową potoczną: Jak wspomniałem na początku jest to przykład mowy potocznej ponieważ mówi się tam o zdarzeniach, potrzebach, doznaniach, uczuciach w kontaktach z ludźmi. Słowa te są układane w taki sposób w jaki raperzy mówią na codzień. Są czasami piękne, czasami wulgarne a czasami niepoprawne. - argumenty za poezją śpiewaną: Rymy w rapie są układane zwykle w obrębie wersu a jest to charakterystyczne dla rymów w poezji. Teksty są śpiewane więc mamy poezję śpiewaną. b) kompilacja obu typów: Rap jest moim zdaniem kompilacją mowy potocznej z poezją śpiewaną.
sobota, 24 lipca 2010
Problem z ClamAV
Ostatnio próbowałem włączyć system mailingowy na moim serwerze i oto jaką wiadomość dostałem gdy próbował włączyć się silnik antywirusowy ClamAV:
Na stronie domowej ClamAV znalazłem opis problemu: http://www.clamav.net/lang/en/2009/10/05/eol-clamav-094/. Wszystko wyglądało na to, że będę musiał ręcznie skompilować ClamAV i czekać na poprawkę, jednak znalazłem obejście tego problemu:
Czyli jak zwykle dochodzę do wniosku, że nie ma rzeczy niemożliwych :)
Starting ClamAV daemon: clamd LibClamAV Warning: ***********************************************************
LibClamAV Warning: *** This version of the ClamAV engine is outdated. ***
LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/support/faq ***
LibClamAV Warning: ***********************************************************
LibClamAV Error: cli_hex2str(): Malformed hexstring: This ClamAV version has reached End of Life! Please upgrade to version 0.95 or later. For more information see www.clamav.net/eol-clamav-094 and www.clamav.net/download (length: 169)
LibClamAV Error: Problem parsing database at line 738
LibClamAV Error: Can't load /tmp/clamav-68821fd5938f593d3d0f1fcfe8b48ca0/daily.ndb: Malformed database
LibClamAV Error: Can't load /var/lib/clamav/daily.cvd: Malformed database
ERROR: Malformed database
failed!
Na stronie domowej ClamAV znalazłem opis problemu: http://www.clamav.net/lang/en/2009/10/05/eol-clamav-094/. Wszystko wyglądało na to, że będę musiał ręcznie skompilować ClamAV i czekać na poprawkę, jednak znalazłem obejście tego problemu:
# rm /var/lib/clamav/daily.cvd
# /etc/init.d/clamav-freshclam stop
Stopping ClamAV virus database updater: freshclam.
# /etc/init.d/clamav-daemon start
Starting ClamAV daemon: clamd LibClamAV Warning: ***********************************************************
LibClamAV Warning: *** This version of the ClamAV engine is outdated. ***
LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/support/faq ***
LibClamAV Warning: ***********************************************************
.
# postsuper -r ALL
postsuper: Requeued: 1 message
# postfix flush
Czyli jak zwykle dochodzę do wniosku, że nie ma rzeczy niemożliwych :)
poniedziałek, 19 lipca 2010
TCP Timestamp do liczenia hostów za NAT-em
1. Prolog
Cześć! Minęło troche czasu odkąd opublikowałem tłumaczenie jednego z
artykułów z 63. Phracka z serii Linenoise. Prezentuję dzisiaj kolejny pt.
"TCP Timestamp do liczenia hostów za NAT-em".
|=-------------------------=[ 0x03-2 ]=----------------------------------=|
|=---------=[ TCP Timestamp do liczenia hostów za NAT-em ]=---------------=|
|=-----------------------------------------------------------------------=|
|=-------------=[ Elie aka Lupin (lupin@zonart.net) ]=-------------------=|
Tabela zawartości
*=*=*=*=*=*=*=*=*
1.0 Wprowadzenie
2.0 Czas ma nam coś do powiedzenia
- 2.1 Przeszłość
- 2.2 Teraźniejszość
- 2.3 Powrót do początkowej historii timestamp
- 2.4 Powrót do NAT
- 2.5 Omówmy PAT
- 2.6 Czas na zwalczanie
3.0 Historia ma nam coś do powiedzenia
- 3.1 Która klasa?
- 3.2 Więc skąd to się wzięło?
- 3.3 Jak to znaleźć?
- 3.4 Powrót do przyszłości
4.0 Nauka z przełości aka wniosek
A - Uznania
B - Dowód koncepcji
--[ 1.0 Wprowadzenie
Ten artykuł jest o rozwiązaniu jakim jest TCP timestamp. Rozwiązanie to oferuje
nową możliwość liczenia hostów będących za NAT-em oraz podwyższony fingerprinting
tych hostów. Dogłębniej: ten artykuł próbuje przedstawić nową wizję klasy
znanych dziur w oprogramowaniu mających "projektowany błąd". Ta dziura została
opisana tutaj i jest godna zainteresowania choćby z następujących powodów:
- jest nowa,
- działa na każdej platformie odkąd jest to związane raczej ze specyfikacją
niż implementacją,
- jest to niezła możliwość aby wyjaśnić jak niektóre specyfikacje mogą być
złamane.
Ten artykuł jest zorganizowany następująco: najpierw wyjąśnię co jest złego
w TCP timestamp. Potem opiszę jak to wykorzystać, ograniczenia tego
wykorzystania oraz jak tego uniknąć. W drugiej części pomówię o pochodzeniu
tego błędu i dlaczego to się znowu zdarza. Na koniec przedstawię dowód
koncepcji i pozdrowienia jak zwykle.
--[ 2.0 Czas ma nam coś do powiedzenia
----[ 2.1 Przeszłość
Fingerprinting i detekcja NAT były aktywnymi dziedzinami od bardzo dawna.
Od czasu kiedy czytasz Phrack znasz już starą szkołę TCP/IP Fyodora.
Możesz znać także p0f (passive OS fingerprinting) Michała Zalewskiego. Z
wersją 2. ukończył on wspaniałe narzędzie, przedstawia pomysłowe drogi
na zrozumienie czy hosty używają mechanizmu NAT przez analizę opcji
pakietu TCP. Jeżeli jesteś zainteresowany tym narzędziem (a powienieneś!)
przeczytaj jego artykuł: "Dr. Jekyll had something to Hyde" [5].
Faktycznie, opisana tutaj technika jest związana z p0f, coś jak p0f, to
może być całkowicie pasywne.
Żeby skończyć temat detekcji NAT muszę nadmienić że AT&T ukończyło badania
nad liczeniem hostów będących za NAT-em [1]. Ich praca była skupiona na IP
ID, przypuszczali że ta wartość jest inkrementowana w niektórych systemach.
Rzeczywiście, mowili oni głownie o Windows który zwiększa IP ID każdego
pakietu o 256. Odkryte przez Antirez [7]. Nmap [6] użył tego dawno temu
(opcja -sI).
Teraz wiemy o czym mówimy. Czas wyjaśnić o co chodzi.
----[ 2.2 Teraźniejszość
NAT został zaprojektowany aby stanąć naprzeciw wyczerpaniu puli adresów IP.
Jest także używany aby ukryć wiele hostów będących za pojedyńczym adresem
IP. Opcja TCP timestamp [2] jest błędnie opracowana przez mechanizm
Translacji Adresów Sieciowych czyli Network Adress Translation (NAT) [3].
Innymi słowy nawet zeskrobanie tego z p0f nie podrobi opcji timestamp.
Do teraz właściwość NAT-u była bezużyteczna (z punktu widzenia
bezpieczeństwa). Warto zwrócić uwagę na to że opcja timestamp była używana
już poprzednio przez samą siebie do ujawniania informacji. Spójrzmu szybko
na historię bezpieczeństwa timestamp.
----[ 2.3 Powrót do początkowej historii timestamp
W przeszłości timestamp był używany do obliczania uptime'u komputera
[4]. Każdy kto wypróbował opcję fingerprintingu TCP w Nmapie (-O) był pod
wrażeniem gdy zobaczył coś takiego:
"Uptime 36.027 days (since Tue May 25 11:12:31 2004)".
Oczywiście za tym nie kryje się żadna czarna magia, tylko dwa fakty:
- czas powraca tylko w filmach (przykro mi, chłopcy...),
- wszystkie systemy operacyjne inkrementują timestamp o jeden co
milisekundę.
Więc jeżeli znasz system operacyjny to wiesz jak często system ten zwiększa
timestamp. Wszystko co musisz zrobić żeby dowiedzieć się ile wynosi uptime
to zastosować prostą matematyczną formułę:
timestamp / wartość o którą się zwiększa co sekundę = uptime w sekundach
Możesz zauważyć że ta formuła nie bierze pod uwagę osnowy zaokrąglenia
liczby całkowitej. Teraz znamy dwie rzeczy: aktualny timestamp i liczbę o
którą zwiększa się co sekundę. Skończymy to tylko jeżeli znamy typ systemu
operacjnego. Zobaczmy jak możemy udoskonalić tą technikę robiąc to bez
znajomości systemu operacyjnego.
----[ 2.4 Powrót do szkoły
Pamiętasz? Dawno temu w szkole mówiono o równaniu kierunkowym prostej.
Podstawowym przykładem tego jest:
"y = Ax + B"
gdzie A oznacza monotoniczność funkcji a B punkt początkowy.
Graficzną reprezentacją tego jest linia prosta. Z punktu widzenia timestamp
to może być ekspresowe jak następuje:
timestamp = wartość o którą się zwiększa co sekundę * sekunda + wartość
początkowa
Kiedy wykonujesz aktywny fingerprinting dostajesz timestamp i znasz wartość
o którą się zwiększa co sekundę poprzez odgadnięcie systemu operacyjnego.
Załóżmy że możesz odgadnąć jaki jest system operacyjny. W tym wypadku nie
znasz monotoniczności funkcji i nie możesz odgadnąć uptime'u. Ale jest inna
droga na dowiedzenie się jaka jest monotoniczność systemu operacyjnego.
Musisz zdobyć komputer z podwójnym timestampem. Nazwą jest ts1 i ts2 a
wartość czasu (w sekundach) gdzie jest zapisywany to s1 i s2.
Mając tamte informacje można bardzo łatwo znaleźć monotoniczność dzięki
następujacemu układowi:
ts1 = A*s1 + B
ts2 = A*s2 + B
gdzie rozwiązaniem jest to oto równanie:
ts1 - ts2 = A*(s1 - s2) <=> A = (ts1 - ts2) / (s1 - s2)
Bezpośrednia aplikacja wykorzystująca ten pomysł może być zaimplementowana
w aktywnym skanerze: dwókrotne żądanie o timestamp w celu weryfikacji czy
monotoniczność jest taka sama jak przypuszczaliśmy.
To może zostać użyte do złamania jakiegoś anty-fingerprintingowego narzędzia.
Innym zastosowaniem jest użycie tego jako techniki standalone fingerprinting
ale nie będziemy mieć pewności czy ma raz TCP czy ICMP.
Teraz znamy już teorię, wróćmy do NAT-u.
----[ 2.5 Powrót do NAT-u
Utwórzmy połączenie z NAT-em. Odkąd rozwiązanie timestamp nie jest
przepisywane przez NAT, możemy policzyć liczbę hostów za NAT-em używając
następującego algorytmu:
1) dla każdego już odkrytego hosta weryfikowany jest pakiet należący do
tego równania linii prostej. Każdy host ma unikatowe równanie prostej
dopóki dwa hosty są bootowane w tej samej sekundzie.
2) w przeciwnym wypadku należy dodać pakiet do nie pasującego pakietu: nowy
host za NAT-em jest wykrywany.
Rzuć okiem na dowód koncepcji jeżeli chcesz zrobić to bardziej klarownie.
Ten prosty algorytm ma wiele do udoskonalenia. Został przedstawiony jako
prosty i możliwie jak najbardziej przezroczysty. Jak widzisz rozwiązanie
timestamp może zostać użyte do liczenia hostów za NAT-em w sposób niezawodny.
Poda również wskazówkę dotyczącą klasyfikację systemu operacyjnego.
----[ 2.6 Omówmy PAT
PAT (Port Address Translation - Translacja Adresu Portu) jest używana do
dostarczania usługi na komputerze za NAT-em.
Pytaniem jest skąd wiem że port jest forwardowany? Timestamp jest raz
jeszcze Twoim przyjacielem. Jeżeli dla dwóch różnych usług monotoniczność
timestampu jest inna, wtedy PAT i system operacyjny dwóch komputerów są różne.
Jeżeli timestamp pobrany z dwóch portów nie należy do tej samej prostej, wtedy
jest to ten sam system ale nie ten sam komputer.
Inną interesującą funkcją PAT-u jest round robin (od tł.: w wolnym
tłumaczeniu jest to okrągły rudzik). Do teraz nie było żadnej możliwości żeby się
dowiedzieć czy taki mechanizm został użyty. Przez porównywanie różnych
zebranych timestampów możesz ustalić ile hostów jest za pojedyńczym portem.
Dodanie takiej funkcji w aktywnym skanerze mogło być ciekawe.
----[ 2.7 Czas na zwalczanie
Od czasu kiedy gra z tą opcją mogła dać cenne informacje, jest tam
jakieś ograniczenie na tą technikę. Stacje windowsowe właściwie nie używają
rozwiązania timestamp kiedy ustanawiają połączenie [8] chyba że je
aktywujesz. To ograniczenie oddziałuje tylko na pasywną analizę, jeżeli
używasz timestamp do łączenia się z Windowsem to on także będzie tego
używał. Ponadto wiele ściąganych programów aktywuje rozszerzenie TCP w
Windowsie.
Żeby zakończyć temat chciałbym nadmienić że wydaje się że rozszerzenie TCP
nie istnieje w Windows 9X.
Jednym z innych problemów jest przerwa czasowa. W trybie pasywnym może być tam
desynchronizacja pomiędzy komputerami spowodowana komputerową
desynchronizacją lub sieciowymi opóźnieniami. W dowodzie koncepcji to
zjawisko może się przytrafić. Żeby to załatwić nie musisz polegać na
komputerowym zegarze ale na timestamp.
Co możemy zrobić w stosunku do tego? Od czasu kiedy żaden sprzedawca prócz
Microsoftu (1) (dzięki Magnus) nie zadał mi pytania, następujące
obejścia mogą nie być dostępne:
1) Wyłączanie TCP timestamp. To jest gorsze rozwiązanie ponieważ będziemy
tego potrzebowali mimo szybkiej sieci.
2) Przepisanie NAT-u na timestamp i zmienianie The NAT RFC.
3) Zmienianie zawartości RFC na taką że rozwiązanie timestamp musi mieć
przypadkowy przyrost. Modyfikowanie każdej implementacji odbija tą
zmianę. Czyste rozwiązanie utwierdzające tą rzecz ponieważ to nie
polega na zewnętrznym systemie (komputer z NAT-em w tym wypadku).
Więc muszę spróbować być tak kompletnym jak to możliwe w tej technicznej
części. Następna część będzie bardziej "filozoficzna" zaczynając od tego jak
to ma do czynienia z powodem zamiast konsekwencji.
--[ 3.0 Historia ma nam coś do powiedzenia
W tej części spróbuję skupić się na tym dlaczego mamy taką sytuację i co
możemy z tym zrobić. Nie będę mówił tutaj o rozwiązaniu timestamp samym w
sobie ale o interakcji pomiędzy timestamp a mechanizmem NAT.
----[ 3.1 Która klasa?
Pierwsze pytanie brzmi: co jest bugiem? Ta dziura należy do modelu klasy
błędów. Bardziej precyzyjnie: bug istnieje ponieważ istnieje specyfikacja
protokołu. IP został zaprojektowany jako protokół jeden na jeden: jeden
klient mówi do jednego serwera. NAT narusza tą specyfikację przez
dopuszczenie wielokrotnych odwołań do jednego serwera. Z natury to nadużycie
powoduje wiele problemów dzięki którym tracę to co policzyłem, lecz jest to
dosyć pewne że najbardziej rekurencyjnym problemem jest transfer FTP. Jeżeli
używasz FTP to wiesz o co mi chodzi (inni mogą spojrzeć na netfilter ftp
conntrack).
----[ 3.2 Więc skąd to się wzięło?
Problem FTP jest dobrym przykładem aby wyjaśnić pochodzenie problemu
zachodzącej specyfikacji. FTP został wyspecyfikowany do pracy nad solidnym
połączeniem jeden do jednego (w rzeczywistości TCP). NAT został
zaprojektowany do modyfikacji IP. Więc dzięki zależnościom protokołu to
także zmienia TCP i przeto FTP.
Podczas specyfikacji NAT-u nie było brane pod uwagę że każdy protokół który
polega na IP, może wchodzić w konflikt ze zmodyfikowaną specyfikacją. Jeżeli
chciano powiedzieć prawdę, nawet jeżeli ludzie którzy zaprojektowali mechanizm
NAT kiedykolwiek potrzebowali gwarancji że każdy protokół który opiera się na
IP może pracować z NAT-em, nie można było tego zrobić.
Dlaczego? Ponieważ specyfikacje są w RFC i RFC jest po angielsku. Angielski
nie jest dobrym pomysłem na specyfikację rzeczy szczególnie jeżeli masz
wykres zależności dla specyfikacji.
Np. wiele języków programowania ma formalne specyfikcje. Która jest
pełniejszym dowodem rozwiązania. Rozwiązanir tego braku specyfikacji
znajduje się w historii Internetu [9]. W tym czasie pisząc mały tekst była to
dostateczna ilość. Teraz może to być problemem.
----[ 3.3 Jak to znaleźć?
Ważym pytaniem jest, jak mam znaleźć ten bug? Więc, znalazłem ten problem
przez formalizację części RFC TCP i porównanie wyniku tej analizy z
prawdziwymi śladami wykonania. Mój analizator (2) ostrzegł mnie że timestamp
był mniejszy niż jeden poprzedni i jak wiesz czas nie wróci...
Sprawdziłem dlaczego i jak znalazłem ten problem. Interesujące jest tutaj
to że punktem wyjścia do znalezienia tego błędu jest raczej specyfikacja niż
implementacja jak to zwykle można znaleźć przepełnienie bufora dla przykładu.
----[ 3.4 Powrót do przyszłości
Więc co się od tej porty będzie działo? Ano znajdowanych będzie więcej
projektowanych błędów ponieważ nie możemy zmienić przeszłości i musimy z tym
żyć.
Nie jest sensowne mówić że możemy ścierać wszystko to co materiał TCP i
rozpoczynać nową rzecz od zadrapania. Internet i sieć są po prostu za duże do
poruszania się w ten sposób. Najprościej mówiąc myślą co sekundę o rozlokowaniu
IP v6 i przekonasz się o tym. Wszystko co możemy zrobić to być tak ostrożnymi
jak to możliwe kiedy projektujemy jakieś nowe rozszerzenie lub protokół.
Próbujmy zapewniać że ten nowy materiał nie powoduje konfliktów z
poprzednimi wersjami lub nie narusza zależności. Możemy także próbować
formalizować protokoły tak dużo jak to możliwe i wykrywać błędy zanim
spowodują jakieś problemy. Łatanie błędów jest naszym głównym zadaniem na
najbliższe lata.
--[ 4.0 Nauka z przeszłości aka wniosek
Przeszłość mówi nam że protokół nie jest dostatecznie dobrze
wyspecyfikowany i prowadzi do błędów (bug, konflikt...). To może być czas na
zmianę naszych zwyczajów i próbę dodania czegoś na podstawie bilansu naszego
czasu. Np. do zaprojektowania naszych rzeczy bezpiecznie w umyśle. W tym
artykule spróbowałem pokazać wam że przez proste zrozumienie specyfikacji i
z pomocą podstawowej znajomości matematyki możesz:
- znaleźć usterkę o ogólnoświatowym wpływie,
- wykorzystać tą usterkę w elegancki sposób za pomocą prostej teorii,
- rozwijać sztukę fingerprintingu.
Mam nadzieję że to pomoże przekonać cię że teoria i formalne narzędzia są
niezbędną częścią obszaru bezpiecznego komputera. Następnym razem skupię się
na prostej formalnej metodzie znalezienia bugu. Mam nadzieję że tutaj
będziecie :)
--[ A Uznania
Najpierw chciałbym podziękować Romainowi Bottierowi za jego pomoc i jego
cierpliwość. Chcę także podziękować Plopsowi i Polucowi za wiarę we mnie.
Widzicie ludzie udało się nam!
Chcę także powiedzieć że biorę całkowitą odpowiedzialność za nie ujawnienie
polityki. Powiadomiłem głównych sprzedawców (Kernel.org, FreeBSD, OpenBSD,
Cisco...) miesiąc temu. Tak jak powiedziałem nie otrzymałem żadnej reakcji
więc dochodzę do wniosku że ich to nie obchodzi.
Referencje
*=*=*=*=*
[1] AT&T Steven M. Bellovin. A Technique for Counting NATted Hosts
http://www.research.att.com/~smb/papers/fnat.pdf
[2] Jacobson, Braden, & Borman. RFC 1323 :TCP Extensions for High
Performance.
[3] K. Egevang, Cray Communications, P. Francis. RFC 1631:
The IP Network Address Translator (NAT).
[4] Bret McDanel. TCP Timestamping - Obtaining System Uptime Remotely
originally posted to Bugtraq Security Mailing List on March 11, 2001.
[5] Michal Zalewski. p0f 2:Dr. Jekyll had something to Hyde.
[6] Fyodor. Nmap - Free Security Scanner For Network Exploration &
Security Audits.
[7] Antirez. dumbscan original BUGTRAQ posting (18 Dec 1998)
[8] Microsoft. TCP timestamp in windows : KB224829.
[9] Hafner, Katie, Matthew Lyon. Where Wizards Stay Up Late: The Origins of
the Internet.
Notatki
*=*=*=*
(1) Punktem widzenia Microsoftu jest to że NAT nie jest bezpiecznym
mechanizmem więc nie chcą tego łatać.
(2) Jesteś zainteresowany moim analizatorem? Mam nadzeję nadzieję że
niedługo opublikuję teoretyczny artykuł o tym jak to działa. Mam także
nadzieję wypuścić wkrótce jakąś wersję tego. Co do pytania czy znalazłem
inne interesujące rzeczy odpowiedź brzmi: może muszę to sprawdzić
bardziej dogłębnie.
--[ B Dowód koncepcji
/*
* Dowód koncepcji: liczenie hostów za NAT-em przy pomocy timestamp
* Żeby skompilować ten plik potrzebujesz libpcap
* Wszelkie prawa zatrzeżone dla Elie Bursztein (lupin@zonart.net)
* Kompilacja udała się na FreeBSD 5.X i Linux 2.6.X
*
* $ gcc natcount.c -o natcount -I/usr/local/include -L/usr/local/lib -lpcap
*/
#define __USE_BSD 1
#include <sys/time.h>
#include <time.h>
#include <netinet/in.h>
#include <net/ethernet.h>
#ifdef __FreeBSD__
#include <netinet/in_systm.h>
#endif /* __FreeBSD__ */
#ifdef __linux__
#include <linux/if_ether.h>
#endif /* __linux__ */
#include <netinet/ip.h>
#include <stdlib.h>
#include <string.h>
#include <pcap.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <net/if.h>
#include <netinet/tcp.h>
#include <netinet/udp.h>
#ifdef __linux__
#define th_off doff
#endif /* __linux__ */
u_int32_t addr = 0;
/* Łańcuch struktur list */
typedef struct listes_s {
struct listes_s *next;
void *elt;
} listes_t;
/* Struktury dla opcji TCP */
typedef struct { u_int32_t ts, ts_r; } timestamp_t;
typedef struct { timestamp_t *ts; } tcp_opt_t;
/* Struktury do składu danych */
typedef struct { u_int32_t from, first_timestamp; struct timeval
first_seen; } machine_t;
typedef struct { u_int32_t host, nat; struct timeval first_seen; }
nat_box_t;
#define TIMESTAMP_ERROR_MARGIN 0.5
#define DELAY 1
/* Lista funkcji */
int add_in_list(listes_t **list, void * elt) {
listes_t *lst;
lst = malloc(sizeof (listes_t));
lst->next = *list;
lst->elt = elt;
*list = lst;
return (1);
}
void show_nated(listes_t *list) {
nat_box_t *nat;
struct in_addr addr;
printf("-- Poczatek listy NAT-owanych adresow IP --\n");
while (list) {
nat = (nat_box_t *) list->elt;
if (nat->nat > 1) {
addr.s_addr = nat->host;
printf("Przypuszczam ze %i komputerow rozdziela te same adresy
(%s)\n", nat->nat, inet_ntoa(addr));
}
list = list->next;
}
printf("-- Koniec listy NAT-owanych adresow IP --\n");
}
/* Funkcja używana do pobierania wszystkich opcji TCP.
* Prosty parser opcji TCP */
int tcp_option_parser(const u_char *options, tcp_opt_t *parsed, unsigned int
size) {
u_int8_t kind, len, i;
bzero(parsed, sizeof(tcp_opt_t));
i = 0;
kind = *(options + i);
while (kind != 0) /* EO */ {
switch (kind) {
case 1:
i++;
break; /* Bajt NOP */
case 2:
i += 4;
break;
case 3:
i += 3;
break;
case 4:
i += 2;
break;
case 5: /* pominięcie opcji SACK */
len = (*options + ++i) - 1;
i += len;
break;
case 6:
i += 6;
break;
case 7:
i += 6;
break;
case 8:
i += 2;
parsed->ts = (timestamp_t *) (options + i);
i += 8;
return (1);
break;
default:
i++;
}
kind = *(options + i);
}
return (0);
}
/* Najbardziej interesująca funkcja... Tutaj możemy sie dowiedzieć czy
* pakiet TCP pochodzi od kogoś kogo już znamy!
*
* Prototyp:
* finc(sekundy) = aktualny_czas_pakietu - pierwszy_czas_pakietu <-
* czas_pomiedzy_dwoma_pakietami
* ts_inc = inc_table[i] * finc <-
* nasz_przypuszczalny_inkrementowany_timestamp_pomiedzy_dwoma_pakietami
* new_ts = pierwszy_timestamp + ts_inc <- new *
timestamp_ktory_powinnismy_miec_teraz!
*
* Teraz musimy poprostu porównać new_ts z aktualnym czasem timestampu.
* Możemy autoryzować marginesowy błąd od 0.5%.
*
* Nasza inc_table zawiera inkrementowany co sekundę timestamp dla wielu
* systemów operacyjnych. */
int already_seen(machine_t *mach, tcp_opt_t *opt, struct timeval temps)
{
int inc_table[4] = {2, 10, 100, 1000};
unsigned int new_ts;
float finc, tmp, ts_inc;
int i, diff;
finc = ((temps.tv_sec - mach->first_seen.tv_sec) * 1000000.
+ (temps.tv_usec - mach->first_seen.tv_usec)) / 1000000.;
for (i = 0; i < 4; i++) {
ts_inc = inc_table[i] * finc;
new_ts = ts_inc + mach -> first_timestamp;
diff = ntohl(opt->ts->ts) - new_ts;
if (diff == 0) { /* Celny strzał! */
return (2);
}
tmp = 100. - (new_ts * 100. / ntohl(opt->ts->ts));
if (tmp < 0.)
tmp *= -1.;
if (tmp <= TIMESTAMP_ERROR_MARGIN) { /* Uaktualniony timestamp i czas */
mach -> first_seen = temps;
mach -> first_timestamp = ntohl(opt->ts->ts);
return (1);
}
}
return (0);
}
/* Zwykła funkcja sprawdzająca czy adres IP jest już w naszej liście. Jeżeli
* nie to jest to tylko nowe połączenie. */
int is_in_list(listes_t *lst, u_int32_t addr)
{
machine_t *mach;
while (lst) {
mach = (machine_t *) lst -> elt;
if (mach -> from == addr)
return (1);
lst = lst -> next;
}
return (0);
}
/* Ta funkcja powinna być wywoływana jeżeli pakiet z adresu IP został
* znaleziony, jeśli adres jest już w liście ale nie pasuje do żadnej
* wartości timestamp. */
int update_nat(listes_t *list, u_int32_t addr)
{
nat_box_t *box;
while (list) {
box = (nat_box_t *) list -> elt;
if (box->host == addr) {
box->nat++;
return (1);
}
list = list->next;
}
return (0);
}
int check_host(listes_t **list, listes_t **nat, u_int32_t from,
tcp_opt_t *opt, struct timeval temps)
{
listes_t *lst;
machine_t *mach;
int found, zaped;
found = zaped = 0;
lst = *list;
while (lst && !(found)) {
mach = (machine_t *) lst -> elt;
if (mach -> from == from) {
if (temps.tv_sec - mach -> first_seen.tv_sec > DELAY) {
found = already_seen(mach, opt, temps);
}
else
zaped = 1;
}
lst = lst->next;
}
if (!(zaped) && !(found)) {
mach = malloc(sizeof (machine_t));
mach -> from = from;
mach -> first_seen = temps;
mach -> first_timestamp = ntohl(opt->ts->ts);
add_in_list(list, mach);
update_nat(*nat, from);
show_nated(*nat);
return (1);
}
return (0);
}
void callback_sniffer(u_char *useless, const struct pcap_pkthdr* pkthdr,
const u_char *packet)
{
static listes_t *list_machines = 0;
static listes_t *list_nat = 0;
const struct ip *ip_h;
const struct tcphdr *tcp_h;
tcp_opt_t tcp_opt;
machine_t *mach;
nat_box_t *nat;
struct in_addr my_addr;
ip_h = (struct ip *) (packet + sizeof(struct ether_header));
if (ip_h -> ip_p == IPPROTO_TCP) {
tcp_h = (struct tcphdr *) (packet + sizeof(struct ether_header) +
sizeof(struct ip));
if (tcp_h -> th_off * 4 > 20) {
if (tcp_option_parser((u_char *) (packet + sizeof(struct
ether_header) + sizeof(struct ip) + sizeof(struct tcphdr)),
&tcp_opt, tcp_h->th_off * 4 - 20)) {
if (is_in_list(list_machines, (ip_h->ip_src).s_addr)) {
check_host(&list_machines, &list_nat, (u_int32_t)
(ip_h->ip_src).s_addr, &tcp_opt, pkthdr->ts);
}
else {
if (ntohl(tcp_opt.ts -> ts) != 0) {
addr = (ip_h -> ip_src).s_addr;
my_addr.s_addr = addr;
mach = malloc(sizeof(machine_t));
mach -> from = (ip_h -> ip_src).s_addr;
mach -> first_seen = pkthdr -> ts;
mach -> first_timestamp = ntohl(tcp_opt.ts -> ts);
nat = malloc(sizeof(nat_box_t));
nat -> host = (u_int32_t) (ip_h -> ip_src).s_addr;
nat -> nat = 1;
nat -> first_seen = mach -> first_seen;
add_in_list(&list_machines, mach);
add_in_list(&list_nat, nat);
}
}
}
}
}
}
int main(int ac, char *argv[])
{
pcap_t *sniff;
char errbuf[PCAP_ERRBUF_SIZE];
struct bpf_program fp;
char *device;
bpf_u_int32 maskp, netp;
struct in_addr my_ip_addr;
char filter[250];
if (getuid() != 0) {
printf("Musisz byc rootem zeby uzywac tego narzedzia.\n");
exit (2);
}
if (--ac != 1) {
printf("Uzycie: ./natcount xl0\n");
return (1);
}
device = (++argv)[0];
pcap_lookupnet(device, &netp, &maskp, errbuf);
my_ip_addr.s_addr = (u_int32_t) netp;
printf("Uzywany interfejs IP %s: %s\n", device, inet_ntoa(my_ip_addr));
if ((sniff = pcap_open_live(device, BUFSIZ, 1, 1000, errbuf)) == NULL) {
printf("ERR: %s\n", errbuf);
exit(1);
}
bzero(filter, 250);
snprintf(filter, 250, "not src net %s", inet_ntoa(my_ip_addr));
if (pcap_compile(sniff,&fp, filter, 0, netp) == -1) {
fprintf(stderr,"Blad nazywany pcap_compile\n");
exit(1);
}
if (pcap_setfilter(sniff,&fp) == -1) {
fprintf(stderr, "Blad ustawienia filtra\n");
exit(1);
}
pcap_loop(sniff, -1, callback_sniffer, NULL);
return (0);
}
2. Epilog
To by było na tyle. I pamiętajcie że głowa jest pełna pomysłów.
Cześć! Minęło troche czasu odkąd opublikowałem tłumaczenie jednego z
artykułów z 63. Phracka z serii Linenoise. Prezentuję dzisiaj kolejny pt.
"TCP Timestamp do liczenia hostów za NAT-em".
|=-------------------------=[ 0x03-2 ]=----------------------------------=|
|=---------=[ TCP Timestamp do liczenia hostów za NAT-em ]=---------------=|
|=-----------------------------------------------------------------------=|
|=-------------=[ Elie aka Lupin (lupin@zonart.net) ]=-------------------=|
Tabela zawartości
*=*=*=*=*=*=*=*=*
1.0 Wprowadzenie
2.0 Czas ma nam coś do powiedzenia
- 2.1 Przeszłość
- 2.2 Teraźniejszość
- 2.3 Powrót do początkowej historii timestamp
- 2.4 Powrót do NAT
- 2.5 Omówmy PAT
- 2.6 Czas na zwalczanie
3.0 Historia ma nam coś do powiedzenia
- 3.1 Która klasa?
- 3.2 Więc skąd to się wzięło?
- 3.3 Jak to znaleźć?
- 3.4 Powrót do przyszłości
4.0 Nauka z przełości aka wniosek
A - Uznania
B - Dowód koncepcji
--[ 1.0 Wprowadzenie
Ten artykuł jest o rozwiązaniu jakim jest TCP timestamp. Rozwiązanie to oferuje
nową możliwość liczenia hostów będących za NAT-em oraz podwyższony fingerprinting
tych hostów. Dogłębniej: ten artykuł próbuje przedstawić nową wizję klasy
znanych dziur w oprogramowaniu mających "projektowany błąd". Ta dziura została
opisana tutaj i jest godna zainteresowania choćby z następujących powodów:
- jest nowa,
- działa na każdej platformie odkąd jest to związane raczej ze specyfikacją
niż implementacją,
- jest to niezła możliwość aby wyjaśnić jak niektóre specyfikacje mogą być
złamane.
Ten artykuł jest zorganizowany następująco: najpierw wyjąśnię co jest złego
w TCP timestamp. Potem opiszę jak to wykorzystać, ograniczenia tego
wykorzystania oraz jak tego uniknąć. W drugiej części pomówię o pochodzeniu
tego błędu i dlaczego to się znowu zdarza. Na koniec przedstawię dowód
koncepcji i pozdrowienia jak zwykle.
--[ 2.0 Czas ma nam coś do powiedzenia
----[ 2.1 Przeszłość
Fingerprinting i detekcja NAT były aktywnymi dziedzinami od bardzo dawna.
Od czasu kiedy czytasz Phrack znasz już starą szkołę TCP/IP Fyodora.
Możesz znać także p0f (passive OS fingerprinting) Michała Zalewskiego. Z
wersją 2. ukończył on wspaniałe narzędzie, przedstawia pomysłowe drogi
na zrozumienie czy hosty używają mechanizmu NAT przez analizę opcji
pakietu TCP. Jeżeli jesteś zainteresowany tym narzędziem (a powienieneś!)
przeczytaj jego artykuł: "Dr. Jekyll had something to Hyde" [5].
Faktycznie, opisana tutaj technika jest związana z p0f, coś jak p0f, to
może być całkowicie pasywne.
Żeby skończyć temat detekcji NAT muszę nadmienić że AT&T ukończyło badania
nad liczeniem hostów będących za NAT-em [1]. Ich praca była skupiona na IP
ID, przypuszczali że ta wartość jest inkrementowana w niektórych systemach.
Rzeczywiście, mowili oni głownie o Windows który zwiększa IP ID każdego
pakietu o 256. Odkryte przez Antirez [7]. Nmap [6] użył tego dawno temu
(opcja -sI).
Teraz wiemy o czym mówimy. Czas wyjaśnić o co chodzi.
----[ 2.2 Teraźniejszość
NAT został zaprojektowany aby stanąć naprzeciw wyczerpaniu puli adresów IP.
Jest także używany aby ukryć wiele hostów będących za pojedyńczym adresem
IP. Opcja TCP timestamp [2] jest błędnie opracowana przez mechanizm
Translacji Adresów Sieciowych czyli Network Adress Translation (NAT) [3].
Innymi słowy nawet zeskrobanie tego z p0f nie podrobi opcji timestamp.
Do teraz właściwość NAT-u była bezużyteczna (z punktu widzenia
bezpieczeństwa). Warto zwrócić uwagę na to że opcja timestamp była używana
już poprzednio przez samą siebie do ujawniania informacji. Spójrzmu szybko
na historię bezpieczeństwa timestamp.
----[ 2.3 Powrót do początkowej historii timestamp
W przeszłości timestamp był używany do obliczania uptime'u komputera
[4]. Każdy kto wypróbował opcję fingerprintingu TCP w Nmapie (-O) był pod
wrażeniem gdy zobaczył coś takiego:
"Uptime 36.027 days (since Tue May 25 11:12:31 2004)".
Oczywiście za tym nie kryje się żadna czarna magia, tylko dwa fakty:
- czas powraca tylko w filmach (przykro mi, chłopcy...),
- wszystkie systemy operacyjne inkrementują timestamp o jeden co
milisekundę.
Więc jeżeli znasz system operacyjny to wiesz jak często system ten zwiększa
timestamp. Wszystko co musisz zrobić żeby dowiedzieć się ile wynosi uptime
to zastosować prostą matematyczną formułę:
timestamp / wartość o którą się zwiększa co sekundę = uptime w sekundach
Możesz zauważyć że ta formuła nie bierze pod uwagę osnowy zaokrąglenia
liczby całkowitej. Teraz znamy dwie rzeczy: aktualny timestamp i liczbę o
którą zwiększa się co sekundę. Skończymy to tylko jeżeli znamy typ systemu
operacjnego. Zobaczmy jak możemy udoskonalić tą technikę robiąc to bez
znajomości systemu operacyjnego.
----[ 2.4 Powrót do szkoły
Pamiętasz? Dawno temu w szkole mówiono o równaniu kierunkowym prostej.
Podstawowym przykładem tego jest:
"y = Ax + B"
gdzie A oznacza monotoniczność funkcji a B punkt początkowy.
Graficzną reprezentacją tego jest linia prosta. Z punktu widzenia timestamp
to może być ekspresowe jak następuje:
timestamp = wartość o którą się zwiększa co sekundę * sekunda + wartość
początkowa
Kiedy wykonujesz aktywny fingerprinting dostajesz timestamp i znasz wartość
o którą się zwiększa co sekundę poprzez odgadnięcie systemu operacyjnego.
Załóżmy że możesz odgadnąć jaki jest system operacyjny. W tym wypadku nie
znasz monotoniczności funkcji i nie możesz odgadnąć uptime'u. Ale jest inna
droga na dowiedzenie się jaka jest monotoniczność systemu operacyjnego.
Musisz zdobyć komputer z podwójnym timestampem. Nazwą jest ts1 i ts2 a
wartość czasu (w sekundach) gdzie jest zapisywany to s1 i s2.
Mając tamte informacje można bardzo łatwo znaleźć monotoniczność dzięki
następujacemu układowi:
ts1 = A*s1 + B
ts2 = A*s2 + B
gdzie rozwiązaniem jest to oto równanie:
ts1 - ts2 = A*(s1 - s2) <=> A = (ts1 - ts2) / (s1 - s2)
Bezpośrednia aplikacja wykorzystująca ten pomysł może być zaimplementowana
w aktywnym skanerze: dwókrotne żądanie o timestamp w celu weryfikacji czy
monotoniczność jest taka sama jak przypuszczaliśmy.
To może zostać użyte do złamania jakiegoś anty-fingerprintingowego narzędzia.
Innym zastosowaniem jest użycie tego jako techniki standalone fingerprinting
ale nie będziemy mieć pewności czy ma raz TCP czy ICMP.
Teraz znamy już teorię, wróćmy do NAT-u.
----[ 2.5 Powrót do NAT-u
Utwórzmy połączenie z NAT-em. Odkąd rozwiązanie timestamp nie jest
przepisywane przez NAT, możemy policzyć liczbę hostów za NAT-em używając
następującego algorytmu:
1) dla każdego już odkrytego hosta weryfikowany jest pakiet należący do
tego równania linii prostej. Każdy host ma unikatowe równanie prostej
dopóki dwa hosty są bootowane w tej samej sekundzie.
2) w przeciwnym wypadku należy dodać pakiet do nie pasującego pakietu: nowy
host za NAT-em jest wykrywany.
Rzuć okiem na dowód koncepcji jeżeli chcesz zrobić to bardziej klarownie.
Ten prosty algorytm ma wiele do udoskonalenia. Został przedstawiony jako
prosty i możliwie jak najbardziej przezroczysty. Jak widzisz rozwiązanie
timestamp może zostać użyte do liczenia hostów za NAT-em w sposób niezawodny.
Poda również wskazówkę dotyczącą klasyfikację systemu operacyjnego.
----[ 2.6 Omówmy PAT
PAT (Port Address Translation - Translacja Adresu Portu) jest używana do
dostarczania usługi na komputerze za NAT-em.
Pytaniem jest skąd wiem że port jest forwardowany? Timestamp jest raz
jeszcze Twoim przyjacielem. Jeżeli dla dwóch różnych usług monotoniczność
timestampu jest inna, wtedy PAT i system operacyjny dwóch komputerów są różne.
Jeżeli timestamp pobrany z dwóch portów nie należy do tej samej prostej, wtedy
jest to ten sam system ale nie ten sam komputer.
Inną interesującą funkcją PAT-u jest round robin (od tł.: w wolnym
tłumaczeniu jest to okrągły rudzik). Do teraz nie było żadnej możliwości żeby się
dowiedzieć czy taki mechanizm został użyty. Przez porównywanie różnych
zebranych timestampów możesz ustalić ile hostów jest za pojedyńczym portem.
Dodanie takiej funkcji w aktywnym skanerze mogło być ciekawe.
----[ 2.7 Czas na zwalczanie
Od czasu kiedy gra z tą opcją mogła dać cenne informacje, jest tam
jakieś ograniczenie na tą technikę. Stacje windowsowe właściwie nie używają
rozwiązania timestamp kiedy ustanawiają połączenie [8] chyba że je
aktywujesz. To ograniczenie oddziałuje tylko na pasywną analizę, jeżeli
używasz timestamp do łączenia się z Windowsem to on także będzie tego
używał. Ponadto wiele ściąganych programów aktywuje rozszerzenie TCP w
Windowsie.
Żeby zakończyć temat chciałbym nadmienić że wydaje się że rozszerzenie TCP
nie istnieje w Windows 9X.
Jednym z innych problemów jest przerwa czasowa. W trybie pasywnym może być tam
desynchronizacja pomiędzy komputerami spowodowana komputerową
desynchronizacją lub sieciowymi opóźnieniami. W dowodzie koncepcji to
zjawisko może się przytrafić. Żeby to załatwić nie musisz polegać na
komputerowym zegarze ale na timestamp.
Co możemy zrobić w stosunku do tego? Od czasu kiedy żaden sprzedawca prócz
Microsoftu (1) (dzięki Magnus) nie zadał mi pytania, następujące
obejścia mogą nie być dostępne:
1) Wyłączanie TCP timestamp. To jest gorsze rozwiązanie ponieważ będziemy
tego potrzebowali mimo szybkiej sieci.
2) Przepisanie NAT-u na timestamp i zmienianie The NAT RFC.
3) Zmienianie zawartości RFC na taką że rozwiązanie timestamp musi mieć
przypadkowy przyrost. Modyfikowanie każdej implementacji odbija tą
zmianę. Czyste rozwiązanie utwierdzające tą rzecz ponieważ to nie
polega na zewnętrznym systemie (komputer z NAT-em w tym wypadku).
Więc muszę spróbować być tak kompletnym jak to możliwe w tej technicznej
części. Następna część będzie bardziej "filozoficzna" zaczynając od tego jak
to ma do czynienia z powodem zamiast konsekwencji.
--[ 3.0 Historia ma nam coś do powiedzenia
W tej części spróbuję skupić się na tym dlaczego mamy taką sytuację i co
możemy z tym zrobić. Nie będę mówił tutaj o rozwiązaniu timestamp samym w
sobie ale o interakcji pomiędzy timestamp a mechanizmem NAT.
----[ 3.1 Która klasa?
Pierwsze pytanie brzmi: co jest bugiem? Ta dziura należy do modelu klasy
błędów. Bardziej precyzyjnie: bug istnieje ponieważ istnieje specyfikacja
protokołu. IP został zaprojektowany jako protokół jeden na jeden: jeden
klient mówi do jednego serwera. NAT narusza tą specyfikację przez
dopuszczenie wielokrotnych odwołań do jednego serwera. Z natury to nadużycie
powoduje wiele problemów dzięki którym tracę to co policzyłem, lecz jest to
dosyć pewne że najbardziej rekurencyjnym problemem jest transfer FTP. Jeżeli
używasz FTP to wiesz o co mi chodzi (inni mogą spojrzeć na netfilter ftp
conntrack).
----[ 3.2 Więc skąd to się wzięło?
Problem FTP jest dobrym przykładem aby wyjaśnić pochodzenie problemu
zachodzącej specyfikacji. FTP został wyspecyfikowany do pracy nad solidnym
połączeniem jeden do jednego (w rzeczywistości TCP). NAT został
zaprojektowany do modyfikacji IP. Więc dzięki zależnościom protokołu to
także zmienia TCP i przeto FTP.
Podczas specyfikacji NAT-u nie było brane pod uwagę że każdy protokół który
polega na IP, może wchodzić w konflikt ze zmodyfikowaną specyfikacją. Jeżeli
chciano powiedzieć prawdę, nawet jeżeli ludzie którzy zaprojektowali mechanizm
NAT kiedykolwiek potrzebowali gwarancji że każdy protokół który opiera się na
IP może pracować z NAT-em, nie można było tego zrobić.
Dlaczego? Ponieważ specyfikacje są w RFC i RFC jest po angielsku. Angielski
nie jest dobrym pomysłem na specyfikację rzeczy szczególnie jeżeli masz
wykres zależności dla specyfikacji.
Np. wiele języków programowania ma formalne specyfikcje. Która jest
pełniejszym dowodem rozwiązania. Rozwiązanir tego braku specyfikacji
znajduje się w historii Internetu [9]. W tym czasie pisząc mały tekst była to
dostateczna ilość. Teraz może to być problemem.
----[ 3.3 Jak to znaleźć?
Ważym pytaniem jest, jak mam znaleźć ten bug? Więc, znalazłem ten problem
przez formalizację części RFC TCP i porównanie wyniku tej analizy z
prawdziwymi śladami wykonania. Mój analizator (2) ostrzegł mnie że timestamp
był mniejszy niż jeden poprzedni i jak wiesz czas nie wróci...
Sprawdziłem dlaczego i jak znalazłem ten problem. Interesujące jest tutaj
to że punktem wyjścia do znalezienia tego błędu jest raczej specyfikacja niż
implementacja jak to zwykle można znaleźć przepełnienie bufora dla przykładu.
----[ 3.4 Powrót do przyszłości
Więc co się od tej porty będzie działo? Ano znajdowanych będzie więcej
projektowanych błędów ponieważ nie możemy zmienić przeszłości i musimy z tym
żyć.
Nie jest sensowne mówić że możemy ścierać wszystko to co materiał TCP i
rozpoczynać nową rzecz od zadrapania. Internet i sieć są po prostu za duże do
poruszania się w ten sposób. Najprościej mówiąc myślą co sekundę o rozlokowaniu
IP v6 i przekonasz się o tym. Wszystko co możemy zrobić to być tak ostrożnymi
jak to możliwe kiedy projektujemy jakieś nowe rozszerzenie lub protokół.
Próbujmy zapewniać że ten nowy materiał nie powoduje konfliktów z
poprzednimi wersjami lub nie narusza zależności. Możemy także próbować
formalizować protokoły tak dużo jak to możliwe i wykrywać błędy zanim
spowodują jakieś problemy. Łatanie błędów jest naszym głównym zadaniem na
najbliższe lata.
--[ 4.0 Nauka z przeszłości aka wniosek
Przeszłość mówi nam że protokół nie jest dostatecznie dobrze
wyspecyfikowany i prowadzi do błędów (bug, konflikt...). To może być czas na
zmianę naszych zwyczajów i próbę dodania czegoś na podstawie bilansu naszego
czasu. Np. do zaprojektowania naszych rzeczy bezpiecznie w umyśle. W tym
artykule spróbowałem pokazać wam że przez proste zrozumienie specyfikacji i
z pomocą podstawowej znajomości matematyki możesz:
- znaleźć usterkę o ogólnoświatowym wpływie,
- wykorzystać tą usterkę w elegancki sposób za pomocą prostej teorii,
- rozwijać sztukę fingerprintingu.
Mam nadzieję że to pomoże przekonać cię że teoria i formalne narzędzia są
niezbędną częścią obszaru bezpiecznego komputera. Następnym razem skupię się
na prostej formalnej metodzie znalezienia bugu. Mam nadzieję że tutaj
będziecie :)
--[ A Uznania
Najpierw chciałbym podziękować Romainowi Bottierowi za jego pomoc i jego
cierpliwość. Chcę także podziękować Plopsowi i Polucowi za wiarę we mnie.
Widzicie ludzie udało się nam!
Chcę także powiedzieć że biorę całkowitą odpowiedzialność za nie ujawnienie
polityki. Powiadomiłem głównych sprzedawców (Kernel.org, FreeBSD, OpenBSD,
Cisco...) miesiąc temu. Tak jak powiedziałem nie otrzymałem żadnej reakcji
więc dochodzę do wniosku że ich to nie obchodzi.
Referencje
*=*=*=*=*
[1] AT&T Steven M. Bellovin. A Technique for Counting NATted Hosts
http://www.research.att.com/~smb/papers/fnat.pdf
[2] Jacobson, Braden, & Borman. RFC 1323 :TCP Extensions for High
Performance.
[3] K. Egevang, Cray Communications, P. Francis. RFC 1631:
The IP Network Address Translator (NAT).
[4] Bret McDanel. TCP Timestamping - Obtaining System Uptime Remotely
originally posted to Bugtraq Security Mailing List on March 11, 2001.
[5] Michal Zalewski. p0f 2:Dr. Jekyll had something to Hyde.
[6] Fyodor. Nmap - Free Security Scanner For Network Exploration &
Security Audits.
[7] Antirez. dumbscan original BUGTRAQ posting (18 Dec 1998)
[8] Microsoft. TCP timestamp in windows : KB224829.
[9] Hafner, Katie, Matthew Lyon. Where Wizards Stay Up Late: The Origins of
the Internet.
Notatki
*=*=*=*
(1) Punktem widzenia Microsoftu jest to że NAT nie jest bezpiecznym
mechanizmem więc nie chcą tego łatać.
(2) Jesteś zainteresowany moim analizatorem? Mam nadzeję nadzieję że
niedługo opublikuję teoretyczny artykuł o tym jak to działa. Mam także
nadzieję wypuścić wkrótce jakąś wersję tego. Co do pytania czy znalazłem
inne interesujące rzeczy odpowiedź brzmi: może muszę to sprawdzić
bardziej dogłębnie.
--[ B Dowód koncepcji
/*
* Dowód koncepcji: liczenie hostów za NAT-em przy pomocy timestamp
* Żeby skompilować ten plik potrzebujesz libpcap
* Wszelkie prawa zatrzeżone dla Elie Bursztein (lupin@zonart.net)
* Kompilacja udała się na FreeBSD 5.X i Linux 2.6.X
*
* $ gcc natcount.c -o natcount -I/usr/local/include -L/usr/local/lib -lpcap
*/
#define __USE_BSD 1
#include <sys/time.h>
#include <time.h>
#include <netinet/in.h>
#include <net/ethernet.h>
#ifdef __FreeBSD__
#include <netinet/in_systm.h>
#endif /* __FreeBSD__ */
#ifdef __linux__
#include <linux/if_ether.h>
#endif /* __linux__ */
#include <netinet/ip.h>
#include <stdlib.h>
#include <string.h>
#include <pcap.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <net/if.h>
#include <netinet/tcp.h>
#include <netinet/udp.h>
#ifdef __linux__
#define th_off doff
#endif /* __linux__ */
u_int32_t addr = 0;
/* Łańcuch struktur list */
typedef struct listes_s {
struct listes_s *next;
void *elt;
} listes_t;
/* Struktury dla opcji TCP */
typedef struct { u_int32_t ts, ts_r; } timestamp_t;
typedef struct { timestamp_t *ts; } tcp_opt_t;
/* Struktury do składu danych */
typedef struct { u_int32_t from, first_timestamp; struct timeval
first_seen; } machine_t;
typedef struct { u_int32_t host, nat; struct timeval first_seen; }
nat_box_t;
#define TIMESTAMP_ERROR_MARGIN 0.5
#define DELAY 1
/* Lista funkcji */
int add_in_list(listes_t **list, void * elt) {
listes_t *lst;
lst = malloc(sizeof (listes_t));
lst->next = *list;
lst->elt = elt;
*list = lst;
return (1);
}
void show_nated(listes_t *list) {
nat_box_t *nat;
struct in_addr addr;
printf("-- Poczatek listy NAT-owanych adresow IP --\n");
while (list) {
nat = (nat_box_t *) list->elt;
if (nat->nat > 1) {
addr.s_addr = nat->host;
printf("Przypuszczam ze %i komputerow rozdziela te same adresy
(%s)\n", nat->nat, inet_ntoa(addr));
}
list = list->next;
}
printf("-- Koniec listy NAT-owanych adresow IP --\n");
}
/* Funkcja używana do pobierania wszystkich opcji TCP.
* Prosty parser opcji TCP */
int tcp_option_parser(const u_char *options, tcp_opt_t *parsed, unsigned int
size) {
u_int8_t kind, len, i;
bzero(parsed, sizeof(tcp_opt_t));
i = 0;
kind = *(options + i);
while (kind != 0) /* EO */ {
switch (kind) {
case 1:
i++;
break; /* Bajt NOP */
case 2:
i += 4;
break;
case 3:
i += 3;
break;
case 4:
i += 2;
break;
case 5: /* pominięcie opcji SACK */
len = (*options + ++i) - 1;
i += len;
break;
case 6:
i += 6;
break;
case 7:
i += 6;
break;
case 8:
i += 2;
parsed->ts = (timestamp_t *) (options + i);
i += 8;
return (1);
break;
default:
i++;
}
kind = *(options + i);
}
return (0);
}
/* Najbardziej interesująca funkcja... Tutaj możemy sie dowiedzieć czy
* pakiet TCP pochodzi od kogoś kogo już znamy!
*
* Prototyp:
* finc(sekundy) = aktualny_czas_pakietu - pierwszy_czas_pakietu <-
* czas_pomiedzy_dwoma_pakietami
* ts_inc = inc_table[i] * finc <-
* nasz_przypuszczalny_inkrementowany_timestamp_pomiedzy_dwoma_pakietami
* new_ts = pierwszy_timestamp + ts_inc <- new *
timestamp_ktory_powinnismy_miec_teraz!
*
* Teraz musimy poprostu porównać new_ts z aktualnym czasem timestampu.
* Możemy autoryzować marginesowy błąd od 0.5%.
*
* Nasza inc_table zawiera inkrementowany co sekundę timestamp dla wielu
* systemów operacyjnych. */
int already_seen(machine_t *mach, tcp_opt_t *opt, struct timeval temps)
{
int inc_table[4] = {2, 10, 100, 1000};
unsigned int new_ts;
float finc, tmp, ts_inc;
int i, diff;
finc = ((temps.tv_sec - mach->first_seen.tv_sec) * 1000000.
+ (temps.tv_usec - mach->first_seen.tv_usec)) / 1000000.;
for (i = 0; i < 4; i++) {
ts_inc = inc_table[i] * finc;
new_ts = ts_inc + mach -> first_timestamp;
diff = ntohl(opt->ts->ts) - new_ts;
if (diff == 0) { /* Celny strzał! */
return (2);
}
tmp = 100. - (new_ts * 100. / ntohl(opt->ts->ts));
if (tmp < 0.)
tmp *= -1.;
if (tmp <= TIMESTAMP_ERROR_MARGIN) { /* Uaktualniony timestamp i czas */
mach -> first_seen = temps;
mach -> first_timestamp = ntohl(opt->ts->ts);
return (1);
}
}
return (0);
}
/* Zwykła funkcja sprawdzająca czy adres IP jest już w naszej liście. Jeżeli
* nie to jest to tylko nowe połączenie. */
int is_in_list(listes_t *lst, u_int32_t addr)
{
machine_t *mach;
while (lst) {
mach = (machine_t *) lst -> elt;
if (mach -> from == addr)
return (1);
lst = lst -> next;
}
return (0);
}
/* Ta funkcja powinna być wywoływana jeżeli pakiet z adresu IP został
* znaleziony, jeśli adres jest już w liście ale nie pasuje do żadnej
* wartości timestamp. */
int update_nat(listes_t *list, u_int32_t addr)
{
nat_box_t *box;
while (list) {
box = (nat_box_t *) list -> elt;
if (box->host == addr) {
box->nat++;
return (1);
}
list = list->next;
}
return (0);
}
int check_host(listes_t **list, listes_t **nat, u_int32_t from,
tcp_opt_t *opt, struct timeval temps)
{
listes_t *lst;
machine_t *mach;
int found, zaped;
found = zaped = 0;
lst = *list;
while (lst && !(found)) {
mach = (machine_t *) lst -> elt;
if (mach -> from == from) {
if (temps.tv_sec - mach -> first_seen.tv_sec > DELAY) {
found = already_seen(mach, opt, temps);
}
else
zaped = 1;
}
lst = lst->next;
}
if (!(zaped) && !(found)) {
mach = malloc(sizeof (machine_t));
mach -> from = from;
mach -> first_seen = temps;
mach -> first_timestamp = ntohl(opt->ts->ts);
add_in_list(list, mach);
update_nat(*nat, from);
show_nated(*nat);
return (1);
}
return (0);
}
void callback_sniffer(u_char *useless, const struct pcap_pkthdr* pkthdr,
const u_char *packet)
{
static listes_t *list_machines = 0;
static listes_t *list_nat = 0;
const struct ip *ip_h;
const struct tcphdr *tcp_h;
tcp_opt_t tcp_opt;
machine_t *mach;
nat_box_t *nat;
struct in_addr my_addr;
ip_h = (struct ip *) (packet + sizeof(struct ether_header));
if (ip_h -> ip_p == IPPROTO_TCP) {
tcp_h = (struct tcphdr *) (packet + sizeof(struct ether_header) +
sizeof(struct ip));
if (tcp_h -> th_off * 4 > 20) {
if (tcp_option_parser((u_char *) (packet + sizeof(struct
ether_header) + sizeof(struct ip) + sizeof(struct tcphdr)),
&tcp_opt, tcp_h->th_off * 4 - 20)) {
if (is_in_list(list_machines, (ip_h->ip_src).s_addr)) {
check_host(&list_machines, &list_nat, (u_int32_t)
(ip_h->ip_src).s_addr, &tcp_opt, pkthdr->ts);
}
else {
if (ntohl(tcp_opt.ts -> ts) != 0) {
addr = (ip_h -> ip_src).s_addr;
my_addr.s_addr = addr;
mach = malloc(sizeof(machine_t));
mach -> from = (ip_h -> ip_src).s_addr;
mach -> first_seen = pkthdr -> ts;
mach -> first_timestamp = ntohl(tcp_opt.ts -> ts);
nat = malloc(sizeof(nat_box_t));
nat -> host = (u_int32_t) (ip_h -> ip_src).s_addr;
nat -> nat = 1;
nat -> first_seen = mach -> first_seen;
add_in_list(&list_machines, mach);
add_in_list(&list_nat, nat);
}
}
}
}
}
}
int main(int ac, char *argv[])
{
pcap_t *sniff;
char errbuf[PCAP_ERRBUF_SIZE];
struct bpf_program fp;
char *device;
bpf_u_int32 maskp, netp;
struct in_addr my_ip_addr;
char filter[250];
if (getuid() != 0) {
printf("Musisz byc rootem zeby uzywac tego narzedzia.\n");
exit (2);
}
if (--ac != 1) {
printf("Uzycie: ./natcount xl0\n");
return (1);
}
device = (++argv)[0];
pcap_lookupnet(device, &netp, &maskp, errbuf);
my_ip_addr.s_addr = (u_int32_t) netp;
printf("Uzywany interfejs IP %s: %s\n", device, inet_ntoa(my_ip_addr));
if ((sniff = pcap_open_live(device, BUFSIZ, 1, 1000, errbuf)) == NULL) {
printf("ERR: %s\n", errbuf);
exit(1);
}
bzero(filter, 250);
snprintf(filter, 250, "not src net %s", inet_ntoa(my_ip_addr));
if (pcap_compile(sniff,&fp, filter, 0, netp) == -1) {
fprintf(stderr,"Blad nazywany pcap_compile\n");
exit(1);
}
if (pcap_setfilter(sniff,&fp) == -1) {
fprintf(stderr, "Blad ustawienia filtra\n");
exit(1);
}
pcap_loop(sniff, -1, callback_sniffer, NULL);
return (0);
}
2. Epilog
To by było na tyle. I pamiętajcie że głowa jest pełna pomysłów.
Analiza podejrzanych plików i procesów
1. Prolog
Elo! Oto kolejne tłumaczenie Phrack w moim wykonaniu, czyli Bartłomieja
Korpały. Innym znany jestem bliżej jako seprob. Tym razem jest to
tłumaczenie pliku Lineonise.txt z numeru 63. Zawarte są w nim trzy artykuły
i ze względu na objętość postanowiłem podzielić to na trzy osobne artykuły.
W tym wydaniu możecie przeczytać artykuł "Analiza podjerzanych plików
binarnych i procesów". Miłej lektury...
==Phrack Inc.==
Tom 0x0b, Wydanie 0x3f, Plik #0x03-1 z 0x14
|=-------------------------=[ 0x03-1 ]=----------------------------------=|
|=---------Analiza podejrzanych plików binarnych i procesów--------------=|
|=-----------------------------------------------------------------------=|
|=-----------------------Boris Loza, PhD---------------------------------=|
|=-------------------bloza@tegosystemonline.com--------------------------=|
|=-----------------------------------------------------------------------=|
1. Wprowadzenie
2. Analizowanie 'nieznanego' pliku binarnego
3. Analizowanie 'nieznanego' procesu
4. Bezpieczeństwo dochodzeniowe, używanie DTrace
5. Konkluzja
--[ Wprowadzenie
Artykuł o bezpieczeństwie dochodzeniowym wymaga dużo cierpliwości,
kreatywności i obserwacji. Nie zawsze może Ci się powodzić w Twoich
staraniach ale stałe 'wyostrzanie' swoich umiejętności przez praktykowanie
uczy kilku rzeczy więcej tu i tam które w przyszłości będą pomocne.
W tym artykule chciałbym przedstawic moje własne doświadczenia w analizie
podejrzanych plików binarnych i procesów żebyś mógł je znaleźć w systemie.
Będziemy używać tylko standardowych, spoza skrzynki, użytecznych narzędzi
UNIX-a. Wszystkie przykłady w tym artykule są przedstawianie w oparciu o
system Solaris.
--[ Analizowanie 'nieznanego' pliku binarnego
Podczas swojego dochodzenia możesz spotkać jakieś wykonywalne (binarne)
pliki których przeznaczenia w Twoim systemie nie możesz zrozumieć. Kiedy
próbujesz przeczytać taki plik on wyświetla 'śmieci'. Możesz poznać ten plik
po nazwie ale nie jesteś pewny czy widziałeś go przedtem.
Na szczęście, nie możesz czytać pliku binarnego przez more, cat, pg, vi czy
innymi narzędziami których normalnie używasz do czytania plików tekstowych.
Będziesz potrzebował innych narzędzi. W porządku, do czytania takich plików
ja używam następujacych narzędzi: strings, file, ldd, adb i innych.
Podsumujmy, na przykład znaleźliśmy plik o nazwie cr1 w katalogu /etc/.
Pierwszą komenda użytą do uruchomienia tego pliku jest strings(1). To
polecenie pokaże wszystkie drukowalne łańcuchy w obiekcie lub pliku binarnym:
$ strings cr1 | more
%s %s %s%s%s -> %s%s%s (%.*s)
Version: 2.3
Using: dsniff [-cdmn] [-i interface] [-s snaplen] [-f services]
[-t trigger[,...]] [-r|-w savefile] [expression]
...
/usr/local/lib/dsniff.magic
/usr/local/lib/dsniff.services
...
Całość pokazana przez to polecenie jest bardzo długa, więc nie została
pokazana. Ale możesz obejrzeć to co zostało pokazane jeżeli to jest aktualne
narzędzie dsniff jako cr1.
Czasami nie będziesz miał szczęścia w wyszukiwaniu nazwy programu, jego
wersji oraz użycia wewnątrz pliku. Jeżeli nadal nie wiesz co ten plik robi,
spróbuj uruchomić strings z parametrem 'a', albo tylko '-'. Z tymi opcjami
strings będzie wypatrywał łancuchy gdziekolwiek w pliku. Jeżeli ten parametr
został opuszczony, strings wyszukuje tylko odstepów inicjowanych danych
danego pliku:
$ strings cr1 | more
Spróbuj porównać rownież dane wyjściowe ze znanych Ci plików binarnych,
żeby zgadnąć czym ten program mógłby być.
Alternatywnie możesz uzyć komendy nm(1) zeby wyświetlić listę nazw danego
pliku:
$ /usr/ccs/bin/nm -p cr1 | more
cr1:
[Index] Value Size Type Bind Other Shndx Name
[180] |0 | 0| FILE | LOCL | 0 |ABS | decode_smtp.c
[2198] |160348| 320| FUNC | GLOB | 0 | 9 | decode_sniffer
Zaznaczam że dane wyjściowe tej komendy mogą zawierać się w tysiącach
linii, w zależności od rozmiaru danego pliku. Możesz uruchomic nm przez
tunel do more lub pg, albo przekierować do pliku i później zanalizować.
Żeby sprawdzić tabele symboli czasu wykonywania linkera - wywołaj algorytm
dzielonej biblioteki, użyj nm z opcjami '-Du', gdzie '-D' wyświetla symbol
tablicy użytej przez ld.so.1 i jest prezentowany nawet w zdjętej dynamicznej
tablicy wykonywania, i '-u' pokazuje długi listing dla każdego
niezdefiniowanego symbolu.
Możesz także wyrzucić wybrane części każdego binarnego pliku przy pomocy
narzędzia dump(1) lub elfdump(1). Następujace łancuchy wyrzuca tabele
łancuchów pliku cr1:
$ /usr/ccs/bin/dump -c ./cr1 | more
Możesz użyć następujących opcji do wyrzucenia romaitych części pliku:
-c Wyrzuć tabele znaku/znaków
-C Wyrzuć zdekodowane tabele nazw symboli C++
-D Opuść debagowanie informacji
-f Wyrzuć każdy nagłówek pliku
-h Wyrzuć sekcje nagłówków
-l Wyrzuć informacje o numerze linii
-L Opuść dynamiczne linkowanie informacji i informacje częściowej
biblioteki, jeżeli są dostępne
-o Wyrzuć każdy nagłówek wykonywania programu
-r Opuść ponowne ulokowanie informacji
-s Wyrzuć sekcje treści w systemie szesnastkowym
-t Wyrzuć wejścia tabeli symbolu
Notatka: Aby wyświetlic wewnętrzną informację o wersji zawartą wewnatrz
pliku ELF, użyj narzędzia pvs(1).
Jeżeli nadal nie jesteś pewny do czego dany plik służy, użyj komendy file(1):
$ file cr1
cr1: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+
Required, UltraSPARC1 Extensions Required, dynamically linked, not
stripped
Na tej podstawie możemy powiedzieć że jest to plik wykonywalny dla SPARC,
wymagający dostępu do bibliotek ładowanych przez system operacyjny
(dynamicznie linkowanych). Ten plik nie jest także zdjęty, co znaczy że
tabele symboli nie były usunięte z kompilowanej binarki. To pomoże nam w
dużej mierze podczas przyszłej analizy.
Notatka: Aby zdjąć symbol, użyj strip <mój_plik>.
Komenda file może także nam powiedzieć, że plik binarny jest statycznie
linkowany, z debagowanymi lub rozebranymi danymi wyjściowymi.
Statycznie linkowane oznacza że wszystkie funkcje są włączone w binarce,
ale rezultaty w większym pliku wykonywalnym. Debagowane dane wyjściowe -
włączają debagowane symbole, jak zmienne nazwy, funkcje, wewnętrzne symbole,
numery linii kodu oraz informacje o pliku źródłowym. Jeżeli plik jest
zdjęty, to rozmiar jest o wiele mniejszy.
Komenda file identyfikuje typ używanego pliku, wśród innych testów, testów
w rodzaju czy plik rozpoczyna się z pewną liczbą magiczną (zobacz plik
/etc/magic). Liczba magiczna jest numeryczną lub stałą łańcuchową, która
wskazuje na typ pliku. Obejrzyj magic(4) w celu wytłumaczenia formatu pliku
/etc/magic.
Jeżeli nadal nie wiesz w jakim celu wykorzystywany jest dany plik, spróbuj
zgadnąć to przez obejrzenie które dzielone biblioteki są potrzebne binarce,
używając komendy ldd(1):
$ ldd cr1
...
libsocket.so.1 => /usr/lib/libsocket.so.1
librpcsvc.so.1 => /usr/lib/librpcsvc.so.1
...
Te dane wyjściowe mowią że ta aplikacja wymaga częściowo bibliotek
sieciowych (libsocket.so.1 i librpcsvc.so.1).
Debugger adb(1) także może być bardzo użyteczny. Np. następujace dane
wyjściowe pokazują krok po kroku binarki w zapytaniu:
# adb cr1
:s
adb: target stopped at:
ld.so.1_rt_boot: ba,a +0xc
<ld.so.1_rt_boot+0xc>
,5:s
adb: target stopped at:
ld.so.1_rt_boot+0x58: st %l1, [%o0 + 8]
Może także ten plik zanalizować lub uruchomić go i zobaczyć jak aktualnie
pracuje. Ale bądź ostrożny kiedy uruchamiasz aplikacje, ponieważ nie wiesz
jeszcze czego masz się spodziewać. Na przykład:
# adb cr1
:r
Using device /dev/hme0 (promiscuous mode)
192.168.2.119 -> web TCP D=22 S=1111 Ack=2013255208
Seq=1407308568 Len=0 Win=17520
web -> 192.168.2.119 TCP D=1111 S=22 Push Ack=1407308568
Możemy zauważyć że ten program jest snifferem. Przeczytaj stronę man adb(1)
aby uzyskaż więcej informacji na temat używania tego debuggera.
Jeżeli jednak zdecydowałeś się uruchomić program, możesz uzyć truss(1).
Komenda truss pozwala Ci na uruchomienie programu dopóki wywołuje wywołania
systemowe i sygnały.
Notatka: truss wypisuje na wyjście bardzo dużo danych. Przekieruj dane
wyjściowe do pliku:
$ truss -f -o cr.out ./cr1
listening on hme0
^C
$
Teraz możesz spokojnie badać dane wyjściowe w pliku cr.out.
Jak widzisz, wiele narzędzi i technik może być użytych do analizy
nieznanego pliku. Nie wszystkie pliki są łatwe w analizie. Jeżeli plik jest
statycznie linkowaną zdjętą binarką, może być o wiele trudniej znaleźć
odpowiedź na to do czego służy. Jeżeli nie możesz powiedzieć nic na temat
pliku używając prostych narzędzi jak strings i ldd, spróbuj go zdebagować i
użyc truss. Doświadczenie w używaniu i analizie danych wyjściowych tych
narzędzi, razem z dobrą ilościa cierpliwości, zakończy się sukcesem.
--[ Analizowanie 'nieznanego' pliku binarnego
Co zrobisz jeżeli znajdziesz proces, który jest uruchomiony w Twoim
systemie, ale nie wiesz co on robi? Tak, w Uniksie wszystko jest plikiem,
nawet proces! Może zaistnieć sytuacja, w której aplikacja zostanie
uruchomiona w systemie ale plik zostanie usunięty. W tej sytuacji proces
będzie nadal działał ponieważ odnośnik do tego procesu istnieje w katalogu
/proc/[PID]/object/a.out, ale możesz nie znaleźć procesu przez jego nazwę
uruchamiając komendę find(1).
Np. załóżmy że zaczęliśmy badać proces o numerze ID 22889 z podejrzanej
aplikacji srg, który znaleźliśmy uruchomiony w naszym systemie:
# ps -ef | more
UID PID PPID C STIME TTY TIME CMD
...
root 22889 16318 0 10:09:25 pts/1 0:00 ./srg
...
Czasami jest to tak proste jak uruchomienie komendy strings(1) w stosunku do
/proc/[PID]/object/a.out aby zidentyfikować proces.
# strings /proc/22889/object/a.out | more
...
TTY-Watcher version %s
Usage: %s [-c]
-c turns on curses interface
NOTE: Running without root privileges will only allow you to monitor
yourself.
...
Widzimy że ta komenda jest aplikacją TTY-Watcher, która widzi wszystkie
keystroke-i z każdego terminala w systemie.
Zakładamy że nie jesteśmy zdolni użyć strings w celu identyfikacji co ten
proces robi. Możemy zbadać proces innymi narzędziami.
Możesz zatrzymać proces dopóki nie pojmiesz czym jest. Np. uruchom komendę
kill -STOP 22889 jako root. Sprawdź rezultaty. Zobaczmy dla znaku 'T' który
określa które procesy zostały zatrzymane:
# /usr/ucb/ps | grep T
root 22889 0.0 0.7 3784 1720 pts/1 T 10:09:25 0:00 ./srg
Otrzymujemy z powrotem proces, w razie potrzeby użyjmy kill -CONT <PID>. Dla
potrzeb dalszej analizy procesu stworzymy \core dump\ zmiennych i stos
procesu:
# gcore 22889
gcore: core.22889 dumped
Tutaj 22889 jest numerem ID procesu (PID). Sprawdźmy wyniki core.22889
uźywając strings:
# strings core.22889 | more
...
TTY-Watcher version %s
Usage: %s [-c]
-c turns on curses interface
NOTE: Running without root privileges will only allow you to monitor
yourself.
...
Możesz użyć także coreadm(1M) do analizy pliku core.22889. Narzędzie
coreadm dostarcza interfejsy do zarządzania parametrami, które oddziałują na
tworzenie jądra pliku. Komenda coreadm modyfikuje plik /etc/coreadm.conf.
Ten plik jest czytany w czasie bootowania i ustawia globalne parametry dla
tworzenia core dump.
Najpierw ustawmy naszą nazwę pliku jądra w formie core.<PROC NAME>.<PID>.
Zrobimy to tylko dla wszystkich programów które wykonujemy w tej powłoce
(notacja $ wyrównuje PID naszej aktualnej powłoki):
$ coreadm -p core.%f.%p $
%f oznacza że nazwa programu będzie włączona, a %p informuje że PID będzie
dodany do nazwy pliku jądra.
Możesz także użyć adb do analizy procesu. Jeżeli nie posiadasz danego pliku,
użyj /proc/[PID]/object/a.out. Mozesz użyc pliku jądra w celu odrzucenia
procesu przez gcore lub sprecyzować '-' jako plik jądra. Jeżeli ociupina (-)
jest sprecyzowana dla pliku jądra, adb użyje systemowej pamięci do wykonania
danego pliku. Możesz faktycznie uruchomić dany plik pod kontrolą adb (to
może być niebezpieczne ponieważ nie jesteś pewny co ta aplikacja robi!):
# adb /proc/22889/object/a.out -
main:b
:r
breakpoint at:
main: save %sp, -0xf8, %sp
...
:s
stopped at:
main+4: clr %l0
:s
stopped at:
main+8: sethi %hi(0x38400), %o0
$m
? map
...
b11 = ef632f28 e11 = ef6370ac f11 = 2f28 /usr/lib/libsocket.so.1'
$q
Zaczynamy sesje przez ustawienie breakpointu w miejscu gdzie zaczyna się
funkcja main(), i później rozpoczynamy wykonywanie a.out przez podanie adb
komendy uruchamiającej ':r'. Natychmiast stajemy na main() gdzie został
ustawiony nasz breakpoint. Następnie listujemy pierwszą instrukcję z danego
pliku. Komenda ':s' mówi adb o tym kroku, wykonuje tylko jedną instrukcje
asemblerową na raz.
Notatka: Sprawdź ksiażkę Panic! autorstwa Drake'a i Browna, aby dowiedzieć się
więcej na temat używania adb w celu analizy core dump.
Do analizy uruchomionego procesu użyj truss:
# truss -vall -f -o /tmp/outfile -p 22889
# more /tmp/outfile
Na innych systemach uniksowych do których masz dostęp możesz śledzić proces
używając komendy ltrace lub strace. Aby rozpocząć śledzienie wklep ltrace -p
<PID>.
Aby obejrzeć środowisko uruchomionego procesu możesz użyć następującej
komendy:
# /usr/ucb/ps auxeww 22889
USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND
root 22889 0.0 0.4 1120 896 pts/1 S 14:15:27 0:00 -
sh _=/usr/bin/csh
MANPATH=/usr/share/man:/usr/local/man HZ=
PATH=/usr/sbin:/usr/bin:/usr/local/bin:/usr/ccs/bin:/usr/local/sbin:
/opt/NSCPcom/ LOGNAME=root SHELL=/bin/ksh HOME=/
LD_LIBRARY_PATH=/usr/openwin/lib:/usr/local/lib TERM=xterm TZ=
Katalog /usr/ucb/ zawiera pakiety komend zgodne z SunOS/BSD. Komenda
/usr/bin/ps wyświetla informacje o procesach. Użyliśmy następujących opcji
(ze strony manuala ps(1B)):
-a Włącza informacje o procesach należących do innych użytkowników
-u Wyświetla dane wyjściowe danego użytkownika. Opcja ta dołącza
części USER, %CPU, %MEM, SZ, RSS i START z wartościami
-x Dołącza procesy z niekontrolowanym terminalem
-e Wyświetla srodowisko jak i argumenty do komendy
-w Użyj szerokiego formatu danych wyjściowych (132 kolumny zamiast 80);
jeśli powtórzony, wtedy jest -ww, użyj szeroko dowolnych danych
wyjściowych. Ta informacja jest używana do decydowania jak długie komendy
wyświetlać.
Aby obejrzeć adres pamięci wpisz:
# ps -ealf | grep 22889
F S UID PID PPID C PRI NI ADDR SZ WCHAN
STIME TTY TIME CMD
8 S root 3401 22889 0 41 20 615a3b40 474 60ba32e6 14:16:49
pts/1 0:00 ./srg
Aby obejrzeć użycie pamięci wpisz:
# ps -e -opid,vsz,rss,args
PID VSZ RSS COMMAND
...
22889 3792 1728 ./srg
Mozemy zobaczyc że ./srg używa 3,792 K wirtualnej pamięci, 1,728 której było
alokowane z fizycznej pamięci.
Możesz zrobić użytek z /etc/crash(1M) do badania zawartości struktury proc
uruchomionego procesu:
# /etc/crash
dumpfile = /dev/mem, namelist = /dev/ksyms, outfile = stdout
> p
PROC TABLE SIZE = 3946
SLOT ST PID PPID PGID SID UID PRI NAME FLAGS
...
66 s 22889 16318 16337 24130 0 58 srg load
> p -f 66
PROC TABLE SIZE = 3946
SLOT ST PID PPID PGID SID UID PRI NAME FLAGS
66 s 22889 16318 16337 24130 0 58 srg load
Session: sid: 24130, ctty: vnode(60b8f3ac) maj( 24) min( 1)
...
>
Po spożytkowaniu crash, użylismy funkcji p do pobrania slotu tabeli procesu
(66 w tej części). Następnie aby wyrzucić strukturę proc dla procesu o
numerze PID 22889, ponownie zrobiliśmy użytek z p, dodając flage '-f' i
numer slotu tabeli procesu.
Jak struktura procesu, zawartość uarea wspierająca dane dla sygnałów, włącza
zestaw definicji dyspozycji dla wszystkich możliwych sygnałów. Dyspozycja
sygnału mówi systemowi operacyjnemu co zrobić w wypadku sygnału - zignorować
go, złapać go i wezwać nagłówek sygnału zdefiniowanego użytkownika lub
wykonać domyślną akcje. Aby wyrzucić uarea procesu:
> u 66
PER PROCESS USER AREA FOR PROCESS 66
PROCESS MISC:
command: srg, psargs: ./srg
start: Mon Jun 3 08:56:40 2002
mem: 6ad, type: exec su-user
vnode of current directory: 612daf48
...
>
Funckcja 'u' pobiera numer slotu tabeli procesu jako argument. Aby wyrzucić
przestrzeń adresu procesu, wklep:
# /usr/proc/bin/pmap -x 22889
Aby uzyskać listę otwartych plików procesu, użyj komendy /usr/proc/bin/pfiles:
# /usr/proc/bin/pfiles 22889
Komenda ta wypisuje nazwę procesu i PID dla otwartych plików procesu.
Zaznaczam że różne części informacji są akceptowane na poszczególnym
otwartym pliku, włączając typ pliku, flagę pliku, czśści trybu i rozmiar.
Jeżeli nie możesz znaleźć binarnego pliku i proces jest tylko w pamięci,
możesz nadal użyć opisanych metod w odniesieniu do analizy podejrzanych
plików binarnych rownież nad danymi plikami procesu. Na przykład:
# /usr/ccs/bin/nm a.out | more
a.out:
[Index] Value Size Type Bind Other Shndx Name
...
[636] | 232688| 4|OBJT |GLOB |0 |17 |Master_utmp
[284] | 234864| 20|OBJT |GLOB |0 |17 |Mouse_status
Mozesz użyć także mdb(1) - modularny debugger do analizy procesów:
# mdb -p 22889
Loading modules: [ ld.so.1 libc.so.1 libnvpair.so.1 libuutil.so.1 ]
> ::objects
BASE LIMIT SIZE NAME
10000 62000 52000 ./srg
ff3b0000 ff3dc000 2c000 /lib/ld.so.1
ff370000 ff37c000 c000 /lib/libsocket.so.1
ff280000 ff312000 92000 /lib/libnsl.so.1
--[ Bezpieczeństwo dochodzeniowe, używanie DTrace
Solaris 10 ma zaimplementowane nowe narzędzie do dynamicznego trasowania w
środowisku systemu operacyjnego - dtrace. Jest to bardzo potężne narzędzie
które pozwala administratorom systemów na obserwację i debagowanie
zachowania OS-u lub nawet na dynamiczną modyfikację kernela. Dtrace ma swój
własny język programowania jak C/C++ nazywany 'językiem D', i dostarcza
wielu różnych opcji ale nie mam zamiaru ich tutaj omawiać. Obejrzyj stronę
manuala dtrace(1M) a także zaglądnij na
http://docs.sun.com/app/docs/doc/817-6223 aby zdobyć więcej informacji.
Chociaż to narzędzie zostało zaprojektowane pierwotnie dla developerów i
administratorów, wyjaśnię jak ktoś może użyć dtrace do analizy podejrzanych
plików i procesów.
Będziemy dalej pracować nad studiowaniem przypadku jak nastepuje. Np.
przyjmijmy że badamy proces o ID 968 z podejrzanej aplikacji srg, którą
znaleźliśmy uruchomioną w naszym systemie.
Przez wpisanie następujących komend linii poleceń, wypiszesz wszystkie pliki
które otwiera ten określony proces. Poniższa komenda wykonuje daną czyność
dopóki nie zostanie wciśnięta kombinacja klawiszy Control-C:
# dtrace -n syscall::open:entry'/pid == 968/
{ printf("%s%s",execname,copyinstr(arg0)); }'
dtrace: description 'syscall::open*:entry' matched 2 probes
^C
CPU ID FUNCTION:NAME
0 14 open:entry srg /var/ld/ld.config
0 14 open:entry srg /lib/libdhcputil.so.1
0 14 open:entry srg /lib/libsocket.so.1
0 14 open:entry srg /lib/libnsl.so.1
Język D ma swoją własną terminologię, którą będę próbował tutaj krótko
przedstawić.
Całkowita konstrukcja 'syscall::open:entry' nazywana jest 'próbą' i
definiuje lokalizacje lub czynność do której dtrace dołącza odwołanie do
wypełnienia kompletu 'akcji'. Element 'wywołanie systemowe-syscall' próby
nazywany jest 'dostawcą' i, w naszym przypadku, zezwala próbom na
'wejście-entry' (start) do każdego 'otwartego-open' wywołania systemowego
Solarisa ('otwarte-open' wywołanie systemowe uczy kernel otwierać plik do
czytania i pisania).
Tzw. 'orzeczenie' - /pid == 968/ używa predefiniowanej zmiennej dtrace
'pid', zawsze oceniającą do procesu, ID towarzyszący wątkowi który zapalił
odpowiednie badanie.
'execname' i 'copyinstr(arg0)' nazywane są 'akcjami' i definiują nazwę
aktualnego pliku tabeli wykonywania procesu i konwertują pierwszy całkowity
argument wywołania systemowego (arg0) do odpowiedniego formatu łancucha.
Funckja printf używa takiej samej składni jak język C i używana jest w tym samym
celu - do formatowania danych wyjściowych.
Każdy program napisany w jezyku D składa się z serii 'warunków', każdy
warunek opisuje jedną lub więcej prób uzyskania upoważnien, i opcjonalnie
komplet wykonywanych funkcji kiedy próba zostaje odpalona. Akcje są listowane
jako serie wyrażeń zawartych w nawiasach klamrowych { } następujacej nazwy próby.
Każde wyrażenie zakończone jest średnikiem (;).
Możesz przeczytać Wprowadzenie do Przewodnika Trasowania w Solarisie
(http://docs.sun.com/app/docs/doc/817-6223) aby poznać więcej opcji i
zrozumieć wykonanie.
Notatka: Jak sugeruje nazwa, dtrace (Dynamic Trace) pokaże Ci informacje o
zmieniających się procesach - w dynamice. Tzn. że jeżeli proces jest
bezczynny (nie może wykonać żadnego wywołania systemowego lub otworzyć
nowego pliku), nie będziesz w stanie otrzymać żadnych informacji. Do analizy
procesu albo go zrestartuj albo użyj metod opisanych w dwóch poprzednich
sekcjach tego artykułu.
W kolejnej fazie użyjemy następującej konstrukcji linii komend aby
wyświetlić wszystkie wywołania systemowe dla 'srg'.
# dtrace -n 'syscall:::entry /execname == "srg"/ { @num[probefunc] =
count(); }'
dtrace: description 'syscall:::entry ' matched 226 probes
^C
pollsys 1
getrlimit 1
connect 1
setsockopt 1
...
Możesz dowiedzieć się trochę o budowanych elementach tego małego programu
pisanego w jezyku D. W dodatku ta klauzula definiuje zestaw nazwany 'run' i
wyznacza stosownego członka 'probefunc' (funkcja wykonanego wywołania
systemowego) ilość tych szczególnych funkcji powinna być liczona (count()).
Używając dtrace możemy łatwo emulować wszystkie użyteczne rzeczy które
używaliśmy w poprzedniej sekcji do analizy nieznanych plików binarnych i
procesów. Ale dtrace jest o wiele bardziej użytecznym narzędziem i dostarcza
o wiele więcej funkcji: np. możesz dynamicznie monitorować stos procesów
zapytaniem:
# dtrace -n 'syscall:::entry/execname == "srg"/{ustack()}'
0 286 lwp_sigmask:entry
libc.so.1__systemcall6+0x20
libc.so.1pthread_sigmask+0x1b4
libc.so.1sigprocmask+0x20
srgsrg_alarm+0x134
srgscan+0x400
srgnet_read+0xc4
srgmain+0xabc
srg_start+0x108
Bazując na wszystkich naszych doświadczeniach (zobacz listę otwartych
plików, wywołań systemowych i stos badany wyżej) możemy pozytywnie wnioskować
że srg jest aplikacją sieciową. Czy to jest napisane dla sieci? Sprawdźmy to
konstruując nastepującą komendę:
# dtrace -n 'mib:ip::/execname == "srg"/{@[execname]=count()}'
dtrace: description 'mib:ip::' matched 412 probes
dtrace: aggregation size lowered to 2m
^C
srg 520
Jest. Użylismy providera 'mib' aby wyjaśnic czy nasza aplikacja laczy się z
siecią.
To może być tylko sniffer lub aplikacja ala netcat bindowana na specyficznym
porcie? Uruchomimy dtrace w truss(1) jako wzór do odpowiedzenia sobie na to
pytanie (zainspirowane przez użyteczność dtruss Brendana Gregga):
#!/usr/bin/sh
#
dtrace='
inline string cmd_name = "'$1'";
/*
** Save syscall entry info
*/
syscall:::entry
/execname == cmd_name/
{
/* set start details */
self->start = timestamp;
self->arg0 = arg0;
self->arg1 = arg1;
self->arg2 = arg2;
}
/* Print data */
syscall::write:return,
syscall::pwrite:return,
syscall::*read*:return
/self->start/
{
printf("%s(0x%X, \"%S\", 0x%X)\t\t = %d\n",probefunc,self->arg0,
stringof(copyin(self->arg1,self->arg2)),self->arg2,(int)arg0);
self->arg0 = arg0;
self->arg1 = arg1;
self->arg2 = arg2;
}
'
# Run dtrace
/usr/sbin/dtrace -x evaltime=exec -n "$dtrace" >&2
Zapisz jako truss.d, dodaj prawa wykonywania i uruchom:
# ./truss.d srg
0 13 write:return write(0x1, " sol10 -
> 192.168.2.119 TCP D=3138 S=22 Ack=713701289 Seq=3755926338 Len=0
Win=49640\n8741 Len=52 Win=16792\n\0", 0x5B) = 91
0 13 0 13
write:return write(0x1, "192.168.2.111 -> 192.168.2.1 UDP D=1900
S=21405 LEN=140\n\0", 0x39) = 57
^C
Dla mnie wyglada jak sniffer, z prawdopodobieństwem jakiegoś zdalnego
logowania (przypomij sobie powyższą trasmisje sieciową przez ./srg odkrytą
przez providera 'mib'!).
Aktualnie możesz napisać jakieś niezłe i wymyślne programy dla dtrace
używając jezyka D.
Zobacz dla przykladu /usr/demo/dtrace.
Mozesz użyć także dtrace do innych czynności dochodzeniowych. Poniżej
znajduje się przykład bardziej kompleksowego skryptu, który pozwala na
monitorowanie kto odpala podejrzane aplikacje i rozpoczyna zapisywanie
wszystkich plików otwartych przez proces:
#!/usr/bin/sh
command=$1
/usr/sbin/dtrace -n '
inline string COMMAND = "'$command'";
#pragma D option quiet
/*
** Print header
*/
dtrace:::BEGIN
{
/* print headers */
printf("%-20s %5s %5s %5s %s\n","START_TIME","UID","PID","PPID","ARGS");
}
/*
** Print exec event
*/
syscall::exec:return, syscall::exece:return
/(COMMAND == execname)/
{
/* print data */
printf("%-20Y %5d %5d %5d %s\n",walltimestamp,uid,pid,ppid,
stringof(curpsinfo->pr_psargs));
s_pid = pid;
}
/*
** Print open files
*/
syscall::open*:entry
/pid == s_pid/
{
printf("%s\n",copyinstr(arg0));
}
'
Zapisz jako wait.d, dodaj prawa wykonywania 'chmod +x wait.d' i uruchom:
# ./wait.d srg
START_TIME UID PID PPID ARGS
2005 May 16 19:51:20 100 1582 1458 ./srg
/var/ld/ld.config
/lib/libnsl.so.1
/lib/libsocket.so.1
/lib/libresolv.so.2
...
^C
Widac każdorazowe uruchomienie srg.
Niemniej jednak prawdziwa siła dtrace pochodzi z faktu że możesz coś robic
z tym że to nie będzie możliwe bez napisania obszernego programu w C. Np.
aplikacja shellsnoop napisana przez Brendana Gregga
(http://users.tpg.com.au/adsln4yb/DTrace/shellsnoop) pozwala na użycie
dtrace przy objętości ttywatcher!
Nie możliwe jest żeby pokazać wszystkie możliwości dtrace w takiej małej
prezentacji tego niezwykle użytecznego narzędzia. Dtrace jest bardzo funckcjonalny
jak wiele kompleksowych narzędzi z niekończącymi się wirtualnymi możliwościami.
Aczkolwiek Sun upiera się że nie musisz posiadać 'głębokiego pojęcia o kernelu
żeby DTrace był dla Ciebie funckjonalny', znajomość istotnych wartości
Solarisa jest prawdziwym skarbem. Zobaczmy include-pliki w katalogu
/usr/include/sys/, może to pomoże Ci w napisaniu kompleksowego skryptu
języka D i da więcej informacji pomocnych w zrozumieniu jak Solaris 10 jest
implementowany.
--[ Konkluzja
Bądź kreatywnym i spotrzegawczym. Użyj całej swojej wiedzy i doświadczenia
do analizowania podejrzanych plików binarnych i procesów. A także bądź
cierpliwy i miej poczucie humoru!
2. Epilog
Mam nadzieję że wam się podobało. Elo!
Elo! Oto kolejne tłumaczenie Phrack w moim wykonaniu, czyli Bartłomieja
Korpały. Innym znany jestem bliżej jako seprob. Tym razem jest to
tłumaczenie pliku Lineonise.txt z numeru 63. Zawarte są w nim trzy artykuły
i ze względu na objętość postanowiłem podzielić to na trzy osobne artykuły.
W tym wydaniu możecie przeczytać artykuł "Analiza podjerzanych plików
binarnych i procesów". Miłej lektury...
==Phrack Inc.==
Tom 0x0b, Wydanie 0x3f, Plik #0x03-1 z 0x14
|=-------------------------=[ 0x03-1 ]=----------------------------------=|
|=---------Analiza podejrzanych plików binarnych i procesów--------------=|
|=-----------------------------------------------------------------------=|
|=-----------------------Boris Loza, PhD---------------------------------=|
|=-------------------bloza@tegosystemonline.com--------------------------=|
|=-----------------------------------------------------------------------=|
1. Wprowadzenie
2. Analizowanie 'nieznanego' pliku binarnego
3. Analizowanie 'nieznanego' procesu
4. Bezpieczeństwo dochodzeniowe, używanie DTrace
5. Konkluzja
--[ Wprowadzenie
Artykuł o bezpieczeństwie dochodzeniowym wymaga dużo cierpliwości,
kreatywności i obserwacji. Nie zawsze może Ci się powodzić w Twoich
staraniach ale stałe 'wyostrzanie' swoich umiejętności przez praktykowanie
uczy kilku rzeczy więcej tu i tam które w przyszłości będą pomocne.
W tym artykule chciałbym przedstawic moje własne doświadczenia w analizie
podejrzanych plików binarnych i procesów żebyś mógł je znaleźć w systemie.
Będziemy używać tylko standardowych, spoza skrzynki, użytecznych narzędzi
UNIX-a. Wszystkie przykłady w tym artykule są przedstawianie w oparciu o
system Solaris.
--[ Analizowanie 'nieznanego' pliku binarnego
Podczas swojego dochodzenia możesz spotkać jakieś wykonywalne (binarne)
pliki których przeznaczenia w Twoim systemie nie możesz zrozumieć. Kiedy
próbujesz przeczytać taki plik on wyświetla 'śmieci'. Możesz poznać ten plik
po nazwie ale nie jesteś pewny czy widziałeś go przedtem.
Na szczęście, nie możesz czytać pliku binarnego przez more, cat, pg, vi czy
innymi narzędziami których normalnie używasz do czytania plików tekstowych.
Będziesz potrzebował innych narzędzi. W porządku, do czytania takich plików
ja używam następujacych narzędzi: strings, file, ldd, adb i innych.
Podsumujmy, na przykład znaleźliśmy plik o nazwie cr1 w katalogu /etc/.
Pierwszą komenda użytą do uruchomienia tego pliku jest strings(1). To
polecenie pokaże wszystkie drukowalne łańcuchy w obiekcie lub pliku binarnym:
$ strings cr1 | more
%s %s %s%s%s -> %s%s%s (%.*s)
Version: 2.3
Using: dsniff [-cdmn] [-i interface] [-s snaplen] [-f services]
[-t trigger[,...]] [-r|-w savefile] [expression]
...
/usr/local/lib/dsniff.magic
/usr/local/lib/dsniff.services
...
Całość pokazana przez to polecenie jest bardzo długa, więc nie została
pokazana. Ale możesz obejrzeć to co zostało pokazane jeżeli to jest aktualne
narzędzie dsniff jako cr1.
Czasami nie będziesz miał szczęścia w wyszukiwaniu nazwy programu, jego
wersji oraz użycia wewnątrz pliku. Jeżeli nadal nie wiesz co ten plik robi,
spróbuj uruchomić strings z parametrem 'a', albo tylko '-'. Z tymi opcjami
strings będzie wypatrywał łancuchy gdziekolwiek w pliku. Jeżeli ten parametr
został opuszczony, strings wyszukuje tylko odstepów inicjowanych danych
danego pliku:
$ strings cr1 | more
Spróbuj porównać rownież dane wyjściowe ze znanych Ci plików binarnych,
żeby zgadnąć czym ten program mógłby być.
Alternatywnie możesz uzyć komendy nm(1) zeby wyświetlić listę nazw danego
pliku:
$ /usr/ccs/bin/nm -p cr1 | more
cr1:
[Index] Value Size Type Bind Other Shndx Name
[180] |0 | 0| FILE | LOCL | 0 |ABS | decode_smtp.c
[2198] |160348| 320| FUNC | GLOB | 0 | 9 | decode_sniffer
Zaznaczam że dane wyjściowe tej komendy mogą zawierać się w tysiącach
linii, w zależności od rozmiaru danego pliku. Możesz uruchomic nm przez
tunel do more lub pg, albo przekierować do pliku i później zanalizować.
Żeby sprawdzić tabele symboli czasu wykonywania linkera - wywołaj algorytm
dzielonej biblioteki, użyj nm z opcjami '-Du', gdzie '-D' wyświetla symbol
tablicy użytej przez ld.so.1 i jest prezentowany nawet w zdjętej dynamicznej
tablicy wykonywania, i '-u' pokazuje długi listing dla każdego
niezdefiniowanego symbolu.
Możesz także wyrzucić wybrane części każdego binarnego pliku przy pomocy
narzędzia dump(1) lub elfdump(1). Następujace łancuchy wyrzuca tabele
łancuchów pliku cr1:
$ /usr/ccs/bin/dump -c ./cr1 | more
Możesz użyć następujących opcji do wyrzucenia romaitych części pliku:
-c Wyrzuć tabele znaku/znaków
-C Wyrzuć zdekodowane tabele nazw symboli C++
-D Opuść debagowanie informacji
-f Wyrzuć każdy nagłówek pliku
-h Wyrzuć sekcje nagłówków
-l Wyrzuć informacje o numerze linii
-L Opuść dynamiczne linkowanie informacji i informacje częściowej
biblioteki, jeżeli są dostępne
-o Wyrzuć każdy nagłówek wykonywania programu
-r Opuść ponowne ulokowanie informacji
-s Wyrzuć sekcje treści w systemie szesnastkowym
-t Wyrzuć wejścia tabeli symbolu
Notatka: Aby wyświetlic wewnętrzną informację o wersji zawartą wewnatrz
pliku ELF, użyj narzędzia pvs(1).
Jeżeli nadal nie jesteś pewny do czego dany plik służy, użyj komendy file(1):
$ file cr1
cr1: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+
Required, UltraSPARC1 Extensions Required, dynamically linked, not
stripped
Na tej podstawie możemy powiedzieć że jest to plik wykonywalny dla SPARC,
wymagający dostępu do bibliotek ładowanych przez system operacyjny
(dynamicznie linkowanych). Ten plik nie jest także zdjęty, co znaczy że
tabele symboli nie były usunięte z kompilowanej binarki. To pomoże nam w
dużej mierze podczas przyszłej analizy.
Notatka: Aby zdjąć symbol, użyj strip <mój_plik>.
Komenda file może także nam powiedzieć, że plik binarny jest statycznie
linkowany, z debagowanymi lub rozebranymi danymi wyjściowymi.
Statycznie linkowane oznacza że wszystkie funkcje są włączone w binarce,
ale rezultaty w większym pliku wykonywalnym. Debagowane dane wyjściowe -
włączają debagowane symbole, jak zmienne nazwy, funkcje, wewnętrzne symbole,
numery linii kodu oraz informacje o pliku źródłowym. Jeżeli plik jest
zdjęty, to rozmiar jest o wiele mniejszy.
Komenda file identyfikuje typ używanego pliku, wśród innych testów, testów
w rodzaju czy plik rozpoczyna się z pewną liczbą magiczną (zobacz plik
/etc/magic). Liczba magiczna jest numeryczną lub stałą łańcuchową, która
wskazuje na typ pliku. Obejrzyj magic(4) w celu wytłumaczenia formatu pliku
/etc/magic.
Jeżeli nadal nie wiesz w jakim celu wykorzystywany jest dany plik, spróbuj
zgadnąć to przez obejrzenie które dzielone biblioteki są potrzebne binarce,
używając komendy ldd(1):
$ ldd cr1
...
libsocket.so.1 => /usr/lib/libsocket.so.1
librpcsvc.so.1 => /usr/lib/librpcsvc.so.1
...
Te dane wyjściowe mowią że ta aplikacja wymaga częściowo bibliotek
sieciowych (libsocket.so.1 i librpcsvc.so.1).
Debugger adb(1) także może być bardzo użyteczny. Np. następujace dane
wyjściowe pokazują krok po kroku binarki w zapytaniu:
# adb cr1
:s
adb: target stopped at:
ld.so.1_rt_boot: ba,a +0xc
<ld.so.1_rt_boot+0xc>
,5:s
adb: target stopped at:
ld.so.1_rt_boot+0x58: st %l1, [%o0 + 8]
Może także ten plik zanalizować lub uruchomić go i zobaczyć jak aktualnie
pracuje. Ale bądź ostrożny kiedy uruchamiasz aplikacje, ponieważ nie wiesz
jeszcze czego masz się spodziewać. Na przykład:
# adb cr1
:r
Using device /dev/hme0 (promiscuous mode)
192.168.2.119 -> web TCP D=22 S=1111 Ack=2013255208
Seq=1407308568 Len=0 Win=17520
web -> 192.168.2.119 TCP D=1111 S=22 Push Ack=1407308568
Możemy zauważyć że ten program jest snifferem. Przeczytaj stronę man adb(1)
aby uzyskaż więcej informacji na temat używania tego debuggera.
Jeżeli jednak zdecydowałeś się uruchomić program, możesz uzyć truss(1).
Komenda truss pozwala Ci na uruchomienie programu dopóki wywołuje wywołania
systemowe i sygnały.
Notatka: truss wypisuje na wyjście bardzo dużo danych. Przekieruj dane
wyjściowe do pliku:
$ truss -f -o cr.out ./cr1
listening on hme0
^C
$
Teraz możesz spokojnie badać dane wyjściowe w pliku cr.out.
Jak widzisz, wiele narzędzi i technik może być użytych do analizy
nieznanego pliku. Nie wszystkie pliki są łatwe w analizie. Jeżeli plik jest
statycznie linkowaną zdjętą binarką, może być o wiele trudniej znaleźć
odpowiedź na to do czego służy. Jeżeli nie możesz powiedzieć nic na temat
pliku używając prostych narzędzi jak strings i ldd, spróbuj go zdebagować i
użyc truss. Doświadczenie w używaniu i analizie danych wyjściowych tych
narzędzi, razem z dobrą ilościa cierpliwości, zakończy się sukcesem.
--[ Analizowanie 'nieznanego' pliku binarnego
Co zrobisz jeżeli znajdziesz proces, który jest uruchomiony w Twoim
systemie, ale nie wiesz co on robi? Tak, w Uniksie wszystko jest plikiem,
nawet proces! Może zaistnieć sytuacja, w której aplikacja zostanie
uruchomiona w systemie ale plik zostanie usunięty. W tej sytuacji proces
będzie nadal działał ponieważ odnośnik do tego procesu istnieje w katalogu
/proc/[PID]/object/a.out, ale możesz nie znaleźć procesu przez jego nazwę
uruchamiając komendę find(1).
Np. załóżmy że zaczęliśmy badać proces o numerze ID 22889 z podejrzanej
aplikacji srg, który znaleźliśmy uruchomiony w naszym systemie:
# ps -ef | more
UID PID PPID C STIME TTY TIME CMD
...
root 22889 16318 0 10:09:25 pts/1 0:00 ./srg
...
Czasami jest to tak proste jak uruchomienie komendy strings(1) w stosunku do
/proc/[PID]/object/a.out aby zidentyfikować proces.
# strings /proc/22889/object/a.out | more
...
TTY-Watcher version %s
Usage: %s [-c]
-c turns on curses interface
NOTE: Running without root privileges will only allow you to monitor
yourself.
...
Widzimy że ta komenda jest aplikacją TTY-Watcher, która widzi wszystkie
keystroke-i z każdego terminala w systemie.
Zakładamy że nie jesteśmy zdolni użyć strings w celu identyfikacji co ten
proces robi. Możemy zbadać proces innymi narzędziami.
Możesz zatrzymać proces dopóki nie pojmiesz czym jest. Np. uruchom komendę
kill -STOP 22889 jako root. Sprawdź rezultaty. Zobaczmy dla znaku 'T' który
określa które procesy zostały zatrzymane:
# /usr/ucb/ps | grep T
root 22889 0.0 0.7 3784 1720 pts/1 T 10:09:25 0:00 ./srg
Otrzymujemy z powrotem proces, w razie potrzeby użyjmy kill -CONT <PID>. Dla
potrzeb dalszej analizy procesu stworzymy \core dump\ zmiennych i stos
procesu:
# gcore 22889
gcore: core.22889 dumped
Tutaj 22889 jest numerem ID procesu (PID). Sprawdźmy wyniki core.22889
uźywając strings:
# strings core.22889 | more
...
TTY-Watcher version %s
Usage: %s [-c]
-c turns on curses interface
NOTE: Running without root privileges will only allow you to monitor
yourself.
...
Możesz użyć także coreadm(1M) do analizy pliku core.22889. Narzędzie
coreadm dostarcza interfejsy do zarządzania parametrami, które oddziałują na
tworzenie jądra pliku. Komenda coreadm modyfikuje plik /etc/coreadm.conf.
Ten plik jest czytany w czasie bootowania i ustawia globalne parametry dla
tworzenia core dump.
Najpierw ustawmy naszą nazwę pliku jądra w formie core.<PROC NAME>.<PID>.
Zrobimy to tylko dla wszystkich programów które wykonujemy w tej powłoce
(notacja $ wyrównuje PID naszej aktualnej powłoki):
$ coreadm -p core.%f.%p $
%f oznacza że nazwa programu będzie włączona, a %p informuje że PID będzie
dodany do nazwy pliku jądra.
Możesz także użyć adb do analizy procesu. Jeżeli nie posiadasz danego pliku,
użyj /proc/[PID]/object/a.out. Mozesz użyc pliku jądra w celu odrzucenia
procesu przez gcore lub sprecyzować '-' jako plik jądra. Jeżeli ociupina (-)
jest sprecyzowana dla pliku jądra, adb użyje systemowej pamięci do wykonania
danego pliku. Możesz faktycznie uruchomić dany plik pod kontrolą adb (to
może być niebezpieczne ponieważ nie jesteś pewny co ta aplikacja robi!):
# adb /proc/22889/object/a.out -
main:b
:r
breakpoint at:
main: save %sp, -0xf8, %sp
...
:s
stopped at:
main+4: clr %l0
:s
stopped at:
main+8: sethi %hi(0x38400), %o0
$m
? map
...
b11 = ef632f28 e11 = ef6370ac f11 = 2f28 /usr/lib/libsocket.so.1'
$q
Zaczynamy sesje przez ustawienie breakpointu w miejscu gdzie zaczyna się
funkcja main(), i później rozpoczynamy wykonywanie a.out przez podanie adb
komendy uruchamiającej ':r'. Natychmiast stajemy na main() gdzie został
ustawiony nasz breakpoint. Następnie listujemy pierwszą instrukcję z danego
pliku. Komenda ':s' mówi adb o tym kroku, wykonuje tylko jedną instrukcje
asemblerową na raz.
Notatka: Sprawdź ksiażkę Panic! autorstwa Drake'a i Browna, aby dowiedzieć się
więcej na temat używania adb w celu analizy core dump.
Do analizy uruchomionego procesu użyj truss:
# truss -vall -f -o /tmp/outfile -p 22889
# more /tmp/outfile
Na innych systemach uniksowych do których masz dostęp możesz śledzić proces
używając komendy ltrace lub strace. Aby rozpocząć śledzienie wklep ltrace -p
<PID>.
Aby obejrzeć środowisko uruchomionego procesu możesz użyć następującej
komendy:
# /usr/ucb/ps auxeww 22889
USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND
root 22889 0.0 0.4 1120 896 pts/1 S 14:15:27 0:00 -
sh _=/usr/bin/csh
MANPATH=/usr/share/man:/usr/local/man HZ=
PATH=/usr/sbin:/usr/bin:/usr/local/bin:/usr/ccs/bin:/usr/local/sbin:
/opt/NSCPcom/ LOGNAME=root SHELL=/bin/ksh HOME=/
LD_LIBRARY_PATH=/usr/openwin/lib:/usr/local/lib TERM=xterm TZ=
Katalog /usr/ucb/ zawiera pakiety komend zgodne z SunOS/BSD. Komenda
/usr/bin/ps wyświetla informacje o procesach. Użyliśmy następujących opcji
(ze strony manuala ps(1B)):
-a Włącza informacje o procesach należących do innych użytkowników
-u Wyświetla dane wyjściowe danego użytkownika. Opcja ta dołącza
części USER, %CPU, %MEM, SZ, RSS i START z wartościami
-x Dołącza procesy z niekontrolowanym terminalem
-e Wyświetla srodowisko jak i argumenty do komendy
-w Użyj szerokiego formatu danych wyjściowych (132 kolumny zamiast 80);
jeśli powtórzony, wtedy jest -ww, użyj szeroko dowolnych danych
wyjściowych. Ta informacja jest używana do decydowania jak długie komendy
wyświetlać.
Aby obejrzeć adres pamięci wpisz:
# ps -ealf | grep 22889
F S UID PID PPID C PRI NI ADDR SZ WCHAN
STIME TTY TIME CMD
8 S root 3401 22889 0 41 20 615a3b40 474 60ba32e6 14:16:49
pts/1 0:00 ./srg
Aby obejrzeć użycie pamięci wpisz:
# ps -e -opid,vsz,rss,args
PID VSZ RSS COMMAND
...
22889 3792 1728 ./srg
Mozemy zobaczyc że ./srg używa 3,792 K wirtualnej pamięci, 1,728 której było
alokowane z fizycznej pamięci.
Możesz zrobić użytek z /etc/crash(1M) do badania zawartości struktury proc
uruchomionego procesu:
# /etc/crash
dumpfile = /dev/mem, namelist = /dev/ksyms, outfile = stdout
> p
PROC TABLE SIZE = 3946
SLOT ST PID PPID PGID SID UID PRI NAME FLAGS
...
66 s 22889 16318 16337 24130 0 58 srg load
> p -f 66
PROC TABLE SIZE = 3946
SLOT ST PID PPID PGID SID UID PRI NAME FLAGS
66 s 22889 16318 16337 24130 0 58 srg load
Session: sid: 24130, ctty: vnode(60b8f3ac) maj( 24) min( 1)
...
>
Po spożytkowaniu crash, użylismy funkcji p do pobrania slotu tabeli procesu
(66 w tej części). Następnie aby wyrzucić strukturę proc dla procesu o
numerze PID 22889, ponownie zrobiliśmy użytek z p, dodając flage '-f' i
numer slotu tabeli procesu.
Jak struktura procesu, zawartość uarea wspierająca dane dla sygnałów, włącza
zestaw definicji dyspozycji dla wszystkich możliwych sygnałów. Dyspozycja
sygnału mówi systemowi operacyjnemu co zrobić w wypadku sygnału - zignorować
go, złapać go i wezwać nagłówek sygnału zdefiniowanego użytkownika lub
wykonać domyślną akcje. Aby wyrzucić uarea procesu:
> u 66
PER PROCESS USER AREA FOR PROCESS 66
PROCESS MISC:
command: srg, psargs: ./srg
start: Mon Jun 3 08:56:40 2002
mem: 6ad, type: exec su-user
vnode of current directory: 612daf48
...
>
Funckcja 'u' pobiera numer slotu tabeli procesu jako argument. Aby wyrzucić
przestrzeń adresu procesu, wklep:
# /usr/proc/bin/pmap -x 22889
Aby uzyskać listę otwartych plików procesu, użyj komendy /usr/proc/bin/pfiles:
# /usr/proc/bin/pfiles 22889
Komenda ta wypisuje nazwę procesu i PID dla otwartych plików procesu.
Zaznaczam że różne części informacji są akceptowane na poszczególnym
otwartym pliku, włączając typ pliku, flagę pliku, czśści trybu i rozmiar.
Jeżeli nie możesz znaleźć binarnego pliku i proces jest tylko w pamięci,
możesz nadal użyć opisanych metod w odniesieniu do analizy podejrzanych
plików binarnych rownież nad danymi plikami procesu. Na przykład:
# /usr/ccs/bin/nm a.out | more
a.out:
[Index] Value Size Type Bind Other Shndx Name
...
[636] | 232688| 4|OBJT |GLOB |0 |17 |Master_utmp
[284] | 234864| 20|OBJT |GLOB |0 |17 |Mouse_status
Mozesz użyć także mdb(1) - modularny debugger do analizy procesów:
# mdb -p 22889
Loading modules: [ ld.so.1 libc.so.1 libnvpair.so.1 libuutil.so.1 ]
> ::objects
BASE LIMIT SIZE NAME
10000 62000 52000 ./srg
ff3b0000 ff3dc000 2c000 /lib/ld.so.1
ff370000 ff37c000 c000 /lib/libsocket.so.1
ff280000 ff312000 92000 /lib/libnsl.so.1
--[ Bezpieczeństwo dochodzeniowe, używanie DTrace
Solaris 10 ma zaimplementowane nowe narzędzie do dynamicznego trasowania w
środowisku systemu operacyjnego - dtrace. Jest to bardzo potężne narzędzie
które pozwala administratorom systemów na obserwację i debagowanie
zachowania OS-u lub nawet na dynamiczną modyfikację kernela. Dtrace ma swój
własny język programowania jak C/C++ nazywany 'językiem D', i dostarcza
wielu różnych opcji ale nie mam zamiaru ich tutaj omawiać. Obejrzyj stronę
manuala dtrace(1M) a także zaglądnij na
http://docs.sun.com/app/docs/doc/817-6223 aby zdobyć więcej informacji.
Chociaż to narzędzie zostało zaprojektowane pierwotnie dla developerów i
administratorów, wyjaśnię jak ktoś może użyć dtrace do analizy podejrzanych
plików i procesów.
Będziemy dalej pracować nad studiowaniem przypadku jak nastepuje. Np.
przyjmijmy że badamy proces o ID 968 z podejrzanej aplikacji srg, którą
znaleźliśmy uruchomioną w naszym systemie.
Przez wpisanie następujących komend linii poleceń, wypiszesz wszystkie pliki
które otwiera ten określony proces. Poniższa komenda wykonuje daną czyność
dopóki nie zostanie wciśnięta kombinacja klawiszy Control-C:
# dtrace -n syscall::open:entry'/pid == 968/
{ printf("%s%s",execname,copyinstr(arg0)); }'
dtrace: description 'syscall::open*:entry' matched 2 probes
^C
CPU ID FUNCTION:NAME
0 14 open:entry srg /var/ld/ld.config
0 14 open:entry srg /lib/libdhcputil.so.1
0 14 open:entry srg /lib/libsocket.so.1
0 14 open:entry srg /lib/libnsl.so.1
Język D ma swoją własną terminologię, którą będę próbował tutaj krótko
przedstawić.
Całkowita konstrukcja 'syscall::open:entry' nazywana jest 'próbą' i
definiuje lokalizacje lub czynność do której dtrace dołącza odwołanie do
wypełnienia kompletu 'akcji'. Element 'wywołanie systemowe-syscall' próby
nazywany jest 'dostawcą' i, w naszym przypadku, zezwala próbom na
'wejście-entry' (start) do każdego 'otwartego-open' wywołania systemowego
Solarisa ('otwarte-open' wywołanie systemowe uczy kernel otwierać plik do
czytania i pisania).
Tzw. 'orzeczenie' - /pid == 968/ używa predefiniowanej zmiennej dtrace
'pid', zawsze oceniającą do procesu, ID towarzyszący wątkowi który zapalił
odpowiednie badanie.
'execname' i 'copyinstr(arg0)' nazywane są 'akcjami' i definiują nazwę
aktualnego pliku tabeli wykonywania procesu i konwertują pierwszy całkowity
argument wywołania systemowego (arg0) do odpowiedniego formatu łancucha.
Funckja printf używa takiej samej składni jak język C i używana jest w tym samym
celu - do formatowania danych wyjściowych.
Każdy program napisany w jezyku D składa się z serii 'warunków', każdy
warunek opisuje jedną lub więcej prób uzyskania upoważnien, i opcjonalnie
komplet wykonywanych funkcji kiedy próba zostaje odpalona. Akcje są listowane
jako serie wyrażeń zawartych w nawiasach klamrowych { } następujacej nazwy próby.
Każde wyrażenie zakończone jest średnikiem (;).
Możesz przeczytać Wprowadzenie do Przewodnika Trasowania w Solarisie
(http://docs.sun.com/app/docs/doc/817-6223) aby poznać więcej opcji i
zrozumieć wykonanie.
Notatka: Jak sugeruje nazwa, dtrace (Dynamic Trace) pokaże Ci informacje o
zmieniających się procesach - w dynamice. Tzn. że jeżeli proces jest
bezczynny (nie może wykonać żadnego wywołania systemowego lub otworzyć
nowego pliku), nie będziesz w stanie otrzymać żadnych informacji. Do analizy
procesu albo go zrestartuj albo użyj metod opisanych w dwóch poprzednich
sekcjach tego artykułu.
W kolejnej fazie użyjemy następującej konstrukcji linii komend aby
wyświetlić wszystkie wywołania systemowe dla 'srg'.
# dtrace -n 'syscall:::entry /execname == "srg"/ { @num[probefunc] =
count(); }'
dtrace: description 'syscall:::entry ' matched 226 probes
^C
pollsys 1
getrlimit 1
connect 1
setsockopt 1
...
Możesz dowiedzieć się trochę o budowanych elementach tego małego programu
pisanego w jezyku D. W dodatku ta klauzula definiuje zestaw nazwany 'run' i
wyznacza stosownego członka 'probefunc' (funkcja wykonanego wywołania
systemowego) ilość tych szczególnych funkcji powinna być liczona (count()).
Używając dtrace możemy łatwo emulować wszystkie użyteczne rzeczy które
używaliśmy w poprzedniej sekcji do analizy nieznanych plików binarnych i
procesów. Ale dtrace jest o wiele bardziej użytecznym narzędziem i dostarcza
o wiele więcej funkcji: np. możesz dynamicznie monitorować stos procesów
zapytaniem:
# dtrace -n 'syscall:::entry/execname == "srg"/{ustack()}'
0 286 lwp_sigmask:entry
libc.so.1__systemcall6+0x20
libc.so.1pthread_sigmask+0x1b4
libc.so.1sigprocmask+0x20
srgsrg_alarm+0x134
srgscan+0x400
srgnet_read+0xc4
srgmain+0xabc
srg_start+0x108
Bazując na wszystkich naszych doświadczeniach (zobacz listę otwartych
plików, wywołań systemowych i stos badany wyżej) możemy pozytywnie wnioskować
że srg jest aplikacją sieciową. Czy to jest napisane dla sieci? Sprawdźmy to
konstruując nastepującą komendę:
# dtrace -n 'mib:ip::/execname == "srg"/{@[execname]=count()}'
dtrace: description 'mib:ip::' matched 412 probes
dtrace: aggregation size lowered to 2m
^C
srg 520
Jest. Użylismy providera 'mib' aby wyjaśnic czy nasza aplikacja laczy się z
siecią.
To może być tylko sniffer lub aplikacja ala netcat bindowana na specyficznym
porcie? Uruchomimy dtrace w truss(1) jako wzór do odpowiedzenia sobie na to
pytanie (zainspirowane przez użyteczność dtruss Brendana Gregga):
#!/usr/bin/sh
#
dtrace='
inline string cmd_name = "'$1'";
/*
** Save syscall entry info
*/
syscall:::entry
/execname == cmd_name/
{
/* set start details */
self->start = timestamp;
self->arg0 = arg0;
self->arg1 = arg1;
self->arg2 = arg2;
}
/* Print data */
syscall::write:return,
syscall::pwrite:return,
syscall::*read*:return
/self->start/
{
printf("%s(0x%X, \"%S\", 0x%X)\t\t = %d\n",probefunc,self->arg0,
stringof(copyin(self->arg1,self->arg2)),self->arg2,(int)arg0);
self->arg0 = arg0;
self->arg1 = arg1;
self->arg2 = arg2;
}
'
# Run dtrace
/usr/sbin/dtrace -x evaltime=exec -n "$dtrace" >&2
Zapisz jako truss.d, dodaj prawa wykonywania i uruchom:
# ./truss.d srg
0 13 write:return write(0x1, " sol10 -
> 192.168.2.119 TCP D=3138 S=22 Ack=713701289 Seq=3755926338 Len=0
Win=49640\n8741 Len=52 Win=16792\n\0", 0x5B) = 91
0 13 0 13
write:return write(0x1, "192.168.2.111 -> 192.168.2.1 UDP D=1900
S=21405 LEN=140\n\0", 0x39) = 57
^C
Dla mnie wyglada jak sniffer, z prawdopodobieństwem jakiegoś zdalnego
logowania (przypomij sobie powyższą trasmisje sieciową przez ./srg odkrytą
przez providera 'mib'!).
Aktualnie możesz napisać jakieś niezłe i wymyślne programy dla dtrace
używając jezyka D.
Zobacz dla przykladu /usr/demo/dtrace.
Mozesz użyć także dtrace do innych czynności dochodzeniowych. Poniżej
znajduje się przykład bardziej kompleksowego skryptu, który pozwala na
monitorowanie kto odpala podejrzane aplikacje i rozpoczyna zapisywanie
wszystkich plików otwartych przez proces:
#!/usr/bin/sh
command=$1
/usr/sbin/dtrace -n '
inline string COMMAND = "'$command'";
#pragma D option quiet
/*
** Print header
*/
dtrace:::BEGIN
{
/* print headers */
printf("%-20s %5s %5s %5s %s\n","START_TIME","UID","PID","PPID","ARGS");
}
/*
** Print exec event
*/
syscall::exec:return, syscall::exece:return
/(COMMAND == execname)/
{
/* print data */
printf("%-20Y %5d %5d %5d %s\n",walltimestamp,uid,pid,ppid,
stringof(curpsinfo->pr_psargs));
s_pid = pid;
}
/*
** Print open files
*/
syscall::open*:entry
/pid == s_pid/
{
printf("%s\n",copyinstr(arg0));
}
'
Zapisz jako wait.d, dodaj prawa wykonywania 'chmod +x wait.d' i uruchom:
# ./wait.d srg
START_TIME UID PID PPID ARGS
2005 May 16 19:51:20 100 1582 1458 ./srg
/var/ld/ld.config
/lib/libnsl.so.1
/lib/libsocket.so.1
/lib/libresolv.so.2
...
^C
Widac każdorazowe uruchomienie srg.
Niemniej jednak prawdziwa siła dtrace pochodzi z faktu że możesz coś robic
z tym że to nie będzie możliwe bez napisania obszernego programu w C. Np.
aplikacja shellsnoop napisana przez Brendana Gregga
(http://users.tpg.com.au/adsln4yb/DTrace/shellsnoop) pozwala na użycie
dtrace przy objętości ttywatcher!
Nie możliwe jest żeby pokazać wszystkie możliwości dtrace w takiej małej
prezentacji tego niezwykle użytecznego narzędzia. Dtrace jest bardzo funckcjonalny
jak wiele kompleksowych narzędzi z niekończącymi się wirtualnymi możliwościami.
Aczkolwiek Sun upiera się że nie musisz posiadać 'głębokiego pojęcia o kernelu
żeby DTrace był dla Ciebie funckjonalny', znajomość istotnych wartości
Solarisa jest prawdziwym skarbem. Zobaczmy include-pliki w katalogu
/usr/include/sys/, może to pomoże Ci w napisaniu kompleksowego skryptu
języka D i da więcej informacji pomocnych w zrozumieniu jak Solaris 10 jest
implementowany.
--[ Konkluzja
Bądź kreatywnym i spotrzegawczym. Użyj całej swojej wiedzy i doświadczenia
do analizowania podejrzanych plików binarnych i procesów. A także bądź
cierpliwy i miej poczucie humoru!
2. Epilog
Mam nadzieję że wam się podobało. Elo!
Subskrybuj:
Posty (Atom)