Revision 52471fcf body.tex

View differences:

body.tex
1 1
\section{Attacchi Al Mezzo Fisico}
2 2

  
3 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

  
4 15
\frame
5 16
{
6 17
\frametitle{Attacchi al mezzo fisico}
......
56 67
\end{beamerboxesrounded}
57 68
}
58 69

  
70

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

  
59 75
\frame
60 76
{
61 77
\frametitle{ARP-Spoofing}
......
117 133
    \end{minipage}
118 134
    }
119 135
    \end{center}
120
\vskip1cm
121 136
\bi 
122 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à
123 140
\ei 
124 141
}
125 142

  
......
195 212
\bi
196 213
\ii Alla fine dell'attacco Alice e Bob possono mantenere delle connessioni funzionanti che vengono in realtà analizzate da Eve
197 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.
198 216
\ei
199 217
\end{frame}
200 218

  
201 219
\begin{frame}
202 220
\frametitle{ARP spoofing: Mantenimento}
203
\bi
204
\ii Che succede se per qualche motivo Alice deve mandare un pacchetto ad un quarto host?
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?
205 223
\ii Alice invia una nuova richiesta ARP in broadcast, e corregge la tabella ARP di Bob
206 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
207 231
\ei
208 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}
209 238

  
210 239

  
211 240
\frame
......
221 250
}
222 251

  
223 252
\subsection{Fragmentation attacks}
253

  
254

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

  
259

  
224 260
\frame
225 261
{
226 262
\frametitle{Fragmentation attacks}
......
229 265
\col[0.4]
230 266

  
231 267
\bi 
232
\ii Sappiamo che il IP permette di spezzare un pacchetto in
268
\ii Sappiamo che IP permette di spezzare un pacchetto in
233 269
più frammenti
234 270
\ii Il campo Fragment Offset esprime l'offset del pacchetto rispetto all'originale, espresso in multipli di 8 byte
235 271
\ii Total length esprime la lunghezza del pacchetto (frammento) in Byte, header incluso
......
386 422
sono rivolti verso porte alte ma che fanno parte di una connessione aperta
387 423
dall'interno della rete verso l'esterno.}
388 424
\uncover<2->{\item Per bloccare i tentativi di aprire una connessione 
389
verso l'interno filtrano i pacchetti con il flag SYN del protocollo TCP
390
settato ad 1 (pacchetti di inizio 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.}
391 427
\end{itemize}
392 428
}
393 429

  
......
470 506
\ecols
471 507
}
472 508

  
473

  
474 509
\frame
475 510
{
476 511
\frametitle{Fragmentation attacks, segue:}
......
483 518
viene riassemblato, è diretto verso una porta > 1024 ed ha il flag SYN=1
484 519
ma ha superato il firewall
485 520
\ii Rimedio: drop di tutti i frammenti sotto una dimensione minima. 
486
\item E se un firewall filtra tutti i pacchetti verso la porta 22 ma non verso la 80?
521
\item E se un firewall non filtra i pacchetti verso porta 80?
487 522
\end{itemize}
488 523

  
489 524
}
......
508 543
  \bitbox{20}{IP}
509 544
  \bitbox{20}{TCP}
510 545
  \bitbox{260}{Payload}\\
511
  \bitbox[t]{24}{$\underbrace{\hspace{\width}}_{\text{\normalsize 24B}}$}
546
  \bitbox[t]{200}{$\underbrace{\hspace{\width}}_{\text{\normalsize 200B}}$}
512 547
  \end{bytefield}}}
