Each month, I take the time to collect my gym invoices. This process has changed over the years. Initially, it was done using a mobile app. Later on, it moved to a website. Using said website was simple: log in, navigate to the invoices page, and press download on the relevant invoice from the list.

Assuming that invoices are not generated by the website (due to a number of legal requirements), it fascinated me (on a small degree) that they had a list of my invoices. Certainly there was an external system which the website contacted to get:

1. an invoice list (given a user)
2. a specific invoice

Being curious, I looked at the page for a while and decided to take a look at the HTML. Each invoice element from the list had a custom data attribute with the invoice number, which was clearly what the frontend was using to do the download request.

So I wondered: what will happen if I increment this number by 1?

Initial Assessment

The issue was an authorization failure (an Insecure Direct Object Reference / IDOR) in the invoice download flow. The frontend exposed a numeric invoice identifier in a data attribute; by modifying that identifier and issuing the download request while authenticated, the server returned a different invoice that did not belong to my account.

The impact was big: the vulnerability could expose other users’ invoices and the personal data they contain (names, addresses, invoiced services, and ammounts). Fortunately, the exploitability was moderately low — the identifier was predictable (sequential numeric), but an attacker needed an authenticated account to retrieve other invoices. And having an account required either having access to someone else’s, or being a gym member.

Considering the relative gravity of the situation, I started looking into ways to report this in a responsible way. The gym we’re talking about, one of the biggest in Portugal, belongs to one of the biggest conglomerates in the country — with its very own CSIRT, and a Responsible Vulnerability Disclosure program in their web page. It seemed that getting in touch would be easy.

Finding the Right Contact

The conglomerate had a Responsible Vulnerability Disclosure program listed on their website. Said page explicitly asked for 90 before making the breach public. They also explained that they do not make any kind of retribution, or in other words, that the RVD program was not a bounty hunter program. Sad…

It also included instructions to encrypt communications using PGP for confidentiality. However, there was a problem: their public key fingerprint was listed on the page, but the key itself wasn’t available on any public keyserver.

I searched multiple keyservers using both the Key ID and the fingerprint, but found no results. This left me unable to encrypt my initial disclosure as they had instructed.

On July 7th, I sent an email to the RVD address requesting their PGP public key. However, I received no response.

Four days later, I resent the same email, CC’ing the DPO address. Still no answer.

It was only when I emailed the CSIRT on July 25th that I got a response. They explained that previously sent emails had been flagged as spam. Fortunately, they provided the RVD program’s PGP key, which I could now use to encrypt the reproduction steps for the vulnerability.

The Disclosure Process

I wrote a simple explanation of the issue. No examples, no steps to follow. Honestly, I’m not sure that was the best for them, but I was trying to reduce my liability for anything that could go wrong. I didn’t want to give them a step-by-step guide on how to exploit the vulnerability, but I also wanted to provide enough information for them to understand the issue and reproduce it. I then encrypted and signed it. I took the payload and put it in a new e-mail. In that same e-mail, I asked for two things which seemed appropriate at the moment:

1. “any form of acknowledgment or certificate for responsible disclosures”
2. “a small goodwill gesture like a discount on my gym subscription”

Unfortunately, none of these two small request have been answered until today.

Timeline

Response and Resolution

Once I managed to contact them, their response was professional enough. Thee cadence, however, was less than expectable. Confirmation of the vulnerability only took place on the 89th day, whereas their policy states that they would provide a vulnerability evalutaion and fix estimate within 7 days.

Alas, despite the technical issue having been resolved and verified, the requests for formal acknowledgment or a goodwill gesture remain unaddressed.

Lessons Learned

Technical and Ethical Takeaways

• Secure Communication Channels: This disclosure served as a practical introduction to using PGP. It highlighted that even when a company requests encrypted communication, the infrastructure (like public keyservers) may not always be maintained, requiring manual intervention. Also, the situation has not changed… which is a shame.
• Ethical Boundaries and Data Minimization: There is a strong temptation to test the full scale of an IDOR vulnerability. However, responsible disclosure requires strict adherence to data minimization, i.e., extracting only enough information to prove the flaw without compromising the privacy of other users.
• Managing Communication Expectations: The “black hole” effect, where a report is submitted but no feedback is provided for weeks, can be distressing. Despite understanding that it may be hard to stick to their timeline, they’re the ones who set it. And a message saying “We don’t have news (yet)” is better than no message at all.

