Are unsecured digital ads creating a potential national security risk?

It is Monday morning, and special agent Ivan Ivanovich has a new assignment from his boss at the Foreign Intelligence Service headquarters in Moscow, Russia. Ivanovich has been tasked with hacking a number of high-value American targets, including Congressional staffers, intelligence operatives, and military commanders. Ivanovich groans, knowing that this new assignment will probably involve months of careful research and exploit development.

Suddenly, a stroke of inspiration flashes before his eyes. Ivanovich remembers chatting with a deep cover SVR agent who just returned from Washington. His colleague mentioned that important American officials love to read Politico, Defense News, and Roll Call. 

Ivanovich quickly creates a digital advertising account. He photoshops an ad for discounted baseball league tickets, inserts some obfuscated malware, and links it to a website hosting additional exploits. Once the ad creative is ready, he uploads it to his advertising account and restricts the geolocation targeting to a list of zip codes around the US Capitol, NSA headquarters, and various US military bases. He then configures an inclusion list of publisher domains for his ads to run on.

He sits back and relaxes - within a few days, Ivan should have at least a few dozen high-ranking American’s devices under his control.

How might this be possible?

Over the last decade, there have been many instances of malicious actors embedding code within ads that install malware, scrape content, forcibly redirect browsers, or exfiltrate sensitive user information. In 2014, the Interactive Advertising Bureau (IAB), a trade group for digital advertising companies, released a standard known as the Safeframe specification. Safeframes were developed to help give publishers more control when serving ads and to protect consumers. 

Despite the purported benefits of SafeFrames, few publishers are adopting the Safeframe standard on their websites. By analyzing the landing pages of the 10,000 most popular websites in the Tranco domain list, this analysis observed that fewer than 30% of publishers are enforcing SafeFrame standards (or any form of sandboxing) for the ads loading on their webpages.

Through some manual investigation, this analysis also found that it is theoretically possible to use ad tech platforms to target ads to the devices of certain high-value individuals such as military personnel, intelligence agency employees, and government officials. This corroborates previous reports that ad tech platforms can be used to target US military personnel and that ad tech systems are already being used by foreign intelligence operatives.

The lack of SafeFrame utilization and the possibility of targeting ads to high value individuals may constitute a national security threat. For all of the above reasons, widespread adoption of SafeFrames should be further examined by news publishers, cybersecurity professionals, and policy makers.

Background

Previous national security advisories on ad tech

In July of 2018, the US National Security Agency (NSA) published a four page advisory, warning that, “Cyber adversaries can leverage malicious advertising ("malvertising") to install Malware by taking advantage of unpatched vulnerabilities.” The NSA suggested the use of certain ad blockers to protect against malvertising.

In January of 2021, the US Cybersecurity and Infrastructure Security Agency (CISA), issued a similar guide to both federal agencies and non-government organizations, warning that malvertising “is a significant vector for exploitation. It bypasses built-in browser protections against pop-ups and forced redirects and inserts malicious ads into legitimate ad networks.”

More concerningly, CISA warns that foreign hackers “can use carefully crafted and tailored malicious ads as part of a targeted campaign against a specific victim, not just as broad-spectrum attacks.”

Senator Ron Wyden cited a report that Russian operatives may have used “seemingly innocuous ads to target a state election agency.” Sen. Wyden also alluded to reports that foreign agents are targeting the personal devices of Senators and Congressional staffers through various means.

How common is malvertising?

Malicious ads have been known to hit many prominent websites and affect millions of users on different types of device-browser. In 2018, the CEO of ad security company Confiant said malware accounts for 0.5% of all ads served, though this number can spike five fold at times. 

In 2020, The Media Trust detected more than 20,000 distinct malvertising attacks and blocked billions of bad ads. These attacks affected dozens of publishers and may have infected millions of consumer devices.

Vox Media previously detected a series of forced mobile redirect ads loading on their site that year, which attempted to scam users with an alert that they won an Amazon gift card.

Malicious popup ad for a free Amazon gift card scam

Example of a malicious ad that loaded on a Vox Media website in 2018.

In March 2016, the New York Times, BBC, Newsweek, AOL, MSN, and The Hill had their ad networks hijacked again by criminals using the Angler Exploit Kit to deliver TeslaCrypt ransomware.

In 2013, researcher Conrad Longmore found two popular porn sites - XHamster and Pornhub -  served large numbers of malicious ads which could install harmful files on users’ machines without their permissions. Longmore found that 5% of XHamster pages loaded malicious ads in a 90 days period. Pornhub had harmful ads load on 12.7% of its web pages.

Tweet from 2009 warning about a malicious ad on the nytimes.com website

