Vulnerability - The remote server is running Java Debug Wire Protocol service - reported from Qualys scan

Products

• VMware Tanzu Application Service

Issue/Introduction

• Your security team notified you that you have a vulnerability on your diego_cells: "The remote server is running Java Debug Wire Protocol service. No authentication is required if the service is enabled."
• The vulnerability is reported from a Qualys scanner.
• This vulnerability may not be present on all Diego Cells.

Environment

TAS for VMs 6.0.15

 

This condition is not specific to the TAS version as the JDWP feature can be enabled on Java applications independent of version.

Cause

This vulnerability is reported when an application has been enabled for debugging in TAS for VMs. The following KB Article and CF Documentation detail enablement processes.

Resolution

Edit the problem application to disable JDWP debugging:

 

• Use the below identification steps to determine which app has JDWP enabled.
• Edit the application manifest, remove the env variable for: 
  
  JBP_CONFIG_DEBUG: '{enabled: true}'
  
  
• Or, set the variable to 'false'
• cf push the app manifest after changes.

 

 

Identify the application that has debugging installed using cf commands

 

Pull a list of all application environment variables by looping a request over them and piping to less, or to a file using the following for loop:

# for i in $(cf apps | tail -n+2 | awk '{print $1}'); do cf env $i;done | less

 

You can search within the resulting output for "jdwp" to see which application is using the Java Debug Wire Protocol.

 

Identify the application that has debugging installed using ps and runc commands from within Diego Cell

 

If you are still unable to identify the app using the cf command steps, try the following process to correlate the buildpack that is presenting the Java Debug Wire Protocol to the container runtime:

 

1. 1. From an SSH to your Diego Cell on which the Qualys scan identified the vulnerability, gather the PID and parent PID for the buildpack process running jdwp:
      
      # ps -ef | grep jdwp 
      
      The result will look something like:
      
      
      2000      246798  246701  0 Jun17 ?        00:57:03 /home/vcap/app/.java-buildpack/open_jdk_jre/bin/java -agentpath:/home/vcap/app/.java-buildpack/open_jdk_jre/bin/jvmkill-1.17.0 .... truncated ... -agentlib:jdwp=transport=dt_socket,server=y,address=8000

      
      Where 246798 is the Buildpack PID and 246701 is the Application Container PID
      
      
      
   2. Use the resulting Application Container PID in ps to identify the container ID
      
      # ps -ef | grep 246701

      
      The result will look something like:
      
      
      root      246701  235192  0 Jun17 ?        00:00:01 /var/vcap/packages/guardian/bin/dadoo -runc-root /run/containerd/runc/garden exec /var/vcap/packages/runc/bin/runc /var/vcap/data/garden/depot/16ea471e-9fc0-449f-6133-8f0e/processes/c2602852-114f-4714-5574-0f7a0be99931 16ea471e-9fc0-449f-6133-8f0e

2000      246798  246701  0 Jun17 ?        00:57:03 /home/vcap/app/.java-buildpack/open_jdk_jre/bin/java -agentpath:/home/vcap/app/.java-buildpack/open_jdk_jre/bin/jvmkill-1.17.0 ... truncated ... -agentlib:jdwp=transport=dt_socket,server=y,address=8000

root     2210303 2189977  0 18:07 pts/0    00:00:00 grep --color=auto 246701

      
      Where 16ea471e-9fc0-449f-6133-8f0e is the Application container ID
      
      
      
   3. Use the resulting Application Container ID with the following cfdot command to list the application by Org name, Application name and GUID:
      
      # cfdot actual-lrps | jq  '{org: .metric_tags.organization_name, app_ame: .metric_tags.app_name, guid: .instance_guid} | join (",")' | sort | grep 16ea471e-9fc0-449f-6133-8f0e