Statistics
| Branch: | Revision:

root / body.tex @ 52471fcf

History | View | Annotate | Download (30.8 KB)

1
\section{Attacchi Al Mezzo Fisico}
2

    
3

    
4

    
5
\frame
6
{
7
\frametitle{Disclaimer}
8
\bi
9
\ii Non tutte le cose di cui vi parlo sono ancora facilmente praticabili, ma vi insegnano molto sui protocolli 
10
\ii do this at home! don't do this outside your home!
11
\ei
12
}
13

    
14

    
15
\frame
16
{
17
\frametitle{Attacchi al mezzo fisico}
18
Ciascun mezzo fisico è più o meno vulnerabile ad attacchi di vario tipo.
19
\begin{itemize}
20
\uncover<1->{\item DoS: interruzione del collegamento o Jamming}
21
\uncover<2->{\item attacchi di \alert<2>{\textit{Wiretapping}}}
22
\uncover<3->{\item sniffer hardware, sniffing in reti broadcast}
23
\end{itemize}
24
}
25

    
26
\frame
27
{
28
\frametitle{Attacchi al mezzo fisico: accenni}
29
\begin{beamerboxesrounded}[shadow=true]{Jamming}
30
\begin{itemize}
31
\uncover<1->{\item jamming sul mezzo fisico si può fare se il mezzo fisico lo
32
permette, come nel caso di reti wireless o reti wired con cavi non
33
schermati}
34
\uncover<2->{\item anche se il jamming è difficile, basta far
35
fallire la ricezione di un bit per invalidare il checksum e far scartare
36
il pacchetto}
37
\end{itemize}
38
\end{beamerboxesrounded}
39
}
40

    
41

    
42
\frame
43
{
44
\frametitle{Attacchi al livello di collegamento}
45
\begin{beamerboxesrounded}[shadow=true]{}
46
\begin{itemize}
47
\uncover<1->{\item DoS: \alert<1>{\textit{flood}} di pacchetti, generazione di collisioni}
48
\uncover<2->{\item spoofing di indirizzi MAC}
49
\uncover<3->{\item ARP-Spoofing}
50
\end{itemize}
51
\end{beamerboxesrounded}
52
}
53

    
54
\frame
55
{
56
\frametitle{DoS al livello di collegamento: dettagli}
57
\begin{beamerboxesrounded}[shadow=true]{Flood vari}
58
\begin{itemize}
59
\uncover<1->{\item un flood può essere mirato alla saturazione della
60
banda.}
61
\uncover<2->{\item se il mezzo è condiviso si possono non rispettare i
62
tempi di timeout e creare numerose collisioni, oppure mantenere il canale
63
sempre occupato}
64
\uncover<3->{\item un flood può essere mascherato inviando pacchetti con
65
indirizzo mittente modificato}
66
\end{itemize}
67
\end{beamerboxesrounded}
68
}
69

    
70

    
71
\frame{
72
\center{\large ARP-Spoofing}
73
}
74

    
75
\frame
76
{
77
\frametitle{ARP-Spoofing}
78
\begin{beamerboxesrounded}[shadow=true]{Il protocollo ARP}
79
\begin{itemize}
80
\uncover<1->{\item la macchina 192.168.2.51 vuole raggiungere l'indirizzo
81
192.168.2.52 nella stessa sottorete. Per farlo deve inviare un frame all'indirizzo
82
MAC corrispondente}
83
\uncover<2->{\item se non conosce l'indirizzo MAC corrispondente invia una
84
richiesta ARP in broadcast chiedendo che la macchina 192.168.2.52 risponda
85
notificando il suo MAC address}
86
\uncover<3->{\item la macchina 192.168.2.52 risponde con un messaggio di
87
ARP-Reply specificando che il suo indirizzo MAC corrisponde all'IP
88
192.168.2.52}
89
\end{itemize}
90
\end{beamerboxesrounded}
91
}
92

    
93

    
94
\frame
95
{
96
\frametitle{Campi di ARP}
97
\begin{itemize}
98
\uncover<1->{\item campi del protocollo ARP:
99
  \begin{table}
100
    \hbox to\textwidth{\hss
101

    
102
\begin{tabular}{|c|}
103
\hline
104
Hardware type (ethernet)\\
105
\hline
106
Protocol type (IPv4)\\
107
\hline
108
[...]\\
109
\hline
110
Sender hardware address  \\
111
\hline
112
Sender protocol address  \\
113
\hline
114
Receiver hardware address  \\
115
\hline
116
Receiver protocol address  \\
117
\hline
118
\end{tabular}
119
        \hss}
120
\end{table}
121
 }
122
\end{itemize}
123
}
124

    
125
\frame
126
{
127
\frametitle{Algoritmo ARP}
128

    
129
\begin{center}
130
\fbox{%
131
    \begin{minipage}{9cm}
132
      \UseVerbatim[fontsize=\tiny,fontfamily=courier, =1]{ARP-protocol}
133
    \end{minipage}
134
    }
135
    \end{center}
136
\bi 
137
\ii la tabella ARP viene aggiornata ad ogni pacchetto ARP ricevuto, sia di request che di reply
138
\ii gli arp gratuiti possono essere mandati per notificare un cambio di MAC address
139
\ii Si usano ad esempio nei sistemi ad alta affidabilià
140
\ei 
141
}
142

    
143
\frame
144
{
145
\frametitle{ARP-Spoofing, segue}
146
\bcols
147
\col 
148
\begin{beamerboxesrounded}[shadow=true]{Attacco di ARP-spoofing}
149
\begin{itemize}
150
\uncover<1->{\item scopo dell'attacco è intercettare il traffico che passa
151
tra due macchine su una rete con switch. L'attaccante fa parte della rete
152
ma non fa parte del path tra le due macchine vittima.}
153
\end{itemize}
154
\end{beamerboxesrounded}
155
\col
156
\scaledimg{switched-net}
157
\ecols
158
}
159

    
160

    
161
\frame
162
{
163
\frametitle{ARP-Spoofing, segue}
164
\bcols
165
\col[0.4] 
166
\begin{beamerboxesrounded}[shadow=true]{Attacco di ARP-spoofing}
167
\bii
168
\item Eve manda messaggi ARP-Reply diretti
169
all'indirizzo MAC di \alert{Alice}, dichiarando che l'IP di
170
\alert{Bob} corrisponde al suo
171
indirizzo MAC
172
\item Eve manda anche messaggi ARP-Reply diretti
173
all'indirizzo MAC di \alert{Bob}, dichiarando che l'IP di \alert{Alice} corrisponde al suo
174
indirizzo MAC
175
\end{itemize}
176
\end{beamerboxesrounded}
177
\col[0.6]
178
\only<1>{\scaledimg[0.9]{arp-1}}
179
\only<2>{\scaledimg[0.9]{arp-2}}
180

    
181
\only<1>{ARP: 192.168.2.52 is at 08:00:46:b7:25:44}
182
\only<2>{ARP: 192.168.2.51 is at 08:00:46:b7:25:44}
183

    
184
\ecols
185
}
186

    
187

    
188

    
189
\frame
190
{
191
\frametitle{ARP-Spoofing, segue}
192
\bcols
193
\col[0.4] 
194
\begin{beamerboxesrounded}[shadow=true]{}
195
A questo punto le tabelle ARP di Alice e Bob sono inquinate
196
\bii
197
\item Alice manderà un pacchetto a Bob, inviandolo però al MAC di Eve
198
\item Eve guarda/modifica il pacchetto, e lo reinstrada a Bob
199
\end{itemize}
200
\end{beamerboxesrounded}
201
\col[0.6]
202
\only<1>{\scaledimg[0.8]{arp-3}}
203
\only<2>{\scaledimg[0.8]{arp-4}}
204

    
205
\only<1>{tcp syn: dst IP 192.168.2.52,\\ dst MAC 08:00:46:b7:25:44}
206
\only<2>{tcp syn: dst IP 192.168.2.52,\\ dst MAC 00:04:76:13:fb:1e}
207
\ecols
208
}
209

    
210
\begin{frame}
211
\frametitle{ARP spoofing: dettagli}
212
\bi
213
\ii Alla fine dell'attacco Alice e Bob possono mantenere delle connessioni funzionanti che vengono in realtà analizzate da Eve
214
\ii Se Eve realizza l'attacco tra tutti i nodi ed il gateway, diventa un man-in-the-middle sul traffico da qualsiasi host verso Internet.
215
\ii Presumibilmente diventerà un collo di bottiglia e renderà l'attacco visibile.
216
\ei
217
\end{frame}
218

    
219
\begin{frame}
220
\frametitle{ARP spoofing: Mantenimento}
221
\bii
222
\ii Che succede se per qualche motivo Alice deve mandare un pacchetto ad un quarto host di cui non conosce il MAC?
223
\ii Alice invia una nuova richiesta ARP in broadcast, e corregge la tabella ARP di Bob
224
\ii Perché l'attacco sia efficace, Eve deve mandare continuamente pacchetti ARP modificati per continuare a mantenere inquinate le tabelle ARP delle vittime.
225
\ii Un attacco di ARP spoofing è quindi visibile:
226
\bi 
227
\ii Molte richieste/reply ARP gratuite che girano nella rete
228
\ii Una vittima potrebbe vedere più di un IP associato allo stesso MAC, che non è per forza un male a meno che non sia massivo. Gli HIDS possono fare di questi controlli.
229
\ii Uno switch può fare detection di ARP spoofing analizzando le richieste ARP e matchandole con lo stato delle porte (https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/dynarp.html)
230
\ei
231
\ei
232
\end{frame}
233
\begin{frame}
234
\frametitle{Un NIDS può fare cose più complicate (Bro documentation):}
235

    
236
This script leverages knowledge of DHCP transactions, a consistent state of ARP requests and replies, and other metrics in order to provide more accurate information regarding potential attacks. For an attacker to deny a victim service or to initiate a MITM attack, the attacker will need to provide a spoofed MAC address of the victim's gateway. In order to maintain a continuing attack, the attacker will send many spoofed packets, which can be counted. It is possible that these spoofed packets will change IP to MAC mappings, which can be detected as well.
237
\end{frame}
238

    
239

    
240
\frame
241
{
242
\frametitle{Attacchi al livello di rete}
243
\begin{beamerboxesrounded}[shadow=true]{}
244
\begin{itemize}
245
\uncover<1->{\item DoS: flood di pacchetti, smurf}
246
\uncover<2->{\item covert channels, fragmentation attacks, source routing}
247
\uncover<3->{\item spoofing di indirizzi IP}
248
\end{itemize}
249
\end{beamerboxesrounded}
250
}
251

    
252
\subsection{Fragmentation attacks}
253

    
254

    
255
\frame{
256
\center{\large Fragmentation Attacks}
257
}
258

    
259

    
260
\frame
261
{
262
\frametitle{Fragmentation attacks}
263

    
264
\bcols
265
\col[0.4]
266

    
267
\bi 
268
\ii Sappiamo che IP permette di spezzare un pacchetto in
269
più frammenti
270
\ii Il campo Fragment Offset esprime l'offset del pacchetto rispetto all'originale, espresso in multipli di 8 byte
271
\ii Total length esprime la lunghezza del pacchetto (frammento) in Byte, header incluso
272
\ei 
273

    
274
\col[0.7]
275
%\setlength{\bitwidth}{.25cm}
276
\textbf{IP Packet Header:}
277

    
278
\begin{bytefield}{32}
279
\\
280
\bitheader{3,7,15,18,31}\\
281
\bitbox{4}{Vers} 
282
\bitbox{4}{IHL}
283
\bitbox{8}{TOS}
284
\bitbox{16}{Total lenght}\\
285
\bitbox{16}{Identification}
286
\bitbox{3}{Flg}
287
\bitbox{13}{Fragment Offset}\\
288
\bitbox{8}{TTL}
289
\bitbox{8}{Protocol}
290
\bitbox{16}{Header Checksum}\\
291
\bitbox{32}{Source IP}\\
292
\bitbox{32}{Destination IP}\\
293
\bitbox{32}{Options + Padding}\\
294
\end{bytefield}
295

    
296
\ecols
297
}
298

    
299

    
300
\frame
301
{
302
\frametitle{Overlapping Fragmentation attacks}
303
\bcols
304
\col[0.3]
305
Il protocollo IP permette di spezzare pacchetti in frammenti più piccoli di un header TCP. Inoltre i pacchetti che arrivano successivamente possono riscrivere quelli arrivati in precedenza.
306
\col[0.7]
307
\textbf{TCP Packet Header:}
308

    
309
      \begin{bytefield}{32}
310
      \\
311
      \bitheader{15,31}\\
312
      \bitbox{16}{Source port}
313
      \bitbox{16}{Destination Port} \\
314
      \bitbox{32}{Sequence number} \\
315
      \bitbox{32}{Acknowledgment number} \\
316
      \bitbox{4}{Offset} 
317
      \bitbox{4}{RES}
318
      \bitbox{8}{Flags} 
319
      \bitbox{16}{Window}\\ 
320
      \bitbox{16}{Checksum} 
321
      \bitbox{16}{Urgent Pointer} \\
322
      \bitbox{32}{Option + padding} \\
323
      \end{bytefield}
324
      
325
\ecols
326
}
327

    
328
\definecolor{lightgray}{gray}{0.8}
329

    
330

    
331
\frame
332
{
333
\frametitle{Frammentazione: esempio}
334
\bii 
335
\uncover<1->{\item 
336
  Pacchetto IP di partenza: Total length = 230, MTU = 100
337

    
338
  \begin{bytefield}[bitwidth=0.1em]{230}
339
  \\
340
  \bitheader{19,229}\\
341
  \bitbox{20}{IP}
342
  \bitbox{210}{Payload}\\
343
  \end{bytefield}
344
  }
345

    
346
\uncover<2->{\item 
347
  Verrà spezzato in:
348
  
349

    
350
  \begin{bytefield}[bitwidth=0.1em]{230}
351
  \\
352
  \bitheader{19,99, 199, 229}\\
353
  \bitbox{20}{IP}
354
  \bitbox{210}{}\\
355
  \bitbox[t]{100}{$\underbrace{\hspace{10em}}_{\text{\normalsize Frag 1}}$}
356
  \bitbox[t]{100}{$\underbrace{\hspace{10em}}_{\text{\normalsize Frag 2}}$}
357
  \bitbox[t]{30}{$\underbrace{\hspace{3em}}_{\text{\normalsize Frag 3}}$}\\
358
  \end{bytefield}
359
  }
360
\ei
361
}
362

    
363

    
364
\frame
365
{
366
\frametitle{Frammentazione: esempio}
367
\only<1>{\centering{\begin{bytefield}[bitwidth=0.1em]{230}
368
  \\
369
  \bitheader{19,99, 199, 229}\\
370
  \bitbox{20}{IP}
371
  \bitbox{210}{}\\
372
  \bitbox[t]{100}{$\underbrace{\hspace{10em}}_{\text{\normalsize Frag 1}}$}\\
373
  \end{bytefield}}}
374
\only<2>{\centering{\begin{bytefield}[bitwidth=0.1em]{230}
375
  \\
376
  \bitheader{19,99, 199, 229}\\
377
  \bitbox{20}{IP}
378
  \bitbox{210}{}\\
379
  \bitbox[t]{100}{}
380
  \bitbox[t]{100}{$\underbrace{\hspace{10em}}_{\text{\normalsize Frag 2}}$}\\
381
  \end{bytefield}}}
382

    
383
\only<3>{\centering{\begin{bytefield}[bitwidth=0.1em]{230}
384
  \\
385
  \bitheader{19,99, 199, 229}\\
386
  \bitbox{20}{IP}
387
  \bitbox{210}{}\\
388
  \bitbox[t]{200}{}
389
  \bitbox[t]{30}{$\underbrace{\hspace{3em}}_{\text{\normalsize Frag 3}}$}\\
390
  \end{bytefield}}}
391
    
392
\bii 
393
  \ii frammento 1:
394
  \begin{bytefield}[bitwidth=0.1em]{120}
395
  \\
396
  \bitbox{20}{IP}
397
  \bitbox{100}{\bytefieldsetup{bitheight=3ex}\bitbox{20}{IP}\bitbox{75}{}}
398
  \end{bytefield}
399
  \ii frammento 2: 
400
  \begin{bytefield}[bitwidth=0.1em]{120}
401
  \\
402
  \bitbox{20}{IP}
403
  \bitbox{100}{\bytefieldsetup{bitheight=3ex}\bitbox{96}{}}
404
  \end{bytefield}  
405
  \ii frammento 3:
406
  \begin{bytefield}[bitwidth=0.1em]{40}
407
  \\
408
  \bitbox{20}{IP}
409
  \bitbox{30}{\bytefieldsetup{bitheight=3ex}\bitbox{26}{}}
410
  \end{bytefield}
411
\ei
412
}
413

    
414

    
415
\frame
416
{
417
\frametitle{Fragmentation attacks, segue:}
418
\begin{itemize}
419
\uncover<1->{\item I firewall normalmente vengono configurati per bloccare
420
i tentativi di connessione dall'esterno della rete verso le porte alte
421
(oltre la 1024) dei server.  Devono pero' lasciare passare i pacchetti che
422
sono rivolti verso porte alte ma che fanno parte di una connessione aperta
423
dall'interno della rete verso l'esterno.}
424
\uncover<2->{\item Per bloccare i tentativi di aprire una connessione 
425
verso l'interno i firewall \emph{stateless} filtrano i pacchetti con il flag SYN del protocollo TCP
426
settato ad 1 (pacchetti di inizio connessione) rivolti ad una porta oltre la 1024.}
427
\end{itemize}
428
}
429

    
430

    
431
\frame
432
{
433
\frametitle{Tiny Fragments Attack}
434
\only<1>{\centering{
435
Len = 300B
436

    
437
\begin{bytefield}[bitwidth=0.1em]{230}
438
  \\
439
  \bitheader{19,39,299}\\
440
  \bitbox{20}{IP}
441
  \bitbox{20}{TCP}
442
  \bitbox{260}{Payload}
443
  \end{bytefield}}}
444
\only<2>{\centering{\begin{bytefield}[bitwidth=0.1em]{230}
445
  \\
446
  \bitheader{23, 39,299}\\
447
  \bitbox{20}{IP}
448
  \bitbox{20}{TCP}
449
  \bitbox{260}{Payload}\\
450
  \bitbox[t]{24}{$\underbrace{\hspace{\width}}_{\text{\normalsize 24B}}$}
451
  \end{bytefield}}}
452
\only<3>{\centering{\begin{bytefield}[bitwidth=0.1em]{230}
453
  \\
454
  \bitheader{23, 39,299}\\
455
  \bitbox{20}{IP}
456
  \bitbox{20}{TCP}
457
  \bitbox{260}{Payload}\\
458
  \bitbox[t]{24}{}
459
  \bitbox[t]{276}{$\underbrace{\hspace{\width}}_{\text{\normalsize 276B}}$}
460

    
461
  \end{bytefield}}}
462
      
463
\bcols
464
\col[0.4]
465
\only<2-3>{
466
 \begin{bytefield}[bitwidth=0.3em]{32}
467
\tiny
468
    \begin{rightwordgroup}{\tiny IP Header + \\ \tiny 8B TCP header}
469
    \bitbox{4}{Ver}
470
    \bitbox{4}{IHL}
471
    \bitbox{8}{TOS}
472
    \bitbox{16}{LEN}\\
473
\tiny
474
      \bitbox{32}{[...]}\\
475
\tiny
476
      \bitbox{16}{Sport} 
477
    \bitbox{16}{\alert{Dport}}
478
    \end{rightwordgroup}
479
  \end{bytefield}
480
  Primo Frammento:\\
481
  offset = 0, len = 24  
482
  }
483
  
484

    
485
\col[0.6] 
486
\only<3>{
487
 \begin{bytefield}[bitwidth=0.5em]{32}
488
  \tiny
489
    \begin{rightwordgroup}{ \tiny Resto TCP header\\  \tiny + Payload}
490
      \bitbox{32}{Acknowledgment number} \\
491
 \tiny      \bitbox{4}{Offset} 
492
      \bitbox{4}{RES}  
493
      \bitbox{3}{\color{gray}\rule{\width}{\height}} 
494
      \bitbox{1}{\alert{S\\Y\\N}}      
495
      \bitbox{4}{\color{gray}\rule{\width}{\height}} 
496
      \bitbox{16}{Window}\\ 
497
 \tiny      \bitbox{16}{Checksum} 
498
      \bitbox{16}{Urgent Pointer} \\
499
 \tiny      \bitbox{32}{Option + padding} \\
500
 \tiny      \bitbox{32}{Payload...}
501
    \end{rightwordgroup}
502
  \end{bytefield}
503
  Secondo Frammento:\\
504
  offset = 3 (x8), len = 276
505
    }
506
\ecols
507
}
508

    
509
\frame
510
{
511
\frametitle{Fragmentation attacks, segue:}
512
\bii 
513
\item Utilizzando un primo frammento che non contiene i flag TCP il
514
firewall lascia passare il frammento anche se diretto verso una porta >
515
1024, il secondo frammento non viene interpretato come un pacchetto TCP
516
perché non contiene un header TCP valido, quindi anche quello non viene filtrato.
517
\item Quando il pacchetto arriva alla macchina di destinazione
518
viene riassemblato, è diretto verso una porta > 1024 ed ha il flag SYN=1
519
ma ha superato il firewall
520
\ii Rimedio: drop di tutti i frammenti sotto una dimensione minima. 
521
\item E se un firewall non filtra i pacchetti verso porta 80?
522
\end{itemize}
523

    
524
}
525

    
526

    
527
\frame
528
{
529
\frametitle{Overlapping fragments attack}
530
\only<1>{\centering{
531
Len = 300B
532

    
533
\begin{bytefield}[bitwidth=0.1em]{230}
534
  \\
535
  \bitheader{19,39,299}\\
536
  \bitbox{20}{IP}
537
  \bitbox{20}{TCP}
538
  \bitbox{260}{Payload}
539
  \end{bytefield}}}
540
\only<2>{\centering{\begin{bytefield}[bitwidth=0.1em]{230}
541
  \\
542
  \bitheader{23, 39,299}\\
543
  \bitbox{20}{IP}
544
  \bitbox{20}{TCP}
545
  \bitbox{260}{Payload}\\
546
  \bitbox[t]{200}{$\underbrace{\hspace{\width}}_{\text{\normalsize 200B}}$}
547
  \end{bytefield}}}
548
\only<3>{\centering{\begin{bytefield}[bitwidth=0.1em]{230}
549
  \\
550
  \bitheader{23, 39,299}\\
551
  \bitbox{20}{IP}
552
  \bitbox{20}{TCP}
553
  \bitbox{260}{Payload}\\
554
  \bitbox[t]{24}{}
555
  \bitbox[t]{276}{$\underbrace{\hspace{\width}}_{\text{\normalsize 276B}}$}
556

    
557
  \end{bytefield}}}
558
      
559
\bcols
560
\col[0.4]
561
\only<2-3>{
562
 \begin{bytefield}[bitwidth=0.3em]{32}
563
\tiny
564
    \begin{rightwordgroup}{\tiny IP Header + \\ \tiny 8B TCP header}
565
    \bitbox{4}{Ver}
566
    \bitbox{4}{IHL}
567
    \bitbox{8}{TOS}
568
    \bitbox{16}{LEN}\\
569
\tiny
570
      \bitbox{32}{[...]}\\
571
\tiny
572
      \bitbox{16}{Sport} 
573
    \bitbox{16}{\alert{Dport = 80}}\\
574
    \bitbox{32}{...}
575
    \end{rightwordgroup}
576
  \end{bytefield}
577
  Primo Frammento:\\
578
  offset = 0, len = 200  
579
  }
580
  
581

    
582
\col[0.6] 
583
\only<3>{
584
 \begin{bytefield}[bitwidth=0.5em]{32}
585
  \tiny
586
    \begin{rightwordgroup}{ \tiny Src/Dest IP + \\ \tiny Resto TCP header\\  \tiny + Payload}
587
 \tiny 
588
     \bitbox{16}{Src IP}
589
     \bitbox{16}{Dest IP}\\
590
    \tiny
591
      \bitbox{16}{Sport} 
592
    \bitbox{16}{\alert{Dport = X > 1024}}\\
593
\tiny      \bitbox{32}{Acknowledgment number} \\
594
 \tiny      \bitbox{4}{Offset} 
595
      \bitbox{4}{RES}  
596
      \bitbox{8}{Flags} 
597
      \bitbox{16}{Window}\\ 
598
 \tiny      \bitbox{16}{Checksum} 
599
      \bitbox{16}{Urgent Pointer} \\
600
 \tiny      \bitbox{32}{[...]}
601
    \end{rightwordgroup}
602
  \end{bytefield}
603
  Secondo Frammento:\\
604
  offset = 2 (x8), len = 276
605
    }
606
\ecols
607
}
608

    
609
\begin{frame}
610
\frametitle{Overlapping Fragments}
611
\bi 
612
\ii Il primo frammento ha un header IP valido ed un header TCP con porta destinazione 80, quindi il firewall lo lascia passare
613
\ii Il secondo frammento riscrive parte del primo e cambia la porta, ma non contiene un pacchetto IP valido, quindi il firewall non lo può analizzare
614
\ii Il pacchetto viene consegnato a destinazione e riassemblato
615
\ii Rimedio: usare un firewall \emph{stateful}
616
\ei
617
\end{frame}
618

    
619

    
620

    
621
\begin{frame}
622
\frametitle{Sbagliata gestione dei pacchetti}
623
\bi 
624
\ii Si sono verificati in passato molti casi in cui gli stack protocollari sbagliavano a gestire i frammenti
625
\ii In particolare non verificavano la coerenza delle sovrapposizioni
626
\ii Mandando frammenti con buchi nel mezzo, o più lunghi della lunghezza massima si potevano provocare dei segfault nello stack della macchina ricevente
627
\ei
628
\end{frame}
629

    
630

    
631
\frame{
632
\center{\large SYN Flood}
633
}
634

    
635

    
636
\frame
637
{
638
\frametitle{Recall TCP}
639
\scaledimg{setup}
640
}
641

    
642

    
643

    
644
\frame
645
{
646
\frametitle{SYN Flooding}
647
\begin{beamerboxesrounded}[shadow=true]{SYN flood:}
648
\begin{itemize}
649
\uncover<1->{\item Ogni volta che un server riceve un pacchetto con
650
SYN=1 alloca delle risorse di memoria per gestire la connessione che sta
651
per essere creata, quindi invia un pacchetto con i flag SYN=1, ACK=1 e
652
fa partire un timeout per attendere l'arrivo del terzo pacchetto
653
dell'handshake. Si dice che in quel momento sul server c'è una connessione
654
\emph{half-open}.}
655
\end{itemize}
656
\end{beamerboxesrounded}
657
}
658

    
659

    
660

    
661
\frame
662
{
663
\frametitle{TCP SM}
664
\scaledimg[0.8]{tcp_SM}
665
}
666

    
667
\frame
668
{
669
\frametitle{SYN Flooding}
670
\begin{beamerboxesrounded}[shadow=true]{SYN flood:}
671
\begin{itemize}
672
\item Se un attaccante invia un grande numero di pacchetti
673
con SYN=1, prima o poi la memoria del server
674
si saturerà e il server comincerà a scartare pacchetti.
675
\item In alternativa, si raggiungerà il numero massimo di connessioni contemporanee ammesse dal server, ottenendo lo stesso scopo.
676
\item In questo modo si impedisce ad altre macchine di accedere al servizio, un DoS.
677
\end{itemize}
678
\end{beamerboxesrounded}
679
}
680

    
681
\frame
682
{
683
\frametitle{SYN Flooding + IP spoofing}
684
\begin{itemize}
685
\item Un server potrebbe accorgersi che da un IP remoto X sta iniziando un grande numero di connessioni, e cominciare a  filtrare solo i pacchetti provenienti da X.
686
\item L'attacco però per funzionare non necessita che X riceva il pacchetto SYN+ACK.
687
\item L'attacco può quindi essere compiuto usando IP sorgente spoofato, e filtrare con una ACL non è più sufficiente
688
\item L'attaccante deve però usare indirizzi IP sorgenti validi ma su cui non ci sono macchine in ascolto, altrimenti queste macchine risponderanno con un messaggio RST e faranno deallocare la memoria al server
689
\item Conclusione: con un piccolo sforzo da parte dell'attaccante si può produrre un DoS su un server con molte risorse.
690
\end{itemize}
691
}
692

    
693

    
694

    
695
\frame
696
{
697
\frametitle{Attacchi a livello IV:}
698
\begin{beamerboxesrounded}[shadow=true]{SYN cookies:}
699
\begin{itemize}
700
\item Non esistono rimedi comunemente accettati per gli
701
attacchi di SYN Flood, oltre a chiedere agli AS di filtrare i pacchetti da indirizzi IP che non sono loro.
702
\item Un metodo per evitare questo attacco prevede l'utilizzo
703
di SYN cookies, descritti nella RFC 4987: 
704
\begin{itemize}
705
\item quando il server invia il pacchetto SYN=1 e
706
ACK=1 non sceglie un numero di sequenza casuale, ma sceglie un numero che
707
è la codifica di informazioni riguardanti la connessione e non alloca
708
nessuna memoria. Es:
709
\bi 
710
\ii 5 bit: $t\, \%\, 32$ con $t$ contatore incrementato ogni 64 secondi
711
\ii \emph{\color{gray}3 bit: codifica di MSS} $\leftarrow$ non rilevante per noi
712
\ii 24 bit: $f(s, IP_s, Port_s, IP_d, Port_d, t)$ con $s$ segreto
713
\ei 
714
\end{itemize}
715
\item Il numero di sequenza è comunque impredicibile, per evitare gli attacchi di \alert{SYN spoofing}. 
716
\item C'è bisogno di uno stato interno (un unico contatore) ed un segreto usato come seed.
717
\end{itemize}
718
\end{beamerboxesrounded}
719
}
720

    
721

    
722
\frame
723
{
724
\frametitle{Attacchi a livello IV:}
725
\bi 
726
\item Quando il server riceve il terzo pacchetto della connessione (ACK), estrae l' acknowledgement number $a$. 
727
\ii estrae anche IP e porte dal pacchetto ACK
728
\ii calcola $a-1 \stackrel{?}{=} f(s, IP_s, Port_s, IP_d, Port_d, t)$ per valori recenti di $t$
729
\ii se trova un valore di $t$ percui la condizione è vera, il pacchetto ACK appartiene ad una connessione half-open e può allocare memoria
730
\ei
731
}
732
\frame
733
{
734
\frametitle{SYN Cookies}
735
\bi 
736
\ii In pratica, il server codifica informazioni di stato nel sequence number, sapendo che il client restituirà lo stato nell'ACK number
737
\ii Il server così non alloca memoria prima di ricevere un pacchetto di ACK
738
\ei
739
}
740

    
741

    
742

    
743
\frame
744
{
745
\frametitle{Problemi}
746
\bi 
747
\ii TCP supporta estensioni che vengono incluse nel pacchetto di SYN dal client (ad esempio il Maximum Segment Size che il client può ricevere, MSS)
748
\ii Normalmente un server quando riceve un SYN, alloca in memoria una struttura dati che contiene anche informazioni su tali estensioni
749
\ii Se il server non alloca memoria alla ricezione del SYN, si perde le opzioni.
750
\ii Workaround:
751
\bi 
752
\ii Codifica alcune opzioni nel sequence number
753
\ii Non usare sempre i SYN cookies, usarli solo quando si è sotto attacco (il numero di connessioni half-open supera una certa soglia)
754
\ei 
755
\ei
756
}
757

    
758

    
759
\frame{
760
\center{\large TCP reset guess}
761
}
762

    
763

    
764
\frame
765
{
766
\frametitle{Attacchi a livello IV:}
767
\begin{beamerboxesrounded}[shadow=true]{TCP reset Guess:}
768
\begin{itemize}
769
\uncover<1->{\item Una connessione TCP può essere terminata da uno dei due
770
partecipanti inviando un pacchetto con il flag RST=1. Perché venga
771
accettato il pacchetto deve contenere i valori corretti di:
772
\begin{itemize}
773
\uncover<2->{\item Indirizzo IP mittente e destinazione}
774
\uncover<3->{\item Porta TCP mittente e destinazione}
775
\uncover<4->{\item Numero di sequenza corretto all'interno del flusso}
776
\end{itemize}
777
\uncover<5->{\item Un'attaccante che vuole interrompere una connessione
778
tra due macchine remote deve conoscere gli IP, può indovinare le porte
779
(una è nota e l'altra forse predicibile), ma non può conoscere il numero di
780
sequenza corretto. Deve provare un \emph{Brute Force}.} 
781
\end{itemize}
782
\end{beamerboxesrounded}
783
}
784
}
785

    
786
\frame
787
{
788
\frametitle{Attacchi a livello IV:}
789
\begin{beamerboxesrounded}[shadow=true]{TCP reset Guess: qualche conto}
790
\begin{itemize}
791
\uncover<1->{\item Il numero di sequenza è un campo a 32 bit, quindi uno spazio
792
di $2^{32}=4,294,967,295$ cifre.} 
793
\uncover<2->{\item Il protocollo TCP però impone che per essere ricevuto
794
correttamente, un pacchetto di reset deve semplicemente cascare nella
795
finestra di ricezione valida della macchina sotto attacco . Una finestra di ricezione
796
può essere larga fino a $2^{16}$ bit.
797
\uncover<3->{\item Non c'è quindi bisogno di provare tutti i numeri di
798
sequenza, ma provando con numeri di sequenza distanti non più di $2^{16}$ si
799
è ragionevolmente sicuri di riuscire a interrompere la connessione.}
800
\uncover<4->{\item si ottiene che di $(2^{32}/2^{16})=2^{16}=65,535$ cifre.} 
801
\end{itemize}
802
\end{beamerboxesrounded}
803
}
804
}
805

    
806
\frame
807
{
808
\frametitle{TCP reset Guess: qualche conto}
809

    
810
Se un pacchetto TCP RST è composto da 20B di header IP + 20 di header TCP, abbiamo:
811
\begin{scriptsize}
812
\begin{table}[h]
813
  \begin{tabular}{|c|c|c|c|}
814
\hline
815
  Velocità upload & \# Pacchetti & Tempo per una porta \\
816
\hline
817
\hline
818
  256 kbps & 65,537 & $\approx$ 90s \\
819
\hline
820
  1 mbps & 65,537 & $\approx$ 20s \\
821
\hline
822
  32 mbps & 65,537 & $<$ 1s \\
823
\hline
824
  256 mbps & 65,537 & $<$ 1/10s \\
825
\hline
826
  \end{tabular}
827
\end{table}
828
\end{scriptsize}
829

    
830
}
831

    
832
\frame{
833
\frametitle{RWIN di default}
834
\scaledimg[0.8]{RWIN}
835

    
836
Misurati da cdnplanet nel 2011 (https://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/).
837
}
838

    
839

    
840

    
841
\frame{
842
\center\large{DNS Poisoning}
843
}
844

    
845
%
846

    
847

    
848
\subsection{DNS Poisoning}
849
\frame{
850
\frametitle{recall DNS}
851
\bii
852
\ii Ogni host deve poter risolvere un indirizzo di rete da una stringa
853
alfanumerica (un dominio) ad un indirizzo IP. Questa operazione viene
854
svolta con il protocollo DNS, Domain Name System.
855
\ii Per ogni dominio in rete, esiste un server che può svolgere questo
856
compito in modo \emph{autoritative}
857
\ii L'indirizzo di un server \emph{autoritative} non è noto per ogni
858
dominio a priori, quindi ogni host è configurato con un indirizzo di un
859
server DNS locale
860
\ii Il server DNS locale richiederà a dei root server l'indirizzo dei DNS
861
validi per un certo dominio
862
\ii Una volta realizzata la risoluzione nome/IP, il DNS locale mantiene
863
l'associazione in una cache, per un certo periodo.
864
\ei
865
}
866

    
867
\frame{
868
\frametitle{recall DNS}
869
\scaledimg[0.8]{rete}
870
}
871

    
872
\frame{
873
\frametitle{Attacchi sul DNS}
874
\bii
875
\ii In generale, un attacco su un DNS serve a far credere ad un certo host
876
vittima che l'IP che corrisponde ad un nome di dominio è un IP diverso da
877
quello originale.
878
\ii Il protocollo DNS non utilizza forme di cifratura per proteggere i
879
pacchetti, quindi si possono falsificare le risposte di un DNS server.
880
\ii A cosa serve un attacco del genere?
881
\bii
882
\ii phishing, 
883
\ii furto di credenziali
884
\ii attacchi su home-banking
885
\ii redirezione di connessioni e mitm in generale
886
\ei
887
\ei
888
}
889

    
890
\frame{
891
\frametitle{DNS Attack}
892
Dove può essere realizzato l'attacco?
893
\bcols
894
\col[0.4]
895
\bii
896
\ii Nella rete locale
897
\ii Nella richiesta da/verso il server DNS locale
898
\ii Nella richiesta da/verso uno dei server authoritative
899
\ei
900
\col[0.6]
901
\scaledimg{rete}
902
\ecols
903
}
904

    
905
\frame{
906
\frametitle{DNS Attack - Layer II}
907
\bi
908
\ii Già abbiamo visto come a livello II si possono realizzare attacchi di
909
tipo MITM su varie tecnologie:
910
\bi
911
\ii arp-spoofing per reti ethernet
912
\ei
913
Non è quindi sorprendente immaginare che lo stesso attacco possa essere
914
utilizzato per modificare i pacchetti di:
915
\bii
916
\ii DHCP: assegnando ad un nodo della rete un nuovo indirizzo del server
917
DHCP, controllato dall'attaccante
918
\ii DNS responses: modificando i pacchetti che arrivano dal server DNS
919
\ei
920
\ei
921
}
922
\frame{
923
\frametitle{DNS Attack - Layer III}
924
\bii
925
\ii Se l'attaccante è nel path tra il server DNS locale e quello remoto,
926
l'attacco è banale
927
\ii Altrimenti l'attaccante deve poter rispondere ad una richiesta DNS
928
prima del server remoto pertinente.
929
\ii Quali sono i campi interessanti di un pacchetto DNS?
930
\bii
931
\ii La porta UDP di origine e destinazione
932
\ii L'IP di origine e destinazione
933
\ii L'ID del pacchetto, ovvero un numero scelto a caso da chi invia la
934
richesta che deve essere replicato nella risposta
935
\ei
936
\ei
937
}
938
\frame{
939
\frametitle{DNS Attack - Layer III}
940
\bii
941
\ii Lo scopo dell'attaccante è quello di riuscire a inquinare la cache del
942
server DNS locale, ovvero di rispondere al posto del server DNS remoto.
943
\ii Per farlo, nel momento in cui il server DNS locale invia una richiesta
944
per un dominio remoto l'attaccante deve rispondere con un pacchetto
945
forgiato, che contenga le caratteristiche giuste:
946
\bii
947
\ii l'indirizzo IP sorgente $\rightarrow$ quello del server remoto
948
(\alert{prevedibile})
949
\ii la porta UDP sorgente $\rightarrow$ quella del server remoto
950
(\alert{53})
951
\ii l'indirizzo IP destinazione $\rightarrow$ quello del server locale
952
(\alert{prevedibile})
953
\ii la porta UDP destinazione $\rightarrow$ quella usata dal server locale
954
per inviare la richiesta (\alert{non prevedibile?})
955
\ii l'ID del pacchetto $\rightarrow$ quello del pacchetto di richiesta
956
(\alert{non prevedibile!})
957
\ei
958
\ii Ci sono quindi due campi, entrambi di 16 bit (porta e ID) che
959
potrebbero essere non prevedibili dall'attaccante 
960
\ei
961
}
962

    
963
\frame{
964
\frametitle{DNS Attack}
965
\begin{center}
966
\scaledimg[0.8]{DNS-attack}
967
\end{center}
968
}
969

    
970

    
971
\frame{
972
\frametitle{DNS Attack - due calcoli}
973
\bii
974
\ii 32 bit $\rightarrow$ $2^{32}$ possibilità 
975
\ii $2^{32} \simeq$ 4 miliardi di pacchetti
976
\ii L'attaccante, ammesso che sappia il momento in cui deve inviare la
977
risposta fasulla, deve inviare prima del server remoto mediamente 2
978
miliardi di pacchetti.
979
\ii Se ogni pacchetto è lungo 80 byte, l'attaccante deve mandare 160GB di
980
traffico prima che il server remoto possa rispondere.
981
\ei
982
}
983

    
984
\frame{
985
\frametitle{DNS Attack - restringiamo le ipotesi}
986
\bii
987
\ii Alcuni server DNS non utilizzano una porta casuale per inviare le
988
richieste
989
\bii
990
\ii BIND sceglie una porta all'avvio e continua ad usarla
991
\ei
992
\ii una volta scoperta la porta rimangono $2^{16}$ bit da indovinare, che
993
sono comunque $65000*80 \simeq 5MB$ da inviare in poche decine di
994
millisecondi
995
\ei
996
}
997

    
998
\frame{
999
\frametitle{DNS Attack - restringiamo le ipotesi}
1000
\bii
1001
\ii Immaginiamo che l'attaccante (Eve) possa far iniziare la richiesta al server
1002
DNS (o è all'interno della rete, oppure il server DNS (Alice) accetta
1003
anche richieste dall'esterno)
1004
\ii A questo punto l'attaccante sa quando avverrà la richiesta:
1005
\bii
1006
\ii Eve invia ad Alice una richiesta per il dominio www.example.com
1007
\ii Alice reinvia la richiesta al server DNS di example.com (Bob)
1008
\ii Eve prova a rispondere prima di Bob, con un flood di n risposte fasulle
1009
\ei
1010
\ii quante probabilità ha di riuscire? $n/2^{16}$ ammesso che il server
1011
DNS riesca a elaborare tutte le risposte forgiate.
1012
\ii Ci può aiutare il paradosso del compleanno.
1013
\ei
1014
}
1015
\frame{
1016
\frametitle{DNS Attack - Bithday paradox}
1017
Una parentesi, il birthday paradox.
1018
\bii
1019
\ii Quale è la possibilità $P(n)$ che tra le persone in questa stanza ce ne siano
1020
due nate nello stessio giorno? Per calcolare questo valore si usa la
1021
probabilità inversa: 
1022
\bii
1023
\ii $\overline{P}(n)$ = \emph{probabilità che su n persone nessuna sia nata lo stesso giorno}
1024
\ii $\overline{P}(n) =
1025
\frac{364}{365}*\frac{363}{365}*\frac{362}{365}\ldots\frac{365-(n-1)}{365}$
1026
\ii Invertendo: $P(n) = 1-\overline{P}(n)$, che si può scrivere $P(n) = 1 - \prod_{i=1}^{(n-1)}\frac{365-i}{365}$.
1027
\ii Abbastanza sorprendentemente:
1028
\bii
1029
\ii per n=23 P(n) $\simeq$ 51\%, 
1030
\ii per n=30 P(n) $\simeq$ 70\%, 
1031
\ii per n=40 P(n) $\simeq$ 97\%, 
1032
\ei
1033
\ei
1034
\ei
1035
}
1036

    
1037

    
1038
\frame{
1039
\frametitle{DNS Attack - Bithday paradox}
1040
\bii
1041
\ii Come si applica il paradosso all'attacco di DNS poisoning?
1042
\ii Se Eve fa n richieste per l'host
1043
www.example.com, Alice genererà un ID a caso tra 0 e $2^{16}$
1044
per ognuna delle richieste verso Bob. Alice interromperà l'inivo delle richieste
1045
quando riceverà almeno una risposta valida.
1046
\ii Contemporaneamente Eve invierà un burst di risposte falsificate, con un ID scelto a caso.
1047
\ii Se l'ID di almeno una di queste risposte false corrisponde con l'ID di
1048
almeno una delle richieste inviate (e viene ricevuta prima di quella
1049
di Bob) allora Alice avrà nella cache un entry
1050
per www.example.com 
1051
\ii Statisticamente, per il paradosso del compleanno, inviando 700
1052
richieste/risposte si ha ua probabilità vicina al 100\% di indovinare
1053
almeno una risposta. 
1054
\ii In questo modo la cache rimane inquinata e tutte le richieste
1055
successive verranno redirette verso l'host controllato da Eve.
1056
\ei
1057
}
1058

    
1059
\frame{
1060
\frametitle{DNS Attack - Conclusioni}
1061
\bii
1062
\ii Fare poisoning di un server DNS è in linea teorica possibile ma molto
1063
difficile,
1064
\ii Sotto opportune ipotesi però l'attacco è perfettamente realizzabile
1065
con dei mezzi a disposizione di chiunque
1066
\ii L'attacco può essere reso più facile se il server DNS originario (Bob)
1067
è sotto un attacco di DoS, quindi non risponde prontamente
1068
\ii Per evitare che l'attacco sia applicabile è importante scegliere bene
1069
gli applicativi che si usano, avendo la certezza, ad esempio, che
1070
utilizzino porte sorgenti casuali.
1071
\ei
1072
}
1073

    
1074