lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 12 Jan 2015 13:48:01 -0600
From: Brandon Perry <bperry.volatile@...il.com>
To: "fulldisclosure@...lists.org" <fulldisclosure@...lists.org>
Subject: Re: [FD] McAfee ePolicy Orchestrator Authenticated XXE and
	Credential Exposure

After releasing this, I actually got quite a bit of flak (whatever happened
to responsible/coordinated disclosure?!).

Today, Space Rogue wrote a pretty good article about Full Disclosure:
https://twitter.com/spacerog/status/554704824705761280

I tend to agree with the post, and I feel that this vulnerability actually
is a great example of the points Space Rogue makes.

For instance, according to McAfee's official KB article (
https://kc.mcafee.com/corporate/index?page=content&id=SB10095), version 4.x
of ePO will have a fix sometime next month. However, 5.x releases won't
have a fix until Q2 of this year!

Having dropped the vulnerabilities as I did, McAfee decided to provide a
work-around within the KB for anyone wanting to defend themselves against
anyone attempting to exploit the vulnerability. I always assume if I have
found a vulnerability, someone else has found it as well. If I had
coordinated with McAfee, the consumers whom were running vulnerable
instances ePO would have been left vulnerable with no knowledge of having
been vulnerable in the first place until the patch came out months after
initial discovery. Since this was dropped in full disclosure, now their
customers can actually do something to prevent exploitation between now and
when an official patch is released.

I completely consider this a win for any of McAfee's customers running ePO.
Is it more responsible to coordinate with a slow-moving software company to
help them save face, leaving their own customers vulnerable while a patch
is worked up? Or is it more responsible to force the company to act quickly
and at least provide a work-around/mitigation publicly while a patch is
worked on? I go with the latter.




On Tue, Jan 6, 2015 at 2:05 PM, Brandon Perry <bperry.volatile@...il.com>
wrote:

> McAfee ePolicy Orchestrator Authenticated XXE and Credential Disclosure
>
> Trial available here:
>
>
> https://secure.mcafee.com/apps/downloads/free-evaluations/survey.aspx?mktg=ESD1172&cid=ESD1172&eval=A0C692FB-8E29-4D47-BBF1-43CAB5F10069&region=us
>
>
> McAfee ePolicy Orchestrator suffers from an authenticated XXE
> vulnerability, available to any authenticated user. The Server Task Log
> option in the upper left menu is where the vulnerability lies. When
> creating a custom filter, a bit of XML is passed from the client to the
> server to create the said filter. This parameter is called 'conditionXML'
> and is vulnerable to an XXE attack. The attack seems a bit limited however,
> as you can only fit up to 255 characters in the 'value' field.
>
>
>  However, a file in the web server installation configuration directory
> called 'keystore.properties' is less than the size we need, and contains an
> encrypted passphrase that is set during installation. When installing, an
> initial admin user is created (with 'admin' as the default username'). The
> password supplied here will also become the password for the local 'sa' SQL
> user, if you choose to install a local SQL server, and it will be the
> password for the application's certificate key store (hence the name of the
> properties file).
>
>
>  This passphrase is encrypted using a static key, and uses a weak cipher
> (AES-128-ECB).
>
>
>  The supplied metasploit module will authenticate as a given user,
> exploit the XXE to retrieve the encrypted passphrase, then decrypt it and
> print the decrypted password out for the user.
>
>
>  By default, if a local SQL server has been installed, it the SQL server
> will listen on all interfaces. Since the application uses the 'sa' user by
> default, the password supplied during installation can be used to log in
> remotely as the 'sa' user, allowing for remote command execution.
>
> Metasploit module attached.
>
> Also, Github gist link:
> https://gist.github.com/brandonprry/692e553975bf29aeaf2c
>
> --
> http://volatile-minds.blogspot.com -- blog
> http://www.volatileminds.net -- website
>



-- 
http://volatile-minds.blogspot.com -- blog
http://www.volatileminds.net -- website

_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