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

How to create and customize a Docker image for Burp Suite Professional Edition

This ticket explains how to create and customize a Docker image for the Burp Suite Professional Edition. The main difference with a creation of an image for the Burp Suite Free Edition is that you will need to register a valid license during the image creation.

    • Create a Dockerfile for the initial image. You will need to have the burpsuite_pro_Vx.y.z jar file; the jar should be in the bin folder that is on the same level as the Dockerfile. The Docker file looks like this:
    FROM openjdk:8u121-jre-alpine
    RUN apk --update add openssl ca-certificates ttf-dejavu && \
        rm -f /var/cache/apk/* && \
        mkdir -p /opt/burp /work && \ 
        adduser -D -s /bin/sh user user && \
        chown -R user /work

    ADD bin/* /opt/burp/
    RUN chown -R user /home/user/.*
    USER user
    WORKDIR /work
    EXPOSE 8080
  • Build the image:
    docker build -t burppro .
  • Run the image. It will be needed to run the Burp in the UI mode in order to register the license and (eventually) to customize the application (like installing extensions); unfortunately it is not possible to install extensions directly from the command line, so you will have to do it manually.
    docker run -ti \
      -e DISPLAY=$DISPLAY \
      -v /tmp/.X11-unix:/tmp/.X11-unix\
    burppro \
       java -jar /opt/burp/burpsuite_pro.jar
  • Once you’ve finished the customization, commit the new image in order to save the changes made on the initial image.
    docker commit <burppro_container_id> burppro_with_license_with_extension
  • Run the new image (in headless mode).
    docker run -p8080:8080 -ti \
    burppro_with_license_with_extension \
      java -jar -Djava.awt.headless=true /opt/burp/burpsuite_pro.jar

OWASP Security Knowledge Framework – the missing tutorial

skf-miniA few months  ago (during BeneLux OWASP Days 2016) I’ve seen a presentation of the OWASP Security Knowledge Framework. I found the presentation very interesting so I decided to dig a little bit to learn more about OWASP Security Knowledge Framework a.k.a SKF. I found the official documentation a little bit sparse so after playing with SKF a few days I decided to write on paper what I have learned.

Introduction

SKF is a tools that helps the software developers to ease the integration of security into SDLC (Software Development Lifecycle). For the end-user, SKF can be used as web application which can be accessed after creating an account.

SKF web site have deployed a demo application, that can be accessed here SKF demo site (the username is admin and the password is test-skf. (be aware that the site content is scratched every hour).

Installation

If you want to install SKF in-house, then you can follow the installation instructions (installation instructions under Ubuntu, MacOS and Windows are provided and also Chef and AWS). Another installation option would be to use Docker; in this case you could use the following Docker image that I created. (the image is based on Ubuntu 14.04 64 bits version).

Once the application is running (in the case of Ubuntu manual installation it will run over HTTPS on port 5443) you have to unlock the default admin account (I will speak later about user and group management in SKF). This procedure is described in First run page; what is important to note is that on the “first login” page you must use the pincode 1234 and the email [email protected] (these values are hard-coded).

SKF Big picture

The SKF is articulated around 4 security topics:

  • (security) knowledge base.
  • (security) code examples.
  • introduction of the security checklists for applications using the OWASP Application Security Verification Standard (ASVS) project.
  • introduction of the security requirements in the SDLC.

The knowledge base

The SKF knowledge base contains the descriptions and the solutions to over 200 vulnerabilities, attacks and security best practices: API responses security headers, Access Control patterns, Command injection and many, many more.

The code examples

SKF also contains a few dozens of code examples of best practices to write secure code; the examples are written in PHP and C# languages.

Security Checklists

SKF offers also the possibility to create projects and users, the idea being that the users can be part of one or more projects and each project can contains a list of security checklists and security requirements.

The admin user (the user that have been  unlocked after the installation) can create projects and users. For the user creation, a unique pincode is generated and the new user need to use this pincode the first time when he connects to the application.

The security checklists are representing a way to testing web application technical security controls and also provides developers with a list of requirements for secure development. SKF uses the OWASP Application Security Verification Standard (ASVS) checklists. SKF shows the checklists in a very user friendly way and the checklists can be customized in case your project have special security requirements. It is possible to add as many checklists as wanted end every checklists can be downloaded as a .docx document.

The OWASP ASVS contains the following verification criteria:

  • Architecture, design ant threat modeling.
  • Authentication.
  • Session management.
  • Access control.
  • Malicious input handling.
  • Cryptography at rest.
  • Error handling and logging.
  • Data protection.
  • Communications.
  • HTTP security configuration.
  • Malicious controls.
  • Business logic.
  • Files and resources.
  • Mobile
  • Web services
  • Configuration

Security requirements

For me, the most interesting feature of the SFK is the ability to create and attach to each project multiple items called functions. The basic idea is that the user can choose from a list of security requirements depending of the feature that should be implemented; for example you if for implementing a new feature, an eternal library will be used then you can add as security requirement the “third party software” function.  Each security requirement contains a description and a solution about how to be handled.

The OWASP SKF contains the following security requirements:

  1. third party software
  2. sub-domains
  3. Access controls or Login systems
  4. User registration
  5. Form
  6. Sessions
  7. Password forget functions
  8. Forward or redirect
  9. GET variables or parameters
  10. XML files
  11. File Download
  12. File upload
  13. Regular expressions
  14. Eval type functions
  15. Private user data
  16. System commands
  17.  SSI commands
  18. XSLT input and output
  19. HTTP headers
  20. LDAP commands
  21. User-input in HTML output
  22. X-Path
  23. File inclusion
  24. Path or Filename
  25. SQL commands

(My) Conclusion

What I like about OWASP SKF is that it tries to introduce the secure coding practices into the SDLC in a easy and customizable way; ideally you should use all the features of the SKF but it’s up to each team/project to choose how  SKF could help to have a more secure code.

On the negative side  I would have the following remarks:

  • the application looks unstable; very often I have “Internal server error” on my Docker instance.
  • the code examples for Java are in the “Coming Soon” status for the last (at least) 8 months; maybe should be removed to not set-up unreasonable expectations.
  • I (personally) do not appreciate the ergonomy of the user interface; the actions linked projects (project creation, results) are mixed with the user management actions (user and group creation) and with other actions which are independent of projects and groups (code examples and knowledge base).  As a new user I was very confused and I didn’t understood right away that the 4 SKF features can be used independently.