2009 tweet warning about malicious ads loading on the nytimes.com website

Reducing malvertising: sandboxing and safeframes

The simplest approach to reduce malvertising may be to remove third party ad networks completely from publisher websites. This is not tenable for most publishers, as they depend on ad revenues to support their journalistic endeavors and lack the technical resources to build their own digital advertising solutions.

Another approach is to follow various best-practices and existing technologies to reduce the potential attack surface available to hackers.

Digital ads load inside of iframes, which allow developers to embed HTML code from one website inside of another website (such as Twitter widgets, Youtube videos, Google map boxes). Iframes can be labeled with a sandbox attribute, which can impede ads or other content from misbehaving on a webpage. The WebKit website has an interactive demo that showcases how adding the sandbox attribute restricts certain types of functionalities. The sandbox attribute can be especially important because many ad iframes load as same-origin as the top level window page, which can bypass browser’s cross-origin restrictions.

Fully sandboxing an ad iframe can impede ads from performing some of their basic functionalities, so the IAB developed the SafeFrame standard. SafeFrames include some sandboxing protections while still enabling certain functionalities needed by ads for sizing, viewability, measurement, and other functions.

Screenshot of Chrome Developer Tools, showing an ad iframe that has the sandbox attribute

Screenshot of an ad iframe loading on snopes.com. This ad iframe uses the sandbox attribute, which reduces the number of exploits a potential malicious ad could theoretically perform.

Screenshot of Chrome Developer Tools, showing an ad iframe that has the sandbox attributeScreenshot of an ad iframe loading inside of a SafeFrame.

As SafeFrames (or sandboxed) iframes can reduce the potential attack surface for malvertising attacks, this analysis was interested in quantifying how widespread the adoption of this security standard is amongst major news websites. 

Results

More than 70% of top publisher websites do not sandbox iframes

By checking the top 10,000 most frequently visited websites in the Tranco list, this study was able to check which publishers use third party ad iframes via the Google Display Network (GDN), and which of those sites were serving ads without requiring SafeFrames or any form of sandboxing. These sites may be foregoing a layer of protection that could mitigate certain types of malicious ad exploits.

Methodology

The methodology for this study was as follows:

  1. Each domain in the list of 10,000 most widely read sites was checked for the presence of a Google Publisher Tag (GPT) javascript.

  2. If the domain has the GPT installed, the landing page of the domain was loaded and checked for Google Display Network (GDN) iframes. Of the 10,000 websites checked, only 1,325 were observed loading at least one GDN ad iframe.

    1. document.body.querySelectorAll('iframe[id^=google_ads_iframe')

  3. If there was at least one GDN iframe, four techniques were used to determine if it was sandboxed or a SafeFrame

    1. Does the iframe have any sandbox attributes whatsoever?

    2. Does the iframe have the “data-is-safeframe” attribute set to true?

      Screenshot of an iframe that has the
    3. Does the iframe “src” attribute contain the string “tpc.googlesyndication.com/safeframe” or come from a Google SafeFrame URL?

      Screenshot of an ad iframe whose source attribute loads from
    4. Does the GPT console label a given iframe as a SafeFrame or a “Friendly Iframe”

  4. If any of those above criteria were met, the iframe was labeled as a “SafeFrame or sandboxed ad iframe”. If none of the criteria were met, the ad iframe was labeled as an unsandboxed iframe.

  5. For the final classification, Adalytics checked if any of the ad iframes from step 4 were unsandboxed iframes, or if they were all sandboxed or SafeFrames. If a publisher has configured the “setForceSafeFrame” attribute to “true”, this would make all GDN iframes load as SafeFrames.

Readers will note that some of the criteria in step 3 are relatively loose - for example, an iframe can have the sandbox attribute, but every single “allow” attribute enabled, and this methodology would still consider said iframe to be sandboxed. This would obviate many of the security protections offered by sandboxing. 

As a final check, the analysis checked whether each non-SafeFrame was embedded as same-origin as the main page. If the iframe and and parent window are of the same domain, a browser’s same-origin policy protections would not protect a user from malicious Javascript embedded within an iframe. All of the non-sandboxed Google ad iframes appeared as same-origin as the parent windows they loaded onto.

Screenshot of Chrome developer tools, showing an ad iframe that is not sandboxed

Example of a Google ad iframe that is not sandboxed or SafeFramed. This iframe is loaded from the same origin as the parent window, so cross-origin browser protections would not be applied in this context to protect a user from malicious Javascript inside the ad iframe.

Domains with unsandboxed ad iframes

