Webserver's issue found to be much larger-scale than initially thought Nginx (pronounced engine-x), a lightweight alternative to Apache when it comes to webservers, installs access and error logs that are world-readable by default. Intitially, the security advisory related to the issue noted that the impact was low, but researchers at CloudPassage and Redspin have discovered that the issue has a much wider reach, including current source-based installations. An easily deployed, lighweight alternative to Apache when it comes to webservers, Nginx doesn’t tax resources and is able to handle high-traffic domains with ease. The virsitility makes it a favorite for developers the world over, as well as a favorite with investors — who dropped $10 million in funding on the company last month. Many of the Web’s most popular websites run Nginx, including Facebook, Hulu, Dropbox, CloudFlare, GitHub, and more. According to Netcraft, 15 percent of the top million busiest websites run the platform. However, Nginx comes with a rather unique and unexpected risk that needs to be considered before it’s deployed into production. Last week, US-CERT released CVE-2013-0337 that highlights an issue with how Nginx creates access.log and error.log — noting that they are installed with world-readable permissions. [Log management basics]US-CERT, running with the Gentoo Linux advisory, noted that Nginx versions 1.3.13 and earlier were vulnerable, but David Shaw, CTO at Redspin, and Andrew Hay, Director of Applied Security Research at CloudPassage Inc., have discovered a larger affected version count than disclosed in the CVE. According to their tests, Nginx 1.5.6, 1.4.3, and 1.2.9 when installed from source also set world-readable permissions by default. Moreover, the Amazon Linux implementation of Nginx and the version on Ubuntu do it too, and it is likely that other “combinations of operating system specific packages are suceptible to the issues in the CVE,” Hay noted in a report on the issue. When asked about the issue, Nginx’s Maxim Dounin told one researcher that his company was fine with how the default permissions on the logs were set. “If in a particular configuration stricter permissions are required, this may be done either by creating appropriate log files with needed permissions, or by restricting access to a directory with log files,” Dounin said. But how serious is the issue? First, it’s a violation of responsible security practices for information access, but at the same time, it isn’t the Holy Grail of vulnerabilities, Hay told CSO. But in his opinion “the default configuration does give too much access for a production environment.” Nginx is popular, and that popularity is only growing month over month. So what does this issue mean for an organization risk wise, and how can it impact their security posture? “I think it depends entirely on how your web applications are configured to write to the nginx logs. The last thing you want is for your application to log sensitive PII or other regulated data into a log file that is publically accessible by anyone on the system,” Hay explained. “The likelihood of a security risk is low but the potential for privacy related risk is much higher. I can’t help but think an organization would not be too pleased to discover this particular finding during the course of an audit.” With that said, we asked Hay his thoughts on what needs to be done to correct this issue, especially since the fix has been placed on the user’s shoulders by Nginx. What about using logroatate to manage the files? “If you use logrotate you can rotate the existing log file and create a new log file with the specified permissions, owner, and group. The default, however, is to use the same mode, owner, and group as the original file. The odds that a user will apply security scrutiny to the logrotate configuration when they’re already ignoring the native log file permissions, however, is unlikely,” he said. “The quickest way to correct the issue is to use the chmod utility to either reduce existing, or overlay new, permissions. Users should also ensure that these permissions remain intact by employing continuous monitoring methodologies and tools.” Related content feature Top cybersecurity M&A deals for 2023 Fears of recession, rising interest rates, mass tech layoffs, and conservative spending trends are likely to make dealmakers cautious, but an ever-increasing need to defend against bigger and faster attacks will likely keep M&A activity steady in By CSO Staff Sep 22, 2023 24 mins Mergers and Acquisitions Mergers and Acquisitions Mergers and Acquisitions brandpost Unmasking ransomware threat clusters: Why it matters to defenders Similar patterns of behavior among ransomware treat groups can help security teams better understand and prepare for attacks By Joan Goodchild Sep 21, 2023 3 mins Cybercrime news analysis China’s offensive cyber operations support “soft power” agenda in Africa Researchers track Chinese cyber espionage intrusions targeting African industrial sectors. By Michael Hill Sep 21, 2023 5 mins Advanced Persistent Threats Cyberattacks Critical Infrastructure brandpost Proactive OT security requires visibility + prevention You cannot protect your operation by simply watching and waiting. It is essential to have a defense-in-depth approach. By Austen Byers Sep 21, 2023 4 mins Security Podcasts Videos Resources Events SUBSCRIBE TO OUR NEWSLETTER From our editors straight to your inbox Get started by entering your email address below. Please enter a valid email address Subscribe