Six Tips to Make Web Compromises Hurt a Little Less

Author: Admin July 25, 2019

~ by Michael Bailey

Web application compromises can be incredibly disruptive, as well as incredibly common. There are multiple remediation strategies or proactive configurations that can be employed in preventing or proactively mitigating web compromises, but recent observed trends suggest a few mitigations aren’t implemented as often as they should be. In addition to the prescribed tips, consider removing the attacker’s immediate means of access (whether that be an attacker’s backdoor, rogue credentials, etc) while performing a parallel root cause analysis to address any larger issues if you find yourself actively under attack. The purpose of this blog is to provide some practical recommendations for businesses or developers impacted by a web compromise or at risk of a web compromise. This is not an exhaustive summary, and we encourage web development teams to study OWASP and implement conventional system security steps such as updating (library dependencies, underlying infrastructure, etc) and in-depth secure application development. None of these recommendations are particularly bleeding-edge, they are merely recommendations that would have mitigated (not to be confused with unilaterally eliminated) a litany of trending web compromise cases.

  • Upload user content to a directory without execution permissions
    • This is especially important for PHP websites as opposed to languages that encourage or require framework-layer routing like Ruby’s Sinatra or Python’s Django. However, PHP still powers the majority of the websites on the Internet. According to Github, as of late 2018 PHP was the fourth most popular language across all of their project repositories. At the time of this writing, w3techs estimates 78% of the internet’s web applications run on PHP
    • The “web root” directory, commonly defaulting to /var/www/html or /var/www on Linux and c:\inetpub\wwwroot on Windows, are the “it just works” folders in PHP and similar languages. Inserting a file at /var/www/html/home.php conventionally makes it available at example.com/home.php. This is an issue for file uploads, because whatever the attacker uploads can be directly reached by the web server and by default, if the upload has one of the proper extensions, it can be executed as executable code. A specific route/function can then be used to retrieve these user-uploaded files, but it’s also important to ensure the end user is not allowed to arbitrarily retrieve any file from the operating system through this route/function. For instance, if the end user is able to upload their profile pictures, serving them to the end user specifically as static content through application code, as opposed to letting the server decide dynamically how to serve them, is generally safer to prevent execution of user-provided content.
  • Running a Content Management System? Enable two-factor authentication
    • Magento compromises make up a significant percentage of our web compromise tasking. Magento, with a little work from the command line, can leverage two-factor authentication to mitigate any brute force attacks against your user accounts. It’s worth noting, a common mitigation strategy is to prevent external access to the admin interface (most commonly via IP restrictions), but there’s nothing to suggest that the two cannot be used in combination.
  • Integrate a Web Application Firewall
    • The use of Web Application Firewalls is frequently disregarded as a suggestion due to their use not being a holistic, “silver bullet” solution, but they can still be used to address a subset of attacks. Generally, they inspect the traffic or user supplied inputs such as POST/GET requests and reject (or, optionally, log) any suspicious patterns. Rich, feature-dense applications like WordPress blogs and Joomla applications (CMSes, large custom applications, etc) need to be given additional attention, as they often implement functionality the web application firewall may find prohibitive by default. A number of solutions exist, from open source solutions* like CIDRAM** or xWAF to managed solutions like Amazon Web Services’ WAF.
  • File integrity/change monitoring
    • Monitoring a production environment for unauthorized changes is significantly less trivial than some may suggest. Some content on a website tends to be dynamic, whether it be recent purchases in a database or today’s date on the website. Additionally, the vendored products in this space are limited. However, application logic can be used to hash or otherwise check parts of the website as well as the website’s dependencies and compare those hashes against the latest known good content. Javascript files and product pages that would otherwise be infrequently updated can be injected with client-side Javascript code to skim credit card and other sensitive data. Identifying an unauthorized change to these files could be critical to protecting consumers.
  • Version Management
    • Arguably the hardest part of containing a web compromise is that backdoors or otherwise malicious code can be trivially embedded alongside legitimate code and there is no silver bullet to automatically differentiate the two. While the previous version may contain the root cause vulnerabilities, an insecure, clean website is better than an insecure, infected website. Git is a popular technology for developers to manage their changes, tag versions, and compare different code versions, but traditional backup solutions would also suffice in most cases. It’s important to confirm the live website is not able to write to the version control system or the attacker will simply be able to overwrite it.
  • Log management
    • Web compromises are almost as certain as death and taxes, but how an organization reacts isn’t nearly as constant. Without logs, there’s a limited number of artifacts to review for web compromises. Web compromises are unlike other compromises since, for example, in a workstation compromise an attacker can carelessly write to a variety of history files, “stomp” on timestamps, and write to a series of system journals, but generally compromised web applications only write to their web server logs (Nginx, Apache, etc) and adjacent services like MySQL server logs. It’s critical that these logs are stored in such a way that the attacker cannot write over them, such as a syslog server. These logs help establish a timeline and correlate related behavior.
  • BONUS: Require key access when administering web servers over SSH
    • While we are far from the first ones to have said this, Crypsis has seen SSH brute forcing used to compromise web servers. Services like fail2ban are commonly used to mitigate this, but it’s more important to implement public/private keys in lieu of simple password authentication. Rotation (scheduled replacement) and password protection of these keys are beneficial means of further protecting SSH authentication. In these kinds of compromises, history files will also be analyzed and should be preserved from the attacker, similar to how logs are to be retained. 

Below are how these solutions could be used to mitigate (not necessarily bring to a permanent end) the “bleeding” of an organization’s website during a compromise.

Can Help Mitigate...

Screen Shot 2019-07-17 at 3.57.08 PM

*Crypsis has not reviewed these solutions for security concerns and we do not stake any of our reputation on these solutions, as they are simply examples. Use third-party dependencies and vendors at your own risk.

**Disclosure: I personally know the CIDRAM project manager.

***Only in certain circumstances could an attacker use their system access to elevate to SQL access, but it is an extremely common series of circumstances.


Topics: Security Insights