iRules are an event driven language available on BIG-IP, which allow the operator to extend capabilities that are unavailable in the CLI or GUI. Based on the Tool Command Language (TCL), F5 has customized an implementation of the TCL language in BIG-IP to include additional events and commands. The additional capabilities are broad, from supporting uses cases such as extending our Web Application Firewall, organizing network flows based on URL categorization and/or application classification, rewriting HTTP requests and responses and customized logging attributes of network flows. Along with adding capabilities to the standard TCL language, F5 has also removed some of the dangerous functionality inherited by the language. We did this to create a bounded operating environment which avoids use of the riskier functions such as invocation of a subprocess, opening arbitrary system files, and installation of TCL packages.
While we strive to create a balance between customer security and usability, just like any programming language there are common security pitfalls even the most seasoned iRule developers can fall into. This article is written with the intention to inform new and experienced iRule developers of common security pitfalls I've observed over the years. While some of these recommendations can be generically applied, this article is scoped to the TCL based iRules implementation and does not specifically cover Node.js iRulesLX use cases.
One of the main drivers for this article is to inform iRule developers on the issue of double substitution. Double substitution AKA double evaluation is a form of code injection. Code injection attacks are a threat that can allow attackers to gain control of application flow and/or cause other unexpected impacts. In other words, code injection is bad. These can be prevented by following the best practice for TCL scripting, which is to enclose all expressions, ensuring that they are not substituted or evaluated unexpectedly. For more specific guidance on identifying risky use and how to fix it, we've published K15650046: Tcl code injection security exposure. In addition to user education, we've implemented static code analysis on BIG-IP that can detect cases where double substitution may be possible. In addition to local checks, iHealth will trigger heuristic D015332 when the log message emitted by code analysis is observed.
Lack of filtering or sanitizing input is a close second to double substitution, especially when user input is passed to specific commands in an iRule. Two particular commands that should be reviewed carefully are node and sideband.
If an iRule takes input from an untrusted source and passes it directly to the aforementioned commands, an attacker may be able to connect to arbitrary systems defined in a request. This may be intended functionality, but when it's not intended becomes Server Side Request Forgery which results in unexpected network connections to systems reachable by the BIG-IP. This includes directly passing an attacker controlled value to the commands, but an overlooked area is passing in responses from DNS lookups. If a DNS lookup is recursed to an attacker controlled server, the attacker controls the address in the response and therefore controls the destination of the connection by the iRule.
Logging is highly dependent on the business, so my suggestion is to gather a very clear understanding of the necessary business requirements along with any constraints that you need to consider. I'm reminded of the nursery rhyme "Goldilocks and the Three Bears" where finding the "just right" amount of logging is oftentimes discovered after iterative development to identify what works best for the application. As with many things, the desirable optimizations will often come with tradeoffs and risks that need to be balanced appropriately. These decisions don't need to be iRules specific so I will suggest some general tradeoffs I've encountered.
Last but not least - there are known iRule vulnerabilities which range in severity and impact. Reviewing security advisories so you can make an appropriate risk assessment, along with implementing mitigations and/or fixes are important steps in preventing exploitation.
iRules are a powerful tool that enables business value but come with some risk. I hope that by following the suggestions here, you are more adept at recognizing risky patterns and avoiding potential pitfalls encountered during the iRules software development lifecycle. Thanks for reading, hope this helps.