Telnet
Review network device logs and netflow data for indications of TCP Telnet-protocol traffic directed at port 23 on all network device hosts. Although Telnet may be directed at other ports (e.g., port 80, HTTP), port 23 is the primary target. Inspect any indication of Telnet sessions (or attempts). Because Telnet is an unencrypted protocol, session traffic will reveal command line interface (CLI) command sequences appropriate for the make and model of the device. CLI strings may reveal login procedures, presentation of user credentials, commands to display boot or running configuration, copying files and creation or destruction of GRE tunnels, etc. See Appendices A and B for CLI strings for Cisco and other vendors’ devices.
SNMP and TFTP
Review network device logs and netflow data for indications of UDP SNMP traffic directed at port 161/162 on all network-device hosts. Because SNMP is a management tool, any such traffic that is not from a trusted management host on an internal network should be investigated. Review the source address of SNMP traffic for indications of addresses that spoof the address space of the network. Review outbound network traffic from the network device for evidence of Internet-destined UDP TFTP traffic. Any correlation of inbound or spoofed SNMP closely followed by outbound TFTP should be cause for alarm and further inspection. See Appendix C for detection of the cyber actors’ SNMP tactics.
Because TFTP is an unencrypted protocol, session traffic will reveal strings associated with configuration data appropriate for the make and model of the device. See Appendices A and B for CLI strings for Cisco and other vendor’s devices.
SMI and TFTP
Review network device logs and netflow data for indications of TCP SMI protocol traffic directed at port 4786 of all network-device hosts. Because SMI is a management feature, any traffic that is not from a trusted management host on an internal network should be investigated. Review outbound network traffic from the network device for evidence of Internet-destined UDP TFTP traffic. Any correlation of inbound SMI closely followed by outbound TFTP should be cause for alarm and further inspection. Of note, between June 29 and July 6, 2017, Russian actors used the SMI protocol to scan for vulnerable network devices. Two Russian cyber actors controlled hosts 91.207.57.69(3) and 176.223.111.160(4), and connected to IPs on several network ranges on port 4786. See Appendix D for detection of the cyber actors’ SMI tactics.
Because TFTP is an unencrypted protocol, session traffic will reveal strings appropriate for the make and model of the device. See Appendices A and B for CLI strings for Cisco and other vendors’ devices.
Determine if SMI is present
- Examine the output of “show vstack config | inc Role”. The presence of “Role: Client (SmartInstall enabled)” indicates that Smart Install is configured.
- Examine the output of “show tcp brief all” and look for “*:4786”. The SMI feature listens on tcp/4786.
- Note: The commands above will indicate whether the feature is enabled on the device but not whether a device has been compromised.
Detect use of SMI
The following signature may be used to detect SMI usage. Flag as suspicious and investigate SMI traffic arriving from outside the network boundary. If SMI is not used inside the network, any SMI traffic arriving on an internal interface should be flagged as suspicious and investigated for the existence of an unauthorized SMI director. If SMI is used inside the network, ensure that the traffic is coming from an authorized SMI director, and not from a bogus director.
- alert tcp any any -> any 4786 (msg:”Smart Install Protocol”; flow:established,only_stream; content:”|00 00 00 01 00 00 00 01|”; offset:0; depth:8; fast_pattern;)
- See Cisco recommendations for detecting and mitigating SMI. [9](link is external)
Detect use of SIET
The following signatures detect usage of the SIET’s commands change_config, get_config, update_ios, and execute. These signatures are valid based on the SIET tool available as of early September 2017:
- alert tcp any any -> any 4786 (msg:”SmartInstallExploitationTool_UpdateIos_And_Execute”; flow:established; content:”|00 00 00 01 00 00 00 01 00 00 00 02 00 00 01 c4|”; offset:0; depth:16; fast_pattern; content:”://”;)
- alert tcp any any -> any 4786 (msg:”SmartInstallExploitationTool_ChangeConfig”; flow:established; content:”|00 00 00 01 00 00 00 01 00 00 00 03 00 00 01 28|”; offset:0; depth:16; fast_pattern; content:”://”;)
- alert tcp any any -> any 4786 (msg: “SmartInstallExploitationTool_GetConfig”; flow: established; content:”|00 00 00 01 00 00 00 01 00 00 00 08 00 00 04 08|”; offset:0; depth:16; fast_pattern; content:”copy|20|”;)
In general, exploitation attempts with the SIET tool will likely arrive from outside the network boundary. However, before attempting to tune or limit the range of these signatures, i.e. with $EXTERNAL_NET or $HOME_NET, it is recommended that they be deployed with the source and destination address ranges set to “any”. This will allow the possibility of detection of an attack from an unanticipated source, and may allow for coverage of devices outside of the normal scope of what may be defined as the $HOME_NET.
GRE Tunneling
Inspect the presence of protocol 47 traffic flowing to or from unexpected addresses, or unexplained presence of GRE tunnel creation, modification, or destruction in log files.
Mitigation Strategies
There is a significant amount of publically available cybersecurity guidance and best practices from DHS, allied government, vendors, and the private-sector cybersecurity community on mitigation strategies for the exploitation vectors described above. The following are additional mitigations for network device manufacturers, ISPs, and owners or operators.
General Mitigations
All
- Do not allow unencrypted (i.e., plaintext) management protocols (e.g. Telnet) to enter an organization from the Internet. When encrypted protocols such as SSH, HTTPS, or TLS are not possible, management activities from outside the organization should be done through an encrypted Virtual Private Network (VPN) where both ends are mutually authenticated.
- Do not allow Internet access to the management interface of any network device. The best practice is to block Internet-sourced access to the device management interface and restrict device management to an internal trusted and whitelisted host or LAN. If access to the management interface cannot be restricted to an internal trusted network, restrict remote management access via encrypted VPN capability where both ends are mutually authenticated. Whitelist the network or host from which the VPN connection is allowed, and deny all others.
- Disable legacy unencrypted protocols such as Telnet and SNMPv1 or v2c. Where possible, use modern encrypted protocols such as SSH and SNMPv3. Harden the encrypted protocols based on current best security practice. DHS strongly advises owners and operators to retire and replace legacy devices that cannot be configured to use SNMP V3.
- Immediately change default passwords and enforce a strong password policy. Do not reuse the same password across multiple devices. Each device should have a unique password. Where possible, avoid legacy password-based authentication, and implement two-factor authentication based on public-private keys. See NCCIC/US-CERT TA13-175A – Risks of Default Passwords on the Internet, last revised October 7, 2016.
Manufacturers
- Do not design products to support legacy or unencrypted protocols. If this is not possible, deliver the products with these legacy or unencrypted protocols disabled by default, and require the customer to enable the protocols after accepting an interactive risk warning. Additionally, restrict these protocols to accept connections only from private addresses (i.e., RFC 1918).
- Do not design products with unauthenticated services. If this is not possible, deliver the products with these unauthenticated services disabled by default, and require the customer to enable the services after accepting an interactive risk warning. Additionally, these unauthenticated services should be restricted to accept connections only from private address space (i.e., RFC 1918).
- Design installation procedures or scripts so that the customer is required to change all default passwords. Encourage the use of authentication services that do not depend on passwords, such as RSA-based Public Key Infrastructure (PKI) keys.
- Because YARA has become a security-industry standard way of describing rules for detecting malicious code on hosts, consider embedding YARA or a YARA-like capability to ingest and use YARA rules on routers, switches, and other network devices.
Security Vendors
- Produce and publish YARA rules for malware discovered on network devices.
ISPs
- Do not field equipment in the network core or to customer premises with legacy, unencrypted, or unauthenticated protocols and services. When purchasing equipment from vendors, include this requirement in purchase agreements.
- Disable legacy, unencrypted, or unauthenticated protocols and services. Use modern encrypted management protocols such as SSH. Harden the encrypted protocols based on current best security practices from the vendor.
- Initiate a plan to upgrade fielded equipment no longer supported by the vendor with software updates and security patches. The best practice is to field only supported equipment and replace legacy equipment prior to it falling into an unsupported state.
- Apply software updates and security patches to fielded equipment. When that is not possible, notify customers about software updates and security patches and provide timely instructions on how to apply them.
Owners or operators
- Specify in contracts that the ISP providing service will only field currently supported network equipment and will replace equipment when it falls into an unsupported state.
- Specify in contracts that the ISP will regularly apply software updates and security patches to fielded network equipment or will notify and provide the customers the ability to apply them.
- Block TFTP from leaving the organization destined for Internet-based hosts. Network devices should be configured to send configuration data to a secured host on a trusted segment of the internal management LAN.
- Verify that the firmware and OS on each network device are from a trusted source and issued by the manufacturer. To validate the integrity of network devices, refer to the vendor’s guidance, tools, and processes. See Cisco’s Security Center(link is external) for guidance to validate Cisco IOS firmware images.
- Cisco IOS runs in a variety of network devices under other labels, such as Linksys and SOHO Internet Gateway routers or firewalls as part of an Internet package by ISPs (e.g., Comcast). The indicators in Appendix A may be applicable to your device.
Detailed Mitigations
Refer to the vendor-specific guidance for the make and model of network device in operation.
For information on mitigating SNMP vulnerabilities, see
How to Mitigate SMI Abuse
- Configure network devices before installing onto a network exposed to the Internet. If SMI must be used during installation, disable SMI with the “no vstack” command before placing the device into operation.
- Prohibit remote devices attempting to cross a network boundary over TCP port 4786 via SMI.
- Prohibit outbound network traffic to external devices over UDP port 69 via TFTP.
- See Cisco recommendations for detecting and mitigating SMI. [10](link is external)
- Cisco IOS runs in a variety of network devices under other labels, such as Linksys and SOHO Internet Gateway routers or firewalls as part of an Internet package by ISPs (e.g., Comcast). Check with your ISP and ensure that they have disabled SMI before or at the time of installation, or obtain instructions on how to disable it.
How to Mitigate GRE Tunneling Abuse:
- Verify that all routing tables configured in each border device are set to communicate with known and trusted infrastructure.
- Verify that any GRE tunnels established from border routers are legitimate and are configured to terminate at trusted endpoints.
Definitions
Operating System Fingerprinting is analyzing characteristics of packets sent by a target, such as packet headers or listening ports, to identify the operating system in use on the target. [11]
Spear phishing is an attempt by an individual or group to solicit personal information from unsuspecting users by employing social engineering techniques. Phishing emails are crafted to appear as if they were sent from a legitimate organization or known individual. These emails often attempt to entice users to click on a link that will take the user to a fraudulent website that appears legitimate. The user then may be asked to provide personal information, such as account usernames and passwords, which can further expose them to future compromises. [12]
In a watering hole attack, the attacker compromises a site likely to be visited by a particular target group, rather than attacking the target group directly. [13]
Report Notice
DHS encourages recipients who identify the use of tools or techniques discussed in this document to report information to NCCIC or law enforcement immediately. To request incident response resources or technical assistance, contact NCCIC at NCCICcustomerservice@hq.dhs.gov or 888-282-0870 and the FBI through a local field office or the FBI’s Cyber Division at CyWatch@fbi.gov or 855-292-3937. To request information from or report cyber incidents to UK authorities, contact NCSC at www.ncsc.gov.uk/contact.
Appendix A: Cisco Related Command and Configuration Strings
Command Strings.
Commands associated with Cisco IOS. These strings may be seen in inbound network traffic of unencrypted management tools such as Telnet or HTTP, in the logs of application layer firewalls, or in the logs of network devices. Network device owners and operators should review the Cisco documentation of their particular makes and models for strings that would allow the owner or operator to customize the list for an Intrusion Detection System (IDS). Detecting commands from Internet-based hosts should be a cause for concern and further investigation. Detecting these strings in network traffic or log files does not confirm compromise. Further analysis is necessary to remove false positives.
