# Security Disclosures
Security of the RIPE Atlas system is important for us. The development team is continually improving the controlling infrastructure as well as the probes themselves, in order to increase its resiliency against issues potentially caused by network problems, misbehaving components or users, or attackers. The architectural design of the system includes many controls to prevent potential overload, unauthorised use, and "takeover" of the network.
This, however, does not mean that the system is perfect in all aspects. No system is impenetrable; it's possible that hackers, researchers or even regular users find weak points or vulnerabilities in our architecture. We encourage everyone to exercise responsible disclosure (opens new window) should they find an issue that needs special attention.
Please read more about how the RIPE NCC handles security issues and how to contact us about such issues at our responsible disclosure policy (opens new window) page.
As per the principles of responsive disclosure, please allow us enough time to confirm and fix such issues. Due to the distributed nature of the RIPE Atlas infrastructure, it can take some weeks to patch, test and release new versions of our central infrastructure; while with cases related to the probe firmware, this can take longer.
# Reported Issues
Below you can find the issues that have been brought to our attention, confirmed and fixed so far.
Note that none of the reported vulnerabilities resulted in any harm to the RIPE Atlas network, nor to probes or users.
# 2023-03 External security review outcomes for RIPE Atlas system
In March 2023, the RIPE NCC again invited an external security firm (Radically Open Security B.V.) to conduct an independent review of the security mechanisms of the RIPE Atlas website and the recently introduced v5 RIPE Atlas hardware probe. The goal of this process was to exercise due diligence and further improve the resilience against malicious actors in the system.
The reviewers have found a number of areas where they recommended improvements:
- Administrative actions on a probe had insufficient input validation, in certain cases allowing an attacker to transfer probes to a different host. This was fixed by improving input validation on such actions.
- A number of other improvements recommended to address potential shortcomings in the API and probe firmware.
The specific issues have all been corrected. We did not find any evidence that these vulnerabilities have been abused.
Remedies: The RIPE Atlas development team reviewed all the findings, improved on relevant code paths to address the reviewers' findings.
# 2022-12 Built-in measurements stopped through REST API
Issue/impact: A regression in the RIPE Atlas REST API permission checking allowed stopping of built-in measurements by using a DELETE verb on the measurement endpoint. This is the standard way for a user to stop their own measurements, but should be rejected for built-ins. This regression was part of a deploy on 2022-10-07.
Using this method, one built-in measurement (#5051) was stopped on 2022-11-30. A further nine were stopped between 2022-12-22 and 2022-12-24 after the issue was apparently discovered by an automated exploit suite.
User-defined measurements were not affected by this issue.
Remedy: The issue was fixed on 2022-12-24 and the stopped measurements were restarted. In order to prevent a similar issue in the future, extra regression tests were added and an extra check was included in the measurement scheduler.
Reported by: public disclosure
# 2019-09 Input validation on API keys management page
Date of reporting / resolution: 2019-09-23 / 2019-09-24
Issue/impact: While managing API key, a user can also specify a descriptive label. This field, which is echoed back when showing the list of keys, was not properly sanitised. Since this is only visible in a personal list of API keys, the impact is limited to the logged in user.
Remedy: We improved the sanitisation of this field.
Reported By: Wai Yan Aung
# 2019-06 External security review outcomes for RIPE Atlas system
In June 2019, the RIPE NCC invited an external security firm (Radically Open Security B.V.) to conduct an independent review of the security mechanisms specifically about the probe handling in RIPE Atlas. This included the review of communication protocols, connection handling and source code review of the associated components. The goal of this process was to exercise due diligence and further improve the resilience against potentially compromised probes in the system.
The reviewers found no high impact issues, but were able to point out potential improvements in our code base. The reviewers also had further general recommendations on how to increase the resiliency of the system and its components, many of which have been taken into account and planned as future enhancements.
Remedies: The RIPE Atlas development team reviewed all the findings, improved on relevant code paths and adjusted the related configuration settings to address the reviewers' findings.
# 2016-05 External security review outcomes for RIPE Atlas system
In June 2016, the RIPE NCC invited an external security firm (Radically Open Security B.V.) to conduct an independent review of the security mechanisms of the RIPE Atlas website, infrastructure components and software running on the RIPE Atlas probes. The goal of this process was to exercise due diligence and further improve the resilience against potentially compromised probes in the system.
The reviewers have found a number of areas where they recommended improvements:
- Users having administrative access to the RIPE Atlas infrastructure could issue commands to the probes circumventing the protections built around firmware self-upgrade. This allowed a malicious infrastructure administrator full ("root") access to the probe(s).
- The probe firmware code contained cases where a race condition or improper input handling could have lead to processes to crash. Many, though not all, of these case were prevented from ever happening by input sanitisation used in other components of the system (e.g. user input filtering in the API/UI).
- The probe firmware code did not always corretly apply the filter used to prevent measurements against blacklisted targets.
The specific issues have all been corrected. We did not find any evidence that these vulnerabilities were abused.
Remedies: The RIPE Atlas development team reviewed all the findings, improved on relevant code paths to address the reviewers' findings.
# 2015-10 External security review outcomes for RIPE Atlas system
In October 2015, the RIPE NCC invited an external security firm (Madison Gurkha B.V.) to conduct an independent review of the RIPE Atlas system as a whole as well as its security mechanisms. The goal of this process was to exercise due diligence and further improve the overall security of the system.
During this process, several weaknesses (meaning issues marked as "medium" severity or higher by the firm) were identified:
- Even though the RIPE Atlas website enforces the use of HTTPS and uses the HTTP Strict Transport Security (HSTS) feature, some of the cookies used (e.g. for CSRF protection) were not marked as "secure" or "HTTP only".
- Specific RIPE Atlas users who have been allowed to execute HTTP measurements could, theoretically, also trigger other, non-approved measurements. This was possible due to insufficient parameter checking of the HTTP measurements.
- Some attributes from measurement results were shown in the user interface in their "raw form" as they were reported by the probes. For example, the CN attribute of SSL certificates, or DNS TXT records were shown in the user interface without proper HTML sanitisation. This could have led to cross-site scripting (XSS) attacks.
These specific issues have all been corrected. We did not find any evidence that these vulnerabilities were abused.
The reviewers also had further general recommendations on how to increase the resiliency of the system and its components, many of which have been taken into account and planned as future enhancements.
Remedies: the RIPE Atlas development team reviewed all the findings, upgraded the various components or fixed bugs where the findings were relevant, and added more checks to the various automatic tests to increase their coverage.
# 2015-09 Report on probe hacking attempt
On 23 September 2015, a group of researchers published a blog post about "hacking" a RIPE Atlas probe: https://www.mdsec.co.uk/2015/09/an-introduction-to-hardware-hacking-the-ripe-atlas-probe/ (opens new window)
The researchers contacted the RIPE NCC prior to publishing their findings, following the responsible disclosure procedure. Such hacking attempts were anticipated by the RIPE NCC and, as a result, no special action was needed. The researchers' conclusion shows that there is no open vulnerability in the system's security model.
We are pleased to engage with other interested security researchers in order to ensure the best possible security of the system for all RIPE Atlas users.
# 2015-08 Access to Non-public Measurement Results
Date of reporting / resolution: 2015-08-26 / 2015-08-28
Issue/impact: Approximately two months ago, a refactoring of the measurement results API effectively weakened or removed permissions checking on calls to the following APIs:
- measurement latest
- measurement results
- status-checks
- routequake
- timetravel
This means that if you had a measurement not marked as public, these results
and metadata were available for download while this bug was in place. Note
however that the probes API was not affected.
Remedy: We patched the affected files and deployed a patch release. The calls are now behaving appropriately.
Reported By: Pier Carlo Chiodi (opens new window)
# 2014-09 - bash vulnerability (a.k.a. "shellshock")
Date of reporting / resolution: 2014-09 / 2014-09
Issue/impact: The RIPE Atlas v1-v2-v3 probes are/were not affected by this issue at all since they don't run bash and also not providing any accessible services. The anchors have bash installed, but it is not used for any of the services provided. The infrastructure components (ie. controllers) were affected.
The RIPE NCC made a public announcement (opens new window) about this issue.
Remedy: All affected components have been patched as soon as the first patch came out and also as new revisions were published. We also checked for traces of exploit attempts.
Reported by: public disclosure
# 2013-12 - Open port on some v3 production probes
Date of reporting / resolution: 2013-12 / 2013-12
Issue/impact: Due to an issue with the latest firmware release, a subset of the v3 probes were listening to incoming connections on an open port that should not have been left open. As a secondary measure, however, access to this port required credentials only available to the RIPE Atlas probe developers. It therefore never presented open access to the probes. This port (SSH) is used for development purposes in our internal development environment.
Remedy: We upgraded the v3 probes to a new, corrected firmware version (4580), and improved the checks in our firmware release process.
Reported by: Zeelandnet (opens new window)
# 2013-09 - Potential seizure of control traffic destined to another probe
Date of reporting / resolution: 2013-09 / 2013-10
Issue/impact: Possessing a valid RIPE Atlas probe key extracted from a hardware probe, an attacker could capture control traffic that was originally intended to be sent to a different probe (or probes) connected to the same controller. This could have resulted in the other probe(s) not receiving such traffic, therefore running out of tasks, eventually leading to service degradation. The captured control traffic could also be used to pretend to be the different probe for the purpose of reporting (fake) measurement results.
Remedy: The infrastructure on the controllers has been changed to prevent probes from trying to access control traffic destined for other probes.
Reported by: Randomdata (opens new window)
# 2013-06 - Potential traffic forwarding via the controlling infrastructure
Date of reporting / resolution: 2013-09 (Randomdata) and 2013-06 (RIPE NCC) / 2013-07
Issue/impact: Possessing a valid RIPE Atlas probe key extracted from a hardware probe, an attacker could tunnel traffic via the RIPE Atlas infrastructure (the so called "controllers"). This traffic would seemingly originate from the infrastructure rather than from the attacker.
Remedy: The infrastructure on controllers has been changed to prevent probes from sending traffic via the infrastructure.
Reported by: Randomdata (opens new window) and RIPE NCC