GSD-2021-21382
Vulnerability from gsd - Updated: 2023-12-13 01:23Details
Restund is an open source NAT traversal server. The restund TURN server can be instructed to open a relay to the loopback address range. This allows you to reach any other service running on localhost which you might consider private. In the configuration that we ship (https://github.com/wireapp/ansible-restund/blob/master/templates/restund.conf.j2#L40-L43) the `status` interface of restund is enabled and is listening on `127.0.0.1`.The `status` interface allows users to issue administrative commands to `restund` like listing open relays or draining connections. It would be possible for an attacker to contact the status interface and issue administrative commands by setting `XOR-PEER-ADDRESS` to `127.0.0.1:{{restund_udp_status_port}}` when opening a TURN channel. We now explicitly disallow relaying to loopback addresses, 'any' addresses, link local addresses, and the broadcast address. As a workaround disable the `status` module in your restund configuration. However there might still be other services running on `127.0.0.0/8` that you do not want to have exposed. The `turn` module can be disabled. Restund will still perform STUN and this might already be enough for initiating calls in your environments. TURN is only used as a last resort when other NAT traversal options do not work. One should also make sure that the TURN server is set up with firewall rules so that it cannot relay to other addresses that you don't want the TURN server to relay to. For example other services in the same VPC where the TURN server is running. Ideally TURN servers should be deployed in an isolated fashion where they can only reach what they need to reach to perform their task of assisting NAT-traversal.
Aliases
Aliases
{
"GSD": {
"alias": "CVE-2021-21382",
"description": "Restund is an open source NAT traversal server. The restund TURN server can be instructed to open a relay to the loopback address range. This allows you to reach any other service running on localhost which you might consider private. In the configuration that we ship (https://github.com/wireapp/ansible-restund/blob/master/templates/restund.conf.j2#L40-L43) the `status` interface of restund is enabled and is listening on `127.0.0.1`.The `status` interface allows users to issue administrative commands to `restund` like listing open relays or draining connections. It would be possible for an attacker to contact the status interface and issue administrative commands by setting `XOR-PEER-ADDRESS` to `127.0.0.1:{{restund_udp_status_port}}` when opening a TURN channel. We now explicitly disallow relaying to loopback addresses, \u0027any\u0027 addresses, link local addresses, and the broadcast address. As a workaround disable the `status` module in your restund configuration. However there might still be other services running on `127.0.0.0/8` that you do not want to have exposed. The `turn` module can be disabled. Restund will still perform STUN and this might already be enough for initiating calls in your environments. TURN is only used as a last resort when other NAT traversal options do not work. One should also make sure that the TURN server is set up with firewall rules so that it cannot relay to other addresses that you don\u0027t want the TURN server to relay to. For example other services in the same VPC where the TURN server is running. Ideally TURN servers should be deployed in an isolated fashion where they can only reach what they need to reach to perform their task of assisting NAT-traversal.",
"id": "GSD-2021-21382"
},
"gsd": {
"metadata": {
"exploitCode": "unknown",
"remediation": "unknown",
"reportConfidence": "confirmed",
"type": "vulnerability"
},
"osvSchema": {
"aliases": [
"CVE-2021-21382"
],
"details": "Restund is an open source NAT traversal server. The restund TURN server can be instructed to open a relay to the loopback address range. This allows you to reach any other service running on localhost which you might consider private. In the configuration that we ship (https://github.com/wireapp/ansible-restund/blob/master/templates/restund.conf.j2#L40-L43) the `status` interface of restund is enabled and is listening on `127.0.0.1`.The `status` interface allows users to issue administrative commands to `restund` like listing open relays or draining connections. It would be possible for an attacker to contact the status interface and issue administrative commands by setting `XOR-PEER-ADDRESS` to `127.0.0.1:{{restund_udp_status_port}}` when opening a TURN channel. We now explicitly disallow relaying to loopback addresses, \u0027any\u0027 addresses, link local addresses, and the broadcast address. As a workaround disable the `status` module in your restund configuration. However there might still be other services running on `127.0.0.0/8` that you do not want to have exposed. The `turn` module can be disabled. Restund will still perform STUN and this might already be enough for initiating calls in your environments. TURN is only used as a last resort when other NAT traversal options do not work. One should also make sure that the TURN server is set up with firewall rules so that it cannot relay to other addresses that you don\u0027t want the TURN server to relay to. For example other services in the same VPC where the TURN server is running. Ideally TURN servers should be deployed in an isolated fashion where they can only reach what they need to reach to perform their task of assisting NAT-traversal.",
"id": "GSD-2021-21382",
"modified": "2023-12-13T01:23:10.735302Z",
"schema_version": "1.4.0"
}
},
"namespaces": {
"cve.org": {
"CVE_data_meta": {
"ASSIGNER": "security-advisories@github.com",
"ID": "CVE-2021-21382",
"STATE": "PUBLIC",
"TITLE": "Unsafe loopback forwarding interface in Restund"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "restund",
"version": {
"version_data": [
{
"version_value": "\u003c 0.4.15"
}
]
}
}
]
},
"vendor_name": "wireapp"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "Restund is an open source NAT traversal server. The restund TURN server can be instructed to open a relay to the loopback address range. This allows you to reach any other service running on localhost which you might consider private. In the configuration that we ship (https://github.com/wireapp/ansible-restund/blob/master/templates/restund.conf.j2#L40-L43) the `status` interface of restund is enabled and is listening on `127.0.0.1`.The `status` interface allows users to issue administrative commands to `restund` like listing open relays or draining connections. It would be possible for an attacker to contact the status interface and issue administrative commands by setting `XOR-PEER-ADDRESS` to `127.0.0.1:{{restund_udp_status_port}}` when opening a TURN channel. We now explicitly disallow relaying to loopback addresses, \u0027any\u0027 addresses, link local addresses, and the broadcast address. As a workaround disable the `status` module in your restund configuration. However there might still be other services running on `127.0.0.0/8` that you do not want to have exposed. The `turn` module can be disabled. Restund will still perform STUN and this might already be enough for initiating calls in your environments. TURN is only used as a last resort when other NAT traversal options do not work. One should also make sure that the TURN server is set up with firewall rules so that it cannot relay to other addresses that you don\u0027t want the TURN server to relay to. For example other services in the same VPC where the TURN server is running. Ideally TURN servers should be deployed in an isolated fashion where they can only reach what they need to reach to perform their task of assisting NAT-traversal."
}
]
},
"impact": {
"cvss": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 8.6,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"version": "3.1"
}
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE-668: Exposure of Resource to Wrong Sphere"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://github.com/wireapp/restund/security/advisories/GHSA-96j5-w9jq-pv2x",
"refsource": "CONFIRM",
"url": "https://github.com/wireapp/restund/security/advisories/GHSA-96j5-w9jq-pv2x"
},
{
"name": "https://github.com/coturn/coturn/security/advisories/GHSA-6g6j-r9rf-cm7p",
"refsource": "MISC",
"url": "https://github.com/coturn/coturn/security/advisories/GHSA-6g6j-r9rf-cm7p"
},
{
"name": "https://github.com/wireapp/restund/pull/7",
"refsource": "MISC",
"url": "https://github.com/wireapp/restund/pull/7"
},
{
"name": "https://docs.wire.com/understand/restund.html",
"refsource": "MISC",
"url": "https://docs.wire.com/understand/restund.html"
},
{
"name": "https://github.com/wireapp/ansible-restund/blob/master/templates/restund.conf.j2#L40-L43",
"refsource": "MISC",
"url": "https://github.com/wireapp/ansible-restund/blob/master/templates/restund.conf.j2#L40-L43"
},
{
"name": "https://talosintelligence.com/vulnerability_reports/TALOS-2018-0732",
"refsource": "MISC",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2018-0732"
},
{
"name": "https://www.rtcsec.com/post/2021/01/details-about-cve-2020-26262-bypass-of-coturns-default-access-control-protection/#further-concerns-what-else",
"refsource": "MISC",
"url": "https://www.rtcsec.com/post/2021/01/details-about-cve-2020-26262-bypass-of-coturns-default-access-control-protection/#further-concerns-what-else"
}
]
},
"source": {
"advisory": "GHSA-96j5-w9jq-pv2x",
"discovery": "UNKNOWN"
}
},
"nvd.nist.gov": {
"configurations": {
"CVE_data_version": "4.0",
"nodes": [
{
"children": [],
"cpe_match": [
{
"cpe23Uri": "cpe:2.3:a:wire:restund:*:*:*:*:*:*:*:*",
"cpe_name": [],
"versionEndExcluding": "0.4.15",
"vulnerable": true
}
],
"operator": "OR"
}
]
},
"cve": {
"CVE_data_meta": {
"ASSIGNER": "security-advisories@github.com",
"ID": "CVE-2021-21382"
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "en",
"value": "Restund is an open source NAT traversal server. The restund TURN server can be instructed to open a relay to the loopback address range. This allows you to reach any other service running on localhost which you might consider private. In the configuration that we ship (https://github.com/wireapp/ansible-restund/blob/master/templates/restund.conf.j2#L40-L43) the `status` interface of restund is enabled and is listening on `127.0.0.1`.The `status` interface allows users to issue administrative commands to `restund` like listing open relays or draining connections. It would be possible for an attacker to contact the status interface and issue administrative commands by setting `XOR-PEER-ADDRESS` to `127.0.0.1:{{restund_udp_status_port}}` when opening a TURN channel. We now explicitly disallow relaying to loopback addresses, \u0027any\u0027 addresses, link local addresses, and the broadcast address. As a workaround disable the `status` module in your restund configuration. However there might still be other services running on `127.0.0.0/8` that you do not want to have exposed. The `turn` module can be disabled. Restund will still perform STUN and this might already be enough for initiating calls in your environments. TURN is only used as a last resort when other NAT traversal options do not work. One should also make sure that the TURN server is set up with firewall rules so that it cannot relay to other addresses that you don\u0027t want the TURN server to relay to. For example other services in the same VPC where the TURN server is running. Ideally TURN servers should be deployed in an isolated fashion where they can only reach what they need to reach to perform their task of assisting NAT-traversal."
}
]
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "en",
"value": "CWE-862"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://github.com/wireapp/ansible-restund/blob/master/templates/restund.conf.j2#L40-L43",
"refsource": "MISC",
"tags": [
"Exploit",
"Third Party Advisory"
],
"url": "https://github.com/wireapp/ansible-restund/blob/master/templates/restund.conf.j2#L40-L43"
},
{
"name": "https://github.com/wireapp/restund/security/advisories/GHSA-96j5-w9jq-pv2x",
"refsource": "CONFIRM",
"tags": [
"Exploit",
"Third Party Advisory"
],
"url": "https://github.com/wireapp/restund/security/advisories/GHSA-96j5-w9jq-pv2x"
},
{
"name": "https://www.rtcsec.com/post/2021/01/details-about-cve-2020-26262-bypass-of-coturns-default-access-control-protection/#further-concerns-what-else",
"refsource": "MISC",
"tags": [
"Not Applicable"
],
"url": "https://www.rtcsec.com/post/2021/01/details-about-cve-2020-26262-bypass-of-coturns-default-access-control-protection/#further-concerns-what-else"
},
{
"name": "https://talosintelligence.com/vulnerability_reports/TALOS-2018-0732",
"refsource": "MISC",
"tags": [
"Third Party Advisory",
"Exploit"
],
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2018-0732"
},
{
"name": "https://github.com/coturn/coturn/security/advisories/GHSA-6g6j-r9rf-cm7p",
"refsource": "MISC",
"tags": [
"Not Applicable"
],
"url": "https://github.com/coturn/coturn/security/advisories/GHSA-6g6j-r9rf-cm7p"
},
{
"name": "https://github.com/wireapp/restund/pull/7",
"refsource": "MISC",
"tags": [
"Exploit",
"Patch",
"Third Party Advisory"
],
"url": "https://github.com/wireapp/restund/pull/7"
},
{
"name": "https://docs.wire.com/understand/restund.html",
"refsource": "MISC",
"tags": [
"Vendor Advisory"
],
"url": "https://docs.wire.com/understand/restund.html"
}
]
}
},
"impact": {
"baseMetricV2": {
"acInsufInfo": false,
"cvssV2": {
"accessComplexity": "LOW",
"accessVector": "NETWORK",
"authentication": "SINGLE",
"availabilityImpact": "NONE",
"baseScore": 5.5,
"confidentialityImpact": "PARTIAL",
"integrityImpact": "PARTIAL",
"vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:N",
"version": "2.0"
},
"exploitabilityScore": 8.0,
"impactScore": 4.9,
"obtainAllPrivilege": false,
"obtainOtherPrivilege": false,
"obtainUserPrivilege": false,
"severity": "MEDIUM",
"userInteractionRequired": false
},
"baseMetricV3": {
"cvssV3": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 9.6,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
"version": "3.1"
},
"exploitabilityScore": 3.1,
"impactScore": 5.8
}
},
"lastModifiedDate": "2022-10-21T22:44Z",
"publishedDate": "2021-06-11T21:15Z"
}
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…