Bug #3218
openssl_state does the wrong thing
Description
The ssl_state keyword does not alert on the correct state when specified in the rule.
Example 1: should work with client_hello, but only works with server_hello
alert tls any any -> any [465,25,587] (msg:"Test 1 SNI in SMTPS incorrect state (server_hello)"; tls_sni; content:"flagstring"; flow:established,to_server; ssl_state:server_hello; classtype:attempted-admin; sid:1003923; rev:1;)
alert tls any any -> any [465,25,587] (msg:"Test 1 SNI in SMTPS desired state (client_hello)"; tls_sni; content:"flagstring"; flow:established,to_server; ssl_state:client_hello; classtype:attempted-admin; sid:1003924; rev:1;)
fast.log:
09/30/2019-19:55:33.413760 [**] [1:1003923:1] Test 1 SNI in SMTPS incorrect state (server_hello) [**] [Classification: Attempted Administrator Privilege Gain] [Priority: 1] {TCP} 192.168.4.5:55804 -> 69.167.159.100:587
Example 2: should work with client_hello, but only works with server_keyx
alert tls any any -> any any (msg:"Test 2 SNI in HTTPS incorrect state (server_keyx)"; tls_sni; content:"www.google.com"; flow:established,to_server; ssl_state:server_keyx; classtype:attempted-admin; sid:1003925; rev:1;)
alert tls any any -> any any (msg:"Test 2 SNI in HTTPS correct state (client_hello)"; tls_sni; content:"www.google.com"; flow:established,to_server; ssl_state:client_hello; classtype:attempted-admin; sid:1003926; rev:1;)
fast.log:
09/27/2019-17:32:40.365473 [**] [1:1003925:1] Test 2 SNI in HTTPS incorrect state (server_keyx) [**] [Classification: Attempted Administrator Privilege Gain] [Priority: 1] {TCP} 192.168.100.10:49159 -> 172.217.4.68:443
Example 3: should only alert with server_hello state, instead alerts with client_keyx
alert tls any any -> any any (msg:"Test 3 HTTPS certificate incorrect state"; content:"Google Trust Services"; flow:established,to_client; ssl_state:client_keyx; classtype:attempted-admin; sid:1003928; rev:1;)
alert tls any any -> any any (msg:"Test 3 HTTPS certificate desired state"; content:"Google Trust Services"; flow:established,to_client; ssl_state:server_hello; classtype:attempted-admin; sid:1003929; rev:1;)
fast.log
09/27/2019-17:32:40.416945 [**] [1:1003928:1] Test 3 HTTPS certificate incorrect state [**] [Classification: Attempted Administrator Privilege Gain] [Priority: 1] {TCP} 172.217.4.68:443 -> 192.168.100.10:49159
Tested with:
5.0.0-dev (9340769ad 2019-09-29)
4.1.5 RELEASE (with and without rust)
Files
Updated by Andreas Herz about 5 years ago
- Assignee set to OISF Dev
- Target version set to TBD
Updated by Victor Julien about 5 years ago
Can you create some SV tests out of these pcaps/rules?
Updated by Philippe Antoine almost 3 years ago
https://github.com/OISF/suricata-verify/pull/136 had been created by the way
Updated by Victor Julien over 2 years ago
- Target version changed from TBD to 7.0.0-beta1
Updated by Victor Julien about 2 years ago
- Target version changed from 7.0.0-beta1 to 7.0.0-rc1
Updated by Victor Julien about 2 years ago
- Target version changed from 7.0.0-rc1 to 8.0.0-beta1
Updated by Philippe Antoine over 1 year ago
- Label deleted (
Needs Suricata-Verify test)
S-V test is the oldest alive https://github.com/OISF/suricata-verify/pull/136
Updated by Victor Julien 3 months ago
- Related to Bug #7274: ssl_state:unknown not implemented added
Updated by Victor Julien 3 months ago
The issue is due to the time of app update vs time of inspection. In IPS mode, at least the first test case works. Packet 10 has the client hello and sni, and matches.
In IDS mode, inspection is delayed by the ACK. This results in the `ssl_state->current_flags` being reset by the processing of the server hello as inspection happens in the first packet in the toserver direction after the ACKing of the client hello. This means that packet 13 inspects the signature. As the TLS state has moved on to server hello, that sig matches instead of the correct one.
It's not immediately clear to me how to address this. One way could be to track these flags in the session per direction.