dc:14:de:8e:d7:c1:15:43:23:82:25:81:d2:59:e8:c0

And there are many more fingerprints that are also duplicated, which you can check out yourself using the following Python code:

import shodan

api = shodan.Shodan(YOUR_API_KEY)

# Get the top 1,000 duplicated SSH fingerprints
results = api.count('port:22', facets=[('ssh.fingerprint', 1000)])

for facet in results['facets']['ssh.fingerprint']:
    print '%s --> %s' % (facet['value'], facet['count'])

Going back to the fingerprint mentioned above, when you plug that into Shodan the picture becomes somewhat clearer:

It looks like all devices with the fingerprint are Dropbear SSH instances that have been deployed by Telefonica de Espana. It appears that some of their networking equipment comes setup with SSH by default, and the manufacturer decided to re-use the same operating system image across all devices.

The next duplicated fingerprint on the list comes in at around 200,000 devices, followed by another one used by 150,000 devices. By analyzing the facets it's easy to get a picture of systemic issues that plague both hardware manufacturers as well as ISPs/ hosting providers. I've uploaded a list of unique fingerprints and their counts to the following Gist location:

https://gist.github.com/achillean/07f7f1e6b0e6e113a33c

Feel free to download the CSV and start analyzing the duplicated fingerprints because there are a lot of them. I wouldn't be surprised if you'd uncover interesting security issues by analyzing why these things are misconfigured.

After spending some time fixing bugs and making sure it scales, I'm happy to say that Shodan is now also collecting the following information:

• Parsed certificate
• Certificate chain
• Supported SSL versions
• Preferred cipher

All the SSL information has been put into property on the top-level called ssl instead of being dug into the opts field. This is how it looks like right now:

"ssl": {
    "cert": {
        "sig_alg": "sha1WithRSAEncryption",
        "issued": "20110325103212Z",
        "expires": "20120324103212Z",
        "expired": true,
        "version": 2,
        "extensions": [{
            "data": "\u0003\u0002\u0006@",
            "name": "nsCertType"
        }],
        "serial": 10104044343792293356,
        "issuer": {
            "C": "TW",
            "L": "TAIPEI",
            "O": "CAMEO",
            "ST": "TAIWAN"
        },
        "pubkey": {
            "bits": 1024,
            "type": "rsa"
        },
        "subject": {
            "C": "TW",
            "L": "TAIPEI",
            "O": "CAMEO",
            "ST": "TAIWAN"
        }
    },
    "cipher": {
        "version": "TLSv1/SSLv3",
        "bits": 256,
        "name": "AES256-SHA"
    },
    "chain": ["-----BEGIN CERTIFICATE-----  \nMIICETCCAXqgAwIBAgIJAIw4xswSiNXsMA0GCSqGSIb3DQEBBQUAMD8xCzAJBgNV\nBAYTAlRXMQ8wDQYDVQQIEwZUQUlXQU4xDzANBgNVBAcTBlRBSVBFSTEOMAwGA1UE\nChMFQ0FNRU8wHhcNMTEwMzI1MTAzMjEyWhcNMTIwMzI0MTAzMjEyWjA/MQswCQYD\nVQQGEwJUVzEPMA0GA1UECBMGVEFJV0FOMQ8wDQYDVQQHEwZUQUlQRUkxDjAMBgNV\nBAoTBUNBTUVPMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCj8HWSuWUHYWLD\nASV1KCWd9+9U19tINKgY8CTw/gKeVoF6bjgQ3tuXliScLAsU8nNGiZibaXq9KR67\nnLjjHzFiJDr6s8M3qimLdhcA7kf71v806Mls4KctdrMUiX3Bc7WvYtbClke0QDlC\nFGgK7HksEWpQ026E3pI0T/2mTvbeXQIDAQABoxUwEzARBglghkgBhvhCAQEEBAMC\nBkAwDQYJKoZIhvcNAQEFBQADgYEANbiCHCROX0X9ZbBaOsijkGh6+7WLaLUDEUpp\nrw+bHFKhOvtQgEyQ01U0V9ZYtdPyVLnNVmJu6Q8MPuqBCkpcv0/gH31YSSRyOhid\nvc+qCUCA7UBqt5f7QVOOYPqhzieoUO+pmQ3zidcwUGYh19gQv/fl7SnG00cDgxg3\nm89S7ao=\n-----END CERTIFICATE-----\n"],
    "versions": ["TLSv1", "SSLv3", "-SSLv2", "-TLSv1.1", "-TLSv1.2"]
}

The ssl.versions field is a list of SSL versions that the device permits and denies. If the version has a - (dash) in front of the version, then the device does not support that SSL version. If the version doesn't begin with a -, then the service supports the given SSL version. For example, the above server supports:

• TLSv1
• SSLv3

And it denies versions:

• SSLv2
• TLSv1.1
• TLSv1.2

The information that used to be stored in the opts.pem field is now available in the ssl.chain field, which is basically an array of PEM-serialized certificates. If you'd like to access the parsed information of the service's main certificate then you can get that directly from the ssl.cert property. It's the parsed SSL certificate made accessible in a programmer-friendly way (parsing certificates can be a pain...).

New SSL Filters and Facets

Alongside these new properties, I'm also re-introducing revamped SSL filters and facets. The following new filters and facets are available in Shodan to search the SSL data:

• ssl.chain_count
• ssl.version
• ssl.cert.alg
• ssl.cert.expired
• ssl.cert.extension
• ssl.cert.serial
• ssl.cert.pubkey.bits
• ssl.cert.pubkey.type
• ssl.cipher.version
• ssl.cipher.bits
• ssl.cipher.name

Using these filters, you can for example keep track of devices that only allow SSLv2 - a deprecated version of SSL that nothing should exclusively support:

ssl.version:sslv2

Or you can generate a distribution of certificate chain lengths by faceting on ssl.chain_count:

The above chart shows that the majority of SSL certificates are self-signed and don't trace back to a root.

The reports that Shodan generates also take advantage of this new SSL information, so keep an eye out for those charts in your new reports. For example, here's a general report on the state of SSL usage on the Internet:

https://www.shodan.io/report/EvoSNCVF

I'm excited to be collecting this new data and I'd love to hear your thoughts (@achillean). As always, if there's something you'd like to see me add just send me an email