run the container in read only mode: docker run --read-only...or docker run –v /hostdir:/containerdir:ro

Hardening

Container

docker run --cap-drop option, you can lock down root in a container so that it has limited access within the container.

--security-opt=no-new-privileges prevents the uid transition while running a setuid binary meaning that even if the image has dangerous code in it, we can still prevent the user from escalating privileges

Host

networking – only SSH and NTP

Logging

Securing Containers on the High Seas (by Jack Mannino)

The entire presentation is around the 4 phases used to create an application that runs on containers:

Design

Build

Ship

Run

Design (secure the design)

Understand how the system will be used and abused.

Beware of tightly-coupled components.

Can solve security issues through patterns that lift security out of the container itself. ex Service Mesh Pattern.

Build (secure the build process)

Build first level of security controls into containers.

Orchestration systems can override these controls and mutate containers through an extra layer of abstraction.

Use base images that ship with minimal installed packages and
dependencies.

Use version tags vs. image:latest; do not use latest !

Use images that support security kernel features

Limit privileges

Often, we only need a subset of capabilities

ex: Ping command requires CAP_NET_RAW. So we can run docker image like this:

docker run -d --cap-drop=all --cap-add=net_raw my-image

Kernel Hardening

Seccomp is a Linux kernel feature that allows you to filter dangerous syscalls.

MAC (Mandatory Access Control)

SELinux and AppArmor allow you to set granular controls on files and network access.

Context and goal

The goal of this ticket is to explain how to create an extension for the Burp Suite Professional taking as implementation example the “Reverse Tabnabbing” attack.

“Reverse Tabnabbing” is an attack where an (evil) page linked from the (victim) target page is able to rewrite that page, such as by replacing it with a phishing site. The cause of this attack is the capacity of a new opened page to act on parent page’s content or location.

The attack vectors are the HTML links and JavaScript window.open function so to mitigate the vulnerability you have to add the attribute value: rel="noopener noreferrer" to all the HTML links and for JavaScriptadd add the values noopener,noreferrer in the windowFeatures parameter of the window.openfunction. For more details about the mitigation please check the OWASP HTML Security Check.

Basic steps for (any Burp) extension writing

The first step is to add to create an empty (Java) project and add into your classpath the Burp Extensibility API (the javadoc of the API can be found here). If you are using Maven then the easiest way is to add this dependency into your pom.xml file:

Extend the (Burp) scanner capabilities

In order to find the Tabnabbing vulnerability we must scan/parse the HTML responses (coming from the server), so the extension must extend the Burp scanner capabilities.

The interface that must be extended is IScannerCheck interface. The BurpExtender class (from the previous paragraph) must register the custom scanner, so the BurpExtender code will look something like this (where ScannerCheck is the class that extends the IScannerCheck interface):

Let’s look closer to the methods offered by the IScannerCheck interface:

consolidateDuplicateIssues – this method is called by Burp engine to decide whether the issues found for the same url are duplicates.

doActiveScan – this method is called by the scanner for each insertion point scanned. In the context of Tabnabbing extension this method will not be implemented.

doPassiveScan – this method is invoked for each request/response pair that is scanned. The extension will implement this method to find the Tabnabbing vulnerability. The complete signature of the method is the following one: List<IScanIssue> doPassiveScan(IHttpRequestResponse baseRequestResponse). The method receives as parameter an IHttpRequestResponse instance which contains all the information about the HTTP request and HTTP response. In the context of the Tabnabbing extension we will need to check the HTTP response.

Parse the HTTP response and check for Tabnabbing vulnerability

As seen in the previous chapter the Burp runtime gives access to the HTTP requests and responses. In our case we will need to access the HTTP response using the method IHttpRequestResponse#getResponse. This method returns a byte array (byte[]) representing the HTTP response as HTML.

In order to find the Tabnabbing vulnerability we must parse the HTML represented by the HTML response. Unfortunately, there is nothing in the API offered by Burp for parsing HTML.

