On detecting drive-by download attacks and new malware distribution vectors via Flash banners
Today we want to tell you about a new kind of drive-by download attack using Flash banners, and how to fight it. Such an attack allows attackers to spread viruses through the site without hacking it. Malicious software is distributed through Flash advertising banners, through which webmasters want to monetize their website. At the same time, they themselves may not suspect that the banner placed on a web page made their portal part of a virus distribution network.
Malicious code
The execution of malicious JavaScript code, for example, in the context of a web browser, is possible thanks to the call to the ExternalInterface class, which appeared in ActionScript 3.0. The process of executing JavaScript code in the context of web browsers that support the ability to work with ActiveX is implemented through the ActiveX component for Shockwave Flash. And for web browsers without this feature, a plug-in for Shockwave Flash is used. An ActiveX component or a plugin parses the bytecode of the Flash file transmitted to it and generates the JavaScript code that will be executed in the context of a web browser if such functionality is present in the Flash file. After the JavaScript code is generated, it is further processed for processing through JavaScript functions that are pre-built in the ActiveX component or a plug-in for Shockwave Flash. Figure 1 shows a list of such functions.
')
Fig.1 - JavaScript functions that use the generation and further execution of the code passed to ExcternalInterface.call ()
Below is the harmless JavaScript code of the test Flash banner generated for execution in the context of a web browser by an ActiveX component or a plug-in for Shockwave Flash.
Look at Yandex. Photos
Fig.2 - JavaScript code transmitted to ExcternalInterface.call () of a test Flash banner, which is formed by an ActiveX component or a plug-in for Shockwave Flash
Look at Yandex. Photos
Fig.3 - The result of executing ExcternalInterface.call () from the test Flash banner
Figure 3 shows the FireBug plugin window for the Firefox browser with the result of displaying a test Flash banner and invoking prepared JavaScript code that does not perform malicious actions. Thus, using the call () method belonging to the ExternalInterface class, you can call any function in the JavaScript language. This allows attackers to perform malicious actions.
Look at Yandex. Photos
Fig. 4 — Calling the ExternalInterface.call () from a Flash banner to use an external JavaScript script on the HTML page
Look at Yandex. Photos
Fig.5 - Calling ExcternalInterface.call () from a Flash banner to steal session data using JavaScript
There are a number of limitations for successful execution of JavaScript code from a Flash banner, which are applicable to the Flash runtime environment and are described on the official manual page for the fscommand () function from the flash.system package and applicable to ExcternalInterface.call (). Such restrictions apply depending on external parameters. Namely, if the property allowScriptAccess is set to:
• sameDomain (default) - scripts are allowed only for SWF files located in the same domain as the web page;
• always - SWF can access the HTML page in which it is embedded, even if it is located on a different domain;
• never — The SWF file cannot access any HTML pages.
The system for detecting malicious content on web pages, developed by Yandex, first discovered the use of this method of executing malicious JavaScript code in December 2010.
On 04.24.2012, this file was detected by only one of 42 antiviruses presented on the VirusTotal service. Namely, Sophos Antivirus with the verdict Troj / SWFDlr-AB .
Malicious SWF file hash sums:
• MD5: fd588c260cf38be7a7259c195da5b023
• SHA-1: 9db53d82392c85451e99cb7736ba7b30498e1624
• SHA-256: e15758a2f0ec5b6cb3203ee42d0454ffc7830a2026bcc3eebfdfa9bd0017c965
Figure 6 - Malicious Flash banner detected as Troj / SWFDlr-AB by Sophos classification
This malicious SWF file contains in its body an ActionScript code, which is shown in the figure below.
Look at Yandex. Photos
Fig.7 - Malicious code passed to the ExcternalInterface.call () method in the Troj / SWFDlr-AB Flash banner
As can be seen from this figure, the value of the User-Agent field transmitted in the HTTP header is checked. If the browser does not belong to the Chromium family, and this Flash application is accessed from the desired address, specified as in the code snippet in the figure, an invisible element is created on the page that loads the malicious JavaScript code at hxxp: // 66.199.232.59/workarounds.js. At the time of the spread of the malicious code, the script from the workarounds.js file contained the counts () function. After execution, this function created a hidden element DIV on the page, and inside it - a hidden IFRAME. The SRC attribute of the latter contained the address hxxp: //nnuled.co.cc/in.cgi? 3 - for switching to TDS Sutra.
Look at Yandex. Photos
Fig.8 - Part of the malicious code of the counts () function from the workarounds.js file
Then from the address hxxp: //nnuled.co.cc/in.cgi? 3 there was a transition to the BlackHole Exploit Pack, located at hxxp: //ds3c.co.cc/index.php? Tp = 50afe4b907e38c82. Malware has already spread from there.
Since the first detection of this family of malicious Flash banners, attackers have begun to complicate the ability to detect malicious calls and malicious code. This is evidenced by a malicious Flash banner, the distribution of which was recorded by us in the middle of April 2012. At that time, the detected file was not considered as malicious by any of the antiviruses presented on the VirusTotal service.
Malicious SWF file hash sums:
• MD5: 6daa91ce91eee37be0d89e351a7e3a3e
• SHA-1: bccc85031396e9c14911ed1c5e6829087eeb9893
• SHA-256: 92395014ac2a8a9e35eaf17f6e73b4fdd643538afbff0bf50afb80f0c6dfccfb
Fig.9 - Malicious Flash banner, fixed in mid-April 2012
In appearance, this is a regular Flash advertising banner, but there is another SWF file in the contents of this SWF file.
Fig.10 - Flash banner containing inside another SWF file
This SWF file is loaded from a binary array using ActionScript code, as shown in Figure 11.
Look at Yandex. Photos
Fig.11 - Loading a SWF file from a binary array
The hidden ActionScript is heavily obfuscated. To make code analysis difficult, garbage instructions, spurious traces and reserved words (if, for, do, each, etc.) are used as names of methods and variables, as well as checking where the Flash banner was accessed from and whether currently application under debugging. After de-obfuscation, large integer two-dimensional arrays inside ActionScript code are converted to strings:
• superfoo
• file: //
• StandAlone
• sendtoas
• en
• ru
• Rambler
• Mail.Ru
• YB
• Yx
• Ya
• Begun
• Google
• Bot
• bot
• GTB
• vkontakte
• mail.ru
• bing
• yahoo
• google
• yandex
• rambler
• Windows
• MSIE
• Explorer
• Firefox
• Opera
Malicious code checks the value of the User-Agent field passed in the HTTP header. If it does not coincide with one of the popular browsers listed above or contains substrings indicating that the site visitor is a search robot, the malicious code stops its work. The value of the Referer field transmitted in the HTTP header is also checked for a transition from the search results page or major portals. If all the conditions described above are met, then the JavaScript code is loaded, which is stored inside the malicious banner in an obfuscated form. Below is a part of deobfuscated malicious JavaScript code that represents the main function of its execution. To make the malicious code more difficult to detect, after the execution of the main JavaScript code, the code that removes traces of malicious activity is executed.
Fig.12 - JavaScript code that removes traces of malicious activity
Look at Yandex. Photos
Figure 13 - Deobfuscated malicious JavaScript code from a SWF file
The malicious code creates an invisible container on the web page that loads the malicious script from the <SUB> yadro-yadro.com resource, where <SUB> is a random integer. From there, it redirects to a malicious host in the .cx domain zone on which Nuclear Exploit Pack was located at the time of the propagation of the malicious code.
The spread of malicious code in this way is recorded quite rarely by the Yandex behavioral analyzer , 1-2 times per quarter. But since, at the same time, malicious Flash banners are downloaded mainly from pages of well-known portals that are visited daily by a large number of users, the number of infected computers is quite significant.
Probably those who invented this method kept it secret to complicate the struggle with it. The active distribution of malicious code from an infected resource using this method lasts on average no more than 2 days, but this is more than enough to gather all the necessary information about it.
In particular, CMS integrated with OpenX Ad Server is most often used to distribute malicious code. OpenX Ad Server is a popular system for managing ads on your site, the number of times it shows with the price per click, etc. The attackers choose exactly the sites that use it, because in it, for the Flash object created, the parameter allowScriptAccess is set to the value "always". After a site that uses OpenX Ad Server advertising banners to rotate is found (which is not difficult - this system is very popular), the attackers need only agree on the placement of a malicious Flash object on it.
Look at Yandex. Photos
Fig.14 - JavaScript code for creating a new Flash object in OpenX Ad Server
Conclusion
Probably, after some time, such malicious Flash applications will become reliably detected by ordinary antiviruses, and the vulnerabilities that they use will be closed. But until then, to ensure the safety of users of your site and stable traffic to it (infection significantly reduces attendance), we recommend that you:
• To prevent execution of JavaScript code from Flash applications, set the parameter allowScriptAccess to “never”. You can also set the parameter allowNetworking to “none” or “internal” to restrict calls to navigateToURL (), fscommand (), ExternalInterface.call (). Unfortunately, this is due to the need to reduce the functionality of Flash applications.
• So that the navigateToURL () method required for advertising applications could work, and the dangerous ExternalInterface.call () could not, place Flash banners on a separate domain or subdomain, then set the allowScriptAccess parameter to “sameDomain” and the allowNetworking parameter to “all” .
• If the Flash application needs maximum permissions to work, get its source code, carefully check and compile it yourself. If you check, you find the methods navigateToURL (), fscommand (), ExternalInterface.call (), and also ExternalInterface.addCallback (), obfuscated code and large data arrays - this is a reason to ask for clarification from those who suggested that you place this application on your site.
• You can use HTML5 as an alternative technology for animated interactive ad units.
For more information on the limitations that can be used, we recommend that you familiarize yourself on the Adobe security page , as well as on the “ Restricted Network Connection API ” page.
If you suspect that your site is infected or you don’t want to allow it to become infected, you can use the site security recommendations . You can learn how to protect your site from spreading malware from it from the text of the report of the Yandex Safe Search Team at RIT 2012 .
In addition, we regularly publish research and analytics on the Yandex Safe Search blog , stay tuned.
Yandex Safe Search Team
Malicious code
The execution of malicious JavaScript code, for example, in the context of a web browser, is possible thanks to the call to the ExternalInterface class, which appeared in ActionScript 3.0. The process of executing JavaScript code in the context of web browsers that support the ability to work with ActiveX is implemented through the ActiveX component for Shockwave Flash. And for web browsers without this feature, a plug-in for Shockwave Flash is used. An ActiveX component or a plugin parses the bytecode of the Flash file transmitted to it and generates the JavaScript code that will be executed in the context of a web browser if such functionality is present in the Flash file. After the JavaScript code is generated, it is further processed for processing through JavaScript functions that are pre-built in the ActiveX component or a plug-in for Shockwave Flash. Figure 1 shows a list of such functions.
')
Fig.1 - JavaScript functions that use the generation and further execution of the code passed to ExcternalInterface.call ()
Below is the harmless JavaScript code of the test Flash banner generated for execution in the context of a web browser by an ActiveX component or a plug-in for Shockwave Flash.
Look at Yandex. Photos
Fig.2 - JavaScript code transmitted to ExcternalInterface.call () of a test Flash banner, which is formed by an ActiveX component or a plug-in for Shockwave Flash
Look at Yandex. Photos
Fig.3 - The result of executing ExcternalInterface.call () from the test Flash banner
Figure 3 shows the FireBug plugin window for the Firefox browser with the result of displaying a test Flash banner and invoking prepared JavaScript code that does not perform malicious actions. Thus, using the call () method belonging to the ExternalInterface class, you can call any function in the JavaScript language. This allows attackers to perform malicious actions.
Look at Yandex. Photos
Fig. 4 — Calling the ExternalInterface.call () from a Flash banner to use an external JavaScript script on the HTML page
Look at Yandex. Photos
Fig.5 - Calling ExcternalInterface.call () from a Flash banner to steal session data using JavaScript
There are a number of limitations for successful execution of JavaScript code from a Flash banner, which are applicable to the Flash runtime environment and are described on the official manual page for the fscommand () function from the flash.system package and applicable to ExcternalInterface.call (). Such restrictions apply depending on external parameters. Namely, if the property allowScriptAccess is set to:
• sameDomain (default) - scripts are allowed only for SWF files located in the same domain as the web page;
• always - SWF can access the HTML page in which it is embedded, even if it is located on a different domain;
• never — The SWF file cannot access any HTML pages.
The system for detecting malicious content on web pages, developed by Yandex, first discovered the use of this method of executing malicious JavaScript code in December 2010.
On 04.24.2012, this file was detected by only one of 42 antiviruses presented on the VirusTotal service. Namely, Sophos Antivirus with the verdict Troj / SWFDlr-AB .
Malicious SWF file hash sums:
• MD5: fd588c260cf38be7a7259c195da5b023
• SHA-1: 9db53d82392c85451e99cb7736ba7b30498e1624
• SHA-256: e15758a2f0ec5b6cb3203ee42d0454ffc7830a2026bcc3eebfdfa9bd0017c965
Figure 6 - Malicious Flash banner detected as Troj / SWFDlr-AB by Sophos classification
This malicious SWF file contains in its body an ActionScript code, which is shown in the figure below.
Look at Yandex. Photos
Fig.7 - Malicious code passed to the ExcternalInterface.call () method in the Troj / SWFDlr-AB Flash banner
As can be seen from this figure, the value of the User-Agent field transmitted in the HTTP header is checked. If the browser does not belong to the Chromium family, and this Flash application is accessed from the desired address, specified as in the code snippet in the figure, an invisible element is created on the page that loads the malicious JavaScript code at hxxp: // 66.199.232.59/workarounds.js. At the time of the spread of the malicious code, the script from the workarounds.js file contained the counts () function. After execution, this function created a hidden element DIV on the page, and inside it - a hidden IFRAME. The SRC attribute of the latter contained the address hxxp: //nnuled.co.cc/in.cgi? 3 - for switching to TDS Sutra.
Look at Yandex. Photos
Fig.8 - Part of the malicious code of the counts () function from the workarounds.js file
Then from the address hxxp: //nnuled.co.cc/in.cgi? 3 there was a transition to the BlackHole Exploit Pack, located at hxxp: //ds3c.co.cc/index.php? Tp = 50afe4b907e38c82. Malware has already spread from there.
Since the first detection of this family of malicious Flash banners, attackers have begun to complicate the ability to detect malicious calls and malicious code. This is evidenced by a malicious Flash banner, the distribution of which was recorded by us in the middle of April 2012. At that time, the detected file was not considered as malicious by any of the antiviruses presented on the VirusTotal service.
Malicious SWF file hash sums:
• MD5: 6daa91ce91eee37be0d89e351a7e3a3e
• SHA-1: bccc85031396e9c14911ed1c5e6829087eeb9893
• SHA-256: 92395014ac2a8a9e35eaf17f6e73b4fdd643538afbff0bf50afb80f0c6dfccfb
Fig.9 - Malicious Flash banner, fixed in mid-April 2012
In appearance, this is a regular Flash advertising banner, but there is another SWF file in the contents of this SWF file.
Fig.10 - Flash banner containing inside another SWF file
This SWF file is loaded from a binary array using ActionScript code, as shown in Figure 11.
Look at Yandex. Photos
Fig.11 - Loading a SWF file from a binary array
The hidden ActionScript is heavily obfuscated. To make code analysis difficult, garbage instructions, spurious traces and reserved words (if, for, do, each, etc.) are used as names of methods and variables, as well as checking where the Flash banner was accessed from and whether currently application under debugging. After de-obfuscation, large integer two-dimensional arrays inside ActionScript code are converted to strings:
• superfoo
• file: //
• StandAlone
• sendtoas
• en
• ru
• Rambler
• Mail.Ru
• YB
• Yx
• Ya
• Begun
• Google
• Bot
• bot
• GTB
• vkontakte
• mail.ru
• bing
• yahoo
• google
• yandex
• rambler
• Windows
• MSIE
• Explorer
• Firefox
• Opera
Malicious code checks the value of the User-Agent field passed in the HTTP header. If it does not coincide with one of the popular browsers listed above or contains substrings indicating that the site visitor is a search robot, the malicious code stops its work. The value of the Referer field transmitted in the HTTP header is also checked for a transition from the search results page or major portals. If all the conditions described above are met, then the JavaScript code is loaded, which is stored inside the malicious banner in an obfuscated form. Below is a part of deobfuscated malicious JavaScript code that represents the main function of its execution. To make the malicious code more difficult to detect, after the execution of the main JavaScript code, the code that removes traces of malicious activity is executed.
Fig.12 - JavaScript code that removes traces of malicious activity
Look at Yandex. Photos
Figure 13 - Deobfuscated malicious JavaScript code from a SWF file
The malicious code creates an invisible container on the web page that loads the malicious script from the <SUB> yadro-yadro.com resource, where <SUB> is a random integer. From there, it redirects to a malicious host in the .cx domain zone on which Nuclear Exploit Pack was located at the time of the propagation of the malicious code.
The spread of malicious code in this way is recorded quite rarely by the Yandex behavioral analyzer , 1-2 times per quarter. But since, at the same time, malicious Flash banners are downloaded mainly from pages of well-known portals that are visited daily by a large number of users, the number of infected computers is quite significant.
Probably those who invented this method kept it secret to complicate the struggle with it. The active distribution of malicious code from an infected resource using this method lasts on average no more than 2 days, but this is more than enough to gather all the necessary information about it.
In particular, CMS integrated with OpenX Ad Server is most often used to distribute malicious code. OpenX Ad Server is a popular system for managing ads on your site, the number of times it shows with the price per click, etc. The attackers choose exactly the sites that use it, because in it, for the Flash object created, the parameter allowScriptAccess is set to the value "always". After a site that uses OpenX Ad Server advertising banners to rotate is found (which is not difficult - this system is very popular), the attackers need only agree on the placement of a malicious Flash object on it.
Look at Yandex. Photos
Fig.14 - JavaScript code for creating a new Flash object in OpenX Ad Server
Conclusion
Probably, after some time, such malicious Flash applications will become reliably detected by ordinary antiviruses, and the vulnerabilities that they use will be closed. But until then, to ensure the safety of users of your site and stable traffic to it (infection significantly reduces attendance), we recommend that you:
• To prevent execution of JavaScript code from Flash applications, set the parameter allowScriptAccess to “never”. You can also set the parameter allowNetworking to “none” or “internal” to restrict calls to navigateToURL (), fscommand (), ExternalInterface.call (). Unfortunately, this is due to the need to reduce the functionality of Flash applications.
• So that the navigateToURL () method required for advertising applications could work, and the dangerous ExternalInterface.call () could not, place Flash banners on a separate domain or subdomain, then set the allowScriptAccess parameter to “sameDomain” and the allowNetworking parameter to “all” .
• If the Flash application needs maximum permissions to work, get its source code, carefully check and compile it yourself. If you check, you find the methods navigateToURL (), fscommand (), ExternalInterface.call (), and also ExternalInterface.addCallback (), obfuscated code and large data arrays - this is a reason to ask for clarification from those who suggested that you place this application on your site.
• You can use HTML5 as an alternative technology for animated interactive ad units.
For more information on the limitations that can be used, we recommend that you familiarize yourself on the Adobe security page , as well as on the “ Restricted Network Connection API ” page.
If you suspect that your site is infected or you don’t want to allow it to become infected, you can use the site security recommendations . You can learn how to protect your site from spreading malware from it from the text of the report of the Yandex Safe Search Team at RIT 2012 .
In addition, we regularly publish research and analytics on the Yandex Safe Search blog , stay tuned.
Yandex Safe Search Team
Source: https://habr.com/ru/post/143345/
All Articles