Re: Decrypting data within an opened channel?

[Aris Adamantiadis <aris@xxxxxxxxxxxx>]

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
>
>
>