The world is continuously evolving and many things become outdated. Cryptography is no different. While strong crypto should always be used, in time this strong crypto becomes weak due to advancements in the cryptoanalysis research and simply constant improvements of the cost and availability of compute resources.
When strong crypto becomes weak, all related software needs to be updated. But this can be a challenge, as more often than not, there are cases where a particular piece of software is either unmaintained or proprietary, and the software vendor is not cooperative enough to make this change. And what’s more, this piece of software cannot be easily replaced, for a number of reasons.

While there is no perfect go-to solution for every unique case, there may be a way for old/proprietary/unmaintained software based on OpenSSL to be fixed. OpenSSL has a pluggable extensible architecture called “engines”, which allows for the addition or replacement of cryptographic algorithm implementations without having to completely recompile the whole thing. However, the ability to use this functionality requires support from the linked application—the application itself needs additional code to hotswap OpenSSL engines—which most applications lack.

Luckily, to fix such applications, dynamic linker code preloading can be used—a feature supported by most modern operating systems. This talk walks through a hypothetical scenario in which a proprietary tool based on OpenSSL using weak cryptography needs to be fixed.

My name is Onix. I’m mostly made out of C++. My whole life is indexing for fast searching purposes. I do it so well, Adobe decided to adopt me back in 2003. I was having a great time with my new parents. I did what I’m supposed to do for one of their products, indexing for fast searching purposes in Adobe Reader. For 15 years I stayed under cover. No one knew about me, or what I do.

I was happy. I did what I had to do without raising any flags. Until one day…

A human who works at an organization known as Trend Micro’s Zero Day Initiative (ZDI) decided to take a closer look at me. He started analyzing all my indexing and fast searching functionalities and examining my innermost details. Something drew him to me…and he saw that I was not up-to-date. He kept looking, and he started pointing out my defects. He told my parents. They were not happy. They went back to my biological parents. They were not happy either. They tried to correct my defects…once… twice… but, no dice… And those mean people at the ZDI started giving me Pokémon names.

Throughout this presentation, I will talk about how I – and all my flaws – went undetected for 15 years. I will also talk about the defects that were found in my code along with the final decision taken by my adopted parents… my complete removal from Adobe Reader.

Those ZDI guys sure know to ruin a good time.

Agenda:

• Introduction
• Overview
o Lextek, Onix, and Adobe
• Adobe Reader/Acrobat Architecture
• Indexing
o Potential Indexing Attack Surface
 Catalog Plugin
 Search Plugin
• Fuzzing the Indexing API
o Writing a wrapper
 Public documentation
o WinAFL
• Vulnerability Case studies
o Catalog Vulnerabilities
o Indexing Core API Vulnerabilities
• Patching Notes
• Conclusion

Starting as a developer’s best friend, the Android Debug Bridge has turned into a security nightmare as time passed. While having an open port available for debugging over the internet sounds great, forgetting to turn off that service in production environment can spell big trouble for you or even your customers. My analysis will be of the protocol, the worms abusing it and how I discovered it all after putting my freshly built honeypot up.

The Android Debug Bridge protocol was initially designed for accessing various critical services of an Android device over USB. However, it also got encapsulated over TCP/IP recently, opening up port 5555 for a remote debugger to attach itself. From a security standpoint however, no improvements have been made, and a remote attacker can freely connect and exploit a device over the air. This is why I started developing a low interaction honeypot to catch this kind of attacks following a surge in hits on that specific port in our sensors.
Shortly after, I opensourced the project on GitHub. This led in a huge surge of honeypots being open by fellow security researchers, and thus awareness about this vulnerability significantly increased. After also publishing a blogpost about one of the new threats that I found, Trinity (p2p bot that spread a miner), the amount of vulnerable devices dropped by 50%, from more than 44000 to around 22000.
In the first part of the presentation I’ll be discussing the development procedure for the honeypot from the ground up as well as dissecting the ADB protocol in order to enable researchers to more easily implement their own honeypots.
The second part of the talk will be focused on exploring various strands of malware that have started hitting the honeypot in the last months, some that are even quite hilarious. From apologetic miners to aggressive peer to peer botnets, I’ll be showcasing the whole ecosystem of ADB worms that have circulated around the internet.

Enabling two-factor authentication for any online account is a necessity these days. Most common phishing attacks aim to steal login credentials, which are often not enough to provide attackers full access to targeted accounts. Since most attackers are unable to get hold of external authentication devices, multi-factor authentication (MFA) is widely proclaimed to be a silver bullet against all phishing attempts. I will challenge that thought and try to prove otherwise, while demonstrating the Evilginx phishing framework.

