Quantcast

schema thoughts - IP network attributes and exploit artifacts

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

schema thoughts - IP network attributes and exploit artifacts

jose nazario
looking over the schema and thinking about my experiences with ICSG  
and also with expressing malicious website behaviors in a schema. two  
things come to mind.

the first is that the "Network_Attributes" elements (yes, there are  
two different ones, similar but not the same ...) don't have anything  
about the IP protocol nor the application protocol. i suggest adding  
these sub-elements. i also suggest that they be standardizes on the  
IANA names (for convenience and lack of ambiguity).

the second is expressing exploits and their effects. i think that  
increasingly exploits are an artifact that should not be ignored in  
this space, and with minimal effort it can be explicitly supported  
(rather than shoehorning it in). in the malicious website world i've  
been working on a honeyclient. here's the alert schema i've been  
developing:

        http://code.google.com/p/phoneyc/source/browse/phoneyc/trunk/doc/xml/ 
output/example.xsd

it's loosely based on the data captured by wepawet (i have never seen  
an XML schema for wepawet):

        http://wepawet.cs.ucsb.edu/view.php?
hash=41a0ef86e5b3f342ac336bab0ae9c432&t=1234806209&type=js

one of the foreign keys here is the CVE-ID of the vulnerability being  
exploited. much of the rest of the material is already well supported  
in MAEC, including API calls, arguments, and effects. expressing  
obfuscation is a challenge and i don't see any good solutions there  
that are clear, unambiguous, and accurate.

anyhow, just some ideas.

_____________________________
jose nazario, ph.d. [hidden email]
sr. manager of security research, arbor networks
http://asert.arbor.net/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: schema thoughts - IP network attributes and exploit artifacts

Kirillov, Ivan A.
Great suggestions Jose. I've added IP and Application Layer protocol elements to the Network_Object_Attributes (we've since renamed the two different ones to Network_Object_Attributes and Network_Action_Attributes - hopefully this is a good bit less confusing now). Standardizing on the IANA names (http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml) also makes good sense.

Thanks for the schema link - I think it makes good sense for capturing honeyclient data. One question - can you explain the 'consequence' element under exploits? Is that akin to our effects in MAEC?

As far as exploits, I would say that the exploitation of a vulnerability is a behavior accomplished through some actions, so I concur that we already have the capability to characterize them to some degree. I think we could associate the CVE of the vulnerability exploited at the behavioral level, as an attribute of the behavior's effect.

Shellcode is interesting because although it is used in a singular fashion, it has its own unique attributes and can perform different types of actions. Perhaps it would make sense to create a new object class for it? In terms of its execution, I think that it could be represented in MAEC as a behavior that is dependent on a successful exploit behavior.

Funny that you mention wepawet - I was attempting to characterize some of their analyses using MAEC recently. Unfortunately, there's not too much there that's easily deconstructable into actions and behaviors, so I wasn't able to capture very much beyond the general analysis data.

I also agree that characterizing obfuscation is challenging, both for exploits/web-based malware and binaries. This is something that we plan on tackling at some point, but perhaps initially we should just have a binary indicator for the presence (or lack thereof) of obfuscation?

Regards,
Ivan

Ivan Kirillov
MAEC Working Group
The MITRE Corporation

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of jose nazario
Sent: Thursday, May 20, 2010 3:05 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: schema thoughts - IP network attributes and exploit artifacts

looking over the schema and thinking about my experiences with ICSG  
and also with expressing malicious website behaviors in a schema. two  
things come to mind.

the first is that the "Network_Attributes" elements (yes, there are  
two different ones, similar but not the same ...) don't have anything  
about the IP protocol nor the application protocol. i suggest adding  
these sub-elements. i also suggest that they be standardizes on the  
IANA names (for convenience and lack of ambiguity).

the second is expressing exploits and their effects. i think that  
increasingly exploits are an artifact that should not be ignored in  
this space, and with minimal effort it can be explicitly supported  
(rather than shoehorning it in). in the malicious website world i've  
been working on a honeyclient. here's the alert schema i've been  
developing:

        http://code.google.com/p/phoneyc/source/browse/phoneyc/trunk/doc/xml/ 
output/example.xsd

it's loosely based on the data captured by wepawet (i have never seen  
an XML schema for wepawet):

        http://wepawet.cs.ucsb.edu/view.php?
hash=41a0ef86e5b3f342ac336bab0ae9c432&t=1234806209&type=js

one of the foreign keys here is the CVE-ID of the vulnerability being  
exploited. much of the rest of the material is already well supported  
in MAEC, including API calls, arguments, and effects. expressing  
obfuscation is a challenge and i don't see any good solutions there  
that are clear, unambiguous, and accurate.

anyhow, just some ideas.

_____________________________
jose nazario, ph.d. [hidden email]
sr. manager of security research, arbor networks
http://asert.arbor.net/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: schema thoughts - IP network attributes and exploit artifacts

Maxim Weinstein
On Thu, May 20, 2010 at 4:29 PM, Kirillov, Ivan A. <[hidden email]> wrote:
As far as exploits, I would say that the exploitation of a vulnerability is a behavior accomplished through some actions, so I concur that we already have the capability to characterize them to some degree. I think we could associate the CVE of the vulnerability exploited at the behavioral level, as an attribute of the behavior's effect.

I'd disagree with this insofar as it relates to web-based exploit code. In many cases, a single exploit pack will attempt several different exploits/actions via different vulnerabilities. From a tracking standpoint, there's a value to knowing that a particular pattern of javascript code is recurring, regardless of its activity.

Regards,
Maxim
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: schema thoughts - IP network attributes and exploit artifacts

Kirillov, Ivan A.

