Categories
Reading Unit - DoS Research

FIT5108 – DoS Reading Unit Part 8

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.

phlashdance
Phlashdance - automated firmware vulnerability tester (Rich Smith, 2008)

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.

Categories
Advanced Network Security

FIT5037 – Advanced Network Security Week 8

Taking a more abstract view on computer security, week 8’s topic was computer security for large networks. This first part of the lecture discussed risk analysis. Some key steps in conducting risk analysis:

  • Value of assets being protected – if attacks break into our network what is the worst case scenario? This value is constantly rising in today’s business environment. This step will also establish a budget range for system security, there is no point spending 1 million protecting a system that contains information and assets worth one hundred thousand.
  • Threat identification – What are the known threats to our system? This could include likely attackers, the types of known exploits and an understanding of what possible unknown exploits may be capable of.
  • Identification of key system components:
networkcomponents
Some key components (source: Week 9 lecture notes)
  • Define each step in the security life cycle – Prevention -> Detection -> Response -> Recovery
  • Specifying policy areas for People, Processes and Tools
  • Begin development of security policy using a logical framework: Organizational -> Security Architecture -> Technical
  • Design, implementation and testing of chosen security tools:
defencesystems
Some security tools (source: Week 9 lecture notes)
  • Audit any security systems in place at set time periods (ie: once a year)
  • Understand that organization requirements can change quickly and that the security policy is in place to protect organizations whilst allowing them to operate as unhindered as possible, there is no point having a completely secure systems that takes employees 2 hours to gain access to.

Design of system wide security policies may come off as a more managerial, less technical operation. However, to implement a good security policy, decision makers must be aware of and have an in depth understanding of the available tools, threats from attackers and the organizational requirements. I would be very surprised if most vulnerabilities were as a direct result of technical issues rather than holes as a result of poorly designed and implemented security policies.