Thanks to Kafeine for sharing the sample.
NOTE: Information is based on a sample captured on 2013-08-16. This sample is compared to the ones captured earlier this year - May 2013. All Sakura EK blog posts can be found here.
URL pattern is still quite short, but the file extensions for JAR file and Initial Payload requests have changed.
JAR file is requested through an HTTP GET for a file with '.b' extension and in case of the Initial Payload it's '.a'.
PluginDetect script 0.8.2 is now being used.
Code block for selecting what JAR file to request has been changed slightly. The execution flow logic is now simpler and a potential victim won't be getting 'Page not found' message in case if Java version running on his/her machine does not satisfy the exploit criteria.
The <applet> code for requesting the JAR file is still padded with a random characters pattern - in this case it's 'MGio@#as'. The file selection logic:
- If detected Java version is between '1.7.10' and '1.7.17' inclusive then the JAR file will be requested through a specially crafted JNLP file that allows to bypass Java Security Warning Window. The JNLP file is stored 'base64' encoded.
- If detected Java version is lower than '1.7.10' then the JAR file will be requested through a standard <applet>. No encoding applied.
- If detected Java version is '1.7.18' and higher then no exploit will be attempted.
There are now two boolean variables that track the system architecture type and Java version.
Both variables are used within 'CVE-2013-2471' exploit code when setting up different parameters.
'_is7u17' value is set with the following Java version check code:
Exploit code will be attempted 5 times before giving up.
The Initial Payload URL is still stored on the landing page using the same encoding technique it 'borrowed' from RedKit EK, but the Initial Payload is no longer encrypted with AES - it now uses XOR. The XOR key is stored in one of the variables within Java code.
The Initial Payload will be stored in Java Temp folder with a randomly generated filename using just lower case letters(6 in total).
Coincidental or not but this code looks exactly like the one here with only 1 line difference. It's not like the first time Sakura EK author 'borrows' someone else code, but I just personally find it entertaining to some extend. Maybe it's just me expecting some creativity when it comes to writing a malicious code. On the other hand it shows that any kiddo with some basic knowledge of Java can come up with the likes of this 'copy/paste' job - I wonder now how bad the server side code looks like.