Polymorphic Viruses

• Recall that Earlybird (and all security systems) makes assumptions.
• To avoid detection, a virus writer will try to break those assumptions.
• Viruses can try to change their own code during replication.
• 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 random key.
• 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 executable format
• 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 process.
• 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 costly.
• It may work like a time bomb, spreading slowly, but waiting for a good saturation of infectible hosts before simulataneously launching the attack.

• 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 previous day.
• Telescope analysis traced first infected hosts back to a European retail ISP
• Analysts concluded it was written by a professional.

Web Security

• 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] [Reason-Phrase]
1xx: informational (e.g. I am still processing your request)
2xx: Success
3xx: Redirection
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 example.


• URLs (or URIs for Uniform Resource Identifier)
• URLs are complicated
• URI::=scheme ":" heir-part["?"query]["#"fragments]
• There are ~750 schemes: http, ftp, tel, ldap, etc
• It is possible to encode the state of a session in the URL
• 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 www.whitehouse.gov

• They can be used for obfuscation.
E.g. use IP address or unicode instead of readable string



• 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 then (re)posted.
• Just because you can't see it on the screen does not make it hard to eavesdrop
• State can be stored in cookies.


• Cookies
• They contain: NAME=STRING [expire date], [path], [domain], [secure]
• The NAME=STRING typically encodes the state information.
• Expiration date may be used to timeout sessions
• Path and Domain fields help restrict when a cookie is sent.
• The [secure] flag causes the cookie only to be sent with https.
• When connecting to a server the client browser looks through the cache and sends all cookies that apply.
• 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 data.
• 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.
• The code may cause cookies to be sent to some address.