Minun viimeinen viesti Havaitsimme, että asiakkaan järjestelmä oli luultavasti käynnissä jonkinlainen työkalu anturi tiedetään olevan haavoittuvia tiedostoja. Meillä on vielä selittää reset paketit kuitenkin sekä miksi palvelin oli välittämättä niistä.
Juuri nyt emme edes tiedä, missä tämä packet capture otettiin suhteessa kahden päätepisteen. Aion juosta tshark käyttäen "-T kenttiä" kytkin tulostaa TTL tiedot. Analysoimalla TTLS, meidän pitäisi pystyä selvittämään, missä olemme haistelevat suhteessaan asiakkaan ja palvelimen. Olen myös menossa tulostaa IP tunnukset nähdä onko poikkeavuuksia paketin tilauksen.
Tässä komento ja lähtö:
tshark-R challenge1.cap-T kentät-e frame.number-e ip.src-e tcp.srcport-e ip.ttl-e ip.id
1 148.78.247.10 26922 49 0x2a6b
2 12.33.247.4 80 64 0 × 0000
3 148.78.247.10 26922 49 0x2a95
4 148.78.247.10 26922 49 0x2a96
5 12.33.247.4 80 64 0 × 3743
6 12.33.247.4 80 255 0xb0f2
7 148.78.247.10 26922 255 0xb0f2
8 12.33.247.4 80 64 0 × 3744
9 12.33.247.4 80 64 0 × 3745
10 12.33.247.4 80 64 0 × 3746
11 12.33.247.4 80 64 0 × 3747
12 12.33.247.4 80 64 0 × 3748
13 12.33.247.4 80 64 0 × 3749
14 12.33.247.4 80 64 0x374a
15 12.33.247.4 80 64 0x374b
16 12.33.247.4 80 64 0x374c
17 12.33.247.4 80 64 0x374d
148.78.247.10 on asiakas. Tiedämme, että koska se aloitti istuntoon ja sen viestintä käyttäen ylä lähdeportin. 12.33.247.10 on meidän HTTP-palvelin kommunikoi satamasta 80.
Vuonna paketti 1 näemme asiakas on TTL 49. Lähin alkaen TTL ottelu tunnettu käyttöjärjestelmä on 64, joten tämä kertoo meille asiakas on Linux-, UNIX-tai Mac-järjestelmä istuu 15 humalaa pois. Vuonna packet 2 näemme palvelimelle TTL arvo 64, joten se on yksi edellä mainituista käyttöjärjestelmistä istuu lähiverkossa. Joten olemme samalla törmäys verkkotunnuksen kuin palvelin, mutta istuu 15 humalan pois asiakkaan.
On ongelma kuitenkin. Katso paketit 6 ja 7. Tässä näemme TTL molempien järjestelmien muuttaminen 255. OS koskaan muutu se TTL istunnon aikana, joten tämä näyttää erittäin epäilyttävältä. Lisäksi olemme jo todenneet, että asiakas istuu 15 humala päässä meistä. 255 on suurin mahdollinen TTL arvo kuin TTL-kenttä on vain yksi tavu (tavu 8 IP header). Joten vaikka lähde IP osoite väittää olevansa etäasiakas, ei ole mitään keinoa, että paketin voisi olla peräisin mistä tahansa, mutta paikallisesta verkosta. Jos paketti oli ylittänyt yhden tai useamman reitittimiä, TTL arvo olisi pienempi.
IP ID tietoja ei näytä oikealta joko. Kolmessa ensimmäisessä paketteja, jotka asiakas näemme IP ID arvot 0x2a6b (10859), 0x2a95 (10901), ja 0x2a96 (10902). Tämä kertoo asiakkaalle on mahdollisesti käyttämällä +1 inkrementaalinen IP ID, emme vain nähnyt 42 pakettien välillä ensimmäisen ja toisen paketti lähetetään. Seuraava IP ID näemme asiakas 0xb0f2 (45298). OK, jos emme jääneet yli 34000 pakettia, tämä IP ID ei jive.
Huomaa yllä analyysi olisi vain teoreettinen jos se ei epäjohdonmukainen TTL-arvot. Vain kolme pakettia katsomaan, emme voi täsmällisesti IP ID lisäyksen. On myös mahdollista, mutta erittäin epätodennäköistä, että IP ID lisäys on täysin satunnainen ja järjestelmä vain sattui valjastaa kaksi vähitellen IP-tunnukset, yksi oikea toisensa jälkeen. Silti yhdistää TTL ja IP ID tiedot yhteen ja ne osoittavat, että tämä lopullinen paketti ei olisi peräisin samasta järjestelmästä.
Meillä on enemmän IP ID tietoja palvelimesta toimimaan, niin sallikaa Katsokaa tuota. Tunnukset ovat:
- 0 (0)
- 0 × 3743 (14147)
- 0xb0f2 (45298)
- 0 × 3744 (14148)
- 0 × 3745 (14149)
- 0 × 3746 (14150)
- 0 × 3747 (14151)
- 0 × 3748 (14152)
- 0 × 3749 (14153)
- 0x374a (14154)
- 0x374b (14155)
- 0x374c (14156)
- 0x374d (14157)
Tutustu kolmannen lueteltu IP tunnus, joka on peräisin paketti 6 jäljittää. Huomaa, että kaikki muut IP tunnukset ovat inkrementaalinen +1, mutta tämä IP ID ei kuulu. Itse voimme osoittaa, että palvelin askelin se IP ID +1 ja että ei ole mitään keinoa tämä paketti peräisin palvelimelle.
Humm. Ihmettelen, jos nämä epäilevät paketit riviin outo nollaa näimme:
tshark-R challenge1.cap-T kentät-e frame.number-e ip.src-e tcp.srcport-e ip.ttl-e ip.id-e tcp.flags.reset
1 148.78.247.10 26922 49 0x2a6b 0
2 12.33.247.4 80 64 0 × 0000 0
3 148.78.247.10 26922 49 0x2a95 0
4 148.78.247.10 26922 49 0x2a96 0
5 12.33.247.4 80 64 0 × 3743 0
6 12.33.247.4 80 255 0xb0f2 1
7 148.78.247.10 26922 255 0xb0f2 1
8 12.33.247.4 80 64 0 × 3744 0
9 12.33.247.4 80 64 0 × 3745 0
10 12.33.247.4 80 64 0 × 3746 0
11 12.33.247.4 80 64 0 × 3747 0
12 12.33.247.4 80 64 0 × 3748 0
13 12.33.247.4 80 64 0 × 3749 0
14 12.33.247.4 80 64 0x374a 0
15 12.33.247.4 80 64 0x374b 0
16 12.33.247.4 80 64 0x374c 0
17 12.33.247.4 80 64 0x374d 0
Ah ha! Joten jos katsomme pakettien kanssa outoja TTL ja IP ID arvot, nämä olivat outoja reset lähetetyt paketit istunnon aikana.
Minusta näyttää siltä kuin joku kolmas järjestelmä on hyppääminen keskusteluun, jotta välittää reset paketteja. Koska nämä oudot paketeissa on TTL 255, tiedämme sen täytyy olla sama törmäyksen toimialueella kuin missä olemme haistaa. Koska se on samalla törmäys verkkotunnuksen, Ethernet otsikkotiedot voivat olla avuksi:
tshark-R challenge1.cap-T kentät-e frame.number-e ETH-e tcp.flags.reset
1 Ethernet II, SRC: HewlettP_ea: 20: ab (0:50:08 b: EA: 20: ab), DST: DellComp_20: 7d: E3 (00: b0: d0: 20:7 d: E3) 0
2 Ethernet II, SRC: DellComp_20: 7d: E3 (00: b0: d0: 20:7 d: E3), DST: HewlettP_ea: 20: ab (0:50:08 b: EA: 20: ab) 0
3 Ethernet II, SRC: HewlettP_ea: 20: ab (0:50:08 b: EA: 20: ab), DST: DellComp_20: 7d: E3 (00: b0: d0: 20:7 d: E3) 0
4 Ethernet II, SRC: HewlettP_ea: 20: ab (0:50:08 b: EA: 20: ab), DST: DellComp_20: 7d: E3 (00: b0: d0: 20:7 d: E3) 0
5 Ethernet II, SRC: DellComp_20: 7d: E3 (00: b0: d0: 20:7 d: E3), DST: HewlettP_ea: 20: ab (0:50:08 b: EA: 20: ab) 0
6 Ethernet II, SRC: D-Link_8f: E0: 0C (00:50: ba: 8 f: E0: 0C), DST: HewlettP_ea: 20: ab (0:50:08 b: EA: 20: ab) 1
7 Ethernet II, SRC: D-Link_8f: E0: 0C (00:50: ba: 8 f: E0: 0C), DST: DellComp_20: 7d: E3 (00: b0: d0: 20:7 d: E3) 1
8 Ethernet II, SRC: DellComp_20: 7d: E3 (00: b0: d0: 20:7 d: E3), DST: HewlettP_ea: 20: ab (0:50:08 b: EA: 20: ab) 0
9 Ethernet II, SRC: DellComp_20: 7d: E3 (00: b0: d0: 20:7 d: E3), DST: HewlettP_ea: 20: ab (0:50:08 b: EA: 20: ab) 0
10 Ethernet II, SRC: DellComp_20: 7d: E3 (00: b0: d0: 20:7 d: E3), DST: HewlettP_ea: 20: ab (0:50:08 b: EA: 20: ab) 0
11 Ethernet II, SRC: DellComp_20: 7d: E3 (00: b0: d0: 20:7 d: E3), DST: HewlettP_ea: 20: ab (0:50:08 b: EA: 20: ab) 0
12 Ethernet II, SRC: DellComp_20: 7d: E3 (00: b0: d0: 20:7 d: E3), DST: HewlettP_ea: 20: ab (0:50:08 b: EA: 20: ab) 0
13 Ethernet II, SRC: DellComp_20: 7d: E3 (00: b0: d0: 20:7 d: E3), DST: HewlettP_ea: 20: ab (0:50:08 b: EA: 20: ab) 0
14 Ethernet II, SRC: DellComp_20: 7d: E3 (00: b0: d0: 20:7 d: E3), DST: HewlettP_ea: 20: ab (0:50:08 b: EA: 20: ab) 0
15 Ethernet II, SRC: DellComp_20: 7d: E3 (00: b0: d0: 20:7 d: E3), DST: HewlettP_ea: 20: ab (0:50:08 b: EA: 20: ab) 0
16 Ethernet II, SRC: DellComp_20: 7d: E3 (00: b0: d0: 20:7 d: E3), DST: HewlettP_ea: 20: ab (0:50:08 b: EA: 20: ab) 0
17 Ethernet II, SRC: DellComp_20: 7d: E3 (00: b0: d0: 20:7 d: E3), DST: HewlettP_ea: 20: ab (0:50:08 b: EA: 20: ab) 0
Joten kun asiakas tulee sisään Internet, se kulkee HP järjestelmä toimii joko reititin tai palomuuri. Meidän Web-palvelin on käynnissä Dell laitteisto. Huom meidän nollaa (paketit 6 ja 7) ovat molemmat jossa toimitusten samaa järjestelmää käyttäen D-Link verkkokortti.
Joten miksi D-Link järjestelmä yrittää tappaa istunto? Tämä tapahtui juuri, kun asiakas lähettää epäilyttävän tiedoston pyynnöstä. Minusta näyttää siltä kuin D-Link järjestelmä on todellakin yksi hiottu tunkeutumisen havainnointi (IPS). Kun hyökkäys todetaan, IPS pyrkimykset estää hyökkäyksen lähettämällä reset paketit molemmissa päissä yhteyden.
Mutta meillä on vielä joitakin avoimia kysymyksiä. Oliko hyökkäys onnistuu ja miksi palvelin näyttävät sivuuttaa IPS yritti tappaa istunto?
Käännöksen seuraavan jakson selvittää.
Liittyvien virkojen:
