0Document Title
NTP in Amplification Inferno
Sriram Krishnan
1Document Title
To Introduce Myself...
 Sriram Krishnan
 Senior Manager, Security Solutions, Group Information Security - Scope International
Pvt. Ltd. (A wholly owned subsidiary of Standard Chartered Bank)
 Over 9 years of experience in Information Security
2Document Title
Agenda
 Why NTP Amplification?
 Demystifying DDoS
 Time to Deep Dive
 NTP Amplification Attack – Demo
 Challenges & Countermeasures
3Document Title
Why NTP Amplification?
4Document Title
A Background
5Document Title
Why NTP?
 Why NTP is targeted
 Ease of attack:
 Small request may lead to relatively large response
 Evade Detection:
 Spoofing of IP Address due to lack of handshake process– as
it is a UDP based protocol
 Availability:
 Essential service with large clusters of public timeservers
available in internet
 Traffic Volume:
 Potential to generate from 200 to 400Gbps of traffic that will
shutdown a network
Targeted Industries
 Internet Service
Providers,
 Banks and
Financial Services,
 Managed Services
(Including SaaS),
 Critical
Infrastructure of
countries
 e-Commerce
6Document Title
Demystifying DDoS
7Document Title
Understanding DDoS Terminology
 Master / Handler
Compromised system in the interest used by the attacker to launch attacks.
 Slave / Agent:
System that responds to the instructions of Master which are controlled by the attacker. Slave
serves as the amplifiers for DDos attacks.
 Daemon:
Process running the Slave, executing the commands for amplification.
 Reflector
Systems that respond to instructions of Master, without the awareness of participating in DRDoS
attack.
 Victim
Target host or network for the DDoS attack.
8Document Title
DDoS Categorized Based on Attack Method
Conventional DDoS Attack:
 Attacker takes control of master system to send instructions to slaves running the affected
daemon.
 The slaves will execute the command and amplify the traffic to finally send it to victims.
Compromised Systems
Fig 1: Distributed Denial of Service (DDOS) Attack
9Document Title
DDoS Categorized Based on Attack Method
Distributed Reflective Denial of Service Attack
 Attacker takes control of the master system and sends instruction to reflector running the
vulnerable daemon.
 Reflectors executes the command and amplifies the traffic to finally send it to victims.
 Host of both categories (Master and Slave) are compromised in DDoS, but in DRDoS attack the
reflector is not compromised.
Compromised Systems
Fig 2: Distributed Reflective Denial of Service (DRDOS) Attack
10Document Title
DDoS Categorized Based on Impact
 Volume / Bandwidth Based Attacks
 Chokes victim’s network bandwidth
 Measured in bits per second (Bps)
 Example: UDP Flood, ICMP Flood
 Protocol Based Attacks
 Exhaust the system / network device resources and shutdown the service or systems
 Measured as packets per second
 Example: SYN Flood, Ping of Death, Smurf DDoS
 Application Layer Based Attacks
 Shutdown application layer resources / services
 Example: Slowloris, HTTP Flood.
11Document Title
Time to Deep Dive
12Document Title
Vulnerability Details
 NTP allows administrators to monitor service via ntpd daemon – by executing remote commands
 Affected command is monlist
 monlist command operates in mode 7 – private use (which allows remote administration).
 Purpose of this command is to obtain details about NTP Associations (up to 600) from NTP server
 NTP Associations are formed when two peers exchange messages, and this transaction is
maintained in the Most Recently Used (MRU) list.
 NTP Associations details are stored in ntp.conf file. Example, in unix-based OS this file is stored in
</etc/ntp.conf>
 Attacker sends a request (get_monlist ) to public NTP Server (in internet) with spoofed IP of the
victim
 Response to this request generates enormous traffic towards the victim’s network
13Document Title
Monlist Command – Understanding the Details
14Document Title
Examining the Source Code
Let’s examine the source code that defines the structure and executes the monlist command
 ntp_request.c - respond to information requests
 ntp_monitor.c - monitor who is using the ntpd server
ntp_request.c
 mon_getlist_1 function obtains MRU list from the NTP server.
 Arrow indicates structure of mon_data that defines the maximum number of NTP associations.
 The keyword “extern” is used as this variable has already been defined in ntp_monitor.c.
