Never Anger a Pentester: Lessons in Security, Privacy, and OTR

The ‘Revenge Served Warm’ Introduction

One of our pentesters, Dennis, doesn’t seem to believe revenge is a dish best served cold–and he’s actually quite good at serving it up warm. The story I’m about to tell you is one with many lessons, including:

1. You should never take your privacy for granted.
2. It’s best to have people who don’t administer your network auditing it.
3. You should actually listen to those people who audit your network.
4. NEVER anger a pentester.

Off-the-Record Messaging

There is a fantastic tool for IM privacy called OTR (stands for Off-the-Record). It enables two users to communicate privately over what would otherwise be an insecure channel, such as a public IM server (or, as we learn later, a private IM server). I’m not the best person to speak about it from a technical standpoint, but you can read about it on their website.

OTR does come with all of the important privacy bells and whistles though, such as: encryption, authentication, deniability, and perfect forward secrecy. It comes as a plugin for Pidgin, integrated into Adium (for Mac OS X), as a general library you can use in your own applications. Basically, there’s isn’t a reason not to use it. Which is funny, actually, because that’s exactly what the initial disagreement was all about.

Did we really NEED OTR?

The initial disagreement was simple. When using a privately controlled XMPP server, with properly configured SSL settings, was it necessary to use OTR all the time? There was no question that it should be used when sending sensitive information, such as passwords, but did we need to use it for our everyday communications?

The “Yes” Side

On one side of the debate was our pentest department, who said yes, every message you send should be protected by OTR, even if for no other reason than everything you say is valuable to a would-be attacker. On the other side was me, who said that anything sensitive you say should be protected, but the day-to-day conversation was sufficiently protected by the SSL of the private server.

And The Other Side…

Now, no one will ever tell you that I’m a level headed or reasonable person. So, my natural (and in no way irrational overreaction) was to completely disable OTR. If I need to secure my communications, I said, I would use PGP to encrypt those communications myself. At first, I thought they would settle this argument by PGP encrypting EVERYTHING they said to me (including messages as simple as the word “ugh”). However, today I learned that Dennis really had a beef to settle, and he was going to hold nothing back.

Settling the matter at hand

Dennis was determined to gain access to the chat server to prove two things to me. First of all, he wanted to prove that by gaining access to the chat server, he could read all of the chats going through the server. He also wanted to prove that he could then impersonate a user (me, in this case) and that other users wouldn’t know, as OTR was not there to provide the reliability.

He discovered a vulnerable service was open from our pentest shell server (one that had been reported, but that was thought to be protected by way of network and host based firewalls – we will discuss this later) and was able to exploit it to gain a non-root shell on the chat server. He attempted a variety of privilege escalations, but none were successful, thanks (in part) to the hardening we do as standard practice on all of our managed Linux servers.

He then remembered another vulnerability (this time a service misconfiguration) that had been reported (and thought to be fixed by our internal admin team) in our two factor authentication system. This vulnerability allowed him, from certain parts of our network, to gain access to the administrative interface without providing administrative credentials. Through this interface, he was able to create a new two-factor software token that he controlled, but associate it to one of our administrative users – this allowed him to authenticate to any server on our network, as well as “sudo” to gain root access.

Once he had root access, he quickly created a backdoor for himself to be able to get back in without being noticed. He was then able to make a quick configuration change (and during off-hours, restart the chat service) to enable logging, and he was able to see everything in the clear (except, of course, the conversations of people using OTR). With his first goal achieved, he moved on to impersonating a user. This is where he really got clever.

With root access to the chat server came access to the SSL certificate and private key used for encryption – this meant access to the encrypted traffic passing to/from the XMPP service, including authentication data. By creating (and then quickly removing) a local host firewall rule that rejected my XMPP traffic, he was able to force me to reauthenticate, which provided my plaintext password (which has since been changed – I liked that password, too). After that, he re-added the rule to reject my traffic and proceeded to login as me.

Within five minutes, nearly half of the company had come to my desk and said, “Yeah, what do you need,” as they had received an IM from me that said, “Hey, can you come over here real quick.” In a few other cases, they picked up other conversations I had right where they left off, as they had been reading them in plaintext all day. It wasn’t long before I realized something was up, and only a little longer before they stopped their tomfoolery and reported the issues to the admin team. And even less time before I changed my password (I can be paranoid sometimes, it was one of the first things I did when I realized I was being impersonated).

Key lesson review

So what have we learned. Well, as I said, there were four lessons to be gleaned from this experience:

• You should never take your privacy for granted – At the time, most of the conversations I was having I would consider unimportant, unclassified, non-sensitive, etc. However, once Dennis started repeating them back to me, I realized that, from his perspective, there were just a couple pieces he would’ve needed to engineer a ton of information out of someone. It doesn’t matter if the conversation seems private at the time, what’s not private to me is a goldmine of information to a master social engineer.
• You need to have people who don’t administer your network auditing it – This one is key. One of our pentesters’ responsibilities here is to treat our own network like a monthly pentest customer’s network. They have free reign to test things as they see fit. So, none of this was outside of Dennis’s job description. By doing this, we have a “second set of eyes” checking on our security. Our admin team does a pretty good job, but no one is perfect. We were violently reminded of that today. For the same reason you had someone else proofread your papers in college, having someone else auditing your network makes sure that something that your admins overlooked (like treating a rogue host the same way you treat your monitoring system in the firewall) gets caught by a good guy.
• You need to listen to those people who audit your network – Nothing Dennis did today had gone unreported or was a newly discovered issue. One issue was thought to be fixed, but had not been re-tested by the pentest team. The other, however, had been accepted as a mitigated risk. It is important to take the input of the people who are auditing your network seriously, because if they think they can do something with a security hole, so will someone else.
• You should NEVER anger a pentester – This is kind of like poking an angry, hungry bear with a stick, while backed into a dead-end alley, with your arms and legs cuffed and chained to a post. A pentester (well, at least, our pentesters – I don’t know if this is a generally true stereotype outside of Hurricane Labs) has all of the knowledge and skills to own your network and its users, given just the smallest crack. And, if you choose not to heed their advice, it’s on your head when they have their revenge. I am by no means ashamed to say that I was taken to school today by one of our pentesters. I wouldn’t listen to his advice, and he decided to make me listen.

To conclude our story…

All in all, this was a fantastic experience for everyone. I re-enabled OTR in Adium today; and not JUST because they promised to stop PGP encrypting everything they sent me, but because I was shown the error of my ways. We had a constructive discussion on educating end users about security, and where you draw the line between teaching them security, and drawing them into a false sense of security. And, most importantly, everyone had a good chuckle at my expense when they got to my desk (especially the third and fourth and fifth person, who got to witness the look of exasperation on my face) to find out I had not, in fact, asked them to come by.

Hopefully, we can use this as a teaching experience for anyone in the company who DARES to think they don’t need OTR. Even our sales engineer went back to his desk and changed his encryption setting to force OTR for all conversations. As long as something good comes from it, I am happy to have been on the receiving end of Dennis’s Revenge.