Category: Reading Unit – DoS Research

The final post on attack reviews will delve into physical denial of service attacks via network intrusion. Physical attacks can be carried out by attackers gaining access to location where physical systems are stored but this attack method extends beyond the scope of this reading unit. Physical attacks via a networks generally involve maliciously modifying vulnerable firmware in an attempt to create further vulnerabilities/render hardware temporarily unavailable/ permanently disable (brick) targeted hardware.

This type of attack can be referred to by a few different names:

• Phlashing
• Permanent DoS / PDoS
• Bricking
• Firmware attack

Rich Smith of HP labs outlined this vulnerability in his 2008 presentation of a tool called PhlashDance.

In the presentation Rich looks:

• Achieving PDoS remotely
• Possibility of generic attacks – Which would significantly increase the likelihood of attackers creating tools, allowing almost anyone to exploit a firmware vulnerability.
• Mitigation

Taking an abstract look at firmware development in industry we can see that it is generally behind system software. For example it is not uncommon to patch drivers, in fact Windows does this quite regularly. Updating firmware is much less common. Thus there is a great deal more legacy code and code that was not developed with security in mind. Given these facts the chances of vulnerabilities are high. Smith goes on to highlight the lack of auditing for firmware vulnerabilities and fact that most security policies over look this as a system component. This combines with the emergence of network devices that are connected to networks automatically updating firmware.

Another great point that Smith makes is the very weak access control of many devices firmware when weighed against the power re-flash access provides. The introduction to firmware is closed with definitions of the two major firmware update mechanisms:

• Push – Firmware is sent to the device
• Pull – Firmware update is signaled to the device which then connect to a designated location to collect the new binary

These update mechanisms are the main target for attackers who wish to maliciously modify a devices firmware.

Smith look at the lack of cryptographic data verification as the primary weakness in automatic firmware update packages. He implements a fuzzer to overcome the cyclical redundancy checks implemented by most vendors.

Mitigation

The presentation recommends the following mitigation efforts by developers:

• Remote updates off by default
• Physical presence required to flash firmware
• Crypto signatures required to flash
• Validation in firmware, not client application
• Design with attack tolerance not fault tolerance

The following is also recommended for users:

• Patch firmware
• Lock down devices
• Understand the full capabilities of devices and take their security seriously

For an administrator of a large network implementing intrusion detection rules that can identify malicious firmware updates would also be an ideal solutions. Taking note of the ports that firmware updates will also allow for locking down of devices behind the firewall.

This weeks DoS attack review will focus on wireless vulnerabilities, specifically as a result of replay attacks. The simple definition of which is:

A network attack whereby valid data transmission is maliciously or fraudulently repeated or delayed

A key article used in this post is: Feng Z., Ning, J., Broustis, I., Pelechrinis, K., Krishnamurthy, S. V., Faloutsos, M.,  2008?, Coping with Packet Replay Attacks in Wireless Networks, US Army Research Office

Replay attacks are particularly effective against wireless networks as the capture and injection of packets is much easier to accomplish as opposed to a wired network. Aireplay-ng is a linux tool that enables replay attacks to be conducted on unprotected wireless network very simply. This tool is used in conjunction with packetforge-ng which allows attackers to easily create new or forged packets for injection. Feng et al. cite network degradation via one terminal against an access point of up to 61%. That degradation is a achieved through unintelligent packet spamming. Also mentioned is the straight forward mitigation strategy of using public key encryption to digitally sign packets although this is indeed a slow process for data comms.

Using packet replay, there are a number of attacks that can be launched:

• Simplistic packet replay to increase network congestion.
• De-authentication – This attack sends disassociate packets to one or more clients which are currently associated with a particular access point.

Mitigation strategies:

• One time passwords
• Session tokens
• Random check numbers
• Timestamping
• RADIUS [Remote Authentication Dial In User Service] server
• EAP [Extensible Authentication Protocol]

As per advanced network security lectures this post will focus on analyzing how a RADIUS and EAP prevent replay attacks. The RADIUS protocol documentation lists a Digest-nonce count attribute as does the EAP protocol specification.

Through the handshake process nonce values are used by both the AP and the supplicant to protect against replay attacks:

I need to do further reading as to the process post key handshake. I would imagine that an encrypted counter could be used to prevent effectivness of replay attacks.

This week will look at what to me seems like a less well known form of DoS attack, DNS poisoning. This attack is more dangerous than the others we have looked at before because it can not only prevent users from accessing a services, it can lead them to a fake version of the service and ask for sensitive information. There are many methods for this attack, such as grabbing packet in a MITM attack and altering them. An example of this method which can be executed over wireless networks can be seen in the video below:

 As mentioned in the video, the process of reading packets, checking for a specific field, editing it and re-injecting the packet requires ‘a half-way decent computer’.