513 548
\only<3>{\centering{\begin{bytefield}[bitwidth=0.1em]{230}
514 549
  \\
......
535 570
      \bitbox{32}{[...]}\\
536 571
\tiny
537 572
      \bitbox{16}{Sport} 
538
    \bitbox{16}{\alert{Dport = 80}}
573
    \bitbox{16}{\alert{Dport = 80}}\\
574
    \bitbox{32}{...}
539 575
    \end{rightwordgroup}
540 576
  \end{bytefield}
541 577
  Primo Frammento:\\
542
  offset = 0, len = 24  
578
  offset = 0, len = 200  
543 579
  }
544 580
  
545 581

  
......
553 589
     \bitbox{16}{Dest IP}\\
554 590
    \tiny
555 591
      \bitbox{16}{Sport} 
556
    \bitbox{16}{\alert{Dport = 22}}\\
592
    \bitbox{16}{\alert{Dport = X > 1024}}\\
557 593
\tiny      \bitbox{32}{Acknowledgment number} \\
558 594
 \tiny      \bitbox{4}{Offset} 
559 595
      \bitbox{4}{RES}  
......
573 609
\begin{frame}
574 610
\frametitle{Overlapping Fragments}
575 611
\bi 
576
\ii Il primo frammento ha un header IP valido ed un pezzo di header TCP con porta destinazione 80, quindi il firewall lo lascia passare
612
\ii Il primo frammento ha un header IP valido ed un header TCP con porta destinazione 80, quindi il firewall lo lascia passare
577 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
578 614
\ii Il pacchetto viene consegnato a destinazione e riassemblato
615
\ii Rimedio: usare un firewall \emph{stateful}
579 616
\ei
580 617
\end{frame}
581 618

  
......
591 628
\end{frame}
592 629

  
593 630

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

  
635

  
594 636
\frame
595 637
{
596 638
\frametitle{Recall TCP}
......
714 756
}
715 757

  
716 758

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

  
763

  
717 764
\frame
718 765
{
719 766
\frametitle{Attacchi a livello IV:}
......
728 775
\uncover<4->{\item Numero di sequenza corretto all'interno del flusso}
729 776
\end{itemize}
730 777
\uncover<5->{\item Un'attaccante che vuole interrompere una connessione
731
tra due macchine remote deve conosce gli IP, può indovinare le porte
732
(una è nota e l'altra predicibile), ma non può conoscere il numero di
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
733 780
sequenza corretto. Deve provare un \emph{Brute Force}.} 
734 781
\end{itemize}
735 782
\end{beamerboxesrounded}
......
760 807
{
761 808
\frametitle{TCP reset Guess: qualche conto}
762 809

  
763
Se un pacchetto TCP RST è composto da 20B di header IP + 24 di header TCP, abbiamo:
810
Se un pacchetto TCP RST è composto da 20B di header IP + 20 di header TCP, abbiamo:
764 811
\begin{scriptsize}
765 812
\begin{table}[h]
766 813
  \begin{tabular}{|c|c|c|c|}
......
780 827
\end{table}
781 828
\end{scriptsize}
782 829

  
783
Attacco realistico: fibra con 100 mbps di upload, finestra da 
784 830
}
785 831

  
786 832
\frame{
......
792 838

  
793 839

  
794 840

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

  
795 845
%
796
%
797
%\pgfdeclareimage[width=8cm]{rete}{images-intro/rete}
798
%\pgfdeclareimage[width=6cm]{retel}{images-intro/rete}
799
%%\pgfdeclareimage[width=8cm]{attack}{images-intro/attack}
800
%
801
%\subsection{DNS Poisoning}
802
%\frame{
803
%\frametitle{recall DNS}
804
%\bii
805
%\ii Ogni host deve poter risolvere un indirizzo di rete da una stringa
806
%alfanumerica (un dominio) ad un indirizzo IP. Questa operazione viene
807
%svolta con il protocollo DNS, Domain Name System.
808
%\ii Per ogni dominio in rete, esiste un server che può svolgere questo
809
%compito in modo \emph{autoritative}
810
%\ii L'indirizzo di un server \emph{autoritative} non è noto per ogni
811
%dominio a priori, quindi ogni host è configurato con un indirizzo di un
812
%server DNS locale
813
%\ii Il server DNS locale richiederà a dei root server l'indirizzo dei DNS
814
%validi per un certo dominio
815
%\ii Una volta realizzata la risoluzione nome/IP, il DNS locale mantiene
816
%l'associazione in una cache, per un certo periodo.
817
%\ei
818
%}
819
%
820
%\frame{
821
%\frametitle{recall DNS}
822
%\center\pgfuseimage{rete}
823
%
824
%}
825
%
826
%\frame{
827
%\frametitle{Attacchi sul DNS}
828
%\bii
829
%\ii In generale, un attacco su un DNS serve a far credere ad un certo host
830
%vittima che l'IP che corrisponde ad un nome di dominio è un IP diverso da
831
%quello originale.
832
%\ii Il protocollo DNS non utilizza forme di cifratura per proteggere i
833
%pacchetti, quindi si possono falsificare le risposte di un DNS server.
834
%\ii A cosa serve un attacco del genere?
835
%\bii
836
%\ii phishing, 
837
%\ii furto di credenziali
838
%\ii attacchi su home-banking
839
%\ii redirezione di connessioni e mitm in generale
840
%\ei
841
%\ei
842
%}
843
%
844
%\frame{
845
%\frametitle{DNS Attack}
846
%Dove può essere realizzato l'attacco?
847
%\begin{columns}
848
%\column{5cm}
849
%\bii
850
%\ii Nella rete locale
851
%\ii Nella richiesta da/verso il server DNS locale
852
%\ii Nella richiesta da/verso uno dei server authoritative
853
%\ei
854
%\column{6cm}
855
%\begin{center}
856
%\pgfuseimage{retel}
857
%\end{center}
858
%\end{columns}
859
%}
860
%
861
%\frame{
862
%\frametitle{DNS Attack - Layer II}
863
%\bii
864
%\ii Già abbiamo visto come a livello II si possono realizzare attacchi di
865
%tipo MITM su varie tecnologie:
866
%\bii
867
%\ii arp-spoofing per reti ethernet
868
%\ii attacchi sulle chiavi WEP per reti WiFi
869
%\ei
870
%Non è quindi sorprendente immaginare che lo stesso attacco possa essere
871
%utilizzato per modificare i pacchetti di:
872
%\bii
873
%\ii DHCP: assegnando ad un nodo della rete un nuovo indirizzo del server
874
%DHCP, controllato dall'attaccante
875
%\ii DNS responses: modificando i pacchetti che arrivano dal server DNS
876
%\ei
877
%\ei
878
%}
879
%\frame{
880
%\frametitle{DNS Attack - Layer III}
881
%\bii
882
%\ii Se l'attaccante è nel path tra il server DNS locale e quello remoto,
883
%l'attacco è banale
884
%\ii Altrimenti l'attaccante deve poter rispondere ad una richiesta DNS
885
%prima del server remoto pertinente.
886
%\ii Quali sono i campi interessanti di un pacchetto DNS?
887
%\bii
888
%\ii La porta UDP di origine e destinazione
889
%\ii L'IP di origine e destinazione
890
%\ii L'ID del pacchetto, ovvero un numero scelto a caso da chi invia la
891
%richesta che deve essere replicato nella risposta
892
%\ei
893
%\ei
894
%}
895
%\frame{
896
%\frametitle{DNS Attack - Layer III}
897
%\bii
898
%\ii Lo scopo dell'attaccante è quello di riuscire a inquinare la cache del
899
%server DNS locale, ovvero di rispondere al posto del server DNS remoto.
900
%\ii Per farlo, nel momento in cui il server DNS locale invia una richiesta
901
%per un dominio remoto l'attaccante deve rispondere con un pacchetto
902
%forgiato, che contenga le caratteristiche giuste:
903
%\bii
904
%\ii l'indirizzo IP sorgente $\rightarrow$ quello del server remoto
905
%(\alert{prevedibile})
906
%\ii la porta UDP sorgente $\rightarrow$ quella del server remoto
907
%(\alert{53})
908
%\ii l'indirizzo IP destinazione $\rightarrow$ quello del server locale
909
%(\alert{prevedibile})
910
%\ii la porta UDP destinazione $\rightarrow$ quella usata dal server locale
911
%per inviare la richiesta (\alert{non prevedibile?})
912
%\ii l'ID del pacchetto $\rightarrow$ quello del pacchetto di richiesta
913
%(\alert{non prevedibile!})
914
%\ei
915
%\ii Ci sono quindi due campi, entrambi di 16 bit (porta e ID) che
916
%potrebbero essere non prevedibili dall'attaccante 
917
%\ei
918
%}
919
%
920
%\frame{
921
%\frametitle{DNS Attack}
922
%\begin{center}
923
%\scaledimg[0.8]{DNS-attack}
924
%\end{center}
925
%}
926
%
927
%
928
%\frame{
929
%\frametitle{DNS Attack - due calcoli}
930
%\bii
931
%\ii 32 bit $\rightarrow$ $2^{32}$ possibilità 
932
%\ii $2^{32} \simeq$ 4 miliardi di pacchetti
933
%\ii L'attaccante, ammesso che sappia il momento in cui deve inviare la
934
%risposta fasulla, deve inviare prima del server remoto mediamente 2
935
%miliardi di pacchetti.
936
%\ii Se ogni pacchetto è lungo 80 byte, l'attaccante deve mandare 160GB di
937
%traffico prima che il server remoto possa rispondere.
938
%\ei
939
%}
940
%
941
%\frame{
942
%\frametitle{DNS Attack - restringiamo le ipotesi}
943
%\bii
944
%\ii Alcuni server DNS non utilizzano una porta casuale per inviare le
945
%richieste
946
%\bii
947
%\ii BIND sceglie una porta all'avvio e continua ad usarla
948
%\ei
949
%\ii una volta scoperta la porta rimangono $2^{16}$ bit da indovinare, che
950
%sono comunque $65000*80 \simeq 5MB$ da inviare in poche decine di
951
%millisecondi
952
%\ei
953
%}
954
%
955
%\frame{
956
%\frametitle{DNS Attack - restringiamo le ipotesi}
957
%\bii
958
%\ii Immaginiamo che l'attaccante (Eve) possa far iniziare la richiesta al server
959
%DNS (o è all'interno della rete, oppure il server DNS (Alice) accetta
960
%anche richieste dall'esterno)
961
%\ii A questo punto l'attaccante sa quando avverrà la richiesta:
962
%\bii
963
%\ii Eve invia ad Alice una richiesta per il dominio www.example.com
964
%\ii Alice reinvia la richiesta al server DNS di example.com (Bob)
965
%\ii Eve prova a rispondere prima di Bob, con un flood di n risposte fasulle
966
%\ei
967
%\ii quante probabilità ha di riuscire? $n/2^{16}$ ammesso che il server
968
%DNS riesca a elaborare tutte le risposte forgiate.
969
%\ii Ci può aiutare il paradosso del compleanno.
970
%\ei
971
%}
972
%\frame{
973
%\frametitle{DNS Attack - Bithday paradox}
974
%Una parentesi, il birthday paradox.
975
%\bii
976
%\ii Quale è la possibilità $P(n)$ che tra le persone in questa stanza ce ne siano
977
%due nate nello stessio giorno? Per calcolare questo valore si usa la
978
%probabilità inversa: 
979
%\bii
980
%\ii $\overline{P}(n)$ = \emph{probabilità che su n persone nessuna sia nata lo stesso giorno}
981
%\ii $\overline{P}(n) =
982
%\frac{364}{365}*\frac{363}{365}*\frac{362}{365}\ldots\frac{365-(n-1)}{365}$
983
%\ii Invertendo: $P(n) = 1-\overline{P}(n)$, che si può scrivere $P(n) = 1 - \prod_{i=1}^{(n-1)}\frac{365-i}{365}$.
984
%\ii Abbastanza sorprendentemente:
985
%\bii
986
%\ii per n=23 P(n) $\simeq$ 51\%, 
987
%\ii per n=30 P(n) $\simeq$ 70\%, 
988
%\ii per n=40 P(n) $\simeq$ 97\%, 
989
%\ei
990
%\ei
991
%\ei
992
%}
993
%
994
%
995
%\frame{
996
%\frametitle{DNS Attack - Bithday paradox}
997
%\bii
998
%\ii Come si applica il paradosso all'attacco di DNS poisoning?
999
%\ii Se Eve fa n richieste per l'host
1000
%www.example.com, Alice genererà un ID a caso tra 0 e $2^{16}$
1001
%per ognuna delle richieste verso Bob. Alice interromperà l'inivo delle richieste
1002
%quando riceverà almeno una risposta valida.
1003
%\ii Contemporaneamente Eve invierà un burst di risposte falsificate, con un ID scelto a caso.
1004
%\ii Se l'ID di almeno una di queste risposte false corrisponde con l'ID di
1005
%almeno una delle richieste inviate (e viene ricevuta prima di quella
1006
%di Bob) allora Alice avrà nella cache un entry
1007
%per www.example.com 
1008
%\ii Statisticamente, per il paradosso del compleanno, inviando 700
1009
%richieste/risposte si ha ua probabilità vicina al 100\% di indovinare
1010
%almeno una risposta. 
1011
%\ii In questo modo la cache rimane inquinata e tutte le richieste
1012
%successive verranno redirette verso l'host controllato da Eve.
1013
%\ei
1014
%}
1015
%
1016
%\frame{
1017
%\frametitle{DNS Attack - Conclusioni}
1018
%\bii
1019
%\ii Fare poisoning di un server DNS è in linea teorica possibile ma molto
1020
%difficile,
1021
%\ii Sotto opportune ipotesi però l'attacco è perfettamente realizzabile
1022
%con dei mezzi a disposizione di chiunque
1023
%\ii L'attacco può essere reso più facile se il server DNS originario (Bob)
1024
%è sotto un attacco di DoS, quindi non risponde prontamente
1025
%\ii Per evitare che l'attacco sia applicabile è importante scegliere bene
1026
%gli applicativi che si usano, avendo la certezza, ad esempio, che
1027
%utilizzino porte sorgenti casuali.
1028
%\ei
1029
%}
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
}
1030 1073

  
1031 1074

  

Also available in: Unified diff