Good point Maxim – characterizing a vulnerability (CVE) solely as part of a behavioral effect assumes that the behavior itself was successful, and that the effect occurred.

 

I would certainly agree that characterizing attempted behaviors and their constituent actions is useful for correlation and tracking. Therefore, we could also associate CVE’s with the ‘Purpose’ behavioral element, which at the moment serves as a textual description of what the behavior was intended to accomplish.

 

Regards,

Ivan

 

Ivan Kirillov

MAEC Working Group
The
MITRE Corporation

From: Maxim Weinstein [mailto:[hidden email]]
Sent: Thursday, May 20, 2010 5:08 PM
To: Kirillov, Ivan A.
Cc: jose nazario; maec-discussion-list Malware Attribute Enumeration Discussion
Subject: Re: schema thoughts - IP network attributes and exploit artifacts

 

On Thu, May 20, 2010 at 4:29 PM, Kirillov, Ivan A. <[hidden email]> wrote:

As far as exploits, I would say that the exploitation of a vulnerability is a behavior accomplished through some actions, so I concur that we already have the capability to characterize them to some degree. I think we could associate the CVE of the vulnerability exploited at the behavioral level, as an attribute of the behavior's effect.


I'd disagree with this insofar as it relates to web-based exploit code. In many cases, a single exploit pack will attempt several different exploits/actions via different vulnerabilities. From a tracking standpoint, there's a value to knowing that a particular pattern of javascript code is recurring, regardless of its activity.

Regards,
Maxim

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: schema thoughts - IP network attributes and exploit artifacts

Maxim Weinstein
That covers one of my points, but not the other, which is the value of capturing the actual exploit code, rather than just the effect of the code. There's a tracking aspect here that's valuable, independent of the analysis of the behavior.

Regards,
Maxim

On Fri, May 21, 2010 at 8:39 AM, Kirillov, Ivan A. <[hidden email]> wrote:

Good point Maxim – characterizing a vulnerability (CVE) solely as part of a behavioral effect assumes that the behavior itself was successful, and that the effect occurred.

 

I would certainly agree that characterizing attempted behaviors and their constituent actions is useful for correlation and tracking. Therefore, we could also associate CVE’s with the ‘Purpose’ behavioral element, which at the moment serves as a textual description of what the behavior was intended to accomplish.

 

Regards,

Ivan

 

Ivan Kirillov

MAEC Working Group
The
MITRE Corporation

From: Maxim Weinstein [mailto:[hidden email]]
Sent: Thursday, May 20, 2010 5:08 PM
To: Kirillov, Ivan A.
Cc: jose nazario; maec-discussion-list Malware Attribute Enumeration Discussion
Subject: Re: schema thoughts - IP network attributes and exploit artifacts

 

On Thu, May 20, 2010 at 4:29 PM, Kirillov, Ivan A. <[hidden email]> wrote:

As far as exploits, I would say that the exploitation of a vulnerability is a behavior accomplished through some actions, so I concur that we already have the capability to characterize them to some degree. I think we could associate the CVE of the vulnerability exploited at the behavioral level, as an attribute of the behavior's effect.


I'd disagree with this insofar as it relates to web-based exploit code. In many cases, a single exploit pack will attempt several different exploits/actions via different vulnerabilities. From a tracking standpoint, there's a value to knowing that a particular pattern of javascript code is recurring, regardless of its activity.

Regards,
Maxim


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: schema thoughts - IP network attributes and exploit artifacts

Kirillov, Ivan A.

Ah, I see. Perhaps I should have made this more explicit, but in referring to these exploit behaviors I’ve always assumed that such code would be captured as part of the action implementation of each action that makes up the behavior.

 

Regards,

Ivan

 

Ivan Kirillov

MAEC Working Group
The
MITRE Corporation

From: Maxim Weinstein [mailto:[hidden email]]
Sent: Friday, May 21, 2010 9:16 AM
To: Kirillov, Ivan A.
Cc: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: Re: schema thoughts - IP network attributes and exploit artifacts

 

That covers one of my points, but not the other, which is the value of capturing the actual exploit code, rather than just the effect of the code. There's a tracking aspect here that's valuable, independent of the analysis of the behavior.

Regards,
Maxim

On Fri, May 21, 2010 at 8:39 AM, Kirillov, Ivan A. <[hidden email]> wrote:

Good point Maxim – characterizing a vulnerability (CVE) solely as part of a behavioral effect assumes that the behavior itself was successful, and that the effect occurred.

 

I would certainly agree that characterizing attempted behaviors and their constituent actions is useful for correlation and tracking. Therefore, we could also associate CVE’s with the ‘Purpose’ behavioral element, which at the moment serves as a textual description of what the behavior was intended to accomplish.

 

Regards,

Ivan

 

Ivan Kirillov

MAEC Working Group
The
MITRE Corporation

From: Maxim Weinstein [mailto:[hidden email]]
Sent: Thursday, May 20, 2010 5:08 PM
To: Kirillov, Ivan A.
Cc: jose nazario; maec-discussion-list Malware Attribute Enumeration Discussion
Subject: Re: schema thoughts - IP network attributes and exploit artifacts

 

On Thu, May 20, 2010 at 4:29 PM, Kirillov, Ivan A. <[hidden email]> wrote:

As far as exploits, I would say that the exploitation of a vulnerability is a behavior accomplished through some actions, so I concur that we already have the capability to characterize them to some degree. I think we could associate the CVE of the vulnerability exploited at the behavioral level, as an attribute of the behavior's effect.


I'd disagree with this insofar as it relates to web-based exploit code. In many cases, a single exploit pack will attempt several different exploits/actions via different vulnerabilities. From a tracking standpoint, there's a value to knowing that a particular pattern of javascript code is recurring, regardless of its activity.

Regards,
Maxim

 

Loading...