CVE-2014-9113 : CCH Wolters Kluwer PFX Engagement <= v7.1 Local Privilege Escalation

Product Affected:

CCH Wolters Kluwer PFX Engagement <= v7.1

This vulnerability has been reference checked this against multiple installs. This configuration was identical across all systems and each version encountered.

Executables/Services:

Pfx.Engagement.WcfServices

PFXEngDesktopService

PFXSYNPFTService

P2EWinService

Attack Detail:

The PFX services for engagement install with LOCAL SYSTEM service credentials in the directory C:\PFX Engagement\

 

The executables that are installed, by default, allow AUTHENTICATED USERS to modify, replace or alter the file. This would allow an attacker to inject their code or replace the executable and have it run in the context of the system.

This would allow complete compromise of a machine on which it was installed, giving the process LOCAL SYSTEM access to the machine in question. An attacker can replace the file or append code to the executable, reboot the system or restart the service and it would then  compromise the machine. As LOCAL SYSTEM is the highest privilege level on a machine, this allows total control and access to all parts of the system. This affects both the server and workstation builds.

Remediation:

Remove the modify/write permissions on the executables to allow only privileged users to alter the files.
Apply vendor patch when distributed.

Vulnerability Discovered: 11/26/2014

Vendor Notified: 11/26/2014

Vendor states this will be patched with next software update.

Website: www.information-paradox.net
This vulnerability was discovered by singularitysec@gmail.com. Please credit the author in all references to this exploit.

  


A security update has been released on 12/03/2014 to address the vulnerability in CCH Wolters Kluwer ProSystem fx Engagement. This update corrects the permissions on necessary application services. Please see the online release bulletin for instructions on how to apply the security update.

https://support.cch.com/updates/Engagement/pdf/Services%20Security%20Update%20-%20Release%20Bulletin%20-%20US.pdf
 

Hacking the Human Firewall -- Part 2

One of the most useful things you can do which is particularly useful is using read receipts to map a network and target out.

Most people acknowledge read receipts (knowingly or unknowingly) and they also leave their email application opening webpages externally.

Read receipts are interesting because inside of the email headers you get a clear view of a lot of information. Ingress/Egress IPs, anti-virus and spam services, AD information (yes, Active Directory information) and a few other interesting bits.

Along with that, if you're lucky enough to have someone using IMAP/SMTP or POP3/SMTP, you'll get a fair amount of information about their machine.
















Take this read receipt/email heard for example. Thing to remember: No one needed to reply to this! They opened the email and allowed the read receipt to be sent. Many times, even if they have it shut off, you can get something from another part of the system (We'll cover that in another post.)

1. Egress IP of the mail server.
2. IP of the mailhandler IP on your end
3. Declared Mail Connector Name
4. FQDN (external) of the server sending it.
5. INTERNAL AD NAME of the originating server AND the next server to handle it.
6. Identifying information about the mail servers internally
7. Declared Connector name and IPv6 information

Let's discuss:

1. Egress IP - Many organizations, particularly smaller ones, will have it "all on one box" or separate the roles out so that the SMTP handler is also a client access server. You now have confirmed operational receipt of the mail server, that the address works. You have also confirmed that you have an SMTP connector to run AUTH attempts against.

2. You have confirmed they are able to query DNS and find your name. Useful for other purposes later

3. This is the "banner name" of the mail server. Many admins never change this, much less know that it exists. These folks "did it right" but many do not. This is typically left as the default which gives you a good amount of information on the organization as you will see below.

4. FQDN, also a useful piece of data.

5. INTERNAL DNS NAME OF THE ORIGINATING SERVER. As these folks left it default, I now have the server NAME of the email server and ITS INTERNAL IP ADDRESS.

6. I can use this to figure out what version of exchange this is. Google will tell you it's Exchange 2010 SP3.

7. Again, I have ANOTHER email (and internal) server name, AD information and that they have IPv6 going.

From one read receipt, I know quite a bit.

If they're using domain\credential for authentication, I now have that.
If I can breach the perimeter in some manner, the internal IP becomes extremely useful.
I know the admins aren't security conscious and don't change defaults (connector names and DNS), I have a good idea that stuff may remain default/un-hardened/unpatched. Admin/admin anyone?
I know the version of exchange and if it's vulnerable I can run attacks against it.
IPv6 may be in use, which opens up a new world of exploration for me.


All that, from a read receipt. Pairing that with the fact that most Exchange Orgs use the email address/login name matching scheme. I have a point of entry and places to use it.

....to be continued....