Recently we blogged about Google Code hosting malware. Within a month we have observed a second instance where malicious .jar files are being hosted on Google Code. Using Google code to distribute malware seems to increasing in popularity, no doubt due not only to the free hosting provided, but also the positive reputation of the google.com domain. This indicates that there is presently inadequate validation performed by Google prior to content being uploaded to the Google Code site. In this case, a simple anti-virus scan would have found following pieces of malware.
Google Code URLs:
Both files 'update.jar' and 'Client.jar' have an MD5 of '0521c911e442cd9eec927d8439731a76' and a size of '3,626' bytes. VirusTotal Result:
ZULU Result: 100/100 score ZULU rules which are flagging .jar files as malicious.
The two projects are hosted on 'code.google.com' by the same uploader who has an email ID of '[email protected]'. The second project is also currently live (hosted at "hxxp://code.google.com/p/update-java-download/") and contains the same 'Client.jar' file. You will note that other links within the projects like 'Project Home, 'Wiki', 'Issues', etc. contain minimal information about the project, suggesting that malware hosting was the only goal.
Malicious piece of Java code in 'Client.jar' file:
This .jar file basically takes a URL as input and downloads a file from the given URL. The same type of .jar file was previously analyzed and mentioned in an earlier Zscaler blog.
The release date on the 'Download' link indicates Apr 26, 2013, but we have observed in the Zscaler logs, the same file being hosted on "hxxp://heckraiser.fileave.com/youtube/YouTube.jar" as far back as July 24, 2011.
In the past, we have seen sites like Dropbox, Google Code and other free hosting providers being leveraged to deliver malware. Free hosting providers, especially those with a positive reputation are becoming popular for attackers to serve malicious content. Enterprises and end users alike, should consider any third party content, regardless of location, to be untrusted until it has been appropriately scanned.