Re: Decrypting data within an opened channel?

[Karl Scott <karlscottbg@xxxxxxxxx>]

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