BSides Knoxville 2019

In an age where data breaches and malware infections are quickly becoming the norm, we must prepare for Digital Forensics and Incident Response (DFIR). Most DFIR talks and advice discuss what to do once an incident has occurred. Instead, this talk provides Security Architects, System Administrators, SOC teams, and management new techniques and advice to supercharge their IR capabilities by preemptively collecting forensic evidence as a baseline.

The content provided in this presentation goes beyond the age-old advice of verbose logging and asset inventories. It will promote a cooperative relationship between DFIR and the rest of the Blue Team. We will kick this presentation off with a discussion about Threat Hunting versus Forensics. During this presentation, blue teamers and management will be armed with actionable advice as to how to pre-emptively capture artifacts as baselines BEFORE anything ever happens and the actions to take WHEN something happens.

The Microsoft Office 365 suite contains many applications that can help organizations do some amazing things. But every once in a while, a user account will get compromised by an attacker. You can (and should) reset the user password, but is that enough? If that was all you needed to do, this would be a VERY short session. Regaining control of a user account does take a little more effort to ensure the attacker isn't just temporarily inconvenienced.

How do you extract the attackers and get them off your SaaS?

I'll walk you through some sneaky areas where attacker can retain access, and show you how to shut it down.

I can almost guarantee I'll show you some attack methods you haven't thought of before!

Projects like ZMap and Masscan have made scans of the entire IPv4 Internet very practical and have resulted in interesting insights into the state of the Internet. However, with growing adoption of IPv6, very little has been done in the way of IPv6 scans because exhaustive scans cannot be performed due to the size of the address space.

