ImageGate: Check Point uncovers a new method for distributing malware through images
Check Point researchers identified a new attack vector, named ImageGate, which embeds malware in image and graphic files. Furthermore, the researchers have discovered the hackers’ method of executing the malicious code within these images through social media applications such as Facebook and LinkedIn.
According to the research, the attackers have built a new capability to embed malicious code into an image file and successfully upload it to the social media website. The attackers exploit a misconfiguration on the social media infrastructure to deliberately force their victims to download the image file. This results in infection of the users’ device as soon as the end-user clicks on the downloaded file.
In the past week, the entire security industry is closely following the massive spread of the Locky ransomware via social media, particularly in its Facebook-based campaign. Check Point researchers strongly believe the new ImageGate technique reveals how this campaign was made possible, a question which has been unanswered until now.
The Check Point researchers uncovered the attack vector which affects major websites and social networks worldwide, including Facebook and LinkedIn. Check Point updated Facebook & LinkedIn of the attack vector early in September.
Watch the demo: https://youtu.be/sGlrLFo43pY
In the case of the Locky ransomware, once users download and open the malicious file they receive – all the files on their personal device are automatically encrypted and they can only gain access to them after the ransom is paid. The industry estimation is that the campaign is still raging and accumulates new victims every day.
As more people spend time on social networking sites, hackers have turned their focus to find a way in to these platforms. Cyber criminals understand these sites are usually ‘white listed’, and for this reason, they are continually searching for new techniques to use social media as hosts for their malicious activities. To protect users against the most advanced threats, Check Point strives to identify where attackers will strike next.
How to stay protected:
Check Point recommends the following preventive measures:
- If you have clicked on an image and your browser starts downloading a file, do not open it. Any social media website should display the picture without downloading any file.
- Don’t open any image file with unusual extension (such as SVG, JS or HTA).
UPDATE: DECEMBER 20
The Facebook Proof of Concept #1
Facebook is one of the most prominent websites proven vulnerable to the ImageGate attack vector. The attack on Facebook consists several stages, in which its security measures are circumvented.
To begin the attack, the attacker crafts a payload that will eventually be downloaded by force to the victim’s computer, and will execute a real malware or malicious code.
First, the attacker embeds the malicious content inside the image using HEX editor (or any other editor) according to the image structure.
This is the result:
The image with the payload is uploaded and downloaded to see if the payload was corrupted by the upload to the Facebook servers.
However, this tactic is not so simple, as Facebook ripped the payload out of the image.
This obstacle can be overcome by using graph photo upload API and a custom made fuzzer. The fuzzer’s main logic is the following:
- Change the image baseline and inject the payload somewhere in the file.
- Upload that image to Facebook.
- Get the image after Facebook rip out the payload and reconstruct it.
- Check for the payload exists in the image.
- Stop if worked.
- Move the payload X bytes.
- Manually adjust the payload locations (according to the output and behavior of the system)
Code snippet from the fuzzer main part:
Note that graph API return smaller image than the original one, hence the image will not contain the full image data with the payload. We managed to find that if we remove the s720x720 from the URL, it is possible to access the original image that contains the full image data with our payload.
By doing this, the attacker can upload his payload inside the image to Facebook servers.
Once this obstacle is removed, the attacker will need to go further to ensure his success. To do that, the attacker uploads the malicious file in the form of an image with resolution higher than 962X541. This is necessary since it does not entail adding a token to the file’s link. If a token is added, the attack will fail. Once the image is uploaded, the attacker will copy the file’s link, which would look something like this: http://scontent-lhr3-1.xx.fbcdn.net/t31.0-8/14086313_295633347470226_3946240742478472027_o.jpg.
The next step is altering the content type, from a mere .jpg to an octet-steam. The attacker can change the content type simply by adding a dot at the end of the URL as shown below:
The attacker adds a dl=1 parameter, which causes Facebook to download the image instead of presenting it.
To understand what happens when the dl=1 is added, we offer this detailed analysis:
As can be seen in the image above, the Facebook server added a Content-DispositionL attachment header, but did not specify a filename. The attacker can manipulate the Chrome CoreWebkit component to change the file name. In the Chrome CoreWebkit component, the function PopulateURLResponse will be called when it receives the data from the server:
This function will manage all the response components which contain the filename.
In this function the following lines call GetSuggestedFileName
If the function at headers->EnumerateHeader does not find the filename in the “content-disposition” the &value will be cleared hence the value will be taken from the URL as seen in the following functions.
That function will call the function GetFileNameFromURL because content_disposition.empty() will be True as seen in the image below:
The function GetFileNameFromURL calls the function ExtractFileName if the URL is valid and not “about://” or “data://”.
Which calls DoExtractFileName
Next, the code reaches to the function DoExtractFileName which extracts the filename from the path which is between that last slash and the following semicolon.
Using this information, the attacker can manipulate the URL and change the filename at client side if he adds /filename.extension ; to the URL.
By doing this, the attacker can present the malicious image as an attractive file like facebook_password.exe for example:
At this stage, the file won’t run, because the file header is not a PE header. However, the attacker can change the header to a format that can either be an image or an executable, such as the (.hta) format. This way, the application that executes it determines its capabilities.
Once all these steps are completed, all the attacker needs to do is to send the image to someone via Facebook.
And the payload will be executed on his device.
The Facebook Proof of Concept #2
This time, the attack is based on the Facebook messenger. The attacker will act on the following steps:
The attacker Attach an image to the messenger:
Then the attacker modifies the request content type which will change the data to octet-stream as shown before. This time we need to use an image content-type: image/svg+xml
The attacker used svg+xml content-type In order to make Facebook present the attachment as image file and change the content type to octet-stream otherwise the browser will save the file as image.
When the victim clicks the image, the file will be downloaded. Once the victim opens the file it will be executed according to the file extension, which is HTA in our demo.
Clicking on the file will launch the attack and the attacker will be able to fully control the victim’s machine!
Reproduce Steps in LinkedIn
LinkedIn is also vulnerable to the ImageGate attack vector, with a slight variation.
To execute the same attack, vector the attacker needs to change his profile image to the malicious image that contains the payload.
Get the URL from the proxy, and cancel the operation, this way the image will not be shown in his profile but will exist on LinkedIn CDN servers.
The link will look like this:
This time the attacker will take a different approach, and create a link to this URL using Anchor Tag:
<p>LinkedIn POC<br>
<a href=”http://media.licdn.com/media/AAEAAQAAAAAAAAiEAAAAJDk5YzJjMzAzLTU2ZjEtNDk2OC1iNzQ5LWZjYzcXXXXXXXXXXX.jpg” download=”linkedin_password.hta”>Download this image1</a>
</p>
Using new HTML5 download parameter and filename it is possible to change the filename on the client side, but this works only under the same origin policy. This means the Anchor Tag needs to be on the same domain with the downloaded file to work.
The question arises: how Anchor Tag will select the filename?
To understand we need to go back to the core Webkit source code and see how the filename is selected:
If there is a downloadAttr in Anchor Tag the suggestedName will be the name from the download parameter, only if the request is made from isSameOrigin otherwise it’s not possible to change it on the client side.
However, as seen before, the file name can be controlled via /filename.extension; the attacker can add that to the Anchor Tag.
<a href=”http://media.licdn.com/media/AAEAAQAAAAAAAAiEAAAAJDk5YzJjMzAzLTU2ZjEtNDk2OC1iNzQ5LWZjYzcXXXXXXXXXXX.jpg/linkedin_password.hta;aaaa” download=”will_not_be_selected_as_file_name.jpg“> press here
</a>
And the filename indeed changes! It is possible to use the same technique to control the filename on the client side even if it does not comply with the same origin policy as mention in the WebKit source code.
If the victim downloads and opens the file, the payload will be executed.
You may also like
AI’s Impact in 2024 Elections and What Voters Can Do to Protect Themselves from Disinformation
Ransomware’s Evolving Threat: The Rise of RansomHub, Decline of Lockbit, and the New Era of Data Extortion
A Closer Look at Q3 2024: 75% Surge in Cyber Attacks Worldwide
