SSL: Another reason not to ignore IPv6
Currently, many public web sites that allow access via IPv6 do so via proxies. This is seen as the "quick fix", as it requires minimum changes to the site itself. As far as the web application is concerned, all incoming traffic is IPv4.
The most obvious issue here is logging, in that the application only "sees" the proxies IP address, unless it inspects headers added by the proxy, which will no point to (unreadable?) IPv6 addresses.
But there is another issue: SSL Certificates. If only IPv6 connections are passed via the proxy, you will end up with two different certificate: One for the proxy, and one for the web application (or the IPv4 proxy). It may also happen that the IPv6 and IPv4 site are considered two different hosts on the web server, requiring distinct configurations.
For example, at this point, "www.socialsecurity.gov" uses two different certificates. One for IPv6 and one for IPv4. The IPv6 certifiate is expired, while the IPv4 certificate is valid. This is in particularly painful as some simple comand line tools, like "openssl s_client' are still not able to work over IPv6. For my test, I used gnutls-cli, which works similar to openssl s_client but supports IPv6.
Excerpt from the result:
gnutls-cli -p 443 --x509cafile /opt/local/share/ncat/ca-bundle.crt www.socialsecurity.gov Processed 291 CA certificate(s). Resolving 'www.socialsecurity.gov'... Connecting to '2001:1930:c01::aaaa:443'... [...] - subject `C=US,ST=maryland,L=baltimore,O=social security administration,OU=diias,OU=Terms of use at www.verisign.com/rpa (c)05,CN=www.socialsecurity.gov', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)10,CN=VeriSign Class 3 Secure Server CA - G3', RSA key 1024 bits, signed using RSA-SHA1, activated `2012-04-05 00:00:00 UTC', expires `2013-04-29 23:59:59 UTC', SHA-1 fingerprint `3286afd908f256947b396dbae88d37b111c9aaaf' [...] - Status: The certificate is NOT trusted. The certificate chain uses expired certificate. *** Verifying server certificate failed... *** Fatal error: Error in the certificate. *** Handshake has failed GnuTLS error: Error in the certificate.
Next, lets try IPv4. A disadvantage of gnutls-cli is that you are not able to force an IPv4 connection, so I will just fall back to openssl here:
$ openssl s_client -connect www.socialsecurity.gov:443 -CAfile /opt/local/share/ncat/ca-bundle.crt [....] subject=/C=US/ST=maryland/L=baltimore/O=social security administration/OU=diias/OU=Terms of use at www.verisign.com/rpa (c)05/CN=www.socialsecurity.gov issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3 [...]
$ openssl x509 -in /tmp/ssa.gov -text [...] Validity Not Before: Apr 22 00:00:00 2013 GMT Not After : Apr 30 23:59:59 2017 GMT Subject: C=US, ST=maryland, L=baltimore, O=social security administration, OU=diias, OU=Terms of use at www.verisign.com/rpa (c)05, CN=www.socialsecurity.gov
------ Johannes B. Ullrich, Ph.D. SANS Technology Institute Twitter
e-netprotections.su ?
Like with .biz, I sometimes have the impression that .su and .cc could be sinkholed in their entirety, because the bad domains seem to vastly outnumber whatever (if any) good is running under these TLDs as well.
Earlier today, ISC reader Michael contacted us with information that several PCs on his network had started to communicate with iestats.cc, emstats.su, ehistats.su, e-protections.su and a couple other domains. I was pretty sure that I had seen the latter domain on an earlier occasion in a malware outbreak, but I couldn't find it in our records .. until I only searched for "e-protections", and found e-protections.cc. This domain had been implicated back in October 2012 in a malware spree that was linked to the nasty W32.Caphaw, a backdoor/information stealer. The similarity of the names was too much of a coincidence, and it meant bad news for Michael.
Looking at what was captured by some of our network sensors allowed to reconstruct a (partial) picture of the IPs and ASN's involved in today's malware wave
Domain | IP | AS | Provider | Country |
---|---|---|---|---|
ppetoc.iestats.cc | 64.85.161.67 | 30517 | Great Lakes Comnet | USA |
ppetoc.iestats.cc | 85.25.132.55 | 8972 | PlusServer Intergenia AG | Germany |
ppetoc.iestats.cc | 173.224.210.244 | 40676 | Psychz Networks | USA |
ppetoc.iestats.cc | 178.63.172.88 | 24940 | Hetzner Online AG | Germany |
ppetoc.iestats.cc | 188.95.48.152 | 57172 | Global Layer B.V. | Netherlands |
The host name portion for some of the domains looks like it is time dependent (incrementing ascii) whereas other domains use (apparently) random names like d3acofzi7hjft.e-protections.su. Name servers involved today include ns1.abercrombienfr.net (currently 199.68.199.178 - AS1426) and ns1.semi-spa.net (currently 91.227.220.104 - AS50300). I doubt the former has anything to do with the clothing store, the domain was created four months ago.
Closer inspection of Michael's PCs revealed that each infected box was apparently running a slightly different version of the EXE. Anti-Virus coverage is still thin (Virustotal) , but the Heuristics of some products seem to be catching on. This sample looks more like a ransomware trojan than Caphaw, but we'll know more once we analyze all the information gathered so far.
If you have information to add on this particular malware or the domains mentioned, please comment below, or use our contact form.
Comments