“Shrink Wrap code attack” is just the act of exploiting holes in unpatched or poorly-configured software. To use the term another way, a “Shrink Wrap vulnerability” would be one which should only be seen in a product immediately after its initial installation – “fresh out of the shrink wrap” you might say.
Most of the Internet relies upon a relatively small number of different applications, frameworks, and OS’s. Because these platforms are shared across a large target base, and because so many organizations and/or admins choose to ignore the “low-hanging fruit”, these sorts of vulnerabilities are often the first an attacker will turn to in order to quickly exploit a system.
Here are some general descriptions of what might be categorized as a “Shrink Wrap vulnerability”:
- A software bug present in the original version of a product, for which the vendor has released an update but the system admin has not patched.
- An insecure default configuration option still in place after the system has been put into production.
- Example: Default (esp. when publicly known or easily calculated) account usernames & passwords left unchanged.
- Debugging scripts or insecure test pages that are bundled with the software, which should have been removed prior to production use.
- Example: A “Hello World” script or page left in place, with an XSS vulnerability.
The above vulnerabilities are not, in most regards, very different from any other vulnerability. What makes them stand out though, is that they are so easily fixable and really are not the types that should be found in production systems. These are the types of vulnerabilities that should be resolved during the initial build process of the system or application, but too many sysadmins and developers out there will carelessly or ignorantly leave them open for the whole Internet to exploit.