In the past few weeks our very own VMware Contexa has reported a surge of malicious PDF files (shown in Figure 1). Attackers will use a malicious PDF to lure victims into visiting fraudulent web sites using fake captcha images: when the captcha image is clicked, and the website is loaded, the browser opens a modal dialog asking the user to allow push notifications as shown in Figure 2.
Figure 1: Peaks of malicious PDFs.
Figure 2: Modal dialog asking to allow notifications.
Push notifications should be allowed only with caution as the chance of receiving malicious notifications is high. Here, we are going to take a deep dive into what a push notification is, how it works, and how it can be abused by a malicious threat actor.
What are push notifications?
A push notification is a message that can be sent by an application to the user even when the target application is temporarily closed; a web push notification is a type of push notification that is sent from a website to the user’s browser.
There are four essential components behind a web push messaging system:
- Website: this is the site that requests additional permissions to deliver push notifications to the user.
- Application server: this is the entity that sends push messages to the user via the push service.
- User agent: this is the web browser that displays the push notification to the user.
- Push service: this is the trusted, always-on, man-in-the-middle component that delivers the push messages to the browser; each browser uses a different push service: Chrome uses Firebase Cloud Messaging, Firefox uses MDN servers.
A push messaging system leverages a service worker installed and running inside the web browser. A service worker is a JavaScript file that encodes the logic handling the processing of push messages sent by the application server. In particular, when the user visits the website for the first time, the service worker needs to be registered to support push messaging; this occurs through a function called register(). The user then needs to subscribe for push messages, which is done through a function called subscribe(). Here, the necessary permissions are provided to the application server to allow push messages to be delivered.
The push message sent by the application server are application-specific; this means that they can be an encoded JSON, simple text, or a simple array of bytes. It is the application server and the service worker that decide and agree on the actual communication protocol. Whenever the application server wants to send a message, it needs to make an API call to the push service, which in turn sends the message to the web browser. The entire push notification system is shown in Figure 3.
Figure 3: Push notification system.
How push notifications are abused by malicious attackers
As we discussed in the previous section, to send push messages an application server sends data to the push service; this data can be anything, and its format is decided by the application server. If the application server is malicious, its malicious activity will involve sending a push message intended to trigger a malicious behavior in the service worker.
It is important to note that it is the service worker that specifies what action is to be taken when the push message is received. In some cases, the worker merely displays a system notification. For example, the service worker can be leveraged to display notifications containing malicious content; malicious content can in turn be links to other fraudulent sites.
A notification can be as malicious as the service worker can be. Service workers do not have access to the Document Object Model or DOM of the website and thus cannot modify it. Also, the service worker cannot run if the browser is not open. So, any malicious action to be taken via the push notification can happen only if the browser is open. Once closed, the service worker will not run. The scope of the service worker is set during its registration and the worker can only operate in that scope. It cannot control URLs other than those in its scope. For instance, if a worker for a website xyz.com has a scope of /abc/, the worker can only access resources under xyz.com/abc/.
Malicious notifications in practice
All malicious PDF files part of the peaks displayed in Figure 1 were structurally similar. In this blog post we show a detailed analysis of 85f0f107123c097f747f773fdff3c6f31db52b60. The PDF does not contain any exploit, or any code per-se malicious. Instead, when the file is opened, it shows a fake captcha image (see Figure 4), which clearly attempts to social engineer the user into clicking the image.
Figure 4: PDF file with fake captcha image.
The image is a simple link leading to a web site prompting the user to allow notifications (see Figure 5).
Figure 5: Web site asking the user to allow notifications.
This is the stage when the service worker for the push notification is registered; if the user clicks ‘Allow’, the service worker is subscribed to accept push messages. This phase is executed by an obfuscated JavaScript ultimately responsible for installing the service worker: it had snippets from different languages like Russian, Arabic, and English, and it contained random strings of numbers and letters and a lot of other obfuscated text. The deobfuscated code is shown in Figure 6 and Figure 7.
Figure 6: Deobfuscated JavaScript code.
Figure 7: Deobfuscated subscribe() function.
The JavaScript code does the following:
- Checks if the service worker is registered, and if so it installs the service worker to check the subscription.
- Checks if the user has subscribed to receiving notifications; if notifications are allowed, the target URL is set to “hXXps://ttraff[.]cc/LJxW3x?keyword=plantronics c054a headset user guide”
- If notifications are not allowed, then the target URL is set to “hXXps://4[.]checkmerobot[.]cc/index.php?p=geygioddga5dmojsgy&sub1=wbly&sub3=1rdkkbc40a91s&sub4=plantronics+c054a+headset+user+guide”. This is the initial page where the user is prompted to allow notifications.
The JavaScript file “b81698fd2.js” is the service worker containing the logic specifying the actions to be taken upon receiving a push message (see Figure 8). In this specific case, when a notification is clicked, the service worker either opens the web site, or brings its tab into the foreground if already open.
Figure 8: the service worker contained inside b81698fd2.js.
This specific push notification was used to take the user to a target URL (as shown in Figure 9). Until the user gave the necessary permissions to the push system, the notification permission pop up was repeatedly displayed in a loop. The attacker abused the push system to ensure the user was taken to a particular malicious URL.
The push messages received by the user can be viewed using the developer tools of a web browser like Chrome. The ‘Application’ tab shows all the service workers of the website, and the service worker files can be accessed from here, as shown in Figure 9.
Figure 9: Service worker file in the ‘Application’ tab of browser developer tools.
On line 17 of Figure 8, the service worker tries to access ‘data.title’ and ‘data.body’. The content of these fields can be seen under the ‘Background Services’ tab. Under this tab there is a tab called ‘Notifications’ as shown in Figure 10. This is where the title and body of the push message are displayed.
Unfortunately, at the time of our analysis, the target URL had been already cleaned up, as nothing was hosted on its domain, so both screenshots displayed in Figure 9 and Figure 10 are taken from a benign test web site; the process to inspect a malicious web site is however identical. While we could not investigate this campaign further, previous reports indicate that the target URL had been involved in many drive-by-download and phishing attacks.
Figure 10: Content of a push message as shown in the browser developer tools.
Conclusions
In this blog post we explained what push notifications are and how a malicious PDF is used to exploit them. We also showed the details of a SPAM campaign using PDFs leveraging notifications to continuously display links to fraudulent web sites. This is unfortunately yet another example of how threat actors are adept at exploiting new features, no matter how mundane. This highlights the importance of keeping your defenses up to date at all costs. Solutions like NSX Network Detection and Response that can analyze the reputation of URLs, even when they are included as links inside a PDF file, are the obvious cornerstone of a good security posture.
