BruCON 0x0B

My name is Rob Fuller, I've been around a bit, not as long as some but longer than others. From the US military to government contracting, consulting, large companies, tiny startups and silicon valley behemoths, from podcasting to television, I've had a storied and humbling career in infosec. Let’s get past complaining about blinky lights and users. Let’s talk about what actually works and what doesn't.

5G raises the security bar a level above 4G. Although IMSI exposure is prevented in 5G, we found new vulnerabilities to attack devices and subscribers.

In this talk we expose a set of vulnerabilities in the 5G/4G protocols that are found in network operators equipment and also consumer devices such as phones, routers, latest IoT sensors, and even car modems. Our vulnerabilities affect several commercial applications and use cases that are active in 4G networks and are expected to take off in 5G networks.

We developed automated tools to exploit the exposed cellular information and share some of our research traces and data sets to the community. We demonstrate a new class of hijacking, bidding down and battery draining attacks using low cost hardware and software tools.

We did a rigorous testing worldwide to estimate the number of affected base stations and are surprised by the results. Finally our interactions with various vendors and standard bodies and easy fixes to prevent our attacks are discussed.

ISO/SAE 21434 "Road vehicles – Cybersecurity engineering"

The automotive industry is currently working with the ISO and SAE standardization bodies to make a standard for automotive cyber security, expected to be released in 2020. After all, simply putting sometimes numerous wireless connectivity devices (e.g., GSM/3G/LTE, bluetooth, tire pressure sensors, ...) into a vehicle has again and again turned out to be a playground for attackers, and can haunt both customers and manufacturers in the long run.

This talk will give an overview of the key elements in the draft, and how they play together to minimize the risk of getting pwned while driving 250 km/h on the Autobahn. I will focus on the technical mechanisms as the point-of-view, and how they are usually embodied in a modern car. This will include signed software updates, authenticated CAN bus messages and secure gateways, just to name a few.

The successful fusion of cloud native SIEM and AI is a watershed moment in cybersecurity that many are yet to fully grasp. For those organizations tainted by past on-premise SIEM experiences and burdened by promises unfulfilled, cloud SIEM ushers in the dream of real-time threat discovery and mitigation at a cost both the CFO and CISO find compelling.

Cloud SIEM is a watershed moment not because of the realization of its integrated technologies, but for the changes it will affect on operational security teams and risk management processes far into the future.
Being able to preemptively identify and categorize an attack in motion before it escalates, and being able to proactively disarm or neuter that attack before evolving into a viable threat, is well within the grasp of first-generation cloud SIEM. What happens next for cloud SIEM?

This session examines the role of “Threat Hunters” and security analysts when incident identification and response becomes just another API, how SecDevOps will embrace cloud SIEM and spearhead threat response, where and when AI will inevitably have to cede expertise to in-house experts, and how an ROI for enterprise security just landed on the CISO’s lap.

Almost everything about us – our handwriting, DNA, faces, voices, fingerprints, even our eyes – can be used to distinguish us from the seven billion other people on the planet. These physical identifiers can allow law enforcement to trace back real-world crimes to offenders, and enable biometric authentication mechanisms. However, such identifiers are often irrelevant when it comes to attempting to track or disrupt threat actors.

In this talk, I will discuss, explore, and explain identifiers which are unintentional, non-physical, and generated as a result of human behaviours and activities, but which can still be used to uniquely identify and/or track individual users in the digital realm. I call these identifiers "human side-channels", and will explore how they work; how they can be used for both attack and defence; and how they can be countered.

I'll examine three human side-channels in particular: forensic linguistics; behavioural signatures; and cultural references. I will start by exploring the theories underpinning these side-channels, which are rooted in personality psychology and the concepts of consistency and distinctiveness as a result of our unique experiences, training, and feedback. I'll then explore how they work; walk through case studies and examples/demos of using them practically in security contexts; and discuss how they could be practically applied to investigate and track threat actors, in situations ranging from hostile social media profiles to post-compromise exfiltration and privilege escalation.

I'll also examine the privacy implications of each technique, and how such characteristics – which are much harder to recognise, obfuscate, or spoof – could be used to erode privacy. I'll go into detail regarding possible countermeasures to disguise your own human side-channels, and I'll wrap up by outlining some ideas for future research in these areas.

Soc analysts face a tough job every day to keep their detection capabilities up with  latest vulnerabilities and threats.
What to start looking for? Where in the network? What about risk of False positives? How frustrating if we missed an attack!

It’s not just about catching the latest, though. For example Windows management instrumentation (WMI). It ’s built right into Windows for years and has become more and more prevalent to attackers. Many administrators and attacker’s love WMI.
Much can be found on its use, however very little seems to be documented on how to detect it on a network level. We gave it a shot.

In this talk, we will have a quick overview on Windows management instrumentation (WMI), our first naive approach to detect it’s usage, the challenges we faced, lessons learned and results.

Part of the results are custom IDS (snort) fingerprints, with some tweaking, could fit your environment. As next step we would like to share it with you. So let’s improve together!

