THC SSL Renegotiation DoS Tool for ESXi authd (port 902)

I had written about the Client-initiated SSL renegotiation DoS tool by THC and how to exploit SMTP STARTTLS mail servers with some modifications some time ago. At the time I’ve also noticed that to my surprise, Client-initiated SSL renegotiation is enabled by default on various vSphere/ESXi components and can be exploited with the THC Tool.

# openssl s_client -connect myesxi.local:443 -state -quiet -no_ign_eof <<< 'R' 
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
verify error:num=19:self signed certificate in certificate chain
verify return:0
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
RENEGOTIATING
SSL_connect:SSL renegotiate ciphers
SSL_connect:SSLv3 write client hello A
SSL_connect:SSLv3 read server hello A
verify error:num=19:self signed certificate in certificate chain
verify return:0
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
DONE

The CIM-SSL port 5989 for hardware status monitoring is is also renegotiating. This affects all currently known versions of ESXi, including the most latest 6.0 U2 and 5.5 U3releases. vCenter on at least ports 443, 7444, 9443 is also affected.

Continue reading

RC4 officially deprecated by RFC 7465

A new RFC 7465 has now been published that effectively calls for disabling RC4 everywhere:

   o  TLS clients MUST NOT include RC4 cipher suites in the ClientHello message.

   o  TLS servers MUST NOT select an RC4 cipher suite when a TLS client
      sends such a cipher suite in the ClientHello message.

   o  If the TLS client only offers RC4 cipher suites, the TLS server
      MUST terminate the handshake.  The TLS server MAY send the
      insufficient_security fatal alert in this case.

Cryptographic weaknesses around RC4 were known since many years, but in the beginning of 2013 they finally became feasible to exploit with some considerable, but not too huge of an effort.
The author of the RFC belongs to Microsoft, which published and advisory for disabling RC4 in November 2013 as well. However, Windows Server 2012 R2 with IIS 8.5 which was released in October 2013 still ships with RC4 enabled by default.

A lot of websites and “modern” software still use RC4 today. According to the SSL-Pulse statistics currently more than 60% of all SSL/TLS enabled websites still offer RC4.

It depends on the service and the security requirements, but at the moment I personally don’t see it that much of a problem in offering RC4 as a fallback, if you always prefer other secure ciphers.

Here are some examples of software or websites that still use RC4 in a manner it shouldn’t be used:

  • PayPal (server prefers RC4, though offers AES as well)
  • Youtube (the servers providing the actual video streams, not the general site; RC4 exclusively(!)) I Tested it last week but it seems like Youtube switched to offering and preferring other AES-based cipher suites just recently.
  • All versions of Windows Server and Client OSes, including the respective Internet Explorer enable RC4 by default
  • Some VMware products (at least the vCenter Web Client, and many virtual appliances; most seem to prefer AES though; ESXi hosts and vCenter service on port 443 and SSO on 7444 do not support RC4)
  • HP ILO interfaces (confirmed with ILO4 2.03, ILO3 1.80; prefers RC4)
  • Cisco IronPort Mail appliances seem to be using RC4 exclusively(!)
  • Check Point Gaia Portal web interface (tested with R77.20 with JHFA Take 77; RC4 exclusively(!))

Seems like there’s a lot of work waiting for vendors and website admins to disable RC4.
It’s a mystery to me how some popular websites or recent software releases can be released without support for any cipher suite besides RC4. And no, mitigating BEAST is not a valid excuse.

Error loading python dll when launching Anki after wine upgrade

ImageThis is at least the 2nd time it hit and took me some time to figure it out, so I might as well write it down here for future reference.

I was updating (read: breaking and re-compiling) a couple of packages on my good ‘ol Gentoo GNU/Linux Laptop, one of them being wine.
Yes, the platform of choice for running the most non-free software possible. Mr. Stallman does not approve.

I’m actually running the awesome flashcard program Anki in wine as opposed to it’s native GNU/Linux implementation. Why you may ask? Because it relies on many other bloaty-ish packages like QT which I want this system to be clean of. Instead of compiling another 350 MB of sources, running Anki in wine works quite well. I also use the unknown ion3 tiling window manager (RIP) on this system and am quite happy with it.

So anyways, after updating wine to 1.4, starting Anki in wine resulted in an ugly “Error loading python dll” error. I knew I’ve seen and fixed this before and the solution is actually quite simple:
All I needed to do was reinstalling Microsoft Visual C++ 2008 SP1 Redistributable in wine.
I have not the slightest idea how the upgrade manages to break this every time.