(My) BruCON 2018 Notes

Here are my quick notes from the BruCON 2018 conference. All the slides of the conference can be found here.

$SignaturesAreDead = “Long Live RESILIENT Signatures” wide ascii nocase (by Daniel Matthew)

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.

Approaches that payed off to detect the execution of regsvr32.:

  • Handle obfuscation separately.
  • Handle renamed .exe/.dll separately

Takeaways

  • Know what you are detecting today and HOW you are detecting it.
  • Capture result of hunts as new detections.

All Your Cloud Are Belong To Us – Hunting Compromise in Azure (by Nate Warfield)

Traditional network (old days) Cloud Network
server restriction was restricted every vm exposed to internet
many layers of ACLs + segmentation VM’s deployed with predefined firewall
dedicated deployment teams anyone with access can expose bad things
well-defined patch cadence patch management decentralized

NoSQL problem

NoSQL solutions were never intended for internet exposure
BUT (naturally) peoples exposed them to internet.

Hunting NoSql Compromise in Azure

Port scans are slow and each NoSQL solution runs on different ports.

The author used shodan:

  • rich metadata for each IP
  • DB names are indexed
  • JSON export allows for automated hunting

The code was added to shodan in dec 2017 but requires shodan enterprise api access.

Network Security Group

Network Security Group is the VM firewall.

  • Configurable during deployment (optional)
  • 46% of images expose ports by default
  • 96% expose more than management

Your Iaas security is your responsibility
Pass and Saas are shared responsibility

  • Patches handled by Microsoft:
    • sas 100% transparent for you
    • paas requires configuration

Cloud marketplaces are supply chains

  • supply chain attacks are increasingly common.
  • cloud marketplaces are the next targets
  • minimal validation of 3rs party images
    • 3rd party iaas imaged are old
    • average azure age 140 days
    • average AWS Age: 717 days

2018 year of the cryptominer

  • cryptomining is the new ransomware
  • open s3 buckets are attacked
  • any vulnerable system is a target

 

Disrupting the Kill Chain (by Vineet Bhatia)

What is this talk about:

  • how to make the adversaries intrusion cost prohibitive.
  • how to monitor and secure Windows 10 environments.
  • how to recover from an intrusion.

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.

How to make intrusions cost prohibitive:

  • reduce attack surface area.
  • detect early and remediate swiftly.
  • deceive, disrupt and deteriorate.

The rest of the talk was about the windows10 security:

Hunting Android Malware: A novel runtime technique for identifying malicious applications (by Christopher Leroy)

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”.

Exploits in Wetware (by Robert Sell)

This was also a talk about social engineering. From my point of view it does not bring new things comparing to the talk “Social engineering for penetration testers” from previous day.

Dissecting Of Non-Malicious Artifacts: One IP At A Time (by Ido Naor and Dani Goland)

The talk was about how can find very valuable information that is uploaded (accidentally or not) on different public cloud services.

 

 

 

(My) OWASP Belgium Chapter meeting notes

These are my notes of OWASP Belgium Chapter meeting of 17th of September.

Docker Threat Modeling and Top 10 (by Dirk Wetter)

Docker not really new:

  • FreeBSD – Jails year 2000
  • Solaris : Zones/Container year 2004

Threat Vectors on the (Docker) containers:

  1. Application escape
  2. Orchestration tool
  3. Other containers
  4. Platform host; especially after the discovery of vulnerabilities into microprocessors (Spectre, Foreshadow).
  5. Network: not properly secured network.
  6. Integrity and confidentiality of OS images.

Top 10 Docker security

  1. Docker insecure default running code as privileged user
    • workaround : remap user namespaces user_namespaces (7)
  2. Patch management
    • Host
    • Container Orchestration
    • OS Images
  3. Network separation and firewalling
    • use basic DMZ techniques
    • allow only what is needed on the firewall level
    • (for external network connection) do not allow initiating outgoing TCP connections.
  4. Maintain security contexts
    • do not mix Development/Production images
    • do not mix Front-End and Back-End services
    • do not run arbitrary images.
  5. Secrets management
    • where to store keys, certificates, credentials
    • not easy to solved problem
  6. Resource protection
    • limit memory (--memory=), swap (memory-swap=), cpu usage (--cpu-*), --pids-limit xx
    • do not mount external disks if not necessary, if really necessary then mount it as r/o.
  7. Image integrity and origin
  8. Follow the immutable paradigm
    • run the container in read only mode: docker run --read-only... or docker run –v /hostdir:/containerdir:ro
  9. 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
  10. 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.
    • Docker leads the way with its default AppArmor profile.

Ship

  • Validate the integrity of the container.
    • ex: Docker Content Trust & Notary
    • Consume only trusted content for tagged Docker builds.
  • Validate security pre-conditions.
    • Allow or deny a container’s cluster admission.
    • Centralized interfaces and validation.

Run

  • Containers are managed through orchestration systems.
  • Management API – used to deploy, modify and kill services.
    • Frequently deployed without authentication or access control.
  • Authentication
    • Authenticate subjects (users and service accounts) to the cluster.
    • Avoid sharing service accounts across multiple services.
    • Subjects should only have access to the resources they need.
  • Secrets management
    • Safely inject secrets into containers at runtime.
    • Anti-patterns:
      • Hardcoded.
      • Environment variables.