Monthly Archives: February 2016

GLIBC getaddrinfo Vulnerability in Linux Systems

A pair of Google researchers recently released a vulnerability report on the GLIBC function “getaddrinfo”, which if exploited, could crash the system or even give a hacker command line control. (Yikes!!) MANY Linux systems are vulnerable to this so please patch your systems quickly. GLIBC packages affected by this are versions 2.9 and newer…2.9 was released way back in 2008, so you can see that the size of the affected systems is huge! Note…”getaddrinfo” is used by systems in resolving DNS names to an IP address. Talk about important…right??

To see what version of GLIBC you are using, simply run the command:  ldd –version

Here is an example from one of my test Linux systems at work…

Example of affected GLIBC package

Example of affected GLIBC package

As you can see, this system is running version 2.10.1 of GLIBC and needs to be patched. For CentOS (which I’m running), you can obtain a more detailed listing about GLIBC this way…

GLIBC info from my CentOS system

GLIBC info from my CentOS system

Most Linux distributors have patches ready to fix the issue, so running the appropriate update commands should take care of things. For CentOS, just run “yum update” and it will grab the fix and apply it…a reboot of your system will be required.

Related links…
Google announcement
SANS InfoSec Post

Cisco Security Advisory – IKE Vulnerability in ASA Code (CRITICAL)

Cisco ASA (via cisco.com)

Cisco ASA (via cisco.com)

Cisco released a critical security advisory today concerning an IKE vulnerability within the ASA software OS…and let me tell you, this will affect a LOT of people! If you are running one of the affected software versions (and I am), then you will want to update your ASA appliance very soon. I’ll have mine updated in the next couple of days.

Don’t delay. Once you read the advisory, you will know why!

Packet Capture on Both Sides of a Conversation

Greetings everyone!! Yes, it’s been a while…sorry about that. Been busy with life…I’ll just leave it at that.

So at work, for the last couple of days, the Citrix admin has been having an issue with users at one of our larger remote sites…seems they are intermittently unable to connect to a Citrix server after being redirected by the Citrix license server. He brought me into the problem this morning once he realized the problem was only occurring at this one site. Very interesting!

First step was to capture some of the traffic and see what’s going on. I have a Linux server at the Data Center running Snort, watching most all of the traffic into and out of the Data Center, so this comes in very handy when I need to capture some traffic. I started a TCPDUMP on the server, specifying the interface in question that has the traffic from the remote site, and dumped it into a file…the command was…

tcpdump -vv -nn -s 0 -i eth3 -w /root/pcapfiles/citrix_issue.pcap host 10.10.21.223

The Citrix admin was remoted onto a PC at the site, and he attempted to connect into Citrix. After I captured the data, I moved the file to my laptop and opened it up with Wireshark…I saw the 3 way handshake (SYN – SYN/ACK – ACK), and then some data going back and forth, but the session never started up and it timed out. Weird.

I also captured a Wireshark session from my own laptop so I could see how it was supposed to work. I still could not see what the issue was…very strange.

I then decided that I needed to see packet captures from both sides of the conversation. So I remoted into the PC and installed Wireshark on it…I then started up Wireshark on the PC and TCPDUMP on my Linux server, and then tried the Citrix client again. After it timed out, I opened up both PCAP files in Wireshark and examined them side by side, packet by packet. On the PC, I saw this…(PC = 10.10.21.223, and Citrix server = 10.12.1.122)…

Packet capture on PC side showing initial SYN packet

Packet capture on PC side showing initial SYN packet

I found the matching packet on the capture from the Data Center…

Packet capture from Citrix server side showing full handshake

Packet capture from Citrix server side showing full handshake

Say what????? I see a completed 3-way handshake…including the SYN/ACK from the server back to the PC (which was not in the PC capture), and another packet from the PC to the server completing the handshake…also not in the PC capture. VERY bizarre!!!

Then it hit me…Riverbed!! The only way a handshake could be completed in this manner was from another device sitting in-between…and we do have that. We have Riverbed devices sitting at the Data Center and at most large remotes sites handling WAN optimization. Since no other sites were reporting any issues, then the Riverbed at this remote site must be “kinked”. So we restarted the Citrix application optimization process on the Riverbed, and that fixed everything!

VERY cool…and very interesting. This took some time to figure out, but once I got visibility at both ends of the conversation, the answer was easy. Remember…Wireshark is your friend.