RSG Model Works

It’s mid-2016. XP has been end-of-life for over a year or something. What’s that mean? It means there’s approximately a 100% chance that any given XP system is exploitable. It definitely means the system has exited the vendor’s maintenance window. Either way there are few if any reasons to justify use of XP from a security standpoint.

So when you hear about present-day XP deployments, it’s disturbing. Well before March of 2016 there should be zero XP deployments out there. “Oh, yeah, that’s an old recording appliance. It’s still running XP” is not the kind of thing you should hear at a PACS user group meeting.

It’s 2015. And yet some vendors are still shipping network-attached devices like… well, at least like it’s 1999, if not before.

We’re talking about Telnet. In 2015, do not use Telnet. It’s unencrypted and it can leak passwords to an adversary. This is not a news flash.

Telnet was really cool back in the day. The user didn’t have to be in front of the computer they wanted to access. They could – gasp – connect remotely.
In the intervening decades since telnet was first introduced, we’ve learned a few things about network security. For example, it’s bad to use unencrypted protocols if it can be avoided, specifically where an adversary could trace a password. Console connections through the “telnet” protocol are “in the clear” because they are exposed.

Telnet was developed last century. Here in the future in 2015, you can’t assume anything about the network between you and the remote device you’re logging in to. You have to assume somebody’s going to wire tap it. Either the bad guys, or some off-the-reservation sysadmin, or who knows what else. This means you have to assume any password you type into telnet is really in the clear. What should you do? Don’t run telnet. Use SSH or some other protected mechanism. At this point in the 21st century telnet is really quaint, outdated and sort of scandalously unsafe.

This happens repeatedly. Apparently we have to keep reinforcing this concept. See this post from 2011…
http://www.engadget.com/2011/01/31/hackers-increasingly-using-telnet-for-attacks-port-23-looking-y
I’d like to tell you I’ve not seen telnet deployed in new vendor products but it’s January 2015 and I’ve seen one this year already.

Check out https://plus.google.com. It’s got a certificate for “*.google.com”. Wildcard certs may be the “store the used control rods in the attic and forget about them” technical trick of the certificate world. But wait, it gets better. This was issued by the “Google Internet Authority”. This presumptuous name describes a Certificate Authority, operated by Google (a/k/a google.com), that is in turn signed by a GeoTrust root.

Uh, guys, the point of certificates was to introduce a “trusted third party” (see Wikipedia definition or use BING to search for the term yourself…)

When the company running the web site issues the cert for a public TLS-protected website, the point was to be able to trust it because SOMEONE ELSE was the trusted third party. That’s why they are the THIRD party (not the first party, the browser user, called the “relying party” in certificateSpeak, or the second party, the private key holder of the site being accessed via “https”.)

Other sites do this. Akamai has in the past (and may still) practice this “I’m the second party and the third party” stunt.

Is this bad? Yes, this is bad. There’s no trust here. You’re only trusting the web site operator. If they are compromised, or go rogue, you’ve got no recourse. Revoking the certificate is no longer a defense. Trusting the root is no longer a defense. And, it implies these retail certificate authorities will take money for all sorts of crazy non-trust-delivering practices.

Check out this . Note the hostname mismatch (it’s got a GeoTrust cert for www.adgrafics.com. Note the WEB TRUST seal in the upper right corner. Click on that, let Chrome kindly translate (appologies, I don’t read Russian or Ukranian.) Note the seal is from “https://webtrustukraineseal.com” (confused yet?) and THAT says “Verisign Trusted” (Verisign != GeoTrust.) Note also the default https://www.certificatesigningrequest.com:8443/ Plesk self-signed certificate.

So… you should trust these certificates? From several different CA’s, and from a site that uses self-signed certificates? Not to pick on Symantec’s Ukrainian trading partners… but really, are we supposed to trust these certificates? When the vendors are this sloppy?

After your enterprise has grown up enough to really need electricity all the time, uninterruptable power becomes a necessity.

In the 70’s if you drove through Waltham Massachusetts on Route 128 you could point out the large enterprises.  They all had a Cat diesel engine mounted on cinder blocks behind the building, set up to run a generator.  You’d put it six feet up on cinder blocks, behind the building so that for example a vehicle in the parking lot wouldn’t have a chance to crash into it.  I noticed these because to me a Caterpillar product was a farm tractor sold as far back as the 1930’s (my father sold three rail freight cars full of Cat D-series tractors one season.)  They looked quite silly to me, until I realized the IBM 370’s we were using would crash horribly if those Cats weren’t out in the back yard.

My point is that’s an OLD STORY.  Check out that “one page tsunami plan” news item on the internet.  Look for the AP version here. Check out picture 4 of the TEPCO-released images in the side bar (also below). That’s water gushing into the basement where the dieslel generators for the coastal nuclear power plant were deployed.

Yeah. After the boss buys you a UPS (because you did pass D/R 201), put it somewhere sensible.