The DNS cache poisoning attack, first released by Dan Kaminsky, actually poisons the source of the IP addresses the target computer is looking up. This way no real time injection or modification is required and a whole subnet can be attacked through their DNS server. Bind, the most common

The patch included in BIND 9.4.2 provided defense by randomization of listening port.

However, this is only a partial fix, Liu warned. “Port randomization mitigates the problem but it doesn’t make an attack impossible,” he said. “It is really just a stopgap on the way to cryptographic checking, which is what the DNSSEC security extensions do.

An example of DNS server cache poisoning effective prior to the port randomization patch can be seen below:

 So why did this vulnerability come about?

As with many aspects of the internet, convenience rather than security was the priority. The internet could function with just the root name servers that store IP addresses entered by an administrator. Every time a user wanted to view a site or service associated with that domain name they could ask the root nameserver to send the relevant address. This would however mean a great deal more DNS traffic clogging up networks and causing bottle necks at the authoritative name servers. So, we create name servers that are below the authoritative name servers, they store the IP addresses from the first time they are asked to check them, until the expiry (TTL) value of the records they retrieved. Kaminsky’s exploit waited for a target DNS server to re-check the IP addresses for a domain name, sending a falsified response to the name server.

Kaminsky’s blog post on the vulnerability can be found here: http://dankaminsky.com/2008/07/09/an-astonishing-collaboration/

Distributed Denial of Service attacks are becoming and increasingly common phenomenon with both Gov’t agencies, activists, individuals and business entities using the attack as a tool to further their goals. Evidence of this can be seen in the list below:

• List of significant DDoS attacks compiled by the Berkman Center for Internet and Society.

Along with the increasing occurrence of DDoS attacks, the power of such attacks is also increasing. Studies conducted in 2002 and again in 2009 showed an increase in the average size of large attacks from 400 Mbps to 49 Gbps. One might argue that this increase would be matched by target networks ability to handle bandwidth, however the study compared the attack from 2002 to be 1 fifth of Harvard’s network capability to 25 times Harvard in 2009. Additionally the paper noted that a 400 Mbps DDoS attack will still cause many networks to crash. The paper used in sourcing for these points is specific to Human Rights sites (a common target for DDoS attacks) and was compiled by Suckerman, E., Roberts, H., McGrady, R., York, J., Palfrey, J., 2010. A link to the article:  click here

Organized activist groups, particularly Anonymous have launched serveral well publicized DDoS attacks in the past 12 months particularly, Operation Payback in relation to companies boycotting WikiLeaks.

Despite the rise in DDoS attacks, three out of ten web hosting providers reported having no dedicated security staff. –  Danny McPherson et al., “Worldwide Infrastructure Security Report: Volume V, 2009 Report,” Arbor Networks, January 19,  2010, http://staging.arbornetworks.com/dmdocuments/ISR2009_EN.pdf.

Methods

A 2009 study identified a shift away from purley bandwidth based attack. – Danny McPherson et al., “Worldwide Infrastructure Security Report: Volume V, 2009 Report.” Additionally, most major network operators reported that DDoS attacks were usually mitigated within 1 hour, much of which came from the ability to call on upstream peers to disconnect attacking sub-nets.

DDoS attacks can be catagorized into:

Application attacks: Use software vulnerabilities to exhaust system resources.

Network Attack: saturate communication lines to the target.

Arbor’s 2009 report states that 45% of DDoS attacks were network attacks and 49% were application attacks.

Botnets and amplifiers are two key components of DDoS attacks. Botnets assist in braodening the range of IP address the attack is coming from, reducing detection and increasing collateral damange in mitigation. A botnet of several hundred thousand computer is not however sufficient to generate 49 Gbps of bandwidth. To up the bandwidth, amplifiers are used. An example of amplification is an attacker sending DNS requests to a DNS server with the source IP address of the target. The packet send to the DNS server by the attack is 1 / 76 the size of the packet send to the target. We can see that the attack has been sgnificantly amplified.

In essence, DDoS attackers use the distributing effect of a botnet in association with resource leverage such as DNS amplification to increase the potency of their attacks.

On a “normal” day, Arbor detects roughly 1300 DDoS attacks. – Arbor Networks, “Atlas Summary Report: Global Denial of Service,” accessed October 26, 2010,
http://atlas.arbor.net/summary/dos

Mitigation