The most efficient solution that I found to parse HTML was to create few classes and interfaces that are implementing the observer pattern (see the next class diagram ):

The most important elements are :

IByteReader interface – this interface represents the Subject (or Observable) from the Observer pattern. This interface has methods for attach and notify the observers.

This talk subject was about the attack on the WPA2 protocol that was made the (security) headlines last year. The original paper can be found here and the slides can be found here.

The talk had 4 parts :

presentation of the attack.

practical impact

common misconceptions

lesson learned

Presentation of the attack

The 4-way handshake is used in any WPA2 protected network. His use if for mutual authentication and to negotiate a new pairwise temporal key (PTK).

The messages sent between the client and the access point (AP) are the following ones:

The PTK is computed in the following way: PTK = Combine (shared secret, ANonce, SNonce) where ANonce, SNonce are random numbers.

Re-installation attack:

the attacker will clone the access point on different channel.

the attacker will/can forward or block frames.

the first 3 messages are sent back to client and AP.

message 4 is not sent to the AP; the attacker block this, and the client install the PTK (as per protocol specification)

client can sent encrypted data but the AP will try to recover from this by re-sending message 3.

then the client will reinstall the PTK meaning that will reset the nonce used to send encrypted data.

the effect of this key re-installation is that the attacker can decrypt the frames sent by the client.

Other types of handshake protocols are vulnerable to this kind of attack:

group key handshake.

fp handshake.

Practical impact of the attack

The main impact is that the attacker can decrypt the data frames sent by the victim to the AP (access point) and the attacker can replay frames sent to the victim.

iOS 10 and Windows, the 4-way handshake is not affected (because they are not following the WPA2 specification), but the group key handshake is affected.

Linux and Android 6.0+ that are using the wpa_supplicant 2.4+ version are exposed to install all-zero key vulnerability. The basic explanation of the vulnerability is the following one; the application do not keep the key, the PTK is installed at the kernel level and the application will zeroed the memory buffer that contains the key. But when the key re-installation is triggered, then the all-zero key will be sent to the kernel to be installed.

Countermeasures:

AP (access point) can prevent most of the attacks on clients:

Don’t retransmit message 3/4.

Don’t retransmit group message 1/2.

Common missconceptions

update only the client or AP is sufficient.

in fact both vulnerable clients & vulnerable APs must apply patches

must be connected to network as attacker.

in fact the attacker only need to be nearby victim and network.

Lessons learned

4-way handshake proven secure AND encryption protocol proven secure BUT the combination of both of them was not proven secure.

This proves the limitation of formal proofs so abstract model ≠ real code.

This talk was about the new version of the OWASP SKF. I already covered the SKF in some of my previous tickets (see here and here) so for me was not really a novelty. The main changes that I was able to catch comparing with the previous version :

(secure) code examples in more languages; at least Go and Java languages was added since last time I looked.

SAMM consists in 4 business functions each one containing 3 security practices. Each security practice have 4 maturity levels (from 0 to 3):

Each (SAMM) maturity level defines the following attributes:

objectives

activities

results

success metrics

cost

personnel

related levels

How do we start with SAMM: It is possible to start with the SAMM Toolbox Excel file in order to do an initial assessment for each of the security processes (the Excel file will compute the maturity level). This initial assessment will help you to plan the improvements.

Secure Development in agile development

There are a mismatch between the agile development goal/s and the security goal/s

agile dev

security

speed and flexibility

short cycles

limited documentation

functionality driven

stable and rigorous

extra activities

extensive analysis

non functional

Introducing security into agile development is not easy task and especially there is not a standardized way of doing it.

OWASP Summit 2017 debrief

The talk was a debrief about the OWASP Summit 2017 which was held in London; more than 200 participants, 176 working sessions, 6 rooms. To see all the outcomes of the summit you can check the Summit Outcomes.

The goal of the presentation was to show how the CBSP (Cloud Based Security Providers) 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).

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

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)

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.