Monday, January 24, 2011

The Lync Server Front-End service terminated with service-specific error %%-2146762487

I installed a fresh copy of Lync Server 2010 Standard and got all the way through the install without a problem.....but none of the services would start. I was getting this error:

The Lync Server Front-End service terminated with service-specific error %%-2146762487.
Warning: Cannot start service RTCPDPCORE on computer **************.
This problem in my situation was because I was using an internal certificate authority. My certificate was just fine and was correctly applied to the server, but I forgot to import my internal CA chain into the server as a trusted root certification authority. As soon as I did this the services started right up.

Sunday, January 23, 2011

Golden FTP 4.70 PASS Remote Exploit

I've been fuzzing ALOT of FTP servers lately. I found a PASS buffer overflow in the Golden FTP 4.70 server and recently had it published to exploit-db.

At first I thought this was just a DOS but then a collegue of mine, Gerardo Iglesias Galvan took a closer look and saw that EIP was being overwritten as well as ESI and ECX. We noticed strange behavior when different buffer lengths were used. By adding some NOPS + shellcode + extrapadding NOPS + EIP, we could control execution flow. We're utilizing a JMP ESI for the EIP address.

Here is where it got confusing. Our exploit was unreliable. My collegue was testing the one I developed his test environment and it wasn't working. I tested his exploit and it would not work on my network. We also had the offsec guys try but they couldn't reproduce it either. If I was a reverse engineer, I probably could have just figured out why this was happening, but I am not :) I noticed that if the subnet the FTP server was running on changed, the exploit would fail. It seems the offsets were changing with different subnets. I went through and manually figured out the offset for 4 different subnets. They were all just slightly different. I'm still not sure why the app does this, maybe someone can let me know?

Also, for this exploit to work, the option "show new connections" HAS to be set in the application. You can find this under the Options button in Golden FTP. It should also be noted that failed exploit attempts usually DOS the service. I didn't test if this works with the paid version or not, all my testing was done on the free version.

****UPDATE****

@bannedit ported our exploit to Metasploit yesterday. His version is certainly much more elegant than the one we did. He managed to figure out how to make it reliable with this little piece of code here:


if datastore['RHOST'].length < 15
            pad = make_nops(1) * (15 - datastore['RHOST'].length)



The IP address is 15 bytes long, including the dots. IE 192.168.100.1 = 13 bytes so 15 -13 = 2 more nops. We did all the work for him but failed to see the pattern! Oh well, at least it is in the framework now!

http://dev.metasploit.com/redmine/projects/framework/repository/entry/modules/exploits/windows/ftp/goldenftp_pass_bof.rb

Sunday, January 16, 2011

mount: unknown filesystem type 'HPFS/NTFS'

I ran into this error when I tried to set my external hard drive to automatically mount to the same mount point on every reboot. First, I went into the disk utility in Ubuntu and got the file system type which was HPFS/NTFS. I got my UUID and entered this line into my fstab file:
UUID=b3a0378a-c352-47fe-ac88-cf2a9d815e13 /media/Backup  HPFS/NTFS defaults 0 0

Then, I ran mount -a to  remount everything in my fstab file but ran into this error:
mount: unknown filesystem type 'HPFS/NTFS'

I couldn't find a solution anywhere on the Internet but then remembered I set this drive to the ext4 file system when I formatted it. I changed my fstab file to reflect that:
UUID=b3a0378a-c352-47fe-ac88-cf2a9d815e13 /media/Backup ext4 defaults 0 0

After re-running mount -a everything worked.

Friday, January 14, 2011

Blackmoon FTP 3.1 Denial of Service Exploit

I found an exploit and had it published to exploit-db. It is a denial of service for the Blackmoon FTP 3.1 Server (Builds 1735 and 1736). The PORT command is not properly sanitized and sending a buffer of 600 bytes crashes the application.

When the Blackmoon FTP Server is installed it sets the Blackmoon FTP Service to automatically restart the service in the event of a failure. This was a little confusing because I could see the application crash, but the FTP service would still respond to my requests. Turning the service recovery feature off enabled me to find the DOS. Because EIP or SEH is not overwritten it's not likely to be anything other than a nuisance.

I contacted the vendor and they fixed the issue within a few weeks. Build 1737 is the latest build that incorporates their fix.