Senior Security Engineer
John Petrucci is a senior security engineer with Optiv’s MSS team. In this role he architects and supports solutions which enable the MSS and SIEM engineering teams to more effectively accomplish their work.
Security Alert: Palo Alto Networks UDP Syslog Exploit
An optional new feature for identifying users by means of syslog messages was introduced in PAN-OS 6.0 (January 2014). This feature is not enabled out-of-box, however unsafe configurations of the User-ID syslog listener on Palo Alto Networks firewalls can allow an attacker to inject arbitrary user-to-IP mappings, including impersonating any other user on the network or de-authenticating valid users. Attacker sophistication required to execute this attack is made very low by the availability of Metasploit modules. Accuvant and FishNet Security MSS has worked with Palo Alto Networks to establish best practice recommendations for configuring User-ID Syslog Server Monitoring.
PAN-OS 6.0 introduces a new feature enabling the User-ID agent (both integrated and dedicated Windows client) to obtain user identities from a wide array of Unix-like platforms by means of syslog message parsing. In short, these devices are configured to send their syslog messages over the network to the User-ID agents where they are then matched against regular expressions which extract both the IP and username. An example of one such message is generated by sshd on an Ubuntu box:
Apr 23 15:59:39 servername sshd: Accepted publickey for jsmith from 192.168.1.150 port 4514 ssh2
The Windows software-based User-ID Agent supports both UDP and TCP delivery of the syslog messages, while the integrated (“agentless”) implementation supports UDP and SSL. Due to the send-and-forget nature of UDP transport, the flow of syslog messages is unidirectional and received logs cannot be verified to have been sent from a trusted syslog server. The configuration of a Palo Alto Networks syslog listener allows for specification of which IP addresses are expected to transmit logs, and syslog traffic from any other source will not be evaluated for parsing. Still, if an attacker were able to discover the IP address of one of the trusted syslog servers, they can spoof their source IP address to match. Consequently, fake syslog packets can be crafted with a source of the trusted server and they will be regex parsed as if they were authentic.
After verifying the attack proof of concept in our lab, Accuvant and FishNet Security MSS notified the vendor, and a joint conclusion allows for two options to mitigate this type of attack:
1) SSL transport of syslog is preferred, or in the case of the Windows User-ID Agent, administrators should use TCP transport. Both protocols have the added benefit of bi-directionality to verify the IP address of the server which transmits the messages, and SSL adds yet another layer of security.
2) If a syslog sender does not support transmitting syslog messages via TCP or SSL, an isolated VLAN should be dedicated for the network which exchanges syslog messages.
Palo Alto Networks has also updated their documentation to reflect these security best-practices:
Accuvant and FishNet Security recommend that clients utilizing Palo Alto Networks OS, using this feature, consider these recommendations during their next change control window to provide mitigation of the above described exploit.