{"document":{"acknowledgments":[{"urls":["https://kb.cert.org/vuls/id/662676#acknowledgements"]}],"category":"CERT/CC Vulnerability Note","csaf_version":"2.0","notes":[{"category":"summary","text":"### Overview ###\r\n<p>Digital Alert Systems DASDEC and Monroe Electronics One-Net E189 Emergency Alert System (EAS) devices exposed a shared private root SSH key in publicly available firmware images. An attacker with SSH access to a device could use the key to log in with root privileges.</p>\r\n\r\n### Description ###\r\n<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\" class=\"wrapper-table\"><tr><td><p>The Digital Alert Systems DASDEC-I and DASDEC-II and Monroe Electronics R189 One-Net/R189SE One-NetSE are Linux-based EAS encoder/decoder (ENDEC) devices that are used to broadcast EAS messages over digital and analog channels. IOActive has <a href=\"http://www.ioactive.com/pdfs/IOActive_DASDEC_vulnerabilities.pdf\">reported</a> several security issues affecting these devices. The most severe of these issues is the public disclosure of the default private root SSH key. The less severe issues could also contribute to an attacker's ability to compromise a vulnerable device.</p><p><b>Compromised root SSH key </b><b>(</b><b>CVE-2013-0137</b><b>)</b><br/>Publicly available firmware images for these devices included a private root SSH key that was authorized to log in to the devices (CWE-798, CWE-321). The fingerprint for the compromised SSH key is 0c:89:49:f7:62:d2:98:f0:27:75:ad:e9:72:2c:68:c3. Although this key is not hard-coded, it may be impractical for less technical users to manually disable or change they key prior to firmware version 2.0-2.<br/><br/><b>Predictable session ID</b><br/>IOActive reports that the administrative web server uses a predictable, monotonically increasing session ID. This finding is based on running the web server in a test environment. Testing on a variety of firmware versions on devices both at the factory and in the field, Monroe Electronics could not reproduce this finding.<br/><br/><b>Log information disclosure</b><br/>Logs available via the web server provide a variety of information about the configuration, operation, and status of the device (CWE-532). Some of the log information is public and may be required by regulation.<br/><br/><b>Predictable password generation</b><br/>The <font face=\"Courier New\">dasdec_mkuser</font> script generates passwords in a deterministic way (CWE-341), however these passwords are not for administrative access, and the script is not used for general user account configuration.<br/><br/><b>Default password</b><br/>Like many similar devices, the DASDEC and One-Net ENDECs use default administrative credentials. Some sites fail to change the default administrative password and allow unrestricted internet access.</p></td></tr></table>\r\n\r\n### Impact ###\r\n<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\" class=\"wrapper-table\"><tr><td><p>An attacker with the private key and SSH access can log in to a device with root privileges.<br/><br/>Predictable session IDs could allow an attacker to take control of an existing administrative web session.<br/><br/>Predictable and unchanged default passwords can allow an attacker to log in to a device, possibly with root privileges. Devices exposed to the internet are at particularly high risk, for example, see <a href=\"http://www.thebdr.net/articles/fcc/eas/EAS-Q5.pdf\">Secure EAS Codecs Prevent Zombie Attacks</a> and US-CERT Alert <a href=\"http://www.us-cert.gov/ncas/alerts/TA13-175A\">TA13-175A</a>.<br/><br/>Logs may disclose configuration information that can benefit an attacker.</p></td></tr></table>\r\n\r\n### Solution ###\r\n<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\" class=\"wrapper-table\"><tr><td><p><b>Apply an update</b><br/><br/>On April 24, 2013, <a href=\"http://www.monroe-electronics.com/MONROE_ELECTRONICS_PDF/130604-Monroe-Security-PR.pdf\">Monroe Electronics</a> and <a href=\"http://www.digitalalertsystems.com/pdf/130604-Monroe-Security-PR.pdf\">Digital Alert Systems</a> released firmware version 2.0-2 that allows users to disable the compromised SSH key, provides a simplified option to install new unique keys, and enforces a new password policy. Monroe Electronics has taken considerable effort to provide update information to DASDEC and One-NetSE users.<br/><br/>DASDEC users can obtain updated firmware and release notes by contacting &lt;support@digitalalertsystems.com&gt;. R189 One-Net users can contact &lt;eas@monroe-electronics.com&gt;.<br/><br/><b>Disable compromised SSH key</b><br/><br/>The compromised root SSH key should be disabled immediately, especially if the SSH service is exposed to untrusted networks such as the internet. If SSH connectivity is required, generate, install, and test new SSH keys before disabling the compromised key. The fingerprint for the compromised SSH key is 0c:89:49:f7:62:d2:98:f0:27:75:ad:e9:72:2c:68:c3.<br/><br/><b>Manually inspect SSH keys</b><br/><br/>To identify a compromised key, examine the <tt>authorized_keys</tt> file at <font face=\"Courier New\">/root/.ssh/authorize</font><tt>d_keys</tt><tt>2.dasdec</tt> and use the <font face=\"Courier New\">ssh-keygen</font> command to show SSH key fingerprints. The following example shows the fingerprint for the compromised key:<br/><br/><font face=\"Courier New\">$ ssh-keygen -l -f authorized_keys2.dasdec</font><br/><font face=\"Courier New\">1024 0c:89:49:f7:62:d2:98:f0:27:75:ad:e9:72:2c:68:c3  wood@endec1 (DSA)</font><br/><br/>Note that <tt>ssh-keygen</tt> only shows the fingerprint for the first key/line in the file. If <font face=\"Courier New\">authorized_keys2.dasdec</font> contains multiple keys (multiple lines, one key per line), it will be necessary to extract each key (line) to a separate file and run the <font face=\"Courier New\">ssh-keygen</font> command on each key/file. The shell script below can be used to list the public keys of concern.\r\n\t<br/><a href=\"https://raw.github.com/aspiers/ssh-config/master/bin/ssh-list-pubkeys\">https://raw.github.com/aspiers/ssh-config/master/bin/ssh-list-pubkeys</a><br/><br/>To generate new SSH keys, use <tt>ssh-kegen</tt>.</p></td></tr></table><table border=\"0\" cellpadding=\"0\" cellspacing=\"0\" class=\"wrapper-table\" style=\"padding-top: 15px;\"><tr><td><p><b>Restrict access</b><br/><br/>If for some reason you are not able to remove and replace the compromised SSH key, restrict access to the SSH service to highly trusted hosts and networks only. As a general good security practice, restrict access to all services to trusted hosts and networks.<br/><br/><b>Change default passwords</b><br/><br/>Change any default passwords, and do not deploy production systems without changing default passwords. Search engines like Shodan can index systems exposed to the internet and default passwords are usually documented and well-known. It is often trivial for an attacker to identify and access systems on the internet using default passwords.</p></td></tr></table>\r\n\r\n### Acknowledgements ###\r\n<p>Thanks to Mike Davis and Cesar Cerrudo of IOActive for reporting these issues. Thanks also to Monroe Electronics for their efforts to contact affected users.</p><p>This document was written by Art Manion.</p>","title":"Summary"},{"category":"legal_disclaimer","text":"THIS DOCUMENT IS PROVIDED ON AN 'AS IS' BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. ","title":"Legal Disclaimer"},{"category":"other","text":"CERT/CC Vulnerability Note is a limited advisory. It primarily identifies vendors impacted by the advisory and not specific products. We only support \"known_affected\" and \"known_not_affected\" status. Please consult the vendor's statements and advisory URL if provided by the vendor for more details ","title":"Limitations of Advisory"}],"publisher":{"category":"coordinator","contact_details":"Email: cert@cert.org, Phone: +1412 268 5800","issuing_authority":"CERT/CC under DHS/CISA https://www.cisa.gov/cybersecurity also see https://kb.cert.org/ ","name":"CERT/CC","namespace":"https://kb.cert.org/"},"references":[{"url":"https://certcc.github.io/certcc_disclosure_policy","summary":"CERT/CC vulnerability disclosure policy"},{"summary":"CERT/CC document released","category":"self","url":"https://kb.cert.org/vuls/id/662676"},{"url":"http://www.monroe-electronics.com/EAS_pages/prod_r189se.html","summary":"http://www.monroe-electronics.com/EAS_pages/prod_r189se.html"},{"url":"http://www.digitalalertsystems.com/products_enc-dec.html","summary":"http://www.digitalalertsystems.com/products_enc-dec.html"},{"url":"http://www.monroe-electronics.com/MONROE_ELECTRONICS_PDF/130604-Monroe-Security-PR.pdf","summary":"http://www.monroe-electronics.com/MONROE_ELECTRONICS_PDF/130604-Monroe-Security-PR.pdf"},{"url":"http://www.digitalalertsystems.com/pdf/130604-Monroe-Security-PR.pdf","summary":"http://www.digitalalertsystems.com/pdf/130604-Monroe-Security-PR.pdf"},{"url":"http://www.digitalalertsystems.com/pdf/wpdas-122.pdf","summary":"http://www.digitalalertsystems.com/pdf/wpdas-122.pdf"},{"url":"http://www.fcc.gov/guides/emergency-alert-system-eas","summary":"http://www.fcc.gov/guides/emergency-alert-system-eas"},{"url":"http://www.ioactive.com/news-events/ioactive_uncovers_vulnerabilities_in_united_states_emergency_alerting_system.html","summary":"http://www.ioactive.com/news-events/ioactive_uncovers_vulnerabilities_in_united_states_emergency_alerting_system.html"},{"url":"http://www.ioactive.com/pdfs/IOActive_DASDEC_vulnerabilities.pdf","summary":"http://www.ioactive.com/pdfs/IOActive_DASDEC_vulnerabilities.pdf"},{"url":"http://blog.ioactive.com/2013/10/strike-two-for-emergency-alerting.html","summary":"http://blog.ioactive.com/2013/10/strike-two-for-emergency-alerting.html"},{"url":"http://blog.ioactive.com/2013/07/why-vendor-openness-still-matters.html","summary":"http://blog.ioactive.com/2013/07/why-vendor-openness-still-matters.html"},{"url":"http://www.commlawblog.com/2013/02/articles/broadcast/fcc-urges-broadcasters-to-secure-eas-equipment/","summary":"http://www.commlawblog.com/2013/02/articles/broadcast/fcc-urges-broadcasters-to-secure-eas-equipment/"},{"url":"http://www.broadcastlawblog.com/2013/02/articles/emergency-communications/hackers-use-eas-to-send-alert-of-zombie-attack-fcc-issues-urgent-warning-to-broadcasters-to-secure-their-eas-systems/","summary":"http://www.broadcastlawblog.com/2013/02/articles/emergency-communications/hackers-use-eas-to-send-alert-of-zombie-attack-fcc-issues-urgent-warning-to-broadcasters-to-secure-their-eas-systems/"},{"url":"http://www.radioworld.com/article/eas-hack-cap-not-the-issue-internet-security-is/217746","summary":"http://www.radioworld.com/article/eas-hack-cap-not-the-issue-internet-security-is/217746"},{"url":"http://www.radioworld.com/article/stations-urged-to-protect-their-eas/217746","summary":"http://www.radioworld.com/article/stations-urged-to-protect-their-eas/217746"},{"url":"http://transition.fcc.gov/pshs/techtopics/techtopics21.html","summary":"http://transition.fcc.gov/pshs/techtopics/techtopics21.html"},{"url":"http://www.thebdr.net/articles/fcc/eas/eas.html","summary":"http://www.thebdr.net/articles/fcc/eas/eas.html"},{"url":"http://www.thebdr.net/articles/fcc/eas/EAS-Q5.pdf","summary":"http://www.thebdr.net/articles/fcc/eas/EAS-Q5.pdf"},{"url":"http://cwe.mitre.org/data/definitions/798.html","summary":"http://cwe.mitre.org/data/definitions/798.html"},{"url":"http://cwe.mitre.org/data/definitions/532.html","summary":"http://cwe.mitre.org/data/definitions/532.html"},{"url":"http://cwe.mitre.org/data/definitions/341.html","summary":"http://cwe.mitre.org/data/definitions/341.html"},{"url":"http://cwe.mitre.org/data/definitions/320.html","summary":"http://cwe.mitre.org/data/definitions/320.html"},{"url":"http://cwe.mitre.org/data/definitions/321.html","summary":"http://cwe.mitre.org/data/definitions/321.html"},{"url":"http://www.us-cert.gov/ncas/alerts/TA13-175A","summary":"http://www.us-cert.gov/ncas/alerts/TA13-175A"},{"url":"https://raw.github.com/aspiers/ssh-config/master/bin/ssh-list-pubkeys","summary":"https://raw.github.com/aspiers/ssh-config/master/bin/ssh-list-pubkeys"},{"url":"http://www.wired.com/threatlevel/2013/07/eas-holes/","summary":"http://www.wired.com/threatlevel/2013/07/eas-holes/"}],"title":"Digital Alert Systems DASDEC and Monroe Electronics R189 One-Net firmware exposes private root SSH key","tracking":{"current_release_date":"2025-08-01T16:16:38+00:00","generator":{"engine":{"name":"VINCE","version":"3.0.35"}},"id":"VU#662676","initial_release_date":"2013-06-24 00:00:00+00:00","revision_history":[{"date":"2025-08-01T16:16:38+00:00","number":"1.20250801161638.97","summary":"Released on 2025-08-01T16:16:38+00:00"}],"status":"final","version":"1.20250801161638.97"}},"vulnerabilities":[{"title":"The default configuration of the Digital Alert Systems DASDEC EAS device before 2.","notes":[{"category":"summary","text":"The default configuration of the Digital Alert Systems DASDEC EAS device before 2.0-2 and the Monroe Electronics R189 One-Net EAS device before 2.0-2 contains a known SSH private key, which makes it easier for remote attackers to obtain root access, and spoof alerts, via an SSH session."}],"cve":"CVE-2013-0137","ids":[{"system_name":"CERT/CC V Identifier ","text":"VU#662676"}],"product_status":{"known_affected":["CSAFPID-e9a30c04-38a0-11f1-8422-122e2785dc9f","CSAFPID-e9a368fc-38a0-11f1-8422-122e2785dc9f"]}}],"product_tree":{"branches":[{"category":"vendor","name":"Digital Alert Systems","product":{"name":"Digital Alert Systems Products","product_id":"CSAFPID-e9a30c04-38a0-11f1-8422-122e2785dc9f"}},{"category":"vendor","name":"Monroe Electronics","product":{"name":"Monroe Electronics Products","product_id":"CSAFPID-e9a368fc-38a0-11f1-8422-122e2785dc9f"}}]}}