Motivated by this, a number of projects have came up with different ideas to unmask in-use IPv6 addresses. Shodan organization had set up IPv6 network time protocol servers so random clients would connect to them and reveal their IPv6 address which Shodan would then scan and make accessible in their database. IPv6.farm project has abused certain properties of DNS and DNSSEC to reveal in-use IPv6 addresses and presented their analysis in a number of papers (https://ipv6.farm/).

In 2015 Martin Zeiser and I presented a joint talk about client-side UPnP attacks at PacSec. Martin talked about interesting UPnP scans he was exploring at the time and I covered memory corruption vulnerability that we had found previously. Recalling this, we had an idea to use UPnP to unmask IPv6 addresses.

By sending a specific UPnP packet, we can have the target connect back to an URL of our choosing. Supplying an IPv6 URL and sending the packet to an IPv4 address of a dual-stack host would make it connect back to us over IPv6 thus divulging it's IPv6 address. By doing this over the whole IPv4 address space we would get back a sizable amount dual-stack UPnP hosts that would reveal their IPv6 address to us.

Further analyzing the gathered data revealed some interesting facts. Doing this across all of IPv4 address space results in IPv4-IPv6 address pairs, which lets us perform interesting additional scans. This revealed a number of hosts with interesting firewall discrepancies between IPv4 and IPv6 side. Also, with UPnP usually being used for local network discovery, the dataset consists of mostly end consumer devices/hosts, IoT devices and similar which is in contrast to the types of hosts scanned in IPv6.farm and Shodan NTP projects giving us a glimpse into this previously unexplored category of targets.

In this presentation we would talk about the IPv6 scanning problem and previous research as motivating examples, we would present our methodology for conducting the initial IPv6 address discovery and subsequent scanning and present our analysis and interesting findings: the unexpected filtering, discrepancies between actual and reported IPv4/IPv6 pairs, cases of lack of filtering on IPv6 side where IPv4 is properly firewalled as well as some facts about the dynamic nature of hosts in this category (usage of teredo, 6to4, ipv6 mac mappings...).

Scenario: You’ve been put in charge of InfoSec for a business with no existing security posture and the executive team thinks that Antivirus and Firewall is a sufficient InfoSec budget. They expect results in one year.

At the end of this talk you will have a roadmap for the first year of implementing a security program, with some understanding of what those who have come before you have done. I hope to explain my mistakes so that you don’t have to make mine, you can make your own.

Our ears are the original nexus of information security. The environments we're in are constantly streaming valuable information to us. All we have to do is listen properly. "Let he who has ears" and all that. Join me as we explore the fascinating world of audio security. We'll cover:

• some meta information about audio
• the basics of digital signal processing
• the fascinatingly complex world of determining what "silence" means
• modern machine learning approaches to sound event detection
• attacks on audio interfaces like Alexa

Emotet has been around for several years. For some it is considered "commodity" malware, while for others it is a real threat to their financial accounts or even their enterprise. Meanwhile it continues to evolve and present new and different threats.

My interest in Emotet as a threat sparked this year as I continued to see variants of it slip past security controls with mixed success and a wide variety of payloads.

In this talk we will explore the origins of Emotet and how it has evolved. We will explore the TTPs associated with it and motivations of those behind it. We will discuss various methods of defense against this attack and responses for systems that have been compromised. Finally, we will speculate about the types of future attacks we might see from and related to Emotet

As the targets in many penetration tests and red team activities as well as being the focus of much of the active research being performed in the InfoSec arena, Windows takes center stage. However, we are not going to be talking about Windows; we are here to discuss Unix (and Unix like OSes). While these systems can and do contain some of the most critical information on many networks, we feel they do not get enough time in the spotlight. So, if you want to learn a bit more about Unix and what you can do to/with it as a pentester, then please stop by and have a listen.

Semantically related objects often get grouped together in memory, and it is about time we take advantage of this in developing software hardening measures.  Types can be naturally assigned to regions of memory in a flexible manner.  Such types can form the basis of a practical and intelligible access control policy. This observation allowed me to retroactively harden an instance of the U-Boot bootloader, to model the bootloader's intentions and build an access control policy that mediated its behavior.

Typed region-based hardening measures can be applied to other kinds of software to not only protect against low-level memory vulnerabilities but also to help protect and address high-level logic-based attacks (i.e., instances of weird machines).

Modern vehicles can be incredibly vulnerable to cyber exploitation. Researchers across the world have demonstrated scary manipulations such as remote control of an unaltered vehicle, unsigned code execution, and the ability to interfere with cars in traffic. Largely, this problem stems from the inherently vulnerable networks which exists on automobiles manufactured after 2008--Controller Area Networks (CANs).

Some security implications of a CAN are that it is a broadcast bus network, allowing all nodes to receive messages with no explicit addressing, and it has no way to authenticate and identify nodes on the network. Therefore, it is extremely straightforward to induce physical changes on an automobile with potentially dangerous consequences.

When CAN was mandated in 2008, it was not particularly concerning that one could develop after-market solutions using the intra-vehicular network. After all, CAN requires proprietary tools (a CAN Controller and CAN Transceiver) along with the knowledge required to program and interface these tools. In recent years, however, automotive CANs have been a topic of interest for homebrew hackers and security professionals. This has been facilitated by the widespread use of inexpensive single-board computers, such as Raspberry Pis and Arduinos.

This presentation will detail the technical aspects of CAN. Particularly, we will discuss messaging at the bit level, arbitration and error handling, common CAN tools and libraries, and network patterns which exist across many makes/models. By the conclusion, attendees will be equipped to build their own automotive interfaces and begin engineering their own after-market solutions.

In this talk, I put together two things we don’t often associate with cybersecurity: The League of Legends game and human psychology.

As an avid gamer, I often saw parallels between the tactics used to win games like League of Legends and the mentality that guides human behavior in general. Thus, when the subject of security awareness and end-users came up, I began to think about how we could address cybersecurity challenges in ways similar to how challenges are addressed in a game.

This realization allowed me to connect League of Legends, human behavior, and cybersecurity in a way that could make us think twice about how we approach the “end-user problem”.

Suppose that you have a small radio, such as a wireless sensor or a digital walkie talkie, and you'd like to talk to it. This action packed talk will show you how to rip the configuration from the airwaves, the firmware, or the SPI bus of an embedded radio, then write them into your own hardware to receive and transmit packets. Learn how to extract keys when crypto is good, or how to efficiently crack it when it's not. Learn how to track down the interesting parts of firmware for patching, and how to rewrite the firmware from scratch and a few notes. These examples are taken from real hardware.

My team loves working on legacy code projects. It's all that we do. That's why a friend of mine reached out to us for some help. _x000D_
_x000D_
His startup was building out a universal API across a very fragmented industry with little to no interoperability or standards. Up until now, integrating with the systems in that industry had been pretty easy, because the companies that built them were willing to help. _x000D_
_x000D_
But now he'd found one that wasn't willing to help. There was no obvious API for getting data out of the legacy application so that it could be exposed via his company's API. A big client for his company was riding on his ability to be able to pull this off. He remembered how much I loved a challenge and how much my team loved legacy code, so he figured we were his best shot._x000D_
_x000D_
The goal was to be able to read from the application's database. _x000D_
_x000D_
In this talk, I'll cover _x000D_
* the different approaches that we took_x000D_
* the one we really wanted to try because we thought it would be fun_x000D_
* the approaches that we needed to try before we could attempt the fun one_x000D_
* the excitement that we felt while working on it_x000D_
* the grind toward completion once the big technical hurdle was crossed_x000D_
* the sense of achievement when we got a read-only solution built_x000D_
* the hope that we'd get the green light to start working on a read-write solution_x000D_
* the disappointment when the plug got pulled and we weren't authorized to proceed any further_x000D_
_x000D_
It was a fun journey, and I'd love to be able to share it.

Beyond the Buzzwords: How Security Can Use Marketing Concepts to Prosper
Given today’s cybersecurity shortage and the hype that accompanies it (“1.5 million jobs will be unfilled by 2020! No, It’s 3 million!”), it would be easy to conclude that learning or keeping up with networking, coding, incident response, threat hunting, and the like is the critical factor for finding and retaining security employment. While it’s certainly true that cybersecurity practitioners will need technical skills—it’s a technical field, after all—there is another aspect to succeeding in the field in the future.
Marketing.
Yes, “marketing” is a dirty word to most security practitioners. Everyone who hears the term immediately conjures up images of vendor marketing departments — the people scorned by many hackers for not having an adequate level of technical knowledge, or the team that relies on catchy buzzwords to sell a product rather than focusing on actual features, capabilities, and technical differentiators. Though marketing people have been known to go overboard on jargon, taking a page out of marketing playbooks can help security practitioners ensure they are meeting the demands of the modern security team, one that understands and is aligned with business needs (vs. one focused on blocking and tackling security threats), and one that enables organizations to move faster with requisite levels of cybersecurity protection.
What will people learn from this talk:
Marketing isn’t about buzzwords (when done right); it’s about conveying information accurately, in a way that resonates with your audience.
Why is this important for security employment? Most non-security people don’t know the minute technical details about how security works and they don’t care. They don’t need to care (just like security pros don’t need to care about the nuances of building web traffic or conversion rates). People do care, however, if they can’t access their stuff. Executives care a lot when the company is distracted from making money. Cyber attacks, breaches, data loss all contribute to distractions from that goal. 


Ultimately, this talk will share marketing concepts you can easily apply to your security program and to ensuring future job security.

Over the years, Texas Instruments graphing calculators have evolved from simple programmable devices with fixed ROMs to complex, USB- and wifi-capable Flash upgradeable computers. Because of their widespread adoption for use in classrooms, Texas Instruments is forced to implement security measures that prevent tampering of the calculator's operating system, storage and usage of notes during tests, temporarily crippling or disabling built-in features, and even outright code execution.

For well over a decade, I have implemented and released exploits that enable writing to Flash memory, allow unsigned code execution, bypass teacher restrictions (which can be enabled by anyone, not just teachers), and open up the hardware to its full potential, even going so far as using it to jailbreak a PS3 or boot a desktop PC via USB flash drive simulation.

In this talk, I will provide a technical overview of the history of achieving and maintaining unsigned code execution on the various graphing calculator models Texas Instruments has released over many years, as well as a personal recollection on how the first Flash unlock exploits were created and evolved to keep up with TI's fixes, how the 512-bit RSA OS signing keys were factored and the legal fallout, and the current challenge to find and utilize new vulnerabilities for the latest models.

Where is the line between misconfiguration and vulnerability? Red team attacks generally succeed by exploiting well-worn paths, as the resources required to discover new zero-days tend to be more fruitfully spent elsewhere. But does this mean that red team coders don't get to write any interesting new exploits? Far from it!

In this talk, we will walk you through the process of developing a novel file format exploit and using it to root a public cloud service during a 2018 red team. This research, which the authors first presented at Derbycon 8.0, will be accompanied for the first time by the release of a new open source tool.

Did you know that we’re having Hacker Jeopardy? Email info@bsidesknoxville.com with your team of up to 4 contestants! We just need a team name and a list of people on your team.

Don’t know what Hacker Jeopardy is? There are many examples of it on YouTube, though our version will be notably ’cleaner’ than anything DEF CON puts on :)