15Document Title
Examining the Source Code (Contd..)
ntp_monitor.c
 First arrow - defines the number of structure to be allocated - 600
 Second arrow - declares and defines the mon_data that updates the statistics of the monitoring data.
16Document Title
NTP Amplification Attack
Spoofed IP Address of Victim
monlist
NTP Associations
MRU List
17Document Title
Demo
18Document Title
Challenges & Countermeasures
19Document Title
Challenges in Defence
 Arresting Help
 DDoS attack floods victim’s network / systems with malicious packets.
 Traffic flow increases rapidly within a quick span of time and without any prior warning or alert.
 This prevents systems to send SoS and are arrested from the attack.
 Filtering of Traffic
 Any attempts made to filter the traffic, hampers service rendered
 All legitimate traffic may be filtered / rejected thus denying service
 Evade Detection
 Generally attackers spoof the IP address of the attack packets.
 Attack triggered from distributed compromised systems
 Heterogeneous Environment:
 Systems with multiple software and diverse architecture are deployed.
20Document Title
Countermeasures
So what is required?
Robust & effective defensive mechanism
How?
Enhancing the protocol design
21Document Title
Countermeasures – NTP Amplification Attacks
 Upgrade the ntpd version to 4.2.7
 If the ntpd version cannot be updated, add the “noquery” directive to the “restrict default”
line in the ntp.conf file.
22Document Title
Countermeasures - DDoS Attacks
 Response Rate Limitation (RRL)
 Limits number of packets issued to a target at a given time interval
 Excess data over the limit is truncated
 Works best when the attack source is limited
 Already implemented in DNS protocol
 Protocol Harding
 Session handling mechanism - requests to be processed only post session initiation
 For example, DTLS (RFC 4347), a UDP-variant of TLS, implements a stateless cookie exchange
mechanism in order to avoid DDoS attacks.
 Response Size Limitation
 Protocol to be designed to:
 Limit the output (packet size) for every request, and
 Demand session initiation before releasing the rest of the output
23Document Title
To Sum Up!
 UDP based network services - easy target for attackers
 Other UDP based services such as SNMP, SSDP, NetBIOS targeted
 Pressing need to harden such protocol design
 Need for investments in preventive defence mechanism pertinent
24Document Title
Thankyou

Ntp in Amplification Inferno

  • 1.
    0Document Title NTP inAmplification Inferno Sriram Krishnan
  • 2.
    1Document Title To IntroduceMyself...  Sriram Krishnan  Senior Manager, Security Solutions, Group Information Security - Scope International Pvt. Ltd. (A wholly owned subsidiary of Standard Chartered Bank)  Over 9 years of experience in Information Security
  • 3.
    2Document Title Agenda  WhyNTP Amplification?  Demystifying DDoS  Time to Deep Dive  NTP Amplification Attack – Demo  Challenges & Countermeasures
  • 4.
  • 5.
  • 6.
    5Document Title Why NTP? Why NTP is targeted  Ease of attack:  Small request may lead to relatively large response  Evade Detection:  Spoofing of IP Address due to lack of handshake process– as it is a UDP based protocol  Availability:  Essential service with large clusters of public timeservers available in internet  Traffic Volume:  Potential to generate from 200 to 400Gbps of traffic that will shutdown a network Targeted Industries  Internet Service Providers,  Banks and Financial Services,  Managed Services (Including SaaS),  Critical Infrastructure of countries  e-Commerce
  • 7.
  • 8.
    7Document Title Understanding DDoSTerminology  Master / Handler Compromised system in the interest used by the attacker to launch attacks.  Slave / Agent: System that responds to the instructions of Master which are controlled by the attacker. Slave serves as the amplifiers for DDos attacks.  Daemon: Process running the Slave, executing the commands for amplification.  Reflector Systems that respond to instructions of Master, without the awareness of participating in DRDoS attack.  Victim Target host or network for the DDoS attack.
  • 9.
    8Document Title DDoS CategorizedBased on Attack Method Conventional DDoS Attack:  Attacker takes control of master system to send instructions to slaves running the affected daemon.  The slaves will execute the command and amplify the traffic to finally send it to victims. Compromised Systems Fig 1: Distributed Denial of Service (DDOS) Attack
  • 10.
    9Document Title DDoS CategorizedBased on Attack Method Distributed Reflective Denial of Service Attack  Attacker takes control of the master system and sends instruction to reflector running the vulnerable daemon.  Reflectors executes the command and amplifies the traffic to finally send it to victims.  Host of both categories (Master and Slave) are compromised in DDoS, but in DRDoS attack the reflector is not compromised. Compromised Systems Fig 2: Distributed Reflective Denial of Service (DRDOS) Attack
  • 11.
    10Document Title DDoS CategorizedBased on Impact  Volume / Bandwidth Based Attacks  Chokes victim’s network bandwidth  Measured in bits per second (Bps)  Example: UDP Flood, ICMP Flood  Protocol Based Attacks  Exhaust the system / network device resources and shutdown the service or systems  Measured as packets per second  Example: SYN Flood, Ping of Death, Smurf DDoS  Application Layer Based Attacks  Shutdown application layer resources / services  Example: Slowloris, HTTP Flood.
  • 12.
  • 13.
    12Document Title Vulnerability Details NTP allows administrators to monitor service via ntpd daemon – by executing remote commands  Affected command is monlist  monlist command operates in mode 7 – private use (which allows remote administration).  Purpose of this command is to obtain details about NTP Associations (up to 600) from NTP server  NTP Associations are formed when two peers exchange messages, and this transaction is maintained in the Most Recently Used (MRU) list.  NTP Associations details are stored in ntp.conf file. Example, in unix-based OS this file is stored in </etc/ntp.conf>  Attacker sends a request (get_monlist ) to public NTP Server (in internet) with spoofed IP of the victim  Response to this request generates enormous traffic towards the victim’s network
  • 14.
    13Document Title Monlist Command– Understanding the Details
  • 15.
    14Document Title Examining theSource Code Let’s examine the source code that defines the structure and executes the monlist command  ntp_request.c - respond to information requests  ntp_monitor.c - monitor who is using the ntpd server ntp_request.c  mon_getlist_1 function obtains MRU list from the NTP server.  Arrow indicates structure of mon_data that defines the maximum number of NTP associations.  The keyword “extern” is used as this variable has already been defined in ntp_monitor.c.
  • 16.
    15Document Title Examining theSource Code (Contd..) ntp_monitor.c  First arrow - defines the number of structure to be allocated - 600  Second arrow - declares and defines the mon_data that updates the statistics of the monitoring data.
  • 17.
    16Document Title NTP AmplificationAttack Spoofed IP Address of Victim monlist NTP Associations MRU List
  • 18.
  • 19.
  • 20.
    19Document Title Challenges inDefence  Arresting Help  DDoS attack floods victim’s network / systems with malicious packets.  Traffic flow increases rapidly within a quick span of time and without any prior warning or alert.  This prevents systems to send SoS and are arrested from the attack.  Filtering of Traffic  Any attempts made to filter the traffic, hampers service rendered  All legitimate traffic may be filtered / rejected thus denying service  Evade Detection  Generally attackers spoof the IP address of the attack packets.  Attack triggered from distributed compromised systems  Heterogeneous Environment:  Systems with multiple software and diverse architecture are deployed.
  • 21.
    20Document Title Countermeasures So whatis required? Robust & effective defensive mechanism How? Enhancing the protocol design
  • 22.
    21Document Title Countermeasures –NTP Amplification Attacks  Upgrade the ntpd version to 4.2.7  If the ntpd version cannot be updated, add the “noquery” directive to the “restrict default” line in the ntp.conf file.
  • 23.
    22Document Title Countermeasures -DDoS Attacks  Response Rate Limitation (RRL)  Limits number of packets issued to a target at a given time interval  Excess data over the limit is truncated  Works best when the attack source is limited  Already implemented in DNS protocol  Protocol Harding  Session handling mechanism - requests to be processed only post session initiation  For example, DTLS (RFC 4347), a UDP-variant of TLS, implements a stateless cookie exchange mechanism in order to avoid DDoS attacks.  Response Size Limitation  Protocol to be designed to:  Limit the output (packet size) for every request, and  Demand session initiation before releasing the rest of the output
  • 24.
    23Document Title To SumUp!  UDP based network services - easy target for attackers  Other UDP based services such as SNMP, SSDP, NetBIOS targeted  Pressing need to harden such protocol design  Need for investments in preventive defence mechanism pertinent
  • 25.