Skip to content

Software Security and Vulnerabilities

Risks

Lack of security within software or unpatched vulnerabilities can allow attackers to gain access to systems and cause issues. We have the risk that the service and data is unavailable, reputation damage, data leaks (including sensitive banking data), data loss, etc.

Consequences

Following these risks, the companies or individuals suffer consequences of their poor cybersecurity practices. Companies lose money through the stock market as investors sell when they are less confident.

In the public sector, we can leak things about people that are supposed to be private, or cause disruption to critical services (e.g., water, electricity).

Defences

To defend ourselves, we can either take measures to allow business continuity in the event of a fault, or take more steps to protect against attackers. In case of a fault, we typically want to employ some sort of data replication and backup, so that we can restore a server in the event it is taken down.

We can also ensure that we have good, tested disaster recovery policies in place, so that we can quickly restore from backups. In terms of protection from attackers, we need to know who the attacker is.

Who is the Attacker?

Attackers have many motivations for wanting to sabotage your assets. They may be rival companies or contracted as such, to dissuade customers from using your services, when they could instead be using the rivals. We also have hackers, which comprise individuals, hacktivist groups, and possibly nation state backed groups. Some hackers use extortion by employing cryptolockers to encrypt data on-drive, such that the company would have to pay vast amounts of money to recover data.

Protecting Assets

Assets encompass a large amount of different things in relation to cyber space. They include information, such as databases, files, datastores, physical assets, and network assets.

Physical

Physical assets are the easiest to overcome, as once an attacker has access to a machine locally, it is very hard to prevent access to the system. We therefore deny unauthorised access to facilities, equipment, data centres, and resources.

To prevent unwanted access, we have comprehensive surveillance, security, barriers, locks and access control throughout the data centre.

Information and Networks

Whilst physical security can be easily accounted for, there is typically huge amounts of traffic traversing a network, and getting access to computing resources within a DC. If an attacker gains access to a network, they can get or modify the data on the systems. Therefore, it is important that the information and network assets are correctly protected.

Vulnerabilities

Vulnerabilities can occur in physical systems, networking and infrastructure systems, operating systems and software applications. Besides physical systems, all these vulnerabilities are things that are caused by bugs in software.

CIA Triad

We've covered this loads in the past couple of years. Essentially, it boils down to maintaining the confidentiality, integrity, and availability of the data. A breach in confidentiality means that the data is available to an unauthorised user, integrity means that we aren't sure if the data is what it is supposed to be, and availability means that the data cannot be accessed as intended by an authorised user.

Buffer Overflows

One of the main vulnerabilities in a piece of software historically is a buffer overflow. This is where we allocate a fixed sized buffer for a program, then write to that buffer without checking the amount of data we are writing to it. This is trivial to fix if we add some guard to the copy function to first check the length of the input data, but a lot of legacy code doesn't really bother.

Any time we see a segmentation fault, this means we may have written to a buffer but gone past the end of our allocated space. This is normally through negligence, but can be abused by an attacker to allow them to exploit the system.

How Vulnerabilities, Threats and Risk Differ

Vulnerabilities are a weakness in the system, caused by some internal factor. A threat is a condition that can cause harm to a system. This is an external factor. A risk is the likelihood of a realisation of a threat. If we have a vulnerability without a threat or a threat without a vulnerability, then nor risk exists.

The issue with this is that there will always be threats in the real world, and unless we formally verify a system for correctness, being a really small codebase, there is no way to prove that we don't have a vulnerability.

Lifecycle

A vulnerability will go through the following lifecycle:

  1. Software is released from a vendor
  2. Vulnerability is discovered by an attacker and an exploit is released
  3. The vulnerability is discovered by the vendor
  4. The vulnerability is then disseminated publicly
  5. Antivirus engines start to reveal the exploit
  6. A patch is released by the vendor
  7. Exploit mitigation is deployed on all affected systems.

Until the point at which the vulnerability has been disclosed publicly, whilst the exploit has been released in the wild, this is known as a zero day attack. Until the patching of the affected systems has been completed, but after the public disclosure, there is the possibility of a follow-on attack.

Price of a Vulnerability

Companies offer incentives for security analysts to attack their software with permission, provided they adhere to a set of guidelines by the vendor. If they find a vulnerability through the course of their testing, they can report this confidentially to the vendor, allowing the vendor to find the root cause and release a patch through their usual update mechanisms before the exploit can be used in the wild. The pay ranges from £5,000 for a simple vulnerability in something like WordPress to £500,000 for a vulnerability in something like an iOS bug.

Cataloguing Vulnerabilities

Historically, vulnerabilities have not been catalogued properly, with systems such as enumeration (a tuple for each vulnerability), or storage based on some other characteristics. To fix these issues and prevent the same vulnerability from being stored in different ways, we now collectively use the Mitre CVE standard.

In 1999, a catalogue of vulnerabilities were introduced on cve.mitre.org, giving a uniform, official catalogue of different vulnerabilities that existed at the time. Now, this might sound like XKCD #927, but for once, it actually seemed to work, and this is now the standard that we all used.

For a vulnerability to be catalogued on CVE, they must violate at least one of the CIA properties. They are assigned a unique string: CVE-YYYY-<number>, such that there is no confusion over what is what.

The vulnerability then is given a page with a description of what it is, a link to either a write up or other detailed references, and the date of creation.

Heartbleed

This was a vulnerability introduced in the OpenSSL library, affecting over 60% of web servers at the time. It failed to do a length validation check on the server side, and allowed the end user to maliciously use the heartbeat function of the library.

Therefore, the user was able to read arbitrary memory that it should not have access to, and thus violated the confidentiality aspect of the CIA triad. The vulnerability was assigned CVE-2014-0160 (NVD website, US NIST).

The issues causing this vulnerability were within two C library files. This was quickly patched but until the patch was released, all servers using legacy OpenSSL were vulnerable. Exploits for this are available on exploit-db.com.

The patch process for this vulnerability was completed by a Chromium engineer and someone from ACM. This was disclosed responsibly to the maintainers of OpenSSL and not made public until the release of the patch.

Even following the release of the patch, the majority of webservers were still vulnerable, and still are, although the total number is continually in decline. Automatic updates help to prevent issues like this, although not all systems administrators have this setup.

Shellshock

This was another vulnerability (CVE-2014-6271), allowing an attacker with access to .bashrc that sends data to a server that is processed with bash to gain remote code execution capabilities. RCE is much more severe than an out-of-bounds memory read as the possibilities with what can be done are much higher.

Common Vulnerability Scoring System

This is the free and open industry standard for assessing the severity of computer system security vulnerabilities. It is a quantitative analysis of different aspects that the vulnerability might be used to exploit.

The formula combines the following:

  • Base metrics:
    • Ease of exploitation
    • Impact
  • Temporal metrics:
    • Is a patch available?
    • Is an exploit available?
  • Environmental metrics:
    • What are the consequences on safety?
    • How many systems are vulnerable?

CVSS classifications also factor in the various aspects of the CIA triad. They look at the access vector, complexity, authentication required, in addition to the CIA properties.

Common Weakness Enumeration

This is similar to a CVE, but assigns a score and a description based on the type of attack. We also calculate the weakness score, to show which weaknesses are most critical to ensure are fixed. For example, the stack-based buffer overflow (CWE-121) is a part of the overall buffer overflow weakness, which is based on an out of bounds write, etc. CWEs are a hierarchical list.

Comments