I'm also trying to create a custom signature to alert on these events, but I'm unable to, as the following pattern evaluates to less than 7 bytes: Basic (.)? This is as far as I got. <vulnerability-threat version="8.1.0">
<entry name="And Condition 1">
<entry name="Or Condition 1">
... View more
I was doing a side-by-side comparison of various IDS/IPS sensors, including an inline Suricata sensor, as well as my PAN firewall. Suricata throws an alert if it detects that an HTTP Basic Authentication event crosses the sensor over an unencrypted connection, but the PAN firewall doesn't. This should throw an alert of some kind, as HTTP Basic Authentication is commonly used as a quick and dirty credential harvesting mechanism in low-complexity phishing attacks. These authentication events traversing the network in the clear also subjects the transmitted credentials to theft at any portion of the network path. An HTTP Basic Authentication event can be detected by the presence of the "Authentication" header in the POST request, followed by the word "Basic" and a base64 encoded string that is the username and password without any further encryption/obfuscation.
... View more
PAN-OS 8.1 seems to lack the capability to perform fine-grained configuration of cipher suite selection and prioritization for GlobalProtect VPN functions. I ran a fairly detailed SSL functionality assessment on a configured TLS v1.2-only GP gateway and found that RSA encryption-based ciphers are selected by default by all simulated clients. This was a bigger concern previously due to ROBOT (CVE-2017-17841 for PAN-OS, patched in PAN-OS 8.0.7), but there's also the fact that RSA encryption-based ciphers don’t provide perfect forward secrecy. My assessment yields the following ciphers, in order of the PAN FW’s preference: AES256-GCM-SHA384 AES128-GCM-SHA256 AES256-SHA256 AES128-SHA256 AES128-SHA ECDHE-RSA-AES256-SHA ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 Highlighted are the RSA encryption-based ciphers. For some reason, they’re A) being used at all and B) prioritized over other PFS-capable cipher options. Any TLS v1.2-capable client is by definition capable of communicating using PFS-capable cipher suites, so this ordering is surprising. Cryptographic best practices (as of now) would dictate the following order: ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-SHA ECDHE-RSA-AES128-SHA AES256-GCM-SHA384 AES128-GCM-SHA256 AES256-SHA256 AES128-SHA256 AES128-SHA Even better, best practices-wise, would be to omit the highlighted options entirely. Ideally, the combination and priority of cipher suites offered to the client would be configurable on the FW itself. Currently, only the TLS version is configurable. (Minorly edited copy-paste of my conversation with a channel engineer.)
... View more