ONYPHE vs Shodan dorks

Written on 2021/07/08

We stumbled upon an article written by ESTEBAN BORGES from SecurityTrails. This article shows how to query our main competitor Shodan with a TOP40 of best search requests. We thought it was a good start to perform some form of benchmarking by showing how you can achieve the same results, in even better and easier ways, in order to find the most relevant information in your own context. Let’s dig into some of the TOP40 dorks by comparing Shodan results against ONYPHE results.

ONYPHE capabilities

We scan the full IPv4 Internet for roughly 200 ports on a monthly basis. Our goal is not only to identify assets with high precision, but also to give our customers the capability to find devices that belong to their organization in an easy and convenient way. Our approach is to first perform a inventory by starting from a domain name and pivoting around different values (or filters) that show clear ownership to a given organization.

For instance, when you have a domain name like example.com (filter domain:example.com, you may found some new fields giving attribution to the searched organization. For instance, the subject organization from an X.509 certificate is a wonderful pivot point. Thus, we just pivot on this new value (filter subject.organization:“Bitnami”) to find more assets linked to the given domain. Also, when a device is hosting more than one domain name, you can pivot on these new domains and create your organization’s owned domain list.

Also, we don’t just gather raw application responses in the data field, we do perform device identification. Our goal is to directly give the classification of the device: be it a VPN server, a database, or any of the other 60 device classifications we have in room. For instance, to get access to all exposed databases simply execute the filter device.class:database. Let’s show some examples based on the TOP40 dorks from SecurityTrails.

Free View vs Butterfly View vs Enterprise Views

With Free View, you can use a part of available search filters. You can also paste some strings or IP addresses and you will get a subset of available results we have within our search engine. That’s a subset because you can only see the 10 latest results. Also, some results will be protected at output. For instance, you can search for RDP or SSH services, but results will display ‘access denied by policy’. That’s a protection from abuse.

With Butterfly View, you will have access to search filters, but not to device classification or tags. Butterfly View is a good start if you want to test some of the dorks we describe in this write-up. Furthermore, you won’t have ‘access denied by policy’ anymore, you will see all details for all data you can search.

With Enterprise Views, you have access to all filters and all information categories.

That’s a short comparison of our three licensing models, you will have more details at the pricing page.

Databases

SecurityTrails article shows some way to find databases exposed on the Internet with or without authentication. That’s an excellent start to demonstrate our capabilities.

The first dork searches for open MongoDB instances with no authentication activated with Shodan:

"MongoDB Server Information" port:27017 -authentication

With ONYPHE and an Enterprise license, you can achieve the same objective without knowing the raw application response format, and, even better, without knowing the well-known port behind MongoDB. In fact, our solution performs protocol identification from the ground up. Of course, listening ports can be customized, but not really application responses. Here is the ONYPHE version of the previous query:

protocol:mongo tag:open

With a Butterfly View, you will only be able to search with the protocol filter part, which is kind of a good start, bug tag filter is only available to Enterprise Views.

We see that we have identified 4,685 open MongoDB instances vs 8,409 from our competitor. Please also note that we have other tags in red in the screenshot, for instance the fact that the database has been compromised and a ransomware note has been deployed.

Other interesting tabs are “Pivots” and “Analytics”. That’s where the magic operates: if you identify a pattern giving clear evidence the value is bound to a given organization, you can just pivot on that value and find other exposed devices for your target.

But this search is too limitative to us. The author wanted to find open databases exposed on the Internet. MongoDB is one of this kind, but there are also Elasticsearch, Kibana, Redis, Memcached, CouchDB and many others.

All of these applications are classified as databases within our solution. Just use the following filter to identify all of them:

device.class:database tag:open -monthago:1

This time, we identified more than 67,000 open databases for last month data. Yes, because we do also have historical records for the last 7 months in datascan category.

But you could also search by raw application responses if you are of that kind. For instance, the following dork:

"Set-Cookie: mongo-express=" "200 OK"

Can be translated and pasted within our search engine by prefixing with data filter:

data:“Set-Cookie: mongo-express=” data:“200 OK”

For MySQL & PostgreSQL related databases, simply search with a protocol filter:

protocol:mysql protocol:pgsql

To search for Elasticsearch databases with their list of indices:

app.http.component.product:elasticsearch -exists:summary

The summary field contains a subset of raw application responses: just the most important patterns. You can search the summary field like the data field, that is by using keywords like any full-text search engine. However the -exists function is only available to Enterprise Views. But you don’t need -exists to execute searches against the field anyway. Example to identify private information:

device.class:database summary:private

That’s some easy ways to search databases, right?

Exposed ports

As we said at the start of this article, we are currently scanning for roughly 200 ports on a per month basis. Of course, you can search by port if you will. But we strongly encourage you to adopt the described “by-protocol-approach” instead. SSH is not always on port 22.

The first query shown in SecurityTrails article is to search for exposed ProFTPD products. We also identify products, whatever the port they listen to. The following search:

proftpd port:21

Becomes:

product:proftpd protocol:ftp

It appears the author wanted to search for anonymous accesses using the following search:

"220" "230 Login successful." port:21

Well, we do have a specific protocol-level filter for such kind of searches:

app.ftp.anonymous:true

That’s a nice comparison: our competitor has found 93,204 anonymous FTP servers while we found 1,314,760.

Now you probably got the point what is the difference between our competitor and our search engine. We want to simplify analysts work by giving them directly the information they need, and to get that, they don’t have to know which strings they want to search for.

So, the following dorks:

openssh port:22
port:"23"
port:"25" product:"exim"
port:"11211" product:"Memcached"

Respectively become:


Simple as that. Don’t bother with port numbers anymore.

As for a last one, the Jenkins dork:

"X-Jenkins" "Set-Cookie: JSESSIONID" http.title:"Dashboard"

Becomes the following search with ONYPHE:

data:“X-Jenkins” data:“Set-Cookie: JSESSIONID” app.http.title:“Dashboard”

Notice the change between http.title vs app.http.title with our solution. You could also have searched with the following filter to avoid putting your own strings in the search:

app.http.component.product:jenkins app.http.title:“Dashboard”

Which yields even more results than the first query from our solution: 4,785 vs 7,810.

Conclusion

We are done with this write-up related to benchmarking our solution versus our competitor Shodan. We showed how easy it is to find open databases for a given organization thanks to our domain filter. Our goal is simply to always have a domain field related to data we gather to make it easy to map a target External Attack Surface.

We are sure you enjoyed reading this write-up as much as enjoyed writing it 🙂 we take the time here to thank SecurityTrails as they allowed us, to the best extent possible, to make an impartial comparison with one of our major competitor.

Interested in our solution? Just contact us if you want a demo.