Additional Considerations

• Persistence in Outreach: Standard reporting channels (like RVD aliases) can fail due to aggressive spam filters. Identifying alternative contacts, such as the CSIRT or the Data Protection Officer (DPO), may be important to ensure the report is seen.
• The Importance of a Timeline: Maintaining a meticulous log of every interaction can help do a retrospective. And making it public is my way of saying “I’m playing by the rules :)”.
• Vendor Complexity: Vulnerabilities in large organizations may involve third-party suppliers, like in this case. This adds layers of bureaucracy to the patching process, which kind of explains why fixes may take longer than the initial 90-day estimate… but still does not justify it.

Final Thoughts

I feel small. Such a big company, with such a big CSIRT, and I had to go through so much just to report a vulnerability. It makes me wonder how many other vulnerabilities are out there, unreported, because people don’t have the time, resources, or patience to navigate this complex landscape of responsible disclosure.

But I also feel slightly disappointed: they’re not rewarding me for my efforts. I understand that they don’t have to, but a little acknowledgment would go a long way in encouraging responsible disclosure in the future. It’s the kind of thing that could help shape career paths, or at least make someone feel appreciated for their contribution to security. Especially considering that there are no financial incentives involved, a simple certificate of acknowledgment, public mention or service perk/discount would be a nice gesture.

In the end, I live with the knowledge that I did it, they fixed it, and personal details of other users are now safe. And I have a story to tell.

Working remotely is not something new. While most professions are not viable to be done remotely, some are. Almost everything that is done with a computer can be done remotely.

Simple as this may sound, it wasn’t until the world was forced to minimize human contact that we witnessed remote work as a rule instead of an exception in jobs that can be done remotely. Other jobs were kept as before, terminated or suspended.

Fast-forward from 2020 to 2025 and what we can see is a number of complex ways companies have come up with in terms of rules and their enforcements. Here are a few I’ve seen thus far:

1. Fully remote:
   1. No offices, no regular IRL meetings of any kind.
   2. No offices, but regular IRL meetings (at least yearly).
   3. Office is available, people are free to show up as they wish.
2. Hybrid:
   1. People can go to the office/work from home as they wish (this is the same as 1.3 😅).
   2. People must go to the office at least x times a month.
   3. People must go to the office at least x times a week.
   4. People must go to the office at least x times a week — on fixed days.
3. Office:
   1. People must work from the office every day.

Then there are a few caveats, especially for hybrid scenarios:

1. You may be required to book a desk before showing up at the office.
2. You may be required to select office days based on your team’s choices.
3. When doing your onboarding, you may be required to go to the office more frequently, or even every day.
4. You may end up working in a pouf.

📝 I’ve also seen computer jobs that cannot be done remotely because you need to work with equipment (e.g. payment terminals) which cannot leave the office.

What I’ve experienced

I started working during COVID, and was not allowed to go to the office at that time. Eventually, we started with model 2.1 — or 1.3 model, whichever grouping you prefer.

I was one of the people that attended the office the most. Getting out of my home for work always feels refreshing. Moreover, being able to make my working hours flexible has allowed me to wake up early, drive to the office while avoiding significant traffic, and then leave the office early as well, again avoiding most of the traffic.

Some months ago, we changed to model 2.4. This shift, from being able to go to the office when we wanted to, to being required to be in the office on fixed week days, has brought some interesting changes to the office dynamics:

1. People that never showed up at the office started showing up

This one is obvious, but noteworthy. I’m not one to say if they’re happy or not. But they’re there!

2. People that used to go to the office more frequently ceased to do so

This one took me by surprise. When people were free to go to the office on any week day they wished to, they would go 2 or 3 times a week, or random days. But then as they became forced to attend on specific days, they limited their going to the office to the minimum required.

3. Weak enforcing of rules has created uncomfortable situations

Some people have found that flexibility in the rules does not have any adverse effects. This has created situations in which people abuse the lack of checking.

