update on the heartbleed situation

| | Comments (0)
So, billing-external.  What happened?

when this heartbleed news came out, I was... a little panicky.  Unwisely so.  The first thing I did was I dist-upgraded billing-external, then ran the heartbleed test, then  I took down ordering because i'm having a hard time getting my old key revoked.

so... yeah. looks like I took down ordering for no reason.   It was debian 5, thus not vulnerable to heartbleed.    The thing was, I did the dist-upgrade before I ran the heartbleed test (or even checked the openssl version.  Shame on me)    

Anyhow, it looks like it was not vulnerable to heartbleed at any point (though,  it /was/ debian 5... I should feel shame for running something out of support in production.)

Note, if billing-external /was/ compromised, the attacker would have been able to sniff passwords of any user that logged in to billing-external, but they would not have had full access to emails or password hashes; the database is on billing-internal;  billing internal is behind a statefull firewall; it initiates a connection (over ssh) to billing-external and opens a unix socket.   when you log in to billing-external, it sends your username and password down that socket to billing-internal, who authenticates you.   

(billing-internal and external are both running a thoroughly obsolete version of freeside, something that will be remedied within the next two months.)

I'll have the new key loaded and ordering back up later tonight.

The only other exposure to openSSL is our puppetmaster and our mailserver;  our mailserver was upgraded and given a new key,  and we've disabled puppet until I get a new puppetmaster up.     The mailserver is by far the scariest compromise;  if someone can read my email, they could probably transfer away the prgmr.com domain and cause all sorts of mischief.  But, nothing of the sort appeared to happen;  hopefully the worst thing that happened was that someone read some of my private emails.   (I have no evidence that anyone got that far... other than that the system was vulnerable to the heartbleed bug.)

Note, the puppetmaster doesn't have ssh private keys that allow it to log in to other hosts;  our puppet clients pull from the puppetmaster, so assuming a read-only attack, an attacker got a look at our configuration and some public keys.  

The risk that a compromise of the puppetmaster ssl key carries is if someone wanted to impersonate the puppetmaster.   This would require an attacker to spoof the puppetmaster's IP, which would require the attacker to be one of my customers, /and/ require me to have somehow screwed up or not set up the antispoof rules on that customer's dom0;   I mean, it's serious enough to warrant taking down puppet for now, but it's unlikely that anyone got in through that hole.  

Leave a comment

About this Entry

This page contains a single entry by luke published on April 9, 2014 9:36 PM.

Scheduled downtime on mantle was the previous entry in this blog.

Luke broke the rt (and support mail queue) last weekend. is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.