When performing vulnerability assessments and penetration tests we often get caught up in OS-level vulnerabilities and end up overlooking Layer 7 issues. This is a dangerous trap to get caught in as there's much more of an attack surface on any given Linux system that just telnet and SSH. In fact the majority of Linux-based flaws that I see are in the application layer. Be it with Apache, PHP, or OpenSSL, or just general misconfigurations -- if the vulnerabilities are accessible via HTTP (and thus, generally open to the world) then anything is fair game.
There are the commonly-cited vulnerabilities such as SQL injection and cross-site scripting but there's more to the Linux Web security equation. The following are some of the other Web security vulnerabilities I often see on Linux-based systems -- things you can check for to help minimize your Web-related risks:
- PHP code injection that allows for direct execution of malicious code. I've seen server-side scripting engines accept unfiltered PHP input and run it on the server providing system-level access to the server.
- User names and passwords passed using HTTP GET requests instead of POST requests. This flaw can create a scenario permitting privilege escalation at both the Web application and OS levels.
- Weak passwords often combined with a lack of intruder lockout. I've found that by using an automated password cracker such as Brutus or plain old login guessing, it's often very simple to gain unauthorized access into the Web site/application when weak logins are present.
- Weak file and directory permissions that allow for system enumeration. I typically find backup/test files containing old and unmaintained code that provide insight and information that not everyone needs to see.
- Outdated versions of Apache, PHP, and related code vulnerable to DoS and remote code execution. I recently saw an OpenSSL flaw that allowed for remote denial-of-service by simply using freely-available exploit code on the Internet.
A few other Web-related vulnerabilities that are lower priority -- but are predictable and potentially troublesome nonetheless -- include lack of consistent SSL enforcement across the site, low encryption SSL ciphers (less than 128 bits), SSL version 2 that is susceptible to attack when the traffic is captured off an unsecured wireless network or wired network where someone is using the free Cain tool to perform ARP poison routing, and cookies that are not marked as secure (and thus only transmitted when SSL is present).
Web security weaknesses such as these are best discovered using a commercial (you get what you pay for) Web vulnerability scanner such as Acunetix Web Vulnerability Scanner, WebInspect, N-Stalker, or NTOSpider. Such findings, when repeated consistently over time, can make or break a security assessment or PCI DSS audit. The good news is that most of these weaknesses are very simple to fix. Be it Linux tweaks, patches, or relatively simple code changes, your Web environment can go from getting a "fair" or "poor" security ranking to "very good" or "excellent" one in a matter of days -- all without having to spend a dime.