2.0 -//Pentabarf//Schedule//EN PUBLISH YNAKFT@@cfp.bsidesvienna.at -YNAKFT Melting the DNS Iceberg - Taking over your infrastructure Kaminsky style en en 20221119T103000 20221119T110000 0.03000

Melting the DNS Iceberg - Taking over your infrastructure Kaminsky style

1. Introduction, explanation of DNS cache poisoning, and the core problem of this research - The talk starts off with a short introduction and a brief refresher on DNS cache poisoning and its consequences. - As a transition from DNS cache poisoning and it’s consequences, I’ll give a short summary of my previous DNS research (https://sec-consult.com/blog/detail/forgot-password-taking-over-user-accounts-kaminsky-style/). This shows, how I identified DNS vulnerabilities in web applications and how this would’ve allowed me to take over user accounts via DNS cache poisoning. - Out of the 146 analyzed web applications, DNS resolvers of two web applications were especially insecure, since they allowed trivial Kaminsky attacks. The resolvers used by these two web applications were identified to be most likely closed (not directly accessible from the Internet). - This sparked the question about the security of closed DNS resolvers. 2. Analysis of closed DNS resolvers - Firstly, I’m showing how closed resolvers can be indirectly accessed from the Internet via various means and which method we picked to scan around 7000 domains on the Internet. - Furthermore, I’m showcasing the required open-source “DNS analysis server” (successor of https://github.com/The-Login/DNS-Reset-Checker). As well, I’m explaining the test process of how to find vulnerabilities in closed resolvers. - After that, we explore the first example of a vulnerable closed DNS resolver and combine it with a short detour to Kaminsky attacks. This ensures a general understanding of off-path DNS cache poisoning attacks and why the discovered resolver is vulnerable. - We then go into an in-depth analysis of how we can find all the systems/domains that are using the vulnerable closed resolver. This shows how thousands of domains are linked to vulnerable resolvers due to being managed by one hosting provider or ISP. Here I’m using a hosting provider for “cloud and security” as well as an e-mail provider as examples. - Then, I’ll reveal the results of an Internet scan of roughly 7000 domains. Even though “only” 25 DNS resolvers were found to be vulnerable, thousands of systems are affected. - I next explain the possible attack vectors to exploit systems using these vulnerable resolvers. This ranges from simple spam protection bypasses (spoofing SPF, DKIM and DMARC) to complete system takeovers. 3. Conclusion - In the conclusion of the talk I'll cover some key takeaways and why the DNS is still a hot topic! PUBLIC CONFIRMED Talk https://cfp.bsidesvienna.at/bsidesvienna-2022/talk/YNAKFT/ Urania Dachsaal Timo Longin PUBLISH GDZYEC@@cfp.bsidesvienna.at -GDZYEC Logrotten - "It's not a bug" en en 20221119T110500 20221119T113500 0.03000

Logrotten - "It's not a bug"

Logrotate is designed to ease administration of systems that generate large numbers of log files. It allows automatic rotation, compression, removal, and mailing of log files. Each log file may be handled daily, weekly, monthly, or when it grows too large. It also gives you a root shell. Logrotate supports different methods for creating new files. For example the directive “copy” makes a copy of the logfile and “create” creates a new empty logfile after rotating. If someone exchanges the log directory with a symbolic link just before creating the new logfile, logrotate will put the new file into a different directory. Such a scenario can be exploited if logrotate runs as user root and a low privileged user is in control of the path to the log directory. If this user exchanges the log directory with a symbolic link at the right time, logrotate will write the new file into the linked directory. After that the permissions of the created file will be adjusted and the attacker might have write access to that file. This talk explains the various scenarios where logrotate can be configured in dangerous ways. It will be explained which software packages that were prone to this kind of attack were found. Finally the current state of logrotate will be discussed. PUBLIC CONFIRMED Talk https://cfp.bsidesvienna.at/bsidesvienna-2022/talk/GDZYEC/ Urania Dachsaal Wolfgang Hotwagner PUBLISH MUWQKG@@cfp.bsidesvienna.at -MUWQKG Charlatans in InfoSec - from Kim to Jonathan en en 20221119T114000 20221119T124000 1.00000

Charlatans in InfoSec - from Kim to Jonathan

InfoSec as a community and as a profession has attracted a lot of charlatans. In this talk you will get an overview of InfoSec charlatans. Starting from famous people like Kim (DotCom) to less known but still funny characters like Jonathan Scott (aka jonathandata1) - you will meet them all. You'll also learn how to spot charlatans and why this is important - for the community and for people outside the community. You'll get a deep dive into the mindset of scammers - including common techniques they use and how to fend them off. All techniques presented will be demonstrated with examples. After this presentation, you will have all the tools you need to protect the community (and yourself) from scammers/fraudsters/charlatans. PUBLIC CONFIRMED Talk https://cfp.bsidesvienna.at/bsidesvienna-2022/talk/MUWQKG/ Urania Dachsaal Sebastian Bicchi PUBLISH EAKWZL@@cfp.bsidesvienna.at -EAKWZL No-Code Malware: Windows at Your Service en en 20221119T134000 20221119T144000 1.00000

No-Code Malware: Windows at Your Service

PUBLIC CONFIRMED Talk https://cfp.bsidesvienna.at/bsidesvienna-2022/talk/EAKWZL/ Urania Dachsaal Michael Bargury PUBLISH 9ALTGS@@cfp.bsidesvienna.at -9ALTGS Nothing To Hide: Privacy-Preserving Cryptographic Authentication In Practice en en 20221119T144500 20221119T151500 0.03000

Nothing To Hide: Privacy-Preserving Cryptographic Authentication In Practice

The problem and the reason I made the project is very nicely put forth by the famous cryptographer Matthew Green: https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/. The protocol I'm working with was very recently standardized by IETF (mid 2020) right here: https://datatracker.ietf.org/doc/html/draft-krawczyk-cfrg-opaque-06. The goal of this talk is to share the knowledge regarding this new protocol (namely, OPAQUE) and the field of zero-knowledge cryptography. The benefits for it in the terms of password authentication and privacy are tremendous and they're well studied. My contribution to the space will be a Go implementation of the protocol that can be used in any form, a backend, and a frontend JS SDK, as well as sharing a simplified explanation of the math behind it. The protocol, backend and frontend codes are open-sourced with a prototype. See here https://github.com/afjoseph/plissken. PUBLIC CONFIRMED Talk https://cfp.bsidesvienna.at/bsidesvienna-2022/talk/9ALTGS/ Urania Dachsaal Abdullah Joseph PUBLISH UR9EQT@@cfp.bsidesvienna.at -UR9EQT Hey You! Get off my Satellite! en en 20221119T152000 20221119T162000 1.00000

Hey You! Get off my Satellite!

PUBLIC CONFIRMED Talk https://cfp.bsidesvienna.at/bsidesvienna-2022/talk/UR9EQT/ Urania Dachsaal Paul Coggin PUBLISH 93FVM7@@cfp.bsidesvienna.at -93FVM7 Self-Labeling Electronic Shelf Labels en en 20221119T165000 20221119T173500 0.04500

Self-Labeling Electronic Shelf Labels

We took apart multiple ESL tags distributed by a chinese manufacturer. These tags are especially popular in China and consist of an e-ink display and an LED. The base station will be connected to the local LAN and will translate packets to a proprietary 433MHz GFSK modulated protocol. We reversed this protocol and found multiple security vulnerabilities. The protocol does not protect against replay attacks. Hence, the tags can always be reset to an older price by replaying the previously recorded frames. Furthermore, we are able to craft our own packets and correctly modulate them with a HackRF. Therefore, we can fully control the display of all tags in a store. The only information required is the tag ID which is printed on the top of the label or could be sniffed from previous tag transmissions. A GNURadio Sketch was developed to correctly receive all packets and to forward them to a UDP port. A Python program is listening on this port and analyzing all contents. In addition, the script can be used to easily reprogram any ESL tag. On top of that, a quick hardware security assessment was performed. We decapped the MCU of an E-Tag, which was only branded with the line "E-Tag M1". It turned out to be produced by STMicroelectronics and is most likely an STM8 microcontroller. All in all, this talk will lead through the teardown of an unknown RF device and showcase, how signals can be intercepted and analyzed with predefined GNURadio blocks and some custom Python code. PUBLIC CONFIRMED Talk https://cfp.bsidesvienna.at/bsidesvienna-2022/talk/93FVM7/ Urania Dachsaal Steffen Robertz PUBLISH PV7STU@@cfp.bsidesvienna.at -PV7STU Malware And Exfiltration : A Telegram Story en en 20221119T174000 20221119T181000 0.03000

Malware And Exfiltration : A Telegram Story

PUBLIC CONFIRMED Talk https://cfp.bsidesvienna.at/bsidesvienna-2022/talk/PV7STU/ Urania Dachsaal Godwin Attigah