TAOSSA Chapter 16

Ch. 16 Network application protocols

Auditing application protocols

• Collect documentation
• Idendity elements of unknown protocols
• Using packet sniffers
• Initiate the connection several times
  • Did a single field change by a lot or a little?
  • Was the change of values in a field drastic? Could it be random, e.g. a connection ID?
  • Did the size of the packet change? Did a field change in relation to the size of the packet? Could it be a size field?
• Many procotols are composed of messages that have a similar header format and varying body
• Replay messages

Reverse-engineer the application

• Use symbols
• Examine strings in the binary
  
  • Useful for debug strings
  • Getting from error messages to code that generates them
• Examine special values - e.g. unique tag values
• Debug - turn on debugging if possible
• Find communication primitives
  
  • For exampls, for TCP: read(), recv(), recvmsg(), WSArecv()
• Use library tracing
• Match data types with the protocol
  
  • Analyze the structure of untrusted data processed by a server/client, then match elements of these structures with vulnerabilty classes

Binary protocols

• Integer overflows and 32-bit length values
  • When 32bit length variables are used to dynamically allocate space for user-supplied data. Usually results in heap corruption
  • size_t in particular
• Integer underflows and 32-bit length values
  • When variables are not adequately checked against each other to enforce a relationship
  • When length values are required to hold a minimum length but the parsing code never verifies this requirement
• Small data types
  • Sign extension issues are more relevant because programs often natively use 32-bit variables even when dealing with smaller data types

Text-based protocols

• Most vulns in binary protocol implementations result from type conversions and arithmetic boundary conditions.
• Text-based protocols tend to contain vulnerabilties related to text processing - standard buffer overflows, pointer arithmetic errors, off-by-ones etc
• One exception is text-based protocols specifying lengths in text that are converted to integers
• Buffer overflows. Text-based protocols manipulate strings, more vulnerable to simpler buffer overflows than to type conversion errors.
  
  • Unsafe use of string functions
  • Pointer arithmetic bugs are more common because more subtle, especially off-by-ones. Common when there are multiple elements in a single line of text.
• Text-formatting issues. Format string issues, resource access; problems in text data decoding implementations - bad hex or UTF-8 decoding routines.

Data verification

• Cases where information disclosure on the network is bad; or when forged or modified data can result in a security issue on the receiver.
• Encryption may be necessary; data verificaiton may be required.

Access to system resources

• Many protocols allow users request system resources implicitly or explicitly
• Questions to consider:
  • Is credential verification for accessing the resource adequate?
  • Does the application give access to resources that it’s supposed to? (ie. implementation is flawed and discloses more than intended)

HTTP

See chapter 17 for details.

• Header parsing. Vulnerabilities are more likely when parsing a “folded header”. Code sometimes assumes headers are limited in length, but an arbitrary long header can be supplied by using folded headers.
• Accessing resources. HTTP is designed to serve content to clients.
  • Many examples of disclosing arbitrary files from the filesystem.
  • Encoding-related traversal bugs.
  • If the server implements additional features or keywords, check the corresponding code, more likely to have bugs.
• Utility functions.
  • Functions for URL handling - dealing with port, protocoal path components etc. Check for buffer overflows.
  • Logging utility functions can be interesting
• Posting data. Data supplied via POST method. Simple counted data post and chunked encoding.
  • Simple counted - depends on how the length value is interpreted. large values can lead to integer overflows or sign issues. Processing of signed content length values also error prone.
  • Chunked encoding - remote attackers specifying arbitrary sizes has been a problem. Careful sanitation of specified sizes is required to avoid integer overflows oe sign-comparison vulnerabilities. Integer overflows are easier to trigger than the same in simple counted encoding.
  • Note that realloc(0) is equivalent to free, so need to overflow not to 0 but 1 or more.

ISAKMP

• ISAKMP packet header contains a 32 bit length field. Primarily signed issues and integer overflows in this user-controlled value.
• The length header in the header is the total packet length, including the header itself. Developers might assume the length field is larger or equal to the ISAKMP header size (=8). Possible underflow.
• 16 bit length field in ISAKMP payloads. Same - overflows and udnerflow. Minimal size 4 bytes.
• Amount of bytes currently processed + current payload length <= isakmp packet length
• Different payload types

<skipped a long description of various issues with different payloads>

