SÉCURITÉ DES RÉSEAUX

LES ATTAQUES

A. Guermouche

0
Plan

Les attaques?

Quelques cas concrets de MiTM

BGP
OSPF
DNS : Failles & dangers

Déni de service distrbué (DDoS)

Comment se défendre?
Mécanismes de detection d’intrusions
honeypot
SIEM

1
L E S A T T A Q U E S?
Techniques d’attaque/d’intrusion

Attaque. n’importe quelle action qui compromet la sécurité des

informations.
Intrusion. Prise de contrôle partielle ou totale d’un système distant.
Description d’une attaque :
Recherche d’informations. réseau, serveurs, routeurs, . . .
Recherche de vulnérabilités. système d’exploitation, serveurs
applicatifs, . . .
Tentative d’exploitation des vulnérabilités. à distance puis localement
Installation de backdoor.
Installaltion de sniffer.
Suppression des traces.
Attaque par déni de service.

3
Buts des attaques (1/2)
Interruption. vise la disponibilité des informations (DoS, . . . )

Interception. vise la confidentialité des informations (capture de

contenu, analyse de traffic, . . . )

Source de l’attaque

4
Buts des attaques (2/2)

Modification. vise l’intégrité des informations (modification, rejeu, . . . )

Source de l’attaque

Fabrication. vise l’authenticité des informations (mascarade, . . . )

Source de l’attaque

5
Technique de recherche d’information

Recherche d’informations publiques.

DNS, whois, . . .
Découverte du réseau et du filtrage IP.
traceroute, ping, hping, netcat, . . .
Découverte des systèmes d’exploitation.
nessus, nmap, xprobe, queso, . . .
Découverte de services ouverts.
nmap, udp-scan, nessus, . . .
Découverte des versions logicielles.
telnet, netcat, . . .

6
Exemple : Découverte de machines via DNS

Interrogation du DNS avec dig :

• serveur de mail (champ MX), serveur DNS (champ NS)
• résolution inverse sur toutes les adresses (dig -x) (peu discret)
• transfert de zone (dig server axfr zone.) (pas toujours autorisé)
>dig [Link]. MX
; < < > > DiG 9.4.1-P1 < < > > [Link]. MX
;; global options: printcmd
;; Got answer:
;; -»HEADER < <- opcode: QUERY, status: NOERROR,
id: 22464
...
;; QUESTION SECTION:
;[Link]. IN MX

;; ANSWER SECTION:
[Link]. 28800 IN MX 10 [Link].
...

7
Balayage

Découverte de machines :
But. • découvrir les machines d’un réseau donné.
Principe. • envoyer un paquet à toutes les adresses.
• analyser le paquet retour
Outils. • nmap
• ...
Découverte de ports ouverts :
But. • découvrir les services/ports ouverts sur une machine
donnée.
Principe. • envoyer des paquests.
• analyser les paquet retour (ou leur absence)
Outils. • nmap
• telnet
• netcat
• ...

8
Détection de ports ouverts

ping sweep (balayage avec ping) : nmap -sP -PI ...

Principe. Envoyer un paquet ICMP Echo Request et attendre le
paquet ICMP Echo Reply.
Inconvénient. Méthode très peu discrète.
Techniques plus sophistiquées : nécessitent généralement des
privilèges administrateur sur la machine source
• Half Open SYN scan un seul paquet SYN
• NULL scan paquet sans flags (réponse uniquement si le port
correspondant est fermé)
• FIN scan un seul paquet avec le flag FIN (réponse uniquement si le
port correspondant est fermé)
• XMAS scan URG + PUSH + FIN (réponse uniquement si le port
correspondant est fermé)
• ...

9
Détection de ports ouverts

scan TCP via HTTP proxy bounce scan Utiliser un proxy HTTP comme
relai pour faire du scan de ports :
• GET [Link] HTTP/1.0 (et
attendre la réponse)
scan TCP via FTP (FTP Bounce attack) Utiliser un proxy FTP (ayant
un disfonctionnement) comme relai pour faire du scan de
ports :
• PORT 10,10,0,2,0,25
• nmap -b ...
scan UDP
• nmap -sU ...
scan RPC
• nmap -sR ...

10
Détection de ports ouverts

idle scan
• technique de balayage de ports TCP.
• hautement furtive.
• utilisation d’un intermédiaire appelé zombie.
• technique basée sur l’utilisation de l’IPID (compteur de
fragementation IP) du zombie.

source [Link]

une version plus avancée et plus récente de ce scan est ONIS.

11
Détermination du filtrage IP

Méthode :
• Forger un paquet avec un ttl tel que le paquet est arrêté par un filtre
IP.
• Essayer de communiquer avec hôte situé derrière le firewall.
• Analyser les réponses.
Outils :
• firewalk, . . .
Défense :
• Interdir aux réponses ICMP de sortir du réseau protégé.
• ...

12
Prise de contrôle d’un serveur distant

En plusieurs étapes :
1. Recherche de services ouverts (SMTP, FTP, . . . )
2. Exploitation de vulnérabilités : (CGI, exploit connu, débordement de
buffer, injection de code/commande, . . . )
3. Pose de sniffer
4. Pose de backdoor
Exemples de backdoor :
rwwwshell. Lancer un client HTTP avec un shell associé sur une
machine à l’intérieur du réseau et ouvrir une connexion
HTTP vers un serveur du pirate.
loki. installer un serveur particulier sur une machine du réseau
interne et communiquer avec lui en utilisant le champ
données des paquets ICMP.

13
Attaques sur les réseaux locaux

Écoute du réseau. Capturer le contenu des paquets qui ne nous sont

pas destinés.
• tcpdump
• sniff
• ...
Usurpation d’adresses (IP et MAC). Forger et envoyer des paquets avec
une fausse adresse IP. . .
• dsniff
• ...
Vol de session. Forger des paquets permettant la prise de contrôle
d’une connexion déjà établie.
• juggernaut
• hunt
• ...

14
Usurpation d’adresses (spoofing)