During the talk you will see how an attacker, armed with right tools, can perform a successful phishing attack on an account with 2FA enabled. Attack will result in full account takeover, despite the additional security measures.

I will also explain how websites and end-users can protect themselves from this new strain of phishing attacks.

In this talk we will review several ways that avoids a Gatekeeper check. According to Apple these are by design, and not bypasses, still plenty of way to execute code on a macOS system. We will also see how the new macOS Catalina changes these.

History repeats itself. All the time. If we learn the lessons from the past and be mindful of what has already happened within the science of hacking, we can move forward, spending time and energy on creating new technology and techniques, and advancing the field. But we must never forget the instructive lessons of the past.

Our hacking journey will start with blue and red boxes and bypassing the “one phone call” restriction. More than 50 years later you can hack smart vending machines with similar techniques. Technology may have evolved, but hacking concepts remain the same.

Bulletin Board Systems were the first places to share information about hacking. But they weren’t merely the place to share information – they were themselves the target of hacking. A ZIP vulnerability was widely exploited to hack BBSs. In 2018 the same hack was reinvented and overhyped.

The concepts of the ancient +++ath0 modem hack will be covered.

The Morris worm from 1988 was as sophisticated as worms like NotPetya from 2017.

Besides old school hacking, I will cover topics like Gopher, Usenet, IRC, Fluxay and ezines.

You can learn how to pwn a misconfigured Windows 95 and achieve interactive remote code execution on it. A Metasploit module will be released so that you can pwn Win95 during your red teaming exercises.

On Windows systems, users can be given special privileges. Some of these, if appropriately abused can lead to elevation of privileges to become SYSTEM.

In this talk, I will explain what the privileges and tokens are, how to get them, and based on their characteristics, identify some possible paths for Privilege Escalation via “Windows Privilege abusing” & “Token manipulation” .

Particular attention will be devoted to the privileges “SeImpersonate” and “SeAssignPrimary” which, combined with the “Rotten Potato” exploit and our subsequent research, the “Juicy Potato”, have proved to be “Golden Privilege”

While to the rest of the world social media are friendly platforms of communication and sharing, for the fellow OSINT analysts, hackers, social engineers and attackers, they are targeting and information harvesting platforms. Undoubtedly, online presence is important to all of us. But despite the benefits social networking can create, a strong online presence can also create vulnerabilities.

This talk will demonstrate how one’s online presence on social media can attract social engineers to target them and victimize them to “open doors” through the organizational security. It will also discuss how social engineers and penetration testers can utilize social media for their engagements in creative ways and to identify their pretexts.

The talk covers the topic of information gathering through social media (a discipline called Social Media Intelligence, or SOCMINT, being a sub-division of OSINT) and explains how even seemingly innocent information can be used to manipulate and victimize targets. Case studies will be provided. A two-part demonstration is included on how a hacker’s mind works when harvesting information on social media; The first part includes real examples of posts that expose vulnerabilities, attract attackers and ultimately lead to security breaches. The second part includes a demonstration on how personal information provided online are gathered, categorized, analyzed and then used to craft an attack, as well as how one ends up revealing online more than he intends to.

On the workshop the participants learn the basics of Ethereum and we exploit common smart contract security flaws together.

The workshop has three parts:
– Introduction to Ethereum (blockchain, transactions, states, smart contrats, gas, nodes, mining)
– Introduction to common Ethereum based vulnerabilities (RPC, nodes, image fails, Solidity based vulnerabilities)
– Exploiting vulnerabilities together

The Workshop also provides hints for those who participate in the CCTF game. The idea of the workshop is born from the lack of Ethereum security trainings.

If you are familiar with K8s secrets, you know that these secrets are placed in etcd. When we say that we intend to bypass K8s security, we mean by not touching etcd at all. The problem with etcd is that when data is encrypted at rest, it is encrypted with a global key. That might be a problem in a multi-tenant cluster, where independent and unrelated users could potentially gain access to the secrets of others. Also, if you already have a security team that’s operating a certified Vault installation, they’re probably not going to be happy about placing an unencrypted secret in an intermediary location.

Our mutating admission webhook injects an executable into containers (in a non-intrusive way) inside Deployments/StatefulSets which can then request secrets from Vault through special environment variable definitions.