LaboratoriumBezpieczeństwo Systemów Informacyjnych |
Wykonali: 1) Łukasz Iwanecki 2) Maciej Czyż 3) Michał Nowak 4) Mateusz Klimek 5) Serge Nkanka Żibigilaj |
---|---|
Rok akademicki : 2012 / 13 |
Rok studiów : I mag. |
Kierunek : Elektronika i Telekomunikacja |
|
Temat ćwiczenia : Badanie ruchu w sieci |
|
Data wykonania ćwiczenia : 24.04.2013 | Ocena: |
Zad 3
W analizowanym zapisie ruchu sieciowego można wyróżnić następujące protokoły:
ARP - Address Resolution Protocol
BROWSER
CDP - Cisco Discovery Protocol
DHCPv6 - Dynamic Host Configuration Protocol using IPv6
DNS – Domain Name System
HTTP – Hyper Text Transfer Protocol
ICMP - Internet Control Message Protocol
ICMPv6 - Internet Control Message Protocol using IPv6
LOOP – Testing Protocol
MNDN - multicast Domain Name System
NBNS - NetBIOS Name Service
NFS - Network File System
SSDP - Simple Service Discovery Protocol
SSLv2 - Transport Layer Security
STP – Spanning Tree Protocol
TCP – Transport Control Protocol
TLSV1 - Transport Layer Security
UDP - User Datagram Protocol
Kiedy zaistnieje możliwość przesłania hasła za pomocą protokołu http, jest zalecane, aby było ono wysyłane bezpieczniejszą metodą POST. Dla tego chcąc sprawdzić, czy w zapisie ruchu sieciowego znajdują się jakieś hasła, warto przefiltrować pakiety pod kątem wystąpienia zapytania typu POST. Po wpisaniu w okno Filter wyrażenia „http.request.method == "POST"” zostały znalezione dwa pakiety. Z pierwszego z nich można się dowiedzieć, iż strona, która go wysłała to: http://pl.wikipedia.org/w/index.php?title=Specjalna:Zaloguj&returnto=Strona_g%C5%82%C3%B3wna, natomiast przesłana zostały następujące pola formularza: wpName=Jurek wpPassword=jurek12345 . Z powyższej analizy wynika iż udało nam się przechwycić hasło dla użytkownika Jurek, do serwisu Wikipedia.
Zad 4
W tym ćwiczeniu poddano analizie plik 24h.cap. Po wybraniu opcji Statistic -> Protocol Hierarchy Statistic możemy przeanalizować jakie protokoły poszczególnych warstw modelu OSI były wykorzystywana, a także jaki był ich procentowy udział w całej transmisji. Po wstępnych oględzinach wyników rzucił się w oczy niezwykle wielki ruch generowany za pomocą protokołu UDP (ok. 60% wszystkich pakietów warstwy transportowej). Protokół UDP jest stosunkowo rzadko wykorzystywanym protokołem warstwy transportowej ze względu na jego bezpołączeniowy charakter.
W dalszej kolejności uruchomiono narzędzie Statistic -> Conversations, dzięki któremu można w łatwy sposób prześledzić, z jakimi adresami była dokonywana wymiana pakietów podczas całej transmisji. Za pomocą górnych zakładek wybieramy protokół UDP, oraz sortujemy zawartość malejąco wg kolumny „Packets A->B”, aby dowiedzieć się, pod jaki adres nasz komputer przesłał najwięcej pakietów. Ze wstępnej analizy konwersacji wynika, iż praktycznie każda z nich jest przeprowadzana z adresem IP 10.0.0.14, przez co możemy przypuszczać, iż adres ten należy do naszego komputera. Dodatkowo warto zauważyć, iż większość transakcji jest przeprowadzanych na port 57977, który nie jest przypisany do żadnej znanej usługi. Kolejnym ciekawym odkryciem jest fakt, iż na tym porcie nasz komputer odbierał dane od ogromnej ilości adresów IP, które w żadnym wypadku nie wyglądają na prywatne ani nawet nie należą do jednej podsieci. Za pomocą usługi whois sprawdzono informacje dla kilku IP, z którymi zostało wymienione najwięcej pakietów. Otrzymane wyniki:
IP | Kraj | Host | Właściciel |
---|---|---|---|
83.190.133.171 | Sweden | m83-190-133-171.cust.tele2.se | TELE2 |
82.143.33.4 | Italy | - | TPN-AS TopneT Telecomunicazioni S.r.L. |
87.61.7.42 | Denmark | - | TDC TDC Data Networks |
87.6.125.42 | Italy | host42-125-dynamic.6-87-r.retail.telecomitalia.it | ASN-IBSNAZ Telecom Italia S.p.a. |
193.217.177.69 | Norway | m193-217-177-69.cust.tele2.no | TELE2 |
81.107.104.166 | United Kingdom | cpc3-lutn1-0-0-cust165.9-3.cable.virginmedia.com | NTL Virgin Media Limited |
Analiza powyższej tabelki pozwala nam wyciągnąć wniosek, iż nasz komputer prowadził bardzo burzliwe konwersacje, z różnymi stacjami, znajdującymi się praktycznie w całej Europie.
Wróćmy do głównego okna programu. Po dokonaniu filtracji i pozostawieniu jedynie pakietów protokołu UDP, widać, że praktycznie przez cały czas trwa obustronna transmisja naszego komputera z różnymi hostami. Warto również zbadać pola Data obserwowanych pakietów. Niestety są to typowe dane binarne, a nie znaki ascii, dla tego nie możemy w łatwy sposób dowiedzieć się, jakie informacje są przesyłane.
Na podstawie przedstawionej analizy możemy wyciągnąć wniosek, iż przedstawiony zapis transmisji nie jest charakterystyczna dla zwykłego peceta, którego głównym zadaniem jest surfowanie po Internecie oraz edytowanie dokumentów w Wordzie. Sądząc po różnorodności oraz ogromnej ilości adresów, z którymi komunikuje się komputer a także po tym, iż wszystkie transakcje są prowadzone na jednym porcie – 57977, możemy być pewni, że na badanej maszynie jest uruchomiona aplikacja, która pełni funkcję serwera. Należy sobie zadać pytanie, czy serwer ten jest świadomie uruchomioną usługą, którą zarządza jego właściciel, czy może jest to jakiś rodzaj malware’u, o którego istnieniu nikt nie wie. Może być to bardzo gadatliwy trojan, albo, co bardziej prawdopodobne, program podłączający stację do botnetu. Biorąc pod uwagę fakt, iż port na którym ta aplikacja nasłuchuje, nie jest znany wyszukiwarce Google, skłaniał bym się ku wnioskowi, iż nie jest to serwer świadczący jakąś konkretną usługę, a raczej mamy do czynienia z botnetem.
Zad 5
Wszystkie komendy w zadaniach 5 i 6 zostały wykonane pod Windowsem.
Wykonanie komendy: whois kwejk.pl
Connecting to PL.whois-servers.net...
DOMAIN NAME: kwejk.pl
registrant type: organization
nameservers: pat.ns.cloudflare.com.
carl.ns.cloudflare.com.
created: 2010.11.21 14:55:18
last modified: 2013.03.03 12:29:41
renewal date: 2013.11.21 14:55:18
option created: 2011.08.03 00:09:05
option expiration date: 2014.08.03 00:09:05
dnssec: Unsigned
REGISTRAR:
NetArt Spolka Akcyjna S.K.A.
ul. Cystersow 20A
31-553 Krakow
Polska/Poland
+48.801 33 22 33
+48.12 297 88 10
+48.12 297 88 08
kontakt@nazwa.pl
www.nazwa.pl
WHOIS displays data with a delay not exceeding 15 minutes in relation to the .pl Registry system
Registrant data available at http://dns.pl/cgi-bin/en_whois.pl
Wykonanie komendy: nslookup kwejk.pl
Nazwa: kwejk.pl
Address: 46.245.199.4
Jak widać, dwie proste komendy wystarczą, aby wyciągnąć wiele ciekawych informacji, a nawet danych teleadresowych znając jedynie nazwę domeny.
Zad 6
Wydanie komendy: tracert kwejk.pl
—ledzenie trasy do kwejk.pl [46.245.199.4]
z maksymalnĄ liczbĄ 30 przeskok˘w:
1 <1 ms <1 ms <1 ms 192.168.0.1
2 1 ms 1 ms 1 ms 192.168.150.1
3 2 ms 1 ms 3 ms 192.168.103.200
4 2 ms 3 ms 2 ms 193-106-245-233.noc.fibertech.net.pl [193.106.245.233]
5 2 ms 2 ms 3 ms 31-172-176-21.noc.fibertech.net.pl [31.172.176.21]
6 2 ms 1 ms 1 ms 31-172-176-33.noc.fibertech.net.pl [31.172.176.33]
7 12 ms 13 ms 12 ms beyond2.plix.pl [195.182.218.129]
8 17 ms 12 ms 13 ms ip-91-102-112-198.beyond.pl [91.102.112.198]
9 13 ms 12 ms 13 ms ip-46-245-199-4.beyonddatacenter.com [46.245.199.4]
—ledzenie zakoäczone.
Komenda tracert służy do sledzenia, przez jakie węzły sieci przechodzi pakiet, aby dostać się do punktu przeznaczenia.
Po mimo usilnych starań oraz instalacji odpowiedniego programu, nie udało się pod Windowsem wykonać komendy hping kwej.pl.
hping to darmowy generator pakietów oraz analizator protokołu TCP/IP. Jest narzędziem do audytowania i sprawdzania bezpieczeństwa zapory sieciowej oraz sieci.
Zad 7
Zadanie 7 polegało na zbadaniu, w jaki sposób szyfrowanie danych wpływa na bezpieczeństwo podczas logowania. W tym celu wykorzystano program WireShark, ustawiono filtr: tcp.port == 80. Podczas logowanie śledzone było kolejne pakiety. Dane o logowaniu znalazły się w pakiecie:
POST /w/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Mai
Bez problemu udało się namierzyć hasło i login:
wpName=asdf&wpPassword=fdsa&wpLoginAttempt=Log+in&wpLoginToken=a1f7343c911c5ad289688e8cf1c2f6a1HTTP/1.0 200 OK
Następnie zalogowano się jeszcze raz, wykorzystując bezpieczny protokół https. Podczas analizowania pakietów w WireSharku należy pamiętać, iż usługa https jest dostępna na porcie 433. Należy więc zmienić filtr na:: tcp.port ==433.
Przechwycone przez WireShark pakiety miały zbliżoną zawartość:
...........Q....(F.rO...J..Nz-."x.|...;.... H. ..N.\v.\....O.d.. 9Kv...=K..K.H.
.......9.8.......5.........E.D.f.3.2...........A...../..............
.............en.wikipedia.org......
.................#....pT..JT.}G/...VC.8%{.6.Z............. .........4....u............:.
@GT#...c.u.E..BA...a.:.v....+wgJ..Td..r.Uw...#%I..|{...)..FaO../..."QG........u.h..1...v..#....Px...r.....3t..uO...............Q...M..Q...1...$...n...2.!..".y...Q.... H. ..N.\v.\....O.d.. 9Kv...=K..K....................$......c.#..:..9.Qn.>...?......x.jm.h..........$ls..u....%.K..-...ms..p(p......../.`......J.n7R...>.kz
.O.o......
Dane zostały zaszyfrowane i nie jest możliwe podsłuchanie hasła.
Wnioski:
Sniffing - Pojęcie 'sniffing' pochodzi z języka angielskiego i oznacza węszenie, podsłuchiwanie. Jako zjawisko sniffing jest jednym z typów aktywności hakerskiej. Termin odnosi się do przechwytywania przez niepowołane do tego osoby informacji przesyłanych w lokalnych sieciach, a także sieciach Wi-Fi. W tym celu wykorzystuje się programy komputerowe wyspecjalizowane w odbieraniu i analizowaniu danych krążących w Sieci. Programy tego typu, od nazwy zjawiska, nazywane są snifferami.
Sniffing był bardzo łatwy do wykonania w czasach, kiedy sieci komputerowe były oparte na huba. Wtedy cały ruch sieciowy był propagowany przez wszystkie interfejsy w równym stopniu. O moment, w którym huby zastąpiono switchami, przeprowadzenie ataku stało się dużo trudniejsze.
Podczas logowania przez protokół HTTP, wszystkie dane, które wpiszemy do formularza są przesyłane jawnym tekstem. Stwarza to możliwość łatwego podsłuchania naszego hasła (co zostało udowodniona podczas laboratorium). Wykorzystując podczas logowania protokół SSL mamy pewność, że nasz dane zostaną zaszyfrowane przed wysłaniem, a przez to mogą bezpiecznie podróżować kanałem transmisyjnym, bez możliwości ich podsłuchania.