WikiPrint - from Polar Technologies

The attacker poisons a DNS cache to take over authority for a given domain. The attacker then creates a phishing page and tries to steal user's usernames/passwords. There are two classes of experiments that need to be combined:

  1. an experiment where a DNS cache is poisoned, subclass of cache poisoning experiments
  2. an experiment where a phishing attack is conducted via a Web page to steal usernames/passwords

Example 2: DNS cache poisoning for phishing

This example used two metadescriptions. Let's go through each of them. This example is written in [CurrentlyProposedLanguage].

Cache poisoning metadescription

Objects:

Attacker extends Node

Name, fakeResource extends String

Cache extends Object

Cache := {String[] records}

Cardinality:

|Attacker|1

|Name|1

|fakeResource|1

|Cache|1

Relationships:

not collocated(Cache, Attacker)

Definitions:

Attacker a, Cache c, Name n, fakeResource fr

e1 := {type = REPLY, origin = a, destination = c, content = (n=fr)}

s1 := {c.records += (n=fr)}

Timeline:

e1 -> s1

DNS Cache poisoning metadescription

This is a special case of cache poisoning where the target is DNS cache.

Objects:

Attacker extends Node

Auth extends Node

Name extends DNSName

RealIP extends IPAddress

FakeIP extends IPAddress or fakeAuth extends DNSName

victimCache extends Object

victimCache := {DNSRecord[] records}

authCache extends Object

authCache := {DNSRecord[] records = {Name=RealIP, auth(domain(Name)) = Auth}

Cardinality:

|Attacker|1

|Auth|1

|Name|1

|FakeIP|1

|fakeAuth|1

|RealIP|1

|victimCache|1

|authCache|1

Relationships:

not collocated(victimCache, Attacker)

not collocated(victimCache, Auth)

collocated(authCache, Auth)

No image "dnswf1.jpg" attached to CachePoisonExample

(in English: Attacker asks for name.domain - nothing is said if the name is a made up one or real one. Cache then finds the authority for that domain - again nothing is said how. Once found, cache asks the authority for the name.domain and gets a reply. At the same time one of two scenarios can happen. If the name is selected randomly (made-up) then the attacker tries to replace the authority for the domain with some fake authority. Otherwise, he tries to replace the name.domain IP with a fakeIP. In both cases the attacker's reply should arrive before the auth's reply. Note that nothing is said about what a reply has to contain to be accepted as the right reply for the query - which is having a specific queryID. This is protocol dependent and at this model level what's important is that "reply should fit the query". How is the question for lower levels. Also, oftentimes at the lower level guesswork will be needed for the reply to fit the query so there may be looping in the actual experiment - that is all left for the lower level.)

Nothing in addition to the topology and timeline above.

Confidential input metadescription

The phishing attempt is essentially same as presenting a valid page to the user that asks for confidential info - it's just that the location of that page is not as user expected.

Dimensions:

(in English: There is a user and a server node. There are two pieces of information - some confidential information about the user and optionally some public information. The user is a human, which means that his actions should be generated by some process that mimics human behavior.)

No image "loginwf.jpg" attached to CachePoisonExample

(in English: User accesses the server and the server asks the user for some confidential info and possibly some public info. The user then sends those over.)

Nothing in addition to the topology and timeline above.

Experiment design

Now I'm a user who wants to design an experiment. I need to combine two metadescriptions (DNS cache poisoning and phishing) and somehow tie them down to generator choices. To combine I'll do something like this:

No image "dnsphishcomb.jpg" attached to CachePoisonExample

i.e. the fakeIP from DNS cache poisoning metadescription belongs to the server from confidential input metadescription. Notice that I did nothing to say that fakeIP should match the IP address of the server but that's obvious from the context. Since fakeIP is an IP address it must match an IP address that somehow has to be related to the server.

The system now needs to offer me several generators: