Java Applets are bytecodes that are delivered via the browser, and executed using the Java Virtual Machine (JVM) at the client-side. Java Applets can access the 3D hardware acceleration, which makes them suitable for graphic visualizations. These applets can be displayed within the browser using the HTML elements ‘applet’ and ‘object’. Java Applets can be compiled at server-side, and the ‘.class’ file hence generated can be stored on the server and invoked using an ‘object’ or ‘applet’ HTML tag. For example:
<applet id=”applet2″ name=”applet2″ code=”applet2.class” codebase=”./” height=”30″ width=”150″></applet>
Note: The use of ‘applet’ HTML element is deprecated.
About Net-Force Java Applets Challenges
In order to solve these challenges, you are required to locate the correct passwords that are revealed to you after exploiting weaknesses in Java Applet based authentication procedures. You can attempt the challenges in any order but you must be logged in to try potential passwords. While attempting these challenges, because these applets are being executed in the JVM at client-side, we will try to reverse engineer the relevant ‘.class’ files, read the source code germane to these Java Applets, and see if we can calculate needed credentials or find them hard-coded in the source. Throughout these challenges, we will make use of Java decompilers such as JAD and JD-GUI.
Please be advised that the following content provides solutions to the intriguing Java Applets challenges on Net-Force. It would be foolish to read further without having tried your absolute best at the challenges first.
Solutions to Java Applets Challenges 1 to 4
Java Applets Challenge 1, Level 201: “Sweet little applet…”
This first challenge asks us to login using the Java Applet shown in the browser. We can access the ‘class’ file pertaining to this Java Applet on the server once we have determined where it is located. We use ‘inspect element’ in Google Chrome to discover the location of this ‘class’ file [Figure 2].
We observe that the applet code is located in the file ‘applet1.class’. Hence, we use wget to download this ‘applet1.class’ file on our local machine from the following location [Figure 3]:
Next, we need to analyze the source code pertaining to this applet file. However, we cannot just view the contents in a simple text editor. We need to reverse engineer the ‘class’ file first in order to obtain legible source code that we can analyze for security weaknesses. For this purpose, we can use a decompiler like JAD or JD-GUI as mentioned before.
We use JAD to obtain the source code [Figure 4]:
Alternatively, you can use JD-GUI to read the source code [Figure 5].
We notice that the authentication logic is implemented in the form of an ‘if’ condition that checks to see if the password entered is equal to ‘applets’. If so, the variable ‘str2’ becomes ‘str3’ (which is the challenge page URL) plus “solution.php”. Hence, the URL that contains the correct password for this challenge is [Figure 6]:
Note: JAD is a command-line Java decompiler that comes pre-installed in Kali Linux. However, JD-GUI is a GUI decompiler that you would need to first download and install.
Java Applets Challenge 2, Level 202: “Decompile me…”
Again, we are asked to login using the given Java Applet. We use ‘inspect element’ in Chrome once again to locate the ‘class’ file pertaining to this applet. We download and reverse engineer this ‘class’ file in the same manner as in the previous challenge [Figure 7].
The highlighted part of this source code pertains to the logic that is useful in solving this challenge. After carefully reading this part of the source code, we know that the variables ‘str1’, ‘str2’, ‘str3’, and ‘str4’ are pivotal in determining whether the user is granted access or not. The ‘if’ condition compares the value entered by the user in the password field to the value stored in ‘str3’ (secr3t), and if they are equal, it concatenates str2 (the URL) and value of ‘str3’ (secr3t) and stores this in ‘str4’. However, in case these values are not equal, the code seems to redirect the user to ‘index.php’, the main challenge page, which is something we don’t want.
Ethical Hacking Training – Resources (InfoSec)
This logic indicates that we need to find the value stored in ‘str4’ when the user provides the right password (which is ‘secr3t’). Hence, we need to calculate the value of str4 according to this statement:
str4 = str2 + str3 + “.php”
Since this a small code, we can calculate the value stored in str4 manually. However, we use an online Java compiler to calculate this value, as that would be faster. We modify the code to remove the ‘if’ condition, hard code the challenge URL in ‘str2’, and print the calculated value of ‘str4’ [Figure 8].
After successful compilation, the output reveals the following URL stored in ‘str4’:
Now, since this where the challenge page redirects to when the user supplies the correct password, we follow this URL and obtain the password to the challenge [Figure 9].
Java Applets Challenge 3, Level 203: “Let me in!”
Keeping in tune with the previous challenges in this section, we are asked to log in using the Java Applet once again. We download and decompile the relevant Java Applet ‘class’ file as before and analyze the source code [Figure 10].
We notice the part of the code that sets a text message “Login Success, Loading..”, and we scrutinize the logic around it. However, we failed to comprehend the authentication procedure by simply looking at this part alone. This code for this challenge is larger than for the previous ones, and we noticed a noteworthy statement near the end of the code [Figure 11].
The file ‘pass.txt’ seems to contain the password. We took a stab at accessing the following location in hopes of discovering the password:
As expected, we were redirected to the main page, which means that this is not the URL we are looking for. We need to know the final value of ‘str2’ to discover the correct location of the password file. For this purpose, we need the value of ‘str1’ from the code. We scan the code looking for the value of ‘str1’ and locate it [Figure 12].
Hence, the value of ‘str2’ becomes ‘123pass.txt’ according to this statement:
str2 = str1 + this.infile;
Equipped with this value of ‘str2’, we access the following URL [Figure 13]:
The page presents us with the name of an HTML file that looks interesting (pass OK), and we access the following URL to locate the password [Figure 13]:
Java Applets Challenge 4, Level 204: “Simple encoding”
This challenge is quite distinctive and absorbing. As with other challenges, we need to login using the Java Applet and for that we need to download and decompile the related Java Applet ‘class’ file. The code reveals 2 interesting functions that we can analyze to discover potential password(s) for this applet (please note that in time we will learn that the authentication logic for this challenge will accept multiple passwords as long as they fulfill a certain condition). The first function is ‘actionPerformed’ [Figure 14], which seems to be providing potential passwords to the PHP file ‘index.php’ as the value of the variable ‘pass’ in the following manner:
We need to calculate the correct password to try here. Hence, we focus our attention towards the other function of interest, which is ‘hash’ [Figure 15]. This function is calculating the ASCII values of every character in the password, adding them together, and storing the result in the variable ‘i’.
After analyzing the logic in both of these functions collectively, we know that the “hash” value, ‘i’, of the correct password would be equal to the value of ‘c’. Hence, all strings where the sum of the ASCII value of the characters is equal to ‘448’ will be acceptable. For example, ‘pranshu’ cannot be the right password since the sum of the ASCII values of the characters will exceed 448. However, ‘pra}’ will be accepted because the total of the ASCII value pertaining to ‘p’, r’, ‘a’, and ‘}’ equals 448 [Table 1].
We can use this online ASCII table for the purpose of solving this challenge manually. We also wrote a Java code that is able to determine if a specified password will work for this challenge [Figure 16].
Now, since we know that ‘pra}’ will work as a password, we access the following URL and obtain the password for this challenge [Figure 17]:
As demonstrated by these challenges, client-side authentication using such Java Applets is highly deficient and should be avoided. Anything that the user can closely inspect, like these Java source codes, should contain as little information as possible about the authentication logic. Moreover, the practice of hard-coding plaintext passwords into applets and delivering them at client-side for verifications is certainly not good. These Java Applets challenges at Net-Force demonstrated several shortcomings in client-side authentication. We also noticed that in some challenges the logic calculated the redirect URL to the password page after a specific ‘if’ condition was satisfied. When security is so straightforward and easily decipherable (which it shouldn’t be), it is crucial to protect the authentication logic. Failing to do so, leads to unauthorized access as demonstrated by these challenges.
If you enjoyed these, consider attempting more captivating challenges at Net-Force to test or build your skills in security. If you have spent a substantial amount of time on a specific challenge – and the solution has evaded you for long – then you can always come here to seek solutions. The solutions above discuss only successful attempts for the sake of brevity.