Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SSH Analyzer Skipping Some Encrypted Messages #566

anthonykasza opened this issue Sep 3, 2019 · 2 comments · Fixed by #567


Copy link

commented Sep 3, 2019

The first encrypted message of an SSH session is not processed if it is included in a packet which also includes an SSH DH message or NewKeys message. This means the ssh_encrypted_packet() event is not raised under certain conditions such as specific client + server combinations. See the attached pcaps

In the pcap named ssh_server_sends_first_enc_pkt_with_newkeys.pcap the server sends its DH reply, NewKeys, and an encrypted message (the first of the session) all in the same packet (packet 12). The encrypted message is not processed by Zeek's SSH analyzer as is expected. The first encrypted packet processed by Zeek's SSH protocol analyzer is packet 15.

In the pcap named ssh_client_sends_first_enc_pkt_with_newkeys.pcap, the client includes an encrypted message (the first of the session) in the packet carrying its NewKeys message (packet 13). Yet, the first encrypted message processed by Zeek's protocol analyzer is packet 15.

This bug can be demonstrated via the following script:

global pkts: count = 0;
redef SSH::disable_analyzer_after_detection = F;

event ssh_encrypted_packet (c: connection, orig: bool, len: count) {
  if (pkts < 2) {
    print orig ? len : len * -1;
    pkts = pkts + 1;
  } else {

Output of the script when run on the attached pcaps.

$ bro test.bro -Cr ssh_client_sends_first_enc_pkt_with_newkeys.pcap 

$ bro test.bro -Cr ssh_server_sends_first_enc_pkt_with_newkeys.pcap

In both cases, the first encrypted packet to raise the ssh_encrypted_packet() event is the first encrypted packet NOT included with any type of SSH message.


This comment has been minimized.

Copy link

commented Sep 3, 2019

Yeah, looks like we're not raising ssh_encrypted_packet for data in the later portion of a (reassembled) tcp segment that transitions into an encrypted state in the middle of that segment. I'll take a look if it's easy to update the binpac grammar to capture that data in the event as well.

(A technicality that's maybe interesting to keep in mind is that this event has "packet" in the name, but maybe really ought to be thought of as "segment" due to the way it's currently raised using the length of data pertaining to reassembled TCP segments being fed into the analyzer, which may end up actually spanning multiple packets, like in the case we're filling in a previous gap).


This comment has been minimized.

Copy link

commented Sep 3, 2019

Even more confusing is that SSH uses the term "packet" for its binary format.

jsiwek added a commit that referenced this issue Sep 4, 2019
GH-566: fix cases where ssh_encrypted_packet event wasn't raised
When encrypted data was bundled within the same segment as the NewKeys
message, it wasn't not reported via a ssh_encrypted_package event as
it should have been.
rsmmr added a commit that referenced this issue Sep 17, 2019
Merge remote-tracking branch 'origin/topic/jsiwek/gh-566-fix-ssh-encr…

* origin/topic/jsiwek/gh-566-fix-ssh-encrypted-packet:
  GH-566: fix cases where ssh_encrypted_packet event wasn't raised

@rsmmr rsmmr closed this in #567 Sep 17, 2019

@jsiwek jsiwek added this to Unassigned / Todo in Release 3.1.0 via automation Sep 17, 2019

@jsiwek jsiwek added this to the 3.1.0 milestone Sep 17, 2019

@jsiwek jsiwek moved this from Unassigned / Todo to Done in Release 3.1.0 Sep 17, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants
You can’t perform that action at this time.