Wednesday, July 20, 2011

FreeFloat FTP Buffer Overflow

The other day on there was a new exploit for FreeFloat FTP 1.0. I took a quick look and decided to see if there were other commands that were vulnerable. I started fuzzing and I noticed quite a few commands were overflowing EIP with 41414141. ABOR, ACCT, ALLO etc etc.... I basically stopped looking because every single command I tried would crash the application.

It seems any unimplemented command caused the same buffer overflow. I posted my exploit on PacketStorm. I also noticed that basically any 4 letters you pretend to be a command....will overflow the buffer. PWND even worked!

If you're interested in buffer overflows or fuzzing, I highly recommend grabbing a copy of this POS software. Who ever coded this did absolutely no checking for user input at all. It really should be used as a learning tool. Everything I found was straight forward overflows. Good fun!

Friday, July 15, 2011

Lync Contact Card Regular Expressions

The contact cards in Lync are a nice feature but is a cause for confusion for some. You may notice that the phone number fields for some of your AD users do not populate or are not populated the same way you've inputted them into Active Directory. The reason is because the Lync server uses a generic set of regular expressions to format them into E.164 format. Why does it do this? A lot of people integrate their phone systems into their Lync server so that you can dial people directly from your computer, by clicking on their phone number. Phone systems need these phone numbers to be in a specific format so they can handle them accordingly.

A client of mine had a situation where multiple hands had been into Active Directory over the years and therefor employees phone numbers were entered in multiple formats. For example:

(111) 222 - 3333
111-222-3333 x44
111-222-3333 x4444
111-222-3333 ex 44

This client did not have an integrated phone system but wanted to utilize the contact card functionality for reference without having to go through their entire AD and re-enter them all. Seems reasonable and easy enough eh? Meh.

Lync Server looks in your share that you setup during installation for address book files. This is typically in \\server\share\1-webservices-1\abfiles in the Company_Phone_Number_Normalization_rules.txt file. This is the file where the regular expressions need to go.

I contacted Microsoft Support (greatest enterprise support known to man) for some help with coming up with a series of regular expressions to help accommodate all of the different variations we could think of. Here is what they came up with and they work perfectly:

## Normalize 10-digit phone number patterns from Active Directory into +E.164
##(?:\+?1[-. ]?)?\(?([0-9]{3})\)?[-. ]?([0-9]{3})[-. ]?([0-9]{4})?\D*(\d*)
##+1($1) $2-$3 $4

#For normal phone numbers with 10 digits

#Various configurations of the 10 digits





#For 10 digit numbers using X as the extension notation (2 digit extensions)

#For 10 digit numbers using X as the extension notation (4 digit extensions)

#For 10 digit numbers using Ex as the extension notation (4 digit extensions)
+1$1$2$3 Ex $4

#For 10 digit numbers using ex as the extension notation (4 digit extensions and case sensitive)
+1$1$2$3 Ex $4


Keep in mind, you'll have to regenerate your Address Book files manually or wait about 24 hours for the new database files to be updated. You also might need to delete your local galcontacts.db files that are located in C:\Users\user\AppData\Local\Microsoft\Communicator\

Hopefully this helps you if you're in the same situation!

Wednesday, July 13, 2011

Solar FTP 2.1.1 PASV Exploit

Let the fuzzing continue.... I found a remote exploit bug in Solar FTP that used the PASV command. Appending a string of about 2127 bytes to the PASV command causes the application to crash. Under certain circumstances remote code execution is possible as well. I worked again with my comrad, Gerardo Galvan and we had it published yesterday

The interesting part about this exploit was the JMP EAX we used took us to some junk before our actual buffer. Fortunately, executing the instructions we landed on did not cause the execution flow to change directions.

We left some work for a future researcher to figure out why the behavior changes when the IP changes. This was a similar problem we had with Golden FTP but it seemed the Solar problem was much more confusing. I couldn't get consistent behavior by changing IP addresses. Hopefully someone can figure this out in the future!