ASN.1

Three standardized methods for encoding: Basic Encoding rules (BER); Packed ER (PER), XML ER (XER)

Data types

• Universal - in the standard
• Application - tags that are unique to applications
• Context-specific - tags used to identify a member in a constructed type (e.g. a set)
• Private - unique to an organization

Primitive vs. constructed types. Constructed composed of one or more simple types and other constructed types. Can be sequences (SEQUENCE), lists (SEQUENCE-OF, SET and SET-OF), or choices

Basic encoding rules

Identifier, length, some content data, and an end-of content (EOC) sequence.

• Identifier class + p/c + tag number. Tag number can be composite if it’s over 30. To encode the value 0x3333, for example, the 0xFF 0xD6 0x33 byte sequence would be used.
• Length definite or indefinite length. Indefinite = terminated with EOC sequence.
• Contents
• End of content - only required when object has an indefinite length. EOC is 0x00 0x00.

Canonical encoding rules (CER) vs Distinguished encoding rules (DER) - limit the ambiguousness of BER.

• CER Same as BER with restrictions: (used when large objects are transmitted; when all the object data is not available; when object sizes are not known at transmission time)
  • Constructed types must use an indefinite length encoding.
  • Primitive types must use the fewest encoding bytes necessary to express the object size.
• DER smaller objects in which all bytes for objects are available and the lengths of objects are known at transmission time.
  • All objects must have a definite length encoding (no EOC)
  • The length encoding must use the fewest bytes necessary (same as CER)

Vulnerabilities in BER, CER, DER implementations

• Tag encodings Some combinations of fields are illegal in certain variants of BER
  • e.g. in CER, an octet string of less than or equal to 1,000 bytes must be encoded using a primitive form rather than a constructed form. Is this really enforced? differences in IDS processing and end host processing.
  • Can trick the implementation into reading more bytes than are available in the data stream.
• Length encodings A common problem.
  • Multibyte encodings - when the length field is made to be more bytes than are left in the data stream.
  • Extended length-encoding value - you can specify 32 bit integers - integer overflows and signed issues.

Packed encoding rules (PER)

More compact than BER. Can be used only to encode values of a single ASN.1 type. COnsists of 3 fields: Preamble, length and contents

• Preamble - a bit map used when dealing with sequence, set, and set-of-data types.
• Length - more complex than in BER. Aligned variants and unaligned variants. Constrained, semiconstrained and unconstrained.
  • The program decoding a PER but stream must already know the structure of an incoming ASN.1 stream so that it knows how to decode the length. Constrained vs unconstrainedand what boundaries are for constrained lengths.

Vulnerabilities in PER

A variety of integer related issues. Problems are more restricted because the values are more constrained.

• In particular for unconstrained lengths bottom 6 bits can be only 1 to 4 but the implementation might not enforce this rule.
• Checking return values incorrectly.

XML encoding rules

Very different problems because this is a text markup language. XER prologue and an XML document element that describes a single ASN.1 object. Prologue does not have to be used.

XER vulnerabilities

Text-based errors: simple buffer overfloes or pointer arithmetic bugs. Programs that exchange XML are often exposing a huge codebase to untrusted data. In particular, check the UTF encoding schemes for encoding Unicode endpoints, see Chapter 8.

DNS

• Domain names and resources records
• Name servers and resolvers
  • Resolver code queries DNS on behalf og user applications
  • Fully functional resolver knows what to do when a non-recursive DNS server doesn’t have an answer
  • Stub resolver relies on a recursive name server to do all the work
• Zones
• Resource record types
• DNS protocol structure
• DNS name encoding and buggy parsers (3www6google3com)

Sample problems:

• Failure to deal with invalid label lenghts. The maximum size for a label is 63 bytes because setting the top 2 bits indicates that the byte is the first in a two-byte pointer, leaving 6 bits to represent a label length. That means any label in which one of the top bits is set but the other one isn’t is an invalid length value.
• Insufficient destination length checks
• Insufficient source length checks
• Pointer values not verified in the packet
• Special pointer values (when pointer compression is used)
• Length variables. (There are no 32-bit integers to specify data lengths in the DNS protocol; everything is 8 or 16 bits)
  • Sign extension of 16-bit values
  • Integer overflows
• DNS spoofing
  • Cache poisoning
  • Spoofing responses