The balance between reducing malicious traffic and service availability to genuine users is very difficult to effectivley maintain. The challenge for all network admins should be to keep this ratio as high as possible. Some simple mitigation methods are listed below, a more expansive review will be conducted in the next post. The legality and lack of collaboration between contries and companies is another key point needed for discussion in a wholistic mitigation strategy.

• Avoiding ‘edge’ ISPs, ie: tier 3, small/inhouse hosting companies
• Replacement of CMS sites withe static HTML content.
• Adding aggressive caching
• Use of DDoS resistent servers (ie: blogger cloud, EC2 cloud) or atleast have these servers as a backup
• Clear communication and understanding of ISP SLAs.

Continuing on with the deeper analysis of each attack method, this post will review the Low-rate DoS attack. The key paper I will be using  as a reference for this review will be:

RRED: Robust RED Algorithm to Counter Low-Rate Denial-of-Service Attacks, 2010, Zhang, C., Yin, J., Cai, Z., and Chen, W., IEEE COMMUNICATIONS LETTERS, VOL. 14, NO. 5, MAY 2010.

Another key resource is this site, tracking recent Low-rate DoS attacks: http://sites.google.com/site/cwzhangres/home/posts/recentpublicationsinlow-ratedosattacks

A presentation by A. Kuzmanovic and E. W. Knightly, 2003 (http://www.cs.northwestern.edu/~akuzma/rice/doc/shrew.ppt) is heavily borrow from.

Starting with a simple definition, Low-rate DoS attacks differ from flood type attacks in that packet transmission is  limited. The TCP timeout mechanism is instead exploited to increase the ratio of attacker resources to target resources consumed. This reduced packet transmission also serves to make the attack method much more difficult to identify. Low-rate DoS attacks are also known as:

• Shrew attacks – see: http://www.cs.northwestern.edu/~akuzma/rice/shrew/
• Pulsing DoS [PDoS]
• Reduction of Quality [RoQ]

Two important variables in the TCP congestion avoidance mechanism are:

• Retransmission time-out [RTO]
• Round Trip Time Estimate [RTT]

Logically the RTO must be less than the RTT to avoid unnecessary retransmission. In fact RTO=S(smoothed)RTT+4*RTTVAR.

At this point it is important look more closely at how the TCP congestion avoidance algorithm works:

1. A ‘congestion window’ is maintained, limiting the number of packet that have not been acknowledge by the receiver, packets in transit.
2. When TCP connections are initialized or after dropped packet TCP enforces a ‘slow start’. The slow start mechanism starts the ‘congestion window’ small and then increases it exponentially with each acknowledged packet. This makes sense, as the TCP connection demonstrates its stability we can increase throughput.

The testing run by A. Kuzmanovic and E. W. Knightly demonstrated that shrew attacks can reduce a targets TCP throughput to a fraction of normal operation. Achieved with a relatively low number of malicious throughput… ” 87.8% throughput loss without detection“.

The Low-rate DoS attack exploits the standardization of the TCP protocol. Many protocols used on the internet are standardize (ie: HTTP, IP, etc) , they need to be standardized for communications to work. This does however present attackers with a target they know will be present on systems everywhere.

Detection and Mitigation

A. Kuzmanovic and E. W. Knightly analyze minRTO randomization and find this to be effective at the cost of general TCP performance. They also highlight that the different TCP congestion avoidance algorithm versions result in significantly different PDoS effectiveness.

Zhang et. al., propose a Robust Random Early Detection [RRED] algorithm, identifying malicious TCP packets by the time frame in which they are resent after a timeout.

I will aim to do some testing using snort or even dynamic iptables rules to allow for effective detection and mitigation of shrew attacks.

This week I will start a detailed review of each of the attack methods introduced in Week 1’s post. I will start with on of the oldest DoS attacks, the Ping of Death.

I incorrectly listed this under ICMP attacks in a previous post, the ping of death actually exploits the process of IP packet reassembly.

We can see above that after being received via the communication medium (ie: cat6 cable), the ethernet packets are unwrapped and we find an IP packets. The maximum size of an IP packet according to the standard specification (http://tools.ietf.org/html/rfc791) is 65,535 bytes. The maximum size of a standard ethernet frame (http://standards.ieee.org/about/get/802/802.3.html) is 1500 bytes. So this means that IP packets must be split across multiple Ethernet frames and the receiver must reassemble them. To keep track of reassembly the IP fragments have an fragment offset field.

The fragment offset says, “I start with the 1000th byte of the complete IP packet, put me after the 999th byte. Now considering the fact that the ethenet protocol allows frames of upto 1500bytes, the IP protocol would not allow an IP fragment to say I am the 65,000th byte put me there. As above the maximum IP packet is 65,535 bytes. However, the IP protocol actually allows an IP fragment to say I am the 65,528th byte!

So, if an attacker send an IP packet that was the allowable size of  65,535 bytes, it will be broken up into Ethernet frames (Ethernet is the most common Datalink protocol). A ping of death occurs when the attacker modifies the the last IP fragment to I am the 65,528th byte but add more that 8 bytes of subsequent data. The receiver will now try to reassemble an IP packet that exceeds 65,535 byte limit.

Due to the fact that data communications and packet assembly must be very fast in older operating systems there were no checks done to ensure the reassembled IP packet did not exceed the memory allocated for it. This would result in a buffer overflow and the crash or bugging of the system.

On any post 1998 systems a check is completed to ensure the sum of Fragment Offset and Total Length field on an IP fragment do not exceed 65,535 bytes. This is obviously an old, now mostly non-exploitable attack but it is worth reviewing to see the type of exploits that have existed in the past as they will provide some insight into future vulnerabilities.

A program written in C by Bill Fenner implementing a ping of death using ICMP can be found here: http://insecure.org/sploits/ping-o-death.html.

Any program implementing a ping of death attack must be able to inject modified packets/frames to a network interface. This is also required in a number of other DoS attacks so I will look at doing a basic script in Python using the PyCap Library: http://pycap.sourceforge.net/. Although it does require Python 2.3 :(.

This week’ summary will be a review of 2 papers from my reading pack: http://mchost/sourcecode/DoS/DoS%20Docs/JournalandBook/

Adaptive Defense Against Various Network Attacks, 2006, Zou, C., Duffield, N., Townsley, D., Gong W., IEEE.

Summary:

The method discussed in the paper was not focused on improving the current malicious packet identification methods but to increase the efficiency of their application by modifying their adjustable parameters based on the current and recent network conditions. One example was drawn via the Hop Count Filtering [HFC] method for mitigation of DDoS attacks through the assumption that attackers do not know the real hop-length from spoofed sources to their target. The effectiveness of this particular mitigation method is not paramount to the contention but rather the fact the HCF has adjustable parameters in its filtration. By adjusting the ‘strictness’ of the HCF using a simple, low overhead, low computational cost method, the authors were able to significantly improve the performance of the HCF.

Note that performance was based on a curve whereby the costs of false positive and false negatives were arbitrarily defined.

Relevance to thoughts in intelligent systems in network security and DDoS mitigation:

• Computational cost is almost always relevant
• Network overhead is always relevant
• The utility, or cost/reward heuristic for the adaptive system must be provided to the system
• Parameter management of multiple non-adaptive mitigation or defense systems can be done by single adaptive service which monitor network conditions and established the probability a current attack and the severity.
• The proposed systems does not use any intelligent systems in the actual identification of malicious packets, perhaps this is due to the computational cost.
• Adaptive systems can be used to achieve cost minimization for security services.

A Distributed Throttling Approach for Handling High Bandwidth Aggregate, 2007, Wei Tan, C., Chiu, D-M., Lui, J., Yau, D., IEEE.

Summary:

This article approach the breakdown of network communication in the case of flash crowds and DDoS attack which both cause high network aggregates sourced from distributed source to a single location. The authors propose what I would describe as a layered router throttling approach. Throughout the article the term ‘dropped traffic’ is used as to describe the effect of router throttling. The article provides some background on the router throttling strategy but I am somewhat confused over the dropping of traffic ones a certain bandwidth level is exceeded. Does this mean that all incoming packets will be dropped regardless of the existence of tcp session? Does it means that existing sessions will remain alive until they time out? I will need to do some further reading on the router throttling mitigation method. A key requirement of this strategy is having a number of routers in the preceding network hops subscribed to the method. See below:

The paper goes on to propose a number of algorithms and lightweight communication between routers and evidence that by dropping traffic the distributed throttling method can keep target servers alive. Although this solution would undeniably be effective in keeping a server alive, it drops traffic based on the traffic level of the router it approaches. I feel that there is a very bad worst case scenario where the probability of packet being dropped would have a very low correlation to whether or not it is malicious. The lack of header/packet inspection does have very good computational efficiency however.

• This solution could be consider somewhat of a benchmark that intelligent mitigation methods would need to improve on, the indiscriminate dropping of packets will result in DoS for users approaching the server via routes that the DDoS approach. Keeping a server alive is probably the primary goal of DoS mitigation but service availability should stand right next to that goal.
• If this defense strategy was widespread it appears to have numerour vulnerabilities that attackers would sureley exploit. Attackers could test thrasholds for tripping packet dropping and possibly launch attacks that deny serverhere is a  to specific regions with less cost than an attack on a service that was not protected by distributed router throttling.
• I get a sense that this strategy could work on a macro sense perhaps piggy backing on border routing protocols, however the ‘dumb’ nature of throttling seems a very limiting factor. I will obvously need to investigate the router throttling methods more as with my current understanding this solution seems sub-optimal.

I am undertaking a reading unit this semester focused on Denial of Service [DoS] attacks and their mitigation. As there are no subjects dedicated to this field a reading unit was the best option. The aims of the unit will be:

1. Study system vulnerabilities and existing DoS attacks
2. Propose a new method to mitigate one of the DoS attacks

I have not investigated DoS attacks on anything other than an introductory level prior to this so my blog notes will start from that point. With this in mind the best beginning is in definitions. Most of this introductory post will glean resources from wikipedia’s DoS page http://en.wikipedia.org/wiki/Denial-of-service_attack, see their reference list for further reading.

Denial of Service Attack:  To slow network performance or unavailability of services (web services). Issues can spread to network branches surrounding the targeted system. In some cases entire geographical regions can be prevented from accessing the external network.

DoS attacks can also be characterized where and attacker explicitly attempts to prevent legitimate users from accessing specific services. There are two major classifications:

• Attacks which crash a server
• Attacks which flood a server

There are five categories that DoS attacks can be placed:

1. Consumption of computation resources (ie: HTTP-GET DDoS flood attack, http://teamxpc.com/forum/topic/155918-http-get-dos-attack-paper/)
2. Disruption of configuration information  (ie: DNS Poisoning attack, http://www.spamstopshere.com/blog/2008/08/07/recent-dns-poisoning-exploit-used-for-dos-attacks/)
3. Disruption of state information (ie: Resetting of TCP Sessions, http://kerneltrap.org/node/3072 , http://en.wikipedia.org/wiki/TCP_reset_attack)
4. Disruption of physical network components (ie: physical access to servers, phlashing attack/PDoS, http://hackaday.com/2008/05/20/phlashing-denial-of-service-attack-the-new-hype/)
5. Obstructing communication media (ie: replay attacks on wifi, http://www.aircrack-ng.org/doku.php?id=simple_wep_crack&DokuWiki=9a77f3d58e7c5e4adc840b60b1a2197e, cable cuts, http://www.guardian.co.uk/world/2011/apr/06/georgian-woman-cuts-web-access)

Some examples of known DoS attacks:

• ICMP Attack  (Smurf, Ping of Death, Ping flood, SYN flood) – Malformed ICMP packets aimed at consuming targets network and computational resources. (tool – http://www.hping.org/)
• Teardrop Attack – mangled IP packets with overlapping and oversized IP payloads    which exploit TCP/IP reassembly methods in numerous operating systems. In a Teardrop attack, the data packets are sent to the target computer in the following format: (1 to 1500 bytes) (1500 to 3000 bytes) (1001 to 3600 bytes). When the target system receives something like the above, it simply cannot handle it and will crash or hang or reboot.
• SYN Flood – Sending multiple SYN request with bad source address so the target queues them all awaiting a timeout on the request (http://mediakey.dk/~cc/hackerguide-syn-flood-attack/)
• Low rate denial of service attacks – While TCP’s congestion control algorithm is highly robust to diverse network conditions, its implicit assumption of end-system cooperation results in a well-known vulnerability by high-rate non-responsive flows. However, little is known about low-rate denial of service attacks. We have discovered that low-rate attacks can be as harmful as the high-rate ones, yet even more dangerous due to the fact that they are difficult for routers and counter-DoS mechanisms to detect. (inventors: http://www.cs.northwestern.edu/~akuzma/rice/shrew/, tools: sockstress: http://www.2shared.com/file/L4VC9Wdp/sockstresstar.html)
• Peer-to-peer botnet attacks -The TDL-4 botnet may have started via p2p networks – http://www.readwriteweb.com/archives/one_botnet_to_rule_them_all_kaspersky_labs_finds_i.php, http://www.securelist.com/en/analysis/204792180/TDL4_Top_Bot, botnets can be used for more than just DoS – http://www.theregister.co.uk/2008/06/28/nugache_creator_plea_agreement/)
• Stacheldraht tool – Botnet attack (http://staff.washington.edu/dittrich/misc/stacheldraht.analysis, see diagram above)

Some additional reading on DoS attack definitions:

http://www.garage4hackers.com/showthread.php?251-DOS-Attacks