Back to list
Plunging Through the Palo Alto Networks Firewall
Jan 04 2011 10:10PM
Jeromie comsecinc com
Class: Bypassing Intended Security Controls
Published: August 11, 2010
Timeline: Submission to MITRE: August 11, 2010
Credit: Jeromie Jackson CISSP, CISM
COBIT & ITIL Certified
President- San Diego Open Web Application Security Project (OWASP)
Vice President- San Diego Information Audit & Control Association (ISACA)
Cell: 832-378-RISK (7475)
All versions prior to 12/07/2010
Palo Alto Networks firewall claims it can ?identify and control applications regardless of port, protocol, encryption, or evasive tactic.? Due to the need for organizations to support protocols and applications not yet categorized by Palo Alto there is an underlying logic issue. Unless a company is willing to disable all services except for those well-known by the Palo Alto firewall risk will be constantly present. I spent a couple hours testing the Palo Alto Network firewall to see if I could puncture the firewall and achieve remote command-and-control.
The Palo Alto Networks firewall uses ?Application Visibility? and ?Application Control? functions in order to identify services and apply controls across the firewall segments. An attacker can leverage a phishing scam or a vulnerabile online forum to distribute a remote command-and-control payload to a machine behind the firewall. The attacked machine will then initiate an outbound command-and-control connection. Palo Alto Networks Firewall simply identifies it as ?Unknown TCP.?
First, I thought about using HTTP to traverse the firewall and remotely control a device behind the firewall. I successfully created a command-and-control session which the firewall identified as generic HTTP traffic. I leveraged the following script from The Hacker's Choice (THC):
Second, I generated a Metasploit reverse_tcp command-and-control payload. I uploaded the payload to a website, generated a phishing email, and had the victim machine go to a malicious URL. Command-and-Control was achieved and the firewall simply characterized it as ?Unknown TCP? traffic. Metasploit has the ability to encode the payloads in a plethora of ways- Palo Alto Networks will need to address all potential encodings in order to mitigate the risk.
I worked with the vendor for several months and they recently came out with a signature update that will identify Metasploit. Due to evasion techniques such as encoding, payload packing, and other ways to evade filters I believe the signatures may not catch all payloads generated by Metasploit. I will be doing a little more work in the near future to run a small battery of tests to evaluate the detection rates.
Below are the details pertaining to the update. I find it odd it was marked as a medium severity. Having these Metasploit remote command-and-control sessions enabled me to gain access to password hashes, install keyloggers, start remote desktop VNC sessions, hide my process, and to pivot off the attacked machine to gain further access into the environment.
Vulnerability Signatures Summary
Metasploit Meterpreter Connection Attempt
Metasploit Meterpreter Connection Attempt
IAX2 Asterisk Remote Denial of Service
Struts2 and XWork remote command execution Vulnerability
Microsoft Office Memory Corruption Vulnerability
Microsoft Word Crafted SmartTag Record Code Execution Vulnerability
Microsoft Excel Record Parsing Remote Code Execution Vulnerability
Microsoft PowerPoint Picture Index Variant Remote Code Execution Vulnerability
Microsoft PowerPoint List Value Parsing Remote Code Execution Vulnerability
Oracle Web Cache Admin Module Denial of Service Vulnerability
Adobe Flash Player loadBitmap Memory Corruption Vulnerability
A patch will be required from the vendor. In order for the vendor to meet its claims of ?identifying and controlling applications regardless of port, protocol, encryption, or evasion techniques,? it will be required to gather signatures from at minimum the most prevalent command-and-control tools available in the wild and create identification techniques to mitigate the risk. Users could block all non-identified application traffic passing through the firewall to mitigate the risk, however this is generally not a viable option. While their technology is proving to be a strong firewall in the market the marketing statements are a bit lofty.
[ reply ]
Copyright 2010, SecurityFocus