On my C|EH course I have heard about term "Shrink Wrap Code Attack", but we've only mentioned it. Now trying to do some research and refresh the topics, I can't seem to find serious description of this attack type.

Looking at presentation PDF I received at the course, it only cites couple of sentences
illustrating the main idea (obviously these presentations are not intended for separate
studying)

it seems that this exact phrase is somewhat colloquial to C|EH, so Google is flooded
only either with instances of above or with quite useless re-interpretations of it

So what is this Shrink Wrap code attack about?

(Any good examples? Or stories how it was particularly successful? Or interesting links?)

Update: This Joel on Software uses the term "Shrinkwrap code" for general type of software that is produced and distributed massively.

Shrinkwrap is software that needs to be used "in the wild" by a large
number of people. It may be actually wrapped in cellophane and sold
at CompUSA, or it may be downloaded over the Internet. It may be commercial
or shareware or open source or GNU or whatever -- the main point here
is software that will be installed and used by thousands or millions of
people.

The problem is that they don't define it. In the PDF they just put 4 bullet points and clip-art of guy cutting his PC with a chainsaw. (The idea those bullet points try to form seems way vague to be considered a definition)
–
Alois MahdalNov 15 '12 at 19:50

3 Answers
3

Strictly based on the context in the presentation, it seems what EC-Council is calling a "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.

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.

Shrink-wrap code attacks.
These attacks take advantage of the built-in
code and scripts most off-the-shelf applications come with. The old
refrain “Why reinvent the wheel?” is often used to describe this
attack type. Why spend time writing code to attack something when you
can buy it already “shrink-wrapped”? These scripts and code pieces are
designed to make installation and administration easier but can lead
to vulnerabilities if not managed appropriately.

Shrink Wrap Code Attacks are attacks where an attacker tries to run default code in the victim's software. This default code (from off-the-shelf libraries and code) is often REM'd or placed in a comment line. With a simple script that removes the REM and ' characters, an attacker can try to let this default (sample) code executed.

That doesn't seem useful. If the attacker's script can modify comments in an already-installed script, why wouldn't it inject arbitrary code, or just run whatever it wants to?
–
GillesAug 14 '13 at 9:27

1

Default code as in "unchanged" or "not configured" or "using default configuration in production". Basically, what @Iszi said, i.e. "fresh out of the shrink wrap". You're actually contradicting yourself - you first say that an attacker "tries to run default code in the victim's software", and later you say the attacker changes this code by "removing commented out code". So which one is it? Default, as is, or changed, re-enabled? And how would naming such attacks as "shrink wrap" make any sense in case of the latter?
–
TildalWaveAug 14 '13 at 10:15