MITRE ATT&CK is quickly gaining traction and is becoming an important standard to use to assess the overall cyber security posture of an organization. Tools like ATT&CK Navigator and Caldera facilitate corporate adoption and allow for a holistic overview on attack techniques and how organizations are preventing and detecting them. Furthermore, many vendors, technologies and open-source initiatives are aligning with ATT&CK. Some more information on Caldera from the official documentation (https://github.com/mitre/caldera):

"CALDERA is an automated adversary emulation system that performs post-compromise adversarial behaviour within Windows Enterprise networks. It generates plans during operation using a planning system and a pre-configured adversary model based on the Adversarial Tactics, Techniques & Common Knowledge (ATT&CK™) project. These features allow CALDERA to dynamically operate over a set of systems using variable behaviour, which better represents how human adversaries perform operations than systems that follow prescribed sequences of actions."

MITRE recently released Caldera 2.0 (end of April 2019), which includes a larger focus on "extendibility". During this talk, we will leverage these features for maximum effect. We will highlight some interesting improvement opportunities in Caldera and we will focus on how we developed additional plugins & features. To make this a bit more concrete:

-How can we improve Caldera's reporting engine? (It's currently not possible to get an easy ATT&CK coverage report / deliverable out of the tool). This is of great use if we want to increase usability of the tool and ATT&CK overall!
-How can we build additional plugins for MITRE Caldera to increase the ATT&CK coverage of the tool?
-How can we adapt Caldera to work around common security controls in place at organizations (e.g. Windows 10 security features such as ExploitGuard and AMSI, which hinder Caldera's PowerShell scripting).

This talk will arm infosec professionals with the required skills to further extend their adversary emulation options without breaking the bank for a commercial tool! As our main focus is to increase Caldera adoption and help the community, we will also publicly release developed plugins!

We will go into the nitty-gritty details of our development efforts and will also include several technical demo's that will help transfer knowledge to the audience and encourage their own development efforts!

Note that this is currently work-in-progress, thus the paper that was added to this submission covers what we set out to do, but not the full result. It is in fact the internal NVISO R&D charter that was approved to start our development activities.

It is worth mentioning that the task set out is feasible and we have already successfully adapted our own internal Caldera with additional functionality (e.g. the AMSI bypass was implemented). We are now working on further optimising, stabilising and documenting our work!

We will be able to provide additional details on our results and status around summer time.

It takes a village... is a discussion about the challenges we face building security teams and strategies to alleviate our hiring bottlenecks. In a field riddled with unconscious bias, the community must work together to explore alternative recruiting strategies, expand hunting grounds for talent, and actively seek out folks with varied backgrounds and experiences who bring fresh perspectives to our projects and teams. Kimber will discuss mentorship programs and how to retain talent through professional development. She'll also provide some tips for jobseekers who've had a non-traditional path to security and ways to improve visibility and marketability to recruiters and potential employers. Whether searching for talent or seeking new opportunities, the landscape is rapidly changing and the security industry needs new approaches to recruiting and hiring if we're going to Secure All The Things™. 

Bluetooth Low energy version 5 has been published in late 2016, but we still have
no sniffer supporting this specific version (and not that much compatible devices
as well). The problem is this new version introduces a new channel hopping algorithm
that renders previous sniffing tools useless as devices can no longer be attacked
and connections analyzed. This new algorithm is based on a brand new pseudo-random
number generator (PRNG) to provide better collision avoidance while kicking out
all of our good old sniffing tools.

Unless some random hacker manages to break this not-that-strong PRNG and upgrades
his BLE sniffing tool to support this algorithm ;). In this talk, we will explain
why this PRNG is vulnerable and how it can be easily defeated to sniff and jam
communications between two BLE 5 devices. A new version of BtleJack will be
released during this talk, providing an efficient way to sniff BLE 5 connections
to our fellow IoT hacker family.

Recently we discovered weaknesses in the Dragonfly handshake of WPA3. But how serious are these issues in practice? In this presentation we will explain the attacks we discovered, and discuss whether they pose a practical risk or not.

In our research, we analysed the security of WPA3. This certification aims to secure Wi-Fi networks, and provides several advantages over its predecessor WPA2, such as protection against offline dictionary attacks and forward secrecy. Unfortunately, we show that WPA3 is affected by several design flaws. Most prominently, we show that WPA3's Dragonfly handshake is affected by password partitioning attacks. These attacks resemble dictionary attacks and allow an adversary to recover the password by abusing timing or cache-based side-channel leaks. Our side-channel attacks target the protocol's password encoding method. The resulting attacks are efficient and low cost: brute-forcing all 8-character lowercase password requires less than 125$ in Amazon EC2 instances. We also discuss backwards-compatible countermeasures against all attacks.

Although all attacks can be mitigated with software changes, our conclusion is that WPA3 does not meet the standards of a modern security protocol. Especially on devices with lightweight processors, vendors may not implement all the costly side-channel countermeasures. This would allow an adversary to perform dictionary attacks even when WPA3 is used.

