Top Website Defacers: June 2015

John Matherly — Sun, 14 Jun 2015 18:44:16 GMT

I wanted to revisit the results of an earlier post this year on how to track website defacements and see how things have changed since then. In case you're wondering how this data is collected, I've created a video that shows in real-time the commands I used to generate the data:

Here's the Top 10 Website Defacers as of June 2015:

GHoST61: 49
El Moujahidin: 31
r00t-x: 29
Ashiyane Digital Security Team
Best Cracker: 22
TechnicaL: 20
virus3033: 17
A.N.T: 15
KkK1337: 14
MR Error ..: 14

GHoST61 also topped the ranking earlier this year and remains at the top at the moment. Other familiar names are: r00t-x (moved up 4 ranks), TechnicaL (moved up 3 ranks) and Best Cracker (moved up 1 rank). This means that 4 of out of the previous top 10 are still around, while the other 6 weren't listed before.

In terms of organizations containing defaced websites, the Ecommerce Corporation remains the most affected by far. After publishing the last blog post some people rightly questioned whether Ecommerce corporation had just been hit with an attack and I happened to do my report right afterwards. This follow-up data makes it clear that there are systemic problems at the company and how they setup/ respond to incidents.

Keeping Up with SSL

John Matherly — Mon, 16 Feb 2015 23:55:00 GMT

SSL is becoming an evermore important aspect of serving and consuming content on the Internet, so it's only fit that Shodan extends the information that it gathers for every SSL-capable service. The banners for SSL services, such as HTTPS, have included the certificate in PEM format for a long time and you've been able to access that data through the REST API or real-time stream.

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

Reports - Shodan Blog

Top Website Defacers: June 2015

Keeping Up with SSL

New SSL Filters and Facets