Contract No.: 285248 Strategic Objective

9.3Scenario Definition

Here are some message definitions that can be used as templates:

from scapy.layers.sixlowpan import LoWPAN_IPHC

from scapy.layers.inet6 import IPv6, ICMPv6EchoRequest

messages['ping_echo'] = LoWPAN_IPHC() \

/ IPv6(dst="aaaa::11:22ff:fe33:4455", src="aaaa::1", hlim=128) \

/ ICMPv6EchoRequest(id=0x1540, seq=0x01, data="test")

messages['example_2'] = LoWPAN_IPHC()/IPv6("""6000000000000000

aaaa000000000000

001122fffe334455

aaaa000000000000

0000000000000001

8000c4cd00000000""".decode('hex'))

The first message is defined by its protocol attributes, using the Scapy definitions, whereas the second one is defined as a raw string, which could have been acquired through packet capture, for instance. Further information can be found in the Scapy documentation.

Then, those messages can be used in XML scenario definitions, such as the one defined below:

type="string" />

In this example, a very simple scenario has been defined:

• 
  first, a message will be sent to the target, using the "ping_echo" template defined in the message.py module excerpt above. It will differ from the template by 3 fields:
  
  • 
    the dst field of the IPv6 layer will be replaced by the value of the first positional argument (passed on the command line using the -a parameter);
    
  • 
    the src field of the IPv6 layer will be replaced by the value of the second positional argument (passed on the command line using the -a parameter);
    
  • 
    the data field of the ICMPv6EchoRequest layer (the actual ICMP payload) will be replaced by the check string;
    
• 
  then, a response will be expected from the target device, and the following will be done:
  
  • 
    the data field of the ICMPv6EchoReply layer (the actual ICMP payload) will be tested, and the test will succeed if it is equal to the check string.
    

10Security-Monitoring: Android Vulnerability Assessment Open API Specification

10.1Introduction to the Android Vulnerability Assessment API

10.1.1Android Vulnerability Assessment API Core

The Android Vulnerability Assessment API is a SOAP API accessed via HTTP that uses XML-based representations for information interchange. It is composed of 2 web services: the Provider web service, that allows devices to update their definition database from the server, and the reporter web service, that allows devices to post analysis results to the server.

10.1.2Intended Audience

This specification is intended for both software developers and reimplementers of this API. For the former, this document provides a full specification of how to interact with the web services. For the latter, this specification provides a full specification of how to reimplement the web service while maintaining compatibility with the existing software.

10.1.3API Change History

This version of the Android Vulnerability Assessment API Guide replaces and obsoletes all previous versions. The most recent changes are described in the table below:

Revision Date	Changes Summary
Jun 28, 2013	Added "/summary" operations Updated paths to reflect R2.3 software changes
Apr 22, 2013	Initial Release

10.1.4Additional Resources

You can download the most current version of this document from the FIWARE specification website at Security-Monitoring: Android Vulnerability Assessment Open API Specification. For more details about the Android Vulnerability Assessment that this specification is based upon, please refer to High Level Description. Related documents, including an Architectural Description, are available at the same site.

10.2General Android Vulnerability Assessment API Information

10.2.1Resources Summary

10.2.2Representation Format

The Android Vulnerability Assessment API supports XML.

10.2.3Resource Identification

Resources are identified using the mechanisms described by HTTP protocol specification as defined by IETF RFC-2616.

10.2.4Faults

Synchronous Faults

Provider Web Service

The OVAL_ProviderWS_AnswerHeader type includes a response_code, which can take the following values:

Fault Element	Associated Error Codes	Expected in All Requests?	Description
Definition Not Found	0	Yes	No definition matching the request was found (this is not necessarily an error)
Definition Found	1	Yes	One or more definition matching the request was found (this usually indicates a successful response)
Malformed Request	2	Yes	The request was malformed
Internal Error	3	Yes	There was an internal server error

Reporter Web Service

The OVAL_UploaderWS_AnswerHeader type includes a response_code, which can take the following values:

Fault Element	Associated Error Codes	Expected in All Requests?	Description
Result uploaded	0	Yes	The request was processed successfully (this is actually not an error)
Bad IMEI (too short)	2	Yes	The IMEI sent in the request was too short
Internal error (database)	3	Yes	There was an error writing to the database
Streaming error	4	Yes	There was an error writing the result to the disk

Download 1.78 Mb.

Share with your friends: