CIS511 Class Notes, April 13, 2006
from Paul Rowe
The Witty Worm
- Recall that Earlybird (and all security systems) makes
- To avoid detection, a virus writer will try to break
- Viruses can try to change their own code during
- The change should be global to avoid detection, and the
possible number of outcomes of the changing process should
be large to avoid setting of threshold alarms.
- The virus may encrypt most of its code with a
- The code required to decrypt, may still serve as a
virus signature, though.
- If the virus spreads through encrypted SSL
communication then a similar effect is obtained at
least as far as a filter is concerned.
- Another technique would be to use a self-decompressing
- This is a useful functionality so you may not want to
filter all such files.
- Instead of NOP commands you could use "add 0" or
"multiply by 1" commands that have the same effect, but
look different to an IDS.
- Such viruses are called "Metamorphic viruses."
- There exist C++ libraries that can automate this
- The libraries can be applied to themselves, to disguise
their presence in the virus code.
- Viruses don't need to scan addresses randomly.
- It can search for "powered by php" on Google
for example, to get known vulnerable addresses.
- It can use information about the local topology
found on infected hosts
- By searching server logs, address books, etc. this
can be very effective and fast
- Viruses can perform "Trickle attacks".
- It may propogate slowly, and cause subtle DoS
over a long period of time, which may end up being more
- It may work like a time bomb, spreading slowly, but
waiting for a good saturation of infectible hosts
before simulataneously launching the attack.
The current situation with malicious code looks pretty
- It spread via single UDP packets, so it could spread
quickly. (12K hosts in 75 mins.)
- It slowly corrupted disc blocks.
- Most notably, it exploited a flaw announced only the
- Telescope analysis traced first infected hosts back to
a European retail ISP
- Analysts concluded it was written by a
Among all the security issues listed on the first two slides,
one is fairly unique to web security: namely, web designers tend to
be graphic designers, not security engineers.
This means that even well intentioned interfaces may have
serious security flaws.
- HTTP is a stateless request/respond protocol.
- Requests include things such as GET, HEAD, POST (for
form entries), etc.
- A response will look like: [HTTP-version] [Status-Code]
1xx: informational (e.g. I am still processing your
4xx: Client error (e.g. 404 not found)
5xx: Server error
- It is now possible to receive an entire page in one TCP
session, as opposed to needing one per picture, for
- URLs (or URIs for Uniform Resource
- URLs are complicated
- URI::=scheme ":"
- There are ~750 schemes: http, ftp, tel, ldap,
- It is possible to encode the state of a session in
- This is what makes Google search result URLs look
like a meaningful mess
- They can be used to confuse people
E.g. www.whitehouse.com instead of
- They can be used for obfuscation.
E.g. use IP address or unicode instead of readable
- Schemes to try to encode state may be insecure
- State can be encoded in the URL
- State be sent in a form in a hidden field which is
- Just because you can't see it on the screen does
not make it hard to eavesdrop
- State can be stored in cookies.
- They contain: NAME=STRING [expire date],
[path], [domain], [secure]
- The NAME=STRING typically encodes the state
- Expiration date may be used to timeout
- Path and Domain fields help restrict when a cookie
- The [secure] flag causes the cookie only to be sent
- When connecting to a server the client browser
looks through the cache and sends all cookies that
- Note possible problems:
- New instances automatically overwrite
old ones. (Used in cross site scripting)
- The browser is not required to delete
expired cookies, which may store confidential
- To delete a cookie one must only set the
expiration date to some past date.
- HTTP shouldn't cache set-cookie headers,
but this is not enforced. Such commands could
be replayed later.
- Scripts and Mobile Code
- CGI ("Common Gateway Interface") allows server
side to call local code in any language.
- There are standard ways to call it, so buffer
overflow attacks are possible.
- PHP Hypertext Processor may naively copy a bogus
URL into the HTML encoded error page.
- If the URL contains scripts then the server will
run those scripts.
- Since the error is generated by the actual server,
all cookies for that server will be sent.