Principe.
• Forger et envoyer des paquets IP avec une fausse
adresse source.
Propriété.
• Impossibilité de trouver la véritable source.
Utilisation.
• Technique souvent utilisée dans le cas d’attaque de
type DoS.
Rappel : Une attaque de type DoS vise l’interruption
d’un service en saturant la cible de requêtes.

15
Vol de session (Connection Hijacking)

Objectif.
• Prendre la main sur une connexion déjà établie.
Principe.
• Attendre l’établissement d’une connexion.
• Désynchroniser la connexion entre le client et le
serveur (en forgeant un paquet avec un numéro de
séquence particulier).
• Profiter de la désynchronisation pour faire faire au
serveur ce qu’on veut.
Difficulté.
• Attaque très compliquée (voire impossible) si on n’a
pas la possibilité de voir le traffic entre le client et le
serveur.

16
Derniers résultats sur TCP
Utilisation de side-channels sur TCP pour deviner : le quadruplet
identifiant la connexion, les numéros de séquence et d’acquittement,
voire voler la connexion.
Attaque blind traditionnelle (brute force)
• Terminaison de la connexion et injection de données.
• Nécessite un paquet forgé contenant:
◦ 4-tuple <src IP, dst IP, src port, dst port> doit être connu.
◦ numéro de séquence utilisé (hypothèse) SEQ est in-window (du point de
vue du récepteur)

RFC 5961 (Aout 2010)

• déjoue les attaques blind in-window (c.f. ci-dessus).
• modification du schéma de réception pour SYN, RST et les paquets
de données.
L’implémentation linux a introduit une vulnérabilité de type side-channel.
source [Link] files/security16_slides_cao.pdf 17
Threat Model
• Consists of:
• An arbitrary pair of client and server
• A blind off-path attacker(no eavesdropping capability)
• Assumption: the attacker can send spoofed packets with the victim
(client or server)’s IP address

Client Server

Attacker

Threat Model

USENIX Security 2016 Yue Cao 5

SYN Receiving Scheme
• Before RFC 5961: blind RST Attack by sending spoofed SYN packet

[Link]

SEQ #: Before RFC 5961 After RFC 5961

RCV_Window
Out-of-Window ACK back Challenge ACK
[Link]+[Link]
In_Window Reset Connection Challenge ACK
SEQ # Space

Challenge ACK: ask sender to confirm if it indeed restarted

SYN
Sender Receiver

USENIX Security 2016 Yue Cao 8

RST Receiving Scheme
• Before RFC 5961: blind RST Attack by sending spoofed RST packet

[Link]
SEQ #: Before RFC 5961 After RFC 5961
0/4G
RCV_Window
Out-of-Window Drop the Packet Drop the Packet

In-Window Reset Connection Challenge ACK

[Link]+[Link]
Exactly match Reset Connection
SEQ # Space

tell sender to confirm if it indeed terminated

RST Challenge ACK:
the connection
Sender Receiver

USENIX Security 2016 Yue Cao 9

Data Receiving Scheme
• Before RFC 5961: blind Data Injection Attack by injecting spoofed DATA packet

Challenge
Accept
Window ACK #: Before RFC 5961 After RFC 5961
Window
[Link]
[Link]-2G Out-of-Window Drop Drop
[Link]
In-Accpt_Window Process Data Process Data

Challenge Window
Challenge ACK
ACK # Space (Old ACK)

[Link]
SEQ #: In-RCV_Window —> Check ACK #
RCV_Window

[Link]+[Link]

