Decode SNMPv3 fails

asked 2024-07-05 06:59:55 +0000

Gargamel
1 ●1

updated 2024-07-06 07:28:18 +0000

Wireshark Version 4.2.5 (v4.2.5-0-g4aa814ac25a1)

I have configured a working SNMPv3 connection. So I know the encryption settings and I have already done several other decryptions with Wireshark before. But in this case I always get "Decrypted data not formatted as expected, wrong key?". As mentioned I have configured this SNMPv3 connection by myself and know the parameters I have configured very well and the connection is working with this parameters. Is there an issue in Wireshark with decryption of SHA1 and AES256 PDUs?

Example output with tshark in Linux (but GUI looks the same):

tshark -r /tmp/test.pcap -o 'uat:snmp_users:"","snmpnbuser","SHA1","Arthur_123","AES256","Arthur_123"' | more
Running as user "root" and group "root". This could be dangerous.
    1   0.000000 10.89.253.16 → 10.225.1.204 SNMP 830 encryptedPDU: Decrypted data not formatted as expected
    2   0.000105 10.89.253.16 → 10.225.1.204 SNMP 830 16604 → 162 Len=788
    3   0.000157 10.89.253.16 → 10.225.1.204 SNMP 831 16604 → 162 Len=789
    4   0.000203 10.89.253.16 → 10.225.1.204 SNMP 831 encryptedPDU: Decrypted data not formatted as expected
    5   0.000246 10.89.253.16 → 10.225.1.204 SNMP 831 encryptedPDU: Decrypted data not formatted as expected
    6   0.000289 10.89.253.16 → 10.225.1.204 SNMP 831 encryptedPDU: Decrypted data not formatted as expected
    7   1.051979 10.89.253.16 → 10.225.1.204 SNMP 827 encryptedPDU: Decrypted data not formatted as expected
    8   1.052081 10.89.253.16 → 10.225.1.204 SNMP 827 encryptedPDU: Decrypted data not formatted as expected
    9   1.052126 10.89.253.16 → 10.225.1.204 SNMP 675 encryptedPDU: Decrypted data not formatted as expected
   10   1.052174 10.89.253.16 → 10.225.1.204 SNMP 717 16604 → 162 Len=675
   11   1.052214 10.89.253.16 → 10.225.1.204 SNMP 695 encryptedPDU: Decrypted data not formatted as expected
   12   8.062186 10.89.253.16 → 10.225.1.204 SNMP 830 encryptedPDU: Decrypted data not formatted as expected

Example PCAP file: https://we.tl/t-hJls4QoOTY

Encryption parameters are the same as in the tshark command above.

BR,

Michael

edit retag flag offensive close merge delete

Comments

Hi I did some additional testing and changed passwords and auth protocol and priv protocol. The problem seems to be related to the priv protocol AES256. AES128(AES) seems to work. Unfortunately I can't change this settings in the other system as to many external systems would be affected. Any suggestions? BR, Michael

Gargamel ( 2024-07-05 08:53:19 +0000 )edit

Please add the output of tshark -v to the question.

Chuckc ( 2024-07-05 10:47:06 +0000 )edit

Added Version 4.2.5 (v4.2.5-0-g4aa814ac25a1) to the question as requested.

Gargamel ( 2024-07-05 13:42:57 +0000 )edit

16381: SNMP: Allow for key expansion algorithm selection has been merged.
Available for testing from automated builds.
For Windows, look for Wireshark-4.3.0rc1-437-gad804dac7f8c-x64.exe or later.
Update SNMP users by changing the additional column: Key expansion method to AGENT++.

Chuckc ( 2024-07-11 13:33:10 +0000 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2024-07-09 11:41:36 +0000

Chuckc
3023 ●6 ●611 ●20

(Adding as additional answer so these links don't get lost down in "more comments")
Analysis of the capture file resulted in two items to look at:
19916: SNMP AES192/AES256 key expansion supports only single expansion algorithm

snmp4j: EngineID doesn’t match RFC3411

edit flag offensive delete link

Comments

Hi I'm no programmer so it's not so easy to answer. We are using JBI and I guess Servicemix SNMP. I couldn't find too much documents about it as I'm not in our R&D department.

BR,

Michael

Gargamel ( 2024-07-10 06:48:16 +0000 )edit

add a comment

answered 2024-07-05 13:23:11 +0000

Jaap

13742 ●711 ●115

SHA1 doesn't provide enough key bits for AES256, so key extension needs to be applied. This isn't standardised, however there's draft-reeder-snmpv3-usm-3desede-00 which goes into this. Wireshark seems to be doing that in the SNMP dissector, although I'm not sure if it exactly follows the algorithm in section 2.1 of this draft. It seems to use "K1 | K2" rather than "K2" in the third round, "K1 | K2 | K3" rather than "K3" in the fourth round, etc. Unfortunately I've no setup to dive into this.

edit flag offensive delete link

Comments

Unfortunately I don't have enough points to upload PCAP file. BR, Michael

Gargamel ( 2024-07-05 13:46:25 +0000 )edit

Place it on a public file share (Dropbox, Microsoft, Google, ...) then update the question with a link to it.

Chuckc ( 2024-07-05 13:59:01 +0000 )edit

Added link to nokia.wetransfer.com to the question. https://we.tl/t-hJls4QoOTY

Gargamel ( 2024-07-06 07:30:36 +0000 )edit

Few observations from the capture file.

The SNMP software appears to be Agent++, that could help to get an insight. Strangely enough the AuthoritativeEngineId encoding is incorrect. Does not appear to impact authentication though.
Even though key extension is necessary, for the applicable key sizes, the current implementation in the dissector has to do one round, which performs correctly. It's subsequent rounds that do not follow the draft-reeder-snmpv3-usm-3desede-00 method. It would take a closer look at the Agent++ code to see how they do key extension (PrivAES::extend_short_key) to see if/how this matches.

Jaap ( 2024-07-06 14:01:47 +0000 )edit

    00.. .... = Class: UNIVERSAL (0)
    ..0. .... = P/C: Primitive Encoding
    ...0 0100 = Tag: OCTET STRING (4)
    Length: 13
    msgAuthoritativeEngineID: 80001370010a59fd10a8e7de2c
        1... .... = Engine ID Conformance: RFC3411 (SNMPv3)
        Engine Enterprise ID: AGENT++ (4976)
        Engine ID Format: IPv4 address (1)
        Data not conforming to RFC3411
            [Expert Info (Warning/Protocol): Data not conforming to RFC3411]
                [Data not conforming to RFC3411]
                [Severity level: Warning]
                [Group: Protocol]

80001370    = AGENT++ (4976)
01          = IPv4 address (1)
0a 59 fd 10 = 10.89.253.16
a8e7de2c    = timestamp ???

rfc3411:

                    The fifth octet indicates how the rest (6th and
                    following octets) are formatted. The values for
                    the fifth octet are:

                      0     - reserved, unused.

                      1     - IPv4 address (4 octets)
                              lowest non-special IP address

epan/dissectors/packet-snmp.c:

case SNMP_ENGINEID_FORMAT_IPV4:
    /* 4-byte IPv4 address */
    if (len_remain==4) {
        proto_tree_add_item(tree, hf_snmp_engineid_ipv4, tvb, offset, 4, ENC_BIG_ENDIAN);
        offset+=4;
        len_remain=0;
    }
    break;

If they have added a timestamp? or other value, it should be (fifth octet):

                    128-255 - as ...

(more)

Chuckc ( 2024-07-06 14:40:40 +0000 )edit

see more comments