ZENIDS: Introspective Intrusion Detection for PHP Applications

INTRODUCTION Content Management Systems (CMS) have taken a leading role in web application development, largely because they provide a vast assortment of powerful components that are easily composed into a polished presentation with a convenient user interface. But for the same reason, even a sophisticated application may use only a small fraction of the framework code that it deploys, and vulnerabilities in the remaining code can expose the website to attacks. Table I shows that three websites hosted by our group use just 4.5-11.7% of the underlying framework. Compounding this is the highly dynamic construction of PHP applications, in which code is dynamically loaded from plain text files—and even user input strings—and fundamental program elements such as function call targets are often specified by string variables. From this perspective, the diverse and flexible functionality provided by the framework represents an important trade-off: it provides convenience for development of the website, yet creates a needless security liability for deployment of the site.

Instead of settling for a compromise between convenience and security, we developed ZENIDS1 to accurately and efficiently detect malicious intrusions. Users retain the freedom to install, configure, customize and even extend any PHP application. During a short online training period, ZENIDS learns the set of execution paths that the deployed application is using. The ZENIDS monitor raises an intrusion alert when the execution of a request in an unprivileged session diverges from the set of trusted execution paths. Since ZENIDS is extremely sensitive to variations in execution, site changes of any kind could result in a high rate of false positives— for example, if a blogger writes a post having as-yet-unused formatting such as a table, the PHP code that renders the post in HTML may take different paths than for any previous post. To accommodate natural evolution in an application’s usage of its underlying framework, ZENIDS selectively trusts new control flow paths that are directly associated with data changes made by privileged users. This allows developers and administrators to use any part of the framework’s rich feature set, yet prevents abuse of both deployed code and dynamic control flow branches that the site is not presently using.

A. Overview To protect a website with ZENIDS, the administrator installs the instrumented PHP interpreter with the ZENIDS extension in an otherwise standard LAMP or WIMP stack. For applications that implement user privileges, a hook must be added in the application’s PHP code to notify ZENIDS of login and logout events. ZENIDS learns the set of features that site visitors are currently using by recording execution traces to a trusted profile for a short period of time. In monitoring mode, ZENIDS raises an intrusion alert when the execution of an unprivileged HTTP request diverges from the trusted profile.

Our experiments in Section VII demonstrate that ZENIDS detects recent attacks against vulnerable applications, yet rarely raises a false alert when deployed on the same applications receiving live Internet traffic. After configuring a WordPress site with 9 vulnerable plugins and a vulnerable theme, ZENIDS detected attempts to exploit all 10 vulnerabilities, only raising false alerts on invalid form entries. We recorded HTTP traffic to live deployments of WordPress, the GitList repository viewer, and DokuWiki for 360 days, then replayed the traffic to replica sites monitored by ZENIDS. The false positive rate was less than .01%, yet ZENIDS raised 38,076 true alerts among more than 1.5 million requests. Privileged users made changes to these sites during the experiment that would have resulted in false alerts on every request, but ZENIDS safely expanded the trusted profile, meanwhile continuing to raise true alerts on malicious requests. A trivial implementation of ZENIDS has 10× overhead vs. a LAMP stack having typical optimizations. In Section VI we employ redundancy elimination and caching techniques to reduce overhead below 5% without compromising security.

B. Intended Usage Scenario We envision ZENIDS being deployed both by web site administrators and by cloud providers who wish to provide an extra service to their users. Although our false positive rate is extremely small, in many scenarios automatically blocking traffic is unacceptable due to the small risk of blocking legitimate visitor requests. Thus, we have designed ZENIDS to provide users with alerts of potential attacks. Users can then manually review the alerts and either write rules to drop the malicious requests or whitelist the control flow as benevolent. Our experiments show that the vast majority of ZENIDS alerts correspond to real attacks. For higher risk deployments where training ZENIDS on live web traffic is less practical, our results show it is feasible to begin training with artificial or trusted traffic, then complete the trusted profile by manually reviewing alerts during an initial segment of live traffic.

C. Contributions This paper makes the following contributions: • A technique for recording a trusted profile of application features that are currently used by unprivileged visitors. • A taint-tracking technique to safely expand the trusted profile according to changes made by trusted users, meanwhile continuing to detect anomalous requests. • An implementation of ZENIDS that supports all features of PHP 7 and performs at low overhead on large web frameworks such as WordPress and Symfony. • An evaluation of the performance, usability and security of ZENIDS in popular web applications facing live Internet traffic and recently reported exploits.