---

Hej gruppe

Hvor stor er risikoen for tcp hijacking idag? Så vidt jeg har forstået,
ligger problemet i, at man, hvis man kender/kan forudsige
sekvensnummeret for en forbindelse, kan insætte pakker i datastrømmen.
Er dette korrekt? Er der evt. lavet nogle 'modtræk' (countermeasures)
imod det? Jeg synes at kunne huske, at Alex Holst engang skrev noget om,
at det var meget svært at gætte sekvensnumre. Kan det passe og iså fald,
hvad skyldes det?

Jeg har ledt på www, men dér fandt jeg ikke noget, der kunne give svar
på spørgsmål mht. risiko etc., så jeg håber, der er nogen her, der kan
gøre mig klogere.

Mvh. Michael
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)

---

Michael Knudsen wrote:

> Hvor stor er risikoen for tcp hijacking idag? Så vidt jeg har forstået,
> ligger problemet i, at man, hvis man kender/kan forudsige
> sekvensnummeret for en forbindelse, kan insætte pakker i datastrømmen.


Ja, og det kan man desværrer på 30% af alle maskiner på Internet.

Gamle operativ systemer, AIX, HPUX, og en den af microsofts, win95,
win98, winntsp3

> Er dette korrekt? Er der evt. lavet nogle 'modtræk' (countermeasures)


En firewall, der omskriver pakkerne, fx en applikationsfirewall med en
god TCP/IP stak.

Eller et operativ system, der designet ordenligt. fx nyere openbsd eller
linux.


> imod det? Jeg synes at kunne huske, at Alex Holst engang skrev noget om,
> at det var meget svært at gætte sekvensnumre. Kan det passe og iså fald,
> hvad skyldes det?

> Jeg har ledt på www, men dér fandt jeg ikke noget, der kunne give svar
> på spørgsmål mht. risiko etc., så jeg håber, der er nogen her, der kan
> gøre mig klogere.


En god artikel (jeg ikke lige kunne huske adressen på, men det kunne
google.com, søgning på "tcp bind sequence guess"), med søde tegninger:

http://razor.bindview.com/publish/papers/tcpseq.html

Denne gennemgår forskellige operativ systemer, og også bind som
applikation!!

---

"Christian E. Lysel" <chlyshoswmdatapunktumcom@example.net> wrote in message
news:3C4C7008.7080406@example.net...
> > Er dette korrekt? Er der evt. lavet nogle 'modtræk' (countermeasures)
>
>
> En firewall, der omskriver pakkerne, fx en applikationsfirewall med en
> god TCP/IP stak.

Jeg har ellers læst at kryptering er den eneste rigtige sikring mod dette.
Men det med firewallen lyder da spændende, vil du uddybe?

mvh
db

---

Daniel Blankensteiner wrote:

> Jeg har ellers læst at kryptering er den eneste rigtige sikring mod dette.


Dvs. et almidelig website, eller mailserver bør kører SSL eller VPN?

> Men det med firewallen lyder da spændende, vil du uddybe?


Filter firewalls og statefull inspection firewalls, lader pakkerne gå
igennem, uden at fortage de størrer ændringer af pakkerne, bortset fra
fx NAT, checksum....

En applikationsfirewall kører på et operativ system, dette operativ
system skal have en "stærk" TCP/IP stak. Firewallen vil modtage session
fra kilden til sin applikationsproxy. Applikationsproxien vil nu oprette
en ny session til destinationen. Hermed skrives den nye session fra en
"stærk" tcp/ip stak.

Dette kan opnåes med fx OpenBSD, ovenpå denne kan smide sine applikationer.

En Raptor Firewall (som nogle nok har opdaget, er dette min fortrukne
firewall), har en hardnet TCP/IP stak, og kan proxie alt IP traffik. For
udvalgte protokoller kan den desuden vertificere at RFC'erne er
overholdt. For SSL kan den kun vertificere at initialiseringen af
sessionen overholder standarden.

---