1,325 domains in the list of top 10,000 websites were observed loading ad iframes via the Google Display Network. Despite the relaxed criteria set in step 3, only 29.4% of sites (390 domains) were observed loading ad iframes exclusively as SafeFrames or sandboxed iframes. The rest (70.6% or 935 websites) were observed loading GDN ad iframes with no SafeFrame or sandboxing protections.

Interactive AirTable showing which publishers were observed loading Google display ads within unsandboxed iframes. If at least one ad iframe loaded without any SafeFrame or sandbox attributes, the publisher was labeled as having "Some Regular Ad Iframes". If all ad iframes were loaded as either SafeFrames or with some sandbox attribute, the publisher domain was labeled as "All SafeFrames". This AirTable itself is loaded as an iframe, with some sandbox attributes enabled.

The New York Times is an example of a publisher that has included code on their website to force all GDN iframes to load as SafeFrames. The “setForceSafeFrame” function directs the publisher tag to ensure that all ad iframes utilize SafeFrame protections. The Google Publisher Tag documentation explains that “setForceSafeFrame” will force all subsequent ad requests “to be rendered using a SafeFrame container”.

Screenshot of Javascript code from the nytimes.com landing page, showing code to enforce SafeFrames on the website.The New York Times landing pages includes configurations to enforce SafeFrames on all ad iframes that load on their webpage.

The methodology in this study relied on sampling rather than extensive code interrogation. Each website was opened several times and checked for the presence of at least one non-sandboxed ad iframe. It is quite likely that many of the 390 sites that were seen loading ads exclusively within SafeFrames are not universally enforcing this protection. 

The list of websites that were observed loading non-sandboxed ad iframes includes several sites that are commonly read by Congressional staffers. For example, a 2018 report on the media habits of congressional staff found that many Republican and Democrat staffers regularly read Politico and The Hill. Both of these sites were seen loading unsandboxed, same origin ad iframes.

Sites such as Defense News and Breaking Defense, which may be commonly read by defense contractors and military policy makers, also loaded unsecured ad iframes.

Ad buying platforms can be used to target individuals in sensitive locations and IP addresses

Many demand-side platforms (DSP) used by marketers to configure their digital ad campaigns offer a plethora of targeting settings. A marketer can choose to target users by cookie-based demographic and behavioral segments, by specific publisher websites, or via geo-location restrictions. Some DSPs allow marketers to specify a range of IP addresses or postal codes. Popular DSPs include Google’s DV360, Xandr Invest, and The Trade Desk.

While the aforementioned targeting options can help marketers reach their intended audiences, these tools can also be abused for nefarious purposes. The recent CISA advisory warns that “adversaries can even create carefully tailored ads as part of a targeted campaign against a specific victim”.