Oak Ridge National Lab, in cooperation with six other National Labs, has now twice held a cyber security competition across the nation, involving 70 university teams, and 1000 volunteers. The most recent event was in December 2018. The competition expanded from one held at Argonne National Lab involving schools and resources local to the Chicago area. The Department of Energy now sponsors the competition and changed its name to CyberForce (tm) (cyberforcecompetition.com) in order to emphasize its goal of workforce development. A unique feature of this competition is each team receives a physical Industrial Control System that is part of what they have to defend. The remainder of their systems are in the cloud - the last two competitions have used Microsoft Azure. The Blue Teams are in the role of making sure their power plant remains operational in spite of attack by Red Team professionals. The hybrid of cloud and physical resources is part of the challenge the students face when competing in this competition. Another unique feature of the competition is the role of Green Teams who are non-specialists who come in on competition day, read the documentation, and operate the power plant. They do not have direct connection to the Blue Teams, except through whatever help desk system is specified and maintained by the Blue Teams. The teams have a month beforehand with their competition environment in order to prepare for the day of competition

This talk will describe the full competition environment and structure, the various ways that this competition helps with workforce development, datasets captured competition day, and the relationships between businesses, universities, military, and laboratories that are a part of this competition. In addition, for this B-Sides talk, we will describe the technical details behind the competition. Especially interesting to the audience will be:

• The role of the Red Team attackers. In the most recent competition the Red Teams operated as an inside threat.
• The technical details for how Azure was used to facilitate the hybrid structure of the competition.
• The preparation of the computer systems given to the students.
• The ICS devices and how SCADA protocols are implemented for the contest.
• Some overall story arcs of how vulnerabilities were built-in, found, and exploited.

The competition put the students into the scenario of being new employees in an unfamiliar environment, charged with supporting and protecting a vital business, using systems that they did not set up. This scenario describes what most security professionals face often in their careers.

The speakers are Jeff Nichols, Ph.D., Chris Craig, M.S., and Raymond Borges, M.S.. All are members of the National Security Sciences Directorate at Oak Ridge National Lab. Jeff is the lead at ORNL for the competition. Chris and Raymond led the Red Teams.