
Shellcode: A Windows PIC Using RSA-2048 Key Exchange, AES-256, SHA-3 - shiski
https://modexp.wordpress.com/2016/12/26/windows-pic/
======
tptacek
Yikes.

The crypto routines are mostly in spp.c (there are hand-written C
implementations of AES and SHA3 in aes.c and sha3.c, but RSA is done directly
off the top of OpenSSL's BN routines).

There are (I think?) at least 3 really bad crypto bugs here, but I didn't look
really hard for them. Since this is shellcode, and not something anyone would
ever legitimately rely on, it might be worth treating this like an exercise.
Anyone want to spot the bugs?

 _edit_

Here are my three, just so I can't cheat:

e019c30c75f24758a7f0abb26397f289a331c4f26daa6412d8e131924472401c

74971f5e207fdc8db836f959e48a4bb3bfbb8701870bd2d61d6178b0c4cc5109

9a9cb1b33126408bce87021e57d3552f62c8f57200f501909a865b59f64cc995

~~~
j_west
Hello Thomas.

I wrote the PIC with overall intention of minimizing code size and while I was
aware of the unauthenticated length, lack of RSA padding and potential for
MitM attack, I didn't think anyone would be even remotely interested in the
code for its intended purpose. For me, it's just a bit of fun.

I've since added authentication of length but I'm not suggesting it's solved
any other problems that might exist. If you spot them, I'd be happy to fix.I'm
not aware of anyone that bothered to test it so that tells you how much
interest there is in it.

I've looked at some of the AEAD algorithms from CAESAR and will probably
choose between OCB and KetJe unless the results indicate something better.

But for now, this code is really just experimental. It's merely a PoC and
nothing more.

As for using OpenSSL BN/RSA library, the reasons for this are simply to avoid
implementing a PRNG with random tests and the additional math routines to
generate the key pair.

I intend to implement those routines later which would also be used for
signature verification but for now OpenSSL gets the server component working
with client (which was my main focus).

Anyway, thanks for your interest. I appreciate feedback good or bad.

~~~
tptacek
Your code isn't any worse than tens of commercial systems I've looked at
professionally. The difference is just that yours is shellcode, so there's no-
harm-no-foul in poking holes in it publicly.

OCB is a good choice, as would be Chapoly (since the Salsa core and Poly1305
MAC are both extremely simple in code).

Since you're Windows native, you should use the system's secure random number
generator rather than OpenSSL's.

I still don't understand the authentication model here, or how RSA is really
helping.

~~~
j_west
Another reason for using OpenSSL was to eventually get the server component
running on unix-based OS. I should have explained that in post because it does
seem odd using OpenSSL on Windows when I could just as easily use Crypto API.

"I still don't understand the authentication model here"

Sorry if I misunderstand but If by that you mean the way in which packets are
transported between 2 systems;Length first, then data. I just wanted a really
lightweight method of transmitting data so that it would be easier to
implement in assembly rather than using TLS, SSH or some other well
established protocol that would require lots of code. It's possible to use
some really lightweight implementation of TLS but I assume the code would grow
significantly.

There is support for SSL + TLS through SChannel and I probably will write
something with this in the future just to see how it works out.

If you mean I could simply embed whatever keys are required inside the payload
and use those for encryption? I thought with some form of key exchange, it
would make the traffic more difficult to analyze.

If session keys were inside payload then it's just a simple matter of
extracting keys from this and decrypting traffic.

I looked at poly1305 for authentication briefly but must test it out, it does
look more compact than using AES + SHA3.

Until you mentioned here, I wasn't aware truncated SHA2 hashes were immune to
length extension attack but even without the HMAC code, SHA2 still generates
more code than SHA3.

------
tedunangst
Is it weird that this article attributes the idea of deriving shellcode by
compiling C code to a 2010 article? That's how the shellcode in smashing the
stack was generated.

