Re: Decrypting data within an opened channel?

[Karl Scott <karlscottbg@xxxxxxxxx>]

Hey Aris,

Just needed for correct myself here. Of course, you're correct about the
HMACs.

I missed something in my calculations late Friday night... not too big a
shock :)

5+5 [5 because of the 4 byte packet length, plus one byte padding length,
once for each packet] +(44−7−1)+(348−18−1)+7+18 = 400, with 40 bytes for 2
HMACs.
Again, this is right from https://tools.ietf.org/html/rfc4253#section-6.

Thank you!

-Karl

On Mon, Oct 12, 2015 at 2:05 AM, Karl Scott <karlscottbg@xxxxxxxxx> wrote:

> Hi Aris,
>
> I think you're right that I'm confused there somehow.
> I'm not entirely sure it is possible for there to be two HMACs in there
> though, since 44 bytes of data + 7 bytes of padding + 348 bytes of data +
> 18 bytes of padding yeilds 417 bytes of my 440 byte data (the total bytes
> read from the socket), so I think there is only room for one 20 byte HMAC
> in there...?
>
> -Karl
>
> On Sun, Oct 11, 2015 at 4:40 AM, Aris Adamantiadis <aris@xxxxxxxxxxxx>
> wrote:
>
>> Hi Karl,
>>
>> I think you are confused by the packet parsing. Each packet has exactly
>> one HMAC, so I think the two "messages" you found in a single packet may
>> be two different packets.
>>
>> Aris
>>
>> Le 10/10/15 03:56, Karl Scott a écrit :
>> > Hi Aris,
>> >
>> > Thanks for the response.
>> >
>> > To begin, I do understand that public key authentication will not
>> > work. This is ok for my case, since I am strictly using password
>> > authentication.
>> >
>> > To end, I looked carefully for any state changes/unintended side
>> > effects I could be causing that I missed on the first pass through --
>> > and, it looks like I had some test prints that decrypted extra data --
>> > messing up the AES IV, or at least, so I think.
>> > Once I removed the extra attempts at decryption, I was able to read
>> > the packet properly. I also didn't realize that you MUST call
>> > packet_decrypt_len() to get the size you can decrypt, before you can
>> > call packet_decrypt(), because multiple encrypted messages can come in
>> > on one packet. Interestingly, this one packet, in my case, is 440
>> > bytes, with two encrypted bits of data in it, with packet lengths of
>> > 44 bytes and 348 bytes, with paddings of 7 and 18 (in base 10), and
>> > only one 20 byte HMAC. Well, 23 bytes are the extra after the data and
>> > the padding, so that means 20 for the HMAC, but I haven't quite
>> > figured the extra 3 bytes yet. That is for tomorrow!
>> >
>> > Thanks much for the help!
>> >
>> > -Karl
>> >
>> >
>> >
>> > On Fri, Oct 9, 2015 at 2:42 PM, Aris Adamantiadis <aris@xxxxxxxxxxxx
>> > <mailto:aris@xxxxxxxxxxxx>> wrote:
>> >
>> >     Hi Karl,
>> >
>> >     It's hard to figure out what you're doing exactly. How are you
>> >     calculating the session keys needed for the interception ? are you
>> >     redoing the diffie-hellman key exchanges with both sides to set up
>> >     different encryption keys ?
>> >     What ciphers are you negotiating ?
>> >     The problem you describe may be related to a padding problem or a
>> >     desync
>> >     in the packet parsing. All ciphers will decrypt to garbage if you
>> even
>> >     miss a single byte or flip a single bit, with the exception maybe of
>> >     stream cipher modes.
>> >     It seems like you used some small parts of libssh for your
>> >     purpose, you
>> >     may have introduced some unexpected side effect. In all honesty I'm
>> >     surprised you managed to decrypt even the channel opening.
>> >
>> >     Are you aware that there is no way the public key authentication
>> >     (client
>> >     to server) is going to work ? The session id (being signed by
>> >     client) is
>> >     a derivative of the diffie hellman key exchange.
>> >
>> >     Regards,
>> >
>> >     Aris
>> >
>> >     Le 9/10/15 03:45, Karl Scott a écrit :
>> >     > Hey guys,
>> >     >
>> >     > Encrypted data moving from a client to a server should keep the
>> same
>> >     > encryption key regardless of if an SSH channel has been opened
>> >     or not,
>> >     > right? And by channel, I mean something created by the
>> >     > ssh_channel_new() function.
>> >     >
>> >     > To explain, I'm working on an SSH proxy of sorts, and so
>> naturally,
>> >     > one of the things I do is:
>> >     > a. See incoming raw encrypted SSH data coming in, wrapped in TCP.
>> >     > b. Decrypt that data after stripping the TCP headers off, using
>> >     > packet_decrypt_len() or packet_decrypt() and providing the length
>> >     > manually (both of these are libssh provided functions, though
>> >     not part
>> >     > of the API).
>> >     > c. Look at the raw unencrypted data, and expect it to be of the
>> >     normal
>> >     > SSH binary format from here:
>> >     https://tools.ietf.org/html/rfc4253#section-6
>> >     > d. Encrypt the data we were just looking at, and wrap in in the
>> >     > appropriate headers (a modified version of packet_send2 is doing
>> >     this
>> >     > for me wonderfully during testing).
>> >     >
>> >     > This is all working for me, except when it comes time to
>> >     transmit the
>> >     > actual exec command I am trying to use. So, I manage to
>> successfully
>> >     > open a proxied channel, which indicates that my decryption and
>> >     > encryption logic is working properly.
>> >     > Also, disconnect messages are properly read and transmitted,
>> >     where all
>> >     > sides can see the plaintext, so I am very confident of the logic
>> in
>> >     > steps a. to d. listed above.
>> >     > As one last example, I can clearly see the decrypted ASCII text of
>> >     > certain encrypted traffic that brings us up to this problem point,
>> >     > such as "Zsession" in this decrypted hex traffic:
>> >     > 5A0000000773657373696F6E000000000020000000008000
>> >     >
>> >     > But when the client sends the encrypted packet which contains the
>> >     > command we want to exec inside of it, I cannot decrypt it -- I
>> just
>> >     > get garbage when I try. It is as if there is some other
>> >     encryption key
>> >     > I need to be using. The function I am using to decrypt is the
>> >     same as
>> >     > listed in step b. The encryption function I use shouldn't matter
>> in
>> >     > this case, since the client is encrypting the message before it
>> >     > reaches my proxy code.
>> >     >
>> >     > Again, this proxy successfully opens the channel, and successfully
>> >     > decrypts and re-encrypts custom disconnected messages.
>> >     >
>> >     > Any help or ideas would be great -- I've spent all day working on
>> >     > this, with no luck!
>> >     >
>> >     > Thank you!
>> >     >
>> >     > -Karl
>> >
>> >
>> >
>>
>>
>>
>>
>