You are here: Home > Analyse > Internet Measurements > RIPE Atlas > Documentation > Security Disclosures

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 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 https://www.ripe.net/contact/responsible-disclosure-policy.

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.

2016-01 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/

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

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 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

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

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 and RIPE NCC