Building The Net

Heartbleed – What is it? (for non geeks)

The Heartbleed bug was caused by a programming error in a software package called OpenSSL. This error had the potential of allowing bad people to attach to secure web and email servers, as well as services that rely on the TLS/SSL protocol, and steal the private encryption key off the servers. The TLS/SSL protocol is what puts the pretty little lock in the address bar in your browser. The private key is what the owners of the sites you go to are suppose to keep secret, and not share with anyone because if someone has it, they can decrypt the encrypted data traveling between your system and the server. THIS IS BAD…

Heartbleed – What is it? (for geeks)

The Heartbleed bug was caused by a programming error in the OpenSSL library that deals with TLS handshakes. A couple years back, a new RFC (rfc 6520) proposed a new extension to the TLS protocol that would allow a heartbeat to be exchanged between the client and server to reduce the number of re-negotiations during a TLS session. This all sounds good, and actually is a very beneficial to the protocol in general, but when it was implemented in OpenSSL, an error in the way the code was written allowed a request to grab a bunch of data without checking the boundaries of the data itself. This could allow someone to make a request crafted in a certain way that would cause OpenSSL to return 64k of protected memory data possibly containing the SSL private key of the server.

Read more »

Millions of LinkedIn, E-Harmony, and Last.fm password hashes posted on message board.

Well, if we have learned anything from the past, if it can go wrong, it will… Although this has been downplayed by the companies involved,  there is no doubt in my mind that many people will be effected by this compromise. Once again, public networking sites storing user data on the internet, have failed to protect that data, and worse, have tried to hide the importance of this compromise. This is sad, but certainly is nothing new. We can take some comfort in the fact that these companies at least used sha1 hashing when storing the password data. Thing is, we don’t know what other information was compromised besides the passwords.

Read more »

SIP brute force attacks escalate over Halloween weekend.

Looks like the bad guys were up to no good again this weekend. SIP based PBX operators reported a huge increase in bogus registration attempts against their systems over the Halloween weekend. Our hosted PBX farm experienced this increase first hand. Logs showed an attack from a new and unique IP address about every minute. At the end of the weekend, over 1300 unique IP addresses were logged.

Read more »

Amazon Brute Force SIP Attacks – Dave Michels Interviews Me.

Shortly After my “SIP Brute Force Attack Originating From Amazon EC2 Hosts” post, Dave Michels interviewed me for an article Dark Side of the Cloud. This is that interview:

Dave:   What do you believe the intent was of the attacks? Free long distance?

Stu: Certainly free long distance would be one reason… But there are many other reasons to hijack a SIP account. I’m sure that organized crime would pay for a block of active SIP logins. They could use them to circumvent surveillance, or possibly use them for fraudulent boiler room calls about extended warranties and such.

Remember, most folks still believe that the Telephone System is secure… They tend to believe someone who is calling them.

Read more »

SIP Brute Force Attack Originating From Amazon EC2 Hosts.

I woke up Saturday morning to find strangely high network activity on some of our inbound connections. After a quick review, it turned out that most of the traffic was going into several of our hosted PBX systems. After a little more digging, I discovered that several systems on the Amazon EC2 network were preforming brute force attacks, against our VoIP servers. They were attempting to guess user names and passwords for our SIP clients. I immediately blocked all traffic from the attacking IPs and examined the logs. Thankfully, I found that non of the attacks had succeeded in guessing passwords.

Read more »