Reversing a Chrome extension is REALLY easy; the .crx file is basically a .zip file containing the extension’s source code.
Almost all the files are related to the plugin’s screen shooting functionality, but we found something that got our attention; there are a few external URLs that are (badly) obfuscated.
I guess obfuscating external URLs is a way of making it harder for Google to find out about the malicious behaviour in the plugin stored in Google’s Chrome Web store.
Click to view the image in a larger format.
The file located at https://s3.amazonaws.com/ktnabv/settingsv14.j is another JS script and it sets some prerequisites before it runs another external JS file. The extension needs an installation date which is older than 7 days, and the parameter LocalStorage.isd can not be present.
The file https://s3.amazonaws.com/ktnabv/setStatsv14.js is the one that logs and sends data.
First it takes the information that will be sent:
- The complete URL.
- Title of tab.
- Country. Taken from the LocalStorage, where also the user IP address is stored. It wouldn’t surprise me if they would update the script to take part of that private information.
- Unique ID. Identifying the user.
And then it sends all these data in a POST parameter (a), but before it makes sure to obfuscate the information. I guess this encoding is to avoid the possibility for a normal-skilled user to see that the computer is leaking information.
The way the plugin encodes data is really weird and unconsidered. It first encodes the string two times in Base64, then it reverses the resulting string and add an ‘a’ at the beginning, just to make a manual analysis harder and an automated one completely useless. In fact, since it doesn’t follow any standard encoding procedure no static code analysis tool would discover it.
When trying to replicate this malicious behaviour, we first had to fake the ‘creation date’ and remove the isd value into the LocalStorage; and then manually run the main script (background.html) which will successively call the external JS scripts.
The LocalStorage is now populating with more data, all of them starting with the prefix dcm.
The next move is sniffing the traffic from our test machine directed to the ip address we identified as the web server receiving all these data, 188.8.131.52.
As expected, the traffic is sent to that web server and it contains the encoded data.
The response we are getting from the web server is a ‘Hello World’ followed by s1, which we discovered has to be the server number, in this case 1.
In order to decode the ‘a’ POST parameter we just need to reverse what the encoding has done. So reverse the text, remove the first character ‘a’, then decode the resulting base64 code twice.
Since these decoded data include URLs, we need to URL decode the resulting string and the final result will be data in json format.
As you can see, an example of leaked information includes data that can traced to a specific user, in this case [email protected]
Two cases we have seen includes:
- Mail subject and username if you are using a web-mail, such as Gmail.
- Internal ticketing systems which include a company’s name and case title.
Since this affect the web browser, possible scenarios are without limits.