"Christian E. Lysel" <chlyshoswmdatapunktumcom@example.net> wrote in message
news:3C4C7B23.6030308@example.net...
> Filter firewalls og statefull inspection firewalls, lader pakkerne gå
> igennem, uden at fortage de størrer ændringer af pakkerne, bortset fra
> fx NAT, checksum....
>
> En applikationsfirewall kører på et operativ system, dette operativ
> system skal have en "stærk" TCP/IP stak. Firewallen vil modtage session
> fra kilden til sin applikationsproxy. Applikationsproxien vil nu oprette
> en ny session til destinationen. Hermed skrives den nye session fra en
> "stærk" tcp/ip stak.
>
> Dette kan opnåes med fx OpenBSD, ovenpå denne kan smide sine
applikationer.
>
> En Raptor Firewall (som nogle nok har opdaget, er dette min fortrukne
> firewall), har en hardnet TCP/IP stak, og kan proxie alt IP traffik. For
> udvalgte protokoller kan den desuden vertificere at RFC'erne er
> overholdt. For SSL kan den kun vertificere at initialiseringen af
> sessionen overholder standarden.

Ok, her er hvordan jeg ser det. Der bliver ført en "samtale" mellem to
computere, fx mig og Unibank (som det hed før). Denne samtale består af
pakker med flere header's og en body. Firewall filtrere for det meste ud fra
headerne, men det er netop dem der bliver spoofet i dette tilfælde. Så den
eneste mulighed er at gøre body'en uforståelig for serveren/programmet (hvis
det altså ikke er de rigtige pakker), dette opnås ved at klienten får
udleveret en algoritme til at kryptere body'en med, så dem der ikke har
algoritmen kan ikke være med i samtalen. Oder was?



mvh

db

---

Daniel Blankensteiner wrote:

> Ok, her er hvordan jeg ser det. Der bliver ført en "samtale" mellem to
> computere, fx mig og Unibank (som det hed før). Denne samtale består af
> pakker med flere header's og en body. Firewall filtrere for det meste ud fra


Tja, ja det kan du godt sige.

> headerne, men det er netop dem der bliver spoofet i dette tilfælde. Så den


En applikationsfirewall vil genskrive alt, således vil svagheder i
headeren forsvinde, som fx sekvensnumre der kan gættes vha. 7 gæt.


> eneste mulighed er at gøre body'en uforståelig for serveren/programmet (hvis
> det altså ikke er de rigtige pakker), dette opnås ved at klienten får
> udleveret en algoritme til at kryptere body'en med, så dem der ikke har


Men en applikationsfirewall vil der være 2 klienter og 2 servere, hvor
firewallen er den ene klient og den ene server, dvs. den vil have en
session med afsender klienten og en session med modtager serveren.


> algoritmen kan ikke være med i samtalen. Oder was?

En hacker kan nu overtage datastrømen, og således overtage http sessionen.

Han kan dog også afbryde datastrømen.

Kryptering af sessionen vil kun hjælpe lidt, da hackeren ikke udnytte at
han har overtages datastrømen.

Hackeren vil stadigvæk kunne afbryde datastrømen.

---

"Christian E. Lysel" wrote:
>
> Daniel Blankensteiner wrote:
>
> > Jeg har ellers læst at kryptering er den eneste rigtige sikring mod dette.
>
> Dvs. et almidelig website, eller mailserver bør kører SSL eller VPN?

Ja. Når jeg besøger et website starter jeg altid med at prøve
https, men det er stadig langt fra alle, der understøtter det.

--
Kasper Dupont
For sending spam use mailto:u972183+6138@daimi.au.dk

---

Hej Christian

> > Hvor stor er risikoen for tcp hijacking idag? Så vidt jeg har forstået,
> > ligger problemet i, at man, hvis man kender/kan forudsige
> > sekvensnummeret for en forbindelse, kan insætte pakker i datastrømmen.
>
> Ja, og det kan man desværrer på 30% af alle maskiner på Internet.

Hvor har du det tal fra? Er det et gæt/skøn?

> En firewall, der omskriver pakkerne, fx en applikationsfirewall med en
> god TCP/IP stak.

Det var nu ikke sådan en løsning, jeg havde i tankerne. Jeg tænkte på
noget i niveauet omkring ip eller tcp.

> En god artikel (jeg ikke lige kunne huske adressen på, men det kunne
> google.com, søgning på "tcp bind sequence guess"), med søde tegninger:
>
> http://razor.bindview.com/publish/papers/tcpseq.html

Fin artikel, men jeg undres lidt over nogle ting:

   http://razor.bindview.com/publish/papers/tcpseq/print.html#tcpseq

I andet afsnit ("As early as..") støder man på denne sætning:

"An attacker wanting to establish connection originating from a fake
address, or to compromise existing TCP connection integrity by inserting
malicious data into the stream [1] would have to know the ISN."

Kan man ikke blot sniffe det? Det sendes måske ikke med? Det passer
nemlig ikke så godt med dette fra afsnit 1.2:

"Among other things, this means that all TCP implementations regularly
discard packets with incorrect ISNs, since the failure to do so presents
an obvious DoS attack."

Det skyldes måske, at man går ud fra, at det ikke er muligt at sniffe på
forbindelsen? Har jeg overset noget?

Mvh. Michael
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)

---

Michael Knudsen wrote:

>>Ja, og det kan man desværrer på 30% af alle maskiner på Internet.
> Hvor har du det tal fra? Er det et gæt/skøn?


Et skøn :)

> Det var nu ikke sådan en løsning, jeg havde i tankerne. Jeg tænkte på
> noget i niveauet omkring ip eller tcp.


En god TCP/IP stak løser også problemet.

> Fin artikel, men jeg undres lidt over nogle ting:
>
>    http://razor.bindview.com/publish/papers/tcpseq/print.html#tcpseq
>
> I andet afsnit ("As early as..") støder man på denne sætning:
>
> "An attacker wanting to establish connection originating from a fake
> address, or to compromise existing TCP connection integrity by inserting
> malicious data into the stream [1] would have to know the ISN."
>
> Kan man ikke blot sniffe det? Det sendes måske ikke med? Det passer
> nemlig ikke så godt med dette fra afsnit 1.2:


Nogle af angrebene kan faktisk udfører i blinde!!

ID feltet på mange TCP/IP implementationen røber mere end de bør.


> "Among other things, this means that all TCP implementations regularly
> discard packets with incorrect ISNs, since the failure to do so presents
> an obvious DoS attack."
>
> Det skyldes måske, at man går ud fra, at det ikke er muligt at sniffe på
> forbindelsen? Har jeg overset noget?


Ja, at nogle angreb kan udfører i blinde, vi snakker sessions hijacking,
og terminiering af sessioner.

En af fordele er at man kan formindste delayet, da man kan forudsige sin
servers "modtræk", således at man kan sende pakker, før man har fået
"ok" for det :)

---

Hej Christian

> >>Ja, og det kan man desværrer på 30% af alle maskiner på Internet.
> > Hvor har du det tal fra? Er det et gæt/skøn?
>
> Et skøn :)

Ah, ok. Efter at have kigget nærmere på den side, du viste, ville jeg
mene, at det måske snarere er op mod det dobbelte, men det kan vi nok
ikke udtale os om.

> > Det var nu ikke sådan en løsning, jeg havde i tankerne. Jeg tænkte på
> > noget i niveauet omkring ip eller tcp.
>
> En god TCP/IP stak løser også problemet.

Løser? Mjae, den hjælper lidt på det, men problemet er der stadig.
Risikoen bliver dog mindre. Jeg går lidt og overvejer noget for tiden,
som måske kan hjælpe på det, men det er langt fra gennemtænkt, så jeg
vil ikke komme nærmere ind på det her. Ja, det er af fare for at blive
til grin/gråd.

> > Kan man ikke blot sniffe det? Det sendes måske ikke med? Det passer
> > nemlig ikke så godt med dette fra afsnit 1.2:
>
> Nogle af angrebene kan faktisk udfører i blinde!!

Ja, det er også, hvad jeg kom frem til. Især hvis man læser Kents
indlæg, kan man se, at det i mange tilfælde skal udføres således.

> ID feltet på mange TCP/IP implementationen røber mere end de bør.

Jeg må se at få læst op på dette igen. Jeg har vist haft for meget
ferie. Gider du uddybe, så jeg kan følge med her og nu? :)

Jeg burde vist dedikere min friuge til at læse RFCer mv.

Mvh. Michael
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)

---

Michael Knudsen wrote:

>>Et skøn :)

> Ah, ok. Efter at have kigget nærmere på den side, du viste, ville jeg
> mene, at det måske snarere er op mod det dobbelte, men det kan vi nok
> ikke udtale os om.


Da jeg lever som konsulent, underdriver jeg altid :)

>>En god TCP/IP stak løser også problemet.
> Løser? Mjae, den hjælper lidt på det, men problemet er der stadig.


Du må redegør for dette, da jeg ikke kan følge dig.

> Risikoen bliver dog mindre. Jeg går lidt og overvejer noget for tiden,
> som måske kan hjælpe på det, men det er langt fra gennemtænkt, så jeg
> vil ikke komme nærmere ind på det her. Ja, det er af fare for at blive
> til grin/gråd.


