Re: Decrypting data within an opened channel?

[Karl Scott <karlscottbg@xxxxxxxxx>]

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