The old adage of “measure twice, cut once” is solid advice that is often ignored in the digital world. We at OpenDNS, however, believe that when talking about IP-enabled devices, a new and more targeted adage should be followed:
“Read [the documentation] twice, connect [the device] once.” – Andrew Hay
Here’s why. We all live busy lives. So busy, in fact, that many believe that computer printers haven’t really changed much over the years to warrant reading the instructions. Sure, many newer models can be connected to your local network but that’s only for internal network connectivity, right? Unfortunately, that is not the case.
The Discovery
While conducting some research, we happened to notice a rather odd domain name that a particular server was beaconing out to. The domain in question was xeroxdiscoverysupernode3.com. Initially, we figured that the domain could be malware or phishing related as the likelihood of Xerox Corporation using such a long domain was relatively low. Upon further investigation, the xeroxdiscoverysupernode3 domain wasn’t even registered. Could a piece of malware have been constructed to call out to this specific domain to download additional files? Why wouldn’t the malware author register the domain ahead of time if that was the plan?
As this domain ended in the number 3, we pondered the idea of there being a ‘1’, ‘2’, or maybe even a ‘4’ numbered domain that followed this same pattern. It turned out that xeroxdiscoverysupernode1, xeroxdiscoverysupernode2, and xeroxdiscoverysupernode3 were actively being queried for within the OpenDNS global infrastructure. Not only were the domains being queried, but each was receiving roughly 2,000 queries per hour (as seen below). The plot thickens.
We began searching Google for the domains in question by using the following search string:
https://www.google.com/search?hl=en&as_q=xeroxdiscoverysupernode1+xeroxdiscoverysupernode2+xeroxdiscoverysupernode3
Without much difficulty we were able to find several official Xerox documents that detailed the purpose of the domains. The Xerox® WorkCentre® 5845/5855/5865/5875/5890 System Administrator Guide talks about the McAfee Embedded Control features that provides 2 specific security functions:
1) Enhanced Security maintains the integrity of printer software by monitoring system files and alerting you if an unauthorized change is made to a system file.
2) Integrity Control is a software option that combines enhanced security features with the ability to monitor and prevent unauthorized executable files from running. Enable this option by providing a feature installation key on the Feature Installation page.
Deeper into the documentation, we noticed a section entitled Designating Printers as Super Nodes. According to the documentation, the “Xerox® extension for McAfee [ePolicy Orchestrator] ePO uses up to three Xerox® printers as supernodes to communicate with the other Xerox® printers that it monitors. Xerox recommends that you designate more than one Xerox® printer as a supernode. If one supernode is not functioning or is offline, McAfee ePO can use the other supernodes to communicate with other printers. You designate printers as supernodes by adding specific entries to your DNS server.” The section continues to state that “Your Xerox® printers and your McAfee ePO server must use the same DNS server.”
The first mention of the suspicious domains shows up in the Adding DNS Entries to One or More Existing Domains section. It states:
If you have a small number of domains in your network, use this method to add DNS entries to each domain.
On your DNS server, find the domain of each printer that you want to designate as a supernode.
For each domain, add entries for all supernodes, then name them:
– XeroxDiscoverySuperNode1
– XeroxDiscoverySuperNode2
– XeroxDiscoverySuperNode3
If your network uses more than one DNS server, repeat the previous step for all other DNS servers. If you have a large number of domains in your network, use this method to add DNS entries to a single domain.
On your DNS server, create a domain named Xerox.local. The Xerox extension for McAfee ePO looks for a domain with this name.
For Xerox.local, add entries for each supernode, then name them:
– XeroxDiscoverySuperNode1
– XeroxDiscoverySuperNode2
– XeroxDiscoverySuperNode3
Note that it doesn’t say xeroxdiscoverysupernode[1-3].com, just the domain without the TLD. It should also be noted that neither Xerox, nor McAfee, show any results for a ‘xeroxdiscoverysupernode’ query on their respective sites:
– http://www.xerox.com/search?q=xeroxdiscoverysupernode
– http://www.mcafee.com/apps/search/default.aspx?region=us&q=xeroxdiscoverysupernode&searchSubmit=Go
Looking at the OpenDNS query traffic for April 17 through April 20, 2014 (inclusive) we were able to identify 142 unique hostnames attempting to query the three xeroxdiscoverysupernode domains. A map indicating the approximate host geolocations can be seen below.
The Domains and The External Sinkhole
Further Google searches also lead us to Internet Corporation for Assigned Names and Numbers (ICANN) List of rSecond-Level Domains (SLDs) to Block list which expressly calls out the three suspicious domains.
In an effort to proactively deny the use of these domains by potentially malicious
users, we registered the 3 domains and pointed them at a VPS. This server acted as an external sinkhole of sorts for all public queries to the xeroxdiscoverysupernode[1-3].com domains. On the external sinkhole we ran several packet captures using tcpdump to identify some ports associated with Xerox printers. With our port samples we went back to the Xerox documentation. The port that jumped out almost immediately was port 3702.
Unfortunately, the information about the port was quite limited in the Xerox® WorkCentre® 5845/5855/5865/5875/5890 System Administrator Guide – stating only that it was “WS-Discovery (UDP port 3702)”. As we were seeing both TCP and UDP on this particular port, back to Google we went looking for keywords like “xerox+3702+tcp+udp filetype:pdf”. It wasn’t long before we found 38,900 results. The most descriptive was the Xerox WorkCentre™ 7525/7530/7535/7545/7556
Information Assurance Disclosure Paper Version 1.1 document which stated:
2.8.2.21. Port 3702, WSD Discovery, WS Discovery Multicast
This is the default port for WS-Discovery (the discovery of services in an ad hoc network with a minimum of networking services (for example, no DNS, UDDI or other directory services). It does this by announcing or advertising the existence of the printer and its services on the network when it becomes available, and announcing its departure when unavailable. The default state is selected (enabled).
(Note: emphasis added)
Further investigations on the WS-Discovery protocol led me to several sites which described the protocol, including:
– WS-Discovery From Wikipedia, the free encyclopedia,
– Windows 2003 Web Services Dynamic Discovery (WS-Discovery)
– OASIS Web Services Dynamic Discovery (WS-Discovery) Version 1.1
It looked as though we had found what we were looking for. To monitor the traffic more easily, we installed ntopng to get a sense of just how many queries were being made. As you can see from the cumulative stats below, quite a bit of traffic was heading towards the server.
Analysis of the domains shows 327 unique hosts querying the external sinkhole. The map on the left shows the OpenDNS queries and the right-hand side shows the external sinkhole queries.
The combination of both OpenDNS client queries and the external sinkhole queries results in 422 unique hosts. The map below shows the cumulative hosts.
The OpenDNS Sinkhole
At this point we decided to sinkhole the domains for OpenDNS customers and monitor the queries. The internal sinkhole showed SOAP queries that resembled the following:
{
"dport": 3702,
"ip_src": "a.b.c.d",
"payload": "POST / HTTP/1.1rnHost: 54.193.55.93:3702rnUser-Agent: gSOAP/2.8rnContent-Type: application/soap+xml; charset=utf-8; action="http://schemas.xmlsoap.org/ws/2005/04/discovery/Hello"rnContent-Length: 2268rnConnection: closernSOAPAction: "http://schemas.xmlsoap.org/ws/2005/04/discovery/Hello"rnrnn<wsa",
"ts": 1398203136
}
The SOAP requests confirmed that port 3702 queries were, in fact, WSD queries. It would be a trivial exercise to write a client to interact with this request as the protocol information is freely available and relatively easy to understand (see the external presentation below).
Web Services Discovery for Devices from Jorgen Thelin
Setting up a ‘fake’ WSD server could potentially allow a malicious user to do any number of things from sending print jobs to printers to tie up resources, pushing down customized drivers to allow further access, or even something as simple as reseting the devices back to factory defaults to deny people access to the devices.
Alex Stamos, formally of iSec Partners and now the CISO of Yahoo!, had a fantastic presentation entitled Attacking Web Services: The Next Generation of Vulnerable Enterprise Applications that he presented at CanSecWest in 2006 that provided quite a bit of background on how web services could be exploited.
It is entirely possible that someone has already attempted to perform some form of malicious act using these super node domain names. Looking at OpenDNS Investigate we can see that the xeroxdiscoverysupernode3.com domain has a co-occurrence with a suspicious looking domain (seen below):
As presented in Frank Denis’ blog post, the infection chain for serving a single piece of malware is frequently made of many, constantly-changing domains. The security community finds thousands of new sites serving malware or acting as intermediaries every day. Hosts used to control botnets are also constantly changing in order to be resilient to takedowns. The cizjvdm…qsyd.biz domain has a very high DGA score which is indicative of a domain that was randomly generated by an algorithm.
Another observation is that the domain in question has co-occurrences with other DGAs which could indicate a malicious campaign of some sort.
Interesting, but not yet conclusive. Further investigation by the OpenDNS Security Labs on these domains may shed some light on the campaign objectives.
Who is affected?
We do not want to implicate the individual companies observed but we did, however, want to provide a breakdown of the vertical industries represented in the traffic:
– Automotive
– Consumer
– Engineering
– Energy
– Oil and Gas
– Fast-Moving Consumer Goods (FMCG)
– Food and beverage
– Healthcare
– Insurance
– Manufacturing
– Retail
– Technology
– Telecommunications
There were also 5 companies listed in the Fortune 500 which means that this issue is not isolated to organizations of any size or security program maturity level.
As stated previously, OpenDNS has added the xeroxdiscoverysupernode[1-3].com domains to our sinkhole server, providing protection for all users of our DNS service (both free and paid). We will also continue to operate the external sinkhole for the time being but may opt to forward the queries for the super node domains to a dead IP instead of an actual live server. This would prevent anyone from using the super node domains for malicious purposes.
Had we not registered the domains and/or sinkholed the traffic, it’s entirely possible that a malicious actor could have exploited this threat vector to gain access to numerous printers, and potentially internal networks, around the world.
So what are the next steps?
Beaconing of this nature could serve to alert a potential attacker to the technology assets within your organization (or home). Do you really need the world to know that you’re using a specific brand of printer? Probably not.
At an absolute minimum, you should add these domain names to your internal DNS servers to ensure that future queries never leave your network. You may also want to add firewall and/or IPS rules to block domain-level access to the super node domains.
For individuals or organizations with any IP-enabled devices, from printers to scanners to wireless access points, OpenDNS highly recommends that you allocate time to review the documentation, configuration settings, and software/firmware version. For existing devices, a frequent review process should exist as part of the device lifecycle management policy and device-specific procedure. For new devices…read the documentation twice, connect the device once! Never put anything on your corporate or home network without first understanding its expected behavior.
This threat vector would not exist if documentation was read carefully and devices were not carelessly introduced into corporate and home networks.
We hope you have found this post educational. Thanks for reading!
Photo Credit: Truthout.org via Compfight cc
