This is a follow up of my previous JSP Shell post. This JSP shell has the following functionality:
- Signed Diffie-Hellman key exchange
- Blowfish Encrypted commands
- Blowfish Encrypted result
However the way I implemented the crypto part is as far as i know flawed, this because I’ll maybe try to break my own implementation. It’s on my todo list to understand more about cryptographic attacks. To my knowledge the following flaws are present(there are probably more, feel free to point them out in the comments). Thanks to the people of #crypto on freenode for answering my questions and having me realize the flaws listed below:
- Non-authenticated exchange of encrypted messages
- The derivation of the Blowfish key from the Diffie-Hellman output isn’t hashed sufficiently
So just to be clear, ONLY the initial key exchange is authenticated using DSA signatures, after which the secret key is established to encrypt the rest of the communication using Blowfish. Let’s take a closer look at the usage and deployment of the shell. If you just want the code, it’s available on my github page. The bin directory contains everything you need for a grab&go usage.
Continue reading “Encrypted JSP Shell with signed diffie-hellman key exchange”
So, just when you think hypes don’t affect you, a new hype gets your attention. Lately Java has hit the news as one of the latest risks and it’s pretty well abused for exploitation. Luckily we all know that exploiting “bugs” is not the only way to abuse Java. You can also abuse the trust Java places in digitally signed code, I’ve blogged about this issue before. Nowadays metasploit/SET even has a ready to use module for it. If you are wondering what all this has to do, with in-memory class loading…well sometimes when executing a java attack you want to make it harder for someone to detect your payload and you also want to leave less traces behind. In terms of Java I think that class loading is the thing that comes the closest to traditional in-memory execution. So let’s get started on making it harder for an investigator to investigate.
Continue reading “Java in-memory class loading”
abusing the trust people have in signed applets.
It’s been blogged before but oh well I always learn by example so here is an example. The thing I’m talking about is trusting signed java applets. In short when you trust a java applet it can do whatever it wants. So what could you do with a java applet? The java source code will steal your mac address, rather useless but it serves the example purpose good enough. The stolen mac address get’s submitted to a page in this case it will be google which will look like this:
Continue reading “Trusting Java Applets”