Background

Signatures and indicators: what is a good signature ? A good signature depends of the context but the main properties are:

More resilient than rigid (resist evasion and normal changes).

More methodology-based than specific (capture methods or techniques).

More proactive than reactive (identifies new technologies )

Process

Define detection

what. where, when to find.

Assemble a sample set

collected sample set.

generated sample set.

try to enumerate the entire problem set.

Test existing detection/s

Test existing detection capabilities for any free wins.

Adjust priorities of existing applicable existing detections.

Generate data

logs.

binary metadata.

Write detection

start broad and tune after.

Test and tune

Process Walk-through for binaries

It applies the previous process to binaries.Malware binaries changes very often. In this case can’t rely on anti-viruses.

Process Walk-through for regsvr32.exe

It applies the previous process to the regsvr32.exe. It shows that is rather difficult to detect the regsvr32 arguments or process name
because there are multiple possibilities for the parameters for ex: /s or -s /u or -s or /us or -us.

Computer scientists at Lockheed-Martin corporation described a new “intrusion kill chain” framework; see KillChain.

PRE-ATT&CK: Adversarial Tactics, Techniques & Common Knowledge for Left-of-Exploit is a curated knowledge base and model for cyber adversary behavior, reflecting the various phases of an adversary’s lifecycle and the platforms they are known to target.

PRE-ATT&CK consists of 15 tactics and 151 techniques.

ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge for Enterprise is an adversary model and framework for describing the actions an adversary may take to compromise and operate within an enterprise network. The model can be used to better characterize and describe post-compromise adversary behavior.

Summary of the adversary behavior:

know when they are coming, use PRE-ATT&CK

see them when they operate on your infrastructure, use ATT&CK.

map their activities, use the “kill chain”.

Don’t jump directly to attacker remediation; If an adversary perceives you as hostile (e.g.: hacking back), they will react differently.

Malware is a constant threat to the Android ecosystem. How to protect from the malware:

have to look to the APK file/s:

statically

or in a sandbox

looking for:

(code) signatures

hashes

permissions reputations

What are the shortcomings of the current detection techniques:

static analysis is hard and it only can reveal a subset of the functionality.

bypass the AV products is easy.

cannot do forensics on realtime.

Idea: look to the application heap because the Android apps make us of objects. But the novelty is that should instrument the code before the execution:

objects exist on the heap so they are accessible.

trace calls and monitor the behavior.

great way to gain insight into applications

The authors presented his own framework called UITKYK. Uitkyk is a framework that allows you to identify Android malware according to the instantiated objects on the heap for a specific Android process.

The framework is also integrates with Frida framework which is a “dynamic instrumentation toolkit for developers, reverse-engineers, and security researchers”.

Here are my quick notes from the BruCON 2018 conference.This first day was called “Retro Day” because it contained the best (as chosen by peoples) previous talks. All the slides of the conference can be found here.

Implementing of selfish behavior using cheap devices

Implement the selfish behavior (this was done by modifying the firmware):

disable Backoff.

reduce AIFSN.

Countermeasures to this problem:

DOMINO defense system detects selfish devices

What if are multiple selfish stations ?
in theory : in collision both frames are lost but in reality due to the “capture effect” in a collision the frame with best signal and lowest
bit-rate is decoded (similar to FM radio).

Continuous jamming

how it works:

instant transmit:disable carrier sense

no interruptions : queue infinite packets

This will
– only first package visible in monitor mode
– other devices are silcenced

What is the impact in practice:
We can jam any device that use the 2.4 and 5 GHz band, not only wifi, but other devices like security cameras.

Selective jammer

Decides based on the header whether the jam the frame
so it should:

detect and decode the header.

abort receiving current frame.

inject dummy packet

The hard part is the first step. This is done by monitoring the (RAM) memory written by the radio chip.

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

In some situations it is needed that some of the OSGI bundles are started in a specific order.

A concrete case is when the Apache Camel is used in the context of the OSGI. If one of the OSGI bundles are an user defined Apache Camel component and another bundle uses this user defined Camel component into a (Camel) route then the bundle containing the Camel component should be started before the bundle that is using the Camel component.

Solution – modify the bundle/s start level

The first solution would be to modify the start level of the bundle that you want to start later.

Solution – use a BundleListener

The basic idea is that the bundle B (than needs the bundle A to be active) will wait until the the bundle A is marked as started. This can be achieved by implementing a BundleListener to the level of bundle B.

The implementation of the “bundleChanged” method of the listener will look like this:

public void bundleChanged(BundleEvent bundleEvent) {
String symbolicName = bundleEvent.getBundle().getSymbolicName();
int eventType = bundleEvent.getType();
if ("The Bundle A Symbolic Name".equals(symbolicName)
&& BundleEvent.STARTED == eventType) {
//here we know that bundle A is started
//so can do something that will need
//bundle A
}
}

The advantage of this approach is that the bundle developer is in control of the behavior. On the the other side this approach will not work if you do not own the code of the bundle that you want to start later.

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.

Context

In the context of a (Java) Selenium test it was needed to set-up a http proxy at the level of the browser. What I wanted to achieve it was exactly what is shown in the next picture but programmatically. In this specific case the proxy was BurpPro proxy but the same workflow can be applied for any kind of (http) proxy.

Solution

I know this is not really rocket science but I didn’t found elsewhere any clear explanation about how to do it. In my code the proxy url is injected via a (Java) system property called “proxy.url“.

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.