Attack Surface Management
‘Ident’- ifying SonicWall Email Security Appliances - An Odyssey
April 23, 2021
No matter how hard it is to fingerprint a technology, we will find a way to do it to ensure our customers are protected from a new zero day.
As the news broke about another zero day vulnerability in Sonicwall, we at Intrigue immediately set out to identify and protect vulnerable assets for our customers. Per our usual process, our first step is to use Intrigue Ident to fingerprint the technology before we test for the vulnerability itself. Fingerprinting Sonicwall Email Security turned out to be an adventure instead of the routine we are used to. Part of the reason was Sonicwall’s active measures to protect from scanners (more on that later). This post details what we went through to build the capability to identify the devices.
It started with the normal process... I’ll walk you through what I did....
DockerHub and other common image registries are not yielding any findings. Neither are Shodan, Publicwww or others… More searching needed. Google yields results, but primarily marketing material - not helpful. Too close for missiles, Time to find a trial version. Sonicwall’s website has a “contact sales button” - no budget authority here, but with a little luck and determination, we stumble on a website for live demos of Sonicwall software.
Let the games begin...
Amongst many other products, Sonicwall has a live demo for their email security product. Following the link to the demo, we are presented with a login that (from experience) does not look like the actual product.
A few quick searches on our usual sources and nothing comes up, so this is definitely not what we are looking for. It’s probably a specific page for their demo portal. We login and we are presented with another view, with a link to “Email Security Appliance” over https.
It's getting warmer…
Now we land on yet another login page. This time the expected Sonicwall appliance branding welcomes us, and with confidence we conclude that we have found the droids we were looking for.
In order to confirm, we check the aforementioned sources for live instances. Interesting enough, the usual suspects did not have any assets. Something feels weird, but nothing to do but continue. Using pieces of the HTML source and Google, we finally find one resource, ZoomEye that reliably can find Sonicwall Email Security Appliances. A total of 76 instances are identified - again it feels low given Sonicwall’s penetration but this is more than enough for our testing purposes.
Now The Real Work Begins, Again
We throw together an Intrigue Ident fingerprint for this appliance. Ident fingerprints are quick to write - you can see the structure here. Quick decisions are made - we want to look for the combination of <div id='loginCustomText' and <td class=\"logonTitle\">Email Security Login<\/td> to identify the software. Interestingly, and unexpectedly, the fingerprint doesn’t work on our first run.
Looking at the network tab while browsing to the appliance reveals that a number of requests and redirects are made. However, there is one anomaly. And it is very easy to miss.
Can you see it?
The first request to the root path returns a 200. OK. Yet, after being redirected from the original request three times we land at /login.html. This! Intrigue Ident was not identifying the asset because it never reached login.html. We look at the source and it's quite telling...
Equipped with this knowledge, we adjusted Intrigue Ident to hit the /index.html path. After testing against the instances found online, we verify that the fingerprint works as expected. (Bonus: Intrigue’s version extraction technology also extracts the firmware version of the appliance using the dynamic_version extractor. Handy for future vulnerability identification.).
With reliable fingerprinting now in place, we can now turn our attention to the vulnerability check.
We use this excellent research provided by Fireeye to develop a PoC which can be found here. The PoC sends a request to /createout?data= with dummy data. If the appliance is vulnerable, it will try to parse the dummy data as XML and return a parsing error. This is enough to conclude that the API is accessible and our PoC works. For patched appliances, the response returns a 401 error.
The Odyssey concludes...
Now, with both of these pieces in place, not only can we identify Sonicwall Email Security reliably as a technology, but we can also flag vulnerable instances in that process. Intrigue Enterprise customers benefit - effective immediately - from the automatic detection, and open source users can download the latest version of Intrigue Core and kick off a ‘Profile an Organization’ workflow to check their organization.
We’ve recently worked through similar efforts with Pulse Secure, Exchange and others - given the threat activity on these devices. If this sort of thing is interesting to you, join our community and come collaborate with us.