From a pool of 11 million scans of HTTPS sites, I could only find ~265k targets with SSLv2 enabled [1]. That's 2.4%, not 25%.
A breakdown of the type of target that have SSLv2 enabled would be useful to understand how they reached that number. It's possible that they scanned much much more than HTTPS on port 443, and found a lot of embedded devices with poor SSL configurations.
[edit] the page https://drownattack.com/top-sites shows that sites like yahoo.com are vulnerable, but there are no details as to why it is listed vulnerable. yahoo.com does not allows connections with SSLv2, but some of its subdomains do, so maybe the top-level domain is listed because some of its subdomains are vulnerable?
That seems to make sense, given that any SSLv2 service using a pubkey that's used on a non-SSLv2 service can be used in an attack against the latter.
The main takeaway from this is probably that it's a good idea to separate your SSL keys by service (or, more specifically, by DISTINCT($attack_surface), where $attack_surface is your software stack, OpSec, etc.). This would limit the impact of a number of vulnerabilities (think: Heartbleed) and should generally become a best-practice.
Due to CVE-2015-3197, many servers using OpenSSL reported they supported no SSLv2 ciphers, which causes OpenSSL-based SSLv2 clients to hang up. However, if you aggressively choose a cipher and continue the handshake, the server will still negotiate the connection. As a result, most existing scanning tools vastly underestimate SSLv2 support.
It's not enough to not run SSLv2 on the target; SSLv2 can't be available on any server that shares the same RSA keypair. It's a cross protocol attack, where attackers use the SSLv2 server as a tool to attack the TLS server.
A breakdown of the type of target that have SSLv2 enabled would be useful to understand how they reached that number. It's possible that they scanned much much more than HTTPS on port 443, and found a lot of embedded devices with poor SSL configurations.
At any rate, you should verify the configuration of your websites. There are many tools to do that, and we publish configuration sample to make it easy: https://mozilla.github.io/server-side-tls/ssl-config-generat...
[1] https://twitter.com/jvehent/status/704657734810148864
[edit] the page https://drownattack.com/top-sites shows that sites like yahoo.com are vulnerable, but there are no details as to why it is listed vulnerable. yahoo.com does not allows connections with SSLv2, but some of its subdomains do, so maybe the top-level domain is listed because some of its subdomains are vulnerable?
[edit 2] according to one of the researcher, the scanner "check if pubkey (not cert) runs on SSLv2. Then mark all others with that pubkey vuln" (src: https://twitter.com/seecurity/status/704665265712308224)