- SANS's Johannes Ullrich logged a Cisco IOS exploit attempt on a honeypot. It carried opt-out headers from RootEvidence, a vulnerability management platform.
- Ullrich could find no standard for those headers. Because they are self-declared, a defender cannot verify them.
- Leaders should ask who is allowed to scan their devices, and not rely on a scanner's own label as proof of intent.
A label is a claim, not a control
Security teams are used to sorting hostile traffic from friendly traffic. A small detail in a recent SANS Internet Storm Center diary shows how weak that sorting can be. The lesson here is that a scanner's own label is a claim. It is not a control.
Johannes Ullrich, Dean of Research at SANS.edu, was reviewing honeypot data for PHP exploit attempts. A honeypot is a decoy system that records whoever connects to it. He found a request aimed at Cisco IOS, the operating system on many Cisco network devices. He wrote that it was "still nothing new" and that he suspected it targeted CVE-2023-20198.
What the request did
The request was a POST to a web path on port 8000 of the honeypot. The path was /%77ebui_wsma_https. In URL encoding, %77 is a way of writing the letter w. A server that decodes paths would read this path as webui_wsma_https.
The body was an XML message in the SOAP format, a long-standing way for programs to send commands to each other. It carried a username, admin, and a masked password. It then asked the device to run a single command: uname -a.
How the technique works
The name of the path offers a clue. Many Cisco devices have a web management interface, where administrators configure the device from a browser. WSMA is a Cisco management interface that lets programs send commands to a device as XML messages. The urn:cisco:wsma-exec label in the request points to that kind of command service. This is general background. Ullrich only says he suspects CVE-2023-20198, and the diary does not describe the flaw.
The command is a second clue. As general background, uname is a Unix command, not a Cisco IOS one. On a Unix-style system, it prints basic system details. Ullrich highlighted it as the actual command. That it only gathers information is our inference. It would fit a scanner checking whether a device responds, and it would also fit the first step of an attacker.
The opt-out headers
The part Ullrich found more interesting was in the request headers. Two read Opt-Out-Email and Opt-Out-Url. The URL pointed to rootevidence.com/scanners. The user-agent, a header that names the client software, read RootEvidence/1.0.
Ullrich describes RootEvidence as another exposure and vulnerability management platform. He could not find a standard that proposes these headers. He thinks it is the first time he has seen them. RootEvidence has used them since December of last year, he wrote, but he only noticed them now.
Why a self-declared label falls short
The argument here is ours, not Ullrich's. Because these headers are unstandardised and self-declared, a defender cannot verify them. They cannot be relied on as proof of intent.
Nothing stops a hostile actor from copying them. That is a hypothetical, and the diary reports no case of it. It shows the limit of the signal. A header that anyone can write tells you little about who sent the request.
An opt-out header may still have value if a scanner honours opt-outs and a defender can confirm it. The diary does not say whether RootEvidence does either. This is a general point about scanners, not a claim about RootEvidence.
What the request did is easier to judge. It carried a username and a masked password to a device's management interface and asked for a command to run. The request's content is something a team can judge directly, without trusting a label.
Ullrich also made a guess about the encoded path. He said he bets some WAFs, or web application firewalls, fall for it. A WAF filters web traffic by matching known bad patterns. Ullrich offered this as a bet, not a test result. Teams can check it on their own filters.
Questions to put to your team
First, which internet-facing devices expose a management interface of the kind this request probed? Ullrich suspected CVE-2023-20198. Ask whether your team has checked each Cisco IOS device against that CVE.
Second, how does your team treat scanning traffic that identifies itself? If the answer is "we ignore it," ask who decided that, and on what evidence.
Third, do your web filters decode a request path before matching it? A short test with an encoded path would settle Ullrich's guess for your own setup.
Fourth, who is authorised to scan you? If an outside platform probes your devices, you want to know whether you hired it or whether it just showed up.
The single request in this diary is one data point. It does not show a trend. It does show why a header that anyone can write cannot be relied on as proof of intent.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: SANS Internet Storm Center.
