(My) OWASP Belgium Chapter meeting notes

CloudPiercer: Bypassing Cloud-based Security Providers (by Thomas Vissers, iMinds-DistriNet-KU Leuven)

The goal of the presentation was to show how the CBSP (Cloud Based Security owasp_logoProviders) are protecting the applications and how this protections can be circumvented.

The most common attacks on the web applications are the DDOS.

2 types of DDOS attacks:

  • volumetric attacks – no more network bandwidth
  • application level attacks – servers are targeted

How the CBSP are protecting the web application ?

CBSP reroute and filter the customer traffic through their cloud (see the following picture).

cbsp

The secrecy of the origin server IP address is crucial because, (if discovered) the server can be hit directly and the CBSP protection is useless.

Vulnerabilities, or how the origin server IP can be found

  1. subdomains – administrators can create a specific subdomain, such as origin.example.com, that directly resolves to the origin’s IP address; they need it in order to easily connect to the server for non http services (SSH, FTP)
  2. dns records – other DNS records might still reveal your origin.; ex TXT records, MX records
  3. SSL certificates – it concerns the https connection between CBSP and origin server. If an attacker is able to scan all IP addresses and retrieve all SSL certificates, he can find the IP addresses of hosts with certificates that are associated with the domain he is trying to expose.
  4. IP history – companies constantly track DNS changes
  5. sensitive files on the (target) web application; error messages, files containing IP information
  6. outbound connections – force the origin to connect to you.

Defenses/what can i do to protect ?

  • request a new ip address when activating the CBSP.
  • block all non-CBSP requests with your firewall
  • choose a CBSB that assignes a dedicated IP address to you
  • use cloudpiercer.org to scan your website

If interested you can read Bypassing Cloud-based Security Providers – DistriNet – KU Leuven

Hackers! Do we shoot or do we hug? (by Edwin van Andel, Zerocopter)

For me the presentation was a (very) funny pleading for an ethical hacking.

Threat Modeling for mere mortals

This ticket is an introduction to the threat modeling in the context of software development.

Definition

In the context of the IT security, threat modeling is a structured approach that enables you to identify, quantify, and (eventually) address the security risks associated with an application.

A more formal definition

 For somebody having the security mindset the previous definition might be not very formal; let’s try a new definition but before let’s introduce some new definitions:

  • asset  – an asset is what it must be protected. In the context of software, it could be the infrastructure, the software installed, the user data.
  • vulnerability – a vulnerability is a weakness that can be present in one of the assets.
  • threat – anything that can exploit a vulnerability and obtain, damage, or destroy an asset.
  • risk – the potential for loss, damage or destruction of an asset as a result of a threat exploiting a vulnerability.

So, the threat modeling (also sometimes called risk analysis or architectural risk analysis) is the process integrated in the SDLC (Software Development Life Cycle) having as goal to find and address (mitigate, eliminate, transfer or accept) all possible risks for a specific software functionality.

The threat modeling should be applied in the SDLC as early as possible, ideally in the requirements phase (the earliest the problems will be found the easiest would be to fix) and could even modify or adjust the requirements.

The threat modeling process

The threat modeling process have 3 phases:

  1. model the system for which you want to find the threats.
  2. find the threats.
  3. address each threat found in the previous step.

1. Model the system

The goal is to have a diagram representing the system under process. In the specialized literature, the Data Flow Diagrams are very often used because it easily represent all interaction points that an adversary can leverage to attack a system and also show how data moves through the system. The diagram could be improved adding “trust boundaries”, boundaries where data changes its level of “trust”.

2. Find the threats

After having a diagram of the system then you can ask how an attacher could attack the system. There are different approached that can be used to find “what can go wrong”:

  • STRIDE –this methodology (created by Microsoft) classifies threats into 6 groups:Spoofing, Tampering, Repudiation,
    Information Disclosure, Denial of Service and Elevation of Privilege.
    Threat Modeling is executed by looking at each component of the system and determines if any threats that fall into these categories exist for that component and its relationships to the rest of the system.
  • Threat/Attack libraries – libraries containing common and already known attacks. Threat library can be a quick way to take advantage of industry security knowledge (helping teams that lack sufficient knowledge themselves). Some examples of Threat libraries: OWASP Top Ten, CAPEC, CWE.
  •  Misuse cases – These cases should be derived from the requirements of the system, and illustrate ways in which protective measures could be bypassed, or areas where there are none.

3. Addressing the threats

Once identified,each threat must be evaluated according to the risk attached to it (using a risk rating system such as Common Vulnerability Scoring System), the resources available,the business case and the system requirements.

This will help prioritize the order in which threats should be addressed during development, as well as the costs involved in the mitigation  (if you decide to mitigate it).

Not all the treats can be mitigated. It is also possible to decide that some of them should be eliminated (meaning that the feature of the functionality that if affected should be removed), transfered (let somebody or something else to handle the risk) or accepted (accept the risk that could happen).

If you want to go further

If you want to go further and dig deeper hare are some links that I found useful:

(my year) 2015 in review

The WordPress.com stats helper monkeys prepared a 2015 annual report for this blog.

Here’s an excerpt:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 22,000 times in 2015. If it were a concert at Sydney Opera House, it would take about 8 sold-out performances for that many people to see it.

Click here to see the complete report.

(my year) 2013 in review

The WordPress.com stats helper monkeys prepared a 2013 annual report for this blog.

Here’s an excerpt:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 9,700 times in 2013. If it were a concert at Sydney Opera House, it would take about 4 sold-out performances for that many people to see it.

Click here to see the complete report.

2012 in review

The WordPress.com stats helper prepared a 2012 annual report for this blog.

Click here to see the report.