SEQ # Space
USENIX Security 2016 Yue Cao 10
Why Does This Vulnerability Exist?
• RFC 5961: a much stricter check on incoming packets
• Challenge ACK is triggered in a established connection:
• SYN packet with correct 4-tuples <srcIP, dstIP, srcPort, dstPort> (any SEQ #)
• RST packet with 4-tuples, in-window SEQ #
• Data packet with 4-tuples, in-window SEQ #, old ACK #(in challenge window)

SYN-triggered RST-triggered ACK-triggered

challenge ACK challenge ACK challenge ACK
Rate limit of
Side-Channel Side-Channel Side-Channel challenge ACK
(recommended
by RFC 5961)
Port number SEQ number ACK number
Linux followed faithfully
SYN
RST
Data
USENIX Security 2016 Yue Cao 11
Side Channel Vulnerability
• sysctl_tcp_challenge_ack_limit: implemented in Linux 3.6+
• Global limit of all challenge ACK per sec, shared across all connections
• Default value: 100 (reset per second)

Client Server

Any OS at Client! RST

100 CK
ge A
llen
cha
100
Attacker
Side-Channel Vulnerability Example

USENIX Security 2016 Yue Cao 13

Exploit The Vulnerability
• Guess-then-Check method: SYN-triggered
challenge ACK
RST-triggered
challenge ACK
Data-triggered
challenge ACK

• Send spoofed packets with guessed values

• Example: to guess correct client-port number Port number
Inference
SEQ number
Inference
ACK number
Inference

• If it’s a correct guess:

1 challenge ACK

ith
ts w c port
packe sr
SYN guesse d
Guess Phase
Client ofed a Server
Spo IP and
nt’s RST
clie 100 ACK
e
eng
hall
99 c Check Phase

Attacker

USENIX Security 2016 Yue Cao 14

Guess-Then-Check Method
• Send spoofed packets with guessed values
• Example: to guess correct client-port number
• If it’s a wrong guess:

No challenge ACK

ith
ets w port
Y N pack ed src
S s
fed gues
Client Spoo P and a Server
n t ’sI
clie RST
100
e ACK
leng
chal
100

Attacker

USENIX Security 2016 Yue Cao 15

Guess-Then-Check Method
• Challenge: expensive time cost
• N: maximum spoofed probing packets in one second
• Bandwidth dependent

with rt
kets o
Y N pac ed src p
S s
Client o o fed nd gues
Sp IP a Server
nt’s
clie

Attacker

USENIX Security 2016 Yue Cao 16

Guess-Then-Check Method
• Same process works for guessing SEQ SYN-triggered
challenge ACK
RST-triggered
challenge ACK
Data-triggered
challenge ACK

number and ACK number

• Correct guess: Port number
Inference
SEQ number
Inference
ACK number
Inference

• SEQ number RST packet with correct 4-tuples, SEQ # in-window

• ACK number Data packet with 4-tuples, SEQ # in-window, old ACK #

ient’s
th c l
ck ets wi ed SEQ
a s
ST P gues
fed R port and
Spoo c Server
Client SEQ: nown sr ent’s
IP, k OR h Cli K
k et s wit ssed AC
ac e
d R ST p Q and gu
fe SE
Spoo ort,
ACK: wn src p
, kn o
IP
Attacker

USENIX Security 2016 Yue Cao 17

Guess-Then-Check Method
• Guess is correct when:
• Src Port SYN packet with correct 4-tuples(src Port)
• SEQ number RST packet with correct 4-tuples, SEQ # in-window
• ACK number Data packet with correct 4-tuples, SEQ # in-window, old ACK

• Traditional brute-force attack: 104•109•109=1022 different combinations

• Our attack: Time cost is additive instead of multiplicative
Possible to finish within 1 minute!

Dst IP, Src IP Src Port SEQ number ACK number

Dst Port 104 109 109

USENIX Security 2016 Yue Cao 18

QUELQUES CAS CONCRETS DE MITM
MitM sur internet?

MiTM?
• Détournement du trafic vers l’attaquant qui est en mesure d’analyser,
modifier ou corrompre ce dernier.
• vise en général des protocoles liés à l’infrastructure d’internet.
• Dans notre contexte:
◦ Détournement du protocole BGP.
◦ Exploitation d’une ambiguité dans les RFCs du protocole OSPF.
◦ Attaque sur l’infrastructure DNS.
• DNS cache-poisonning traditionnel (2008)
• Exploitation de la fragmentation IP (2018-)

19
Protocoles de routage dynamique

Routage dynamique
• Internet est organisé en systèmes autonomes (AS) reliées entre elles.
• Deux classes de protocoles de routage dynamique
◦ protocoles intra-AS: OSPF, RIP, ...
◦ protocoles inter-AS: BGP
• Présentation d’exploitation de failles majeures sur BGP1 et OSPF2 .

source [Link]
1 [Link] dc- 09/Zmijewski/BlackHat- DC- 09- Zmijewski- Defend- BGP- [Link]
2 [Link] 13- Nakibly- Owning- the- Routing- Table- Part- II- [Link]

20
Plan

Les attaques?

Quelques cas concrets de MiTM

BGP
OSPF
DNS : Failles & dangers

Déni de service distrbué (DDoS)

Comment se défendre?
Mécanismes de detection d’intrusions
honeypot
SIEM

21
 Part 1: BGP Routing Basics

• Basics of routing and the inherent threats

• Prefixes
• ASNs
• Routing updates
• Route attributes
• Vulnerabilities
• Typical historical attacks

February 2009 Black Hat Briefings 4

 Internet Routing – Prefixes

• Internet routing is orchestrated via blocks of IP addresses

• A network prefix is a block of contiguous IP addresses:

• [Link]/24 contains 256 addresses, namely,
[Link], …, [Link]
• [Link]/20 contains 4096 addresses, namely,
[Link], …, [Link]
• [Link]/24 is more specific than [Link]/20

• IP addresses in the same prefix are routed in the same way.

February 2009 Black Hat Briefings 5

 Internet Routing – most specific route wins

February 2009 Black Hat Briefings 6

 Internet Routing – ASNs

Global Internet routing relies on the Border Gateway Protocol.

Each organization participating in BGP is assigned:
• A unique Autonomous System Number or ASN (integer)
• One or more prefixes (range of IP addresses)

February 2009 Black Hat Briefings 7

 Routers talk to neighboring routers via BGP
(Border Gateway Protocol) - That’s how global routing is established

February 2009 Black Hat Briefings 8

 All routing decisions are local

February 2009 Black Hat Briefings 9

 BGP Update Messages

• An UPDATE message announces a new route or

withdraws a previously announced route.
UPDATE = prefix + route attributes
• Adjacent routers chatter constantly with each other as
routes come and go. Globally, Renesys observes
45,000+ updates per minute when things are quiet!

February 2009 Black Hat Briefings 10

 BGP Attributes

• Routing announcements have attributes …

many possibilities but the (hopefully valid) AS path
to the announced prefix is always present.

February 2009 Black Hat Briefings 11

 Key to routing vulnerabilities

• No single authoritative source of who

should be doing what.
• If there were, you could filter out the errors / hijacks.
• As a result, filtering by ISPs is not common or easy.

• All of Internet routing is based on trust.

• Anyone can announce any IP space they want.
• Anyone can prepend any ASN to any path that they want.

• No mechanism in place to handle ASNs who

go rogue. There are no Internet police!

February 2009 Black Hat Briefings 12

 Hijacking Used Space – YouTube: Feb ’08

• YouTube owns [Link]/22

• This contains the more-specific [Link]/24
• The above /24 used to contain all of YouTube’s
• DNS Servers (have since moved)
• Web Servers (have since added additional IP space)
• YouTube announced only the /22

February 2009 Black Hat Briefings 15

 Hijacking Used Space – YouTube: Feb ’08

• Pakistan Telecom announces the /24

• In BGP, most specific route to an IP address wins!
• Pakistan Telecom gets all traffic intended for YouTube
• YouTube is globally unreachable for 2 hours

February 2009 Black Hat Briefings 16

 New type of hijacking: BGP MITM
- BGP Man-In-The-Middle (think “wiretapping”)

• Presented at DEFCON 16, August 10, 2008

• “Stealing the Internet” – Alex Pilosov and Tony Kapela

• Basic Idea
• Hijack someone’s traffic, but then ultimately
send it on to them
• Allows an attacker to alter, log, misdirect or simply observe
somebody else’s incoming Internet traffic.
• The attacker “blinds” some of the Internet to the hijack,
in order to construct a viable path to the victim
• Abuse AS path loop detection to blind some ASes

February 2009 Black Hat Briefings 19

 AS Path Attribute
Paths grow as announcements propagate

February 2009 Black Hat Briefings 20

 BGP Loop Prevention via AS Path attribute

February 2009 Black Hat Briefings 21

 ASN 200 announces
[Link]/22 to its
providers AS20 and AS30

Source: Alex Pilosov and Tony Kapela

February 2009 Black Hat Briefings 22
 Announcement propagates
to the global Internet

Source: Alex Pilosov and Tony Kapela

February 2009 Black Hat Briefings 23
 Every AS picks its “best”
route to [Link]/22

Source: Alex Pilosov and Tony Kapela

February 2009 Black Hat Briefings 24
 BGP MITM – Plan reply path
Hijacker prepares to attack

Source: Alex Pilosov and Tony Kapela

February 2009 Black Hat Briefings 25
 BGP MITM – Plan reply path
ASN 100 wants to preserve its valid
route to [Link]/22 via AS10

Source: Alex Pilosov and Tony Kapela

February 2009 Black Hat Briefings 26
 BGP MITM – Plan reply path
To preserve this path, ASN 100 must
prepend AS 10, 20, and 200 to the ASPATH
of any hijack announcement

Source: Alex Pilosov and Tony Kapela

February 2009 Black Hat Briefings 27
AS 100 announces the more-specific prefixes
[Link]/23 and [Link]/23, prepending
AS 10, 20 and 200 to the ASPATH.

Source: Alex Pilosov and Tony Kapela

February 2009 Black Hat Briefings 28
 Most global traffic for [Link]/22 now
goes to ASN 100, who forwards it onto AS 10
after examining, copying or altering it.

Source: Alex Pilosov and Tony Kapela

February 2009 Black Hat Briefings 29
 How can the victim observe this?

• Victim’s routes and those of at least

one provider will look normal
• Traceroute from a public looking glass to
the victim’s IPs will show the hijacker
(assuming the looking glass hasn’t been blinded to the attack).

• Traceroute depends on incrementally increasing TTLs

(TTL: Time to Live – number of transmissions a packet can experience before being discarded.)

• Hijacker can hide his presence by silently increasing

TTLs for packets intended for the victim
• Hides hijacker’s routers
• Hides hijacker’s outbound routes to victim

February 2009 Black Hat Briefings 30

Plan

Les attaques?

Quelques cas concrets de MiTM

BGP
OSPF
DNS : Failles & dangers

Déni de service distrbué (DDoS)

Comment se défendre?
Mécanismes de detection d’intrusions
honeypot
SIEM

22
 Background
• This work is a second installment of our
research on OSPF security.
– The first part was presented at Black Hat USA 2011.
• In this part we push the envelope further and
present a more powerful attack that allows to
take control of a Cisco’s router routing table.
 Overview
• The holy grail of routing attacks is owning
the routing table of a router
– without having to own the router itself.
• We present a newly found vulnerability of
the OSPF protocol.
• It allows to own the routing tables of all
routers in a routing domain from just a
single compromised router.
 Why is this so desirable?
• Owning the routing tables allows doing
tricks such as:
– Black holes
– Network cuts
– Traffic diversion
• towards longer routes
• or through an attacker-controlled router
– And much much more
 OSPF Primer
• Every router periodically advertises it’s link state
(i.e. “who are my neighbors?”).
– This is called Link State Advertisement (LSA).
• The LSAs are flooded throughout the network
hop-by-hop.
• Every router receives the LSAs of all other
routers
– and installs it in its LSA DB
– this allows to build the topology map of the AS.
 LSA flooding
R1 LSA
R1
R2 R2 LSA

LSA DB:
R1 R2
 OSPF Primer (cont.)
• There are several types of LSAs. The
most important one is:
– Router LSA – contains the links of a given
router.
• Throughout the presentation we shall refer
only to Router LSAs unless we specifically
indicate otherwise.
 The Attacker
• Location: inside the AS
– Controls a single legitimate router in an
arbitrary location
– This means it can flood LSAs to its neighbors
• Goal: Full control of the routing tables of
all other routers in the AS.
 OSPF Security Strengths
• Every LSA is flooded throughout the AS
• The “fight back” mechanism
• One LSA holds only a little piece of
topology information
 Known Attacks
• Falsifying self LSAs
– Falsify only a small portion of the AS topology, hence
full control over the routing table can not be achieved.
• Falsifying other routers’ LSAs
– Triggers immediate fight back
• non-persistent
• Falsifying phantom router LSAs
– Does not have an affect on the routing table
– since no real router advertises a link back to the
phantom.
Owning the Routing Table – Part I
• Until 2011 the common knowledge was that an
inside attacker cannot gain full and persistent
control over the routing table of a router it does
NOT control.
• At Black Hat USA 2011 we presented the first
general technique to evade fight-back.
– Thereby, persistently falsifying LSAs of other routers.
– This was called the “Disguised LSA” attack.
• See [Link]
[Link]#Nakibly
 The New Attack
• We now present an even more powerful attack.
– It too allows to persistently falsify LSAs while evading
fight-back
• On top of that, it offers some added bonuses:
– The routing table of the victim router is erased
• Can be used as a means to easily DoS a router
– Only a single well-crafted attack packet is
required
 Background
• The LSA header:

• An LSA is uniquely identified by:

– LS type (for Router LSA it is always ‘1’)
– Advertising Router
– Link State ID
 Background (cont.)
• Advertising Router
– identifies the router that originated the LSA.
• i.e., the router ID
• Link State ID
– identifies the part of the AS that is being described by
the LSA.
• i.e., the router ID
The two fields must have the same value.
– But, the OSPF spec does not specify a check to verify
this on LSA reception!
 The Vulnerability
• According to the OSPF spec (Sec. 13.4)
– A router fights back only if it receives a false LSA in
which
• “the Advertising Router is equal to the
router's own Router ID”
• If the victim router receives a false LSA having:
– Link State ID = victim router’s ID
– Advertising Router ≠ victim router’s ID
• Then, no fight back is triggered by the victim!
– This is despite the fact that the LSA claims to
describe links of the victim router itself.
 Illustration

- False LSA
The false LSA is
sent by the attacker.

victim
No Fight back is
triggered! Flooding
proceeds as usual.

All routers install the false LSA in their LSA DBs!

The OSPF spec guarantees it.
 But wait, it’s not that simple…
• There should be a problem:
– Remember Sec. 12.1? An LSA is identified by both:
• Advertising Router, and
• Link State ID
– Hence, the false LSA has a different identifier than
that of the valid LSA (different Advertising Router fields).
• This means that the two LSAs are different from the OSPF
point of view.
– This potentially makes the attack futile
• The false LSA is installed in the LSA DB, but may simply be
ignored by all routers while they keep using the valid LSA
 Ambiguity
• On the other hand, according to the OSPF spec
(Sec. 16.1)
– During the routing table calculation LSAs are looked
up in the LSA DB
• “This is a lookup … based on the Vertex ID“
only!
– Vertex ID = Link State ID

• This is an ambiguity in the spec

– According to Sec. 12.1 an LSA is identified by the tuple
(Link State ID, Adv. Router).
– On the other hand, according to Sec. 16.1 an LSA is
looked up by the Link State ID only.
 Ambiguity (cont.)
• All the routers in the AS (including the victim!)
have in their LSA DBs two LSAs with the same
Link State ID.
– the false LSA, and
– the valid LSA.
• Which LSA will be considered during the routing
table calculation?
– The OSPF spec does not provide an answer…
– Hence, this is implementation dependent
 Cisco
• Holds about 75% of the global enterprise
router market.
 Attack Application Example #1
• Black hole
– The false LSA announces that the victim router is directly
connected to some external destination (e.g. the IP range of
[Link])
– All AS traffic to that destination will be directed to the victim
router which will simply drop the packets.

victim
[Link]
Attack Applications Example #2
• Traffic diversion
– The false LSA announce no links for the the victim router
– All traffic will circumvent the victim.
• Taking alternative routes, if such routes exist.
• If not, the AS is partitioned.
• Green and red paths are before and after the attack, respectively.

victim
Plan

Les attaques?

Quelques cas concrets de MiTM

BGP
OSPF
DNS : Failles & dangers

Déni de service distrbué (DDoS)

Comment se défendre?
Mécanismes de detection d’intrusions
honeypot
SIEM

23
Pourquoi DNS? (1/2)

DNS :
• Proposé en 1983, très peu d’évolution depuis.
• Mécanisme rapide, précis pour trouver la correspondance entre noms
et adresse IP.
• Équivalent des services de renseignement téléphonique pour
internet.
◦ Service plus critique/sensible que les renseignements téléphoniques.
◦ Une personne peut garder son numéro de téléphone pendant des années
alors qu’un serveur peut changer d’adresse IP tous les jours.
◦ Internet n’a pas de mécanisme d’envoi d’un echec ou une redirection
(l’equivalent de “le numéro que vous demandez n’est pas attribué, le
nouveau numéro est ... ”).

24
Pourquoi DNS? (1/2)

Est-il possible que DNS fasse plus que renvoyer l’adresse IP à partir du
nom?
Réponse Simple : Biensur, il peut renvoyer la liste des serveurs mail,
des noms à partir d’adresses IP, . . .
Meilleure réponse : Pourquoi cette question?
• DNS est le deuxième plus ancien protocole “incontesté” dans ce qu’il
fait.
◦ Telnet a évolué vers ssh, FTP a été délaissé pour HTTP, . . .
◦ Il ne reste que SMTP dans le même cas.
• Il est universellement utilisé et largement déployé.

25
Mécanismes pouvant poser problème

Proxy DNS. Si un serveur ne sait pas répondre à une requête, il va

demander à quelqu’un qui sait (correspond à une
recherche récursive).
Cache DNS. Si un serveur sert de proxy pour un autre, les résultats
sont stockés (mis en cache) pour un certain temps (au
plus une semaine pour la majorité des implémentation).
Route DNS. Si un serveur ne sait pas répondre à une requête et qu’il
ne veut pas demander à quelqu’un qui connait la réponse,
il peut donner une indication sur le serveur à contacter
(correspond à une recherche itérative).

26
DNS Cache Poisoning: forger les réponses (1/2)

Cache Poisoning : Attaque consistant à faire en sorte que le cache DNS

contienne des correspondances invalides (c’est à dire que l’adresse IP
n’est pas celle de la machine demandée mais une autre).
• Théoriquement possible mais attaque dure à mettre en œuvre (dure
jusqu’à cet été).
• À l’été 2008, Dan Kaminsky, un chercheur en sécurité, a mis au point
une attaque simple pour empoisoner les caches DNS.
• L’attaque se base sur un défaut de presque tous les serveurs DNS (à
savoir le port source de la communication est toujours le même).

27
DNS Cache Poisoning : forger les réponses (2/2)

Propriétés :
• Chaque requête DNS est identifiée par un identifiant unique codé sur
16 bits (216 possibilités).
• Le port source est toujours le même sur presque toutes les
implémentations de serveur DNS.
description :
1. Récupérer la liste des serveurs ayant l’authorité sur la zone visée.
2. Émettre une requête DNS pour une correspondance qui n’est pas
dans le cache.
3. Envoyer plein de réponses “ spoofées” (au plus 65536), chacune
avec un numéro de requête différent, au serveur en se faisant passé
pour le serveur d’authorité et en mettant dans la réponse une
correspondance erronée.
4. Si l’opération réussit, le cache contient une entrée invalide.

28
Dangers et Solutions

Dangers :
• Peut tout simplement casser la hiéarchie DNS et donc faire tomber
Internet.
• Le cache poisoning peut permettre de rediriger le traffic entre un
serveur et un client vers un tier qui peut être malveillant.
• Beaucoup de protocoles, et notamment des protocoles de sécurité,
sont sensibles aux résolutions DNS.
Solutions retenues :
• Améliorer la randomisation pour le choix du numéro de requête.
• Utiliser un port source aléatoire (ce qui ferait la taille de l’espace de
recherche pour forger une réponse “valide” de 216 à 232 ).
• À plus long terme, il faudrait utiliser un protocole à signature
électronique tel que DNSSec.

29
DNS Cache Poisoning : fragmentation (1/2)
• Exploitation du fait que le second fragment d’une réponse DNS
fragmentée ne contient pas d’entêtes DNS ou UDP.
◦ Contourner les défenses introduites contre l’attaque précédente.
• Point clé: comment forcer la fragmentation?
◦ Réduire le Path Maximum Transmission Unit (PMTU) entre le serveur
victime et le serveur d’authorité.
◦ Envoyer des requêtes DNSSEC pour augmenter la taille de la réponse et
engendrer la fragmentation.
• plusieurs variantes qui fonctionnent même avec DNSSEC.

source [Link]
30
DNS Cache Poisoning : fragmentation (2/2)

Contremesures
• Revérifier la correspondance stockée dans le cache lorsque celle ci a
été obtenue avec fragmentation (ou forcer une requête DNSSEC).
◦ augmentation du coût de la résolution
• Uitilisation d’un encodage avancé (0x20) pour les enregistrement
DNS. Ceci permet d’augmenter l’aléa dans la réponse.
• Utilisation d’algorithmes aléatoires pour la gestion des IPID.
◦ Nécessite une modification des systèmes d’exploitation.
◦ Ne résiste pas à une attaque de type brute-force sur la valeur de l’IPID.

31
DÉNI DE SERVICE DISTRBUÉ (D D O S)
DDoS&botnet3

DDoS
• Attaque nécessitant un nombre
important de participants (Bots).
• Construction d’un Botnet en
utilisant le schéma suivant.
• Botnet visant les objets
connectés ont un fort potentiel
de nuisance.

3 source N. Vlajic and D. Zhou, "IoT as a Land of Opportunity for DDoS Hackers," in Computer, vol. 51, no. 7, pp. 26-34, July 2018

33
Stratégies pour assurer la furtivité des Bots (1/2)

Direct DDos attack.

source N. Vlajic and D. Zhou, "IoT as a Land of Opportunity for DDoS Hackers," in Computer, vol. 51, no. 7, pp. 26-34, July 2018

34
Stratégies pour assurer la furtivité des Bots (2/2)

Reflection DDos attack.

source N. Vlajic and D. Zhou, "IoT as a Land of Opportunity for DDoS Hackers," in Computer, vol. 51, no. 7, pp. 26-34, July 2018

35
Botnet et IoT

Botnets
• Plusieurs générations de Botnets visant les IoT
◦ Grand nombre des IoT.
◦ Faible niveau de sécurité.
◦ Existance de moteurs de recherche d’objets connectés à internet
([Link], [Link],. . . ).
• Possibilité de faire des recherches très ciblées (un modèle de caméra par
exemple).
• Suppression de la phase 1 du schéma de fonctionnement de l’attaque
(découverte).
• souvant une architecture avec centre de commande (C&C) controlé
par le botmaster qui contrôle le botnet.
• Mirai 4 est le plus célébre des botnets visant les IoT (IPv4).
◦ mode d’infection simple (attaque par dictionnaire, brute force,. . . ), C&C
centralisé.
◦ Plusieurs succésseurs: Iotroop/Reaper (utilisation d’exploit pour infecter
les Bots), Hajime (C&C distribué à la P2P).
4 source [Link] sessions/presentation/antonakakis
36
 Growing IoT Threat

2016 2020
6 - 9 Billion ~30 Billion

3 Understanding the Mirai Botnet ▪︎ Zane Ma

 Research Goals
Snapshot the IoT botnet phenomenon

Reconcile a broad spectrum of botnet data perspectives

Understand Mirai’s mechanisms and motives

4 Understanding the Mirai Botnet ▪︎ Zane Ma

 Lifecycle
Attacker
Send command

Command Report Loader

Dispatch
Infrastructure & Control Server

  Relay Load

Report

Devices Scan Victim

Bots

 Attack

DDoS Target

5 Understanding the Mirai Botnet ▪︎ Zane Ma

 Measurement
Attacker Data Source Size
Send command
Network Telescope 4.7M unused IPs

Command Report Active Scanning 136 IPv4 scans

Dispatch Loader
Infrastructure & Control Server
Telnet Honeypots 434 binaries
  Relay Load

Report
Malware Repository 594 binaries
Active/Passive DNS 499M daily RRs
Devices Scan Victim C2 Milkers 64K issued attacks
Bots
Krebs DDoS Attack 170K attacker IPs
 Attack
Dyn DDoS Attack 108K attacker IPS

DDoS Target
July 2016 - February 2017

6 Understanding the Mirai Botnet ▪︎ Zane Ma

 What is the Mirai botnet?

7 Understanding the Mirai Botnet ▪︎ Zane Ma

 Population
700,000
Total Mirai Scans
# network telescope scans

600,000

500,000

400,000

300,000

200,000

100,000

0
08/01/16 09/01/16 10/01/16 11/01/16 12/01/16 01/01/17 02/01/17
Date

8 Understanding the Mirai Botnet ▪︎ Zane Ma

 Rapid Emergence
140,000

120,000

# network telescope scans

700,000
1:42 AM Single Scanner Total Mirai Scans
# network telescope scans

600,000 100,000
500,000 80,000 23:59 PM 64,500 scanners
400,000
60,000
300,000
40,000 3:59 AM Botnet Expands
200,000
Mirai TCP/23 scans
100,000 Non-Mirai TCP/23 scans
0
0
08

08

08

08

08

08

08

08

08

08

08

08
08/01/16 09/01/16 10/01/16 11/01/16 12/01/16 01/01/17 02/01/17
-0

/0

/0

/0

/0

/0

/0

/0

/0

/0

/0

/0
1

3
1

Date
06

12

18

00

06

12

18

00

06

12

18
00

:0

:0

:0

:0

:0

:0

:0

:0

:0

:0

:0
:0

0
0

Date

9 Understanding the Mirai Botnet ▪︎ Zane Ma

 Many Ports of Entry
700,000
Total Mirai Scans
# network telescope scans

600,000 TCP/23
TCP/2323
500,000

400,000
“IoT Telnet” TCP/2323
300,000

200,000

100,000

0
08/01/16 09/01/16 10/01/16 11/01/16 12/01/16 01/01/17 02/01/17
Date

10 Understanding the Mirai Botnet ▪︎ Zane Ma

 Many Ports of Entry
700,000
CWMP TCP/7547
600K peak Total Mirai Scans
# network telescope scans

600,000 TCP/7547
500,000

400,000

300,000

200,000

100,000

0
08/01/16 09/01/16 10/01/16 11/01/16 12/01/16 01/01/17 02/01/17
Date

11 Understanding the Mirai Botnet ▪︎ Zane Ma

 Many Ports of Entry
700,000
CWMP TCP/7547
~1 month = 6.7K Total Mirai Scans
# network telescope scans

600,000 TCP/7547
500,000

400,000

300,000

200,000

100,000

0
08/01/16 09/01/16 10/01/16 11/01/16 12/01/16 01/01/17 02/01/17
Date

12 Understanding the Mirai Botnet ▪︎ Zane Ma

 Many Ports of Entry
700,000
Total Mirai Scans TCP/443
# network telescope scans

600,000 TCP/23231 TCP/5555

TCP/22 TCP/6789
500,000 TCP/2222 TCP/8080
TCP/37777 TCP/80
400,000

300,000

200,000

100,000

0
08/01/16 09/01/16 10/01/16 11/01/16 12/01/16 01/01/17 02/01/17
Date
9 Additional Protocols

13 Understanding the Mirai Botnet ▪︎ Zane Ma

 200K-300K Mirai Bots
700,000
Total Mirai Scans TCP/6789
# network telescope scans

600,000 TCP/23231 TCP/8080

TCP/22 TCP/80
500,000 TCP/2222 TCP/23
TCP/37777 TCP/2323
400,000 TCP/443 TCP/7547
TCP/5555
300,000
Steady state
200,000

100,000

0
08/01/16 09/01/16 10/01/16 11/01/16 12/01/16 01/01/17 02/01/17
Date

14 Understanding the Mirai Botnet ▪︎ Zane Ma

 Cameras, DVRs, Routers
Targeted Devices Infected Devices
Source Code Password List HTTPS banners
# Targeted Device Type # HTTPS banners
Device Type Examples
Passwords
Camera / DVR 26 (57%) dreambox, 666666 Camera / DVR 36.8%

Router 6.3%
Router 4 (9%) smcadmin, zte521
NAS 0.2%
Printer 2 (4%) 00000000, 1111
Firewall 0.1%
VOIP Phone 1 (2%) 54321
Other 0.2%
Unknown 13 (28%) password, default Unknown 56.4%

17 Understanding the Mirai Botnet ▪︎ Zane Ma

C O M M E N T S E D É F E N D R E?
Mécanismes de protection

Détecteur d’intrusion
Outils permettant de détecter une attaque, d’émettre une alarme voire
d’agir à chaud.

Honeypot
Outils permettant d’attirer l’attaquant vers un système particulier pour
éviter que le réseau valide soit attaqué et pour étudier le comportement
de l’attaquant.

SIEM
Outils permettant de faire de la corrélation entre différents evénements
de sécurité.

38
Plan

Les attaques?

Quelques cas concrets de MiTM

BGP
OSPF
DNS : Failles & dangers

Déni de service distrbué (DDoS)

Comment se défendre?
Mécanismes de detection d’intrusions
honeypot
SIEM

39
IDS/IPS(1/2)

Intrusion Detection System

• Surveiller
• Contrôler
• Détecter
Capturer les paquets, les analyser et emettre des alertes en cas de
problèmes.

Intrusion Prevention System

• Surveiller
• Contrôler
• Détecter
• Agîr
Écouter activement les paquets (inline), les analyser et mettre fin aux
communications suspectes. Possibilité d’émettre des alarmes.
40
Exemple de fonctionnement d’un IDS
Étape 1. une attaque est lancée sur un réseau qui a une sonde IDS.
Étape 2. le switch envoie des copies de tous les paquets à la sonde IDS
pour analyse.
Étape 3. la sonde IDS détecte le trafic malicieux à l’aide d’une signature.
Étape 4. la sonde IDS intéragit avec le switch pour lui demander de
mettre fin au traffic malicieux.
Étape 5. l’IDS envoie une alarme au gestionnaire.

source [Link]
41
Exemple de fonctionnement d’un IPS
Étape 1. une attaque est lancée sur un réseau qui a une sonde IPS.
Étape 2. la sonde IPS analyse les paquets dès qu’ils arrivent sur
l’interface de la sonde.
Étape 3. en utilisant des signatures, la sonde IPS détecte le trafic
malicieux et met un terme à l’attaque. La sonde IPS peut
détruire un trafic qu’elle considère malicieux.
Étape 4. la sonde IPS peut envoyer une alarme au gestionnaire.

source [Link]
42
Types des méthodes de détection des IDS/IPS

3 méthodes
par signature. La sonde recherche des motifs prédéfinis (signatures) dans le trafic réseau. Une alarme
est émise lorsqu’une correspondance est trouvée.
par politique. La sonde est préconfigurée en se basant sur la politique de sécurité du réseau. Tout ce
qui ne correspond pas à la politique est considéré comme suspect.
par anomalie. La sonde recherche du trafic anormal.

Avantages Limitations
par signature Facile à configurer Pas de détection d’attaques
inconnues
peu de faux positifs initiallement beaucoup de faux
positifs
beaucoup de signatures disponibles signatures doivent être créées et
mises à jour
par politique simple et fiable
politiques configurables les politiques doivent être créées
peut détecter des attaques
inconnues
par anomalie facilité de configuration difficulté de caractériser un
trafic normal dans un réseau
peut détecter des attaques le profil du trafic normal doit
inconnues être constant

43
Types d’IDS/IPS
Il existe deux types d’IDS/IPS :
• HIDS (Host IDS)
• NIDS (Network IDS)

Host IDS
• Basé dans un ordinateur hôte
• HIDS permet de surveiller le système et les applications
◦ Les journaux systèmes,
◦ de contrôler l’accès aux appels systèmes,
◦ de vérifier l’intégrité des systèmes de fichiers
• Le HIDS à accès à des composants non-accessibles sur le réseau
• Ne surveille qu’un seul hôte

44
Types d’IDS/IPS
Il existe deux types d’IDS/IPS :
• HIDS (Host IDS)
• NIDS (Network IDS)

Network IDS: Une sonde placée dans le réseau

• Surveille l’ensemble du réseau
• Capture et analyse tout le trafic
• Recherche de paquets suspects
◦ Contenu des données
◦ Adresses IP ou MAC source ou destination
◦ ...
◦ Envoi d’alertes

44
Types d’IDS/IPS
Il existe deux types d’IDS/IPS :
• HIDS (Host IDS)
• NIDS (Network IDS)

Network IDS: Une sonde placée dans le réseau

• Surveille l’ensemble du réseau
• Capture et analyse tout le trafic
• Recherche de paquets suspects
◦ Contenu des données
◦ Adresses IP ou MAC source ou destination
◦ ...
◦ Envoi d’alertes

Les IDS/IPS sont souvent des systèmes hybrides combinant HIDS et

NIDS.

44
Plan

Les attaques?

Quelques cas concrets de MiTM

BGP
OSPF
DNS : Failles & dangers

Déni de service distrbué (DDoS)

Comment se défendre?
Mécanismes de detection d’intrusions
honeypot
SIEM

45
Honeypot (1/2)

honeypot
Une ressource de sécurité dont le principal
• Tout le trafic vers le honeypot est authorisé.
• Tout trafic initié par le honeypot est suspect (souvent dû au fait que le
système a été compromis).
Le but du honeypot est d’être attaqué.

Types
deux types de honeypot du point de vue leur objectif :
Production. Il s’agît des infrastructures classiques. Leur but est
d’augmenter la sécurité du réseau.
Recherche. Il s’agît de mécanisme permettant de récupérer de
l’information sur les pirates et les attaques qu’ils utilisent.

46
Honeypot (1/2)

honeypot
Une ressource de sécurité dont le principal
• Tout le trafic vers le honeypot est authorisé.
• Tout trafic initié par le honeypot est suspect (souvent dû au fait que le
système a été compromis).
Le but du honeypot est d’être attaqué.

Classification
interaction haute faible
machine physique ou virtuelle logiciel simulant le comportement
d’une machine/service
implementation virtuelle physique
simulation du comportement machine réelle

46
Honeypot (2/2)

Avantages
• Les informations récupérées à partir de honeypots ont de la valeur
(personne d’autre qu’un pirate n’est censé s’y connecter).
• Pas de problèmes de saturation de la ressource vu que la trafic dirigé
vers le honeypot est très ciblé. (par opposition à conntrac par ex).
• Permettent de mettre en évidence de l’activité suspecte etc ...

Inconvénients
• Vision étroite (on ne voit que ce qui est destiné au honeypot).
• Les honeypots laissent souvent une empreinte qui fait qu’on peut les
reconnaître.
• On laissant une machine sans défense, le honeypot pause un
problème en cas de compromission.

47
Plan

Les attaques?

Quelques cas concrets de MiTM

BGP
OSPF
DNS : Failles & dangers

Déni de service distrbué (DDoS)

Comment se défendre?
Mécanismes de detection d’intrusions
honeypot
SIEM

48
Security Information and Event Management (SIEM)

SIEM
Le SIEM désigne:
• les capacités de collecte, d’analyse, de corrélation et de présentation
de l’information provenant du réseau et des dispositifs de sécurité
• les applications de gestion des identités et des accès
• les outils de gestion des vulnérabilités et de conformité aux politiques
• le système d’exploitation, la base de données et les journaux
d’application
• les données sur les menaces externes

Principaux objectifs
• Identifier les menaces et les brèches possibles.
• Collecter les journaux d’audit pour la sécurité et la conformité (à la
politique de sécurité)
• Aîder à meener des enquêtes et à fournir des preuves
49
Un exemple

source [Link]

50
Fonctionnement
Contextualisation Présentation
Collecte de données Extraction d'informations Corrélation
intelligentes Traitement Rapports

Contextualisation
• Exemples
◦ ajout d’informations de géo-localisation
◦ ajout d’informations issues du serveur DNS
◦ ajouter des détails sur l’utilsateur
• Ajouter du contexte aide à identifier
◦ accès depuis un endroit inhabituel
◦ transfert de données suspect

Corrélation
La corrélation est la différence entre:
“14:10 7/4/20110 User BRoberts Successful Auth to [Link] from [Link]”

et
“An Account belonging to Marketing connected to an Engineering System from an office desktop, on a day

when nobody should be in the office”

51
Conclusion

Pourquoi le SIEM?
• Augmentation des violations de données dues à des menaces
internes ou externes.
• Les attaquants sont créatifs et les outils de sécurité traditionnels ne
suffisent plus.
• Contrer les cyber-attaques sophistiquées.
• Gérer les volumes croissants de logs provenant de sources diverses.
• Répondre à des exigences de conformité strictes vis à vis des
politiques de sécurité.

D’une manière générale

• Il est souvent nécessaire de combiner plusieurs de ces technologies.
• Une analyse régulière par un spécialiste est nécessaire.
• Un compromis doit être trouvé entre le coût de la solution retenue et
la politique de sécurité voulue. 52