Chapter 4. Collaborative Defending System for Computer Worms
4.2. Process in Local Extended VODKA
Extended VODKA considers context information. Therefore, the context information such as infecting path analysis, are proposed to reduce the confirmation effort of domain experts. The infecting path analysis is the environment factors for computer worm domain.
Now we will introduce them as follows.
4.2.1 Knowledge Decision Phase
The environment factors in StageII described in Figure 3.2 in computer worm domain can be treated as infecting path analysis. Because most variant worms use the same vulnerabilities to exploit, the system can be determined to have vulnerabilities by mapping Infecting Path Table and System Profile. Such context information will be consulted to make a decision.
Figure 4.2 shows that if we capture candidate embedded knowledge from VODKA. Before confirming by experts, we will analyze first and supply context information for suggesting experts. The infecting path analysis will tell us vulnerable or not by mapping infecting path of original worms and system profile of local host.
With the context information, we have two conditions- certainty or uncertainty.
Certainty means the evidence is powerful enough to confirm. Uncertainty means the evidence is not enough.
Figure 4.2 : Knowledge Decision Phase
The generation of the context information which will decrease the weakness of VODKA are described as follows.
4.2.1.1 Infecting Path Analysis - System Profile and Infecting Path Table
A. System Profile
Some worms are designed to infect wrong configured system and some worms exploit vulnerabilities of system or applications. If we have not patched our system frequently, it is easy to be infected by specific worms based upon the vulnerability of local host recorded in system profile.
Figure 4.3 : System Profile of Local Host How to get System Profile ?
When installing VODKA, the local system profile including ID, OS version and vulnerable applications can be recorded. Once the system profile is modified,
VODKA will update it at the same time.
Now, the system profile is defined according to the worm domain.
Data format of System Profile Definition:
Table 4.1:Format of System Profile
ID OS (Application <-> Vulnerability)
140.113.*.* Windows Xp Internet Explorer5.5 <-> CVE-2001-0154(MIME header)
Notation:
ID:Host IP
OS:Operation System
( Application <-> Vulnerability ):This represents which application is vulnerable Data Type
ID:IPv4 OS:String
( Application <-> Vulnerability ):String
The following is a simple example to show our system profile Table 4.2:System Profile of Local Host
ID OS (Application <-> Vulnerability)
140.113.*.* Windows Xp InternetExplorer5.5 <-> CVE-2001-0154(MIME header) ID:140.113.*.*:the local IP address
OS:The operation system is Windows XP
(Application<->Vulnerability)=(InternetExplorer5.5<->CVE-2001-0154) means
InternetExplorer5.5 with MIME header vulnerability CVE-2001-0154 is the standard name defined by CVE
B. Infecting Path table
Because most variant worms use the same vulnerabilities to infect the system, the infecting path table to acquire vulnerabilities of original worms is proposed.
Infecting Path table
Figure 4.4:Infecting Path Table Acquisition
The infecting path table will be generated in Log collecting Stage. It accompanies with the generation of original rules (original worm). A simple knowledge acquisition is also proposed to acquire the infecting path of original worms.
The infecting table construction algorithm is shown as follows:
Algorithm 4.1: Infecting Path Table Construction Algorithm Input: The worm domain know-how and skeletal of worm Output: The Infecting Path of worm
Step1: List all elementary knowledge objects according to technical documents.
Step2: Transfer each infecting path into the Infecting Path Table.
The following example is given to construct infecting path table of CodeRed.
Example 4.1:Infecting Path Table of CodeRed
In this example, we construct infecting path table of CodeRed. Domain experts will extract infecting path of each original worm from technical documents. Therefore, the CVE-2001-0500, which is the Indexing Service2.0 and IIS6.0 vulnerability, and the CVE-2001-0506, IIS4.0 and IIS5.0 vulnerability, are exploited by CodeRed will be extracted in Step1. Then in Step2, the knowledge objects will be stored into
Infecting Path Table, shown in Table 4.1, with the pair of original name of Worm and the Infecting Paths exploited by the worm, where the data type are both string.
Hence, we can obtain the following infecting path table of CodeRed after the process.
Table 4.3:Infecting Path of CodeRed Worm_Name Infecting_Path
CodeRed
CVE-2001-0500(Indexing Service2.0 and IIS6.0)
CVE-2001-0506(IIS4.0 and IIS5.0)
C. Mapping with System Profile and Infecting Path Table
If local VODKA learns a new variant worm, it may map with system profile and infecting path table of this new variant worm. If the system is vulnerable, the decision confidence will be increased.
The following example is given to illustrate how to map with system profile and infecting path table.
Example 4.2:Mapping with System Profile and Infecting Path Table
Hence, VODKA now can suggest expert that a new variant worm derived from original CodeRed is learned. By mapping with system profile and infecting path table, we can know the system is vulnerable for CodeRed.
Table 4.4:System Profile of Local Host
Table 4.5:Infecting Path Table of CodeRed Family
ID OS (Application <-> Vulnerability) 140.113.87.175 WinXp IIS4.0 <-> CVE-2001-0506
Worm_name Infecting Path
CodeRed CVE-2001-0500(Indexing Service2.0 and IIS6.0)
CVE-2001-0506(IIS4.0 and IIS5.0)
Mapping
Hence, we can know the IIS4.0 has the vulnerability CVE-2001-0506 for CodeRed through such simple mapping. Therefore, the system is vulnerable and the decision confidence is increased.
4.2.1.2 Decision Information for Experts
The decisions information of infecting path analysis will be proposed to help experts make correct decisions. Hence, the confirmation effort of experts to decide variant worms could be reduced. Our suggestion is listed as follows.
Suggestion:System Profile matches infecting path of variant worms or not
According to our suggestion, experts will have two decisions.
1) Certain
It is a variant worm and then we will generate knowledge by EMCUD.
2) Uncertain
It is an uncertain case and will be transferred to collaborative analysis center.
In order to clearly show our decision flow, we give an example to illustrate our idea.
Example 4.3:Uncertain Case in Local VODKA
The Repertory Grid, AOT and partial embedded rules for Yaha are listed in Example 3.1. Now we have receive inference log as follows:
Table 4.6:Inference Log from Inference Engine
Rule # A1 A2 A3 A4 A5 Object CF R2,5 Email flood Project.exe True {25} Tcpsvs32.exe Yaha 0.4 R2,5 Email flood Project.exe True {25} Tcpsvs32.exe Yaha 0.4 R2,3 Email flood readme.exe False {25} svhoot.exe Yaha 0.53 R2,5 Email flood Project.exe True {25} Tcpsvs32.exe Yaha 0.4 R2,5 Email flood Project.exe True {25} Tcpsvs32.exe Yaha 0.4 R2,3 Email flood readme.exe false {25} svhoot.exe Yaha 0.53
R2,5 Email flood Project.exe True {25} Tcpsvs32.exe Yaha 0.4 R2,5 Email flood Project.exe True {25} Tcpsvs32.exe Yaha 0.4 R2,5 Email flood Project.exe True {25} Tcpsvs32.exe Yaha 0.4 R2,5 Email flood Project.exe True {25} Tcpsvs32.exe Yaha 0.4
The large itemset L2=(A2= Project.exe,A5=Tcpsvs32.exe) and minimal support 30% is satisfied.
VODKA will ask the following questions
VODKA:Does the attribute-value pair (A2= Project.exe) AND (A5=Tcpsvs32.exe) belong to any new variant object?
/*VODKA process in the background*/
Suggestion :
Table 4.7:System Profile of Local Host for Yaha
Table 4.8:Infecting Path table of Yaha Family
ID OS (Application <-> Vulnerability)
140.113.87.175 WinXp Outlook<->none
Worm_name Infecting Path
Yaha Email;CVE-2001-0154(MIME Header) Mapping
The result shows that one of infecting path is not existed. But the normal communication of Email is a path to infect.
VODKA:
Suggestion:System without any vulnerability but Email is the way to infect.
Expert:Uncertain
Experts say uncertain because the context information is not enough and the embedded knowledge with low CF may be caused by improperly operation. The local host may possibly install mass mailer software and the firewall may be temporarily abnormal. Hence, we transfer this uncertain case to the collaborative analysis center.