Black Alps is a two-day technical cybersecurity conference held in Yverdon-les-Bains, Switzerland. The conference is renewed for the quality of its signal track talks, its concluding Capture The Flag event, but also for the food served. Expect delicious lunches with local products, Swiss-made chocolate in the shape of the conference logo, and an amazing dinner of melted raclette cheese.

Food is definitely a good reason to attend Black Alps, but the conference also has the right amount of technical and community side discussions.

Black Alps 2024 was the sixth edition of the conference. It welcomed over 600 participants from Switzerland and abroad. The program committee did an amazing job of selecting the 16 talks from the 117 submissions and managing the lively breakout sessions. Here are just a few highlights from this edition.

This talk is a practical deep-dive to macOS applications safeguarding that  prevents malicious file access, or code injection among other things. Wojciech Regula explained the protection provided by SIP (System Integrity Protection), such as file system access restrictions or no debugging of Apple signed binaries, and reminded to never disable SIP! If you disable it, any application will be able to elevate its privileges to the root user.

He presented ways to abuse architectural designs of famous macOS password managers. While enumerating his discoveries, he engaged with the participants to decide whether his findings were security problems or useful features. For example, malicious MacPass plugins could be loaded and ultimately steal passwords. BitWarden can be exploited by loaded dynamic libraries, as the hardened runtime is not enforced for applications downloaded from the App Store.

Wojciech's takeaway message is that theory and practice are two different things. In theory, MacOS applications are isolated from each other. However, if you look closely enough, as he did in his research, you can find practical tricks that lead to vulnerabilities and password leaks.

As you may know, GitLab Personal Access Tokens (PAT) leak in various places such as source code. If a malicious actor finds them, they can impersonate the GitLab user and access their resources without any restrictions. There are solutions, such as short-lived or restricted tokens, but they don't fit all use cases.

This talk from GitLab presents their solution to provide sender-restricted PAT. For GitLab, there are two main goals: protecting users from leaked tokens and reducing the amount of money paid out in their bug bounty program. Leaked PATs account for 5% of all reports and 8% of all bounties paid so far. Again, some leaks happen in usual places: now and then, GitLab employees leak tokens in YouTube tutorial videos that they make to explain the platform.

This illustrates perfectly the goal of DPoP (Demonstrating Proof of Possession): viewing a token should not be enough to use it. GitLab used RFC9449 as its source of inspiration, but I did a different implementation.

In short, GitLab binds a user's SSH key to their PAT. Each time the PAT is used to authenticate against a REST endpoint, a signature is obtained using the glab command line tool. This is a really interesting solution to token leakage, but it also raises questions about SSH private key storage. As long as the key is not stored with the token, sender-constraining personal access tokens are a great solution. However, since the GitGuardian platform often detects developers' SSH private keys, I believe this solution should be deployed along with hardware security keys to enforce that private keys cannot be extracted and leaked.

This talk is a red team adventure that takes you from leaked or stolen GCP credentials to infrastructure compromise.

Shannon McHale ,shared how she uses the Google Cloud Platform Command Line Interface (GCP CLI) and the different ways to authenticate depending on the leaked credentials.

From her point of view, credentials can be found on on-premises hosts, code repositories, resource metadata or file shares such as Google Cloud Storage buckets. While not the norm, it is not uncommon to find service account keys in such buckets.

Finally, Shannon shared some tips for blue teams looking to defend their GCP infrastructure: get rid of service account keys, reduce session duration, apply Google Best Current Practices, and perform regular audits. In this regard, I think the GitGuardian platform could be of great help to Blue Teams by providing them with fast and accurate detection.

Black Alps 2024 was a great event. It provided the right balance between technical presentations and community discussions. Everything was recorded, and the videos should be available on YouTube by the end of the year.

I am looking forward to the next edition, which will take place on November 20 and 21, 2025.  If you can't wait to meet this friendly Swiss security crowd, you can attend the Black Alps 2025 BBQ in June 2025. I strongly encourage you to attend or submit a presentation to share and engage with the Black Alps community.

*** This is a Security Bloggers Network syndicated blog from GitGuardian Blog - Take Control of Your Secrets Security authored by Guillaume Valadon. Read the original post at: https://blog.gitguardian.com/black-alps-2024-highlights-from-switzerland-cybersecurity-ecosystem/