Java Applet Attack

[Eri Pfaff]

TheJava Applet Attack considers as one of the most successful and popular methods for compromising a system.Popular because we can create the infected Java applet very easily,we can clone any site we want that will load the applet very fast and successful because it affects all the platforms.The only difficulty is how to deliver the Java Applet properly in order to trick our victims.

The Website that it will load the Java Applet in this tutorials is the pentestlab.wordpress.com but you can use any website you feel comfortable that can trick the users to run the Java Applet.

The next part is to decide which payload it will be used.There is a variety of available payloads that SET provides but here we have chosen to use a simple Windows Shell Reverse TCP as you can see it and from the image below:

After the selection of the payload it is necessary to decide which encoding would be used in the payload in order to bypass the antivirus protection of the target.There are 16 options here with a rate from SET so we have chosen the Backdoored Executable which is the best choice there.

Our next step now is to try to find a way to mask our IP address in order to have a domain that will look original.We can register a domain or we can use any of the online shorten URL services to hide our IP when we will send the link to our target.

For example we can spoof email addresses of the company that we are conducting the penetration test in order our mail to look legitimate.Most of the employees will think that it is an email that came from inside the company so we have many possibilities to open it and to allow the Java Applet to run without knowing that the applet is already infected with a malicious code.

The easy part is running the exploit. The hard part is getting the victim to put the correct URL address in the address bar and then clicking on the java message. I would say this would be very difficult to do unless your target is a very stupid person.

And, this is the problem with the SET exploits and sometimes also the Metasploit exploits. In tutorials it is made to look easy. But, easier shown in tutorials that actually done successfully in reality.

I agree with you Tom.It is much more difficult in a real word scenario than in safe lab environment thats why I have mentioned in this tutorial that the challenging part is to convince the victim to run the Applet.

However if you can implement it properly then you could trick some users during the engagement because you will no run SET against educated people but in people from finance or other departments that may not be aware about phishing and those kind of attacks.

I really like the Java programming language, but I continuously hear about how insecure it is. Googling 'java insecure' or 'java vulnerabilities' brings up multiple articles talking about why you should uninstall or disable Java to protect your computer. Java often releases a huge number of security patches at a time, and yet there are still tons of vulnerabilities left to patch.

I understand that there will always be bugs in software, but the amount of vulnerabilities Java has had does not seem normal (or am I imagining that?). What's even more confusing is that if there is a single architectural decision that is creating these vulnerabilities, why not change that design? There are tons of other programming languages that don't have this problem, so there must be a better way to do whatever Java is doing wrong. So why is Java still so insecure?

If you use Java like most other programming languages, e.g. to write standalone applications, it is no less secure than other languages and more secure than C or C++ because of no buffer overflows etc.

But Java is regularly used as a plugin inside the web browser, e.g. similar to Flash. Because in this case the user runs untrusted code without having explicitly installed it, the idea is to have the code run inside a limited sandbox, where it should not be able to somehow act against the system or the user (e.g. read local files and send them to the website, scan the local network etc). And this is where Java failed in the recent years, e.g. new bugs popped up sometimes on a daily basis which allowed escaping from the sandbox.

And as for the other languages being better: these usually can't even run as untrusted code inside a sandbox (exception is JavaScript and maybe Flash), so they would be even worse because there is no inherent way to limit their interaction with the system.

The security vulnerabilites reported are not about Java (the programming language), which, by virtue of the JVM enforcing memory safety, is actually more robust than languages such as C or C++, where buffer overflows and buffer over-reads remain a threat, and can result in messes like Heartbleed.

Instead, the vulnerabilites reported are in the Java Sandbox, which attempts to enforce a priviledge model that permits safe execution of untrusted code, and is most famously used to permit the automatic execution of Java Applets in a browser. That sandbox is riddled with holes. Also, Oracle releases patches (the "critical patch updates") only 4 times a year. Needless to say to browser vendors are not happy about this. Firefox, for instance, is requiring user authorisation to launch a Java Applet since Firefox 26.

The reason the press reports do not make that distinction is that Oracle uses the "Java" trademark both for the programming language, and the browser plugin that runs applets. In fact, if an ordinary user encounters the Java trademark, it probably refers to the latter.

It is somewhat speculative why exactly the Sandbox remains vulnerable. If you ask me, one reason is that the same API is used both with and without the Sandbox, and most Java code runs without the Sandbox (because the code is trusted). As a result, it is quite possible for a developer to forget about that obscure feature when changing the Java API or its implementation, accidentally exposing things that should be protected (to illustrate how easy that is, behold the lengthy Secure Coding Guidelines for Java SE). Another but related reason is the sheer size of the Java API (5800 classes, and nearly 50,000 methods, for Java SE 6).

Java technology is designed to operate in distributed environments, which means that security is of paramount importance. With security features designed into the language and run-time system, Java technology lets you construct applications that can't be invaded from outside. In the network environment, applications written in the Java programming language are secure from intrusion by unauthorized code attempting to get behind the scenes and create viruses or invade file systems.

If you don't include "be secure" in the specifications for your programming language, you'll rarely have to release security patches. If, on the other hand, that's one of your stated goals, you'll be hard pressed not to.

All array accesses are checked with regards to allocated array length. Buffer overflows are thus reliably trapped, and trigger an exception, which is better (this turns remote code execution vulnerabilities into mere denial-of-service).

Memory allocation is managed through a garbage collector, which prevents use-after-free and double-free errors. Also, the GC allows for an easier handling of character strings (strings are immutable in Java), which removes most occasions for buffer overflow bugs.

Strict typing is enforced; code cannot access data bytes for what they are not. This again prevents vulnerabilities (bugs where data types are transgressed will be reported at compilation or, at worst, as a runtime ClassCastException).

However, the Java designers tried to leverage this enhanced security to make something hard, i.e. applets. The problem is attack surface: since the applet is potentially hostile code, everything it does must be controlled. But the hostile code must be able to use the "standard Java classes" if it is to do anything, so "control points" must be enforced on every single standard Java class. The attack surface thus consists of hundreds of classes containing thousands of methods, and all of them must enforce adequate checks.

We can compare Java with Javascript here; for instance, Java allows access to files on disks, but this right must not be granted to applets, except if the applet asked for it and the user agrees (which entails the whole applet signing business). Javascript, less ambitious, simply lacks any file access method: access controls on a function cannot be implemented improperly if the function does not actually exist !

To sum up: Java is fine and secure. Java applets imply a huge attack surface whose security is very hard to ensure. For stand-alone applications and servers, though, using Java is a good idea if you want security (this equally applies to C#).

These days, finding more vulnerabilities may not imply how insecure the software is. The problem is how the security response team of each software vendor reacts to it and how quickly the patches are coming out.

As I remember, Oracle has a program called Critical Patch Updates (CPU) which gives lots of patches quarterly. They also release patches without CPU if there is a zero-day vulnerability out there. But the problem is the time taken by Oracle to release a patch.

Overrated fear .. Java itself is fine; the problems occur with old-school Java-Applets running within web browsers, but I doubt anyone actually creates Applets anymore - most development houses have used Flash or HTML4/5 for front-end web interfaces for at least the last 10 years.

Nowadays, 'insecure by default' is expected in a programming language. Java fails here miserably, and they never update it to fix the problems. In combination with poor documentation that does not tell the proper way to use security functionality, the language is filled with security booby traps.

What about Java. Can you delete all your files, completely wipe your hard drive using a Java applet (hosted on a web site)? The answer is yes, if you accept running the applet. Unlike any other web browser language.

3a8082e126