Over the past few years we have seen organizations move a part of, or even their entire infrastructure to the cloud. With on-premise infrastructure it used to be clear that the security needed to be taken care of by the organization itself. With cloud infrastructure there is quite some confusion about who takes care of which security controls. This confusion has led to several painful incident response cases where we were called in only to discover we hardly had any data to work with. In general, we observe 3 common problems with incident response in the cloud:

1. Lack of knowledge about the different logging options within cloud environments. What is enabled by default and what is not?
2. Increased response times due to the lack of visibility and security knowledge about the cloud environments.
3. Lack of resources available to respond to the incidents, most organizations are not capable due to the limited amount of people and tools to respond timely.

This presentation consists of three key parts highlighting incident response challenges in the cloud, but also how we can purposely use what cloud providers offer us to improve our security operations.

The first section includes some key examples of what went wrong during incidents in cloud environments and lists some key challenges that we face as an incident response team to investigate security incidents in depth.

A second section in the presentation describes the overview of critical logs that are required to do incident response. These logs and settings are mapped on the 2 main cloud providers; Amazon AWS and Microsoft Azure. This will allow you to understand which logs are there by default and which logs should be activated for incident response and forensic investigations.

A 3rd section will introduce automated response, by explaining a use case were a system gets infected, server-less code will be executed to protect other systems and enable advanced analytics on the compromised system. This example is based on Microsoft Azure Security Center and applogic to enforce actions in case a specific alert is triggered.

We will present our project — Atomic Threat Coverage framework (https://github.com/krakow2600/atomic-threat-coverage), which allows to automatically generate actionable analytics, designed to combat threats (based on the MITRE ATT&CK adversary model) from Detection, Response, Mitigation and Simulation perspectives. This way Atomic Threat Coverage represents a Core of Security Operations Center, creating analytics database with all entities, mapped to all meaningful, actionable metrics, ready to use, ready to share and show to leadership, customers and colleagues.

There are plenty decent projects that provide analytics (or functionality) to counter cyberthreats (Sigma, Atomic Red Team, MITRE CAR). All of them have one weakness — they exist in the vacuum of their area. In reality everything is tightly connected: data for alerts doesn't come from nowhere, and generated alerts don't go nowhere. Data collection, security systems administration, threat detection, incident response etc are parts of bigger and more comprehensive process which requires close collaboration of various departments.

Sometimes problems of one function could be solved by methods of other function in a cheaper, simpler and more efficient way. Most of the tasks couldn't be solved by one function at all. Each function is based on abilities and quality of others. There is no efficient way to detect and respond to threats without proper data collection and enrichment. There is no efficient way to respond to threats without understanding of which technologies/systems/measures could be used to block specific threat. There is no reason to conduct penetration test or Red Team exercise without understanding of abilities of processes, systems and personal to combat cyber threats. All of these require tight collaboration and mutual understanding of multiple departments.

In practice there are difficulties in collaboration due to:

- Absence of common threat model/classification, common terminology and language to describe threats
- Absence common goals understanding
- Absence of simple and straightforward way to explain specific requirements
- Difference in competence level (from both depth and areas perspectives)

That's why we decided to create Atomic Threat Coverage — project which connects different functions/processes under unified Threat Centric methodology (Lockheed Martin Intelligence Driven Defense® aka MITRE Threat-based Security), threat model (MITRE ATT&CK) and provide security teams an efficient tool for collaboration on one main challenge — combating threats.

This talk will show the results of an internet-scale analysis of the security of AWS Cognito configurations. During this research it was possible to identify 2500 identity pools, which were used to gain access to more than 13000 S3 buckets (which are not publicly exposed), 1200 DynamoDB tables and 1500 Lambda functions.

The talk starts with an introduction to the AWS Cognito service and how it can be configured by the developers to give end-users direct access to AWS resources such as S3 and DynamoDB. Access is restricted by IAM policies which are under the developer's control and, in many cases, do not follow the least privilege principle.

The configuration weakness is first explained step by step for a specific AWS account and Cognito identity pool using a series of demos, the same concepts are then automated to perform an internet-scale analysis of AWS Cognito configurations.

Because Cognito identity pool IDs are UUID4 it was necessary to download thousands of APKs from the Google Play store, decompile them and extract the identifiers. Other sources such as Common Crawl were also used to identify valid identifiers. The tools used to perform these tasks will be made public.

Each Cognito identity pool that was configured with an unauthenticated role was analyzed using an in-depth permission brute-force tool that identifies potential breaches to least privilege principle.

The talk ends with recommendations for developers that want to configure the service in a secure manner, and an analysis of potential reasons for this widespread issue such as poor documentation and examples on AWS site

We will be bringing our combined decades of experience to teach the most common and effective physical security bypasses we use to enter commercial buildings and combine every technique with a war story. The last ~20m will just be our most enthralling stories from physical security engagements we've performed including some hilarious failures and how we social-engineered our way out of them.