Thursday, March 24, 2011

Avaya IP Office Manager 8.1 TFTP DoS

I found a boring DoS in the TFTP server that runs on the IP Office Manager for Avaya phone systems. Nothing exciting, no registers were overwritten and neither was SEH. Here is my exploit:

Monday, March 7, 2011

"Lync is Experiencing Connection Issues with the Exchange Server"

I was receiving this error on only one person's machine. If I used their account on other machines, I would get the same error on the Lync client. It was denoted by a red X in the bottom right of the client. The problem ended up being some sort of corruption in their Exchange email box. I backed up their current mailbox, disabled their current mailbox and then created a brand new mailbox. The error went away after doing this. I was able to recreate the issue by disabling the new mailbox and then reconnecting them to their old box. It was a bit annoying for the user while you're moving mail around but oh well! Dont forget to grab their Exchange Server side rules as well before you blow away the old box, or before the system blows it away for you. I'm not sure how the email box got corrupted, but this was my fix!

I am running Lync Server 2010 and Exchange 2007.

***UPDATE***July 15, 2011***

Based on one of the comments to this post, I did some additional research. The person who posted about the bad character with the contact is yet ANOTHER fix to this issue.

I deleted all the users contacts (they were left in the deleted items). Then I closed Outlook and Lync, then reopened Outlook and then Lync..... the error went away!

I moved the contacts back in blocks of 10-15 at a time trying to isolate the contact and repeating the process of opening and closing the apps. I finally got the error to come back on one of the iterations. I ended up isolating the issue to a single contact and I noticed that there was a strange character at the end of this contacts phone number. It looked like a square or in binary terms, a null byte. As soon as I deleted this "square" I was able to move this contact back and the error did not come back. Then, I moved all the rest of the contacts back in and fortunately, there were no other contacts that had this issue.

I suspect that an easy solution to this for a person who has a lot of contacts would be to export them all to a CSV file then delete the user's contacts. I don't think the special characters would make it to your export so all you would have to do is import them as new contacts. Maybe someone can test this and let the readers know.

Thanks again to the "anonymous" poster for the additional information to spark this investigation!

Tuesday, March 1, 2011

Server 2003 DHCP VLANS and Cisco Aironet Problem

I was adding a Cisco Aironet 1310 to a location that had multiple VLANS all being serviced by a Cisco Router, HP Procurve Switch and Windows Server 2003 DHCP.

I configured the Aironet with two SSID's on different VLANS. The employee VLAN was the "native" VLAN in Aironet speak. The Guest VLAN was the secondary VLAN.

First Problem:  
When connecting to the Guest VLAN, we were getting IP addresses from the first VLAN. It seemed the DHCP server was not able to distinguish between requests from the different VLANS.

Because DHCP is broadcast based, the router naturally segments our broadcast domains as it should so the broadcasts don't reach the other networks. This is typically subverted by adding the "ip helper-address x.x.x.x" on sub interfaces that are not on the same network as the DHCP server. This essentially turns the router into a DHCP relay agent. I have implemented this a 100 times and was stumped as to why this wasn't working.

Looking at the packet captures, I noticed that the initial DHCPDISCOVER packet that the client sends was showing up in multiples of two, but they were slightly different. One of the packets had the source address of the router's sub interface and the destination of the DHCP server, the other packet was a true broadcast packet to the whole subnet. The Problem was that the regular broadcast packet was the one the server was responding to and thus, getting the IP from the employee VLAN every single time, regardless of the VLAN the client was on.

First Solution:
The culprit was that there was a monitor port setup on the HP Procurve switch that was monitoring all the traffic on the port that the router was plugged into and replicating it to the port the DHCP server was plugged into. That's why I was seeing both packets in the capture. As soon as I turned this off, I didn't get the wrong IP on the guest network.... I was getting NO IPS.... the plot thickens....

Second Problem:
While troubleshooting the first issue I setup a DHCP server on the router itself, trying to isolate the issue. I ended up removing the DHCP configuration but in a mistake, I typed the command "no service dhcp." This was the problem. "service dhcp" is also related to the DHCP relay agent functionality on the router. You can read about this command here

Second Solution:
Typing "service dhcp" immediately fixed the issue. The reason I knew there was a problem with the router was because the DHCPDISCOVER packets were hitting the server but the server was ignoring them. The reason was because the router wasn't changing the source IP to the sub interface of the router so the DHCP server didn't know what IP to give it.