Hentyder du til Bjarne?

Det tror jeg ikke du skal være bange for.

>>Nogle af angrebene kan faktisk udfører i blinde!!
> Ja, det er også, hvad jeg kom frem til. Især hvis man læser Kents
> indlæg, kan man se, at det i mange tilfælde skal udføres således.


Nogle "firewall" forhindre fx udgående pakker, og?

Ved hjælp af ovenstående kan man oprette en TCP/IP session, som kun er
envejs!

>>ID feltet på mange TCP/IP implementationen røber mere end de bør.
> Jeg må se at få læst op på dette igen. Jeg har vist haft for meget
> ferie. Gider du uddybe, så jeg kan følge med her og nu? :)


Søg på pixie-scan eller ID scan. nmap i en af beta'erne har
implementeret den.

ID feltet benyttes til at samle fragmenteret IP pakker, og skal i dette
tilfælde forøges, således at fragmenterne kan samles i den rigtige
rækkefølge i den anden ende.



Men nogle TCP/IP stakke, forøgere blot tælleren i ID altid. Man må gætte
dette blot er dovnskab fra udviklernes side.

Således kan man antage om ens pakke er nået frem, eller scanne maskiner
der sidder bag NAT-enheder, eller om der er meget netværksaktivitet på
hosten.

---

Hej Christian

> >>En god TCP/IP stak løser også problemet.
> > Løser? Mjae, den hjælper lidt på det, men problemet er der stadig.
>
> Du må redegør for dette, da jeg ikke kan følge dig.

En bedre PRNG mindsker risikoen for at gætte ISN, men det kan stadig
lade sig gøre at gætte rigtigt.

> > Risikoen bliver dog mindre. Jeg går lidt og overvejer noget for tiden,
> > som måske kan hjælpe på det, men det er langt fra gennemtænkt, så jeg
> > vil ikke komme nærmere ind på det her. Ja, det er af fare for at blive
> > til grin/gråd.
>
> Hentyder du til Bjarne?

Overhovedet ikke. Jeg havde faktisk glemt ham.

> Det tror jeg ikke du skal være bange for.

Det er nu mere fordi, jeg ikke vil poste noget, der ikke er helt
gennemtænkt. Det vil jo være rart at selv kunne skrotte det, hvis man
opdager noget fundamentalt umuligt.
[snip - må jeg kommerere imorgen, da jeg ryster af sult]

Mvh. Michael
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)

---

Den Mon, 21 Jan 2002 21:48:17 +0100 skrev Michael Knudsen:
>
>I andet afsnit ("As early as..") støder man på denne sætning:
>
>"An attacker wanting to establish connection originating from a fake
>address, or to compromise existing TCP connection integrity by inserting
>malicious data into the stream [1] would have to know the ISN."
>
>Kan man ikke blot sniffe det? Det sendes måske ikke med? Det passer
>nemlig ikke så godt med dette fra afsnit 1.2:
>
>"Among other things, this means that all TCP implementations regularly
>discard packets with incorrect ISNs, since the failure to do so presents
>an obvious DoS attack."
>
>Det skyldes måske, at man går ud fra, at det ikke er muligt at sniffe på
>forbindelsen? Har jeg overset noget?

Ja. Du har overset at forbindelsen normalt går via. de store internet-
udbyderes routere - fx. TeleDanmark. Og det er normalt ikke TeleDanmark
man behøver at være nervøs for, men derimod en eller anden skummel
person på fx. en ADSL, som kun ser trafik der er bestemt for ham.

Mvh
Kent
--
Der' ingen bånd der binder mig
ingen holder på mig, nej...

---

Hej Kent

> >Det skyldes måske, at man går ud fra, at det ikke er muligt at sniffe på
> >forbindelsen? Har jeg overset noget?
>
> Ja. Du har overset at forbindelsen normalt går via. de store internet-
> udbyderes routere - fx. TeleDanmark. Og det er normalt ikke TeleDanmark
> man behøver at være nervøs for, men derimod en eller anden skummel
> person på fx. en ADSL, som kun ser trafik der er bestemt for ham.

Nu kunne jeg mumle noget om Echelon, men jeg lader være. Jeg vil hellere
frem til, at det måske er mere interessant at se på på de lokale netværk
(eks. hos virksomheder). Jeg mener ikke netværk, der ikke er tilsluttet
Internet.

Du har dog ret i, at faren formodentlig er relativt lille på de
'globale' forbindelser.

Mvh. Michael
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)