During the course of this research project, Adalytics consulted with a marketer who had access to a variety of DSPs. This marketer was asked to verify whether certain DSP’s allowed him to configure ad targeting against sensitive geo-locations. The marketer was able to set geo-location targeting for ads against the following ‘sensitive’ US postal codes:

  • US Senate Office Buildings (20510)
  • US House of Representatives Office Buildings (20515)
  • CIA Headquarters in Mclean, Virginia (22101)
  • NSA headquarters in Fort Meade, Maryland (20755)
  • US Strategic Command at Offutt Air Force Base (68113)
  • US Special Operations Command at MacDill Air Force Base (33621)
  • Pentagon - Secretary of Defense (20301)
  • Pentagon - Joint Chiefs of Staff (20318
Screenshot from an ad buying platform (DSP), showing geolocation targeting to sensitive postal codes

Screenshot from an ad buying demand-side platform (DSP), which allows geo-location targeting to a number of 'sensitive' postal codes, with no errors shown.

On the other hand, attempting to target ads to postal codes for Armed Forces - Americas (34042), Armed Forces - Pacific (96367), and Armed Forces - Europe (09014)

Screenshot from an ad buying platform (DSP), showing geolocation targeting does not work properly for certain Armed Forces postal codes

Screenshot from an ad buying demand-side platform (DSP), which does not allow geo-location targeting to Armed Forces postal codes for Armed Forces Pacific, Europe, or Americas. Attempting to target these zip codes generates an error.

Building upon the 2021 CISA advisory warning, a foreign intelligence service could theoretically create a malware-loaded ad creative, and use a DSP to specifically target it to certain geolocations or IP ranges that are enriched for high-value government officials or staff. To further enhance the likelihood of success, they could target their malware-laced ads exclusively to domains that do not enforce iframe sandboxing and are frequently visited by government officials.

A recent report by the Harvard Kennedy School noted that ad tech services are already being “weaponized” and used for offensive operations by entities such as Russia’s Internet Research Agency. These operatives have previously used ad tech to target Americans who were interested in State Police, Law Enforcement in the United States, Police, Sheriffs in the United States, as well as groups like National Police Wives Association and Police Wives United.

Conclusion

Caveats & Limitations

This analysis involved a review of the Tranco 10,000 most popular website landing pages on a single date in February 2021. These sites can enable or disable ad iframe sandboxing at any point in the future. It is also possible that these websites use different configurations on different parts of their websites - they could theoretically enforce SafeFrame only on certain pages, just not their landing pages. Ads can also load inside SafeFrames if the advertiser enabled this feature. It is possible for a publisher to not enforce SafeFrames, but all the ads that happened to have loaded on their website were from advertisers who had enabled SafeFrames. 

Secondly, the analysis only focused on Google display ads - advertisements served through other networks or means were outside the analysis’ scope.

This study also did not focus on other mechanisms that could reduce malvertising attacks. Publishers can configure Content Security Policy response headers or meta tags, add X-XSS-Protection headers, block specific ad creatives on their publisher console, and scan ads that load on their web pages via security services such Confiant, Ad Lightning, and GeoEdge. Some of these services also integrate with the ad exchanges, which would prevent malicious ads from reaching publishers in the first place.

Lastly, the DSP analysis did not actually verify whether geolocation targeted ads would run against certain sensitive zip codes or IP ranges. The analysis only checked whether an ad campaign could be configured against those parameters without any error messages from the system.

Discussion

There are many ways in which malicious ads can escape detections or built-in browser protections. Although Google continuously scans all creatives that pass through its systems and many publishers use independent tools to audit ads, the fact that malvertising attacks get through each year suggests the need for continued vigilance. Over-relying on one layer of protection may lead to a false sense of security, and applying a “defense-in-depth” mentality with multiple, redundant precautions may be needed to protect readers from malicious ads.

There are a number of reasons why publishers should consider enforcing SafeFrames or sandboxing on their ad iframes. 

The first is a matter of best of practices - Google’s own documentation states that “To minimize the chances of malicious creatives serving, we recommend enabling SafeFrame whenever possible, in conjunction with the HTML5 sandbox attribute to prevent top-level navigation.”

Dennis Buchheim, the CEO of the IAB Tech Lab, recommended that publishers use SafeFrames, saying they are “the best scalable solution available to be used by both the sell side and buy side.

Certain ad management platforms, such as CafeMedia, already enable SafeFrames for the majority of their ad inventory. The Chief Strategy Officer of CafeMedia, Paul Bannister said “[Not having SafeFrames] ultimately costs more time and revenue [...] A publisher without SafeFrames has to deal with more mobile redirects and other malicious ad issues.”

Secondly is a matter of trust - certain consumers want to support news publishers’ business models, but are worried about opening themselves up to malware attacks. If malvertising attacks continue to spread at a large scale consumers (and government agencies) may be forced to adopt ad blockers.

Twitter poll showing that 18.3% of respondents use ad blockers to avoid malvertising

Twitter poll from February 2021, illustrating that some users adopt ad blockers primarily for security reasons.

Thirdly, publishers should consider the benefits of Safeframes or sandboxing out of rational self-interest. Unsandboxed iframes have been described as a perfect delivery vector to evade bot detections and scrape publisher’s content. By not sandboxing ad iframes, the publishers may be facilitating copy-cat websites. If government agencies feel the need to recommend ad blockers, it may also negatively impact publisher revenues.

SafeFrames are by no means a panacea. Certain types of malvertising attacks would require more extensive sandboxing or other types of security precautions. Nonetheless, they do reduce the probability of certain types of exploits, and when combined with other security precautions, can protect their audiences from malvertising attacks. Configuring SafeFrames or iframe sandboxing properly may involve some extra work initially, but it should hopefully save publishers time down the road when they reduce the number of malvertising attacks they have to track down.

On a final note, Congress and the US Department of Homeland Security should further consider the potential dangers of targeted malvertising attacks and develop policies to help protect various high value officials. One approach could be to restrict ad tech platforms from enabling geolocation or IP address targeting for sensitive government locations and network ranges. Google Earth has been known to remove photos of sensitive military locations at request from military officials. Facebook previously removed many of the military ad-targeting groups after being warned by an activist that these parameters would enable anyone to narrowly target US military personnel on the platform.

Take-away points

  1. Majority (70.6%) of news publishers that show display ads do not sandbox iframes, which can increase readers’ exposure to malvertising attacks
  2. Ad tech platforms can theoretically be used to target high value government officials with malicious ads. 

  3. Congress and the Department of Homeland Security should consider requesting that ad tech platforms exclude targeting parameters against sensitive geo-locations or IP addresses

Receive future blog posts

Subscribe below to get new articles