Hacking Major Swiss Software Companies (Multimillion CHF Companies)

Howdy folks, 0x90 here, your friendly neighborhood CISO and occasional bug bounty hunter. Over the past few months, I’ve been on a cyber-adventure through the world of Swiss software giants. And let me tell you, what I found lurking behind their pristine veneers was enough to make even the bravest digital forensics pro break a sweat.

The Shocking Discoveries
Let’s cut straight to the chase: many of these big players are committing some serious security faux pas. Imagine a fortress with the gates wide open—inviting, right? Here’s the gist of it:

Debug Logs Galore
First on the list: publicly accessible debug logs, especially on WordPress. These logs often spill the beans on internal file structures and API endpoints. Translation? Attackers can take one quick look and map out the entire site like they’re reading a blueprint.

Leftover Dev Modes
Next up, front-end frameworks left in their development modes (looking at you, Vue.js). That nifty dev tool that was supposed to stay local? It’s now giving away object environments in production, handing attackers a roadmap of your web app’s architecture and in some cases even allowing manual auth state changes.

Password Laziness
I’ve seen password policies that only require three characters. Three! That’s basically the digital equivalent of a wet paper bag. If you think no one tries brute-forcing that, think again.

JavaScript + Frontend = Hacker Candy
Frontend apps stuffed with JavaScript that reveals how data flows to backend servers? Attackers can trace your steps, figure out your endpoints, and line up a shot before you even see them coming.

APIs Wide Open
Lastly, some APIs are practically rolling out the red carpet for unauthorized users. Weak authentication, stale tokens, or no token checks at all—these are surefire ways to invite hijacking or data leaks.

The Hidden Dangers of Java Decompilation
Java’s platform independence is a double-edged sword. On the one hand, it lets you write once and run anywhere. On the other, it makes your code far too accessible when decompiled. Tools like JD-GUI or CFR can transform compiled bytecode back into readable source code almost effortlessly. And what happens when that source code contains hardcoded encryption or decryption keys? Well, you’ve essentially left your digital front door wide open.

The Bounty Debacle: 5 Reports, 5 Giants, 200+ Pages
After uncovering these issues, I did what any responsible security researcher would do—I reported them. Over the past months, I’ve submitted five extensive reports to five different major enterprises, totaling over 200 pages of detailed vulnerability findings. And what was the response?
  • Two companies rewarded bounties (small ones, mind you).
  • Three companies gave the classic "We are aware and working on it" response.
Now, I’m all for responsible disclosure, but let’s be real—some of these issues could be patched in under 24 hours. Yet, the "we are working on it" excuse drags on for weeks, months, or even longer. It’s almost as if they’re hoping it’ll just go away on its own. Spoiler: It won’t.

Why This Keeps Happening
So, why are these multi-million-dollar software teams leaving the barn doors unlocked? It usually boils down to the classic game of “Not my problem.” Developers add security features but don’t enforce them, sales teams have no clue about the risks (or choose not to freak out their clients), and end-users often ignore best practices in favor of convenience. Throw in some internal finger-pointing, and you’ve got a breeding ground for data disasters.

And as for the bug bounty programs? Let’s just say, if companies spent half as much on actual security fixes as they do on PR spin, the internet would be a much safer place.
 
Back
Top