Takeaways

I’ve had several months to think about many of these policies. Here are some thoughts I haven’t seen written out:

1. Once you create office day rules, be ready to enforce them — otherwise, they’re just cute suggestions.
2. Breaking the status quo is the hardest part: once the COVID model is broken, it becomes easy to change things around.
3. Be mindful of the exceptions you open and make them public. Exceptions may be based on distance to the office, health considerations, etc. But if people are using such exceptions in a non-transparent way, everyone else will question the motive for it, and with good reason.

April 28th, 2025 is a day that will be in many Portuguese and Spanish people’s memories. At 11:33 WEST, the power went out in the Iberian Peninsula. Everything connected to a wall socket not powered by a generator or a UPS died seemingly at the same time.

In the aftermath, several people wrote fancy texts on how the blackout taught them something. And I mocked them. It wasn’t until a couple of weeks later I realised it had taught me something too.

Our work with computers is only viable for as long as there is electrical power. And this is obvious, of course: we also need microcontrollers, and people who can design them, and people who extract the components for building those controllers, as well as the ones who design the keyboards we use, as well as screen technologies that we need to display meaningful output to the end users.

The thing with electricity, however, is how we need it on a constant basis. Everything else could stop being produced now and we’d still have everything we have thus far, but that’s not the case with power.

Actually, there’s something else: the Internet.

When considering telecommunication between private people, the Internet has become the (single) ubiquitous solution, without which no one can really communicate anymore. Even phone calls run on VoIP now.

When I was young, there were already PCs in my home, which I used to access the internet via the ADSL connection we had.

But I remember my first computer, the one that was strictly mine. It ran Windows XP with Service Pack 2. I also managed to install Microsoft Office XP. Despite having an internet connection at home, I had no ethernet connection to the router… due to physical constraints of distance. I could have used a wireless dongle to connect my computer to the internet, but I didn’t because I had no idea what USB WiFi dongles were! My dad knew, but I figure he wanted me away from the web on my own PC when I was that young.

So here’s the scenario: 8-10 year old me had a PC which I could use to do school assignments, play games, listen to CDs, exchange files with friends using thumb drives… but no internet access whatsoever. No updates. No IRC or Reddit (I knew not of those at the time). I could use another PC to access my e-mail and MSN, but I did not spend a lot of time there.

Bringing that experience to the present, it sounds almost ridiculous that someone could use a computer without internet. And while the way it has been created does introduce a lot of redundancy, I just can’t shake the feeling that sooner or later we may have some sort of Internet blackout on our hands, be it due to attacks, laws, or other creative causes.

In fact, such a scenario could present in many ways:

• An isolated continent.
• An isolated country.
• Isolated cities.
• Isolated households/offices/schools/etc.
• And, most likely, a group of ISPs or IXPs.

How ready are we, from an individual point of view, to live without internet access, as we know it, for a long period of time? Imagine that, all of a sudden you lose access to your e-mail. Your files on the cloud. Your customers’ systems. Your streaming services.

Imagine that, all of a sudden, and for the next few weeks, you could only access your street neighbours’ networks. I wonder if we could create City Area Networks or something similar!

Getting ready

Some people were ready for the blackout. Those that weren’t, went shopping for… toilet paper.

Then there’s the internet. I consider myself moderately ready for a lack of Internet, but we can always do more.

💡 Here are some ideas:

• Have local backups of your most important cloud files. Outdated backups are better than no backups at all. Bonus points if you manage to automate your local backups.
• Become a radio amateur and connect to people who do the same: this way you can connect to people without resorting to the Internet.
• Alternatively, make sure you have a simple battery-powered FM radio to listen to news as things develop around you. And don’t hope to listen to the radio on your smartphone, that’s not viable anymore.
• Make sure you can access local media you may own, be it music CDs, game installers, etc. Ripping is a great way to preserve your collection!
• If you’re using home automation tools, make sure they do not depend on outside connectivity in order to work in your home ecosystem.
• Maintain a Linux mirror for a distro. How cool would it be if you became the apt source for everyone in your city? Dreadful, but cool.
• Keep your Linux ISOs handy. Yes, the ISOs, preferably the complete installation images.