Feature #8517
openikev2: new buffers and keywords
Description
Recently reviewed and attempted to create coverage on Windows IKEv2 vulnerability which lead me to find that Suricata only carves buffers for nonce and key exchange payloads but here having access to a buffer for the Encrypted Payload would have been convenient.
It would great to have the rest of the IKE payloads given keyword buffers.
RFC: https://datatracker.ietf.org/doc/html/rfc4306
Additionally, it'd be great to have a keyword for Next Payload which contains all `next payload` values (in sequence) or for each payload a keyword (ike.encrypt_payload_next).
VJ Updated by Victor Julien about 1 month ago
- Subject changed from New IKEv2 Payloads Buffers and Keywords to ikev2: new buffers and keywords
Could you provide a more specific lists of which buffers and keywords you'd expect, suggest naming and syntax and ideally also describe what the usecase per keyword is?
VJ Updated by Victor Julien about 1 month ago
- Related to Task #4772: tracking: parity between fields logged and fields available for detection added
PA Updated by Philippe Antoine about 1 month ago
- Status changed from New to Assigned
- Assignee set to Community Ticket
SD Updated by Stuart DC about 1 month ago ยท Edited
current ikev2 payloads as buffers/keywords
nonce -> already exists as ike.nonce_payload
key exchange -> already exists as ike.key_exchange_payload
new ikev2 payloads would be implemented similarly as the above.
security association -> ike.security_assoc_payload
identification -> ike.identification_payload
certificate -> ike.certificate_payload
certificate request -> ike.certificate_req_payload
authentication -> ike.auth_payload
notify -> ike.notify_payload
delete -> ike.delete_payload
traffic selector -> ike.traffic_selector_payload
encrypted -> ike.encrypted_payload
configuration -> ike.config_payload
extension authentication protocol (eap) -> ike.eap_payload
unfortunately I can't speculate to the use case per keyword. the discovery of this vulnerability does warrant a need to easily navigate IKEv2 payloads in order to test values within the desired IKE payload.
current implementation only allows a rule to blindly match with an assumption on which payloads exists within the IKE packet.
PA Updated by Philippe Antoine about 1 month ago
- Status changed from Assigned to Triaged
Thanks
Are these fields already logged by Suricata ?
assumption on which payloads exists within the IKE packet.
Should we have a ike.payload_type keyword ? (is it relevant for the protocol ?)
SD Updated by Stuart DC 10 days ago
Philippe Antoine wrote in #note-5:
Are these fields already logged by Suricata ?
These fields are not being logged in Suricata currently.
Should we have a ike.payload_type keyword ? (is it relevant for the protocol ?)
I think an ike payload type should be included. This would the IKE Next Payload field, which indicates which payload appears next in the packet.
I suggest in the main ticket, there could be either a `ike.next_payload` keyword that contains (in sequence) the array of payloads in the packet and/or for each ike payload a keyword (ike.encrypt_payload.next) that would contain the value for the next payload.