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

 

 

 

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: